在 8 美元的 ESP32-S3 微控制器上运行 28.9M 参数大语言模型

在售价 8 美元的微控制器上运行 2890 万参数的大语言模型

28.9M-parameter LLM running on an ESP32-S3

这是一个拥有 2890 万参数的语言模型，能在 ESP32-S3 上生成文本，而后者是一款售价约 8 美元的微控制器。它完全在芯片本身上运行，不向服务器发送任何数据，并以大约每秒 9 个 token 的速度将每个词写到连接在芯片上的小屏幕上。此前人们在这类芯片上运行的语言模型只有 26 万参数，因此这个模型的参数量大约是其一百倍。它之所以能装得下，是因为模型的大部分存放在 flash 而非 RAM 中，借助了 Google Gemma 模型中的一个思路，叫做逐层嵌入向量（Per-Layer Embeddings）。

数据


参数	存储 2890 万（其中 2500 万存放在 flash 查找表中）
芯片	ESP32-S3，约 8 美元，配备 512KB SRAM、8MB PSRAM 和 16MB flash
速度	端到端约 9.5 tok/s（纯计算为 9.7 tok/s）
连接性	无，一切都在设备上运行
模型大小	4-bit 下为 14.9MB

为什么这件事很难，以及它究竟如何适配

微控制器拥有的快速内存非常少。ESP32-S3 只给你 512KB 的 SRAM。通常整个模型都必须能从这块内存中访问到，这就把你困在极小的模型上，也正是为什么此前在这类芯片上的模型只有 26 万个参数。

绕开这一限制的办法，是干脆不再把模型放进快速内存。语言模型的大部分参数都位于一张嵌入向量表中，模型是从中读取，而不是在其上进行计算。因此，你可以把这张 2500 万行的表留在慢速 flash 中，只在每个 token 需要时拉取那几行，大约 450 字节，而真正干活的那一小部分则留在快速内存里。这样一来，这个大模型的运行成本几乎为零，因为你从不会加载它的大部分内容。它只是待在 flash 里，一次被采样一点点。

这个思路就是 Google 的 Per-Layer Embeddings，来自 Gemma 3n 和 Gemma 4。在这里，它运行在微控制器的内存布局上，而不是手机或 GPU 上。据我所知，还没有人在这般小的芯片上尝试过它。

  SRAM  (fast, tiny)   the "thinking" core, used on every token
  PSRAM (medium)       the output head and working memory
  FLASH (huge, slow)   the 25M-param table, about 6 rows read per token (~450 B)

它能做什么，以及它不能做什么

该模型是在 TinyStories 上训练的，因此它会写简短、简单的故事，并且大多能保持连贯。它不会回答问题、遵循指令、编写代码，也不掌握事实知识。这一限制来自模型中负责推理的那一小部分，而记忆技巧并不会改变这一点。这里有趣的是其架构——把一个大模型塞进一块小小的芯片，而不是一个 2890 万参数的模型能说出什么。

自己动手运行

固件、接线和烧录步骤都在 firmware/esp32_llm/README.md 中。训练、消融和量化代码在 src/ 和 experiments/ 中。完整方法、消融实验以及片上测量结果都写在 RESULTS.md 中。

致谢

TinyStories 是它训练所用的数据集：简短的合成故事，简单到一个小模型也能学会连贯地写作（Ronen Eldan 和 Yuanzhi Li，Microsoft Research，arXiv:2305.07759）。另一半是 Per-Layer Embeddings，这是 Google 在 Gemma 模型中的设计，正是它让一个大模型能塞进一块小芯片。

Andrej Karpathy 的 llama2.c 正是让很多人（包括我）相信你可以训练一个小型语言模型并用纯 C 运行它的原因。这项工作就是从那里发展而来的。

实际经过如何

我故意把混乱的提交历史留在了仓库里。这包括我在自己的参数核算中发现的一个 bug——它曾让早期的一个数字被夸大——以及我修复后随之而来的更正结果。提交历史和 RESULTS.md 展示了这些数字在哪里发生了变化，以及原因。