8 美元的 ESP32-S3 跑起 28.9M 参数模型，但它不是一台缩小版 ChatGPT

一个开源项目把语言模型塞进了售价约 8 美元的 ESP32-S3。仓库给出的配置是 N16R8：512KB 内部 SRAM、8MB PSRAM、16MB Flash。模型储存参数约 2890 万个，端到端生成速度约 9.5 token/s，纯计算测得 9.72 token/s，全部在芯片本地完成，没有把文本发到服务器。

数字很容易让人误会。28.9M 并不等于一个 2890 万参数的通用大模型。项目把它拆成约 559K 的稠密核心、约 3.1M 的输出头，以及 2500 万参数的 Per-Layer Embeddings 表。核心放在 SRAM，较大的查找表放在 Flash，每个 token 只读取少量行。模型文件约 14.9MB，采用 4-bit 量化后塞进 16MB 分区，启动时把输出头放进 PSRAM。

这套设计借用了 Gemma 系列的 Per-Layer Embeddings 思路：并非所有参数都需要每一步以同样方式参与计算。对桌面 GPU 来说，把权重放在慢速存储里通常是坏事；对微控制器来说，Flash 比 SRAM 大得多，重新安排内存层级反而可能成为唯一可行的路。项目在真实芯片上测到 Flash 查表每 token 的成本约 0.12ms，占孤立带宽测试的约 0.7%；真正拖慢速度的是输出头读取 PSRAM 和标量计算。

项目作者也主动写了能力边界。模型在 TinyStories 数据集上训练，能写短小、连贯的故事，但不会回答问题、执行指令、写代码，也没有事实知识。它可以被称为「在微控制器上运行的语言模型」，却不能被包装成一个可以直接控制机器人的具身智能体。它没有视觉输入、动作空间、传感器闭环、工具调用或实时控制保证。

所以这条消息对具身智能的价值，不是「8 美元芯片马上替代机器人主控」。更实际的价值有两层。第一，边缘设备可以把一些极小的语言交互、状态解释或离线提示放在本地，减少网络依赖。第二，模型设计者可以开始把内存层级当作模型架构的一部分，而不是训练完模型再想办法压缩。对机器人来说，这种思路未来可能用于低风险的语音指令、设备自检、故障描述和本地策略索引，但那需要新的数据、接口和安全评测。

还有一条工程细节值得留意：作者修正过早期的参数统计，并把多个版本的速度写进 RESULTS.md。当前 9.5 token/s 是最新端到端结果，58 token/s 只是带宽上限，两者不应混用。SIMD 还没有使用，输出头仍受 PSRAM 带宽约束，下一步更可能是减少每 token 读取的字节数，而不是继续堆参数。

这类项目最容易被标题带偏。它证明的是「存储参数规模可以和高速内存容量脱钩」，不是「小芯片拥有了大模型的推理能力」。在具身系统里，后一个命题要靠闭环任务、延迟、功耗、掉线和安全测试来证明，不能用参数总数代替。

原文：

• 项目仓库：https://github.com/slvDev/esp32-ai
• 实验结果：https://github.com/slvDev/esp32-ai/blob/main/RESULTS.md
• TinyStories：https://arxiv.org/abs/2305.07759