1. 项目缘起为什么要在 MCU 上跑大模型把一个大语言模型塞进 MCU这件事放在两年前说出来大概率会被同行当成段子。毕竟主流认知里LLM 推理是 GPU 和服务器的事动辄几十 GB 显存、几百瓦功耗跟一颗主频几百兆、内存以 KB 计的微控制器根本不在一个世界。但嵌入式圈子有个特点越是看起来不可能的事越有人想试试。ESP32-P4 出来之后这个念头第一次有了落地的可能。ESP32-P4 是乐鑫在 ESP32 家族里定位比较特殊的一颗芯片。它没有集成 Wi-Fi 和蓝牙把资源全砸在了算力和外设上双核 RISC-V 处理器主频拉到 400 MHz带 AI 指令扩展和 PIEProcessor Instruction Extension处理器指令扩展加速单元片上 SRAM 有 768 KB还支持外挂 PSRAM。这几个参数单独看都不算炸裂但组合在一起就构成了一个能跑点正经计算的底座。尤其是 PIE 指令集它本质上是给 RISC-V 核心加了一套 SIMD 风格的向量运算能力做点乘、乘加、饱和运算这类神经网络里最常见的操作时能一次处理多个数据效率比纯标量循环高出一大截。我最初的目标很朴素让 ESP32-P4 跑通一个能对话的小模型哪怕慢一点先证明能跑。选型上没太多纠结直接上 llama2.c 这套极简推理框架。原因很简单它的代码量小、依赖少、结构清晰整个推理流程就是矩阵乘法加注意力机制没有花里胡哨的调度和算子融合特别适合拿来在资源受限的平台上做移植和优化。模型方面选的是 TinyStories 系列的小模型参数量在几百万到一千多万之间词表小、层数少是这类实验的经典起点。第一版跑通的时候速度是 0.61 tok/s。什么概念生成一句话要等半分钟基本属于能出字但没法用的状态。但这个数字恰恰是整件事的起点——它证明了在 MCU 上跑 LLM 不是玄学剩下的就是工程问题怎么把这个数字往上抬。后面经过一系列优化最终稳定在 4.31 tok/s差不多 7 倍。这个系列就是把这 7 倍是怎么一点点抠出来的完整复盘一遍。这篇文章是系列总览我会先把整体思路、关键技术点、优化路径和踩过的坑讲清楚后面再分篇展开每个环节的细节。如果你手上正好有 ESP32-P4 或者类似的 RISC-V MCU想折腾本地推理这篇应该能帮你少走不少弯路。如果你只是想了解 MCU 上跑 LLM 到底是怎么回事也能从这里看到一个完整的工程视角。2. 整体方案设计从框架选型到优化路线图2.1 为什么是 llama2.c 而不是别的框架市面上 LLM 推理框架不少llama.cpp、MLC、TensorFlow Lite Micro 各有各的定位。但在 ESP32-P4 这个场景下选择逻辑跟服务器端完全不一样。服务器上你关心的是吞吐、并发、算子覆盖率MCU 上你首先关心的是代码能不能塞进 Flash运行时内存够不够有没有隐藏的动态分配编译出来会不会直接爆掉。llama.cpp 功能全但代码体量大、依赖多移植到 MCU 上光是裁剪就是个无底洞。TensorFlow Lite Micro 有官方 MCU 支持但它的算子库偏通用针对 Transformer 这种结构的优化有限而且引入 TFLM 本身会带来不小的代码体积。相比之下llama2.c 的优势非常突出整个推理核心就一个 C 文件几百行代码没有外部依赖内存布局一目了然。你想优化哪一块直接改就行不用跟框架的抽象层斗智斗勇。提示llama2.c 的极简是有代价的它只支持推理不支持训练算子也没做融合。但对于先跑通再优化这个目标来说简单可控比功能齐全重要得多。2.2 模型选择的取舍模型这块我最终用的是 TinyStories 的 15M 参数版本作为主实验对象同时也试过更小的 1M 和 3M 版本。参数量的选择直接决定了速度上限因为推理时间基本跟参数量成正比。15M 模型在 PC 上跑当然毫无压力但放到 400 MHz 的 MCU 上每生成一个 token 都要把全部权重过一遍这就是为什么第一版只有 0.61 tok/s。这里有个容易被忽略的点模型权重的存储格式。原始权重是 float3215M 参数就是 60 MBESP32-P4 的片上 SRAM 根本放不下必须外挂 PSRAM。但 PSRAM 的访问速度远低于片上 SRAM如果每次矩阵乘法都从 PSRAM 读权重带宽会成为瓶颈。所以量化是绕不开的一步——把权重从 float32 压到 int8体积直接降到四分之一15 MB 左右访问压力小很多而且 int8 乘加可以用 PIE 指令加速。这个决策后面会专门展开。2.3 优化路线图整个优化过程不是拍脑袋试出来的而是沿着找到瓶颈、针对性解决的思路推进的。我把它分成四个阶段每个阶段解决一个主要矛盾阶段主要瓶颈核心手段速度区间基线纯标量浮点运算直接移植无优化0.61 tok/s量化权重体积大、访存慢int8 量化 定点运算约 1.5 tok/s指令加速乘加运算效率低PIE 向量指令重写热点约 3.0 tok/s内存与调度访存与计算重叠差权重预取、缓存优化、循环展开4.31 tok/s这个路线图背后的逻辑很清晰先解决数据太大的问题量化再解决算得太慢的问题指令加速最后解决等数据的问题内存调度。每一步都建立在前一步的基础上顺序不能乱。如果你一上来就去抠指令级优化但权重还是 float32那大部分时间其实耗在访存上指令优化带来的收益会被稀释。3. 核心技术点拆解PIE、量化与内存布局3.1 PIE 指令集到底加速了什么PIE 是 ESP32-P4 上最值得说道的东西。它的全称是 Processor Instruction Extension本质是一组自定义的 RISC-V 扩展指令专门用来加速神经网络里的常见运算。你可以把它理解成给 CPU 装了一个小型的向量协处理器虽然规模比不上真正的 DSP 或 NPU但在 MCU 这个级别已经相当能打。具体来说PIE 提供了几类关键指令向量乘加MAC、向量点积、饱和加减、以及一些数据搬移指令。以点积为例标量实现是两个循环嵌套每次取一个元素相乘再累加N 次乘法就要 N 个时钟周期起步。而 PIE 的向量点积指令可以一次处理多个元素对配合 128 位的向量寄存器理论上能把乘加吞吐提升好几倍。但这里有个坑PIE 指令对数据对齐和类型有要求。它主要面向 int8 和 int16 的定点运算如果你传进去的是 float要么先转换要么根本用不了。这也是为什么量化必须走在指令加速前面——不量化PIE 的大部分能力你根本调不动。注意PIE 的向量寄存器数量有限写热点循环时要注意寄存器压力。我一开始把整个注意力计算塞进一个函数结果编译器频繁 spill性能反而下降。后来拆成小块让数据在寄存器里流转效果才出来。3.2 int8 量化的实操细节量化这件事理论上一句话把 float32 的权重和激活值映射到 int8 的整数域。但实操里细节很多处理不好精度掉得厉害模型直接变哑巴。我用的是对称量化公式很简单q round(x / scale) x_approx q * scale其中 scale 是该张量里绝对值最大的元素除以 127。对称量化的好处是零点固定在 0计算时少一次偏移对 MCU 这种算力紧张的平台很友好。代价是对于分布不对称的张量精度会有损失。实测下来TinyStories 这类小模型的权重分布还算温和对称量化够用。真正麻烦的是激活值的量化。权重可以离线量化好激活值是运行时算出来的每一层的范围都不一样。我的做法是先用一批校准数据跑一遍统计每层激活值的最大绝对值把 scale 固定下来。这样运行时不用动态求 max省了不少开销。校准数据不用多几十条就够因为小模型的激活分布比较稳定。量化之后还要处理反量化的问题。矩阵乘法的结果是 int32 累加值要乘回 scale 才能得到近似的 float 结果。这个 scale 乘法可以合并到后续操作里比如在 softmax 之前统一处理减少乘法次数。3.3 内存布局为什么权重排布能决定速度这一块是我踩坑最多的地方。同样的算法权重在内存里怎么摆速度能差出一倍。最直觉的做法是按行优先存储权重矩阵矩阵乘法时按行读取。但在 MCU 上PSRAM 的突发读取burst read效率远高于随机读取。如果权重按行存每次计算一个输出元素都要跨行取数缓存命中率很低。后来我改成按列分块存储把经常一起访问的权重放在连续地址上配合 PSRAM 的突发模式带宽利用率明显提升。另一个关键点是权重的预取。推理是逐层进行的当前层在算的时候下一层的权重其实可以提前从 PSRAM 搬到片上 SRAM。ESP32-P4 有 DMA 控制器可以后台搬运数据跟 CPU 计算并行。我实现了一个简单的双缓冲机制一块 SRAM 放当前层权重另一块接收 DMA 搬来的下一层权重算完一层就切换。这个改动单独看不大但叠加起来对整体速度贡献不小。内存优化手段解决的问题实测收益权重按列分块随机访问多、缓存命中低约 15%DMA 双缓冲预取计算与访存串行约 20%热点数据常驻 SRAMPSRAM 访问延迟高约 10%4. 实操过程从编译到跑通的完整链路4.1 环境搭建与交叉编译ESP32-P4 的开发环境用的是乐鑫官方的 ESP-IDF版本建议用较新的稳定版因为 PIE 相关的 intrinsics 和编译选项在旧版本里支持不完整。安装流程官方文档写得很清楚这里只说几个容易卡住的点。第一是工具链。ESP32-P4 是 RISC-V 架构交叉编译器是 riscv32-esp-elf-gcc。安装完 IDF 之后记得跑一遍 export 脚本把工具链加进 PATH否则编译时会报找不到编译器。第二是 PIE 支持的开启需要在编译选项里加上对应的架构扩展标志具体是在 CMakeLists 里设置 target 的编译参数。如果没开PIE intrinsics 会编译失败。第三是 PSRAM 的配置。ESP32-P4 支持外挂 PSRAM但默认配置里不一定启用。要在 menuconfig 里打开 PSRAM 支持并设置正确的容量和时序参数。时序配错了PSRAM 读写会不稳定表现为推理结果随机出错这种问题最难查。# 设置目标芯片 idf.py set-target esp32p4 # 打开配置菜单启用 PSRAM 和 PIE idf.py menuconfig # 编译并烧录 idf.py build flash monitor4.2 模型转换与权重打包PC 上训练好的模型不能直接给 MCU 用中间要做格式转换。我的流程是先用 Python 脚本把 PyTorch 的 checkpoint 读出来做量化然后把量化后的权重按 MCU 端期望的内存布局重新排列最后导出成一个二进制文件。这个二进制文件会被烧录到 Flash 的特定分区运行时直接按地址读取。这里有个细节值得说权重的排列顺序必须和 MCU 端的读取逻辑严格对应。我一开始在 Python 端按行导出MCU 端却按列读结果输出全是乱码。调试了半天才发现是布局不匹配。后来我干脆在 Python 端写了个校验函数导出前先模拟一遍 MCU 的读取顺序确认无误再生成文件。模型文件的大小也要注意。15M 参数的 int8 模型大约 15 MB加上词表和元数据接近 16 MB。ESP32-P4 的 Flash 分区要提前规划好给模型留足空间别到时候烧不进去。4.3 推理主循环的实现推理主循环是整个程序的心脏结构上分三步prefill、decode、采样。prefill 阶段把输入的 prompt 一次性喂进去建立 KV cachedecode 阶段逐 token 生成每次只处理一个新 token采样阶段根据 logits 选下一个 token。在 MCU 上prefill 和 decode 的开销差异很大。prefill 要处理整个 prompt计算量大但可以并行decode 每次只处理一个 token计算量小但没法并行而且每步都要读一遍全部权重访存压力大。所以 decode 阶段是优化的重点我大部分的指令级优化都花在这里。KV cache 的管理也是个问题。cache 大小跟序列长度成正比序列越长占内存越多。ESP32-P4 的 SRAM 有限我把 KV cache 放在 PSRAM 里但访问延迟高。折中方案是把最近几层的 KV 放在 SRAM老的在 PSRAM用的时候按需搬。这个策略对短对话场景效果不错。提示调试推理时先关掉采样直接取 argmax这样输出是确定性的方便对比不同优化版本的结果是否一致。采样引入的随机性会让 bug 排查变得很痛苦。5. 常见问题与排查技巧实录5.1 输出乱码或重复先查量化推理跑起来但输出是乱码或者反复重复同一个 token这是最常见的问题。九成以上的情况出在量化环节。排查顺序建议这样先把量化关掉用 float32 跑一遍如果输出正常那问题就在量化。然后逐层检查 scale 的计算重点看有没有某一层的 scale 算成了 0 或者异常大。激活值的校准数据如果覆盖不全某些层的 scale 会偏导致量化误差累积。另一个隐蔽的坑是 int8 溢出。矩阵乘法的累加是 int32但如果中间某步用了 int16 累加很容易溢出。ESP32-P4 的 PIE 指令有些是 int16 累加的用的时候要确认累加范围够不够。我遇到过一层输出全变成极值的情况查了半天是累加溢出。5.2 速度不达预期用 profiler 定位优化之后速度没怎么涨别急着改代码先用 profiler 看时间花在哪。ESP-IDF 自带性能计数器可以统计每个函数的周期数。我一般会重点看三个地方矩阵乘法、softmax、以及权重读取。如果矩阵乘法占比高说明计算是瓶颈往指令优化方向走如果权重读取占比高说明访存是瓶颈往内存布局和预取方向走。有个反直觉的发现softmax 在小模型里占比不低。因为 softmax 涉及 exp 运算而 MCU 上没有硬件 exp 指令全靠软件查表或多项式近似。我后来用了一个分段线性近似精度损失可接受速度提升明显。5.3 常见问题速查表现象可能原因排查方向输出乱码量化 scale 错误关量化对比、逐层查 scale输出重复采样温度过低或 logits 异常检查采样参数、查 logits 范围速度骤降PSRAM 时序配置错误检查 menuconfig 时序参数运行崩溃内存越界或栈溢出查任务栈大小、开内存检查结果不稳定DMA 与计算竞争检查双缓冲同步逻辑5.4 几个独家避坑经验第一别在中断里做重活。我一开始想用 PIE 中断来做计算调度结果发现中断上下文里能用的资源有限而且频繁中断反而拖慢主循环。后来改成主循环轮询加 DMA 回调稳定多了。第二编译优化等级要试。-O2和-O3在 PIE 代码上表现不一样有时候-O3的自动向量化反而会打乱你手写的指令序列。我最终用的是-O2加手动 intrinsics可控性最好。第三留出调试余量。优化到后期每提升一点都要付出很大代价。我的建议是先把功能做扎实速度优化到能用就行别为了最后那 10% 把代码搞得没法维护。4.31 tok/s 这个数字其实是在可维护性和性能之间找的平衡点。6. 系列后续规划与扩展方向这个系列接下来会分几篇展开。第一篇讲量化的完整实现包括校准数据的采集、scale 的计算、以及精度验证的方法。第二篇讲 PIE 指令的实战会给出具体的 intrinsics 用法和热点函数的改写示例。第三篇讲内存优化重点是 DMA 双缓冲和权重布局的细节。最后会有一篇讲怎么把这套东西移植到其他 RISC-V MCU 上因为核心思路是通用的换平台主要改的是指令集相关的部分。扩展方向上我还在试几个东西。一是更激进的量化比如 4 bit理论上能把模型再压一半但精度损失需要仔细评估。二是多核并行ESP32-P4 是双核目前我只用了一个核做推理另一个核基本闲着如果把矩阵乘法按行拆分到两个核理论上还能再快一些但核间同步的开销要算清楚。三是算子融合把矩阵乘法和激活函数合并减少中间结果的读写这个在服务器端是常规操作在 MCU 上同样有价值。我个人在实际操作中的体会是MCU 上跑 LLM 这件事难点不在算法而在工程。算法都是现成的怎么在有限的资源里把它高效地实现出来才是真正考验人的地方。0.61 到 4.31 这 7 倍每一倍背后都是对硬件特性的理解和反复的实测。如果你也在做类似的事希望这个系列能帮你省下一些试错的时间。