今日概览
- 循环加深计算只能加两层：LoopCoder-v2用并行循环把「循环几次」变成可工程化的旋钮，两次循环让SWE-bench Verified从43.0涨到64.4，但三次及以上反而退化——test-time compute的scaling曲线在很浅处就饱和。
- 让agent交出一个能玩的游戏：GameCraft-Bench在Godot引擎里设140个任务，不靠读代码打分而是把游戏跑起来回放评判，把「能否交付完整交互系统」变成可观测基准。
- 老师放进prompt而非gradient：ZPPO在小模型后训练里把老师当「提示」去救那些全失败的难题，0.8B到9B四个规模上稳定超过蒸馏和GRPO，越小收益越大。
- 共享一个离散tokenizer也能跑通：UniAR押下和UniDDT相反的赌注，用位运算量化让理解与生成共用一套视觉token，图像生成编辑双SOTA，统一多模态的路线之争仍未收敛。
重点关注
01 推理加速 循环架构想把「加深计算」做成可调旋钮，结果发现只能加两层
循环Transformer的思路是重复套用同一组共享层来加深latent计算，但串行循环每多一次，延迟和KV-cache内存就跟着涨，深度收益被成本吃掉。LoopCoder-v2用并行循环(PLT)绕开这点——靠跨循环位置偏移和共享KV的滑窗注意力把串行成本摊平，让「循环几次」变成一个可以工程化选择的设计参数。团队从头训了一组7B的PLT编程模型(18T tokens)来做对照，结论很反直觉：两次循环相比不循环的baseline全面提升，SWE-bench Verified从43.0涨到64.4、Multi-SWE从14.0涨到31.0；但三次及以上反而退化。诊断显示主要的有效精炼集中在第二次循环，再往后更新越来越小、还会震荡,而位置偏移带来的错配成本基本固定不变,于是收益缩水后成本就开始占上风。值得留意的是,标题叫「Only Loop Once」,但摘要里真正最优的是两次循环——这条test-time compute的scaling曲线在很浅的地方就饱和了,究竟能不能同时拿到深度收益和并行效率,得看全文的延迟/内存实测数字才好下判断。
原文：LoopCoder-v2: Only Loop Once for Efficient Test-Time Computation Scaling
02 评测 让agent写代码容易，让它交出一个能玩的游戏才是真考验
普通coding任务里，代码跑通、测试通过就算赢。但游戏生成不一样：它发生在游戏引擎里，脚本、场景、资产、渲染和运行时交互必须共同产出连贯的可玩性——光让脚本不报错远远不够。GameCraft-Bench正是冲着这个缺口来的，它在Godot引擎里设计了140个任务、覆盖15类游戏，并且不靠读代码打分，而是把agent生成的游戏真正跑起来、回放玩家操作的录像，再用多模态评委按评分细则判断「这游戏到底能不能玩」。这套思路的价值不在分数本身，而在于它把「agent能不能交付一个完整可运行的交互系统」这件一直难以量化的事，变成了可观测、可复现的基准。结果也很诚实：agent往往能实现看得出来的玩法机制，却在内容完整度、视觉反馈是否真的生效、整体呈现是否连贯上集体掉链子。
原文：GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?
03 训练优化 老师该在哪一层介入小模型的训练？
蒸馏想让小模型学大模型，但在参数差距很大时很脆：逼小学生去模仿大老师的logits，等于把它强行压到老师最尖锐的那几个模式上，结果训练集外的泛化反而塌了。RL换个思路，用学生自己的rollout训练绕开logit模仿，可又撞上老问题——遇到全部尝试都失败的难题，优势为零、整批样本被静默丢弃，学生在这些题上学不到任何东西。ZPPO的切入点很具体：不是改怎么挑数据，而是改老师介入的位置——把老师放进prompt里而不是policy gradient里。难题上它构造两种重写prompt，一种把老师的正确答案和学生的错误答案混在一起让学生去分辨，另一种把学生多次错误的rollout聚合起来暴露共同的失败模式，再配一个replay buffer反复回炉直到这道题的平均准确率过半才「毕业」。在0.8B到9B四个学生规模、27B老师的设置下，ZPPO在31个benchmark上稳定超过蒸馏和GRPO，且越小的模型收益越大。
原文：Zone of Proximal Policy Optimization: Teacher in Prompts, Not Gradients
04 多模态 统一多模态该解耦还是该共享，同一周给出了相反答案
几天前UniDDT还在论证「解耦」——理解和生成各走各的视觉通路，认为强行共享一条路只会两头不讨好。UniAR这篇押的是完全相反的赌注：用一个离散视觉tokenizer同时服务理解和生成，让模型在同一个上下文里直接读懂自己刚生成的视觉token，不用再重新编码一遍。没想到这条「共享」路线真能跑通——靠的是免查表的位运算量化（lookup-free bitwise quantization），既保住高层语义又保住低层细节，还顺手把视觉序列压短、生成提速。结果是图像生成和编辑都做到SOTA，多模态理解也没掉队。两个相反的技术赌注摆在同一周，说明统一多模态的路线之争还没收敛，谁对谁错得看后面谁更能scale。
也值得关注
今日观察
今天三篇互不相关的工作，凑巧在同一处使力：LoopCoder-v2用循环把深度折叠进时间，Looped World Models把同一招搬进世界模型，Variable-Width Transformers则按深度非均匀分配宽度。表面看一个讲推理加速、一个讲世界模型、一个讲架构，但它们其实在回答同一个问题——算力没必要沿深度均匀铺开，可以按每层不同的计算角色去分配。循环是「深度复用」的答法，变宽是「宽度成形」的答法，眼下正在不同任务上同时冒头。这不等于「循环架构是未来」或「静态堆叠已死」，更够不上「架构革命」；准确说，只是「层层等宽、一路堆叠」这个被默认太久的假设，被从几个角度同时松动了一下，能松到哪还不好说。如果你手上有自己的训练栈，不妨挑一个深度敏感的任务，先做个最朴素的对照：把中间几层共享权重循环两次，或者只给中段加宽，看收益曲线在第几层饱和——别等论文给结论，自己的负载才知道这道假设值不值得动。