企业官网建设流程全解析

1. 项目缘起：为什么要在 MCU 上跑大模型

把一个大语言模型塞进一颗微控制器里，这件事放在三年前说出来，大概率会被同行当成段子。毕竟我们习惯的 LLM 推理场景，要么是数据中心里成排的加速卡，要么是手机 SoC 上那颗专门为矩阵运算优化的 NPU。而 MCU 是什么？是那种主频几百兆、SRAM 按 KB 算、连操作系统都未必跑得起来的小芯片。这两者之间的鸿沟，看起来比太平洋还宽。

但需求是真实存在的。我接触过不少做工业设备、智能家居、车载终端的团队，他们的诉求非常朴素：设备要能离线理解自然语言指令，不能把数据传到云端，不能依赖网络，成本还要压到几十块钱以内。你跟他们说"上一颗带 NPU 的应用处理器"，他们算完 BOM 成本就摇头了。这时候，如果一颗十几块钱的 MCU 就能跑通一个精简版的语言模型，哪怕速度慢一点，很多场景其实是可以接受的——比如语音助手的意图识别、设备故障的自然语言问答、离线命令词理解，这些任务对吞吐的要求并不高，但对"离线"和"低成本"的要求是刚性的。

这就是我盯上ESP32-P4的原因。这颗芯片是乐鑫在 ESP32 家族里定位偏高性能的一颗，双核 RISC-V 架构，主频能跑到 400MHz，片上带了不小的 SRAM，还支持外挂 PSRAM，最关键的是它有一套PIE 指令集扩展（Processor Instruction Extension），专门用来加速 SIMD 和定点运算。这套东西原本是给音频处理、图像处理准备的，但我第一眼看到它的规格时就想：这不就是为量化后的 LLM 推理量身定做的吗？

项目标题里那个"从 0.61 到 4.31 tok/s"的数字，就是我这段时间折腾下来的真实战绩。0.61 tok/s 是什么概念？大概就是你说一句话，它要愣个十几秒才蹦出第一个字，体验约等于没有。而 4.31 tok/s 已经接近"能用"的门槛了——虽然还是慢，但对于短指令理解类的任务，已经可以接受。这中间 7 倍的提升，不是靠换硬件堆出来的，而是靠一层一层抠出来的：内存布局、指令调度、量化策略、算子融合，每一步都有讲究。

这个系列我打算完整复盘一遍，从环境搭建到最终优化，把踩过的坑、试过的方案、放弃的思路都摊开讲。适合谁看？如果你是对边缘 AI 感兴趣的嵌入式工程师，或者想搞清楚 LLM 推理底层到底在算什么，再或者你手里正好有一块 ESP32-P4 想折腾点不一样的东西，那这个系列应该对你有用。我不假设你懂 LLM 推理框架，但假设你会写 C、会用基本的嵌入式工具链。

2. 硬件与软件底座：ESP32-P4 到底给了我们什么

2.1 芯片规格拆解：哪些参数决定了推理上限

先把 ESP32-P4 的关键规格摆出来，因为后面所有的优化决策，本质上都是在这些约束下做取舍。

这里我要重点说三个参数，因为它们直接决定了你能跑多大的模型、跑多快。

第一个是PIE 指令集。这是整个项目能成立的前提。普通的 RISC-V 核做矩阵乘法，只能一个数一个数地乘加，效率极低。PIE 提供了 128 位宽的 SIMD 操作，一条指令能同时处理多个 8 位或 16 位整数。LLM 推理里 90% 的计算量都在矩阵乘法上，PIE 相当于把这块的吞吐直接拉高了一个数量级。你可以把它理解成：别人用勺子舀水，你换了个大瓢。

