企业官网建设流程全解析

如果你问我过去半年在嵌入式方向做过最折腾、也最值得的一件事，我会毫不犹豫地说是把 LLM 跑在 ESP32-P4 上。从最初的 0.61 tok/s——生成一个字要一秒半，肉眼可见地慢——到最后稳定在 4.31 tok/s，整整 7 倍的性能提升。整个过程没有魔法，就是七轮优化、三次重构、无数个深夜实验堆出来的。这篇是系列的总览，先把整张地图铺开：为什么选 P4、软件栈怎么搭、每一步优化解决了什么问题，以及每一步跑下来 tok/s 的变化曲线。后续每一篇会对一个具体环节深挖，方便你照着复现，而不是只看到一串漂亮数字。

1. 项目拆解：在 P4 上跑 LLM，到底难在哪里

1.1 为什么偏偏是 ESP32-P4：选型背后的考量

用户会问，想跑本地大模型，为什么不直接用电脑、手机或者树莓派，非要选一颗 MCU？这个问题的答案，恰恰是这个项目最有意思的地方。

ESP32-P4 是乐鑫在高性能 MCU 方向上的一个新台阶。它不再像 ESP32-S3 那样停留在 240MHz 的 Xtensa 内核，而是直接上了双核 RISC-V 400MHz，并且带了 AI 相关的向量指令扩展。单看算力，它肯定没法跟手机应用处理器比，但它的功耗、体积、实时性和成本，是那类平台给不了的。在我这个场景里，我需要一个能在端侧完成 LLM 推理、不上云、不依赖网络、可以长时间跑电池供电的硬件节点，P4 几乎是目前最现实的选择。

另一个关键因素是外设和引脚。P4 本身不带 Wi-Fi 和蓝牙射频，这意味着它把大部分资源都留给了算力场景：高速 USB、千兆以太网、丰富的 GPIO 和显示接口。对于端侧 AI 设备来说，这种"纯粹"反而是优势。我不需要在 SoC 上为用不到的无线功能付功耗和面积成本。

把 P4 和 S3 放在一起看会更清楚。S3 在 AIoT 市场已经很成熟，但它的终极算力天花板就在那，跑跑几十 MB 的视觉模型还行，真要推 Transformer 这种动辄几百 MB 权重的东西，和 P4 完全不是一个体验。我前期在 S3 上做过一次最小验证，效果惨不忍睹，这也是我换到 P4 的直接原因。

1.2 三座大山：内存、带宽与算力的极限拉扯

在 MCU 上跑 LLM，本质上是在跟三个硬瓶颈较劲。

第一是内存容量。LLM 的权重动辄几百 MB，哪怕经过量化，一个 0.5B 参数的模型也要 300MB 左右。P4 内置的 SRAM 只有几百 KB 级别，根本放不下，模型只能放在外部 PSRAM 里。这就引出了第二个问题：内存带宽。CPU 要从 PSRAM 里读权重，每一步推理都要把几百 MB 数据搬回 SRAM，传输速度和稳定性直接决定了推理速度的下限。

第三是算力。Transformer 的核心运算是矩阵乘法，虽然量化之后可以走整数路径，但每生成一个 token 依然要完成海量乘加操作。没有向量指令，纯靠标量循环一个个算，400MHz 双核也是杯水车薪。

这三个瓶颈不是独立的。算力不够时，瓶颈在 CPU；算力上来后，瓶颈会转移到内存带宽；带宽够了，又可能被缓存命中率和数据结构拖住。整个优化过程就是在三者之间反复找新的瓶颈、解决它、然后继续找下一个。这也是为什么我始终建议把"定位瓶颈"放在"动手优化"之前，否则很容易做了大量工作却看不到 tok/s 变化。

2. 硬件底牌与软件栈：动手之前先把基础打牢

2.1 ESP32-P4 关键规格与 AI 指令扩展

先把我手头这块 P4 开发板的核心规格摆出来，后面所有优化都在这个基础上谈。

