去年年底我第一次拿到 ESP32-P4 开发板时，第一反应不是点灯，而是想试一件在别人看来有点“魔怔”的事：把大语言模型跑上去。这颗芯片没有 NPU，只有双核 RISC-V，外部挂 PSRAM，怎么看都不像是跑 LLM 的料。但端侧 AI 这件事，最有趣的部分恰恰就是“把不可能压到刚好能用”。第一次完整跑通时，模型生成速度只有 0.61 tok/s，一句话要等十几秒。经过两个多星期的折腾，我把这个数字拉到了 4.31 tok/s，整体提升了 7 倍左右。这篇是“00 号系列总览”，我不会一上来就把所有优化细节全部倒完，而是先把整条链路讲清楚：为什么选 ESP32-P4、0.61 这个数字是怎么测出来的、4.31 是用哪几招换回来的、后续系列文章会分别展开哪些内容。如果你正在评估 MCU 上做端侧 LLM 的可能性，或者手里刚好有一块 P4 开发板，这篇总览可以帮你建立全局判断。
1. 为什么偏要在 MCU 级芯片上跑 LLM：从选型逻辑说起
1.1 端侧 LLM 的真实价值不是什么“离线聊天”
先泼一盆冷水：想在 MCU 上跑出一个能陪你畅聊的 ChatGPT，目前不现实。但 LLM 的价值远不止“聊天”这一种产品形态。
我接触到的真实需求集中在三个方向：一是隐私敏感场景，比如医护设备或者工业控制面板，用户指令不想离开设备；二是完全离线的环境，设备在仓库、野外、产线上，网络不稳定甚至根本没有网；三是成本敏感的消费硬件，比如玩具、遥控器、智能家电，不可能为每个设备配一台云端推理服务器。
在这些场景里，设备端真正需要的是“短指令 + 结构化输出”。用户说一句“把会议室温度调到 25 度，并且把投影打开”，设备端模型直接输出一段 JSON 或固定格式的指令，再交给本地控制逻辑执行。这种任务的输出长度通常只有 20 到 40 个 token，4 tok/s 意味着 5 到 10 秒出结果，用户是可以接受的。反过来，如果拿它做实时语音对话，语音识别、生成、语音合成三段延迟叠在一起，体验就很糟糕。
所以，端侧 LLM 的正确定位是“小生成器”，不是“大模型替代品”。它把原来必须靠云端理解的那一小段逻辑，挪到了本地。
1.2 为什么是 ESP32-P4 而不是其他平台
很多人会问：想跑 LLM，为什么不用树莓派？或者直接用带 NPU 的 AI SOC？
树莓派的优势是能跑 Linux，生态成熟，但成本、体积、功耗都不适合做嵌入式设备。带 NPU 的方案理论上算力更高，可开发链路过长，很多 SDK 是闭源的，模型转换工具还经常和最新模型脱节，调试起来非常难受。ESP32-S3 是乐鑫上一代网红，跑语音唤醒、简单分类没问题，可内存带宽有限，跑序列生成模型会很吃力。
ESP32-P4 正好卡在一个很有意思的位置：它有一颗主频 400MHz 级别的双核 RISC-V 处理器，带向量指令扩展，支持外部大容量 PSRAM，功耗和成本又维持在 MCU 级别。没有 NPU 听起来是短板，但好处也很直接：所有优化手段都是显式的，带宽、多核、向量化、内存布局，每一样都可以自己控制。对于想真正搞懂端侧推理的人来说，这反而是一个更好的学习对象。
| 平台 | 架构与算力 | 内存/存储上限 | 开发难度 | 成本（相对） |
|---|---|---|---|---|
| ESP32-S3 | 单核/双核 Xtensa | 通常 8MB PSRAM | 较低 | 低 |
| ESP32-P4 | 双核 RISC-V + SIMD | 大容量 PSRAM，视模组而定 | 中 | 中 |
| 树莓派 Zero 2W | ARM Cortex-A53 四核 | 512MB LPDDR | 中（Linux） | 中 |
| 带 NPU 的 AI SoC | ARM + NPU | 视型号而定 | 较高 | 高 |
做本次项目时，我更看重的是“在一颗没有现成 AI 软件栈的芯片上，从零把推理链路拎起来”这个过程。它带来的经验是可迁移的：今天能优化 ESP32-P4，明天换任何一颗新 MCU，思路都是同一套。
1.3 先把 4.31 tok/s 的预期摆正
tok/s 是 tokens per second，也就是模型每秒能生成多少个 token。token 不能简单理解为“字”，它是模型的基本处理单元。中英文混合时，一个 token 可能是一个汉字、一个英文单词的一部分，或者一个标点。
4.31 tok/s 是什么概念？相当于模型每秒往外吐 4 个多 token，写一个 50 token 的短句需要 11 秒左右。你说它快吗？肯定不比云端快。但在 MCU 级设备上，这已经是一个“能做成产品”的速度，前提是把任务设计成短输出、结构化输出的形态。
我把这个数字当作整个项目的锚点。后续所有优化，都以“不牺牲语义正确性、不把上下文压缩到不可用”为前提。如果只为了追速度把上下文砍到 32 token，那这个 tok/s 就没有意义了。
2. 第一版 0.61 tok/s：一个能跑的试验系统是怎么搭起来的
2.1 最小可用系统的四个组成部分
第一个能跑的系统，核心是由四块拼起来的：模型文件、推理内核、内存布局、基准测试外壳。
模型方面，我选的是开源的小参数 GGUF 格式模型，参数规模控制在 0.1B 级别，量化用 Q4_K_M。GGUF 是 llama.cpp 生态的标准格式，优势是权重布局紧凑、支持多种量化档位，现在已经成了本地推理的事实标准。之所以没有选更大的模型，原因很简单：权重体积必须能塞进板子上的 PSRAM，同时还要给 KV cache、中间激活、运行时缓冲区留出余量。
推理内核没有直接上完整的 llama.cpp。完整版的设计目标是桌面和服务器，动态内存分配、mmap、复杂的多线程调度，这些在 MCU 上都是负担。我用的是一套裁剪过的 C 推理实现，保留 Transformer 的完整计算图，但把内存分配改成静态化，手动管理每一块缓冲区。
内存布局遵循一个基本原则：权重常驻 PSRAM，KV cache 也放 PSRAM，只有最频繁访问的中间变量、反量化后的临时缓冲区放内部 SRAM。这个布局第一版就定了，后面优化时基本没有大改。
2.2 0.61 这个数字是怎么测出来的
做性能优化之前，必须先定义“什么叫快”。一开始我犯过一个错误：用“启动时间 + 生成 100 个 token 的总时间”去除 token 数，得到的结果看起来还可以，但那是被 prompt 预填充阶段稀释过的假数字。
后来我统一了测量协议：固定一段 prompt，固定生成 token 数量，temperature 设为 0，保证结果可复现；只统计从第一个生成 token 到最后一个生成 token 之间的 decode 时间，不包含 prefill。下面是测量代码的示意：
/* 伪代码/示意片段：用系统定时器统计 decode 阶段的平均速度 */ int64_t start = time_us(); for (int i = 0; i < GENERATE_TOKENS; i++) { model_decode(&model, &sampler); // 生成一个 token } int64_t elapsed_us = time_us() - start; float tps = (float)GENERATE_TOKENS / (elapsed_us / 1e6f); printf("decode tps: %.2f\n", tps);第一次按这个协议跑出来的结果，就是 0.61 tok/s。这个数字成了整个项目的基线。后面每做一步优化，我都会把同一份协议再跑一遍，记录在案。
2.3 第一版慢在什么地方
拿到 0.61 之后，我做的第一件事不是改代码，而是问“时间花在哪了”。
第一个显而易见的瓶颈是：所有计算都是标量的，乘加是一个一个算的。普通 MCU 上没有 GPU 那么方便，但 ESP32-P4 有向量指令扩展，第一版实现完全没有用上。
第二个瓶颈是单核包办一切。每个 token 的生成过程，既要读权重、又要做矩阵乘、还要做注意力、采样、解码。计算单元在忙的时候，存储总线在闲着；总线搬运权重的时候，计算单元又在空转。
第三个瓶颈是内存访问没有对齐。PSRAM 走的是多线 SPI 接口，如果读取地址不对齐、访问长度太短，有效带宽会低得离谱。第一版代码里到处是小段分散读取，等于每次从很远的仓库搬回来一块很小的货。
更隐蔽的是，采样器和 tokenizer 也在同一颗核上跑。虽然它们本身计算量不大，但如果在 decode 循环里每次都跑一遍完整的分词回退逻辑，积少成多也很痛。把时间分布拆开之后，局面很清楚：大头在权重搬运等待，矩阵运算本身反而没那么慢。
3. 7 倍提升怎么来的：优化矩阵与每一步的收益边界
3.1 优化收益总表
从 0.61 到 4.31，不是一步跳上去的，而是分阶段累积的结果。每一步的收益会因为模型、PSRAM 布线、运行温度不同而浮动，下面这张表是在本项目环境里整理出来的参考值。
| 优化阶段 | 主要动作 | 收益参考 |
|---|---|---|
| 第 1 阶段 | 权重读取对齐、批量化突发读、减少分散小段访问 | 1.3~1.6x |
| 第 2 阶段 | int4 反量化与矩阵乘融合，避免中间结果反复搬运 | 1.2~1.4x |
| 第 3 阶段 | 双核流水线：一个核预取权重，一个核执行计算 | 1.5~2.0x |
| 第 4 阶段 | KV cache 与注意力路径精简，减少重复计算 | 1.1~1.3x |
| 第 5 阶段 | 采样器与 tokenizer 开销削减、词表优化 | 5%~10% |
把这些倍率乘起来，大致就是 7 倍。之所以精确数字不好给，是因为有些优化是乘数关系，有些在特定模型上会被其他瓶颈掩盖。比如权重读取对齐之后，矩阵乘融合的收益会更明显；如果不先解决带宽问题，单纯给矩阵乘做向量化，可能只有 10% 的提升。
3.2 为什么存储带宽是第一个矛盾点
MCU 上跑 LLM，本质上是个 memory-bound 问题，不是 compute-bound 问题。原因是自回归生成的特殊性：每生成一个 token，都需要把模型的全部权重重新读一遍。权重不会因为上次读过就缓存住，因为模型太大了。
这个特性可以用一个很简单的公式来理解：
理论最高 tok/s ≈ 存储有效带宽 / 单 token 需要读取的权重字节数如果某个模型的量化权重是 60MB，PSRAM 有效带宽做到 60MB/s，那么理论上限就是 1 token/s。反过来，想提高 tok/s，要么压缩读取量（用更狠的量化），要么提高有效带宽（访问对齐、突发读、DMA 预取）。
所以整个优化的第一个矛盾点，根本不是把加法变成 SIMD，而是让权重“更顺畅地”从 PSRAM 流向 CPU。第一版之所以只有 0.61，很大程度上就是因为有效带宽离硬件理论值差了一个数量级。
明白了这个逻辑之后，优化顺序就清晰了：先解决搬运问题，再解决计算问题，最后才去抠采样、分词这些边角料。这也是为什么我把“内存对齐 + 突发读”放在第一阶段。
3.3 量化格式的选择及其边界
量化是直接减小“单 token 读取字节数”的手段。可选档位很多，从 Q2_K 到 Q8_0，我最后选了 Q4_K_M，而不是更低或更高。
原因是要平衡体积和质量。Q2_K 可以做更小，但小模型本身表达能力有限，再压到 Q2，输出的语义就开始“变形”了。Q8_0 质量好，但体积几乎翻倍，直接影响带宽和 PSRAM 容量。Q4_K_M 在体积和精度之间比较稳妥，也符合 GGUF 生态里“中端均衡档位”的定位。
选型时还冒出来一个容易被忽略的点：词表大小。两个参数规模相近的模型，词表一个 32k、一个 64k，embedding 矩阵的体积会差很多，这在桌面端无所谓，在 MCU 上可能就是几十 MB 的差异。所以不能只看模型榜单的跑分，还要看 tokenizer 词表大小和层宽，这些都属于“存储成本”的一部分。
4. 可以先点破的三个优化内核：带宽、解码阶段和双核协作
4.1 向量化不等于快，先保证数据进得了 CPU
很多朋友一听说优化矩阵乘，第一反应就是上 SIMD。这个方向是对的，但不能放在第一步。
我实际踩过的坑是这样的：先花了一天时间把矩阵乘的部分改成向量化版本，跑了之后速度几乎没变。原因很直白——CPU 在等权重数据从 PSRAM 搬进来，向量指令再快，也只能处理已经在寄存器或者 SRAM 里的数据。数据到不了，计算单元就是在空转。
正确的顺序是先让权重批量、连续、大块地进入 SRAM 临时缓冲区，再让向量化代码去处理这块连续数据。具体操作上，可以用 DMA 或者多线突发读的方式，把一块权重一次性拉进缓冲区，然后计算单元跟上。这和流水线的思路是一致的：搬运和计算重叠起来，总线在传下一块，CPU 在算当前块。
我在第一阶段只做了“读取对齐 + 突发读”，就把速度拉上来一截。这足以说明，在 MCU 上，数据管线往往比算力优先级更高。
4.2 解码阶段才是主战场，KV cache 和 QKV 不是玄学
很多人第一次接触 Transformer 注意力机制时，会被 Q、K、V 这几个字母绕晕。我后来跟同事解释时用了个查资料的类比：Query 是你想搜的关键词，Key 是词条上的标签，Value 是标签对应的正文内容。模型先算 Query 和各条 Key 的相似度，再用相似度作为权重，把对应的 Value 加权求和。这就是注意力计算的大致逻辑。
在文本生成场景里，这个机制会带来一个麻烦：模型每生成一个新 token，都要让最新的 Query 去和前面所有历史 token 的 Key、Value 做注意力计算。如果不把历史 K/V 存下来，每来一个新 token 就把前面全部重算一遍，复杂度会变成序列长度的平方。
KV cache 就是干这个的：把已经算出来的历史 Key、Value 缓存住，后面的 token 直接读取使用。对 MCU 来说，KV cache 的大小直接决定了最大上下文长度，因为它是动态膨胀的。我的做法是静态分配一块固定大小的 KV cache，通过牺牲一部分运行时内存，换来确定性的内存布局和更少的边界检查。
优化注意力路径时，我做了两件小事：一是把 QK 的分数计算和 softmax 的 max/sum 归约尽量合并，减少对中间内存的读写；二是把 KV cache 的存储对齐到 cache line 长度，避免跨行访问。这两项都不起眼，但叠在一起能贡献 10%~20% 的速度改善。
4.3 双核协作的真相：别让同步开销吃掉收益
双核 RISC-V 听起来就是天然的加速器，但双核写不好，反而可能比单核更慢。最常见的错误是：两个核同时操作同一个共享缓冲区，为了安全加了一堆锁，结果大部分时间都在互相等待，核心间的通信成本比计算成本还高。
我最终采用的结构是生产者/消费者流水线。一个核专职从 PSRAM 预取下一块权重到 SRAM ping-pong 缓冲区，另一个核专职计算当前缓冲区里的权重。两个核之间通过一个无锁的、容量为二的环形队列通信。缓冲区的状态有明确的“空/满”标识，生产者只会写那些已经被消费者消费完的槽位，消费者也只会读到生产者已经完成的槽位。
这套设计比一开始用互斥锁快很多。实测下来，如果同步粒度太细，双核收益会被打折 15%~20%；改成粗粒度的缓冲交接之后，收益才真正体现出来。
还有一个容易翻车的点：两核各自需要的代码路径和数据布局，必须尽量避免 cache line 冲突。如果两个核频繁写同一个 cache line 的相邻地址，硬件一致性开销会非常惊人。把关键数据结构按核分开，是很便宜的优化。
5. 性能数字必须能复现：测量协议与体检项
5.1 让 tok/s 可复现的测量协议
性能优化最怕的就是“感觉快了”，最后还是要有数据说话。我定下的测量协议很简单，但非常严格，整个项目期间都没变过。
固定模型文件、固定 prompt、固定生成 token 数量、固定 temperature 和 top-p。每次运行前先做 3 次预热，排除冷启动以及 PSRAM 初始化带来的偏差。正式记录时，同一配置跑 5 次，取中位数，而不是平均值。原因是偶尔会出现一次由于中断或其他任务干扰造成的极端慢值，中位数更能反映稳定水平。
一个很典型的坑是：有人用“总耗时除以总 token 数”来报速度。prefill 阶段是对整段 prompt 一次性并行计算，速度非常快；decode 是逐 token 生成，速度慢很多。把两者混在一起算平均，报出来的数字会更好看，但它不能说明实际用户体验。所以我的报告里，prefill 和 decode 永远分开记录。
5.2 除了 tok/s 还要看的几个指标
tok/s 只是结果，真正决定优化方向的是过程指标。我习惯在做每个版本测试时，同时记录四类数据：
| 指标 | 观察工具/方法 | 说明 |
|---|---|---|
| PSRAM 带宽利用率 | 总线计数器或估算 | 看权重搬运是否接近硬件上限 |
| 双核忙闲占比 | FreeRTOS 任务统计 | 检查两核是否均衡、是否互相等待 |
| 峰值内存占用 | 静态内存统计/堆监控 | 防止优化导致内存越界 |
| 功耗与温度 | 板载电流计、温度传感器 | 过热会触发降频，速度异常时先看它 |
后两项容易被忽略。我遇到过好几次优化后速度反而倒退的情况，最后发现不是代码问题，而是板子供电不够，芯片降频了。没有监测手段的话，这种环境因素会严重干扰判断。
5.3 优化后先做语义一致性 sanity check
速度上去了，还要确认模型“没有变傻”。算子的数值精度变化、量化粒度调整、softmax 的计算顺序改变，都可能让输出结果漂移。我用的方法很简单：
先把优化前的模型跑一组固定 prompt，记录输出；优化后跑同样的 prompt，做语义层面的对比。温度设为 0，理论上输出应是确定性的。如果输出出现明显不同，尤其是反复出现乱码、重复生成死循环，就要怀疑数值精度问题。
还有一个便宜的检测方法：给同一个 prompt 连续跑 5 次，temperature=0 时输出必须完全一致。如果结果有跳动，说明有未初始化变量或内存访问越界，而不是模型本身的问题。这一步放在每次改完内存布局之后，能快速过滤掉非常隐蔽的 bug。
6. 系列路线图与动手建议：把这份经验搬回你自己的板子
6.1 后续系列文章会分成这几条线
既然这是“00 号总览”，后面每一篇都会把优化矩阵里的某个环节拆开讲透。我初步规划的路线是这样的：
- 01：ESP32-P4 开发环境与最小推理 demo，覆盖工具链版本和交叉编译的坑；
- 02：模型选型与 GGUF 量化，怎么根据 PSRAM 容量倒推模型参数上限；
- 03：内存布局与 PSRAM 带宽调优，包括对齐、突发读、DMA 预取；
- 04：int4 反量化与矩阵乘融合，手把手写一个向量化版本；
- 05：双核流水线与 ping-pong 缓冲区的实现细节；
- 06：prefill/decode 拆分，以及 KV cache 的静态管理；
- 07：落地案例，把 4.31 tok/s 变成一个小型离线指令解析器。
这个顺序基本就是当初项目的推进顺序。每一篇都会给到可以独立复现的步骤和代码片段。
6.2 想复现的读者，先盯住这三件事
第一件：硬件别省。建议直接选择带大容量 PSRAM 的 P4 模组，并且优先考虑板载电源质量更好的开发板。供电不行的板子，跑推理时会出现明显的频率波动，干扰你判断优化效果。
第二件：工具链版本固定。ESP-IDF 的版本以及 RISC-V 工具链版本，会直接影响是否能用上向量指令扩展。建议找一个已经被验证过的组合，先原样跑通，再升级。不要一开始就追最新版。
第三件：先在 PC 上把模型量化好、验证过，再烧进板子。用 llama.cpp 在电脑上加载同一个 GGUF 文件，跑同样的 prompt，记录一个“参考输出”。这样 MCU 上出现语义异常时，你马上能判断是模型转换的问题，还是板子代码的问题。
6.3 优化迭代时的几个实际心得
如果只让我说一条最重要的经验，那就是：每一步优化都要能回滚。我项目里每个阶段的代码都单独打 tag，情况不对就立刻退回上一个能跑的版本，而不是在坏代码上继续叠新的优化。找 Bug 的成本远高于写代码，能快速定位“哪一步改坏了”比什么都重要。
另一个心得是：永远先算理论上限，再定优化目标。用公式估算出“以当前量化模型和 PSRAM 带宽，理论上最多能到几 tok/s”，你就可以知道 4.31 距离天花板还有多远，避免花几周时间去追一个物理上达不到的数字。
最后一个建议是：优化 LLM 推理时，不要总想着“把矩阵乘写得多快”，先想想“数据进 CPU 这条路通不通畅”。对 ESP32-P4 这种没有 NPU 的芯片来说，带宽、流水线、内存布局，才是收益最大的地方。把这几个点啃下来，换到任何一颗 MCU 上，你都有一套可以复用的方法论。
