Online Weight Updates in SGLang

在线权重更新(Online Weight Updates) 指的是：不重启推理服务，直接把训练侧的新参数推送到 sglang 运行中的 inference / rollout engine 中。

为什么它在 RL 里重要

• 大模型 强化学习(Reinforcement Learning) 往往把 trainer 和 rollout engine 分开部署。
• trainer 持续更新 actor 权重，而 rollout 端需要尽快用上新策略去采样。
• 如果每次更新都要落盘、重启、重新加载模型，策略会非常陈旧，训练也会更偏 异策略(Off-Policy)。

它要解决的不是“能不能换权重”，而是“能不能足够快地换”

• 离线换权重并不难，传统 update_weights 甚至可以直接从磁盘重新加载。
• 真正困难的是：如何在 rollout 还在跑的时候，把训练侧参数尽可能快地广播到服务侧。
• 因此这个问题本质上是一个 系统新鲜度(freshness) 与 服务停顿(stall) 的权衡问题。

SGLang 里的基本实现思路

1. 区分离线加载和在线更新

• 传统 update_weights 更像“从一个新的 model path 重新读权重”。
• online_update_weights 更像“训练引擎直接把当前参数通过分布式通信广播过来”。
• 后者更适合 RL，因为 trainer 手里本来就有最新权重。

2. 调用链路是分层下传的

从接口职责上看，链路大致是：

• Runtime 接收上层更新请求。
• TpModelWorker 负责把更新动作传到具体 worker。
• ModelRunner 最终把收到的 [name, weight] 对写入模型。

这说明它不是单个函数的小 patch，而是整条 serving stack 都要支持热更新。

3. 常见通信方式是进程组广播

• RL 系统通常会为 trainer 和 inference engine 建立独立的 process group。
• 默认做法是由源 rank 持有新参数，再通过 NCCL 广播(NCCL Broadcast) 分发到各个推理 worker。
• 对 tensor parallel 场景来说，这一步必须和并行切分方式保持一致。

真正的难点

1. 延迟不只是“广播时间”

• 权重更新延迟常由多部分叠加：参数准备、广播、load 到 module、必要的同步与 barrier。
• 如果测量方法不对，CPU 侧日志还没等 GPU 真做完就已经打印结束，结论会失真。
• 这也是相关文章反复强调 torch.cuda.synchronize() 的原因。

2. 参数格式必须和运行时兼容

• trainer 侧参数名、dtype、分片方式、量化格式，都要和 serving 侧期望一致。
• 一旦存在格式不匹配，就不是“更新慢”，而是根本无法安全热更新。
• 这在低精度或量化 rollout 里会更敏感。

3. cache 与请求状态会变得微妙

• 权重一变，旧请求对应的 logits 分布就不再和新模型完全一致。
• 因此系统需要决定：是等待当前 batch 自然结束后切换，还是接受一小段混杂状态。
• 这也是为什么在线更新天然和 rollout staleness、policy freshness 绑定在一起。

更一般的系统思路

• 小规模系统可以直接全量广播权重。
• 大规模系统则经常会把“周期性全量 checkpoint + 高频 delta 更新”结合起来，以缩短刷新停顿。
• 这类技巧不是 SGLang 独有，但它们解决的是同一个问题：让 rollout 端更快接近当前策略。

一个实用理解

• online weight update 不是训练算法本身。
• 它是 RL 基础设施的一部分，用来控制“采样用的是多新的策略”。
• 在高吞吐 RL 系统里，这个问题往往和 reward 设计同样关键。

相关页面

• 服务实体介绍见 sglang。
• 如果从训练新鲜度角度理解，可结合 on-policy-vs-off-policy-rl。
• 阅读导览见 zhaochenyang20-rl-systems-reading-guide。