特别需要强调 AI 指令扩展这一点。它跟独立的 NPU 不一样，不是黑盒加速器，而是一组可以在通用 CPU 上执行的向量指令。好处是可以灵活控制数据布局，坏处是必须自己写算子，深入到底层去优化。很多现成的模型推理代码在普通 PC 上能跑，但直接丢到 P4 上是完全跑不动的，必须针对这颗内核重新编译、重新调优。

我在 3.3 节会详细展开向量指令重写矩阵乘法的过程，这里只提醒一句：在开始所有优化之前，先确认你的工具链支持这套向量指令，并且开了对应的编译选项。很多人在第一阶段就吃了这个亏，编译出来的二进制根本没用到硬件特性，白白损失了一大截性能。

2.2 推理框架与模型格式：llama.cpp 和 GGUF 这条路线

选型阶段我对比过好几条路，包括 TFLite Micro、TensorRT 的嵌入式变体、以及专门为单片机写的微型推理引擎。最后全部放弃，统一走 llama.cpp 的嵌入式路线，配合 GGUF 模型格式。

GGUF 是目前端侧 LLM 事实上的标准格式。它把模型权重、超参数、tokenizer 词表打包在一个文件里，支持从 Q2 到 Q8 各种量化粒度，还跨平台通用。手机端本地跑 GGUF 的经验已经很成熟，我只需要把同一套格式接到嵌入式端，不需要自己再造一套模型序列化方案。llama.cpp 本身是纯 C/C++ 写的，移植到 RISC-V 平台虽然有工作量，但相比从零写推理引擎，省掉了大量底层稀疏代码。

模型选择上，0.2B 到 0.5B 这个量级是 P4 的甜点区。我在正式测试中使用的是 Qwen2-0.5B 的 Q4_0 量化版，权重约 300 多 MB，可以完整放进 16MB PSRAM。如果你只有 8MB PSRAM，那得更激进的量化或者换更小的模型，1B 模型不是不能跑，但最终速度大概率掉到 2 tok/s 以下，实用性会大打折扣。

2.3 token/s 怎么测才算数：我的测速方法论

tok/s 是衡量 LLM 推理速度最直观的指标，但很多人在测速时口径不清，导致数据完全不可比。

首先要区分 prefill 和 decode。给一段 prompt，模型先要并行处理所有输入 token，这段时间是 prefill；然后逐字生成新 token，每个字都依赖之前所有的上下文，这段时间是 decode。我们通常说的 tok/s 指 decode 阶段的稳态速度，而不是把 prefill 时间平均进去的数字。prefill 首 token 延迟普遍高很多，如果把两者混在一起，根本看不出真实生成能力。

我的标准流程是：固定一段 512 token 的 prompt，先让模型空跑 5 轮预热，让缓存状态稳定下来；然后正式统计生成 50 个 token 的总耗时，除以 50 得到平均 tok/s。每次改动硬件、模型或固件后，我都会记录完整的测试环境，包括固件 commit 号、模型量化位宽、序列长度、CPU 频率、是否开启双核、采样器参数。没有这套记录习惯，后面每次做优化对比都是糊涂账。

3. 七步优化全复盘：0.61 到 4.31 是怎么一步步爬上去的

3.1 第 1 步：Q4_0 量化，第一次吃到内存带宽的红利

拿到能在 P4 上跑通的第一个版本时，性能只有 0.61 tok/s，慢到让人怀疑人生。当时跑的是 FP32 模型权重，生成一个 token 要把所有权重从 PSRAM 搬进 CPU，每一组 4 字节浮点数都实打实占用带宽。

先优化的一定是量化。把模型从 FP32 降到 Q4_0，权重从 4 字节变成 0.5 字节，内存流量直接降到原来的 1/8，这是整个项目里单点收益最大的一次改动。量化后 0.61 直接拉到 1.62 tok/s，翻了 2.65 倍。

