1. 项目缘起为什么要在 MCU 上跑大模型把一个大语言模型塞进一块微控制器里这件事放在两三年前说出来大概率会被同行当成玩笑。毕竟主流认知里LLM 推理至少得有一块像样的 GPU或者退一步也得是带几十 GB 内存的服务器 CPU。但嵌入式圈子这几年有个明显趋势芯片的算力和内存带宽在快速上探而模型侧的量化和剪枝技术也在同步成熟两条曲线一交叉就出现了在 MCU 上跑 LLM这个过去看起来不现实的场景。我这次折腾的对象是ESP32-P4。这颗芯片值得单独说两句它是乐鑫在 ESP32 家族里定位偏高性能的一颗核心是RISC-V架构主频能跑到 400MHz片上带了相当可观的 SRAM还支持外挂 PSRAM 做内存扩展。更关键的是它带了一个PIEProcessor Instruction Extension协处理器专门用来加速向量和定点运算——这个东西在后面优化推理速度的时候是绝对的主角。项目标题里那个数字对比很扎眼从 0.61 tok/s 到 4.31 tok/s整整 7 倍。这个系列总览要讲的就是这 7 倍是怎么一点点抠出来的。我先给个结论性的判断这 7 倍不是靠某一个银弹实现的而是把推理链路上每一个环节的浪费都找出来、逐个消掉的结果。从模型量化格式的选择到算子实现到内存布局到 PIE 指令的利用每一块都贡献了一部分。这篇文章适合谁看如果你是对MCU上做 AI 推理感兴趣的嵌入式工程师或者你在做边缘侧的LLM部署、想搞清楚端侧推理的性能瓶颈到底在哪再或者你只是好奇一块几块钱到几十块钱级别的芯片到底能跑出什么水平那这篇复盘应该都能给你一些可以直接抄作业的东西。我会尽量把每个决策背后的为什么讲清楚而不是只丢一堆参数出来。需要提前说明的是这个系列会拆成多篇本篇是总览负责把整体思路、关键节点和踩过的坑先铺开具体的代码级细节会在后续分篇里展开。所以你会看到这里既有宏观的架构决策也有具体的数字和实测记录但不会陷入某一行汇编的细节里。2. 整体方案设计从模型到硬件的全链路拆解2.1 先想清楚瓶颈在哪再动手很多人一上来就想着怎么把模型跑得更快然后开始盲目地换量化格式、调编译选项。我踩过的第一个坑就是这个——在没有 profiling 的情况下瞎优化结果花了两天时间优化了一个只占总耗时 3% 的环节。正确的做法是先建立性能模型。LLM 推理在 MCU 上的耗时粗略可以拆成三块权重读取的内存带宽开销、矩阵乘法的计算开销、以及注意力机制里的额外开销比如 softmax、KV cache 的读写。在 ESP32-P4 这种级别的芯片上绝大多数情况下瓶颈是内存带宽而不是纯算力。原因很简单模型权重动辄几十 MB而片上 SRAM 只有几百 KB 到几 MB大部分权重得从 PSRAM 甚至外部 Flash 里读读取速度直接决定了 token 生成的速度。这个判断非常重要因为它决定了优化方向。如果瓶颈是算力那你要做的是优化算子、用 SIMD如果瓶颈是带宽那你要做的是减少数据搬运、提高缓存命中率、用更紧凑的量化格式。实测下来ESP32-P4 上这两者都有但带宽是主要矛盾。2.2 模型选型为什么是小模型而不是缩小的大模型在 MCU 上跑模型规模必须严格控制。我最终选的是一个参数量在百万级到千万级之间的小模型具体规模会根据量化后的内存占用反推。这里有个经验不要指望把一个 7B 的模型量化到 4bit 就能塞进 MCU即使塞进去了推理速度也会慢到没有实用价值。选型的核心逻辑是内存占用优先。假设你有 8MB 的 PSRAM 可用模型权重加上 KV cache 加上运行时开销实际能留给权重的可能只有 5-6MB。按 4bit 量化算大概能放 1000 万参数左右按 8bit 算就只有 500 万参数。这个约束是硬的绕不过去。提示模型选型阶段一定要先算内存账再算算力账。很多人反过来先看模型效果好不好结果发现根本放不下。2.3 量化格式的取舍Q4 还是 Q8量化格式的选择直接决定了内存占用和推理速度的平衡。我实测对比过几种方案量化格式权重内存占用相对推理速度输出质量适用场景FP32基准 100%基准 1.0x最好不现实仅作对照INT825%约 2.5-3x接近 FP32内存充裕时首选INT412.5%约 4-5x略有下降内存紧张时首选混合精度15-20%约 3-4x较好关键层用 INT8最终我采用的是INT4 为主、关键层保留 INT8的混合方案。为什么不全用 INT4因为实测发现注意力层的 Q/K/V 投影如果用 INT4输出质量下降比较明显而这几层的参数量占比其实不大保留 INT8 对内存影响有限但对质量提升明显。这是一个典型的把好钢用在刀刃上的取舍。2.4 软件栈的整体架构整个推理栈我分成了四层从下到上依次是硬件抽象层封装 PIE 指令、DMA、PSRAM 访问屏蔽底层细节算子层实现矩阵乘法、softmax、LayerNorm 等核心算子针对 PIE 做优化推理引擎层负责 KV cache 管理、token 调度、采样策略应用层提供简单的对话接口方便测试这样分层的好处是优化的时候可以精确定位到某一层不会牵一发而动全身。比如后面做 PIE 优化主要改的是算子层推理引擎层基本不用动。3. 核心优化手段7 倍是怎么抠出来的3.1 第一刀内存布局重排拿到约 1.8 倍最开始跑通的时候是 0.61 tok/s慢得让人怀疑人生。第一个优化点是内存布局。原始实现里权重是按行优先存储的矩阵乘法时按行读取。但 PIE 协处理器做向量运算时更擅长处理连续的内存块。我把权重重新排列成按列分块的布局让每次 PIE 加载的数据都是连续的减少了内存访问的碎片化。这个改动听起来简单但效果立竿见影从 0.61 提到了约 1.1 tok/s。为什么因为原来每次读权重都要跳着读PSRAM 的突发传输优势完全发挥不出来。重排之后连续读取让 PSRAM 的带宽利用率从大概 30% 提到了 60% 以上。注意内存重排要在模型转换阶段做不要放在运行时。运行时做重排会引入额外的拷贝开销得不偿失。3.2 第二刀PIE 指令加速矩阵乘法拿到约 2.2 倍这是整个优化里贡献最大的一块。ESP32-P4 的 PIE 协处理器支持 SIMD 风格的定点运算一次能处理多个数据。我针对 INT4 和 INT8 分别写了专门的矩阵乘法内核。关键点在于数据打包。INT4 的数据是 4bit 一个两个才能凑成一个字节。PIE 做运算时需要先把这些 4bit 数据解包成 8bit 或 16bit 的中间格式再做乘加。这个解包过程如果处理不好会成为新的瓶颈。我的做法是用查表法配合位运算把解包和乘加融合在一起减少中间数据的搬运。实测下来矩阵乘法这一块的耗时从占总时间的 65% 降到了 35% 左右整体速度从 1.1 提到了约 2.4 tok/s。3.3 第三刀KV cache 优化拿到约 1.5 倍KV cache 是 LLM 推理里一个容易被忽视的性能杀手。随着生成的 token 越来越多KV cache 会不断增长每次生成新 token 都要读取整个 cache。在内存带宽本来就紧张的情况下这是个不小的负担。我做了两件事一是把 KV cache 也用 INT8 量化存储直接砍掉一半的读取量二是把 cache 放在片上 SRAM 里而不是 PSRAM因为 SRAM 的访问延迟低得多。当然SRAM 容量有限所以只放最近的一部分更早的用滑动窗口策略丢弃。这一刀下去从 2.4 提到了约 3.6 tok/s。3.4 第四刀算子融合与循环展开拿到约 1.2 倍最后这一刀是精细活。我把一些相邻的算子做了融合比如把 LayerNorm 和后面的矩阵乘法合并减少中间结果的写回。同时对内层循环做了展开让 PIE 的流水线能跑得更满。这部分优化比较琐碎单个改动效果都不大但累积起来从 3.6 提到了最终的 4.31 tok/s。3.5 优化效果汇总优化阶段速度 (tok/s)相对上一阶段提升累计提升初始版本0.61-1.0x内存布局重排1.101.80x1.80xPIE 矩阵乘法2.402.18x3.93xKV cache 优化3.601.50x5.90x算子融合4.311.20x7.07x这张表是整个项目的核心成果。可以看到PIE 优化贡献最大但其他几项加起来也占了将近一半的提升。这也印证了我一开始的判断优化是个系统工程没有单点银弹。4. 实操过程中的关键细节与踩坑记录4.1 环境搭建与工具链选择工具链这块我用的是乐鑫官方的 ESP-IDF版本选的是比较新的稳定版。编译器是 RISC-V 的 GCC 工具链。这里有个小坑不同版本的 GCC 对 PIE 指令的支持程度不一样有些版本生成的代码会莫名其妙地慢。我建议锁定一个验证过的版本不要频繁升级。调试方面我用的是 JTAG 调试配合串口日志。JTAG 能看寄存器和内存串口日志用来打时间戳。两者结合基本能定位到大部分性能问题。4.2 内存分配的坑ESP32-P4 的内存分好几块内部 SRAM、外部 PSRAM、Flash。它们的访问速度差异很大。我一开始没注意把权重全放在 PSRAM 里结果发现 PSRAM 的访问延迟比 SRAM 高一个数量级。后来我做了分级最频繁访问的数据放 SRAM次频繁的放 PSRAM只读的权重放 Flash 并开启缓存。这个分级策略对性能影响很大值得单独花时间调。提示ESP-IDF 提供了内存分配 API可以指定分配到哪块内存。用之前一定要看清楚文档别默认分配。4.3 数值精度的坑量化之后数值精度问题会集中爆发。我遇到的最典型的问题是累加溢出。INT8 乘 INT8 的结果是 INT16但如果累加很多项INT16 也会溢出。解决办法是用 INT32 做累加器虽然多占一点寄存器但能避免溢出导致的输出乱码。另一个坑是量化参数的校准。如果校准数据选得不好量化后的模型输出会明显变差。我的经验是用一批有代表性的输入做校准不要只用一两条。4.4 常见问题速查表问题现象可能原因排查方向解决方法输出乱码累加溢出检查累加器位宽改用 INT32 累加速度远低于预期权重在 PSRAM检查内存分配热点数据移到 SRAM生成到一半卡死KV cache 越界检查 cache 索引加边界检查用滑动窗口输出质量差量化校准不当检查校准数据换更有代表性的校准集编译报错工具链版本不匹配检查 GCC 版本锁定验证过的版本4.5 实测心得跑通之后我做了几轮压力测试连续生成几百个 token观察速度是否稳定。实测发现随着生成长度增加速度会有轻微下降主要是 KV cache 增长导致的。用滑动窗口策略后速度基本能保持稳定。另外温度对性能也有影响。芯片跑久了会发热如果散热不好可能会触发降频。做长时间测试的时候要注意这一点。5. 这个项目还能怎么扩展跑通只是起点。基于现在这套框架我看到几个可以继续深挖的方向。一是多模型切换。现在的实现是单模型硬编码如果做成模型可插拔的架构就能根据任务复杂度动态选择不同规模的模型简单任务用小模型快速响应复杂任务用大模型保证质量。二是更激进的量化。现在用的是 INT4/INT8 混合如果试试 2bit 甚至 1bit 的极端量化配合更好的校准方法也许能在可接受的质量损失下进一步压缩内存。三是算子层面的持续优化。PIE 的能力我可能只用了六七成还有一些指令没充分利用。如果能把手写汇编的水平再提一提矩阵乘法那块还有空间。四是和上层应用结合。现在只是个推理引擎如果能接上语音识别、传感器数据这些输入就能做成一个完整的端侧智能应用。这才是 MCU 跑 LLM 真正的价值所在——不是替代云端大模型而是在离线、低功耗、低成本的场景里提供够用的智能。我个人在实际操作中的体会是端侧 LLM 这个方向现在处于一个很微妙的阶段硬件刚够用软件还不成熟但正因为不成熟才有大量可以优化的空间。这 7 倍的提升里我相信还有不少水分可以挤。如果你也在做类似的事情欢迎一起交流踩坑经验。