一块 ESP32-P4 开发板大多数时候被人拿去点灯、采集传感器、做屏幕交互。但最近有人展示了一件事在 ESP32-P4 上离线运行 180.9M 参数的 LLM并且还能完成 Agent 推理。初看这个标题很容易产生疑问1.8 亿参数就算量化到 INT4权重也要 90MB 左右这还没算中间激活和 KV Cache。更别说 Agent 这种需要多轮决策的流程通常默认要跑在云端或开发板上。标题里的 Offline 和 inference 已经把问题说得很清楚推理真的发生在设备本地。这件事最值得关注的不是“180.9M 参数被塞进了一颗 MCU”而是“端侧智能正在从感知任务走向规划与决策任务”。过去我们习惯在嵌入式设备上跑图像分类、语音唤醒这些模型只负责判断“是什么”Agent 推理则意味着模型可以决定“接下来做什么”并且调用工具、观察结果、进入下一轮。把这种闭环搬到本地等于给离线设备装了一个真正可决策的最小大脑。这篇文章不打算只用“有人做到了”来开头。我更想把它拆成几个工程问题一个 180.9M 参数模型要经过哪些处理才能在 ESP32-P4 上完成单次推理Agent 流程在端侧和云端有什么本质区别如果你也想复现最合理的落地路径是什么以及真正适合这种方案的产品边界在哪里。1. 为什么“1.8 亿参数模型跑在单片机”这件事值得认真看1.1 先纠正一个直觉参数越小不代表越弱在云端大模型动辄 7B、70B 甚至更大时180.9M 这个数字很容易被看成玩具。但这里有个误区模型能力并不是只由参数量决定。同一个数量级的模型如果经过任务定向微调可以在特定领域内表现得像一个“熟练工”而一个更大的通用模型在受限动作空间里反而可能因为自由度太高出现更多不可控输出。Agent 推理更接近“从有限选项里选动作”而不是“在开放问题里自由发挥”。180.9M 模型当然不能和云端助手比知识面但它可以记住一套设备相关的工具说明理解用户指令里的意图然后选择一个动作编号。决定这个闭环是否可靠的更多是任务边界和流程设计而不是单纯堆参数量。所以看到 180.9M 参数不应该先问“它能不能打”而应该问“它被训练成解决什么问题”。在嵌入式场景里把任务收敛得足够窄小模型就能真正用起来。1.2 ESP32-P4 到底是一块什么样的芯片先说明一个边界具体芯片频率、核数、内存大小应该以官方手册和实际开发板配置为准。这里不展开写某个“官方确认”的参数而是从工程视角看为什么会有项目选择在 ESP32-P4 上做这件事。跑 LLM 推理硬件上最核心的限制不是单纯算力而是“能不能装下运行时状态”。一个模型的权重文件可能被量化到几十 MB但推理过程中还有中间激活、KV Cache、临时缓冲区。如果芯片只有几百 KB 的片上 SRAM光靠片上内存根本不可能完成哪怕一次前向计算。所以这类项目通常依赖 PSRAM 或外部存储扩展。ESP32-P4 的定位正好覆盖了高性能计算、多媒体和人机交互评估板也普遍带有更大内存这让它有了承载轻量 LLM 的基础。但“硬件能装下”只是第一步。真正决定上限的是软件链路模型是否被正确量化、算子是否能在设备上执行、推理框架是否适配 MCU 的运行方式。同一颗芯片有人只能跑官方示例有人能跑出可用的 Agent差别主要在这里。2. 离线 LLM 推理的真正难点不在模型而在整条链路2.1 模型从通用权重到设备可执行文件至少要过四道关一个在 PC 上能跑起来的模型到了 MCU 上并不是“下载模型文件、调用接口”这么简单。通常要经历模型裁剪根据设备内存和 Flash 容量决定是否减小 hidden size、层数或裁剪词表。180.9M 参数可以理解为一个起点实际部署时可能还会做进一步压缩。量化常见做法是 INT8 或 INT4。权重量化后体积明显下降但会带来精度损失。需要用校准集评估确保量化后仍能完成预期任务而不只是“能生成内容”。格式转换训练框架导出的模型需要转换为推理格式并确认每个算子都有对应实现。转换完成后要逐个检查不能只看转换过程有没有报错。编译链接与内存规划模型权重变成一个大数组和固件一起烧进 Flash运行时再按需加载到 PSRAM。Tokenizer 词表同样要存储位置、对齐方式、访问方式都需要在链接阶段规划好。这一整套流程任何一个环节出错结果都不是“效果差一点”而是编译不过、启动崩溃或推理结果完全不可用。很多人在 PC 上觉得模型没问题换到 MCU 后状况百出通常不是参数问题而是转换链路没跑通。这里可以整理一个最小流程清单1. 选一个小于目标规模的轻 ESP32-P4上离线运行1.8亿参数LLM，端侧Agent推理成为可能
一块 ESP32-P4 开发板大多数时候被人拿去点灯、采集传感器、做屏幕交互。但最近有人展示了一件事在 ESP32-P4 上离线运行 180.9M 参数的 LLM并且还能完成 Agent 推理。初看这个标题很容易产生疑问1.8 亿参数就算量化到 INT4权重也要 90MB 左右这还没算中间激活和 KV Cache。更别说 Agent 这种需要多轮决策的流程通常默认要跑在云端或开发板上。标题里的 Offline 和 inference 已经把问题说得很清楚推理真的发生在设备本地。这件事最值得关注的不是“180.9M 参数被塞进了一颗 MCU”而是“端侧智能正在从感知任务走向规划与决策任务”。过去我们习惯在嵌入式设备上跑图像分类、语音唤醒这些模型只负责判断“是什么”Agent 推理则意味着模型可以决定“接下来做什么”并且调用工具、观察结果、进入下一轮。把这种闭环搬到本地等于给离线设备装了一个真正可决策的最小大脑。这篇文章不打算只用“有人做到了”来开头。我更想把它拆成几个工程问题一个 180.9M 参数模型要经过哪些处理才能在 ESP32-P4 上完成单次推理Agent 流程在端侧和云端有什么本质区别如果你也想复现最合理的落地路径是什么以及真正适合这种方案的产品边界在哪里。1. 为什么“1.8 亿参数模型跑在单片机”这件事值得认真看1.1 先纠正一个直觉参数越小不代表越弱在云端大模型动辄 7B、70B 甚至更大时180.9M 这个数字很容易被看成玩具。但这里有个误区模型能力并不是只由参数量决定。同一个数量级的模型如果经过任务定向微调可以在特定领域内表现得像一个“熟练工”而一个更大的通用模型在受限动作空间里反而可能因为自由度太高出现更多不可控输出。Agent 推理更接近“从有限选项里选动作”而不是“在开放问题里自由发挥”。180.9M 模型当然不能和云端助手比知识面但它可以记住一套设备相关的工具说明理解用户指令里的意图然后选择一个动作编号。决定这个闭环是否可靠的更多是任务边界和流程设计而不是单纯堆参数量。所以看到 180.9M 参数不应该先问“它能不能打”而应该问“它被训练成解决什么问题”。在嵌入式场景里把任务收敛得足够窄小模型就能真正用起来。1.2 ESP32-P4 到底是一块什么样的芯片先说明一个边界具体芯片频率、核数、内存大小应该以官方手册和实际开发板配置为准。这里不展开写某个“官方确认”的参数而是从工程视角看为什么会有项目选择在 ESP32-P4 上做这件事。跑 LLM 推理硬件上最核心的限制不是单纯算力而是“能不能装下运行时状态”。一个模型的权重文件可能被量化到几十 MB但推理过程中还有中间激活、KV Cache、临时缓冲区。如果芯片只有几百 KB 的片上 SRAM光靠片上内存根本不可能完成哪怕一次前向计算。所以这类项目通常依赖 PSRAM 或外部存储扩展。ESP32-P4 的定位正好覆盖了高性能计算、多媒体和人机交互评估板也普遍带有更大内存这让它有了承载轻量 LLM 的基础。但“硬件能装下”只是第一步。真正决定上限的是软件链路模型是否被正确量化、算子是否能在设备上执行、推理框架是否适配 MCU 的运行方式。同一颗芯片有人只能跑官方示例有人能跑出可用的 Agent差别主要在这里。2. 离线 LLM 推理的真正难点不在模型而在整条链路2.1 模型从通用权重到设备可执行文件至少要过四道关一个在 PC 上能跑起来的模型到了 MCU 上并不是“下载模型文件、调用接口”这么简单。通常要经历模型裁剪根据设备内存和 Flash 容量决定是否减小 hidden size、层数或裁剪词表。180.9M 参数可以理解为一个起点实际部署时可能还会做进一步压缩。量化常见做法是 INT8 或 INT4。权重量化后体积明显下降但会带来精度损失。需要用校准集评估确保量化后仍能完成预期任务而不只是“能生成内容”。格式转换训练框架导出的模型需要转换为推理格式并确认每个算子都有对应实现。转换完成后要逐个检查不能只看转换过程有没有报错。编译链接与内存规划模型权重变成一个大数组和固件一起烧进 Flash运行时再按需加载到 PSRAM。Tokenizer 词表同样要存储位置、对齐方式、访问方式都需要在链接阶段规划好。这一整套流程任何一个环节出错结果都不是“效果差一点”而是编译不过、启动崩溃或推理结果完全不可用。很多人在 PC 上觉得模型没问题换到 MCU 后状况百出通常不是参数问题而是转换链路没跑通。这里可以整理一个最小流程清单1. 选一个小于目标规模的轻