有人会疑惑：内存流量降到 1/8，为什么速度没有 8 倍？原因在于 Q4_0 的权重在计算前需要反量化，这部分 CPU 开销抵消了一部分收益。而且在 MCU 上，SRAM 和 PSRAM 之间的传输效率不是线性的，CPU 在等数据时经常空转。即便如此，量化这一步已经明确验证了一件事：当前瓶颈是内存带宽，不是算力。

实操中有两个必须注意的点。一是 GGUF 转换工具链和 llama.cpp 版本必须对齐，量化后的文件里若缺少 tokenizer 映射，后面输出就会翻车。二是量化位宽不能一味求低，Q2 看似能省更多带宽，但在 0.5B 这种小模型上精度损失会明显影响输出质量，Q4_0 是我测试下来性价比最平衡的档位。

3.2 第 2 步：DMA 与 PSRAM 突发传输，把搬运和计算重叠起来

量化之后，瓶颈顺理成章地转移到了 PSRAM 读取效率上。P4 的 PSRAM 接口本身吞吐不低，但如果你仍然用 CPU 一条一条地把权重从总线读进来，效率低得惊人。

这一步的核心改造是 DMA 突发传输。把连续的权重块交给 DMA 搬运，CPU 在等待数据的同时去执行反量化和乘加操作，让搬运和计算重叠起来。听起来不难，实际做的时候要考虑对齐、突发长度、以及 DMA 描述符的维护。我一开始只是简单地把单次读取替换成 DMA，结果性能提升非常有限，原因是我仍然在等 DMA 传完才开始算。

后来我引入了双缓冲的思路：DMA 搬运下一批权重时，CPU 正在算当前这一批；两边交错进行，几乎把 PSRAM 的读等待时间完全隐藏掉了。这一步从 1.62 拉到 2.11 tok/s，提升 1.3 倍，幅度不如量化那么夸张，但让我确信了方向是对的：软件层面的流水线设计在嵌入式端同样有效。

注意：PSRAM 不是 SRAM，访问时序对 DMA 突发长度特别敏感。我在调试时试过 16、32、64、128 字节等不同突发长度，64 字节在这个场景下表现最稳定。这个参数没有通用最优解，必须结合你的实际模型权重布局多跑几轮对比。

3.3 第 3 步：向量指令重写矩阵乘法，真正开始压榨 CPU

到这一步，CPU 的标量计算能力已经成了新的瓶颈。矩阵乘法是 Transformer 中最内层的循环，必须在指令级别重写。

向量化的核心思路，是一次处理多个数据。P4 的向量指令可以一次性对 8 个甚至更多数据做乘加，而不是像标量那样一个一个算。我把量化矩阵乘法的内层循环拆成对 k 维度分组处理，每组同时加载多个权重块，在寄存器里完成反量化和乘加，最后一次性累加。

伪代码层面的思路大概是这样：

// 优化前：标量循环，一个 k 一个 k 地算 for (int m = 0; m < M; m++) { for (int n = 0; n < N; n++) { float acc = 0; for (int k = 0; k < K; k++) { acc += dequant(a[m][k]) * dequant(b[k][n]); } c[m][n] = acc; } } // 优化后：一次处理多个 k，向量累加 for (int m = 0; m < M; m++) { for (int n = 0; n < N; n += 8) { vec8 acc = vec_zero(); for (int k = 0; k < K; k++) { vec8 va = dequant_vec(a[m][k]); vec8 vb = dequant_vec(b[k][n..n+7]); acc = vec_mul_add(acc, va, vb); } vec_store(c[m][n..n+7], acc); } }

上面只是思路示意，真正的代码还要处理数据对齐、量化块的边界、行切分等细节。手动写这部分向量指令是我在这个项目里最磨人的工作，但收益也直接反映在数字上：2.11 到 2.83 tok/s，提升 1.34 倍。这 0.72 的涨幅几乎是纯靠 CPU 算力挖出来的。

