1. 项目缘起为什么要在 MCU 上跑大模型1.1 一个看似不务正业的念头第一次跟朋友聊起这个项目对方的第一反应是你疯了吧ESP32 跑 LLM那不是拿自行车拉集装箱吗说实话这个反应我完全理解。毕竟在大多数人的认知里大语言模型推理是 GPU 集群的活儿至少也得是带 NPU 的 SoC 才能勉强跑起来。而 ESP32-P4 是什么定位一颗双核 RISC-V 的高性能 MCU主频 400MHz带 768KB 片上 SRAM支持外挂 PSRAM典型应用场景是 HMI 人机界面、工业控制、智能家居中控这类活儿。但恰恰是这种错位感让我觉得有意思。我做了十多年嵌入式见过太多性能不够就换平台的惯性思维。可现实是很多边缘场景根本不允许你换平台——成本卡死、功耗卡死、体积卡死你手里就这一颗 MCU但业务方就是想要本地能对话的智能交互。这时候与其抱怨硬件不行不如把手里这颗芯片榨干看看极限在哪。这个系列要复盘的核心就是我把一个量化后的小参数 LLM 在 ESP32-P4 上从0.61 tok/s优化到4.31 tok/s的全过程整整 7 倍的提升。这不是一个跑通就完事的 Demo而是一次系统性的性能工程实践。我会把每一层优化为什么做、怎么做、踩了什么坑全部摊开讲清楚。1.2 这个项目适合谁看先说清楚受众免得你读了一半发现不是自己要的。如果你是想在 MCU 上做本地语音助手、离线命令理解、简单文本生成的嵌入式工程师这个系列对你价值最大。如果你是对RISC-V 架构优化、PIE 向量指令、MCU 级推理引擎感兴趣的技术爱好者也能从中拿到不少底层细节。如果你只是想找个现成方案直接抄那我得提前说这个项目需要你对内存布局、指令集、量化格式都有一定理解不是改个配置文件就能跑的。反过来说如果你期待的是在 MCU 上跑 7B 模型或者达到云端对话体验那这个项目不适合你。我们讨论的是参数量在千万级以下、经过激进的量化压缩、面向特定任务的小模型。它的定位是够用的本地智能不是替代云端大模型。1.3 先给结论7 倍提升从哪来很多人喜欢先看结果。我把整个优化路径的贡献拆解成一张表后面每个章节会详细展开。优化阶段关键手段吞吐 (tok/s)相对提升基线版本纯 C 参考实现无优化0.611.0x阶段一内存布局重构 PSRAM 缓存策略1.121.8x阶段二定点量化 算子融合1.953.2x阶段三RISC-V PIE 向量指令加速3.205.2x阶段四流水线调度 中断优化4.317.1x这张表是整篇文章的骨架。注意这不是简单的叠加每个阶段都建立在前一个阶段的基础上而且阶段之间有过反复——比如阶段三做完之后我发现阶段一的内存布局还有优化空间回头又调了一轮。真实的工程从来不是线性的。提示如果你只关心某一层优化可以直接跳到对应章节。但我建议至少把第 2 章的内存部分看完因为后面所有优化都依赖一个合理的内存布局这是地基。2. 硬件与模型选型先把牌看清楚2.1 ESP32-P4 这颗芯片到底什么水平要优化先得知道自己手里有什么牌。ESP32-P4 的关键规格我列一下这些数字后面会反复用到CPU双核 RISC-V最高 400MHz支持 RV32IMAFC 指令集扩展向量扩展支持 PIEPacked SIMD Extension这是后面加速的核心片上 SRAM768KB分多个 bank访问延迟不同外部存储支持外挂 PSRAM常见 8MB/16MB通过高速总线访问CacheL1 Cache 可配置L2 Cache 共享这里有个关键点很多人忽略PIE 不是标准的 RISC-V V 扩展它是乐鑫自己的一套 128 位打包 SIMD 指令。这意味着你不能直接套用标准 RISC-V 向量优化的经验得重新理解它的数据通路。我一开始就吃了这个亏按标准 V 扩展的思路写代码结果性能不升反降后面会详细讲。另一个坑是SRAM 的 bank 划分。768KB 听起来不少但它不是一块连续的高速内存。不同 bank 的访问延迟有差异而且和 CPU 核的亲和性不同。如果你把热数据放在远bank 上性能会莫名其妙地掉。这个细节在官方文档里写得很含蓄我是靠实测才摸清楚的。2.2 为什么选小参数模型而不是硬塞大模型模型选型上我一开始就放弃了塞个大模型的想法。原因很现实第一内存墙。一个 1B 参数的模型即使量化到 4bit也要 500MB 左右。ESP32-P4 外挂 PSRAM 撑死 16MB差了三十多倍。这不是优化能解决的是物理限制。第二带宽墙。LLM 推理是典型的 memory-bound 任务每生成一个 token 都要把模型权重过一遍。PSRAM 的带宽就那么多模型越大每个 token 的耗时越长吞吐直接崩掉。所以我选的是一个参数量在几百万级别、层数很浅、隐藏维度很小的模型结构。具体来说我用的是一个类似 TinyStories 级别的小模型做了激进的量化。它的能力边界很清楚能做一些简单的文本补全、固定格式的命令解析、短句生成。你让它写诗写代码它做不到但你让它理解打开客厅的灯这种指令它能干得不错。注意模型选型没有标准答案取决于你的任务。如果你的任务是固定意图分类甚至可以用更小的模型如果需要开放域对话那 MCU 平台基本可以放弃了。先想清楚任务边界再选模型。2.3 量化格式的选择为什么是 int8 而不是 int4量化这块我纠结了很久。理论上 int4 能把模型体积和带宽需求再砍一半对 memory-bound 的推理是巨大诱惑。但实测下来我最终选了int8 为主、部分层 int4的混合方案。原因有三精度损失int4 在这个小模型上精度掉得太狠生成质量明显下降很多任务直接不可用。反量化开销int4 需要额外的解包和反量化操作在 MCU 上没有专用硬件支持这些操作会吃掉不少 CPU 周期。PIE 指令友好度PIE 的很多向量指令对 int8 的支持更成熟int4 需要手动打包反而增加复杂度。这个决策背后的逻辑是在 MCU 上算力不是唯一瓶颈指令效率和内存访问模式同样重要。一个理论上更省带宽的方案如果引入了大量额外指令实际可能更慢。这个道理在后面每个优化阶段都会反复出现。3. 阶段一内存布局重构从 0.61 到 1.123.1 基线为什么这么慢先看基线版本。0.61 tok/s意味着生成一个 token 要 1.6 秒。这个速度基本没法用但它是一个诚实的起点。我 profile 之后发现时间主要花在三个地方权重读取每次推理都要从 PSRAM 读权重PSRAM 访问延迟高而且没有充分利用 cache。内存拷贝参考实现里有大量冗余的 memcpy数据在 SRAM 和 PSRAM 之间来回搬。算子实现矩阵乘法是朴素的嵌套循环没有任何向量化。其中权重读取是大头占了 60% 以上的时间。这符合预期因为 LLM 推理本质就是不停地读权重、做乘加。所以第一阶段的核心目标很明确让权重读取尽可能快。3.2 内存分层把热数据放进 SRAM我的第一个动作是重新设计内存分层。思路很简单把访问频率最高的数据放在最快的存储上。具体分层策略L1 层片上 SRAM放当前正在计算的层的权重、激活值、KV Cache 的热区。L2 层PSRAM放暂时不用的层权重按需加载。预取缓冲在计算当前层时异步预取下一层的权重到 SRAM。这里有个关键决策SRAM 只有 768KB放不下整个模型。所以我做的是逐层加载——每次只把当前层的权重搬进 SRAM算完再换下一层。这引入了搬运开销但换来的是计算时的高速访问。实测下来这个策略把权重读取时间砍掉了将近一半。但我也踩了个坑一开始我把 KV Cache 也放在 PSRAM 上结果发现随着生成序列变长KV Cache 的访问越来越慢。后来把 KV Cache 的热区挪到 SRAM性能又稳了一截。3.3 PSRAM 访问的隐藏陷阱PSRAM 这块我要单独讲因为坑最多。第一个坑是cache line 对齐。PSRAM 通过 cache 访问如果你的数据没有按 cache line 对齐一次访问可能触发两次 cache 填充带宽直接减半。我一开始没注意权重数组的起始地址是随机的性能波动很大。后来强制所有权重数组按 64 字节对齐性能立刻稳定了。第二个坑是访问模式。PSRAM 对顺序访问友好对随机访问很不友好。矩阵乘法如果按列访问权重性能会惨不忍睹。我改成按行访问、配合转置虽然多了一次转置开销但整体快了很多。第三个坑是bank 冲突。ESP32-P4 的 PSRAM 有多个 bank如果同时访问同一个 bank 会冲突。这个比较底层我是通过调整数据布局、把不同层的权重分散到不同 bank 才解决的。实操心得PSRAM 优化的核心就一句话——顺序、对齐、分散。顺序访问、cache line 对齐、跨 bank 分散。记住这三点能避开 80% 的坑。3.4 阶段一的小结与遗留问题阶段一做完吞吐从 0.61 提到 1.12接近翻倍。但我很清楚这只是开始因为计算部分还是纯 C 的朴素实现一点没优化。内存问题解决后计算瓶颈就暴露出来了。这就引出了阶段二。4. 阶段二定点量化与算子融合从 1.12 到 1.954.1 为什么浮点在这颗芯片上是奢侈品ESP32-P4 有 FPU但它是单精度的而且吞吐有限。LLM 推理里大量的乘加运算如果用浮点做FPU 会成为瓶颈。更麻烦的是浮点权重的体积是 int8 的四倍内存带宽压力也大。所以阶段二的核心是全面转向定点运算。我把权重和激活值都量化成 int8累加用 int32最后再反量化回需要的精度。这样不仅省带宽还能用整数运算单元避开 FPU 瓶颈。量化的关键是scale 和 zero point 的选取。我用的是对称量化zero point 为 0因为对称量化在硬件上更好实现反量化只需要一次乘法。scale 的选取我用的是 per-channel 而不是 per-tensor虽然多存了一些 scale 参数但精度损失小很多。4.2 算子融合减少内存往返量化之后我发现一个新的瓶颈算子之间的内存往返。比如一个典型的 Transformer 层有 QKV 投影、注意力、输出投影、FFN 等多个算子每个算子算完都要把结果写回内存下一个算子再读出来。这些往返在 MCU 上开销很大。于是我做了算子融合。最典型的是把矩阵乘 加偏置 激活函数融合成一个算子中间结果留在寄存器里不写回内存。这一下就省掉了大量的内存读写。融合的粒度需要权衡。融合太多寄存器不够用会溢出到栈上反而更慢融合太少内存往返省不下来。我是通过反复实测找到平衡点的大概融合 2-3 个算子比较合适。4.3 量化精度的实测对比量化精度这块我做了详细的对比测试因为这是能不能用的分水岭。测试方法是用同一组 prompt看生成结果的合理性和任务完成率。量化方案模型体积吞吐 (tok/s)任务完成率备注FP32100%0.9100%基准但太慢int8 对称25%1.9596%主力方案int8 非对称25%1.8597%精度略好但更慢int4 对称12.5%2.478%精度掉太多混合 int8/int418%2.191%部分层妥协最终我选了纯 int8 对称量化。int4 虽然快但任务完成率掉到 78%很多指令理解直接失败不可接受。混合方案是个折中但复杂度高收益不明显我后来放弃了。注意量化精度的评估一定要用你的实际任务不要只看 perplexity 这种指标。perplexity 好看不代表任务能完成我在这上面吃过亏。4.4 阶段二的边界阶段二做完1.95 tok/s累计 3.2 倍。但这时候我 profile 发现计算部分已经占了 70% 以上的时间内存优化带来的收益开始递减。这说明纯靠 C 代码和算法优化已经到顶了必须上硬件加速。这就是阶段三 PIE 的舞台。5. 阶段三RISC-V PIE 向量指令加速从 1.95 到 3.205.1 PIE 到底是什么为什么不是标准 V 扩展PIEPacked SIMD Extension是乐鑫在 RISC-V 基础上扩展的一套 128 位 SIMD 指令。它和标准的 RISC-V V 扩展有本质区别V 扩展是变长向量向量长度可以配置编程模型更灵活。PIE是定长 128 位打包 SIMD一次处理固定数量的数据比如 16 个 int8 或 4 个 int32。这个区别决定了优化思路完全不同。V 扩展你可以写向量化的代码让硬件去处理长度PIE 你必须手动把数据打包成 128 位然后一条指令处理一批。PIE 更像 ARM 的 NEON而不是 RISC-V 的 V。我一开始按 V 扩展的思路写结果编译器根本不认性能也没提升。后来老老实实按 PIE 的编程模型重写才吃到红利。5.2 矩阵乘法的 PIE 化改造矩阵乘法是 LLM 推理的核心也是 PIE 加速的主战场。我的改造思路是数据打包把 int8 权重和激活值按 16 个一组打包成 128 位。乘加指令用 PIE 的esp.vmulas.s8类指令做打包乘加一条指令完成 16 次乘加。累加器管理用 int32 累加器避免溢出最后统一反量化。这里的关键是数据布局要匹配 PIE 的打包方式。PIE 的乘加指令对操作数的排列有要求如果布局不对需要额外的 shuffle 指令反而更慢。我在权重加载阶段就做好了布局转换让计算阶段可以直接用。实测下来矩阵乘法部分加速了 2.5 倍左右。但整体吞吐只从 1.95 提到 3.20因为还有其他部分没优化到。5.3 那些 PIE 不擅长的部分PIE 不是万能的。我发现有几类操作 PIE 帮不上忙甚至可能拖后腿Softmax涉及指数运算和除法PIE 没有直接的指数指令得用查表或近似收益有限。LayerNorm涉及均值和方差计算归约操作 PIE 支持一般。激活函数像 GELU 这种PIE 没有直接支持得用多项式近似。这些部分我保留了标量实现没有强行 PIE 化。优化的原则是只在收益明显的地方投入不要为了全向量化而向量化。我见过太多人为了追求全部用上 SIMD把代码搞得极其复杂结果性能还不如标量版本。5.4 中断与流水线的初步尝试阶段三后期我开始尝试流水线调度。思路是在 PIE 计算当前数据块的同时用 DMA 预取下一块数据。这样计算和访存可以重叠理论上能进一步提升。但这里遇到了中断的问题。DMA 完成会触发中断如果中断处理太慢会打断 PIE 的计算流水。我一开始的中断处理写得很重结果流水线效果很差。后来把中断处理精简到极致只做标志位设置实际的数据处理放到主循环里性能才上来。这个阶段的经验是在 MCU 上做流水线中断延迟是隐形杀手。你的中断处理必须尽可能短否则流水线根本跑不起来。6. 阶段四流水线调度与中断优化从 3.20 到 4.316.1 双缓冲让计算和访存真正重叠阶段四的核心是双缓冲double buffering。原理很简单准备两块缓冲区一块用于当前计算一块用于 DMA 预取下一块数据。当计算完成时切换缓冲区同时启动下一次预取。听起来简单实现起来有几个关键点缓冲区大小太小DMA 启动开销占比高太大SRAM 放不下。我实测下来每块 16KB 左右比较合适。同步机制计算和 DMA 之间需要同步我用的是信号量 中断标志的组合。边界处理最后一块数据没有下一块可预取需要特殊处理否则会死等。双缓冲做完吞吐从 3.20 提到 3.8 左右。这是流水线带来的纯收益。6.2 中断优化的细节中断这块我做了几件事第一降低中断频率。原来每个数据块完成都触发中断我改成累积几个块再触发减少中断次数。第二中断处理极简化。中断里只设置标志位和切换缓冲区指针所有实际计算都在主循环里做。第三中断优先级调整。把 DMA 中断的优先级调到合适的位置既不能太高打断关键计算也不能太低导致响应延迟。这些调整加起来又贡献了 0.3 左右的提升。别小看这些边角料优化在 MCU 上它们往往是压垮性能的最后一根稻草。6.3 最终的 profile 分析4.31 tok/s 达成后我又做了一次完整的 profile看看时间都花在哪模块时间占比备注矩阵乘法 (PIE)45%已经是优化过的注意力计算20%含 Softmax部分标量激活与归一化15%标量为主内存搬运12%双缓冲后已大幅降低其他开销8%调度、中断等可以看到矩阵乘法还是大头但它已经是 PIE 加速过的了。进一步提升需要更激进的方案比如更低位宽、更深的流水线但收益递减明显。4.31 tok/s 对这个平台来说我认为已经接近实用边界。7. 常见问题与排查技巧实录7.1 性能不升反降的几种情况优化过程中我遇到过好几次改了反而更慢的情况这里总结一下PIE 化小矩阵小矩阵用 PIE 打包开销大于收益标量反而快。过度融合算子寄存器溢出数据频繁进出栈比不融合还慢。缓冲区过大SRAM 不够触发换页性能断崖式下跌。中断过于频繁中断开销吃掉流水线收益。这些坑的共同点是优化的收益不是线性的存在一个最优点。你需要实测找到它而不是理论上越多越好。7.2 内存问题的排查方法内存问题在 MCU 上特别隐蔽我总结了一套排查流程先看对齐所有大数组是否按 cache line 对齐。再看布局热数据是否在 SRAM冷数据是否在 PSRAM。然后看访问模式是否顺序访问是否有跨 bank 冲突。最后看容量是否超出 SRAM是否触发换页。这套流程帮我定位了大部分内存相关的性能问题。7.3 量化精度问题的定位量化精度问题表现为生成结果不合理定位方法是逐层对比把量化模型和浮点模型的中间激活值对比找出偏差最大的层。调整 scale对偏差大的层重新校准 scale。局部回退实在不行把关键层保留浮点或更高精度。我遇到过一次输出全是重复 token 的问题最后定位到是某一层的 scale 选得太大导致激活值饱和。重新校准后解决。7.4 常见问题速查表现象可能原因排查方向吞吐突然下降内存换页 / bank 冲突检查 SRAM 占用和布局生成结果乱码量化精度不足逐层对比激活值性能波动大cache 未对齐检查数组对齐流水线无效中断延迟高精简中断处理死机 / 卡住缓冲区同步错误检查信号量和标志位实操心得MCU 上的性能问题80% 是内存问题15% 是同步问题5% 才是算法问题。遇到问题先查内存能省很多时间。8. 这个系列后续会展开什么这个总览篇把整个优化路径的骨架搭起来了但每一层优化都有大量细节值得展开。后续我会分篇深入内存篇详细讲 SRAM/PSRAM 的分层策略、对齐技巧、bank 优化。量化篇讲量化方案的选择、scale 校准、精度评估方法。PIE 篇讲 PIE 指令的具体用法、矩阵乘法的向量化改造、常见陷阱。流水线篇讲双缓冲实现、中断优化、同步机制。每一篇我都会给出可复现的代码片段和实测数据不是纸上谈兵。最后分享一个我在这个项目里最深的体会在资源受限的平台上做优化最重要的不是知道多少技巧而是知道什么时候不该用某个技巧。我见过太多人一上来就堆 SIMD、堆流水线结果性能还不如朴素实现。优化的本质是权衡是在算力、带宽、延迟、复杂度之间找平衡点。这个平衡点只能靠实测找到没有捷径。如果你也在做类似的边缘推理项目欢迎交流。踩过的坑我都写在上面了希望能帮你少走点弯路。