导读开源项目 ESP32s3-LLM-Cluster 用七块 ESP32-S3，把经过裁词表与量化处理的语言模型按层分到不同开发板上。它展示了一条具体的微控制器推理路径：主板处理文本输入和输出，六块计算板顺序完成 Transformer 层计算。但作者同时说明，文档中的量化训练脚本尚未训练充分，验证输出可能像随机 token。本文沿着一次生成过程，拆开“装得下”“算得动”和“答得好”三件事，也解释为何不能把效果问题直接归因于量化。
本文 1865 字，阅读约 5 分钟｜七块板，分担的是什么 → 模型怎么塞进这些小板子 → 生成一个 token，要走完整条链 → 部署链路有了，回答质量还缺什么证据
七块板，分担的是什么
七块 ESP32-S3 摆在一块面包板上，彼此用导线相连。这个项目先解决一个具体的工程问题：一块微控制器放不下的模型权重，怎样拆开存放并接力计算？
ESP32s3-LLM-Cluster 的方案是一主六从。主板接收输入文字，完成分词和词嵌入；六块计算板各保存四层 Transformer 权重，合计负责 24 层。Transformer 层可以理解为模型反复加工当前文本信息的计算模块。计算板按层序串在一起，最后一块把结果送回主板，由主板计算下一个 token。token 是模型处理文本的基本单位，可能是一个字、一个词或词的一部分。
图片说明：项目仓库提供的七块开发板接线实物照。图片来源：ESP32s3-LLM-Cluster 官方仓库
这套设计不是让七块板同时各生成一段回答。每生成一个 token，都要让当前信息按顺序经过模型层，再由主板选出下一个 token。分板让六块计算板各自存放并执行四层；一个 token 仍要等待六块板依次算完。
模型怎么塞进这些小板子
项目以 Qwen2-0.5B 的结构为基础，先把原有词表裁到 3.2 万项，再处理相应的词嵌入。词嵌入是把 token 编号变成一组数字，供后续层计算的表。主板上的这部分用 INT4，也就是每个权重用约四个比特表示；项目文档估算其占用约 14 MB Flash。这里的 Flash 是断电后仍保存程序和权重的存储空间，不是运行时工作内存。
计算板上的线性层则采用三值量化，让权重取 −1、0、1 三种值。项目称之为 1.58-bit 路线：区分三种取值，理论上至少需要 log₂3≈1.58 位；仓库实际用两位固定编码一个权重，四个权重打包成一字节。量化把权重压小，才有机会将每四层约 15.3 MB 的数据放进一块计算板的 16 MB Flash。层所需的归一化参数和缩放信息仍另外保存，不能把整个模型理解成“所有东西都是 1.58 bit”。
这里还要分清两个数字：仓库简介使用“约 0.4B”，正文和操作文档写的是基于 Qwen2-0.5B 的裁剪模型。词表裁剪会改变参数组成，项目没有给出可供本文核对的最终精确参数统计。因此用“基于 Qwen2-0.5B、经过裁剪和量化”描述这套实验，比给它贴一个精确参数量更稳妥。
生成一个 token，要走完整条链
输入文字先由主板切成 token。主板查出当前 token 的词嵌入，得到一组数字，也叫隐藏状态；它把这组数字送到第一块计算板。第一块板执行自己负责的四层，再把更新后的隐藏状态传给下一块。六块板依次计算完，结果回到主板；主板做最后的归一化和输出映射，选出下一个 token。接着，新 token 再作为输入，开始下一轮。
板间通信采用 SPI，一种让芯片按时钟交换数据的接口。项目把板子接成串行路径，固件里也有收发隐藏状态、计算层和统计推理时间的代码。每块计算板还在 PSRAM 中维护自己的 KV cache：它保存此前 token 在注意力计算中要复用的信息，避免每一步都把整段历史从头算一遍。权重分片解决存储，KV cache 解决重复计算的一部分；两者都不会消除六块板顺序执行的等待。
项目文档称每个计算节点推理约需 1.3 秒，代码也提供 /bench 计时入口。不过，公开资料缺少完整的同条件运行日志；单节点时间不能直接换算成整机 token/s。评估体验还要看主板计算、通信、提示词长度和首 token 等待时间。
功耗也缺整机口径：文档中的计算节点由外部电源供电，主板由电脑供电，一组推理电压、电流与瓦数记录还无法直接对上。因此，现有数字不足以计算七块板的总能耗。
部署链路有了，回答质量还缺什么证据
装得下、算得动之后，还要看输出。项目作者在操作文档中明确提醒：文档所用的 qat_158.py 量化感知训练脚本只进行了部分训练，用 run_model158.py 验证时可能吐出无意义 token。这是当前示例训练方案的效果边界，不能据此判定所有三值量化模型都无法对话。
文档还列出重复同一词、词表缺口、节点层序烧录错误等排查情况。这些症状来源不同，不能看到乱码就断定是 SPI 坏了，也不能只因固件能输出 token 就认定模型已经会对话。这里要把两种“随机”分开：当前主板代码以温度 0.7 按概率选词，生成结果本来可能变化；作者指出的更严重问题，是示例训练后的文本可能没有意义。换一种选词方式，也不能替代训练和权重核对。
三值量化负责把权重压到硬件可以承受的范围。回答无意义的原因还需区分训练不足与实现错误，不能直接归咎于量化形式。词表从原模型裁到 3.2 万项，线性层做极低比特量化，再经过训练与打包；任一步的模型质量或编码一致性出问题，最终 token 都可能失去意义。仓库提醒，Python 端的三值打包顺序必须与 C/汇编端解包一致，否则权重会被静默读错。
校准到底在校准什么？从量化两大维度到 LLM 与边缘感知的硬件抉择
这也划出了项目当前最清晰的成果边界：它给出了一条可检查的七板分层部署与推理实现，以及准备权重、烧录和运行的步骤；文档点名的训练方案尚不能提供可用回答，公开资料也不足以证明板上运行能稳定完成有意义的问答。本文没有在七块板上独立复现，因此不把作者的硬件演示写成我们的效果测试。
如果后续要从“工程演示”走向“可用本地模型”，至少需要两类结果一起出现：同一份明确版本的模型，在固定提示上能持续给出可读、相关的输出；同一套硬件在说明测量条件后，公开完整的时延与功耗记录。前者验证模型质量，后者回答实际使用代价。只增加板子，无法替代其中任何一项。
七块 ESP32-S3 的价值，在于把“微控制器能否承载更大的语言模型”变成了可拆解的工程问题。看这类项目，我会先问权重怎么分、一个 token 怎么走，再看输出样例和同条件运行记录。分板部署解决了模型怎样装、怎样算；能否稳定回答，仍要看权重和实测结果。
参考资料
ESP32s3-LLM-Cluster 官方仓库架构说明： https://github.com/Low-Zi-Hong/ESP32s3-LLM-Cluster/blob/68c459a5d07fd963d748311cf33bb3202431db15/README.md
项目烧录、模型规格与已知限制： https://github.com/Low-Zi-Hong/ESP32s3-LLM-Cluster/blob/68c459a5d07fd963d748311cf33bb3202431db15/workflow.md
主板推理流程与计时入口： https://github.com/Low-Zi-Hong/ESP32s3-LLM-Cluster/blob/68c459a5d07fd963d748311cf33bb3202431db15/master_board/main/main.cpp
主板按概率选词的实现： https://github.com/Low-Zi-Hong/ESP32s3-LLM-Cluster/blob/68c459a5d07fd963d748311cf33bb3202431db15/master_board/main/lm_head.cpp
计算节点推理流程： https://github.com/Low-Zi-Hong/ESP32s3-LLM-Cluster/blob/68c459a5d07fd963d748311cf33bb3202431db15/node_board/main/main.cpp
— THE END —
文章仅做学术分享，如有侵权请联系删除，非常感谢！