Gemma

如果只看标题，“在 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 级别的表整块搬进快内存。 ...

如果你最近还在把“LLM 推理优化”等同于量化，我建议停一下。 量化当然重要，尤其是本地部署和消费级 GPU 场景。但 Google 刚发的 Gemma 4 多 token 预测（Multi-Token Prediction, MTP）让我更确信一件事：下一轮推理加速的主战场，不只是在“把模型压小”，而是在减少大模型被调用的次数。 Google 在官方博客里说，Gemma 4 通过 MTP drafters 在推理阶段最高可以做到 up to 3x faster。这个数字本身很抓眼球，但我更关心它背后的工程含义：如果草稿器能一次猜中多个后续 token，大模型就不必老老实实一个 token 一个 token 地跑完整前向传播。 说白了就是：以前是大模型每吐一个字都要“亲自审批”；现在是小模型先写一小段，大模型批量盖章。 为什么“一个 token 一次前向”这么浪费 自回归 LLM 的默认解码方式很朴素：给定上下文，预测下一个 token；把这个 token 拼回上下文，再预测下一个。这个循环看起来合理，但对硬件很不友好。 每生成一个 token，模型都要访问大量权重。对于 27B、70B 这种规模，瓶颈往往不是矩阵乘法算不动，而是显存带宽和调度开销被小步循环吃掉。你可以把它理解成：GPU 明明适合一次搬一大车货，结果我们让它每次只送一个快递。 这也是为什么我之前写 DFlash + DDTree 投机解码 时，最看重的不是某个 benchmark 数字，而是“平均接受长度”。只要一次验证能接受更多 token，大模型前向次数就会下降，吞吐自然上来。 Gemma 4 的 MTP 走的是同一条大方向，但实现路径更靠近模型训练本身。 传统 speculative decoding 通常需要一个独立的小 draft model。经典论文 Speculative Sampling 的思路就是：小模型先生成候选，大模型并行验证，最后用修正过的采样过程保证输出分布不变。这套方法很漂亮，但工程上有两个麻烦：你要维护两个模型，还要处理 tokenizer、KV cache、调度和显存布局。 MTP 的反直觉之处在于，它不一定非要靠“另一个完整小模型”来猜。Meta 的论文 Better & Faster Large Language Models via Multi-token Prediction 提出，在训练时让模型不只预测下一个 token，而是同时预测未来多个 token。技术上可以看成在共享 trunk 上接多个输出 head，训练目标从“只看一步”扩展到“顺手看几步”。 ...