GitSwarm: Decentralized Compounding Inference
Vedant Shah, Ankur Samanta, Paras Dahal, Mikhail Plekhanov, Carole-Jean Wu, Scott Yih, Remi Munos, Rob Fergus, Jakob Foerster, Ruslan Salakhutdinov, Sanjeev Arora, Jason Weston, Aaron Courville, Anirudh Goyal
cs.AI, cs.LG
2026-10-04
让 agent 群体往共享 Git 仓库提交原子工作供后来者扩展:ProgramBench 79.4% 对 Forced 基线 65.1%,94.7% 的贡献被后续工作引用。
推理时计算的常见玩法,重复采样、拉长推理链、搜索、多 agent 辩论,回答的都是「额外算力怎么花」。这篇问另一个问题:花出去的算力能不能攒下来。episode 一结束,中间的失败实验、半成品解法、被否掉的思路通常随之蒸发,后来的计算可能要把同样的路重新走一遍。对长程求解和科研型任务,这是实打实的浪费:失败实验的方向信息、部分解法里的关键构件,价值往往在当时看不出来。
已有的多 agent 系统靠预定义角色、中央规划器或共享对话协作;另一条线把历史尝试蒸馏成摘要再喂给后续推理。GitSwarm(Meta Superintelligence Labs 联合 Mila、普林斯顿、CMU 等)选择让独立 worker 自己保留互相竞争的工作线索和依赖关系,自己决定接下来做什么。
核心机制一句话:一群同构 agent 异步往一个共享的、可分支的 Git 仓库提交原子 commit,用显式的语义依赖边记录每个贡献建立在哪些先前工作之上。
没有中央智力规划器,harness 只管调度和校验;探索、验证、修复、综合、提名由 worker 看仓库现状自己选。
| 任务 | 设置 | GitSwarm | 对照 |
| ProgramBench(50 题) | Codex(GPT-5.5-high),B=500 | 79.4% | Forced Codex 63.1–65.1% |
| IMOProofBench-Advanced(30 题) | GPT-5.5-high worker | B=40/80 全解 30 题,B=20 解 28 | Gemini-3.1-Pro 版 B=160 解 29.0;bash agent 26.5 |
| RMT(held-out loss) | 72 小时、8 张 H200、1.3B token | 2.890 / 2.894 | 参考架构 3.147 |
| Looped Transformer(protected-dev loss) | 48 小时预算跑到 26 小时 | 3.187 | 参考 3.265;direct GPT 3.274;Codex 3.479 |
| NanoChat(验证 BPB) | 24 活跃小时、16 卡 | 0.993 → 0.905 | 基线曲线见论文图 6 |
ProgramBench 上 GPT-5.5 默认档 worker 从 B=100 的 64.6% 涨到 B=300 的 71.2%,Forced 单 agent 停在 63–65%。收益随预算递减,输入 token 随仓库膨胀而增长。
比分数更难得的是论文直接测了「积累」本身:ProgramBench 上 94.7% 的贡献被后续工作引用,99.9% 的 episode 声明了前序依赖;入选解法的传递祖先覆盖贡献图的 81.6–92.6%,其中只有约四分之一来自 Git 父链,其余靠跨分支依赖连通。负面结果也会被翻旧账,Looped Transformer 任务 74% 的否定性结论后来被引用,NanoChat 是 70.1%。RMT 里有个具体例子:用前一个 token 记忆的思路早期失败,49.5 小时后被另一个 worker 捡回来推广成多滞后 temporal mixer,进了最终架构,而最终架构声明的依赖横跨 24 个 commit、24 个 worker。另一次以三轮先前运行获胜 commit 作种子的运行,28 小时把继承的开发损失从 2.909 压到 2.898,积累跨运行也成立。
对做长程 agent 系统的人,这是一套可以直接照抄的组织方案:commit、branch、diff 是 frontier 模型本来就熟的工具语义,不需要发明新记忆格式;跨分支依赖记录让「谁在谁的基础上做了什么」可审计,对科研型 agent 最有价值。与等预算下被反复催着继续干活的单 agent 相比确实多拿十几个点,说明结构化共享记忆有性能意义,不只是工程整洁。
两点要泼冷水:收益随预算递减,仓库检查的输入开销同步上涨;开发集上去中心化提名输给了中央选择器(64.40% 对 62.06%),去中心化在这里更像设计原则,不是最优解。
论文自己承认的:依赖和 trace 分析只证明「用了」,不证明「因它而赢」,informedby= 是 worker 自报;补上因果需要从同一候选恢复、带与不带历史继续跑的干预实验,论文没做。IMOProofBench 满分是单次运行,带 oracle 验证器的 Best-of-N 在更低 token 消耗下同样到顶,这个 benchmark 已无区分度。RMT 对比里 Codex 单 agent 用 10.1B 训练 token 拿到 2.690,好于 swarm 的 2.890,只是训练预算 8 倍;Looped Transformer 记录时还在跑;NanoChat 各方法起始检查点与 GPU 分配不一致,且胜出模型涨到约 1.72B 参数,改进里有容量成分。
读下来另有几点存疑:ProgramBench 只评 200 题中作者自选的 50 题;仓库膨胀的成本论文承认但没给拐点;全部结果压在前沿 API 模型上,机制与模型能力没拆开。