1. 项目缘起为什么要在 MCU 上跑大模型把一个大语言模型塞进一块微控制器里这件事放在两年前多数做嵌入式的朋友第一反应都是图啥。云端 API 调用一次几厘钱手机端跑个 7B 量化模型也不算新鲜为什么非要折腾一块连操作系统都不一定跑得动的芯片我最初也是抱着这个疑问入场的直到真正把 ESP32-P4 这块板子拿到手把一个小参数量的 LLM 从 0.61 tok/s 一点点抠到 4.31 tok/s才慢慢理解这件事的价值所在。先说清楚这个项目到底在做什么。ESP32-P4 是乐鑫推出的一款基于 RISC-V 架构的高性能 MCU双核 400MHz带 AI 指令扩展片上 SRAM 加 PSRAM 可以做到 768KB 加 32MB 的配置。我们要做的事情是在这样一块没有 MMU、没有操作系统级内存管理、算力以百 MOPS 计的芯片上完整跑通一个 Transformer 结构的小型语言模型推理流程并且把推理速度从最初的 0.61 tok/s 优化到 4.31 tok/s整整 7 倍。这个速度听起来依然很慢4.31 tok/s 意味着生成一句话要等好几秒。但关键在于它证明了一件事端侧 LLM 推理不一定非要依赖 NPU 或者 GPU一颗带向量扩展的 RISC-V MCU 也能扛起来。对于做智能家居、工业控制、离线语音交互的朋友来说这意味着一个完全本地化、不联网、低功耗、低成本的推理方案是可行的。你不需要把用户的语音数据传到云端不需要担心网络抖动也不需要为每一次推理付流量费。适合读这个系列的人我大致分三类。第一类是嵌入式工程师手上有 ESP32 系列或者其他 RISC-V MCU想试试能不能跑点重活第二类是做边缘 AI 的开发者一直在找低功耗推理的落地方案第三类是对 LLM 推理底层感兴趣的技术爱好者想搞清楚一个 token 到底是怎么从权重矩阵里挤出来的。不管你是哪一类只要你能看懂 C 语言、知道什么是矩阵乘法、会用 CMake 编译固件这个系列就能带你从零走到能跑。整个系列我会拆成若干篇这一篇是总览先把全局思路、关键技术点、优化路径和踩过的坑讲清楚后面再逐篇展开每个环节的具体实现。我尽量不写那种首先安装、然后配置、最后运行的流水账而是把每个决策背后的为什么讲透让你看完能自己判断哪些手段适用于你的场景。2. 整体方案设计从模型选型到推理框架的取舍2.1 模型选型为什么是 TinyStories 级别的小模型在 MCU 上跑 LLM第一个绕不开的问题就是模型得多小。市面上动辄 7B、13B 的模型光是权重文件就十几个 GB别说 MCU普通手机都吃力。ESP32-P4 的 PSRAM 上限是 32MB扣掉运行时开销留给模型权重的空间大概在 20MB 出头。按 INT8 量化来算一个参数量 20M 左右的模型刚好能塞进去。我最终选的是一个参数量约 15M 的 TinyStories 风格模型层数 8 层隐藏维度 288注意力头数 6词表大小 32000。这个配置不是拍脑袋定的而是反复权衡的结果。层数太少模型表达能力不够生成的内容会前言不搭后语层数太多KV Cache 和中间激活值会撑爆内存。隐藏维度 288 是个比较甜的点既能保证注意力计算有足够的表达空间又不会让单层矩阵乘法的计算量失控。词表大小这里有个坑。32000 的词表意味着 embedding 层就有 32000 乘 288 约 920 万个参数光这一层就占了整个模型参数量的六成。如果换成 8000 词表embedding 层能压到 230 万参数但代价是分词粒度变粗同样的文本 token 数会变多推理步数增加。我实测下来32000 词表在生成质量上的优势明显所以宁可让 embedding 层占大头也要保住词表规模。提示模型选型时不要只看总参数量要拆开看 embedding、注意力、FFN 三部分的占比。embedding 层通常是沉默的大多数优化时容易被忽略。2.2 推理框架为什么自己写而不是用现成的理论上可以用 TensorFlow Lite Micro 或者 ONNX Runtime 的 MCU 版本但实际试下来都不太顺手。TFLite Micro 对 Transformer 的支持比较有限尤其是 KV Cache 这种动态结构它的静态内存规划器处理起来很别扭。ONNX Runtime 的 MCU 版本更偏向 CNN对自回归生成的支持几乎是空白。所以最后我选择自己写一个精简的推理框架只实现 LLM 需要的那几个算子矩阵乘法、LayerNorm、Softmax、GELU、RoPE 位置编码。这样做的好处是完全可控每一块内存怎么分配、每一个循环怎么展开、哪一步用 PIE 指令加速都能自己说了算。坏处是工作量大光是调试矩阵乘法的边界条件就花了我两天。框架的整体结构分三层。最底层是算子层用 C 实现关键路径用 RISC-V 的 PIE 向量指令手写汇编。中间层是内存管理层负责 PSRAM 和 SRAM 的分配、KV Cache 的环形缓冲管理。最上层是调度层负责 token 的输入输出、采样策略、生成循环。三层之间通过明确的接口通信方便单独替换和测试。2.3 量化方案INT8 对称量化与逐通道缩放模型权重从 FP32 压到 INT8是能不能塞进内存的关键。我用的是对称量化公式很简单q round(x / scale)反量化就是x q * scale。scale 的选取有两种逐张量per-tensor和逐通道per-channel。逐张量实现简单但精度损失大逐通道精度好但要在推理时额外读取每个通道的 scale增加访存开销。实测下来对于注意力层的 QKV 投影和输出投影逐通道量化的精度优势很明显困惑度能降 0.3 左右。对于 FFN 层逐张量和逐通道差别不大因为 FFN 的权重分布相对均匀。所以我的策略是注意力层用逐通道FFN 层用逐张量embedding 层保持 FP16 不量化因为它的精度对生成质量影响最大。激活值量化这里要特别小心。LLM 的激活值分布是动态变化的尤其是 Softmax 之后的注意力权重范围可能从 1e-6 到 1 跨好几个数量级。我一开始用固定的激活 scale结果生成的内容全是乱码。后来改成动态量化每个 token 推理时重新计算激活的 min/max精度才回来。代价是每步多一次遍历但换来的是可用的输出这笔账划算。3. 核心优化路径7 倍提速是怎么抠出来的3.1 第一层优化PIE 向量指令替换标量循环最初的 0.61 tok/s 是用纯 C 写的标量矩阵乘法跑出来的。8 层模型每层两次注意力矩阵乘法加两次 FFN 矩阵乘法单 token 的计算量大概在 3000 万次乘加。400MHz 的 CPU 就算一个周期做一次乘加理论极限也就 13 tok/s 左右实际因为访存和循环开销跑到 0.61 不算意外。第一个大动作是用 PIE 指令重写矩阵乘法的内层循环。PIE 是 ESP32-P4 上的 RISC-V 向量扩展支持 128 位宽的向量寄存器一次能处理 16 个 INT8 或者 8 个 INT16。矩阵乘法的内层是取一行乘一列再累加用 PIE 可以一次取 16 个元素做乘加理论上 16 倍加速。实际因为数据搬运和寄存器压力加速比在 6 到 8 倍之间。这里有个关键细节PIE 的向量加载指令对内存对齐有要求。如果权重矩阵的起始地址不是 16 字节对齐加载会触发异常。我一开始没注意模型加载后直接跑飞调试了半天才发现是 PSRAM 分配时没做对齐。后来在内存分配器里强制 16 字节对齐问题解决。这个坑很隐蔽因为不对齐的时候不是每次都崩而是偶发特别难查。注意用 PIE 指令前务必确认所有参与运算的缓冲区都做了 16 字节对齐。建议在分配函数里直接aligned_alloc(16, size)别省这一步。3.2 第二层优化KV Cache 的环形缓冲与内存布局LLM 自回归生成时每生成一个新 token都要和之前所有 token 的 Key、Value 做注意力计算。如果不缓存每步都要重算历史 token 的 K、V计算量随序列长度平方增长。KV Cache 就是把这部分结果存下来用空间换时间。在 MCU 上做 KV Cache难点在于内存布局。8 层模型每层 6 个头每个头 48 维序列长度上限 256INT8 存储算下来 KV Cache 总共约 1.2MB。这个量级 SRAM 放不下必须放 PSRAM。但 PSRAM 的访问延迟比 SRAM 高好几倍如果布局不合理每次注意力计算都要跨层跨头跳着读缓存命中率极低。我的做法是把 KV Cache 按层-头-位置-维度的顺序连续排列每层每个头的 K 和 V 分开存。这样在计算某一层的注意力时只需要顺序读取该层的 K 和 V 区域空间局部性好PSRAM 的突发传输能跑满。另外用环形缓冲管理位置索引序列长度超过上限时覆盖最旧的位置避免动态内存分配。这个改动带来的提速大概在 1.5 倍左右从 1.8 tok/s 提到 2.7 tok/s。看起来不多但它是后续优化的基础因为内存访问模式理顺了后面的计算优化才能发挥效果。3.3 第三层优化算子融合与循环展开到 2.7 tok/s 之后瓶颈从计算转移到了访存。每层推理要读写好几 MB 的中间激活值PSRAM 的带宽成了限制。这时候单靠向量指令已经不够了得从算法层面减少访存。算子融合是主要手段。比如 LayerNorm 后面紧跟 QKV 投影原本是两步先算 LayerNorm 输出写回内存再读出来做投影。融合之后LayerNorm 的结果直接留在寄存器里投影的输入直接从寄存器取省掉一次写和一次读。类似地Softmax 和注意力加权也可以融合GELU 和 FFN 的第二层投影也可以融合。循环展开是另一个手段。矩阵乘法的内层循环展开 4 次减少循环计数和分支预测的开销。配合 PIE 的向量指令一次处理 64 个元素指令流水线填得更满。这部分优化把速度从 2.7 提到了 3.5 tok/s。3.4 第四层优化双核并行与任务划分ESP32-P4 是双核 RISC-V两个核都能跑 400MHz。前面所有优化都只用了单核另一个核在闲着。把推理任务拆到两个核上并行理论上能再快接近一倍。但并行不是简单地把矩阵乘法对半切。LLM 推理有严格的依赖关系层与层之间必须串行。能并行的是层内的计算比如注意力里多个头的计算是独立的FFN 里不同输出维度的计算也是独立的。我的划分策略是核 0 负责前半数的注意力头和前半数 FFN 输出核 1 负责后半数中间用自旋锁同步。实际加速比没有到 2 倍大概在 1.23 倍左右从 3.5 提到 4.31 tok/s。原因是同步开销和 PSRAM 带宽争抢。两个核同时访问 PSRAM带宽被分掉一半计算快的那个核经常要等内存。如果能把部分权重放到 SRAM 里减少 PSRAM 争抢加速比还能再高一些但 SRAM 容量有限只能放最热的那部分。优化阶段手段速度 (tok/s)相对提升基线纯 C 标量0.611.0x第一层PIE 向量指令1.82.95x第二层KV Cache 优化2.74.43x第三层算子融合循环展开3.55.74x第四层双核并行4.317.07x4. 实操环境搭建与关键配置4.1 硬件准备与开发环境硬件上需要一块 ESP32-P4 开发板确认板载 PSRAM 至少 16MB最好 32MB。另外准备一个 USB 转串口模块用于烧录和日志输出一根杜邦线接串口。如果要做性能对比建议再准备一个电流表因为推理时的功耗变化能反映计算负载对调优有帮助。软件开发环境用 ESP-IDF 5.x 版本它对新款芯片的支持最完整。安装步骤这里不展开官方文档写得很清楚。重点是要确认 PIE 指令的支持已经打开在menuconfig里找到Component config - ESP-P4-Specific - Enable PIE acceleration勾上。这个选项默认可能是关的不打开的话向量指令编译不过。工具链用 riscv32-esp-elf-gcc版本要跟 IDF 匹配。我踩过一个坑用了一个稍旧的工具链PIE 的内联汇编语法不认编译报错但错误信息很模糊查了半天才发现是版本问题。建议直接用 IDF 自带的工具链别自己折腾。4.2 模型转换与量化流程模型转换分三步导出、量化、打包。导出是把训练好的 PyTorch 模型转成 ONNX这一步在 PC 上做。量化用自己写的 Python 脚本读 ONNX 的权重按前面说的策略做 INT8 量化同时记录每层的 scale。打包是把量化后的权重和 scale 按推理框架约定的格式写成一个二进制文件烧录到 flash 或者放到文件系统里。量化脚本里有个细节要注意PyTorch 的权重存储是行优先而我的推理框架为了配合 PIE 的加载模式用的是列优先。转换时要转置否则矩阵乘法结果全错。这个错误很隐蔽因为转置后的矩阵维度还是对的只是数值不对生成的内容会变成看似合理但实际无意义的文本特别容易误判为模型本身的问题。提示量化后一定要做数值校验。取几个输入分别用 FP32 和 INT8 跑一遍对比输出的余弦相似度低于 0.99 就说明量化有问题别急着上板子。4.3 内存分配策略与实测数据内存分配是整个项目里最需要精细规划的部分。ESP32-P4 有 768KB 的片上 SRAM 和最多 32MB 的 PSRAM。SRAM 快但小PSRAM 大但慢。分配原则是最热的数据放 SRAM大块权重放 PSRAM。具体分配如下KV Cache 放 PSRAM因为它是顺序访问PSRAM 的突发传输能接受模型权重放 PSRAM但把当前层的权重预取到 SRAM 的缓冲区中间激活值放 SRAM因为读写频繁输入输出缓冲区放 SRAM。这样分配下来SRAM 用了约 600KBPSRAM 用了约 18MB。实测数据方面单 token 推理耗时从最初的 1640ms 降到 232ms。其中矩阵乘法占 60%注意力计算占 25%LayerNorm 和 Softmax 等占 15%。这个分布说明矩阵乘法还是大头后续如果继续优化重点应该放在矩阵乘法的进一步向量化和权重预取上。5. 常见问题与排查实录5.1 生成内容乱码或重复这是最常见的问题原因可能有三个。第一是量化精度不够激活值的动态范围没覆盖住导致 Softmax 输出饱和。排查方法是打印每层激活的 min/max看有没有异常值。第二是位置编码算错RoPE 的旋转角度如果用了错误的基数注意力会完全失效。第三是 KV Cache 的索引越界读到了未初始化的内存。我的排查顺序是先关掉量化用 FP32 跑如果正常说明是量化问题再检查位置编码的实现对照公式逐项核对最后加边界检查在 KV Cache 读写时断言索引范围。这三个步骤能覆盖九成以上的乱码问题。5.2 推理速度远低于预期如果实测速度比预期慢很多先看 PIE 指令有没有真正生效。方法是在反汇编里搜pv开头的指令如果没有说明编译器没生成向量指令可能是menuconfig没开或者代码写法不对。其次看 PSRAM 的访问模式如果矩阵乘法的内层循环是跨行访问缓存命中率会很低改成顺序访问能明显提速。还有一个容易被忽略的点是编译优化等级。默认可能是-O2改成-O3并打开-funroll-loops速度能再提 10% 到 15%。但要注意-O3可能增加代码体积flash 不够的话要权衡。5.3 双核并行时死锁或数据竞争双核并行最容易出的问题是同步没做好。我用的是自旋锁加内存屏障核 0 写完数据后执行__sync_synchronize()核 1 读之前也执行一次保证可见性。如果省掉内存屏障核 1 可能读到旧数据表现为偶发的输出错误特别难复现。另一个坑是任务划分不均。如果核 0 分到的计算量比核 1 多核 1 会提前完成然后空转等锁整体速度受限于慢的那个核。解决办法是动态划分按实际计算量分配而不是简单对半切。我实测下来注意力头按 4 比 2 分比 3 比 3 分更快因为前半数的头计算量略大。问题现象可能原因排查方法解决手段输出乱码量化精度不足对比 FP32 输出改动态量化输出重复位置编码错误核对 RoPE 公式修正基数速度慢PIE 未生效反汇编查 pv 指令开编译选项偶发错误内存屏障缺失加日志复现补同步指令双核无加速任务划分不均测各核耗时动态划分5.4 烧录后无法启动或反复重启这个问题通常跟内存分配有关。如果 PSRAM 初始化失败或者分配了超过实际容量的内存启动时会触发异常重启。排查方法是看串口日志如果有PSRAM not found或者malloc failed就是内存问题。解决手段是减小模型或者降低序列长度上限确保内存需求在硬件能力范围内。还有一个可能是 flash 分区表配置不对。模型权重文件如果放在文件系统分区分区大小要够否则写入时会失败。建议在partitions.csv里给模型文件单独分一个区大小按模型文件实际大小加 20% 余量来定。6. 后续系列的展开计划与个人体会这个总览篇把整体思路和关键节点讲完了后面我会按优化层次逐篇展开。第二篇讲 PIE 向量指令的具体用法和矩阵乘法的汇编实现包括怎么处理边界、怎么对齐内存、怎么用内联汇编写向量循环。第三篇讲 KV Cache 的内存布局和环形缓冲实现重点是怎么在 PSRAM 上做高效顺序访问。第四篇讲算子融合和循环展开的细节会给出融合前后的代码对比和性能数据。第五篇讲双核并行的任务划分和同步机制包括自旋锁的实现和内存屏障的使用。最后可能再加一篇讲怎么把整个流程自动化从模型转换到固件烧录一条命令搞定。我个人在这个项目里最大的体会是MCU 上跑 LLM 这件事瓶颈往往不在算力而在内存。400MHz 的双核 RISC-V 算力其实够用真正卡脖子的是 PSRAM 的带宽和延迟。所有的优化手段本质上都是在减少访存、提高缓存命中率、把数据放在离计算单元更近的地方。理解了这一点再看那些具体的优化技巧就不会觉得是零散的奇技淫巧而是一套有内在逻辑的方法论。另外一点是别怕从慢开始。0.61 tok/s 的时候我也觉得这事没戏但每优化一层速度就往上跳一截那种原来还能这样的反馈感是很强的。如果你手上正好有 ESP32-P4 或者类似的 RISC-V MCU不妨从最小的模型开始先跑通再优化这个过程本身比最终的数字更有价值。