第二个是内存层级。这是最容易被忽视、但实际影响最大的部分。ESP32-P4 的片上 SRAM 只有几百 KB，而一个哪怕量化到 4bit 的小模型，权重也有几十 MB。这意味着权重必须放在 PSRAM 里，而 PSRAM 的访问延迟比 SRAM 高一个数量级。推理过程中，CPU 要不停地从 PSRAM 搬数据到 SRAM 再计算，这个搬运过程如果没优化好，CPU 大部分时间都在等内存，算力根本发挥不出来。我后面会专门讲怎么用缓存和预取来缓解这个问题。

第三个是双核。理论上你可以一个核做计算、一个核做数据搬运，形成流水线。但实际操作中，双核同步的开销、缓存一致性的问题，会让这件事变得比想象中复杂。我在早期尝试过双核方案，收益并不明显，后面会详细说为什么。

2.2 软件工具链：从裸机到推理框架的选择

硬件定了，接下来是软件栈。这里有个关键决策：要不要上操作系统？

我的选择是FreeRTOS，而不是裸机。理由很实际：推理过程需要管理多个任务（数据加载、计算、输出），还需要动态内存分配和任务调度，裸机写起来会很痛苦。FreeRTOS 在 ESP32 生态里支持成熟，开销也可控。

工具链方面，用的是乐鑫官方的ESP-IDF，版本选的是较新的稳定版。这里有个坑要提醒：不同版本的 ESP-IDF 对 PIE 指令的内联汇编支持程度不一样，我建议直接用官方推荐的最新稳定版，别图省事用旧版本，否则你会遇到一些莫名其妙的编译错误。

推理框架这块，我没有直接用现成的（比如 TFLite Micro 或 ONNX Runtime），而是自己写了一个精简的推理引擎。原因有两个：一是现成框架对 PIE 的利用不充分，二是它们的内存管理策略对 MCU 来说太重了。自己写虽然工作量大，但每一行代码都在掌控之中，优化起来有的放矢。当然，如果你是新手，我建议先用现成框架跑通流程，再考虑自己写。

模型格式上，我用的是GGUF的量化思路，但做了裁剪。GGUF 本身是为 llama.cpp 生态设计的，格式比较通用，但解析起来对 MCU 来说还是偏重。我提取了它的量化权重布局方式，自己定义了一个更紧凑的二进制格式，只保留推理必需的部分。

3. 模型选型与量化：在 32MB 里塞下一个能用的模型

3.1 模型规模的天花板计算

先算一笔账，这决定了你能跑多大的模型。

ESP32-P4 外挂 PSRAM 最大 32MB，但实际可用的大概在 20-28MB 之间（要留一部分给运行时和缓冲区）。假设我们用 4bit 量化，每个权重占 0.5 字节，那么理论上能放的参数量是：

可用内存 24MB / 0.5 字节 ≈ 48M 参数

听起来不少？但别忘了，除了权重，你还要放激活值、KV Cache、中间缓冲区。实际能放权重的空间可能只有 15-18MB，对应参数量大概 30-36M。这个规模，大概相当于一个"迷你版"的 Transformer，层数不能太多，隐藏维度也不能太大。

我最终选的模型配置是：隐藏维度 512，层数 8，注意力头数 8，词表大小 8000 左右。这个配置下，4bit 量化的权重占用大约 12MB，留出了足够的内存给运行时。这个规模跑不出什么惊艳的效果，但做意图识别、简单问答是够用的。

提示：别一上来就想着跑 7B 模型，那是不可能的。MCU 上的 LLM 是"够用就好"，不是"越大越好"。先想清楚你的任务需要多强的语言理解能力，再倒推模型规模。

3.2 量化策略：为什么是 4bit 而不是 8bit

量化位宽的选择，本质上是精度和内存的权衡。

8bit 量化精度损失小，但内存占用是 4bit 的两倍。在 32MB 的约束下，8bit 只能跑一个非常小的模型，语言能力会差到没法用。4bit 量化虽然精度有损失，但通过合理的量化方案（比如分组量化、保留关键层的精度），实际效果可以接受。

