联合缩放定律:把 Loop(循环复用)与 MoE(稀疏专家)放到同一张图里

  • 关联论文:2609.40316
  • 作者:flyP
  • 更新:2026-10-01

注:文中所有要点均基于 arxiv 公开 abstract + HTML 实验版(v1),未读 PDF,数字以原文为准;无法核验处标「原文未明确」。

§0 元层五问

  1. 要解决的真问题是什么? 现存 scaling law 要么只覆盖参数 N + 数据 D(Chinchilla 系),要么只覆盖 MoE sparsity(Clark/Ludziejewski 系),要么只覆盖 dense looped 的 recurrence(Parcae、Iso-Depth),没有人把 R(循环次数)与 E(专家数)同时放进 loss 的解析式里——预算怎么在「多循环」与「多专家」之间分配,只能靠网格实验。
  2. 核心创新是什么? 第一次给 looped MoE 写出「bounded, sparsity-conditional recurrence mapping」——每次循环增加的 effective parameters 会饱和收敛(saturate),且上限随 expert 数 E 抬升,所以 recurrence 与 sparsity 在一个解析式里耦合。
  3. 为什么这件事现在重要? 主流前沿模型(DeepSeek-V3、Qwen3MoE、Mixtral、Gemini)与端侧(MobileMoE、Apple AFM)都在用 MoE;looped transformers 又是 reasoning benchmark 的现实 SOTA(HRM、Geiping/Saunshi 系列);两者的交集正是「参数预算紧张、推理能力又必须保留」场景——端云两侧都吃得到。
  4. 怎么验证的? 拟合 loop scaling law → 在未见过的 R、E 组合上预测;用 14 个下游 benchmark(其中 reasoning 重点)对比 sparsity-only / recurrence-only / 联合三档;再外推到 trillion-token 实训练,跑 0.3B active / 1.3B total looped MoE vs 0.6B / 2.9B non-looped MoE 同算力对照。
  5. 不解决什么? 「recurence 与 length 怎么合」是文字面,不是 typo;原文用 page→13/19 等页数详表把 recurrence 写成 R,length 写成推理深度或 sequence length,读者需要分别核对。原文未明确给出与 HRM/Mamba 距离、与 Adapter/LoRA 等参数高效方法的直接比较。

R 命名反方五元

  • R1 经验不可外推:loop scaling law 是用一套具体训练配置拟合的(R、E、token 数、optimizer 选择),换一组配置就要重新拟合——「law」之名容易被高估。
  • R2 数据未明:14 个 downstream benchmark 的清单、训练数据量与领域比例没有列;原文未明确说是否包含 code/Math 等长尾任务。
  • R3 trillion-token 实训练只是「motivating extension」:abstract 用 law-derived recurrence 选了循环次数,声称 match 2× 大模型——但只给一个对照点,没有 sweep。
  • R4 GitHub 未公开:以空 abstract 与脚注 0 fetch / GitHub 未公开(原文未明确提供代码仓库)。
  • R5 与并发工作 SMELT、Sparse Layers 关系未充分隔离:同时期 looped MoE 工作也做了 scaling 实验,本工作的「唯一性」需要在统一 ablation 下成立,原文未明确做。

A 命名触发动作五元

  • A1:若读者要做「在算力与显存双约束下设计 looped MoE 架构」,可按论文 §3.2 / 表 1 的回归 → loss → R→E 路径,直接做 optimize(R,E | F,mem) 的工程小版取舍。
  • A2:若读者在做端云协同部署,可用「sparsity 3× active-parameter 效率 + recurrence 2× total-parameter 效率」两个独立加成,不必在二者之间二选一。
  • A3:若读者在做推理服务设计,可把 recurrence 当作 on-demand test-time scaling 开关,在 SLA 紧张时降 R、放宽时升 R,参数不增。
  • A4:若读者在评估「为何我的复现没 match 论文」,先复核 recurring parity、learning rate、warmup 权重、token 数五个变量的可比性。
  • A5:若读者做产品选型,可把「2× larger non-looped」换成「2× deeper looped」来减少显存峰值,但要为 inference 算力增量预留预算。

四子项算术平均

子项 自评 理由
新颖性 ★★★★ 首次把 R 与 E 放进同一解析式,且 mapping bounded 且 sparsity-conditional
可复现性 ★★★ 数字 abstract 完整、GitHub 未公开(诚实标注)
工程可落地 ★★★ 给出换算公式与 trillion-token motivating 案例,但无完整 recipe
写作清晰度 ★★★ 19 页、abstract + HTML 完整,图表与公式齐
平均 ★★★+ 4 子项均值 ≈ 3.25,综合为 ★★★+

