论文综述:SMELT——把 MoE 的中间一半层跑两遍,在三重预算全对齐下省下 6.8% 到 18.0% 训练算力
SMELT: Scaling Laws for Compute-Matched MoE Looped Transformers
📄 查看原文 →一、论文是干什么的?
想象你在读一本很难的书。有两种办法能读得更透:一是把书读得更厚——去找一本页数更多、讲得更细的版本;二是把同一章翻回去再读一遍。第二种办法不需要买新书,但会多花时间。
深度学习里也有完全对应的两条路。Transformer 模型由一层层「积木」堆起来,想让它「想得更深」,标准做法是加更多层(买更厚的书);另一条路叫 Looped Transformer(循环 Transformer),意思是不加新层,而是让同一组层被重复执行多次(同一章翻回去再读)。这条路从 2019 年的 Universal Transformer 开始,一直有人研究,近两年在数学、多跳推理、算法任务上刷出了不少亮眼结果:论文引用的多项工作显示,循环模型能匹敌甚至超过参数量数倍于它的普通模型。
问题在于——这些「亮眼结果」很可能是作弊来的。论文在引言里一针见血地指出:把一个 12 层模型循环成 24 次执行,确实只存了一半的权重,但它每个 token 花掉的算力(FLOPs)几乎等同于一个真正的 24 层模型,需要的 KV cache 也是 24 层的量。既往研究大多只固定「存了多少参数」,却任由算力和显存悄悄翻倍,于是「架构上的优势」和「偷偷多花的算力」就混在了一起分不清。
这篇来自清华大学、ByteDance Seed、M-A-P 与 TokenWave.AI 的论文,就是要把这笔账彻底算清楚。作者做了一件此前没人做过的事:同时锁死三项预算——每 token FLOPs、非嵌入总参数量、KV cache——再来比循环到底有没有用。答案是肯定的:他们提炼出的配方叫 SMELT(Sparse MoE Transformer, middle layers Loop Twice,即「把中间层循环两遍的稀疏 MoE Transformer」),在四个规模档位、四档稀疏度上全面胜出,一路做到 54B 非嵌入参数,在算力最优前沿上节省 6.8% 到 18.0% 的训练 FLOPs。更有意思的是机理层面的发现:第二遍执行会让 attention sink(注意力汇聚点)几乎消失,把注意力从「无意义的开头符号」重新拨回到真正有信息的内容 token 上。
二、核心方法与创新
2.1 什么是 Looped Transformer:把同一段路走两遍
先用最朴素的比喻。一个 30 层的 Transformer,就像一条有 30 个工位的流水线,每个工位有自己的一套工具(参数),每个 token 从头走到尾,被加工 30 次。
Looped Transformer 的做法是:挑出中间的某几个工位,让产品在这几个工位上来回走两遍。 比如 30 层里挑出第 8 到第 22 层(正好是中间一半),token 走完这 15 层之后,不直接往下走,而是带着已经加工过一轮的状态,再回到第 8 层重新走一遍这 15 层,然后才继续到第 23 层。
关键点在于:这 15 层的工具(权重)是完全共享的——不是复制了两套,而是同一套用了两次。所以:
- 存储的参数没有增加(还是 30 层的权重);
- 实际执行的层数变成了 45 层(30 + 15),论文管这叫有效深度(effective depth);
- 但算力和 KV cache 也按 45 层来算,这就是那笔被人忽略的账。
为什么走两遍会更聪明?直觉上,第一遍读的时候你只有零散印象,第二遍再读时你已经带着「上下文」了,能看出第一遍看不出的关联。论文第 6 节的实证结果恰好支持这个直觉:第二遍并不是推翻第一遍重来,而是沿着第一遍指出的方向继续加力——两次写入残差流的方向余弦相似度平均高达 0.56(同层跨遍),而不同层之间只有 0.16。作者的结论是:循环更像一次精修(refinement),而不是单纯加容量。
2.2 什么叫「预算对齐」:为什么以前的比较不公平
这是全文最核心的方法论创新,值得掰开讲。
假设有两位厨师做同一道菜,比赛谁做得好吃。裁判只规定了一条:食材成本必须一样。于是甲厨师老老实实用 100 元食材、烧 30 分钟;乙厨师也用 100 元食材,但烧了 90 分钟,还额外占用了三个灶台。乙做得更好吃——这能说明乙的手艺更好吗?显然不能,他只是多花了燃气和灶台。
过去比较循环模型和普通模型,犯的就是这个错:只对齐了「食材成本」(参数量),却放任「燃气」(算力 FLOPs)和「灶台」(KV cache)翻倍。
论文明确指出,一个公平的比较必须同时锁死三项预算,因为它们各自约束着现实中的不同资源:
| 预算项 | 它决定了什么 | 生活化理解 |
|---|---|---|
| 每 token FLOPs | 训练和推理的算力成本 | 烧了多少燃气 |
| 非嵌入总参数量 | 模型能记住多少知识 | 用了多少食材 |
| KV cache | 部署时能服务多长的上下文 | 占了几个灶台 |
难点在于这三项互相打架:循环让 FLOPs 涨了,你就得把模型「变瘦」(缩小隐藏维度 )来补回去;可一变瘦,参数量和 KV cache 又掉下来了。
MoE(Mixture-of-Experts,混合专家)架构正是解开这个死结的钥匙。 MoE 的特点是:模型里存了一大堆「专家」子网络,但每个 token 只激活其中很少几个(本文统一是 top-8)。这就让总参数量和每 token 算力这两件事解耦了——你可以往里塞更多专家来涨参数量,而每 token 花的算力几乎不变。
于是论文的对齐配方是三步走:
- 缩窄隐藏维度 ,把循环多花的 FLOPs 省回来;
- 增加每层的专家数量,把缩窄导致的参数损失补回来;
- 调整注意力头的尺寸和 GQA 分组比例,把 KV cache 拉回原位。
论文给了一个具体例子(200M 档、):Baseline 是 12 层、、每层 192 个专家,每 token 训练 FLOPs 为 ,非嵌入总参数 。SMELT 把中间 6 层循环两遍(共执行 18 层), 从 1280 缩到 1056,每层专家从 192 涨到 288。最后落点是:FLOPs (+2.9%),总参数 (+0.4%),KV cache 偏差在 4% 以内。全部 12 个稀疏网格单元里,最大绝对偏差是 FLOPs 3.9%、总参数 1.0%、KV cache 3.6%。
这样一来,两个模型之间剩下的差距,才能被归因到架构本身。
2.3 三次消融实验,锁定 SMELT 配方
在 200M 档上,作者做了三组消融,每组都在预算对齐的约束下重新配平超参:
(1)循环哪些层? 固定 12 层物理深度,让中间连续的一段循环两遍,段长从 0(即 Baseline)扫到 12(整栈循环)。结果在两档稀疏度下,验证损失都在 50% 跨度(即循环中间 6 层)处取到最小:
(下表为摘录,原文完整扫描还含循环 2 层/17% 跨度与循环 10 层/83% 跨度两行,二者在两档稀疏度下均劣于 50%)
| 循环层数 | 跨度 | 有效层数 | 验证损失() | 验证损失() |
|---|---|---|---|---|
| 0(Baseline) | 0% | 12 | 1.9445 | 1.8735 |
| 4 | 33% | 16 | 1.9275 | 1.8524 |
| 6 | 50% | 18 | 1.9257 | 1.8517 |
| 8 | 67% | 20 | 1.9374 | 1.8544 |
| 12 | 100% | 24 | 1.9322 | 1.8601 |
作者解释:首尾层承担着专门化的角色(读入与输出),更适合拥有独立参数;中间层才是最适合被重复的部分。这与多项前人工作的结论一致。
(2)多深多宽? 循环模型偏好更大的有效深宽比。Baseline 的验证损失在物理深度 12 时最优(1.9445),而循环模型在「物理 12 层 / 执行 18 层」时最优(1.9257)。作者的假设是:共享层会从多个访问位置同时收到梯度信号,其中较晚的那次访问离输出更近、路径更短,这种多深度的梯度信号让额外的串行计算比同等深度的独立参数层更容易优化。
(3)循环几遍? 两遍最好。三遍、四遍都会退步——因为 FLOPs 上限被锁死,循环越多次,模型就被逼得越瘦:
| 模型 | 有效深度 | 验证损失 | DCLM Core |
|---|---|---|---|
| Baseline(1 遍) | 12 | 1.9445 | 24.92 |
| 循环 2 遍 | 18 | 1.9257 | 27.57 |
| 循环 3 遍 | 24 | 1.9385 | 27.15 |
| 循环 4 遍 | 30 | 1.9360 | 27.30 |
论文特别提到,另一项并行工作(Gao 等,在 6B 与 20B 上按 wall-clock 对齐)独立地也得出了「两步循环最优」的结论,与本文相互印证。
三条规则合起来就是 SMELT:循环中间一半的层、给循环模型更大的有效深宽比、只循环两遍。 此外还有一个实现细节:循环跨度内每个子层的残差更新都会被缩放 ( 是循环次数,本文 ),以防止权重共享带来的相关更新把残差流「吹大」。
2.4 什么是 attention sink,为什么削弱它是好事
Attention sink(注意力汇聚点)是自回归 Transformer 里一个出了名的怪现象:大量注意力权重会毫无理由地堆积在序列最开头的那几个 token 上(通常是 BOS 起始符),无论它们语义上多么无关紧要。
打个比方:一个学生在做阅读理解,题目要求他从文章里找出关键信息。但你观察他的眼球轨迹,发现他有一大半时间在死盯着试卷左上角的页码。页码当然没有任何信息量——他只是「不知道该看哪」的时候,眼睛需要一个地方停靠。研究者的主流解释也接近这个意思:softmax 强制注意力权重加和为 1,模型总得把权重分给某个地方,于是就找了个「垃圾桶」倾倒多余的注意力。
削弱 attention sink 为什么是好事?因为被倒进垃圾桶的注意力就是被浪费掉的注意力。如果模型能把这部分权重从页码上收回来、投到真正相关的内容 token 上,它读到的信息量就实打实地增加了。
论文第 6.4 节用 Dyck 语言(括号匹配任务)做了一个漂亮的案例研究。这个任务的特点是答案完全无歧义:要闭合一个括号,模型必须从提示里的示例中检索出对应的开括号。作者先用消融法找出「Dyck 头」(删掉后让 Dyck 困惑度上升最多的那个注意力头),再画出它的完整注意力图。结果是:
- 第一遍:注意力大量集中在段首的 BOS 汇聚点上,「好像模型还不知道该往哪儿看」;
- 第二遍:汇聚点几乎消失,注意力质量搬到了提示里的示例答案上。
具体数字:对三个预测目标取平均,BOS 上的注意力质量从 0.60 掉到 0.02,而示例答案上的质量从 0.24 升到 0.85——汇聚点丢掉的,几乎精确地等于示例得到的。
更值得注意的是,这个现象反转了通常的深度趋势。在普通 Transformer 里,attention sink 是越深越强的(有多项工作证实)。但在同样的物理深度上比较,SMELT 的第二遍访问的 sink 质量始终低于第一遍,尽管它在执行顺序上位置更靠后。作者在 1M token 的留出样本上重复测量,确认这个 sink 削弱现象在几乎所有头和层上普遍成立,不只是 Dyck 这一个受控任务。
2.5 第二遍到底在做什么:四组机理探针
论文用四组测量刻画了「第二遍」的内部行为:
| 探针 | 问题 | 发现 |
|---|---|---|
| 专家路由重合度 | 两遍选同一批专家吗? | 时几乎复用全部 8 个; 时只复用 2 到 3 个,但仍远高于随机路由的期望值——路由器刻意复用一个核心子集,其余则分散开 |
| 残差写入幅度 | 第二遍写得更多还是更少? | 全部 16 个网格单元里,四种范数比值全部大于 1(范围 1.2 到 3.5 倍)——第二遍在每个组件上都写得更多 |
| 残差写入方向 | 是覆盖还是叠加? | 同一物理层跨遍的余弦为 0.42 到 0.65(均值 0.56),远高于非同层配对的 0.16——第二遍放大第一遍,而非推翻它 |
| 注意力各阶段 | 看的地方变了还是读的内容变了? | Q 和 K 的跨遍余弦为 0.89 到 0.93(不低于输入本身的 0.84 到 0.93),而 V 掉到 0.65 到 0.74, 与输出 进一步发散——「看哪里」保持不变,「读到什么」变了 |
还有一个离散层面的验证:每个头在两遍中的 top-8 被关注 token 集合重合度为 56% 到 66%,而「换一个头」的对照组只有 28% 到 34%。要知道这是从最多 4096 个位置里挑 8 个,能重合一半以上是很强的信号。
三、使用了哪些模型和计算资源?
3.1 模型:从零预训练的自研 MoE 家族
这不是在开源模型上做微调,而是从零开始的对照预训练实验。 论文明确说明模型建立在一个专有(proprietary)Transformer 家族之上,完整架构与训练栈无法公开,只披露与对照比较直接相关的量:模型规模、隐藏维度、物理深度、专家数、激活参数量、非嵌入参数量、算力等效稀疏度。
共同架构设定:decoder-only Transformer,前馈层为稀疏 MoE,每层路由到 top-8 专家,注意力使用 GQA(grouped-query attention),归一化用 RMSNorm。
网格是 4 个规模档 × 4 个稀疏度档 = 16 个单元,每个单元训练一对对齐好的 Baseline / SMELT。规模档以 Baseline 的激活非嵌入参数量命名:100M / 200M / 600M / 1.6B,对应物理深度 。
Baseline 全部 16 个配置:
| 规模档 | 总专家数 | 激活专家 | 激活参数 | 稀疏度 | 非嵌入总参数 | ||
|---|---|---|---|---|---|---|---|
| 100M | 672 | 10 | 8 | 8 | 0.100B | 0.0% | 0.10B |
| 100M | 672 | 10 | 64 | 8 | 0.100B | 86.0% | 0.71B |
| 100M | 672 | 10 | 192 | 8 | 0.101B | 95.2% | 2.12B |
| 100M | 672 | 10 | 336 | 8 | 0.102B | 97.2% | 3.70B |
| 200M | 1280 | 12 | 8 | 8 | 0.207B | 0.0% | 0.21B |
| 200M | 1280 | 12 | 64 | 8 | 0.207B | 84.3% | 1.32B |
| 200M | 1280 | 12 | 192 | 8 | 0.209B | 94.6% | 3.87B |
| 200M | 1280 | 12 | 336 | 8 | 0.212B | 96.9% | 6.74B |
| 600M | 1792 | 20 | 8 | 8 | 0.663B | 0.0% | 0.66B |
| 600M | 1792 | 20 | 64 | 8 | 0.665B | 84.5% | 4.28B |
| 600M | 1792 | 20 | 192 | 8 | 0.670B | 94.7% | 12.54B |
| 600M | 1792 | 20 | 336 | 8 | 0.675B | 96.9% | 21.83B |
| 1.6B | 2304 | 30 | 8 | 8 | 1.629B | 0.0% | 1.63B |
| 1.6B | 2304 | 30 | 64 | 8 | 1.632B | 84.5% | 10.55B |
| 1.6B | 2304 | 30 | 192 | 8 | 1.641B | 94.7% | 30.94B |
| 1.6B | 2304 | 30 | 336 | 8 | 1.651B | 96.9% | 53.89B |
SMELT 全部 16 个配置(循环配置一律是「中间 50% 跨度、执行 2 遍」):
| 规模档 | 总专家数 | 激活专家 | 激活参数 | 稀疏度 | 非嵌入总参数 | FLOPs 比值 | KV 比值 | ||
|---|---|---|---|---|---|---|---|---|---|
| 100M | 576 | 10 | 16 | 8 | 0.071B | 0.0% | 0.10B | 1.081 | 1.018 |
| 100M | 576 | 10 | 96 | 8 | 0.067B | 86.8% | 0.71B | 1.024 | 0.964 |
| 100M | 576 | 10 | 288 | 8 | 0.069B | 95.5% | 2.12B | 1.031 | 0.964 |
| 100M | 576 | 10 | 504 | 8 | 0.070B | 97.4% | 3.70B | 1.039 | 0.964 |
| 200M | 1056 | 12 | 16 | 8 | 0.142B | 0.0% | 0.21B | 1.039 | 1.031 |
| 200M | 1056 | 12 | 96 | 8 | 0.140B | 84.6% | 1.32B | 1.021 | 1.031 |
| 200M | 1056 | 12 | 288 | 8 | 0.142B | 94.7% | 3.89B | 1.029 | 1.031 |
| 200M | 1056 | 12 | 504 | 8 | 0.145B | 96.9% | 6.78B | 1.037 | 1.031 |
| 600M | 1408 | 20 | 16 | 8 | 0.458B | 0.0% | 0.67B | 1.046 | 1.031 |
| 600M | 1408 | 20 | 96 | 8 | 0.443B | 85.1% | 4.31B | 1.007 | 1.031 |
| 600M | 1512 | 20 | 288 | 8 | 0.453B | 94.7% | 12.44B | 1.024 | 0.984 |
| 600M | 1512 | 20 | 504 | 8 | 0.459B | 96.9% | 21.70B | 1.031 | 0.984 |
| 1.6B | 1848 | 30 | 16 | 8 | 1.101B | 0.0% | 1.64B | 1.022 | 0.984 |
| 1.6B | 1848 | 30 | 96 | 8 | 1.081B | 84.6% | 10.45B | 1.000 | 0.984 |
| 1.6B | 1848 | 30 | 288 | 8 | 1.091B | 94.8% | 30.90B | 1.004 | 0.984 |
| 1.6B | 1848 | 30 | 504 | 8 | 1.103B | 97.0% | 53.90B | 1.008 | 0.984 |
几个可以直接读出来的要点:
- 最大规模档是 1.6B 激活参数、53.90B 非嵌入总参数,这就是摘要里说的「scale up to 54B non-embedding parameters」。
- SMELT 一律比 Baseline 更窄(如 1.6B 档 从 2304 降到 1848),但专家数翻了 1.5 倍(336 到 504),这就是「缩宽度、加专家」的对齐操作。
- 被循环的层是: 时第 3 到 7 层, 时第 4 到 9 层, 时第 6 到 15 层, 时第 8 到 22 层(1-based 索引)。
- 600M 档在不同稀疏度下用了不同的 ( 与 85% 用 1408,95% 与 97% 用 1512),因为预算对齐需要联合调整宽度、专家中间维度与注意力头几何。
3.2 训练 token 数与训练配方
- 优化器:AdamW,学习率调度用 WSD(warmup-stable-decay)。
- 稳定阶段:恒定学习率训练 196,075 步,全局 batch 256 条序列(约 每步 1M token),合计消耗 205B token。
- 从每条稳定运行上,在第 10,000 / 20,000 / 50,000 / 100,000 / 150,000 / 196,075 步各分叉出一条 cosine 衰减分支,每条分支再训 10B token(取自稳定阶段未见过的新数据,无重复数据)。因此最长的一条分支累计约 215B token。
- 这样一条运行就给出 6 个 token 视界,用来拟合 scaling law 的数据轴。
- 序列打包到 4096 token 上下文,用 segment 级注意力掩码(每个 segment 是打包上下文里的一篇文档)。
- 预训练语料是内部语料库(具体构成未披露)。留出验证集覆盖 39 个来源,归为 Code / Math-STEM / Knowledge / Finance / Web 五大类。
- 同一规模同一稀疏度下的 Baseline / SMELT 配对在完全相同的 token 序列上训练。
- 训练前已从语料里过滤掉已知的评测题目,防止污染。
总计:32 次训练运行, 对配对的 Baseline / SMELT,192 个评测端点。
3.3 计算资源与耗时
GPU 型号、卡数、GPU 小时数:论文中暂无相关信息。 论文只在实现说明里表示训练栈是专有的、无法公开;结论部分还特意声明「我们的预算对齐等同的是算术 FLOPs、参数量与 KV cache 大小,而非 wall-clock 成本」,并承认串行的块重执行与稀疏路由可能带来硬件效率上的差距,需要系统层面的优化来弥合。
论文给出的是硬件无关的 FLOPs 口径,这是可以确定引用的「计算单位」:
- 进入 scaling law 拟合的 144 个端点(Baseline 与 SMELT 各 72 个,来自 、、 三档)覆盖 到 累计训练 FLOPs,这也是拟合曲面被支撑的窗口。
- 单 token 口径的例子:200M 档、 的 Baseline 每 token 训练 FLOPs 为 ,SMELT 为 。
- 论文强调这里的 是在打包 4096 token 上下文中的平均文档长度上实测的每 token 训练 FLOPs,包含随长度增长的注意力开销,因此高于常用的 近似。
- 至于「训一个 54B 档位要多少 GPU 小时」,论文没有报告——暂无相关信息。
另外,论文自陈的一个限制是:由于算力约束,三组设计消融都只在 200M 档(最多 3.9B 非嵌入参数)上完成,更大规模下最优的循环跨度或次数可能不同。
四、实验结果
4.1 先说清楚:scaling law 是什么,那 6.8% 到 18.0% 怎么算出来的
Scaling law(规模化定律)说白了就是一条外推曲线:你训几十个大小不同、数据量不同的小模型,把「损失」对「模型大小」「数据量」画成一条公式,然后用它去预测:如果我把算力堆到更大,损失会掉到多少?这样就不用真的烧钱训超大模型才知道结果。
最经典的形式是 Chinchilla 的加性形式 ,三项分别是:不可约损失 (数据本身的熵,再多算力也降不下去的地板)、容量项(模型太小造成的损失)、数据项(数据太少造成的损失)。
但 MoE 模型有个麻烦:总参数量 不能反映一个 token 实际激活了多少参数,一个 轴同时描述稠密模型和稀疏模型是不够的。所以论文把 换成实测的每 token FLOPs ,并用第 3.1 节定义的算力等效稀疏度 来缩放容量项:
(这里 ,其中 , 与 来自一个「全部专家都激活」的对照模型。稀疏度越高,同样的每 token 算力就存下越多总参数,所以容量项越小。)
关键设计:两种架构各自独立拟合一套 6 个系数,没有任何共享的「循环指示变量」。 拟合用同一套 Huber 损失()在对数损失上做 L-BFGS-B 最小化,两边程序完全一致——因为 compute-optimal 的结论对拟合方法非常敏感。 这一档因为「体制」差得太远、加进去反而恶化稀疏网格的 RMSE,被排除在拟合之外。需要说明的是, 只是本文稀疏度网格的最低档而非真正的稠密模型——原文特意澄清,与它对齐的循环模型仍是 16 专家取 top-8。
拟合出来的系数:
| 架构 | RMSE | ||||||
|---|---|---|---|---|---|---|---|
| Baseline | 1.4439 | 0.3703 | 0.1530 | 0.6594 | 0.00554 | ||
| SMELT | 1.4493 | 0.3892 | 0.1460 | 0.7011 | 0.00952 |
两个指数 (容量指数)和 (数据指数)都是 SMELT 更大,意思是它的可约损失沿着算力轴和数据轴都掉得更快。
接下来算「省了多少算力」,一共三步:
第一步,求算力最优前沿。 给定总算力预算 ,你要把它劈成「每 token 花多少 FLOPs(,等价于模型多大)」和「训多少 token()」两半。容量项和数据项是互相拉扯的: 越大容量项越小,但留给 的就越少、数据项越大。求这个折中的极小值,得到最优的每 token FLOPs:
代回去得到「在预算 下能达到的最低损失」,其中前沿指数 。
算出来:,,SMELT 高 5.5%。这个指数控制着「每多花一份算力,损失掉得有多快」——SMELT 的前沿更陡。
第二步,横着量而不是竖着量。 这就是 CE Gain(compute efficiency gain,算力效率增益)的定义,也是衡量「算法进步」的标准视角:不问「同样算力下损失低多少」,而问「要达到同样的损失,我能少花多少算力」。三步走:
- 在预算 下算出 SMELT 前沿的损失值;
- 反解 Baseline 的前沿,找出它要达到同一个损失值所需的预算 ;
- 算省下的比例:
第三步,代入具体预算。 结果就是摘要里那两个数字的来源:
| SMELT 预算 | |||
|---|---|---|---|
| FLOPs | 10.0% | 7.8% | 6.8% |
| FLOPs | 18.0% | 15.8% | 14.7% |
| FLOPs(外推) | 23.5% | 20.9% | 19.6% |
所以「6.8% 到 18.0%」这个区间,正是拟合窗口内 与 两档、三个稀疏度共六个格子的最小值和最大值。 最小的 6.8% 出现在 FLOPs、;最大的 18.0% 出现在 FLOPs、。 那一行标了「外推超出拟合窗口」,所以不计入摘要口径。论文还为每个格子报告了 95% 置信区间( 一行依次为 [1,22]、[3,15]、[4,14]; 一行为 [8,28]、[10,25]、[8,25]; 一行为 [8,42]、[0,48]、[0,51]),区间相当宽。这些区间来自格子级 bootstrap:把 12 个稀疏网格单元有放回地重采样、每次重拟合两套曲面,做 2000 次后取 2.5 和 97.5 分位数。
两个值得注意的读法:
- 收益随算力增长而扩大(每从 到 ,每列大约 +8 个百分点),这是 的直接后果——两条前沿在拟合区间内是越拉越开的。
- 稀疏度影响的是收益的「水平」而不是「增速」: 收益最大,是因为容量项里的 因子把差距放大了,而不是因为差距扩大得更快。
还有一个实用结论:两种架构想要的算力分配几乎一样。 在 下,每个稠密等效参数分到的 token 数(TPP)为:
| Baseline TPP | SMELT TPP | |
|---|---|---|
| 56 | 56 | |
| 78 | 75 | |
| 91 | 86 |
SMELT 的点估计与 Baseline 相差都在 6% 以内,bootstrap 区间几乎完全重叠。原因是:SMELT 的数据系数 更大(在小 时更吃亏)而数据指数 也更大(在大 时掉得更快),两个效应把最优分配往相反方向拉、大致抵消了。换句话说,SMELT 省算力靠的是「在同样的分配下达到更低的损失」,而不是靠「重新分配预算」。 顺带一提,两种架构的 TPP 都远高于 Chinchilla 对稠密模型报告的约 20,这与稀疏 MoE 偏好更多 token 的既有结论一致。
4.2 下游任务:收益比验证损失预测的还多
先看胜负记录(96 对配对):
| 指标 | SMELT 胜出 |
|---|---|
| DCLM Completion(越低越好) | 96 / 96 |
| DCLM Core(越高越好) | 83 / 96 |
| MMLU(限定 Baseline 高于随机基线 10 个百分点以上的配对) | 29 / 30 |
但作者说,这些胜率只是在复述第 4 节——一个验证损失更低的模型,本来就该在任何跟验证损失相关的评测上更好。真正的问题是:下游提升是「刚好等于」损失下降应有的量,还是「超出」了?
为此他们做了一个巧妙的残差分析:用全部 96 个 Baseline 端点拟合一条「从验证损失到评测分数」的四参数单调 sigmoid 校准曲线(拟合非常紧:DCLM Completion 、DCLM Core 、MMLU ),然后看 SMELT 的点偏离这条曲线多远。
结论是:三个评测、四个规模档,平均残差全部为正,即 SMELT 的下游表现超出了一个「达到相同验证损失的 Baseline」应有的水平。而且这个超出量在 DCLM Completion 和 DCLM Core 上随规模单调增大,MMLU 上两个大档也高于两个小档。按 DCLM 领域分类看,全部规模合并时 Reading Comprehension 的超出量最大,但主导类别会随规模迁移,到 1.6B 档时 Symbolic Problem Solving 反超——暗示第二遍访问对结构化推理的帮助随模型容量增长而增强。
4.3 为什么代码任务收益最大
论文把 CE Gain 拆到各个数据领域上算(在 、 处)。做法是:共享总体拟合的三个指数 ,只对每个子集单独拟合三个截距 ——因为单个子集的数据量不足以独立拟合全部六个系数,这样既让每个子集收敛到自己的熵地板,又从数据丰富的总体拟合中「借」来曲率。
| 领域类别 | CE Gain |
|---|---|
| Code | 20.4% |
| Finance | 16.8% |
| Math / STEM | 16.6% |
| Knowledge | 14.9% |
| Web | 14.8% |
五个类别全部为正,Code 领跑。作者给出的解释是:这个排序追踪的是数据「内部结构性」的强弱。 代码有严格的语法和长程依赖——一个函数名在几百行外被调用、一个左括号必须在远处被闭合、缩进和作用域层层嵌套;而 Web 文本几乎不受这种约束。第二遍访问的价值恰恰在于「回头再看一遍,把远处的结构对上」,所以结构越强的数据,收益越大。这也和第 2.4 节 Dyck 括号匹配的机理故事完全咬合。
另一个切法是按 Baseline 自己的表现分组:把 39 个验证来源按 Baseline 的逐源验证损失排序,切成四组(10/10/10/9)。结果不是单调的:Q1(Baseline 学得最好的那批)18.0%,Q2 16.3%,Q3 降到最低 13.8%,Q4 又回弹到 15.9%。作者说他们只把 Q1 端当作可靠信号——它和领域分类的结论对上了,因为 Code 既结构性最强、Baseline 损失也最低、CE Gain 也最高;至于 Q4 为什么回弹,「我们的数据无法给出定论」,一种可能是 Q4 混杂了「真正噪声大、谁都学不好」和「难但有结构」两类来源。
4.4 为什么收益随样本长度和示例数增长
样本长度。 作者把验证集按文档自身的 token 数分成八个长度桶(上界 32、64、……、4096),并构造了三组对照,每组都把逐桶提升按其均值归一化,这样只比较「收益分布的形状」而不比较大小:
| 对照 | 长桶(512 到 4096)收益 / 短桶(32 到 256)收益 |
|---|---|
| SMELT vs. Baseline | 1.52 倍 |
| Baseline 加专家(提高稀疏度) | 0.88 |
| Baseline 加激活参数(放大规模) | 0.98 |
也就是说,单纯把模型做大或加专家,对长短样本的帮助是差不多平均的(0.98 与 0.88),唯独 SMELT 的收益明显偏向长样本。 直觉解释:样本越长,里面可供「回头检索」的结构就越多,而第二遍访问正是干这个的——短样本里本来就没什么远处的东西需要回看,第二遍自然派不上用场。
In-context 示例数。 作者在 16 个 few-shot 任务(15 个 DCLM 任务加 MMLU)上扫描示例数 :
- (零样本)时,SMELT 领先 0.9 个百分点;
- 一旦给出示例(),差距扩大到 1.9 个百分点,并一路保持到 。
在 Dyck Languages 这个「示例敏感型」精确匹配任务上更极端:两种架构在没有示例时都接近 0%,唯一的提升途径就是去读示例里的答案。这里差距不会随 增大而饱和,而是持续扩大,到 时 SMELT 拿到 29.8%,Baseline 只有 26.4%。
这与 attention sink 的机理正好接上。 示例越多,提示里可供第二遍访问的「答案片段」就越多;而第二遍恰好把原本堆在 BOS 上的注意力质量(0.60 降到 0.02)释放出来,转投到这些示例答案上(0.24 升到 0.85)。示例多 = 有更多值得看的地方;sink 削弱 = 有更多注意力可以投过去。两者相乘,收益自然随 增长。
五、潜在应用与已落地应用
已落地应用:暂无相关信息。 论文没有发布模型权重、代码或任何产品化说明,并明确表示底层 Transformer 家族与训练栈是专有的、无法公开。作者署名包含 ByteDance Seed,HuggingFace 页面也把这篇归到 ByteDance Seed 名下,但论文中没有任何关于内部产品采用的陈述。
潜在应用方向:
- 预训练架构选型。 这是最直接的用途。对于正在规划下一代 MoE 基座的团队,SMELT 提供了一个可以照抄的配方:物理深度与 Baseline 一致、循环中间 50% 的层两遍、缩窄 换算力、加专家补参数、调头几何与 GQA 比例补 KV cache。论文给出了 16 个网格单元的完整超参,可以直接对照。
- 同等部署成本下的能力提升。 因为 KV cache 也被锁死了,SMELT 在推理侧不会牺牲可服务的上下文长度,这一点对线上部署很关键——很多「增强推理深度」的方案代价都落在 KV cache 上。
- 代码模型与结构化数据。 Code 领域 20.4% 的 CE Gain 是全场最高,且下游残差分析显示 Symbolic Problem Solving 在最大档反超。对以代码、公式、表格、日志这类强结构数据为主的模型,收益应当最明显。
- 长上下文与 few-shot 密集的场景。 收益随样本长度(1.52 倍偏向长样本)和示例数(0.9 到 1.9 个百分点)增长,意味着 RAG、长文档理解、大量 in-context 示例的场景更适合。
- Attention sink 的新调控手段。 既有工作大多把 sink 当作训练完之后的静态属性来处理(比如 Qiu 等用 query 依赖的 sigmoid 门控去缓解)。本文提供了一个动态的观察:在同一次前向传播内部,一次权重共享的第二遍访问就能削弱 sink。这可能启发新的架构级 sink 抑制设计。
- 更丰富的循环变体。 论文自己列了几个方向:每遍配独立低秩适配器(Relaxed Recursive Transformers)、token 级自适应递归深度(Mixture-of-Recursions)、学习式停机、块选择性共享、跨 token 状态复用。这些变体在预算对齐下能否保住甚至放大 CE Gain,是留给后续工作的问题。
明确的局限(作者自陈):
- 三组设计消融都只在 200M 档做,更大规模下最优跨度或循环次数可能不同;
- 只研究了最简单的循环形式(连续块、完全共享权重);
- 预算对齐的是算术 FLOPs / 参数 / KV cache,不是 wall-clock,串行块重执行与稀疏路由可能带来硬件效率差距;
- 拟合曲面只被 到 FLOPs 支撑,要预测 那种量级的行为,必须在对应规模上真的训模型来锚定;
- 第二遍内部究竟哪个机制造成了收益,仍是开放问题——第 6 节的探针只是描述性的起点,不是因果解释。
六、网络上的讨论与评价
HuggingFace Papers(论文页面)
这篇被评为 Paper of the day 第 3 名,页面显示归属 ByteDance Seed。截至综述撰写时点票数为 88(本文抓取时页面已涨到 91 票)。讨论区目前只有两条内容:
- CheeryLJH(论文提交者,即作者 Jiaheng Liu)在提交当天贴出了论文摘要全文,没有额外评论;
- librarian-bot(HuggingFace 的自动化论文推荐机器人)列出了 7 篇语义相似的论文,全部是 2026 年的工作:Gated Recurrent Transformers: Expressive Depth through Recurrent Modulation、Looped Latent Attention: Cross-Loop KV Compression for Looped Transformers、DeepLoop: Depth Scaling for Looped Transformers、Decode-Branch Transformers、TriRoute、LoopMTP: A looped transformer guided by latent multi-token prediction、A Controlled Study of Attention-Only Transformers。这个列表本身就说明了一件事:「循环 Transformer」在 2026 年是个相当拥挤的赛道。
页面还显示这篇论文已被收进 5 个 collection,包括「WTF GENIUS PAPERS」(326 篇,76 关注)、「ByteDance Papers」(143 篇,36 关注)、「MoE」和「Architectures」。目前没有任何模型、数据集或 Space 引用这篇论文。
alphaXiv(论文页面)
页面显示 748 次浏览、58 次收藏,但讨论区是空的,没有任何评论。平台自动生成的 AI 概述准确复述了论文的三重预算对齐动机与 SMELT 配方,并将机构归为「清华大学、ByteDance Seed 与 TokenWave.AI」。
社区列表收录
论文已被收入 GitHub 上的循环模型精选列表 Awesome-Loop-Models,条目描述为「一个算力对齐的稀疏 MoE Transformer,把同一批中间一半的层执行两次,在不增加每 token FLOPs 或 KV cache 需求的前提下展现出更好的规模化与下游表现」。
其他平台
- Hacker News:通过 Algolia 全站搜索「SMELT looped transformer」,零命中,没有任何提交或讨论。
- Reddit / X(Twitter):多轮搜索均未找到可直接引用的公开讨论帖。搜索引擎返回的全部是 arXiv、HuggingFace、alphaXiv、HyperAI 这类论文索引站的镜像页面,没有找到实质性的第三方评论。
小结: 这篇论文在 HuggingFace Daily Papers 上热度很高(当日第 3、88 票以上),但几乎没有产生实质性的公开技术讨论。这大概率与论文发布仅数日、且内容偏「严谨的对照实验」而非「炸裂的能力演示」有关——它的价值在于把一个此前被算力混淆搞得含糊不清的问题做干净了,这类工作通常在同行中口碑好,但不太容易引发社交媒体上的热议。同时也要注意:论文自己在相关工作里列出了至少三项并行的 MoE 循环工作(LoopMoE 在 3B/9B、Gao 等在 6B/20B、DREAMER 单层递归 16 到 32 次),说明这个方向正在被多个团队同时推进,SMELT 的独特性主要在于「三项预算同时对齐 + 完整规模化阶梯 + 各自独立拟合曲面」这套方法论,而非「循环有用」这个结论本身。
七、思维导图
mindmap
root((SMELT 算力对齐的 MoE 循环 Transformer))
研究背景与问题
Looped Transformer 的旧账
参数固定但 FLOPs 与 KV cache 悄悄翻倍
Huginn Ouro 只固定 model size Schwethelm 丢失 unique params
三项预算必须同时锁死 per-token FLOPs 与 non-embedding params 与 KV cache
MoE 让总参数与 per-token FLOPs 解耦
SMELT 配方与预算对齐
三条规则
只循环中间 50% 的层 而非整栈
更大的 effective depth-to-width ratio
Loop Twice 两遍胜过三遍四遍
对齐三步走 缩窄 hidden dim 提高 expert count 调 head size 与 GQA ratio
残差更新按 1/r 缩放 防止残差流膨胀
残差失配 FLOPs 最大 3.9% params 1.0% KV 3.6%
实验设计与规模化
4x4 网格 32 次训练运行
四个规模档 100M 200M 600M 1.6B 与物理深度 L=10 12 20 30
四档稀疏度 S=0 85% 95% 97% 最大档 53.90B 非嵌入参数
WSD 稳定期 196075 步 205B tokens 加六条 cosine 分支
Scaling law 形式 L=E+A(1-S)^b F^-a + K D^-c 用 Huber loss 加 L-BFGS-B 拟合
主要结果
CE Gain 算力效率增益
1e20 FLOPs 省 6.8% 到 10.0%
1e21 FLOPs 省 14.7% 到 18.0%
前沿指数 gamma 0.237 对 0.250 高 5.5%
下游评测 DCLM Completion 96 比 96 全胜 Core 83 比 96 MMLU 29 比 30
领域拆解 Code 20.4% 领跑 Web 14.8% 垫底 结构性越强收益越大
长样本收益是短样本的 1.52 倍 Dyck k=32 达 29.8% 对 26.4%
两架构 TPP 差距在 6% 以内 省算力靠更低的损失
机理分析 第二遍在做什么
专家路由 S=97% 时只复用 2 到 3 个专家 但远高于随机
残差写入 16 个单元四种范数比值 1.2 到 3.5 倍 第二遍放大而非覆盖
注意力 Q 与 K 跨遍余弦 0.89 到 0.93 但 V 掉到 0.65 到 0.74
Attention sink 削弱 Dyck head 的 BOS 质量 0.60 降到 0.02
局限与展望
消融只在 200M 档完成 且只研究连续块全共享循环
对齐的是 FLOPs 而非 wall-clock
外推到 1e25 需要真实大规模锚点
未来方向 per-visit LoRA 与 token 级自适应递归深度