我用的量化方案是分组量化（Group-wise Quantization），每组 32 个权重共享一个缩放因子。这样做的原因是：LLM 的权重分布在不同通道间差异很大，如果整层共享一个缩放因子，小权重的精度会被大权重"吃掉"。分组之后，每组独立缩放，精度损失明显减小。

具体实现上，每个权重存成 4bit 整数，每 32 个权重配一个 16bit 的缩放因子（用半精度浮点或定点表示）。这样平均每个权重的存储开销是：

4bit + 16bit/32 = 4bit + 0.5bit = 4.5bit

比纯 4bit 多了 12.5% 的开销，但精度提升是值得的。

反量化的时候，把 4bit 整数乘上缩放因子，还原成浮点或定点数参与计算。这里有个优化点：反量化和矩阵乘法可以融合，不需要先把整个权重矩阵反量化到内存里再算，而是边算边反量化。这样能省下大量内存带宽，对 MCU 来说至关重要。

3.3 词表和分词器的精简

词表大小直接影响嵌入层的参数量和输出层的计算量。原始模型的词表动辄几万，对 MCU 来说太奢侈了。

我的做法是：针对特定任务裁剪词表。比如你的应用只涉及设备控制指令，那词表里根本不需要那些生僻的学术词汇。我把词表从几万裁到了 8000，嵌入层参数量直接降了一个数量级。

分词器也要相应精简。标准的 BPE 分词器实现起来比较重，我简化成了一个基于前缀树的贪心分词器，牺牲了一点分词质量，换来了更小的代码体积和更快的分词速度。对于短指令场景，这个取舍是划算的。

4. 推理引擎的核心实现：从访存到算子

4.1 内存布局：决定性能的隐形战场

前面说过，MCU 上跑 LLM 最大的瓶颈不是算力，是访存。所以内存布局的设计，比算子本身还重要。

我的核心思路是分块（Tiling）+ 预取（Prefetch）。具体来说，把大的矩阵乘法拆成小块，每次只把当前需要的一小块权重从 PSRAM 搬到 SRAM，算完再搬下一块。同时，在计算当前块的时候，用 DMA 异步预取下一块，让数据搬运和计算重叠起来。

这里的关键参数是块的大小。块太小，搬运次数多，DMA 启动开销占比高；块太大，SRAM 放不下，或者挤占了其他缓冲区。我实测下来，块大小设在 4KB 到 8KB 之间比较合适，具体要看 SRAM 的剩余空间和 DMA 的吞吐。

还有一个细节：权重的排列顺序。如果按行优先存储，每次取一块可能跨越很多行，访存不连续。我改成了按计算顺序重排权重，让每次搬运的数据在物理上是连续的，DMA 效率能提升不少。这个重排是在模型转换阶段离线做的，不占运行时开销。

4.2 PIE 指令的实战用法

PIE 是这套方案里最"硬核"的部分，也是提速的关键。我举一个矩阵乘法的例子来说明。

假设我们要算一个 4bit 权重和 8bit 激活的内积。传统做法是：反量化权重到 16bit，然后逐个乘加。用 PIE 的话，可以这样：

// 伪代码示意，实际用内联汇编 // 一次加载 16 个 4bit 权重（打包成 64bit） uint64_t w_packed = load_weight_packed(ptr); // 用 PIE 指令解包并扩展到 8bit pie_unpack_4to8(w_packed, &w_vec); // 一次加载 16 个 8bit 激活 pie_load_8bit(act_ptr, &a_vec); // 用 PIE 的乘加指令，一次算 16 个 pie_mac_8bit(w_vec, a_vec, &acc);

一条 PIE 指令处理 16 个元素，相比标量代码，理论上有 16 倍的吞吐提升。当然实际达不到这么多，因为还有解包、加载、累加的开销，但 5-8 倍的提升是有的。