有一点必须提醒：不要上来就重写所有算子，先花点时间确认哪个函数在 profiler 里耗时最高，再针对性地动手。我一开始试图把 attention 和 FFN 里头所有循环全部向量化，结果代码复杂度爆炸，运行还更慢。后来改成只优化矩阵乘法的热点，收益立刻出来了。

3.4 第 4 步：双核并行，从 2.83 到 3.62 的关键一跃

P4 有两颗 400MHz 的高性能核心，放着不用是暴殄天物。双核并行是我这个项目里收益第三大的优化，也是踩坑最多的一项。

并行方案我试了两种。第一种是把矩阵乘法的输出行直接切两半，核 A 算上半部分，核 B 算下半部分。听起来很直接，但实现时发现同步开销巨大。两个核每次算完一行都要去抢下一步要算的行号，这个"抢任务"的过程涉及原子操作和锁，频繁竞争反而把并行收益吃掉了。实测从 2.83 掉到 2.4，比单核还慢。

第二种方案是"块调度"：把输出行分成连续的块，每个核一次领取一块，比如 32 行，然后独立算完再领下一块。锁的竞争次数瞬间减少 32 倍，并行效率才真正释放出来。这一步跑到了 3.62 tok/s，提升 1.28 倍。

双核并行的关键教训是：并行粒度不是越细越好，同步开销会在不知不觉中吞噬掉算力红利。宁可让单个核在某些时刻有一点点空闲，也不要频繁陷入锁竞争。

3.5 第 5 步：KV Cache 环形缓冲与上下文对齐优化

前面四步优化的是计算和内存搬运，第 5 步开始处理 LLM 推理特有的数据结构。

每生成一个新 token，都要把之前所有 token 的 key 和 value 重新读取一遍，这部分数据叫 KV Cache。在长对话场景下，KV Cache 会不断增长，如果每次都动态分配内存，会产生大量碎片，而且数据不连续会导致 DMA 无法高效搬运。

我的做法是把 KV Cache 改成环形缓冲区，容量固定，超过窗口就覆盖最老的 token。同时把缓冲区的起始地址做 64 字节对齐，保证 GPU 式的大块拷贝能直接走最优路径。这一步对短 prompt 的速度提升微乎其微，但当序列长度拉到 512 以上时，稳定性明显改善，tok/s 从 3.62 拉到 3.98。

如果你只测短文本的生成速度，很可能看不出这一步的收益。但真实场景里上下文是会不断变长的，提前把 KV Cache 管好，能让模型在长对话下不掉速，这对实际使用比峰值 tok/s 更重要。

3.6 第 6 步：内存布局与双缓冲，让数据流更顺滑

优化到 3.98 tok/s 时，我开始盯着内存管理下手。原先推理过程中频繁调用动态内存分配，每个 tensor 的位置都不固定，缓存命中率表现很差。

我把推理过程中的大块内存改成静态分配，所有权重按 16 字节对齐存放，代码层面去掉了大量 malloc/free 操作。另外在权重读取路径上做了双缓冲流水，让数据搬运和计算重叠得更充分。这一步的数据变化不大，4.16 tok/s，提升约 1.05 倍，但对整体稳定性的帮助很明显。

越到后期，越是这种细节优化。这也是为什么我在系列开头强调"记录每一步改动"：没有记录，你根本无法区分到底哪项改动带来了真正的 tok/s 收益。

3.7 第 7 步：采样与 tokenizer 的毫秒级裁剪

最后 0.15 tok/s 的提升来自输出管线。

LLM 生成一个 token 后，还要对 logits 做温度缩放、top-k 过滤、top-p 过滤，再做 tokenizer 解码，最后把结果输出到串口或屏幕。这些操作在 PC 上毫秒级完成，但在 CPU 只有 400MHz 的环境里，每一步都可能吃掉几十毫秒。

