一分钟读论文：《循环语言模型的省算力账，批次维度对不上》
内容提要
Apple 论文从零预训练 140M 至 1.3B 参数的循环语言模型，实测发现 halting head 按平均迭代数报告的省算力被系统性高估：预测均值 3.7 次迭代，实际运行 7.6 至 7.9 次，几乎不省算力。改用逐步打分后 token 约停 3 次，但 32 序列批次需等最慢 token，实付 4.4 至 4.7 次，领先从 0.0246 塌缩至 0.003 BPB。论文建议改报预测均值、实跑步数、批次实付三个数。
延伸解读
预测均值不等于实跑成本
论文指出，halting head 报告的“平均迭代数”只是预测均值，并非实际运行步数。默认退出规则要求停止概率累计到 90% 才放行，导致 token 实跑 7.6 至 7.9 次，而预测均值仅 3.7 次。这意味着按预测均值估算的省算力被系统性高估，读者在评估类似方案时应区分预测值与实跑值。
批次解码的等待成本
即使 token 平均约 3 次迭代就停止，32 序列批次仍需等待最慢的 token，实付 4.4 至 4.7 次迭代。370M 模型计时显示，批次比固定跑满 8 次快约 1.6 倍，但若按实跑步数固定深度可快 2.3 倍，差额正是等待最慢 token 的成本。这说明单序列的省算力优势在批次服务中会明显缩水。
领先幅度在批次口径下塌缩
逐步打分方案在单序列下对无头基线领先约 0.0246 BPB，但按批次实付深度重新对账后，领先塌缩至 0.003 BPB。对 Ouro 2.6B 的复测也显示，token 平均省约 1/10 迭代，32 token 批次只省约 1%。因此，比较自适应深度方案时，应以批次实付步数为口径，而非 token 平均迭代数。
结论的适用边界
作者明确限定结论仅适用于其训练的 halting head 配置，参数上限 1.3B、训练 104B tokens，不能外推到所有自适应深度方案。论文建议改报三个数：head 预测均值、退出规则实跑步数、批次实付步数，并给出训练前上界测试方法。读者在引用该结论时需注意其范围限制。
Q&A
循环语言模型里 halting head 报告的省算力为什么被高估了？
因为 halting head 按“平均每 token 迭代数”报告省算力，但默认退出规则要等停止概率累计到 90% 才放行，导致 token 实际运行迭代数远高于预测均值。论文实测预测均值 3.7 次迭代，实际运行 7.6 到 7.9 次，几乎不省算力。
批次解码时，为什么 token 平均只跑 3 次，但批次实付却要 4.4 到 4.7 次？
因为服务端 32 条序列一起解码时，批次必须等迭代最多的那个 token 停止才能关门。token 平均跑 3 次左右，但批次要等最慢的 token，所以实付 4.4 到 4.7 次迭代。
改用逐步打分（per-step loss）后，模型质量领先多少？在批次实付深度上重新对账后领先还剩多少？
改用逐步打分后，token 真的停在约 3 个迭代，对随机深度训练的无头基线领先约 0.0246 BPB（770M 档位实测）。但在批次实付深度上重新对账，领先塌缩到 0.003 BPB。
论文对已发布开源模型 Ouro 2.6B 的复测结果是什么？
复测显示，token 平均省约 1/10 迭代，但 32 token 批次只省约 1%。这是论文自测口径，并非 Ouro 官方结论。
论文建议如何更准确地报告循环语言模型的省算力？
论文建议改报三个数：halting head 预测均值、退出规则实跑步数、批次实付步数。并给出训练前上界测试：瞄准 3 次迭代的 head，单序列解码上界约 0.03 BPB，32 序列批次下缩到约 0.01。
halting head 在什么情况下仍然能保住领先？论文的结论有哪些适用范围限制？
逐步打分加固定深度解码时，模型仍全面领先无头基线；把停止 token 已算出的 key/value 复用进 KV cache，单序列解码能保住几乎全部领先。结论只适用于论文训练的 halting head 配置（mixture/per-step 训练、上限 1.3B 参数、训 104B tokens），不能外推到所有自适应深度方案。