这里有个坑：PIE 指令对数据对齐有要求。如果数据没对齐，要么性能暴跌，要么直接触发异常。我在早期就因为这个调试了很久，后来在内存分配阶段就强制 16 字节对齐，问题才解决。

另一个经验是：别指望编译器自动向量化。RISC-V 的自动向量化能力还比较弱，关键的热点函数必须手写内联汇编。我一开始偷懒，想让编译器自己优化，结果生成的代码惨不忍睹，手动改写后性能直接翻倍。

4.3 算子融合：减少内存往返

LLM 推理的算子链条很长：嵌入、多层 Transformer（每层有注意力、前馈网络、归一化）、输出投影。如果每个算子都独立执行，中间结果要反复写回内存再读出来，内存带宽会被吃光。

算子融合就是把这些相邻的算子合并成一个，中间结果留在寄存器或 SRAM 里，不落内存。最典型的融合是：

• QKV 投影融合：把查询、键、值的三个投影矩阵合并成一个大矩阵乘法，一次算完。
• 注意力 + Softmax 融合：注意力分数算出来后直接做 Softmax，不写回内存。
• 前馈网络的两层融合：第一层的输出直接喂给第二层，中间不落内存。

融合之后，内存访问次数能减少 30%-50%，这对访存受限的 MCU 来说，提升非常明显。

不过融合也有代价：代码复杂度上升，调试难度加大。我的建议是先跑通不融合的版本，确认数值正确，再逐步融合，每融合一步就验证一次输出，别一次性全改了，否则出了问题你都不知道是哪一步的锅。

5. 优化历程复盘：7 倍提升是怎么来的

5.1 基线版本：0.61 tok/s 的"能用但难受"

最初的版本，我用的是一套"教科书式"的实现：权重放 PSRAM，每次计算时按需读取，用标量代码做矩阵乘法，没有算子融合，没有预取。

跑出来的结果是0.61 tok/s。这个速度下，生成 20 个 token 要 30 多秒，基本没法交互。但它的价值在于：它是对的。输出结果和 PC 上的参考实现一致，说明整个推理流程没问题。有了这个正确的基线，后面的优化才有意义。

我强烈建议你也这么做：先求对，再求快。很多新手一上来就想着优化，结果数值对不上，连问题出在哪都不知道。

5.2 第一轮优化：PIE 指令 + 内存对齐，提升到 1.8 tok/s

第一刀砍在矩阵乘法上。我把热点函数用 PIE 内联汇编重写，同时强制所有缓冲区 16 字节对齐。

这一轮提升最明显，直接从 0.61 干到了1.8 tok/s，接近 3 倍。原因很简单：矩阵乘法占了总计算量的 90% 以上，把它加速了，整体自然快。

这里的心得是：优化要抓主要矛盾。别去优化那些占比 1% 的算子，先把 90% 的部分搞定。用性能分析工具（我是用 GPIO 翻转 + 逻辑分析仪测的时间）找出热点，集中火力。

5.3 第二轮优化：分块 + DMA 预取，提升到 2.9 tok/s

PIE 优化后，瓶颈从计算转移到了访存。CPU 经常在等 PSRAM 的数据。

我引入了分块和 DMA 预取：把矩阵乘法分块，用 DMA 异步搬运数据，让搬运和计算重叠。同时重排了权重布局，让 DMA 搬运更连续。

这一轮提升到2.9 tok/s。提升幅度没有第一轮大，但这一步的意义在于：它把瓶颈从访存又推回到了计算，为后续优化打开了空间。

注意：DMA 预取的块大小需要仔细调。我试过 2KB、4KB、8KB、16KB，最后发现 4KB 到 8KB 之间最优。太小了 DMA 启动开销大，太大了 SRAM 不够用，还会挤占缓存。

5.4 第三轮优化：算子融合 + 缓存调优，提升到 4.31 tok/s

最后一轮是组合拳：算子融合减少内存往返，同时调整缓存策略，把最常访问的权重块固定在 SRAM 里，减少 PSRAM 访问。