我做三件事：第一，logits 处理不再遍历整个词表，而是只在 top-k 候选的子集上做进一步过滤；第二，把 top-k 和 top-p 合并到一次遍历中完成，避免重复扫描；第三，tokenizer 解码改成查表方式，避免字符串拼接的隐性开销。这三个小改动加起来，把 4.16 拉到 4.31 tok/s。

到了这个阶段，每提升 0.1 都要付出比以前更大的精力。但正是这些毫秒级的抠索，决定了最终 7 倍这个完整数字。而且采样和 tokenizer 是每次生成都要执行的高频路径，放在长对话场景里，这几处裁剪的收益会被放大得很明显。

4. 数据复盘：7 倍提升具体从哪来，峰值之后还能往哪走

4.1 分阶段性能记录与测试环境说明

把七个阶段的实测数据汇总在一张表里，方便后续复盘和对照。

测试环境统一是：Qwen2-0.5B Q4_0、序列长度 512、双核 400MHz 全开、PSRAM 16MB、采样温度 0.8。换成不同模型或量化位宽，绝对数字会变，但每一步优化的相对趋势是有参考价值的。

从数据里能明显看出收益递减的规律。量化是临门一脚，后面的 DMA、向量指令、双核也都还是几倍级别的提升，到 KV Cache 和内存布局阶段就变成百分之几的微调了。这不是越到后面越不重要，而是说明整个系统的瓶颈在逐步被啃掉，每一处细节都开始变得敏感。

4.2 瓶颈再定位：4.31 tok/s 对真实应用意味着什么

必须诚实说，4.31 tok/s 离流畅聊天还差得远。一个 20 字的回答要 5 秒才能生成完，做实时对话很吃力。但端侧 LLM 不是只能用来聊天，这个速度对很多具体任务已经完全够用。

最典型的是结构化输出。比如设备每 10 秒生成一条状态描述："当前温度 24.5 度，湿度 60%，建议开风扇"，这类输出 token 数少、结构固定，4.31 tok/s 完全能追上传感器采集频率。另一个例子是本地意图分类，给一段文字，模型输出一个动作标签，延迟在几百毫秒级别，可以用作智能设备的本地控制入口。

后续继续提升的空间也还有。更激进的量化格式，比如 2bit 量化，能把内存带宽再压缩一半，代价是精度风险；也可以把部分权重做成只读 XIP 映射，省掉进 SRAM 的拷贝；或者针对小模型做结构化剪枝。这些方向我都会在系列后面的文章里逐一尝试和验证。

5. 踩坑记录：这五个坑我踩过了，你直接绕过去

5.1 PSRAM 带宽掉速 30%：从 profiler 数据里揪出元凶

我明明做完了 DMA 优化，某一天跑测试时发现速度莫名其妙掉了 30%，而且不是稳定掉，是时快时慢。

后来用硬件性能计数器抓数据，发现 PSRAM 的读带宽出现了周期性塌陷。罪魁祸首是 PSRAM 的刷新操作和突发读撞在了同一条物理通道上。解决方法是调整 DMA 突发块的大小，让传输避开刷新冲突窗口；同时把权重数据的 bank 分布做了交错，避免所有热点挤在同一个 bank 里。

这个问题的教训是：MCU 上看似不重要的底层时序，会直接反映到应用层的 tok/s 上。遇到性能波动，先怀疑底层硬件行为，再回头调业务逻辑。

5.2 双核并行反而更慢：调度粒度差点毁掉全部收益

双核并行的第一个版本，我是按"行级调度"来实现的：两个核每算完一行就去抢下一行任务。结果性能不升反降，前面已经提到了。这里再说几个排查细节。

当时的锁用的是自旋锁，两个核频繁争抢同一个变量，导致大量 CPU 周期被白白耗掉。我一度以为是锁实现的问题，换成信号量也一样慢。真正突破是改成块调度之后，线程之间几乎不再碰同一个变量，性能一下子飙上去。

如果你做双核优化也遇到不升反降，先别怀疑是编译器问题，再回头看看你的任务分配粒度。很多时候"看起来高效"的方案，放到真实硬件上会被同步开销打回原形。