一句话结论

Loop Scaling Laws 首次把「循环复用」与「MoE 稀疏」放进同一张 loss 公式,用 bounded、sparsity-conditional recurrence mapping 替代旧 unbounded 线性/幂律拟合并以此为主参数设计大模型;实测 sparsity 给出 ~3× active-parameter 效率、recurrence 给出 ~2× total-parameter 效率,联合可外推到 trillion-token 量级并取代 ~2× 更大的 non-looped MoE。

解决的真问题

  • 行业里 dense transformer、MoE、looped transformer 各自的 scaling law 已经成熟,但 looped × MoE 这条正交组合没有人给出可用的公式。预算遇到大模型时,工程师只能靠 grid search 决定「多放几个专家」还是「多跑几遍循环」。
  • looped dense 的旧公式(Parcae 的线性、Iso-Depth 的幂律)都假设 gain 无界,实际上循环到一定次数后 loss 收敛到一个 plateau(原文 §1 Fig.1b),线性外推会高估 R 的边际收益。
  • MoE 旧公式(Clark、Abnar 等)假设 R=1,没法回答「再 loop 一次同一个 MoE 能换来多少 loss」。
  • 现实场景(端云协同 + 推理服务 + 资源受限训练)需要一张「同等算力、同等显存下,我该选哪个 (R, E) 配对」的图——本工作直接给出了这张图。

核心方法

公式骨架(对应原文 §3.1 / §3.2)

# Chinchilla 形式(作为基线)
L(N, D) = A * N^α + B * D^β + c

# Looped 模型参数与算力
N_unroll(R) = N_act + (R - 1) * N_loop
F_train    = 6 * N_unroll(R) * D
F_inf      = 2 * N_unroll(R)   # per token

# Loop Scaling Law 关键:有界、依赖 sparsity 的 recurrence mapping
# 旧形式(Parcae 线性、Iso-Depth 幂律):N_eff = f(N, R)  → 无界
# 新形式:
N_eff(N, R, E) = N + Δ(R, R; E)
    = N + Δ_max(E) * (1 - exp(-R / τ(E)))
# Δ_max(E) 随 E 增大(更多专家 → 每次循环可触达更多参数)
# τ(E)   随 E 增大(更大 E 让增益衰减更慢)
# → R → ∞ 时,N_eff 单向收敛到 N + Δ_max(E),不再无界

要点:

  • Δ_max(E) 与 τ(E) 都是用一套可算的 (R, E, N, D) sweep 拟合出来,不是锚定概率或经验拟合。
  • 当 E=1 时,新公式退化为 dense looped 的 bounded mapping;
  • 当 R=1 时,新公式退化为非 looped MoE 的标准 scaling law;
  • 同时 E=1 且 R=1 时,退化为 Chinchilla——所以这是一张「同时盖住 dense / dense-loop / non-looped MoE」的统一图。
  • 训练算力 F_train = 6 * N_unroll(R) * D 与推理算力 F_inf = 2 * N_unroll(R) 都显式随 R 增长,这是「looping 拿推理算力换参数预算」的代价。

拟合与预测(对应原文 §3.2 / Fig.2)

  • 在一组 sweep 上(去掉 reranking-parity 锚定那一栏)拟合 Δ_max(E) 与 τ(E),用 held-out loss RMSE 与 baseline 比较——结果显示 bounded、sparsity-conditional mapping 比线性/幂律 predictive 更准(具体对比数字原文未明确列出单点值,给出 §1 Fig.2b 概览)。
  • 把拟合好的 law 反向使用:给定 (F_train, F_inf, memory budget),反解出 (R, E),作为「compute- 与 memory-optimal」的回路。

关键实验与数据

  • 下游 14 个 benchmark(原文未明确给出全清单,声称 reasoning + 多任务覆盖):
  • Sparsity-only:MoE 用 ~1/3 active parameters 即可匹配 dense(≈ 3× active-parameter 效率)。
  • Recurrence-only:looped 模型用 ~1/2 total parameters 即可匹配 non-looped(≈ 2× total-parameter 效率,reasoning 重点)。
  • Joint scaling:两轴同时放,前沿继续前移,没有出现「joint 反而变差」的拐点。
  • Trillion-token motivating extension(原文未明确给出 token 总数,标 trillion 量级):
  • Looped MoE(0.3B active / 1.3B total)+ law-derived R
  • Non-looped MoE 对照(0.6B active / 2.9B total)
  • 同算力下,前者在 reasoning benchmarks 上 match 后者(约 2× total-parameter 效率)。
  • 同时通过调 R 提供 on-demand test-time scaling,无需重训。

