Esp32-ai：把大模型塞进了微控制器

常识告诉你，微控制器跑不了大语言模型。ESP32-S3 这玩意儿就 512KB 的 SRAM，8MB 的 PSRAM，一张手机拍的生图都比它的内存大。之前确实有人在这类芯片上跑过语言模型，260K 参数，写个简单故事大概算顶天了。

但上个月有人把这个数字推到了 2890 万。

不是优化了 10%、20%，是直接翻了 111 倍。用的硬件还是同一块 ESP32-S3，售价不超过 8 美元。作者叫 Slava S.，GitHub 用户名 slvDev，乌克兰独立开发者，一个人写了整个项目。项目上线第三天就在 Hacker News 拿下了 200 多分，GitHub 上三天涨了 1200 多个 Star。

这件事最反直觉的地方在于，芯片本身没有任何性能提升。Slava 没换处理器、没超频、没加协处理器。他做的事情更根本：重新定义了”模型的哪些部分需要住在快内存里”。答案比你以为的少得多。2890 万参数里，实际参与推理计算的只有 55.9 万个，其余 2500 万个参数是一张嵌入查找表，躺在慢速的 16MB Flash 里，每个 token 只从中读取约 450 字节。

内存三级跳：为什么之前的尝试都撞了墙

传统 LLM 推理有一个硬约束：生成每个 token 都要对几乎所有参数做一次矩阵运算。所以模型必须整个待在快速内存里，不然延迟就是灾难级的。Dave Bennett 2024 年的 esp32-llm 项目跑到 260K 参数就是这个原因，再大内存装不下了。

Slava 没走这条路。他借用了 Google Gemma 3n 的逐层嵌入（Per-Layer Embeddings）技术，把模型按访问频率拆成了三层。

最快的一层是 512KB 的 SRAM，放密集推理核心。这个核心只有 55.9 万参数，4-bit 量化后 273KB，刚好塞进 SRAM。中间层是 8MB 的 PSRAM，放输出头，约 310 万参数，每个 token 顺序扫描一次。最慢也最大的那层是 16MB 的 Flash，放 2500 万参数的嵌入查找表，按需读取，每个 token 只访问 6 行左右。

这个三级存储结构的关键洞察是：绝大部分参数属于”存储”而非”计算”。就像厨房里厨师手边的刀具和远处储藏室的食材，不是所有东西都需要放在触手可及的地方。Google 在手机上首次应用了这个想法，Slava 把它移植到了微控制器的存储层级上。

数值上更直观。4-bit 量化后整个模型文件只有 14.9MB，写进一个 15.6MB 的 Flash 分区绰绰有余。ESP32-S3 N16R8 型号上，端到端生成速度约 9.88 tok/s，纯计算速度 9.72 tok/s，每步推理耗时约 102.9 毫秒。这个速度读起来不会觉得卡，在微控制器领域已经算奢侈了。

但有一个容易被误读的细节。很多人觉得瓶颈在 Flash 读取速度，实际上 Flash 读取 6 行嵌入数据只要 0.12 毫秒。真正费时间的是输出头，那个扫描 32768 个候选词的部分，占每次推理的 17 毫秒左右。这也是为什么 PSRAM 的带宽决定了最终吞吐，Flash 反而是便宜的。

你能让它做什么，不能让它做什么

Slava 在 README 里的表述罕见地诚实：“这个模型不会回答问题、不会遵循指令、不会写代码、不知道任何事实。”

这跟内存技巧没关系。训练数据决定了能力天花板。项目基于 TinyStories 数据集训练，这是微软研究院做的合成儿童故事数据集，句子简单、词汇量小、逻辑链短小，整个词汇表只有约 5000 个 token。它的设计目标就是让微型模型也能学到连贯的叙事能力。模型确实能写出还算通顺的小故事，但也仅限于此。训练代码和消融实验都在 research/tinystories/ 目录里，想自己训练的可以直接复用。

除了 Tinystories 故事模型，Slava 还发布了一个叫 Barista 的变体，用相同架构训练成咖啡知识问答。对，专门回答关于浓缩咖啡的问题。这听起来像开玩笑，但它不是在讲笑话。它展示的是同一个架构思路迁移到不同垂直领域的可行性。一台完全离线、不需要 App 的智能咖啡机，知道每种豆子、研磨度、水温和粉水比对风味的影响，这个场景离产品化其实不远。

至于跑起来要花多少钱？电费按每年 24 小时不间断计算，约 3.5 度电，成本不到半美元。对比一下，一块 RTX 3090 光是空载一年的电费就够买 70 多块 ESP32 开发板了。

动手跑起来

项目的部署脚本写得相当认真。下载和烧录是分开的，网络访问和板子操作互不干扰。

scripts/fetch_model.sh tinystories   # 下载模型、SHA-256 校验、安装到 artifacts/
scripts/deploy.sh tinystories        # 生成头文件、跑门禁、编译、烧录

fetch_model.sh 在安装任何文件前会先校验 SHA-256 和文件大小，校验不过就不写入。deploy.sh 完全离线工作，只读 artifacts/ 目录里的内容。两块板子一次只装一个模型，重复部署会覆盖。从下载到烧录的完整链路保护设计得很到位，每步都有校验门禁，不会出现半拉子部署。

