尧图网站建设 
1. 项目缘起与整体思路拆解1.1 为什么要在 MCU 上跑 LLM把一个大语言模型塞进 MCU这件事放在两年前说出来大概率会被当成段子。毕竟主流认知里LLM 推理是 GPU 和服务器的事动辄几十 GB 显存、几百瓦功耗。但嵌入式圈子这几年有个明显趋势边缘设备不再满足于采集数据往上送而是希望本地就能做决策。原因很现实——网络延迟不可控、隐私数据不想出设备、离线场景必须能用。ESP32-P4 这颗芯片有意思的地方在于它不是传统意义上那种够用就行的 MCU。双核 RISC-V、最高 400MHz 主频、带 AI 指令扩展PIE、片上 SRAM 规模在 MCU 里算相当可观还支持外挂 PSRAM。这些特性凑在一起让它成为少数理论上能跑小模型的 MCU 平台。我最初的目标很朴素能不能让它在本地跑一个参数量在千万级别的小语言模型哪怕速度慢只要跑通就行。结果第一版跑下来0.61 tok/s。这个速度什么概念生成一句 20 个字的回复要等半分钟以上基本没法交互。但至少证明了一件事路是通的。接下来的问题就变成了纯工程问题——怎么把这个数字往上推。最终做到 4.31 tok/s差不多 7 倍提升。这篇总览就是把这 7 倍是怎么来的从头到尾拆一遍。1.2 系列文章的整体规划这个系列我打算分成几个部分来讲总览篇先把全局框架和关键决策讲清楚后面再逐个深入。整体上会覆盖这几块内容硬件与工具链准备ESP32-P4 开发环境搭建、模型格式转换、内存布局规划推理引擎移植把轻量级推理框架搬到 RISC-V 上处理指令集差异PIE 指令加速利用芯片自带的 AI 指令扩展做定点运算加速内存与缓存优化PSRAM 访问延迟、数据搬运、算子融合性能剖析与调优从 0.61 到 4.31 的每一步量化收益这样安排的原因是性能优化从来不是单一手段的功劳而是多个环节叠加的结果。如果只讲某一项技术读者很难复现出同样的效果。所以我倾向于把每一步的为什么和怎么做都交代清楚。1.3 核心思路先跑通再压榨整个项目我遵循一个原则先让它在最保守的配置下跑起来建立基线然后逐项优化并记录收益。这个原则听起来简单但实际执行时很容易走偏。很多人一上来就想用最优配置结果某个环节出问题根本不知道是哪一步引入的。我的做法是用最朴素的 C 实现跑通推理不追求速度只求结果正确建立性能基线记录每个算子的耗时占比按耗时从高到低排序优先优化大头每优化一项单独测一次确认收益和副作用这样做的好处是每一步的贡献都清清楚楚。最后汇总时你能明确知道哪项优化值 2 倍哪项只值 5%。对于资源有限的 MCU 来说把精力花在刀刃上比什么都重要。提示建立基线这件事很多人会跳过。但没有基线你后面所有的优化都是盲目的。哪怕基线很慢它也是你判断一切改进的参照物。2. 核心细节解析与实操要点2.1 模型选型为什么是千万参数级别在 MCU 上跑 LLM模型选型是第一道坎。参数量直接决定内存占用和计算量。ESP32-P4 的片上 SRAM 加上外挂 PSRAM可用内存大概在几 MB 到十几 MB 这个量级具体取决于你的板子配置。这意味着模型权重必须控制在几 MB 以内。我最终选的是一个参数量在千万级别的小模型量化到 int8 之后权重占用大约 2-3MB。这个规模是权衡的结果再大一点内存放不下或者要频繁换入换出速度崩掉再小一点模型能力太弱生成质量没法看这里有个经验MCU 上跑 LLM模型能力的天花板不是算力而是内存带宽。因为权重每次推理都要从 PSRAM 读进来PSRAM 的访问速度远低于片上 SRAM。所以模型越大内存搬运的瓶颈越明显。2.2 量化方案int8 是甜点浮点运算在 MCU 上代价很高。ESP32-P4 虽然有 FPU但做大规模矩阵乘还是吃力。所以量化是必须的。我试过几种方案量化方案权重占用推理速度生成质量适用性FP32大慢最好不实用FP16中中好内存吃紧int8小快可接受推荐int4最小最快明显下降极限场景int8 是甜点。它把权重和激活都压到 8 位整数配合量化缩放因子还原数值。关键是ESP32-P4 的 PIE 指令扩展对 int8 点积有硬件加速这是后面提速的核心。量化的具体做法是先在 PC 上用训练后量化PTQ把模型转成 int8校准集选一批有代表性的输入统计每层的激活范围确定缩放因子。这一步在 PC 上做MCU 只负责推理。2.3 内存布局把热数据放在片上内存布局是 MCU 推理的隐形杀手。ESP32-P4 有片上 SRAM 和外挂 PSRAM 两级。片上 SRAM 快但小PSRAM 大但慢。怎么分配数据直接决定性能。我的策略是权重放 PSRAM因为体积大放不下片上激活值放片上 SRAM因为频繁读写KV Cache放片上 SRAM注意力计算时反复访问临时缓冲区放片上 SRAM算子中间结果这个分配不是拍脑袋定的。我做过对比测试把激活值放 PSRAM速度直接掉一半。因为每个算子都要读写激活PSRAM 的延迟被放大了无数次。注意片上 SRAM 是稀缺资源要精打细算。我建议先用工具统计各部分的峰值占用再决定谁放片上谁放片外。别凭感觉。2.4 工具链与开发环境开发环境这块我用的是官方推荐的 ESP-IDF。版本选择上有个坑不同版本的编译器对 RISC-V 的优化程度不一样PIE 指令的支持也有差异。我实测下来较新的版本生成的代码质量更好但要注意和芯片固件的兼容性。编译选项里这几个是关键-O2 # 优化等级-O3 有时反而更慢 -marchrv32imafc # 基础指令集 -mabiilp32f # ABI -DPIE_ENABLE1 # 启用 PIE 指令 -ffast-math # 浮点优化如果还有浮点运算-O3有时比-O2慢是因为过度展开导致指令缓存命中率下降。这个在 MCU 上很常见因为指令缓存很小。所以别迷信最高优化等级要实测。3. 实操过程与核心环节实现3.1 从 PC 到 MCU 的模型转换流程模型转换是整个流程的第一步也是最容易出错的一步。我的流程是这样的PC 端导出从训练框架导出模型权重通常是 PyTorch 的 state_dict图优化做算子融合把 LayerNorm、激活函数等合并到相邻的矩阵乘里量化用校准集做 PTQ生成 int8 权重和缩放因子格式转换转成 MCU 能直接读的二进制格式包含权重、缩放因子、元数据烧录把模型文件放到文件系统或直接嵌入固件这里有个细节算子融合能省多少我实测下来把 LayerNorm 融合进前面的线性层能减少一次完整的内存读写整体提速大概 8%-12%。别小看这个数字在 MCU 上每一次内存搬运都是成本。转换脚本我写了个 Python 工具核心逻辑是遍历计算图识别可融合的模式然后重写。这部分代码量不大但需要仔细处理边界情况比如残差连接的存在会打断融合。3.2 推理引擎的移植与适配推理引擎我选的是一个轻量级框架代码量小依赖少适合移植。移植的主要工作是替换内存分配把框架默认的 malloc 换成 MCU 的内存池管理适配算子有些算子用了 PC 特有的指令要重写成通用 C处理对齐RISC-V 对内存对齐有要求未对齐访问会触发异常对齐这个问题坑了我很久。PC 上未对齐访问顶多慢一点MCU 上直接崩。解决办法是保证所有缓冲区按 4 字节对齐矩阵的行长度也补齐到 4 的倍数。虽然浪费一点内存但换来稳定。移植完成后第一版跑通速度 0.61 tok/s。这个数字虽然难看但至少结果是对的。我拿几个标准输入测了输出和 PC 上的结果对比误差在可接受范围内。3.3 PIE 指令加速的接入PIE 是 ESP32-P4 的 AI 指令扩展专门为神经网络计算设计。它提供了一批 SIMD 风格的指令能一次处理多个 int8 数据。这是从 0.61 到 4.31 的关键。接入 PIE 的核心是把矩阵乘和卷积这类密集计算从标量循环改成 PIE 指令。具体做法用 PIE 的加载指令一次读入多个 int8用点积指令做乘加用累加指令汇总结果我写了一个 PIE 版本的矩阵乘内核对比标量版本单算子提速大概 4-5 倍。但整体提速没有这么夸张因为矩阵乘只占总耗时的一部分其他算子如激活、归一化还是标量。提示PIE 指令有使用门槛需要理解数据布局。建议先写一个小的测试程序验证指令行为再接入主流程。直接改主流程调试会很痛苦。3.4 内存搬运的优化前面说过MCU 上 LLM 的瓶颈往往是内存带宽。我做了几件事来减少搬运算子融合减少中间结果的写回和读取分块计算把大矩阵切成小块让中间结果留在片上 SRAM预取在计算当前块时提前把下一块权重从 PSRAM 读进来分块计算的效果最明显。原本一个大矩阵乘中间结果要写回 PSRAM 再读出来分块后中间结果一直在片上省了大量搬运。这一项优化大概贡献了 1.5 倍提速。预取则需要小心处理因为 PSRAM 的访问有延迟预取太早会占用缓冲区太晚又来不及。我调了几次参数最终确定预取距离为 2 个块。3.5 性能剖析与逐步调优记录整个优化过程我做了详细记录下面是各阶段的提速贡献优化阶段速度 (tok/s)相对提升主要手段基线0.61-标量 C 实现算子融合0.721.18x减少内存搬运分块计算1.101.53x中间结果留片上PIE 矩阵乘2.802.55x硬件加速预取优化3.601.29x隐藏 PSRAM 延迟其他微调4.311.20x循环展开、对齐等这张表是整个项目的核心。它告诉你每一分努力值多少。可以看到PIE 矩阵乘是最大头贡献了 2.55 倍。但如果没有前面的算子融合和分块PIE 的效果也会打折扣因为内存瓶颈会限制它发挥。4. 常见问题与排查技巧实录4.1 推理结果不对怎么排查这是最常见的问题。模型跑起来了但输出是乱码或者重复。排查思路先查量化把量化关掉用 FP32 跑一遍如果结果对了说明是量化精度问题再查算子逐个算子对比 PC 和 MCU 的输出找出第一个不一致的最后查内存检查是否有缓冲区越界或未初始化我遇到过一次输出全是同一个字。查了半天发现是 KV Cache 的索引算错了导致每次都读同一块内存。这种问题只能靠逐算子对比定位。4.2 速度上不去的几个原因速度优化到一定程度会卡住常见原因内存带宽饱和PSRAM 访问已经跑满再怎么优化计算也没用指令缓存未命中代码太大指令缓存装不下频繁换入换出分支预测失败MCU 的分支预测能力弱循环里的条件判断代价高针对指令缓存我的做法是把热点函数放在一起减少跳转。针对分支预测尽量把条件判断提到循环外面或者用查表代替分支。4.3 内存不够用的应对模型稍微大一点就内存不够。应对手段权重分片加载不一次加载全部权重按需加载激活值复用不同算子复用同一块缓冲区降低 KV Cache 精度KV Cache 也用 int8权重分片加载会牺牲速度因为要频繁读 PSRAM。但如果内存实在不够这是唯一的选择。4.4 常见问题速查表现象可能原因排查方向输出乱码量化精度、算子错误逐算子对比速度极慢内存瓶颈、未启用 PIE检查内存布局、编译选项运行崩溃内存越界、对齐问题检查缓冲区大小、对齐结果不稳定未初始化内存、竞态初始化检查、加锁编译报错指令集不匹配检查 march 和 mabi4.5 几个踩过的坑坑一PSRAM 的访问粒度。PSRAM 按块访问随机小数据访问效率极低。我一开始把权重按元素读速度惨不忍睹。改成按块读之后速度翻倍。坑二编译器的自动向量化。RISC-V 编译器有时会自动生成向量指令但生成的代码不一定最优。我遇到过自动向量化反而变慢的情况最后手动写了 PIE 内核。坑三温度对性能的影响。MCU 跑满负载会发热温度升高后可能降频。长时间跑推理要注意散热否则速度会波动。注意这些坑都是实测踩出来的文档里不会写。如果你也在做类似的事建议先把这几个点检查一遍能省不少时间。5. 后续系列的展开方向总览篇到这里把整体框架和关键决策讲完了。后面几篇会逐个深入第二篇讲模型转换和量化包括校准集怎么选、缩放因子怎么算第三篇讲推理引擎移植重点是内存管理和算子适配第四篇讲 PIE 指令包括指令用法和内核编写第五篇讲性能调优把那张提速表里的每一项拆开讲我个人在实际操作中的体会是MCU 上跑 LLM 这件事技术难度不在于某个单点而在于把一堆约束条件同时满足。内存、算力、带宽、功耗每一个都是紧箍咒。但正因为约束多优化空间也大。从 0.61 到 4.31每一步都是实打实抠出来的。最后分享一个小技巧如果你也想在 MCU 上跑模型别一上来就追求大模型。先用一个极小的模型把整条链路跑通建立基线然后再逐步换大模型、加优化。这样每一步都有参照不会迷失方向。 ESP32-P4 上跑 LLM：从 0.61 到 4.31 tok/s 的 MCU 推理优化实战
1. 项目缘起与整体思路拆解1.1 为什么要在 MCU 上跑 LLM把一个大语言模型塞进 MCU这件事放在两年前说出来大概率会被当成段子。毕竟主流认知里LLM 推理是 GPU 和服务器的事动辄几十 GB 显存、几百瓦功耗。但嵌入式圈子这几年有个明显趋势边缘设备不再满足于采集数据往上送而是希望本地就能做决策。原因很现实——网络延迟不可控、隐私数据不想出设备、离线场景必须能用。ESP32-P4 这颗芯片有意思的地方在于它不是传统意义上那种够用就行的 MCU。双核 RISC-V、最高 400MHz 主频、带 AI 指令扩展PIE、片上 SRAM 规模在 MCU 里算相当可观还支持外挂 PSRAM。这些特性凑在一起让它成为少数理论上能跑小模型的 MCU 平台。我最初的目标很朴素能不能让它在本地跑一个参数量在千万级别的小语言模型哪怕速度慢只要跑通就行。结果第一版跑下来0.61 tok/s。这个速度什么概念生成一句 20 个字的回复要等半分钟以上基本没法交互。但至少证明了一件事路是通的。接下来的问题就变成了纯工程问题——怎么把这个数字往上推。最终做到 4.31 tok/s差不多 7 倍提升。这篇总览就是把这 7 倍是怎么来的从头到尾拆一遍。1.2 系列文章的整体规划这个系列我打算分成几个部分来讲总览篇先把全局框架和关键决策讲清楚后面再逐个深入。整体上会覆盖这几块内容硬件与工具链准备ESP32-P4 开发环境搭建、模型格式转换、内存布局规划推理引擎移植把轻量级推理框架搬到 RISC-V 上处理指令集差异PIE 指令加速利用芯片自带的 AI 指令扩展做定点运算加速内存与缓存优化PSRAM 访问延迟、数据搬运、算子融合性能剖析与调优从 0.61 到 4.31 的每一步量化收益这样安排的原因是性能优化从来不是单一手段的功劳而是多个环节叠加的结果。如果只讲某一项技术读者很难复现出同样的效果。所以我倾向于把每一步的为什么和怎么做都交代清楚。1.3 核心思路先跑通再压榨整个项目我遵循一个原则先让它在最保守的配置下跑起来建立基线然后逐项优化并记录收益。这个原则听起来简单但实际执行时很容易走偏。很多人一上来就想用最优配置结果某个环节出问题根本不知道是哪一步引入的。我的做法是用最朴素的 C 实现跑通推理不追求速度只求结果正确建立性能基线记录每个算子的耗时占比按耗时从高到低排序优先优化大头每优化一项单独测一次确认收益和副作用这样做的好处是每一步的贡献都清清楚楚。最后汇总时你能明确知道哪项优化值 2 倍哪项只值 5%。对于资源有限的 MCU 来说把精力花在刀刃上比什么都重要。提示建立基线这件事很多人会跳过。但没有基线你后面所有的优化都是盲目的。哪怕基线很慢它也是你判断一切改进的参照物。2. 核心细节解析与实操要点2.1 模型选型为什么是千万参数级别在 MCU 上跑 LLM模型选型是第一道坎。参数量直接决定内存占用和计算量。ESP32-P4 的片上 SRAM 加上外挂 PSRAM可用内存大概在几 MB 到十几 MB 这个量级具体取决于你的板子配置。这意味着模型权重必须控制在几 MB 以内。我最终选的是一个参数量在千万级别的小模型量化到 int8 之后权重占用大约 2-3MB。这个规模是权衡的结果再大一点内存放不下或者要频繁换入换出速度崩掉再小一点模型能力太弱生成质量没法看这里有个经验MCU 上跑 LLM模型能力的天花板不是算力而是内存带宽。因为权重每次推理都要从 PSRAM 读进来PSRAM 的访问速度远低于片上 SRAM。所以模型越大内存搬运的瓶颈越明显。2.2 量化方案int8 是甜点浮点运算在 MCU 上代价很高。ESP32-P4 虽然有 FPU但做大规模矩阵乘还是吃力。所以量化是必须的。我试过几种方案量化方案权重占用推理速度生成质量适用性FP32大慢最好不实用FP16中中好内存吃紧int8小快可接受推荐int4最小最快明显下降极限场景int8 是甜点。它把权重和激活都压到 8 位整数配合量化缩放因子还原数值。关键是ESP32-P4 的 PIE 指令扩展对 int8 点积有硬件加速这是后面提速的核心。量化的具体做法是先在 PC 上用训练后量化PTQ把模型转成 int8校准集选一批有代表性的输入统计每层的激活范围确定缩放因子。这一步在 PC 上做MCU 只负责推理。2.3 内存布局把热数据放在片上内存布局是 MCU 推理的隐形杀手。ESP32-P4 有片上 SRAM 和外挂 PSRAM 两级。片上 SRAM 快但小PSRAM 大但慢。怎么分配数据直接决定性能。我的策略是权重放 PSRAM因为体积大放不下片上激活值放片上 SRAM因为频繁读写KV Cache放片上 SRAM注意力计算时反复访问临时缓冲区放片上 SRAM算子中间结果这个分配不是拍脑袋定的。我做过对比测试把激活值放 PSRAM速度直接掉一半。因为每个算子都要读写激活PSRAM 的延迟被放大了无数次。注意片上 SRAM 是稀缺资源要精打细算。我建议先用工具统计各部分的峰值占用再决定谁放片上谁放片外。别凭感觉。2.4 工具链与开发环境开发环境这块我用的是官方推荐的 ESP-IDF。版本选择上有个坑不同版本的编译器对 RISC-V 的优化程度不一样PIE 指令的支持也有差异。我实测下来较新的版本生成的代码质量更好但要注意和芯片固件的兼容性。编译选项里这几个是关键-O2 # 优化等级-O3 有时反而更慢 -marchrv32imafc # 基础指令集 -mabiilp32f # ABI -DPIE_ENABLE1 # 启用 PIE 指令 -ffast-math # 浮点优化如果还有浮点运算-O3有时比-O2慢是因为过度展开导致指令缓存命中率下降。这个在 MCU 上很常见因为指令缓存很小。所以别迷信最高优化等级要实测。3. 实操过程与核心环节实现3.1 从 PC 到 MCU 的模型转换流程模型转换是整个流程的第一步也是最容易出错的一步。我的流程是这样的PC 端导出从训练框架导出模型权重通常是 PyTorch 的 state_dict图优化做算子融合把 LayerNorm、激活函数等合并到相邻的矩阵乘里量化用校准集做 PTQ生成 int8 权重和缩放因子格式转换转成 MCU 能直接读的二进制格式包含权重、缩放因子、元数据烧录把模型文件放到文件系统或直接嵌入固件这里有个细节算子融合能省多少我实测下来把 LayerNorm 融合进前面的线性层能减少一次完整的内存读写整体提速大概 8%-12%。别小看这个数字在 MCU 上每一次内存搬运都是成本。转换脚本我写了个 Python 工具核心逻辑是遍历计算图识别可融合的模式然后重写。这部分代码量不大但需要仔细处理边界情况比如残差连接的存在会打断融合。3.2 推理引擎的移植与适配推理引擎我选的是一个轻量级框架代码量小依赖少适合移植。移植的主要工作是替换内存分配把框架默认的 malloc 换成 MCU 的内存池管理适配算子有些算子用了 PC 特有的指令要重写成通用 C处理对齐RISC-V 对内存对齐有要求未对齐访问会触发异常对齐这个问题坑了我很久。PC 上未对齐访问顶多慢一点MCU 上直接崩。解决办法是保证所有缓冲区按 4 字节对齐矩阵的行长度也补齐到 4 的倍数。虽然浪费一点内存但换来稳定。移植完成后第一版跑通速度 0.61 tok/s。这个数字虽然难看但至少结果是对的。我拿几个标准输入测了输出和 PC 上的结果对比误差在可接受范围内。3.3 PIE 指令加速的接入PIE 是 ESP32-P4 的 AI 指令扩展专门为神经网络计算设计。它提供了一批 SIMD 风格的指令能一次处理多个 int8 数据。这是从 0.61 到 4.31 的关键。接入 PIE 的核心是把矩阵乘和卷积这类密集计算从标量循环改成 PIE 指令。具体做法用 PIE 的加载指令一次读入多个 int8用点积指令做乘加用累加指令汇总结果我写了一个 PIE 版本的矩阵乘内核对比标量版本单算子提速大概 4-5 倍。但整体提速没有这么夸张因为矩阵乘只占总耗时的一部分其他算子如激活、归一化还是标量。提示PIE 指令有使用门槛需要理解数据布局。建议先写一个小的测试程序验证指令行为再接入主流程。直接改主流程调试会很痛苦。3.4 内存搬运的优化前面说过MCU 上 LLM 的瓶颈往往是内存带宽。我做了几件事来减少搬运算子融合减少中间结果的写回和读取分块计算把大矩阵切成小块让中间结果留在片上 SRAM预取在计算当前块时提前把下一块权重从 PSRAM 读进来分块计算的效果最明显。原本一个大矩阵乘中间结果要写回 PSRAM 再读出来分块后中间结果一直在片上省了大量搬运。这一项优化大概贡献了 1.5 倍提速。预取则需要小心处理因为 PSRAM 的访问有延迟预取太早会占用缓冲区太晚又来不及。我调了几次参数最终确定预取距离为 2 个块。3.5 性能剖析与逐步调优记录整个优化过程我做了详细记录下面是各阶段的提速贡献优化阶段速度 (tok/s)相对提升主要手段基线0.61-标量 C 实现算子融合0.721.18x减少内存搬运分块计算1.101.53x中间结果留片上PIE 矩阵乘2.802.55x硬件加速预取优化3.601.29x隐藏 PSRAM 延迟其他微调4.311.20x循环展开、对齐等这张表是整个项目的核心。它告诉你每一分努力值多少。可以看到PIE 矩阵乘是最大头贡献了 2.55 倍。但如果没有前面的算子融合和分块PIE 的效果也会打折扣因为内存瓶颈会限制它发挥。4. 常见问题与排查技巧实录4.1 推理结果不对怎么排查这是最常见的问题。模型跑起来了但输出是乱码或者重复。排查思路先查量化把量化关掉用 FP32 跑一遍如果结果对了说明是量化精度问题再查算子逐个算子对比 PC 和 MCU 的输出找出第一个不一致的最后查内存检查是否有缓冲区越界或未初始化我遇到过一次输出全是同一个字。查了半天发现是 KV Cache 的索引算错了导致每次都读同一块内存。这种问题只能靠逐算子对比定位。4.2 速度上不去的几个原因速度优化到一定程度会卡住常见原因内存带宽饱和PSRAM 访问已经跑满再怎么优化计算也没用指令缓存未命中代码太大指令缓存装不下频繁换入换出分支预测失败MCU 的分支预测能力弱循环里的条件判断代价高针对指令缓存我的做法是把热点函数放在一起减少跳转。针对分支预测尽量把条件判断提到循环外面或者用查表代替分支。4.3 内存不够用的应对模型稍微大一点就内存不够。应对手段权重分片加载不一次加载全部权重按需加载激活值复用不同算子复用同一块缓冲区降低 KV Cache 精度KV Cache 也用 int8权重分片加载会牺牲速度因为要频繁读 PSRAM。但如果内存实在不够这是唯一的选择。4.4 常见问题速查表现象可能原因排查方向输出乱码量化精度、算子错误逐算子对比速度极慢内存瓶颈、未启用 PIE检查内存布局、编译选项运行崩溃内存越界、对齐问题检查缓冲区大小、对齐结果不稳定未初始化内存、竞态初始化检查、加锁编译报错指令集不匹配检查 march 和 mabi4.5 几个踩过的坑坑一PSRAM 的访问粒度。PSRAM 按块访问随机小数据访问效率极低。我一开始把权重按元素读速度惨不忍睹。改成按块读之后速度翻倍。坑二编译器的自动向量化。RISC-V 编译器有时会自动生成向量指令但生成的代码不一定最优。我遇到过自动向量化反而变慢的情况最后手动写了 PIE 内核。坑三温度对性能的影响。MCU 跑满负载会发热温度升高后可能降频。长时间跑推理要注意散热否则速度会波动。注意这些坑都是实测踩出来的文档里不会写。如果你也在做类似的事建议先把这几个点检查一遍能省不少时间。5. 后续系列的展开方向总览篇到这里把整体框架和关键决策讲完了。后面几篇会逐个深入第二篇讲模型转换和量化包括校准集怎么选、缩放因子怎么算第三篇讲推理引擎移植重点是内存管理和算子适配第四篇讲 PIE 指令包括指令用法和内核编写第五篇讲性能调优把那张提速表里的每一项拆开讲我个人在实际操作中的体会是MCU 上跑 LLM 这件事技术难度不在于某个单点而在于把一堆约束条件同时满足。内存、算力、带宽、功耗每一个都是紧箍咒。但正因为约束多优化空间也大。从 0.61 到 4.31每一步都是实打实抠出来的。最后分享一个小技巧如果你也想在 MCU 上跑模型别一上来就追求大模型。先用一个极小的模型把整条链路跑通建立基线然后再逐步换大模型、加优化。这样每一步都有参照不会迷失方向。