你好，我是 Changyi 👋

TL;DR：Agent execution 的核心在于如何合理并行化 single task——这是 Bitter Lesson 在协作层面的下一题，也是这场 24 小时 hackathon 让我想清楚的事。 最近参加了一个 24 小时的 hackathon，结束之后越想越觉得，新的协作范式和老的已经完全不一样了。这篇文章把我在现场观察到的几个点串一下，更多算是几个我觉得值得后续认真做的方向，谈不上结论。 Hackathon 为什么是好的压力测试？ 之前的合作模型是「人 ↔ 人」。中间多了 agent 之后，如果 agent 还只是人的纯辅助、context 是人的严格子集，问题不大——这其实是过去一年绝大多数日常工作的状态。 但 24 小时 hackathon 是另一回事： deliver 优先级第一，没人有时间审 agent 的每个判断； agent 的 context 和人的 context 事实上已经独立演化，但协作仍然要继续； latency 比 throughput 重要——你跑得再多 task，最终交付的就是一个 demo。 这些约束把日常工作里看不出来的问题一下子全暴露出来，下面所有的现象都是从这里来的。 一次 demo 8 小时报废：多跳协作里 context 一定会丢 我们队里吃了一个完整的亏。队友 a 跑通了一个挺漂亮的 demo，让自己的 agent「把所有代码和内容别加筛选地提交 GitHub、保证能复现」。他把 PR branch 直接发给我；我又把 branch 丢给自己的 agent，让它复现。结果完全！没法！复现——尤其当 a 的环境和 GPU instance 因为忘记充钱被回收掉之后，我们四个人花了快 2 个小时还是没能跑起来那个 demo，直接把之前 8 个小时的努力全废了。 ...

TL;DR 在 LLM 的 RL post-training 中，trainer 每完成一个 optimizer step，就需要把更新后的权重同步给负责 rollout 的 inference engine。在解耦（disaggregated）架构下，这一步长期被视为必须依赖高带宽 RDMA 的环节——同步开销随模型规模线性增长，并主导整个 sync 阶段。 2026 年上半年，学术界、工业界与开源社区几乎同时给出了同一个观察并加以利用：在典型的 RL 学习率下，每个 step 之后真正发生变化的权重只占很小一部分（在 BF16 表示下，超过 99% 的元素逐字节未变）。因此只传输变化的部分（delta），即可将通信量降低约两个数量级，且重建无损、bit-identical。这把权重同步从一个依赖 RDMA 网络的硬件问题，转化为一个如何编码稀疏 delta 的软件问题——使得 RL 训练能够运行在普通以太网，甚至跨数据中心的共享存储之上。 本文先说明这一观察的来源与依据，再以 slime 的实现为完整实例，拆解要落地 delta weight sync 需要在系统的哪些环节进行改动；最后讨论当 rollout 采用低精度（量化）时，这套 delta 故事会遇到的新问题。 1. 背景：weight sync 为什么是瓶颈 现代 RL 框架普遍将 trainer（Megatron / FSDP）与 rollout/inference engine（SGLang / vLLM）解耦：两者采用不同的并行策略与算子实现，往往运行在不同的进程、节点乃至数据中心。由此产生一个不可回避的步骤：每次策略更新后，必须将 trainer 的新权重同步给 inference engine，否则采样所用的是过期策略。 默认做法是 full broadcast：把全部参数从 trainer 广播给所有 inference rank（典型实现是 trainer 的 rank 0 与 inference engine 的所有 rank 组成一个 NCCL 通信组）。其开销随模型规模线性增长，在解耦架构中通常主导整个 sync 阶段。 ...