1. 为什么要在 MCU 上跑 LLM一个看似不合理的需求第一次跟朋友聊起在 ESP32-P4 上跑大语言模型这件事对方的反应基本都是同一句话你图啥这个反应非常合理。一块主频 400MHz 的 RISC-V 芯片几百 KB 的片上 SRAM外挂 PSRAM 撑死也就 32MB 级别而桌面端随便一个 7B 模型光权重就要 14GB 显存。拿这两者做对比就像用一辆家用小踏板去拉集装箱怎么看都不搭。但真实的需求场景往往不在跑得动大模型这件事本身而在于离线、低功耗、低成本的本地推理能力。我接触到的具体场景大致有这么几类工业设备上的语音指令解析、智能家居面板上的自然语言控制、教育硬件里的对话式交互、以及一些需要在断网环境下做意图识别的边缘节点。这些场景的共同点是——不需要模型无所不知只需要它在一个收窄的领域内把用户的一句话映射成结构化指令或者简短回复。这种任务用 7B 模型是杀鸡用牛刀用几十万到几百万参数的小模型反而更合适。ESP32-P4 这个芯片值得单独说一下。它是乐鑫在 ESP32 系列里第一款真正意义上的高性能 MCU双核 RISC-V主频 400MHz带 FPU带 SIMD 风格的 PIEProcessor Instruction Extensions指令扩展支持外挂大容量 PSRAM。这几个特性叠在一起让它成为目前少数理论上能跑小模型的 MCU 之一。注意我说的是理论上因为从理论到实际跑通中间隔着的就是这篇复盘要讲的全部内容。我最初跑通的版本速度是0.61 tok/s也就是每生成一个 token 要 1.6 秒多。这个速度基本没法用一句话十个字要等十几秒。经过一系列优化之后做到了4.31 tok/s提升了整整 7 倍。这个数字放在 PC 上依然慢得可笑但在 MCU 上它意味着一个 20 token 的短回复可以在 5 秒内出完配合流式输出交互体验已经勉强能接受了。这篇是系列的总览我会把整个优化路径的骨架讲清楚瓶颈到底在哪、每一步优化解决了什么问题、哪些是通用经验、哪些是 ESP32-P4 特有的坑。后面每个环节我都会单独展开成一篇这里先把地图画出来让你知道路该怎么走。提示如果你只是想快速验证能不能跑可以直接跳到第 3 节的环境搭建部分如果你关心的是为什么这么慢、怎么变快第 4 节到第 6 节才是重点。2. 先搞清楚瓶颈0.61 tok/s 到底慢在哪优化这件事最忌讳的就是凭感觉改。我见过太多人一上来就换编译器优化等级、开各种 flag结果速度纹丝不动因为根本没打中瓶颈。所以在动手之前必须先做一次严肃的性能剖析把时间花在哪里搞清楚。2.1 用最朴素的方式定位热点在 MCU 上做 profiling 不像 PC 上那么方便没有 perf没有 VTune。我用的方法很土但很有效在关键函数入口和出口打时间戳用 esp_timer_get_time() 取微秒级时间把耗时累加打印出来。具体做法是在矩阵乘、激活函数、采样这几个大模块外面各包一层计时跑一次完整的生成看总时间怎么分配。第一次测出来的结果让我有点意外。我原本以为瓶颈会在矩阵乘法上毕竟那是计算量大头。但实测数据显示纯计算只占了大约 40% 的时间剩下 60% 花在了内存访问和类型转换上。这个比例在 PC 上几乎不可能出现因为 PC 有巨大的多级缓存和极高的内存带宽而在 MCU 上PSRAM 的访问延迟和带宽是硬约束。具体来说几个大头是这样的环节耗时占比说明权重加载PSRAM 读取约 35%每次矩阵乘都要从 PSRAM 搬权重浮点矩阵乘计算约 30%FP32 软件模拟没有硬件加速量化/反量化转换约 15%权重是 int8计算要转 float激活函数与归一化约 10%含 exp、sqrt 等超越函数采样与输出约 10%相对固定优化空间小这张表基本决定了整个优化路线。权重加载和类型转换加起来占了 50%这意味着减少内存搬运和避免无谓的类型转换比优化计算本身更划算。这个结论直接影响了后面所有的技术选型。2.2 为什么 FP32 是原罪ESP32-P4 虽然有 FPU但它是单精度浮点单元而且没有向量化的浮点乘加指令。也就是说一个 FP32 的矩阵乘编译器只能老老实实生成一条条 fmul fadd没法像桌面 CPU 那样用 FMA 指令一次算两个操作。更糟的是如果你的模型权重是 FP32 存储的那从 PSRAM 读进来的数据量是 int8 的四倍内存带宽压力直接翻两番。我做过一个粗略的估算假设模型有 100 万参数FP32 存储就是 4MBint8 存储是 1MB。PSRAM 的读取带宽在理想情况下大概几十 MB/s 量级那么光是读完一遍权重FP32 就要 100ms 以上int8 只要 25ms 左右。而一次前向传播要读的权重远不止一遍每层都要读累积起来差距就是数量级的。所以量化和 PIE 指令加速是两条必须走的路前者解决搬得少后者解决算得快。这两条路我在后面会分别展开。2.3 一个容易被忽略的坑cache 行为ESP32-P4 访问外部 PSRAM 要经过 cache。cache 命中率对性能影响极大但很多人不知道的是cache line 的大小和访问模式是否连续直接决定了实际带宽。我一开始的权重布局是按每个神经元一行存的结果矩阵乘的时候访问是跳跃的cache 命中率惨不忍睹。后来改成按计算顺序重排权重布局让访问尽量连续速度立刻上了一个台阶。这个经验在 PC 上也有但因为 PC 的 cache 又大又智能影响没那么明显。在 MCU 上cache 小、line 短访问模式的优化收益被放大了好几倍。这是我在整个优化过程中收获最大的一个认知。3. 从零搭起可运行的环境工具链与模型选择在讲优化之前得先把能跑起来这件事说清楚。很多人卡在第一步就放弃了因为 MCU 上的开发环境和 PC 上完全是两回事。3.1 工具链的版本陷阱ESP32-P4 用的是 RISC-V 架构工具链是 riscv32-esp-elf-gcc。这里第一个坑就是版本匹配。乐鑫的 IDF 版本和工具链版本是强绑定的用错版本会出现各种莫名其妙的链接错误或者运行时崩溃。我的建议是直接用官方推荐的 IDF 版本不要图新去追 master 分支MCU 开发里稳定比新特性重要得多。第二个坑是PIE 指令的支持。PIE 是 ESP32-P4 特有的指令扩展用来加速定点运算和部分向量操作。但编译器默认不一定开启 PIE 优化你需要在编译选项里显式打开相关 flag并且确保你的计算代码能被编译器识别成可以用 PIE 加速的形式。这一点非常关键因为 PIE 是后面提速的核心武器之一。第三个坑是PSRAM 的配置。ESP32-P4 支持多种 PSRAM 模式不同的时钟频率和时序配置会直接影响带宽。默认配置往往偏保守需要根据你实际用的 PSRAM 颗粒手动调优。我在这上面花了不少时间因为带宽提升是后面所有优化的基础。3.2 模型怎么选不是越小越好选模型这件事我的经验是不要一味追求小要看参数量和任务复杂度的匹配度。太小比如几万参数的模型表达能力不够回答质量差到没法用太大几百万参数的模型在 MCU 上跑起来慢到没法交互。我最终选的是一个几十万参数级别的、专门为指令解析微调过的小模型。它的特点是词表小这直接决定了 embedding 层和输出层的计算量、层数少、隐藏维度窄。词表大小这个参数特别重要因为输出层的计算量正比于词表大小一个 3 万词表的模型光输出层就能吃掉大量算力。模型格式上我用的是GGUF 风格的量化格式权重以 int8 为主部分敏感层保留更高精度。选择这个格式的原因是它天然支持按块量化反量化逻辑简单适合在 MCU 上实现。如果你用的是别的格式可能需要自己写转换脚本。注意模型转换这一步一定要在 PC 上完成并验证不要指望在 MCU 上做格式转换。MCU 的内存和算力都不足以支撑这种操作。3.3 内存布局把 PSRAM 当成主战场ESP32-P4 的内存分几块片上 SRAM 快但小PSRAM 大但慢。合理的做法是把频繁访问的小数据比如当前层的激活值、临时缓冲区放在 SRAM把大块的、顺序访问的权重放在 PSRAM。我一开始犯的错误是把所有东西都往 PSRAM 塞结果连激活值都要走慢速内存白白浪费了 SRAM 的速度优势。后来重新规划了内存布局把每层的输入输出激活值固定在 SRAM 里权重留在 PSRAM速度有明显改善。还有一个细节是对齐。PSRAM 访问对地址对齐有要求不对齐的访问会触发额外的总线周期。我在权重数组的声明上加了强制对齐属性确保每次读取都是对齐的这个改动虽然小但累积起来也有几个百分点的收益。4. 量化把 FP32 换成 int8 之后发生了什么量化是整个优化里收益最直接的一步但也是最容易做错的一步。做得好速度翻倍质量不掉做得糙速度上去了但模型直接变傻。4.1 量化的本质是用精度换带宽和算力量化的核心思想很简单用低比特整数表示原本的浮点权重和激活值。int8 相比 FP32存储空间省了 4 倍内存带宽压力小了 4 倍而且整数乘加可以用 PIE 指令加速计算速度也能提升。但量化不是免费的。它引入的误差如果控制不好模型输出会明显退化。我见过有人直接把所有权重粗暴地除以一个缩放因子转成 int8结果模型完全不能用。正确的做法是分通道量化也就是每个输出通道或者每个权重块用独立的缩放因子和零点这样能把量化误差控制在可接受范围内。具体到实现我用的是对称量化缩放因子按每个权重块的最大绝对值计算。对称量化的好处是零点固定为 0反量化时只需要一次乘法省掉了减零点的操作在 MCU 上这点开销省下来很可观。4.2 反量化的时机很讲究一个关键的设计决策是什么时候把 int8 反量化成 float 参与计算有两种方案。第一种是先反量化再计算也就是把 int8 权重读进来后立刻转成 float然后做浮点矩阵乘。这种方案实现简单但每次计算都要做转换而且转换后的 float 又要占内存。第二种是整数域计算最后统一反量化也就是权重和激活都保持 int8用整数乘加累加只在最后输出时反量化一次。这种方案计算全程走整数能充分利用 PIE 指令而且中间结果也是整数内存占用小。我两种都试过第二种明显更快但实现难度也更高因为要处理整数累加的溢出问题。累加器的位宽要足够否则中间结果会溢出。我用的累加器是 int32对于几十万参数的模型来说够用。4.3 哪些层不能量化不是所有层都适合量化。我的经验是第一层和最后一层要谨慎。第一层直接接触输入量化误差会被后续层放大最后一层直接决定输出分布量化误差会直接影响采样质量。这两层我保留了 FP16 或者干脆 FP32虽然增加了一点内存和计算开销但换来了输出质量的稳定。中间那些层可以放心大胆地量化到 int8因为它们的作用更多是特征变换对精度的敏感度相对低。这个首尾保精度、中间狠量化的策略是我试了好几版之后总结出来的平衡点。5. PIE 指令把算力真正榨出来的关键如果说量化解决的是搬得少那 PIE 解决的就是算得快。这是 ESP32-P4 相比普通 MCU 最大的差异化优势也是整个优化里技术含量最高的部分。5.1 PIE 到底提供了什么PIE 是 ESP32-P4 上的一组扩展指令主要面向定点运算和向量化操作。它提供了一些类似 SIMD 的能力比如一次处理多个 8 位或 16 位数据的乘加运算。对于量化后的 int8 矩阵乘来说这简直是量身定做的。但 PIE 不是自动生效的。编译器只有在代码模式能被识别成向量化友好的形式时才会生成 PIE 指令。如果你的代码写成一堆标量循环编译器很可能生成的是普通指令PIE 完全用不上。所以要用好 PIE必须主动改写计算内核让它符合 PIE 的使用范式。5.2 手写 PIE 内核的实践我的做法是把矩阵乘的核心循环重写成分块 向量化的形式。具体来说把输出按 4 或 8 个一组分块每次从权重和激活里各取一组数据用 PIE 的乘加指令一次性算完一组。这样既提高了指令级并行度又减少了循环开销。这里有个细节值得说数据在内存里的排列顺序必须和 PIE 的读取模式匹配。PIE 指令通常要求操作数在内存里是连续排列的如果你的权重是按行存的但计算需要按列取那就得先做一次转置或者重排。我选择在模型转换阶段就把权重重排成 PIE 友好的布局避免运行时做额外操作。手写内核的过程比较痛苦因为要反复对照指令手册还要处理边界情况比如维度不是 4 的整数倍时怎么处理。但收益是实打实的光是把矩阵乘换成 PIE 内核速度就提升了将近一倍。5.3 和编译器的配合除了手写内核还要注意编译选项的配合。开启合适的优化等级、允许编译器做自动向量化、指定目标架构支持 PIE这些 flag 都要配对。我踩过的坑是手写内核写好了但编译选项没开 PIE结果编译器把 PIE 指令又优化回了普通指令白忙一场。另外内联汇编和 intrinsics 的选择也值得考虑。内联汇编控制力最强但可读性差、容易出错intrinsics 更安全但可能不如手写汇编极致。我最终用的是 intrinsics 为主、关键路径用内联汇编补充的混合方案兼顾了开发效率和性能。6. 内存访问优化被低估的提速大头前面说过内存访问占了 60% 的时间。量化减少了数据量PIE 加速了计算但如果访问模式本身是低效的再好的量化和指令也救不回来。这一节讲的是怎么把内存访问这件事做到极致。6.1 权重布局重排让访问变连续最有效的改动是重排权重布局。原始的权重矩阵通常是按输出通道 × 输入通道存的但矩阵乘的时候如果按输出通道顺序遍历每次取一行权重访问是连续的如果按输入通道遍历访问就是跳跃的。我一开始没注意这个用的是默认布局结果 cache 命中率很低。后来把权重按计算顺序重排让每次读取都是连续的一段cache 命中率大幅提升。这个改动不需要改算法只是换个存储顺序但效果立竿见影。具体怎么排取决于你的计算内核怎么遍历。原则是让内存访问的地址序列尽量单调递增让每次读取的数据尽量落在同一个 cache line 里。6.2 双缓冲把搬运和计算重叠起来MCU 上内存访问和计算是串行的读数据的时候 CPU 在等算的时候内存总线在闲。双缓冲double buffering就是解决这个问题的经典手段准备两块缓冲区一块用于当前计算另一块同时预取下一批数据。这样计算和搬运就能重叠起来理论上能把内存延迟隐藏掉。在 ESP32-P4 上实现双缓冲要注意 DMA 的使用。如果 PSRAM 访问能走 DMA那 CPU 就可以专心计算数据搬运交给 DMA 后台完成。我用的是 DMA 双缓冲的组合把权重预取和计算流水起来实测能再挤出 15% 到 20% 的性能。6.3 cache 预取与手动管理ESP32-P4 的 cache 行为可以通过一些手段干预。比如手动预取在计算当前块的时候提前把下一块数据用预取指令拉进 cache。这个技巧在访问模式可预测的时候特别有效。还有一个反直觉的经验有时候把数据放在 SRAM 反而更慢。因为 SRAM 容量小如果放不下导致频繁换入换出性能还不如老老实实放 PSRAM 走 cache。所以内存分配不是越快越好而是要看数据的使用模式。频繁访问的小数据放 SRAM大块顺序访问的数据放 PSRAM 走 cache这个分工要清楚。7. 那些让我卡了半天的坑优化路上踩的坑比顺利的时候多得多挑几个有代表性的说说都是血泪教训。7.1 浮点异常导致的静默错误有一次优化完速度是上去了但模型输出开始出现乱码。查了很久才发现是反量化时的缩放因子算错了导致某些权重被放大到超出 float 表示范围产生了 inf 或者 nan。这种错误不会崩溃只会让输出变得莫名其妙特别难查。教训是量化相关的每一步都要做数值校验。反量化后的权重和原始 FP32 权重的误差要在合理范围内超出阈值就要报警。我后来加了一套校验脚本每次转换完模型都跑一遍再也没出过这类问题。7.2 栈溢出MCU 上的经典死法MCU 的栈空间很小默认可能只有几 KB。我在写 PIE 内核的时候局部数组开大了一点直接栈溢出程序跑飞。更坑的是栈溢出不一定立刻崩溃有时候是覆盖了别的变量导致行为诡异。解决办法是把大数组改成静态分配或者放到堆上并且养成检查栈使用量的习惯。ESP32-P4 的 IDF 提供了栈使用量的查询接口跑完关键函数后查一下心里有数。7.3 编译器优化带来的惊喜开高优化等级之后编译器可能会做一些你意想不到的事情比如把某个循环展开、把某个变量提到循环外、甚至重排指令顺序。大部分时候这是好事但偶尔会引入 bug尤其是涉及 volatile 变量或者内存屏障的时候。我的经验是优化等级要逐步往上调每调一级都跑一遍完整测试。不要一次性从 -O0 跳到 -O3出了问题根本不知道是哪一级引入的。另外涉及硬件访问或者多核同步的代码该加 volatile 就加该加屏障就加不要指望编译器懂你的意思。8. 优化效果复盘与后续方向把上面这些手段都用上之后速度从 0.61 tok/s 提到了 4.31 tok/s。拆开看各部分的贡献大致是这样的优化手段累计速度 (tok/s)相对提升基线FP32无优化0.61-int8 量化1.422.3x权重布局重排1.981.4xPIE 内核3.151.6x双缓冲 DMA3.781.2x编译器与细节调优4.311.14x这张表里最值得说的是量化和 PIE 是两大主力但布局重排和双缓冲这些配角加起来也贡献了将近一倍。很多人只盯着量化和指令加速忽略了内存访问优化结果性能卡在半路上不去。后续还能往哪走我目前看到几个方向。一是更激进的量化比如 int4但精度损失需要仔细评估二是算子融合把相邻的层合并计算减少中间结果的读写三是多核并行ESP32-P4 是双核目前我只用了一个核另一个核完全可以拿来并行计算。这几个方向我还在试有结果了再单独写。最后分享一个我自己的体会在 MCU 上做优化最重要的不是掌握多少技巧而是建立先测量、再优化、后验证的纪律。我见过太多人凭直觉改代码改了半天没效果就是因为没搞清楚瓶颈在哪。性能剖析虽然土但它是所有优化的前提。你花在测量上的每一分钟都会在优化阶段省下十倍的时间。