从0.61到4.31 tok/s：ESP32-P4跑LLM推理全链路优化复盘

在嵌入式设备上跑大语言模型这件事，过去两年我是又爱又恨。爱的是开源社区把LLM的门槛一路打穿，哪怕是几块钱成本的MCU也有机会碰一碰“智能化”；恨的是真上手之后，每个环节都能卡你几天——不是缺一个函数，就是慢到让你怀疑人生。这篇就是我这个系列的“00号总览”，聊的是最近在ESP32-P4上把LLM推理速度从0.61 tok/s一路干到4.31 tok/s的全过程，纯手工复盘，没有跑火车。

很多人一听到“ESP32上跑LLM”第一反应是噱头，毕竟传统ESP32只有几百KB内存，跑个TinyML都吃力。但P4这颗芯片不太一样，它最狠的两点是双核400MHz的RISC-V内核和可扩展的PSRAM，带宽和容量都比上一代宽裕得多。我在这颗芯片上跑通了基于llama.cpp二次开发的推理链路，加载的是GGUF格式的小参数模型。0.61 tok/s意味着什么？模型输出一个汉字（大概等于生成2个token的时间）要花3秒以上，别说对话，连读提示词都嫌它磨叽。但优化到4.31 tok/s之后，输出一句完整回答已经具备了“可等待”的体验，配合语音播报或者LCD显示，做离线小助手是够用的。

这篇文章会先把为什么我选了P4这颗芯片讲清楚，接着把从0.61到4.31这条优化链路按阶段拆开复盘，每步收益多少、代价是什么、踩过哪些坑，全摆到台面上。系列后续会按专题逐个深入，我尽量保证每个阶段都能独立阅读，你可以直接跳到感兴趣的部分抄作业。如果你正在嵌入式平台上折腾LLM，或者打算评估MCU级别设备的端侧推理能力，这个系列应该能省你不少弯路。

1. 为什么非要在ESP32-P4上跑LLM

先聊选择硬件这件事。市面上能做端侧推理的设备不少，树莓派、Jetson Nano、各种带NPU的开发板都跑得比MCU快得多，但价格和功耗摆在那里。我评估这个项目时给自己立的规矩是：整板成本压到100元以内，待机功耗要能在电池下撑住，且必须是一个常规的单片机开发流程，这直接把Linux小板排除掉了。

1.1 这颗芯片凭什么能扛住LLM

ESP32-P4是乐鑫目前定位最高的MCU之一，双核RISC-V跑到400MHz，带FPU和矢量扩展指令，最关键的是支持多通道PSRAM，容量可以做到16MB甚至32MB。对比上一代ESP32-S3，P4的整数性能和内存带宽都上了一个台阶，对于1B级别、2B级别的量化模型，算力勉强够用，内存也刚好塞得下。

我实测下来，P4跑LLM的瓶颈其实不是CPU算力本身，而是两条链路：一是PSRAM的读写带宽，二是权重数据在读取时的访存效率。这两点后面会反复提到，它们就是优化空间最大的两张牌。

1.2 0.61 tok/s到底意味着什么

很多没在嵌入式上跑过LLM的人对tok/s没有直觉。正常人阅读速度大约每秒4到6个汉字，1个汉字大约对应1.5到2个token，也就是说你需要至少3 tok/s以上，输出才能“跟得上人眼”。0.61 tok/s是什么体验？你问它一句“今天天气如何”，它要吭哧吭哧十几秒才能蹦出半句话，中间还偶尔卡顿。用来做技术验证可以，放在任何交互产品里都是不合格的。

所以说4.31 tok/s虽然跟GPU动辄几千tok/s没法比，但在MCU这个功耗和成本区间里，它已经把“不可用”变成了“勉强可用”，这中间的7倍差距，值得好好拆解。

1.3 这个系列后面会讲什么

作为总览篇，我有义务把地图画清楚。系列计划按下面几个专题展开：

• 01：ESP32-P4开发环境搭建与llama.cpp移植踩坑记录
• 02：GGUF模型选型与量化参数对比（Q4_0 / Q4_K_M / Q8_0）
• 03：PSRAM带宽优化与数据布局调整
• 04：RISC-V矢量指令在矩阵乘法中的应用
• 05：双核并行推理与任务管线
• 06：采样器、上下文管理与稳定性优化

每一篇都会给出完整的实测数据和可复现代码，这样你可以只挑自己关心的部分精读。

2. 搭出第一个能跑通的“龟速”版本

本来想直接写优化，但复盘还是要从头讲。这个项目的第一步不是优化，而是先让模型能完整地跑完一轮推理，哪怕速度再慢，也是一个可调试的基线。我花了大约两周时间，才跑出最原始版本的0.61 tok/s。

2.1 llama.cpp移植到ESP-IDF的工程要点

llama.cpp本身的算子在桌面平台上优化得不错，但它默认假设你有大内存、大文件系统和相对充裕的CPU资源。移植到ESP32-P4需要自己处理的事情包括：把内存分配从标准malloc改成PSRAM优先的堆管理、把模型文件加载从std::ifstream改成从SD卡或Flash分区读取、以及裁剪所有用不到的依赖项。