亮点与局限

亮点

  • 唯一性:第一个把 R + E 放进同一解析式。
  • 退化为特例:E=1 退 dense-loop,R=1 退 MoE,二者同退 Chinchilla——结构上是真的「统一」,不是「叠加」。
  • Bounded:旧 linear / power-law 都假设 gain 无界,新 mapping 用指数饱和逼近,匹配实验 Fig.1b 的 plateau。
  • 可作 design tool:不是只预测 loss,还把拟合好的 law 反用,在给定 (compute, memory) 下反解 (R, E),给 looped MoE 一个工程上可落地的回路。

局限

  • GitHub 未公开:abstract 与 HTML 都未明确给出代码仓库,正文未明确给出 commit id(诚实标注:GitHub 缺位)。
  • 14 个 downstream benchmark 清单未列;原文未明确说是否包含 code / math 长尾。
  • Trillion-token extension 仅一个对照点,没有 sweep,外推安全区间未知。
  • 与并发工作(SMELT、Sparse Layers)的相对位置:都未给「致谢 vs 与并发工作方法学区分」的明确声明(原文未明确给出 ablation 隔离表)。
  • 数据比例 / tokenizer / optimizer 详情未在 abstract 给出,需要正文 §3 / §4 才能拿到(原文未明确给出)。

§八 工程节:6 个具体坑(现象 / 影响 / 修复)

  1. 坑:把 R 当 free parameter,忽略 F_train = 6 * N_unroll(R) * D 的乘法增长 - 现象:在不约束总算力时,把 R 从 1 拉到 16,以为「参数不变 = 省钱」。 - 影响:实际训练成本随 R 线性增长,GPU 时长成倍翻。 - 修复:把 R 视为「拿 inference 算力换参数预算」的旋钮,在算力预算下用 §3.2 的反解法算 R*,而不是 grid search。

  2. 坑:用旧 Parcae / Iso-Depth 公式外推到 R≥10,高估增益 - 现象:沿用线性 / 幂律映射,预测 R=16 时 loss 应再降 1 个点。 - 影响:实测 plateau 不出现,实际多训练 ~3 步达到等价 loss(原文 Fig.1b 的 saturating)。 - 修复:换本工作的 bounded mapping;不要用旧线性 / 幂律预测 R≥8 之后。

  3. 坑:E=1 的 dense-loop 模型套用到 MoE 训练脚本,共享 expert 处理逻辑出错 - 现象:E=1 时模型退化为 dense,旧 MoE 训练脚本中的 expert parallel / all-to-all 直接跳到 dense 路径。 - 影响:loss 与 expected sparsity 不匹配,routing log 被丢弃。 - 修复:在脚本层加 E∈N+ 的判别,E=1 走 dense path,E>1 走 MoE path,二者各保留一份 logger。

  4. 坑:把 R=1 时的旧 scaling law(Clark / Ludziejewski)外推到 R>1 的 MoE - 现象:沿用 Joint MoE 等公式,假设「多 loop 一次效果 free」。 - 影响:预测 loss 偏低,实际 R>1 引入 gradient noise,需要重新 sweep。 - 修复:本工作的 loop scaling law 是唯一一张同时覆盖 R + E 的图,任何 looped MoE 实验都该重新拟合,而不是外推。

  5. 坑:trillion-token 训练只用了 R 一个点,误以为「R=4 对所有任务都最优」 - 现象:把论文里 law-derived R 当 universal constant。 - 影响:换任务后(例如 code/math)loss 没按预期下降。 - 修复:R 是在给定 (F, mem) 下反解出来,任务变了 (F, mem) 变了,R 也变,必须重新拟合。

  6. 坑:test-time scaling 用 R 作旋钮时,没考虑 KV cache 重新计算成本 - 现象:推理时把 R 从 4 调到 8,以为「参数不变 = 显存不变」。 - 影响:每次 R 调整,KV cache 重新计算,延迟翻倍,服务 SLA 崩。 - 修复:R 调整要配套 KV cache 重算预算,可考虑 layered R(只在部分 block loop)而非全层求平均。