硬件要求很明确：ESP32-S3 N16R8（16MB Flash、8MB 八进制 SPI PSRAM），CPU 跑 240MHz，编译优化级别 O3。换一个型号或者降低 PSRAM 模式，性能数字就得另算了。firmware/esp32_tinystories/README.md 里写了开机后串口输出的预期内容，对第一次上手的人比较友好。

常见卡点就那么几个。PSRAM 必须配置为八进制 SPI 模式，四进制模式下吞吐量不够。Arduino ESP32 core 版本要求 3.3.10 或更高。编译如果报错，先确认 ESP-IDF 工具链的版本匹配。模型文件一定要用脚本下载，手动拖 HuggingFace 的 release 文件会跳过校验环节。

适用场景与局限

不适合的情况同样明确。如果你想要的是一个能正常对话的 AI 助手，xiaozhi-esp32 这类基于云端大模型的项目更适合，25k+ Stars，生态成熟得多。如果你的目标是跑一个真正有用的本地 LLM，Raspberry Pi 5 或者带 NPU 的 Milk-V Duo 大概能给你好得多的体验，价格也没贵多少。

如果你只想验证 PLE 在微控制器上的可行性而手头没有硬件，research/tinystories/ 目录里有完整的训练、消融和量化代码，可以在 Python 环境下跑 Host Golden 验证，跟 PyTorch 的 32768 个 logit 逐位对齐。

社区健康度：一个人的闪电战

61 个 commit，全部来自 slvDev 一个人。这是典型的单人闪电战项目，代码质量、文档完整性、实验结果记录都远超这个规模的个人项目的平均水准，但可持续性完全取决于作者的兴趣和精力。

Hacker News 讨论里最尖锐的反驳是：差不多同样的钱可以买一块带 Linux 和 NPU 的开发板，跑一个真正能用的 1B 级别模型。这个批评在产品选型上是对的，但错过了要点。这个项目不是在论证 ESP32 应该替代树莓派，而是在论证”512KB 内存的芯片能不能通过重新设计模型的内存布局来跑一个结构上相当大的神经网络”。它的答案是一个有数据支撑的”能”。

作者在 RESULTS.md 里把自己发现的参数统计 bug 和修正过程原样保留了。这种透明度在一个两周大的项目里不常见。

这套玩法会改变什么

我一开始其实没太重视这个项目。毕竟一个连问题都回答不了的语言模型，放在 2026 年的 AI 语境里有点像个精巧的学术玩具。Hacker News 上有人管它叫”cute but useless”，这话半对。

对的地方在于直接应用价值确实有限。2890 万参数、TinyStories 训练集、不会回答问题，这些组合起来决定了它不可能成为任何人的日常工具。错的地方在于”无用以外的部分”可能比表面上看起来重要得多。

这个项目的核心贡献不是那个讲故事的小模型，而是一个设计范式：微控制器可以用远远超过其计算能力的参数规模来存储知识，前提是这些知识组织成稀疏条件访问的结构。Flash 里躺着的 2500 万参数不是死数据，是一种廉价的外部记忆。同样的思路在不同垂直领域可以做完全不同的事。一台真正懂咖啡的咖啡机。一个不需要网络的空调故障诊断芯片。一个能识别几百种植物病害的农用传感器。

换个角度看，之前业界对微控制器 LLM 的讨论默认假设是”模型必须全量驻留在快速内存里”。这个项目把这个前提拆了。它证明瓶颈不在 SRAM 容量，在 Flash 的读取速度和 PSRAM 的带宽。带宽比容量好优化得多，因为芯片工艺带来的带宽提升直接转化成了可用的模型规模上限。这意味着微控制器 AI 的扩展逻辑从”内存天花板”变成了”带宽经济性”，后者的曲线漂亮得多。

风险也摆在那。Bus Factor 等于 1，作者的个人时间投入决定了项目存亡。社区还没成型，贡献者数为零。如果你是个想在生产环境里赌这个方向的嵌入式团队负责人，我建议至少盯到有第二个独立复现报告出来再做决定。

但从技术趋势的角度看，PLE 在微控制器上的首次验证是一个值得跟的信号。过去两年 Espressif 一直在把 ESP32 从 Wi-Fi 芯片往 AIoT 芯片方向推，ESP-DL、ESP-SR、TFLM 的支持都在持续加码。硬件和软件工具的底盘在变好，差的是方法论的突破。esp32-ai 补上了这一块。

资源地址

总结

如果你已经在做嵌入式 AI 或者 IoT 产品，esp32-ai 最值得看的部分不是那个写故事的 demo，是 src/ 目录里的 C 运行时和 RESULTS.md 里的消融实验记录。前者是一套可复用的微控制器推理框架，后者告诉你哪些设计选择是必要的、哪些是冗余的。

如果你还在观望，关注两个信号：有没有人成功把这个架构迁移到非 TinyStories 的垂直语料上，以及作者有没有在接下来三个月内保持至少每周一次 commit 的频率。前者决定技术路线的可迁移性，后者决定项目存活的概率。

一块八美元芯片突破的其实不是参数规模，是”需要多少计算资源才能算有 AI”这个问题的默认答案。