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 维，序列长度上限 256，INT8 存储，算下来 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.61 | 1.0x |
| 第一层 | PIE 向量指令 | 1.8 | 2.95x |
| 第二层 | KV Cache 优化 | 2.7 | 4.43x |
| 第三层 | 算子融合+循环展开 | 3.5 | 5.74x |
| 第四层 | 双核并行 | 4.31 | 7.07x |
4. 实操环境搭建与关键配置
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 用了约 600KB，PSRAM 用了约 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，不妨从最小的模型开始，先跑通，再优化，这个过程本身比最终的数字更有价值。