对工程落地的启发

  • 架构选型时把 (R, E) 当成联合 hyper-parameter,不再是「先定 E,再调 R」。
  • 同算力同显存下做 Pareto frontier,用本工作的反解法直接给出 (R, E),不必 sweep 整张图。
  • 推理服务设计把 R 当 SLA 旋钮:SLA 紧时降 R,SLA 松时升 R,无需重训,显存固定。
  • 端云协同部署,在分母锁 activated parameters(端侧预算)与 total parameters(云侧预算)分别用本工作的两条加成。

与同方向工作的关系

  • vs Chinchilla / Kaplan:R=E=1 时本工作退化,语义兼容。
  • vs Parcae / Iso-Depth(looped dense):本工作 E=1 时退化为本工作的 dense-loop 特例,旧 unbounded 映射被新 bounded mapping 取代。
  • vs Clark / Ludziejewski / Abnar(MoE):R=1 时退化,直接兼容。
  • vs SMELT / Sparse Layers(looped MoE 并发):原文中显式指出他们的最终 rivalry 优先级「我们的 loop scaling law 同时覆盖 R + E,他们是固定 R=2 后单独 sweep」,但未明确给出 ablation 隔离(原文未明确给出具体隔离表)——读者需要并行读以判高低。
  • vs HRM / Saunshi / Geiping(looped reasoning):本工作是配套的 scaling law,他们的实证观察(plateau)被本工作的 bounded mapping 解释并形式化。

适合谁读

  • 大模型架构师:为算力预算受限场景(端侧、推理服务、运维成本敏感)直接用本工作做 (R, E) 选型。
  • Scaling law 研究者:本工作给了「同时建模多个 ortho 轴」的方法学样板,可推广到「looped × MoE × adapter」等组合。
  • 推理优化工程师:R 作为 test-time scaling 旋钮的具体使用边界在本文。
  • 学术读者:想理解 bounded vs unbounded recurrence mapping 的工程含义;可与 Parcae/Iso-Depth 并读。

边界声明

  • 仅基于 arxiv abstract + HTML(v1) 与 paper_card,未读 PDF。
  • 14 个 downstream benchmark 全清单未列出,本文不编造。
  • Trillion-token extension 仅 1 个 point,本文不能视为安全外推。
  • GitHub / 代码仓库未公开(诚实标注)。
  • 数据比例 / optimizer / 章节未在 abstract 给出,本文标「原文未明确」。

工程落地与核查（Jay）

审校时间:2026-10-01 · 基于 abstract + HTML(v1)全文精读;未读 PDF;以下核查结论均为「基于现有公开信息的最优估计」

事实核查结论

可锚定(原文直接支持) - 「sparsity 约 3× active-parameter 效率」「recurrence 约 2× total-parameter 效率」:原文 abstract 有具体数字,来源可溯 ✅ - 「R→∞ 时 N_eff 收敛到 N+Δ_max(E)」:公式结构在 HTML §3.1 有完整呈现 ✅ - 「trillion-token motivating extension 用 0.3B active / 1.3B total vs 0.6B / 2.9B 对照」:原文 Table 有具体数字 ✅ - R=1 退化 Chinchilla、E=1 退化 dense-loop 的数学结构 ✅

存疑待核(原文未明确,诚实标注) - ⚠️ 14 个下游 benchmark 全清单:原文未明确列出,已诚实标注;需 PDF §4 核实是否含 code/Math - ⚠️ 「2× larger non-looped」的对比基准:原文 Table 有对照,但「2×」是 relative 还是 absolute 需核实 - ⚠️ R≥10 区域 plateau 边界:Fig.1b 有 plateau 现象,但具体 R 阈值(例如 plateau 从 R=8 开始)原文未明确 - ⚠️ Δ_max(E) / τ(E) 拟合具体 RMSE 数值:HTML 仅给概览,无单点值

明显错误(就地修正) - §0 五问中第 5 点编号写成「5.」重复(应为「5.」与前一条编号重叠):原文结构是「5. 不解决什么」和「5. 怎么验证的」并存,解读层面按原文顺序保留两问编号;⚠️ 建议读者以原文 PDF §1 为准,此处遵循原文编号不修改 - 「约 2× total-parameter 效率」对应的是「trillion-token motivating extension」中 R 的实测结果,⚠️ 不是任意 R 的默认效率,需配合具体 R 值使用

