一场租用 GPU 的接力赛以 200 美元训练出 NanoColibri 的 2.7B MoE

从头预训练一个语言模型通常意味着一个集群、六位数的算力账单，以及被雇来维持训练运行的人。一个新的开源项目给出的答案更简短。NanoColibri-Instruct 是一个 2.7B 参数的混合专家（Mixture-of-Experts）模型，每个 token 仅有 0.34B 活跃参数，它从随机权重变成一个可用模型只花了大约 180 到 260 美元，没有集群，贡献者轮流在租用的 GPU 上逐个训练。代码、检查点以及谁训练了什么的公开账本都存放在训练仓库中。

模型从来不是最终目标。该项目的文档将 Nano 定位为更大想法的环路验证（proof-of-loop）：模型的 int4 容器刻意大于消费级机器的内存，在固定的 RAM 预算下从 NVMe 流式加载专家。一台 16 GB 的笔记本电脑无法在内存中容纳 24 到 28B 的模型。在细粒度 MoE 中，每个 token 只触及稠密主干、一个常驻共享专家，以及几个 3 到 4 MB 的路由专家。用 LRU 缓存专家，让磁盘处理未命中。Nano 以犯错也不会造成损失的价格验证了整个流水线，包括 int4 导出。

架构与推理引擎 HYV3 的原生形态相匹配：24 层（1 层稠密、23 层 MoE），隐藏宽度 1024，64 个宽度为 512 的专家并采用 top-2 路由，一个永不离开内存的 2048 宽共享专家，4 倍分组查询注意力（grouped-query attention），每头带 QK 归一化，以及一个 sigmoid 加偏置的路由器。负载均衡遵循 DeepSeek-V3 的方案：按 gamma 乘以（目标减负载）的符号来微调每一层的专家偏置。

接力训练：Hub 上的比较并交换（compare-and-swap）

你无法像拆分代码库那样把顺序预训练拆分给志愿者。每一步都依赖前一步，因此整个训练过程存放在单个Hugging Face 模型仓库中：权重加优化器状态、training_state.json、RELAY.json、LEDGER.md，贡献者轮流操作：认领、拉取、训练一段、推送、释放。

冲突是必须做到万无一失的部分。如果两个人训练同一段，后推送的人会悄然毁掉一个 GPU 日。因此接力棒认领是一份租约，是与 Hub 之间真实的比较并交换（compare-and-swap），而非一种礼貌约定，训练期间通过心跳续租，这意味着被抢占的 spot 实例会自动释放接力棒。训练机器上的只读仪表盘显示损失、吞吐量、专家均衡度以及谁持有接力棒。

它奏效了：20,000 次更新，大约 5.2B token 的 FineWeb-Edu，然后是 1,500 次在 smol-smoltalk 上的聊天 SFT 更新，总计约 90 个 H100 小时。

有一个结果值得借鉴：即使推理时使用 top-1，训练时也要用 top-2 路由。在 top_k=1 时，路由权重坍缩为常数，路由器从 LM 损失中几乎得不到梯度，因此路由会冻结在随机初始化状态。top_k=2 通过两个胜者之间的竞争恢复梯度流动。推理时引擎仍然每个 token 只运行一个专家。无辅助损失的均衡在该规模下维持住了：死亡专家占比保持低位，负载保持健康，而残存的轻微路由偏斜正是流式缓存所喜欢的。

专家不均衡是 MoE 频谱另一端的同一种失败模式。Nous Research 的实地笔记在描述预训练 1 万亿参数模型时指出，核心挑战是路由器将不成比例的流量发送给某些专家，导致一些 GPU 空闲而另一些排队。NanoColibri 版的那个问题，只花了几百美元就得以应对。

5.4B token 能买到什么

这些数字都附有方法论。基准测试通过仓库内的、兼容 lm-evaluation-harness 的测试框架运行，使用相同的提示词和相同的评分方式，稠密参照模型也通过同一套代码运行，而非相信已发布的数据行。

模型	活跃参数	token 数	lambada	piqa	wino	arc-e	arc-c	obqa	hswag
NanoColibri (chat)	341M	5.4B	26.3	62.7	49.2	43.4	22.8	22.0	31.1
Pythia-410M @ step3000	405M	6.3B	26.3	59.8	50.9	41.3	18.8	15.6	27.0
Cerebras-GPT-256M (final)	256M	5.1B	29.3	61.3	51.1	41.0	17.0	15.8	27.4

NanoColibri 在两个基线上都赢了 7 项中的 5 项，在 LAMBADA 上与 Pythia 打平，在 WinoGrande 上处于噪声范围内（±1.4，n=1267）。这些注意事项是公开的。Pythia 检查点只运行了其学习率调度的大约 2%，这对其不利；完全退火的 Cerebras-GPT-256M 那行是保守的比较，而 Nano 同样赢了。LAMBADA 的落后看起来至少部分是一个数据伪影：FineWeb-Edu 基本上不含虚构类文本，而 LAMBADA 是用小说构建的。

该项目对结果的解读是克制的：在这个预算下，一个 2.7B 总参数的 MoE 表现得像一个 300 到 600M 级别的优秀稠密模型，总参数数量带来了相对于两个 token 匹配的稠密基线的真实优势。与 SmolLM2 级别的数字之间的差距是三个数量级的数据，而非架构。

两个尴尬的教训

第一个是页缓存陷阱。为了“测量”流式加载，团队在一台租用的服务器上给推理引擎设置了远小于容器内存的 RAM 预算，结果在比容器小五倍的预算下仍得到可疑的平稳速度。服务器的 RAM 远大于 1.2 GB 的容器，因此操作系统页缓存悄然支撑了每一次未命中。那些运行从未触及磁盘；它们刻画的是引擎的缓存记账。真正的磁盘压力数字需要在硬件上施加内存上限的 cgroups，且团队承认，还需要一个更大的容器。此后在速度测试框架中发现的一个基准测试缺陷，就是这篇文章没有任何 tokens/s 声明的缘故。以 200 美元的代价学会测量纪律，要划算得多。

第二个是耗尽了的余弦。固定到步数目标的余弦学习率调度在到达目标时已经耗尽，没有余量继续借助动量训练。后续运行使用 WSD（warmup-stable-decay，预热-稳定-衰减）：一个适合接力段的漫长稳定阶段，在团队选定的时机一次性衰减。

下一步：一次 7B 预演，然后是一个 24 到 28B 的容器

NEXT_MODEL.md 中的路线图有两个阶段。Colibri-Micro：总共 7B，1B 活跃参数，100B token，以代码为主的混合数据，先 SFT 再对代码做 RLVR，以及一个真正足够大的容器, , int4 下 3.8 GB, , 用于在目标笔记本电脑上测量真实的磁盘流式加载。然后是 Colibri-Grande，总共 24 到 28B，约 2.4B 活跃参数，其容器刻意超订一台 16 GB 笔记本电脑的内存。Grande 的专家数量只有在 Micro 的实测未命中和速度曲线存在之后才会冻结。一切都开源发布：权重、数据配方、训练代码、接力协议、基准 JSON、账本。

Nano 是自掏腰包支付的。下一阶段需要几千个 H100 小时，按市场价大约 9,000 到 12,000 美元，作者正在申请算力资助。200 美元的环路验证已经完成。它标出的那些教训, , 页缓存和耗尽了的余弦, , 恰恰是一次 9,000 美元的训练无法承受从头去学的。