如果只看标题，“在 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 级别的表整块搬进快内存。
这就是它能跑起来的关键。
28.9M 参数听着大，但大部分不是“每步都算”的参数
这里有个容易混淆的点：28.9M 参数并不意味着每生成一个 token 都要像常规 Transformer 那样密集扫过 28.9M 参数。
RESULTS.md 里写得更具体：部署配置包含 32768 vocab，core 在约 559K 参数量级，25M 参数 PLE table 放在 flash 里；核心部分足够小，符合 ESP32-S3 512KB 内部 SRAM 的约束。4-bit PTQ 之后，作者报告 PLE 相对 baseline 的收益仍然保留，并且在板上测得端到端约 9.5 tok/s。
这不是“奇迹般把大模型压进小芯片”，而是重新定义哪些参数必须快、哪些参数可以慢。
这点对工程实践很有启发。我们做 LLM inference 时经常盯着 FLOPs、量化位宽、GPU 利用率，但很多真实系统最后卡在内存带宽和数据搬运上。云端是 HBM 和 KV cache，手机端是统一内存和 NPU，微控制器则是 SRAM/PSRAM/flash 的残酷分层。尺度不同，问题本质很像。
说白了就是：模型推理不是只有“算得快”这一件事，还要“搬得少”。
这个项目最值得学的是约束意识
ESP32-AI 没有假装自己是生产级通用 LLM。它的边界写得很明白：TinyStories 任务、短文本生成、无事实知识、无指令跟随能力。
我很喜欢这种诚实。因为很多边缘 AI 项目最大的问题不是性能差，而是叙事太满。明明只是一个演示，却包装成“离线智能体”“私有化助手”“云端替代方案”。结果读者真拿去做产品，才发现上下文、任务泛化、稳定性、模型更新、安全边界全是坑。
ESP32-AI 的价值更接近一个工程样板：
- 如果任务分布足够窄，小模型可以有用；
- 如果权重访问模式足够稀疏，大容量参数可以放慢存储；
- 如果部署环境极端受限，架构设计比堆参数更重要；
- 如果你能接受任务边界，端侧离线推理会带来隐私、延迟和可用性收益。
这几个判断比“ESP32 能跑 LLM”更有意义。
对比我之前写过的 本地 LLM 推理选型：Ollama 与 llama.cpp 到底解决什么问题，那篇讨论的是个人电脑和小服务器上的本地推理；ESP32-AI 则把问题推到了更极端的端侧设备。两者共同点是：你不能只看模型名字，要看内存、部署、任务和运维约束。
Per-Layer Embeddings 为什么适合这种场景？
传统 embedding table 最大的问题是大。词表一大，embedding 参数量立刻膨胀。但在生成一个 token 时，模型通常只查很少一部分 embedding 行。既然如此，把巨大表常驻 SRAM 就很浪费。
Per-Layer Embeddings 的思路可以粗略理解为：把“可查表的知识容量”和“每步密集计算的小核心”拆开。小核心负责每一步都必须执行的计算，大表负责提供按需访问的表示容量。
在人话层面，它像把一本厚字典放进慢速存储。你不需要把整本字典背下来，只要查当前用到的几个词条。
这也是为什么它在微控制器上特别有吸引力。ESP32-S3 的 SRAM 太小，PSRAM 也不算快；但 flash 容量相对宽裕。只要每步访问量足够小，flash 的慢就可以被接受。项目 README 提到每 token 大约读取 6 行、约 450 字节，这个数量级让 flash table 变成“几乎可承受”的慢存储，而不是不可用的瓶颈。
当然，这不等于 PLE 适合所有模型。它依赖任务、结构和训练方式，也需要精心的量化与运行时实现。ESP32-AI 目前更像一个研究型工程原型，而不是可直接复用到任意 LLM 的通用方案。
这块我也不认为已经有定论。尤其是当任务从 TinyStories 扩展到指令跟随、工具调用、长上下文时，PLE 带来的容量是否能转化成可用能力，还需要更多实验。
速度数字要怎么看？
9.5 token/s 在云端推理里不算什么，但在 ESP32-S3 上并不低。关键是比较对象要正确。
如果目标是替代手机端 LLM，那它没有意义；如果目标是在极低成本、低功耗、无网络设备上做固定模式文本生成，9 token/s 已经到了可演示、甚至可嵌入某些非实时场景的水平。
firmware/esp32_llm/README.md 给了构建、刷写和 host verification 流程，代码也不只是一个网页 demo：仓库里有 src/、experiments/、firmware/、量化和验证脚本。GitHub API 显示这个仓库已有 1000+ stars，最近提交在 2026-07-26，项目真实性没有问题。
但我不会建议你把它当生产组件直接用。更稳妥的定位是：学习边缘模型部署、内存分层、4-bit 量化、嵌入式 runtime 的参考实现。
这和 Bonsai Image 的 1-bit 边缘图像生成 有点像：真正值得看的不是“效果能不能打败云端大模型”，而是它们如何围绕边缘设备约束重写模型设计。
它对生产系统有什么启发？
我觉得至少有三点。
第一，别把“端侧 AI”理解成把云端模型缩小一圈。真正有效的端侧模型通常不是同一架构的缩水版，而是围绕硬件约束重新设计。ESP32-AI 如果只是把一个普通小 Transformer 硬塞进芯片，大概率不会有这个效果。
第二，内存层级会成为模型架构的一部分。过去我们习惯把模型结构和硬件部署分开讨论：先训练模型，再想办法部署。现在越来越多项目反过来做：先看内存、带宽、功耗，再决定哪些参数密集计算、哪些参数稀疏访问、哪些状态可以缓存。
第三，小模型的价值来自任务边界，而不是幻想通用智能。ESP32-AI 用 TinyStories 做短故事生成，这个任务很窄，所以 28.9M 参数还有意义。如果换成开放域问答，模型能力会立刻露馅。生产系统也一样：与其问“小模型能不能替代大模型”，不如问“哪些固定任务根本不需要大模型”。
比如离线玩具、教育硬件、低成本传感器交互、断网环境的固定模板生成、设备本地提示解释，这些场景不要求模型懂世界，只要求它在有限分布里给出可接受输出。这里才是微控制器 LLM 的合理位置。
我的判断：这是路线信号，不是产品信号
ESP32-AI 现在还不是一个能直接商业落地的通用方案。它的模型能力窄，任务单一，距离可维护的端侧智能系统还有很多工程工作：数据更新、失败兜底、评测、功耗曲线、长期稳定性、用户输入安全，都没有被完整解决。
但它是一个很好的路线信号。
它提醒我们：下一阶段的 LLM 工程不会只是“更大的模型 + 更强的 GPU”。很多增量会来自更聪明的内存布局、更细粒度的参数访问、更贴近硬件的模型结构。云端如此，端侧也如此。
如果你做的是生产系统，我建议把 ESP32-AI 当作两个问题的参考答案：
- 当内存比算力更贵时，模型结构该怎么改？
- 当任务足够窄时，小模型能不能用架构技巧换来本地化部署？
它没有证明微控制器可以运行“真正的通用 LLM”。但它证明了另一件更务实的事：在极端约束下，模型工程还有很多空间，不只是压缩和量化这么简单。
我个人更愿意把它看成边缘 LLM 的一次“内存设计实验”。实验本身不完美，但方向很值得跟。