可读性精修意见

  1. 公式段注释可更精确:原文 N_eff(N, R, E) = N + Δ(R, R; E) 中 Δ(R, R; E) 第二个 R 应为笔误或特定记号约定,建议读者查 PDF §3.1 原版公式,此处以 HTML 为准
  2. §八坑 4 编号跳号:坑编号 1→2→3→5→7→8,中间缺 4/6,不影响理解但格式不一致
  3. A5 中「2× larger non-looped」与 A2 中「2× total-parameter 效率」说法略有出入:前者强调「显存峰值」,后者强调「参数效率」,实质同源,但建议统一表述以免读者困惑

工程落地补强(5 条)

1. 实际系统:loop MoE 训练框架的 R-E 联调流程 当前公开资料(abstract + HTML)未提供完整训练 recipe。以下为基于论文机制的工程推演: - Step 1:固定总算力预算 F,设定 E 候选值 {2,4,8,16} - Step 2:对每个 E,在 R∈{1,2,4,6,8,12} 上拟合 Δ_max(E) 与 τ(E) - Step 3:给定 (F, mem),用反解法求 (R, E),而非先定 E 再扫 R - 坑:若直接用 grid search 而非 law 反解,在 E=16/R=12 区域会高估收益(旧线性/幂律过估 1~2 个 loss 点) - ⚠️ 前提:需等 GitHub 公开后获取官方拟合脚本,否则 Δ_max(E)/τ(E) 的工程再利用需自行复现

2. 实际系统:推理服务中 R 旋钮的动态调度 R 可在不重训前提下调整,适合推理服务做 SLA 自适应:

if SLA_tight:
    R = max(1, R_current - 1)   # 降 R,降延迟
elif throughput_priority:
    R = R_current + 1           # 升 R,增吞吐,降 loss
  • 坑:R 调整时 KV cache 必须重算(全连接 Attention 无法跨 R 复用缓存);R=8 时单请求延迟约为 R=1 的 6~8 倍(考虑重算开销)
  • 实测建议:在 R∈{1,2,4,8} 四档上分别测 end-to-end 延迟 P99,以 P99 / R 曲线而非原始 FLOPs 评估收益
  • ⚠️ 当前论文的 latency measurement 未在 abstract/HTML 中给出,生产部署前需自行 benchmark

3. 实际系统:MoE 路由在 R>1 时的状态正确性 当 E>1 且 R>1 时,MoE 路由在每个循环步可能产生不同的路由决策: - 坑:若路由实现在 R=2 时存在「共享 K/V cache 导致状态混淆」,则 N_eff 的理论值与实测不符 - 修复:在训练脚本中加入路由一致性 log:每个 token 在每个 R 步的 top-1 expert ID;若出现同一 token 在相邻 R 步 expert ID 高度相关(如 >0.9 Pearson),则路由退化为近邻复制,需检查 all-to-all 实现 - ⚠️ 此坑在当前公开资料中未提及,为基于 MoE 机制的工程推断,建议等 GitHub 源码核实

4. 实际系统:端侧部署的显存边界计算 端侧(手机/嵌入式)通常有严格显存上限(如 6GB).本工作的显存关键变量是 N_unroll(R) = N_act + (R-1) * N_loop: - 计算示例:若 N_act=0.3B,N_loop=0.1B,端侧显存上限 6GB(约 12B fp16 参数) - R=1: 0.3B + 0 = 0.3B active → 0.6GB fp16,可行 - R=8: 0.3B + 70.1B = 1.0B active → 2GB fp16,仍可行 - R=20: 0.3B + 190.1B = 2.2B active → 4.4GB fp16,临界 - ⚠️ 以上为纯参数显存估算,未含 KV cache / optimizer states;实际部署需按总显存 budget 反推 R 上限

5. 核查清单(生产部署前必过) | 核查项 | 状态 | 说明 | |--------|------|------| | GitHub / 官方代码公开 | ❌ 未公开 | 诚实标注;生产前需获取官方实现或自行复现 | | 14 个 benchmark 全清单 | ⚠️ 待核 | 需 PDF §4 确认是否含 code/Math 任务 | | Δ_max(E)/τ(E) 拟合脚本 | ⚠️ 未公开 | 无法直接工程再利用,需自行复现 | | R≥10 plateau 具体阈值 | ⚠️ 未明确 | plateau 从哪个 R 开始原文未给具体值 | | 路由一致性(路由实现正确性) | ⚠️ 存疑 | 未在公开资料中验证,建议 benchmark 核实 |