我当时的工程结构大概是：

components/ llama-cpp/ src/ggml.c # 核心张量库 src/llama.cpp # 推理逻辑 src/ggml-alloc.c # 图内存分配 src/ggml-quants.c # 量化权重反量化 ports/ p4_platform.cpp # P4适配层：内存、文件、时间函数 p4_ops.cpp # 自定义算子（后续优化在这里展开）

这里的适配层是整个移植最脏最累的活，建议任何一个想复现的人先花时间把内存分配器和文件I/O的抽象做好，不然后优化的时候还要回来返工。

2.2 实测最简模型的性能基线

拿到稳定复现的起点后，我记录了最原始的性能指标。这里需要强调，以下数据不是理论值，是我在恒温环境下用同一段输入prompt反复测了10次的结果：

第一次跑通的时候我挺兴奋，毕竟LLM真的在一个单片机里输出了文字。但兴奋过后冷静下来，0.61这个数字意味着我如果让它自我介绍一段100字的文本，需要将近5分钟，这个项目如果不优化，就只是个“能跑的Demo”。

2.3 跑通过程中最想砸键盘的三个问题

移植过程有些坑，提前讲出来能帮你少走弯路。第一个是PSRAM初始化时序问题，P4的Octal PSRAM如果初始化参数不对，系统表现不是报错而是随机崩溃，因为某些地址读写不稳定。第二个是SD卡读取太慢，一个几MB的GGUF文件全部读进内存要等好几秒，加载阶段的体验非常差。第三个是堆内存碎片化，llama.cpp在采样阶段频繁做小对象分配，导致运行几分钟后出现莫名奇妙的空指针。

这三个问题的最终解法会在后续专题里分别展开，这里只提醒一句：不要在“先跑通”阶段就过早优化，否则你根本不知道基线在哪里。

3. 从0.61到4.31的完整优化链条

这章是核心。我要把从0.61到4.31的每一步改动按时间顺序复盘，每一段都给收益、风险和取舍。我不是理论派，所以每一步都有硬件实测数据支撑。整体优化思路可以总结成一句话：先让CPU算得更快，再让数据喂得更快，最后把多余开销干掉。

3.1 用int4量化把计算量先压下来

最开始的基线路模型是Q8_0，虽然精度好，但参数量化后的体积和计算量都偏高。对于0.5B级别的小模型，我第一刀就切到了int4量化。这里说明一下，GGUF格式的Q4_0和Q4_K_M在不同模型上的效果有差异，对小模型来说，Q4_K_M的精度损失通常比Q4_0小，但计算量略大。

我实测用同一个prompt对比：

这一步速度只提升了约28%，远不够用，但它为后续算子优化提供了更小的内存带宽压力。量化不是省内存那么简单，它同时减少了每次权重搬运的字节数，直接缓解了PSRAM带宽瓶颈。

3.2 重写矩阵乘法的内层循环：把PSRAM带宽逼出来

基线版本的矩阵乘法是llama.cpp默认的标量实现，它在树莓派上没问题，但在P4上就是灾难。问题在于默认kernel按行读取权重矩阵，而行的长度和缓存行大小严重不匹配，导致每次取数据都有一半带宽浪费在无关字节上。

这一阶段我做的事情是把内层循环改成按块读取：每次从PSRAM连续读取128字节、16字节对齐的数据块，然后立即在SRAM里完成反量化与乘加运算。仅这一步，就把速度提升到了约1.32 tok/s，翻了将近一倍。这里最关键的认知是：MCU跑大模型时，一个权重字节会被读取多次用于不同向量的乘加，所以你要保证每一次读取都有用，而不是把带宽花在读了一遍又一遍的重复数据上。

这一步我用了大约3天时间调试，踩过最大的坑是对齐问题：PSRAM的DMA控制器对未对齐读操作会降速，甚至触发总线异常，必须在模型加载阶段就把每个张量的起始地址对齐到16字节边界。

3.3 双核并行：省出理想的近2倍增额

P4是双核芯片，但处理器内部没有缓存一致性协议，所以双核并行玩不好就是数据竞争和性能回退。我采用的方案是任务级并行：一个核专门做模型的forward计算，另一个核在forward间隙处理tokenize、采样、日志打印等外围任务，同时在非计算阶段协同做权重预取。

这个阶段整体速度从1.32提升到了约2.15 tok/s。没有到达理想的2倍，原因在于双核共享同一个PSRAM控制器，计算核和预取核同时访问PSRAM时会发生仲裁竞争，实际带宽并不能翻倍。但从用户感知角度，生成长文本时，采样和处理时间几乎被完全掩盖了，所以体感提升其实比数字更明显。

3.4 把KV Cache压缩并移到PSRAM高位区间

