当整个行业争相比拼“谁想得更久、算得更多”——推理模型动辄输出成千上万个思考token，循环式架构恨不得在内部反复迭代十遍八遍——一项最新研究却冷静地泼了一盆冷水：一个仅有7B参数的小模型，只需在常规计算之外“多循环这一次”（总共执行2次循环），就能在公认最棘手的真实代码修复基准SWE-bench Verified上，将得分从43.0分大幅提升至64.4分；而继续增加循环次数，不仅不会带来提升，反而一路骤降。

论文标题极为简洁——《Only Loop Once》，即“只循环一次”。该研究来自北京航空航天大学、IQuest Research、澜舟科技和中国人民大学的联合团队。

论文标题：LoopCoder-v2：Only Loop Once for Efficient Test-Time Computation Scaling
论文地址：https://arxiv.org/pdf/2606.18023
研究团队：北京航空航天大学 · IQuest Research · 澜舟科技 · 中国人民大学
模型主页（HuggingFace）：huggingface.co/Multilingual-Multimodal-NLP/LoopCoder-V2

▲ 核心结论一图流：多循环带来“精修收益”，同时也带来几乎恒定的“位置错配成本”；收益在第2次循环时达到峰值后迅速衰减，因此“只循环一次（共2次）”成为最优解。

一、“循环”，当下最热的竞争方向

自从o1、Claude这一代推理模型将“想得越久越强”写入行业共识后，“测试时计算”（test-time compute）便成为过去一年最受瞩目的技术方向：与其把模型训练得更大，不如让它在推理阶段多投入一些算力，反复打磨答案。要理解这项研究，首先需要了解业界具体在“卷”什么。

过去想让模型更强，常规做法是堆叠更多网络层数、增加参数量。而“循环式”大模型（Looped / Recurrent-depth LLM）换了一条思路：不新增网络层，而是让同一套参数在模型内部“反复打磨”多遍表征。打个比方，就像同一个人把一道题在心里默默重算几遍，而不是请来更多人、或者把草稿纸写满——这是一种节省参数的“测试时计算”策略。

听起来很理想，但有一个硬伤：顺序循环的成本太高。每多循环一次，就要多走一遍完整计算，推理延迟和KV-cache显存都随循环次数线性增长。想增加循环次数，算力难以承受。

并行循环Transformer（Parallel Loop Transformer，PLT）正是为了解决这一痛点而生。它通过两项技术有效压低了成本：一是CLP（跨循环位置偏移），打破循环之间的串行依赖，使得多次循环可以并行计算；二是G-SWA（共享KV的门控滑窗注意力），让显存几乎不随循环次数增长。成本被压平后，“循环几次”第一次变成可以自由调节的旋钮。

二、旋钮拧大 ≠ 更强：第2遍封顶，第3遍跳水

问题来了：这个旋钮，究竟拧到多少最合适？

研究团队从零训练了一整个模型家族：7B稠密模型，使用18T token、文本与代码比例1:1、覆盖100多种编程语言，总计算量约100万GPU小时。唯一的变量就是循环次数。结果非常反直觉：

多循环一次（共2次）几乎全面碾压“不循环”的基线表现——SWE-bench Verified从43.0分升至64.4分，多语言版从14.0分升至31.0分，LiveCodeBench从27.4分升至35.4分，十项基准平均分从38.0分跃升至46.5分。但循环到3次、4次时，性能直接跳水：SWE-bench跌至27.6分、22.4分，平均分甚至不如不循环的基线。

更有说服力的是横向对比：这个仅7B参数、只多循环一次的模型，在SWE-bench Verified上取得64.4分，超过了2350亿参数的Qwen3-235B（45.2分），逼近Kimi-K2（69.2分）、Qwen3-Coder-480B（67.0分）等大它数十倍的开源旗舰模型。在偏重“动手干活”的agentic任务上，提升尤其显著：终端操作基准Terminal-Bench两个版本分别从26.3分升至34.2分、从11.2分升至21.0分（后者接近翻倍），工具调用基准BFCL从32.2分升至40.1分，提升幅度相当可观。换句话说，这次性能跃升并非依靠更大的模型规模，而是源于“多想了一遍”这一简单操作。

三、为什么“多循环一次”就够了？一笔收益账

真正有趣的，是团队并未止步于“2次最好”这个调参结论，而是拆解模型内部，算了一笔“收益—成本”明细账。

先看收益侧。研究者使用三把“探针”——隐状态的演化、注意力的路由、输出分布的变化——同步观察每次循环究竟做了什么，只有三者一致时才下结论。结论是：第2次循环几乎包办了所有“有效的精修”——隐状态朝同一方向稳步收敛、注意力重新分配、输出分布明显改善，表征多样性（effective rank）也在这一步达到峰值。再往后，更新幅度越来越小，甚至出现来回震荡（方向反转），注意力路由基本“冻结”，后续循环近乎空转。

再看成本侧。CLP为了实现并行循环，做了一个取巧设计：从第2次循环起，每个token拿到的是“邻居”上一轮的状态，而不是它自己的。这引入了固定的“位置错配税”——团队将其量化为一个可直接从模型内部状态计算的指标Ω，并发现该指标在每次循环中几乎恒定不变。

▲ 蓝线是每次循环的“精修收益”，第2次之后急剧坍缩；红线是CLP的“位置错配成本”，几乎恒定不降。一涨一平之间，第2次循环成为最优平衡点。

两条曲线对照，故事一目了然：精修收益（蓝线）在第2次循环后崩塌，再也没能恢复；而错配成本（红线）持续高位横盘。收益递减、成本恒定，因此超过2次后，错配的代价便盖过了精修的收益，性能自然掉头向下。这也意味着，“循环到几次最好”不必依赖昂贵的暴力跑benchmark逐个尝试，而可以通过这些内部诊断指标提前预判。

四、对行业意味着什么

这项工作的价值，不仅仅是又训练了一个能打的代码模型。

它首先给“测试时计算 = 越多越好”的流行直觉踩了一脚刹车：至少在PLT这类并行循环架构中，存在一个明确且偏低的“甜点”，盲目增加循环次数反而会带来负收益。其次，它提供了一套不依赖暴力实验、而是基于可解释性指标来选择循环次数的诊断方法。最后，它对端侧和小模型尤其友好——一个7B模型只需多循环一次，就能在硬核的真实软件工程任务上实现越级表现，这是一笔相当划算的效率账。

研究团队也指出了几个值得继续深挖的方向：让位置偏移变得自适应、根据任务动态分配循环次数，以及搞清楚这种“内部循环”与模型显式写出的思维链（CoT）之间究竟如何协同工作。

说到底，在这个比拼“谁算得更多”的时代，这篇论文给出的提醒朴素却扎实：有时候，多想一遍就够了，想太多反而坏事。