这一轮提升到4.31 tok/s，终于到了"能用"的水平。

这里有个细节值得说：缓存策略的调整需要根据模型的实际访问模式来定。我用了一个简单的统计工具，记录推理过程中哪些权重块被访问得最频繁，然后把这些块优先放进 SRAM。这个"热点权重驻留"的策略，比无差别的缓存替换策略效果好不少。

6. 常见问题与排查实录

6.1 数值不对：从哪查起

这是最常见也最头疼的问题。我的排查顺序是：

1. 先验证单算子。把矩阵乘法、Softmax、LayerNorm 单独拿出来，用固定输入对比 PC 上的参考实现。哪个算子对不上，问题就在哪。
2. 检查量化反量化。4bit 量化的反量化很容易出错，特别是分组缩放因子的索引计算。我踩过一次坑：缩放因子的索引算错了一位，导致每隔 32 个权重就有一组数值偏差，输出结果看起来"差不多但就是不对"。
3. 检查数据类型溢出。MCU 上常用 int8 或 int16 累加，如果累加器位宽不够，会溢出。我建议累加用 int32，虽然占寄存器，但安全。

6.2 性能不达预期：瓶颈在哪

如果优化后速度还是上不去，按这个顺序排查：

我遇到过一个典型问题：DMA 配置成了同步模式，看起来用了 DMA，实际上 CPU 还是在等。后来改成真正的异步模式，性能才上来。别假设 DMA 就是异步的，一定要确认配置。

6.3 内存不够：怎么省

内存不够是常态。省内存的手段按性价比排序：

1. 降低量化位宽：4bit 降到 3bit 甚至 2bit，但精度损失要评估。
2. 裁剪词表：针对任务裁剪，效果立竿见影。
3. 减少层数或隐藏维度：直接改模型结构，但语言能力会下降。
4. 复用缓冲区：不同算子的临时缓冲区可以复用，前提是生命周期不重叠。
5. KV Cache 量化：注意力机制的 KV Cache 也可以量化，省不少内存。

6.4 独家避坑清单

• 别用浮点。ESP32-P4 没有硬件浮点单元（或者很弱），浮点运算全靠软件模拟，慢得离谱。全程用定点或整数。
• 对齐、对齐、对齐。重要的事情说三遍。PIE 和 DMA 都对对齐敏感，不对齐性能暴跌。
• 先测再优化。别凭感觉猜瓶颈，一定要实测。我猜错过好几次，白费了不少功夫。
• 保留一个"慢但正确"的版本。优化过程中随时可以回退对比，这是救命稻草。
• 注意温度。长时间满负荷跑，芯片会发热，主频可能会降。做性能测试时要考虑这个因素。

7. 这个系列接下来讲什么

这篇是总览，把整个项目的来龙去脉、核心思路和关键数字都交代了。接下来我打算分几篇深入展开：

第一篇讲环境搭建和工具链配置，包括 ESP-IDF 的安装、PIE 内联汇编的写法、调试手段。第二篇讲模型转换和量化，从原始模型到 MCU 可用的二进制格式，每一步都有代码。第三篇讲推理引擎的实现，重点是内存布局、DMA 预取和算子融合的具体代码。第四篇讲性能优化实战，把 7 倍提升的每一步都拆开，附上性能数据和踩坑记录。

我个人在实际操作中的体会是：MCU 上跑 LLM，难点不在"能不能跑"，而在"跑得够不够快"。而速度的提升，从来不是靠某一个"银弹"，而是靠一层一层地抠细节。每一次优化可能只提升 20%、30%，但累积起来就是数量级的差距。这个过程很磨人，但当你看到那个 tok/s 的数字一点点往上爬的时候，那种成就感是实打实的。

如果你也在折腾类似的东西，欢迎交流。这个领域现在还很早期，很多方案都没有标准答案，大家一起摸索。