LLM推理有个特点，每生成一个token都要把历史token的KV状态重新读一遍。在MCU平台上，KV Cache如果按默认的float32精度存储，内存占用大不说，每次自回归都要搬运大量数据。我对KV Cache做了int8量化，并且把它的数据布局从“按层排列”改成“按token排列”，这一步非常关键。

为什么按层排列不好？因为自回归生成时，计算层l和层l+1使用的是同一个token位置的数据，按token排列可以一次性读取所有层的数据，连续搬运，减少寻址开销。这步配合量化，速度提升到约3.11 tok/s。

3.5 采样器、上下文管理和编译器选项的最后一脚

到了3.11 tok/s之后，常规手段收益开始递减。我这时候回头审视整个数据流，发现还有三个“隐形小偷”：采样器的softmax计算用的是完整浮点精度，渲染进度日志时反复格式化字符串，以及编译器开的是-O2没敢上-O3。

把softmax从通用实现换成一个针对嵌入式优化的近似版本、把日志输出降到最低、同时把关键算子标上__attribute__((always_inline))再结合-O3 -flto重新编译之后，最终数字来到了4.31 tok/s。这一步没有大结构改动，属于“挖潜”，但收益相当可感。

整个优化过程我汇总成下面这张表，方便对照复现：

4. 每一步优化背后的收益与代价

很多人看到4.31这个数字，第一反应是“那精度崩了吧”。这个质疑很合理，事实上量化KV Cache那一步确实让部分长文本回答出现过前后不连贯的情况。这个部分我就把精度、稳定性和功耗的事一次说清楚。

4.1 精度损失到底有多少

我采用的验证方法比较土但很可靠：用同一个问题列表，分别在桌面平台（fp16推理）和P4平台（全优化后）上各跑一遍，人工对比答案的语义完整度。测试了大约50条不同长度的中文生成任务，结果是：

• 短回答（1-2句）：差异不明显，绝大部分语义一致
• 长回答（5句以上）：约10%的任务出现指代混乱或重复用词
• 数字推理类任务：误差明显增大，建议这类任务不要用int4+int8 KV的极端组合

如果产品对确定性要求高，我建议把KV Cache退回到fp16精度，用速度换质量，大约会降到3.6 tok/s左右——依然是可用的。

4.2 长时间运行稳定性

MCU跑LLM有个隐患：推理时间越长，PSRAM访问越频繁，芯片温度上升后内存时序可能变得不那么稳。我在30分钟持续压力测试中遇到过一次随机崩溃，定位后确认是电源纹波问题，而不是芯片过热。解决办法是给PSRAM供电脚加了一颗100uF的钽电容，并且把SD卡读取期间的中断优先级调低，从此没再复现。

4.3 功耗和发热表现

把MicroPython和裸机外设性能列出来了。整体功耗我测过，P4全速推理时电流约350mA，折合平均功耗1.2W左右，比树莓派低一个数量级，这也是为什么值得在MCU上折腾LLM的根本原因。发热方面，裸片测试温度在连续生成10分钟之后稳定在52度，外壳加上之后完全可接受。

5. 系列导航：按需食用指南

作为总览篇，除了交代动机和结论，我觉得最有用的部分是帮读者规划阅读路线。这个系列的每一篇我都尽量让它可以独立阅读，但如果你时间有限，可以参考下面的顺序。

5.1 按目标选篇目

• 想评估P4是否适合你的产品，建议看01和06
• 想自己动手移植llama.cpp，重点看01和02
• 想提升当前部署的速度，直接跳到03和04
• 想做更稳定的嵌入式推理产品，05和06别跳过

5.2 需要准备的软硬件

• 一块ESP32-P4开发板（带16MB或32MB PSRAM的版本）
• 一张高速TF卡，建议读速不低于40MB/s
• ESP-IDF v5.x 开发环境
• llama.cpp源码以及GGUF格式的小模型

这里特别说一下，模型不是越大越好，在MCU上跑2B级以上的模型，即便PSRAM容量够，带宽也会卡死性能上限。我在这个系列里选择0.5B级别模型作为基准，是因为它能在“可跑的精度”和“可用的速度”之间找到平衡点。如果你想试更大的模型，请提前做好带宽预算。

5.3 一个已经预见的争议

我知道有人会说，4.31 tok/s有什么值得吹的，随便一个手机跑大模型都吊打它。这句话我完全同意。但做这个项目的意义不是和手机比跑分，而是探索设备形态的最底层边界。当一颗几十块钱的MCU能离线跑通一个可对话的LLM，意味着很多对成本、功耗、体积有极端要求的设备——比如传感器节点、便携翻译器、儿童玩具——都可以不再依赖网络就能拥有基础的生成式AI能力。这个空间，才是这个系列真正想打开的。

按照我个人动手体会，从0.61到4.31最值得反复研究的是3.2那块——改写算子访存方式。前面所有模型选择都是给这一步铺路，后面所有花活都要建立在这一个扎实的基座上。如果你只记住一个要点，我的建议是：MCU上跑LLM优化，不是在算CPU，而是在喂内存带宽。把带宽用满，速度自然就来了。下一篇文章见。