专题后训练系统：Rollout、权重同步与策略版本¶

SFT、DPO、RLVR 的算法属于第三册，但强化学习需要的运行系统横跨训练和推理两侧，必须在第二册把接口讲清，否则读者会以为第三册的 RL 是纯算法问题。

T.1 为什么 RL 训练需要一个完整的推理引擎¶

在线强化学习的每一轮是：用当前策略模型批量生成大量 rollout（可能是几万条、每条几千 token）→ 用奖励模型或验证器打分 → 把样本送给训练 worker 更新权重 → 同步新权重回生成端。

生成阶段通常占整个 wall-clock 的 60%–80%。这意味着 RL 训练的效率首先是推理效率问题，用训练框架里那个朴素的 generate() 会慢一个数量级。现代 RL 框架的做法是直接把 vLLM/SGLang 这类引擎嵌进训练流程。

长思维链的兴起让这件事更极端：一条 rollout 可能生成三万个 token，生成侧的成本进一步压倒训练侧。

Colocate：生成和训练轮流使用同一批 GPU。省去跨集群权重传输，硬件利用率高，但要在两种模式间反复切换显存布局（推理引擎的 KV 池和训练的优化器状态不能同时占满显存），工程上很讲究。

分离：生成池和训练池各自常驻。两边都能持续满载、可独立扩缩容，但权重要跨集群同步，而且必然引入策略滞后。

选择取决于生成和训练的耗时比例。比例悬殊且稳定时分离更好；比例接近或波动大时 colocate 更省。

训练侧更新完参数，要尽快让生成侧用上。三个现实问题：

传输量大。几百 GB 的权重，走文件系统会慢到不可接受，成熟做法是走 RDMA 直接做 GPU 到 GPU 的传输。

布局不同。训练侧可能是 FSDP 分片加 TP=8，生成侧可能是 TP=4，同步时要在线重分片。

频率是个权衡。同步越频繁，生成用的策略越新（更符合 on-policy 假设），但停顿和传输开销越大。

为了不让两边互相等待，工业做法通常是异步：生成端一直在产出，训练端一直在消费，两者用的策略版本相差若干步。

系统侧的责任是让这件事可追踪：每条样本必须标记它是由哪个策略版本生成的。至于允许滞后多少步、旧样本要不要重要性加权或直接丢弃，那是第三册的算法问题。系统不做这个决定，但必须提供做决定所需的信息。

本册回答：rollout 怎么高吞吐生成、资源怎么摆、权重怎么同步、版本怎么追踪。第三册回答：奖励怎么定义、优势怎么估计、策略怎么更新、多旧的样本还能用。

两者混写会让算法假设和系统实现都说不清楚——这也是很多 RL 复现失败的原因：照搬了算法，却没有对齐系统层面的同步语义。

Q：为什么不用训练框架自带的生成？ 它为大 batch 前反向优化，没有连续批处理、分页 KV 和变长调度，生成吞吐可能差一个数量级。而生成占 RL 的大头。

Q：Colocate 一定更省吗？ 不一定。切换有开销，且当生成和训练的耗时比例失衡时，总有一边在闲置。

Q：权重必须每步同步吗？ 不必。这是通信成本和策略新鲜度的权衡，由算法的容忍度决定，系统负责把两种模式都支持好。

Q：为什么样本一定要标策略版本？ 否则无法判断数据有多旧，异步训练的正确性就无从谈起。这是系统必须提供的最小保证。