5.3 量化后中文乱码：tokenizer 对齐问题是隐形杀手

模型量化完之后，英文输出正常，中文却全是乱码。当时我以为是量化精度不够，反复调量化参数，毫无效果。

最后查出来是 GGUF 转换时 tokenizer 映射丢了。llama.cpp 的 tokenizer 依赖 byte-level BPE，转换工具版本不一致时，特殊 token 的 id 会错位，导致中文这种需要多字节编码的字符在解码时全部对不上号。重新用兼容版本转换模型，并手动固定特殊 token id 之后，中文恢复正常。

这个坑提醒所有做嵌入式 LLM 的人：优化不能只盯 tok/s，输出质量同样重要。量化模型跑出乱码，数字再漂亮也是废的。

5.4 掉频与供电：一个被大多数人忽略的外部因素

排查过程中我遇到过一次非常诡异的掉速，同一个固件、同一个模型，昨天 4.3，今天只有 3.2。系统日志里没有任何异常，最终发现是开发板供电不足导致主核降频。

P4 在满负荷跑 LLM 时，峰值电流比官方文档给的参考值高出不少。劣质 USB 线或者供电模块的瞬时响应不够，都会触发芯片的降频保护，tok/s 立刻跳水。确认方法非常简单：测量核心电压在满载时是否稳定。这个外部因素和你的软件优化完全无关，但如果忽略了，你的所有对比数据都会失真。

我在后面所有测试里都固定使用同一根电源线和同一套供电配置，并且每次跑分前先做一次空载预热，确保频率稳定在 400MHz 再开始记录。

5.5 排查工具箱与决策清单

最后把我的排查思路整理成清单，方便你照着做。

• 测速前先确认 CPU 频率稳定，排除供电降频。
• 每次性能对比都记录固件 commit、模型文件 hash、量化位宽、序列长度。
• 用硬件性能计数器观察 cache miss、内存带宽占用和 CPU 占用率，别靠感觉猜瓶颈。
• 一次只改一件事：改了量化就只量化，改了 DMA 就只测 DMA，不要同时叠多个优化再回头排查。
• 如果某一步优化后性能反而下降，第一时间考虑同步开销和锁竞争，而不是急着回滚代码。

6. 系列规划：后续文章会怎么展开

这第 00 篇是总览，后续我会把每一块内容拆成独立文章，每篇都会给到可复现的操作细节和完整代码思路。

01 篇会讲 llama.cpp 的嵌入式交叉编译全流程，包括工具链配置、编译选项、启动参数调优；02 篇会专门做 GGUF 量化模型的选型与基准测试，对比 Q4_0、Q4_K_M、Q8_0 在不同模型上的速度与输出质量；03 篇深入 DMA 与 PSRAM 带宽优化，把对齐、突发长度、bank 交错这些参数全部讲透；04 篇是向量指令重写矩阵乘法的手把手教程，从最内层循环开始一行一行带写；05 篇分析双核并行推理的同步策略设计，对比行调度、块调度、算子级拆分三种方案；06 篇聚焦采样器和 tokenizer 的裁剪实战，尽量把 logits 处理时间压缩到可接受范围；07 篇落地到真实应用场景，我会用结构化输出和本地意图分类两个例子，演示 4.31 tok/s 在实际产品里怎么用。

每篇文章都会保持"先说思路、再贴代码、最后踩坑复盘"的节奏，尽量做到看完就能动手。

我的个人体会是，端侧 LLM 的优化过程和写业务代码完全不同，它更像在解一道约束繁多、每个变量都互相牵连的工程题。可也正是这种"每一步都能量化为 tok/s"的反馈感，让我在整个项目里越做越上瘾。如果看完这篇总览，你也想在 P4 上试一把，我的建议很简单：先把量化跑通，再谈优化；每一步只改一件事，完整记下数据和环境；别指望一次到位，迭代本身就是这个项目的乐趣所在。