ESP32-AI：28.9M 参数 LLM 跑在 8 美元微控制器上，真正有价值的是内存设计
如果只看标题，“在 8 美元微控制器上跑 LLM”很容易被误读成又一个玩具式 demo：模型很小、输出几句童话、离 ChatGPT 差十万八千里。 但我反而觉得这个项目值得认真看。原因不是它能在 ESP32-S3 上聊天，而是它把一个越来越重要的工程问题讲得非常直白：当算力不是最大瓶颈，内存层级才是决定模型能不能落地的关键。 HN 这两天热度很高的 esp32-ai 做了一件很极端的事：把一个 28.9M 参数的小语言模型放到 ESP32-S3 N16R8 上运行。这个芯片大概 8 美元，只有 512KB SRAM、8MB PSRAM、16MB flash。项目 README 给出的公开数字是：模型 4-bit 后约 14.9MB，端到端速度约 9.5 token/s，完全离线运行，不把输入发到服务器。 这当然不是一个通用助手。README 也说得很克制：模型用 TinyStories 训练，只会生成短故事，不能问答、不能写代码、也没有事实知识。换句话说，它的产品能力并不重要。 真正重要的是：它证明了“参数量”不一定等于“必须常驻高速内存”。 别急着问它能不能替代云端模型 我以前看边缘 AI 项目，最容易犯的一个错误是上来就问：“这个东西能不能替代大模型？”答案几乎永远是否定的，然后讨论就结束了。 但这次应该换个问法：如果一个模型的很多参数并不是每个 token 都需要完整读取，那我们能不能把这些参数放到更便宜、更慢、但容量更大的存储层里？ ESP32-AI 的设计核心就是这个问题。 项目作者借用了 Google Gemma 系列里的 Per-Layer Embeddings 思路。Gemma 3n 文档把它描述为一种面向端侧设备的效率设计：把部分模型容量做成按需访问的 embedding 结构，而不是让所有权重都以同样方式参与每一步计算。ESP32-AI 更进一步，把这个想法搬到了微控制器的内存布局里。 用人话说就是：别把整个模型都塞进“办公桌”上。常用的小核心放桌面，偶尔查的巨大词表放书架；每次只抽几页出来看。 在 ESP32-S3 上，这个“办公桌”是 512KB SRAM，“书架”是 flash。项目 README 里的分层很清楚：SRAM 放小的计算核心，PSRAM 放输出头和工作区，flash 放 25M 参数级别的 PLE table。每个 token 只需要从 flash 取大约 450 字节，而不是把 12MB 级别的表整块搬进快内存。 ...