【强化学习与大模型后训练】17｜RL 训练基础设施：采样-训练分离与 PPO 编排

做 LLM 的在线 RL，最容易低估的不是 PPO 公式，而是把采样、打分、训练、同步四件事放到同一个集群里以后，系统会变成什么样。

一个 RLHF 或 RLVR 作业看上去只是“用当前策略生成回答，再按奖励更新策略”。

真正落地时，它同时像推理服务、分布式训练任务、离线数据流水线和实验调度系统。

如果把它当成普通微调脚本，GPU 会在等待采样、等待权重同步、等待奖励模型、等待 critic 之间来回空转。

本文把在线 RL 的工程结构拆开：生成侧为什么通常主导 wall-clock，训练侧为什么不能直接替代推理引擎，actor 与 learner 为什么要同步权重，多模型共驻时显存怎么分配，TRL、OpenRLHF、veRL、NeMo-Aligner、DeepSpeed-Chat 这些框架各自解决哪一层问题。

读完你应该能画出一个 PPO/RLHF 作业的 actor-learner-reward 拓扑，并知道定位吞吐瓶颈时先看哪几条链路。

一、在线 RL 作业不是一次普通微调

1.1 一轮 PPO 的系统视角

从算法看，PPO 只是在旧策略附近最大化裁剪目标。

从系统看，一轮 PPO 至少包含以下阶段。

从 prompt 池抽取一批输入。
用当前策略 \(\pi_\theta\) 自回归生成回答。
用参考模型计算 \(\log \pi_{\mathrm{ref}}\)，用于 KL 惩罚。
用奖励模型、规则验证器或人类反馈代理产生终局奖励。
用 critic 或组内基线估计优势。
把 rollout 样本转换成训练 batch。
对 policy 做 forward、backward、optimizer step。
必要时更新 critic。
把 learner 的新权重同步到 rollout actor。
记录 KL、reward、长度、熵、ratio、clip fraction 等指标。

这十步里，只有第 7 步像传统训练。

第 2 步更像高吞吐推理服务，第 3、4、5 步更像批处理打分，第 9 步更像模型发布。

把这些动作塞进一个进程并不难，难的是让它们在多机多卡上以稳定的节奏运行。

1.2 数据流比损失函数更容易成为瓶颈

SFT 的数据是固定的。

每个 epoch 读取同一批 token，训练端只需要处理 forward、backward 和 optimizer state。

在线 RL 的数据是策略生成出来的。

策略更新以后，下一批回答分布就变了。

这导致数据管线具有闭环结构：policy 生成数据，reward 评价数据，learner 更新 policy，新 policy 再生成下一批数据。

闭环意味着任何一个环节慢下来，整轮训练都会被拖住。

1.3 为什么本文重点讨论 PPO 编排

PPO 是 RLHF 工程里最典型的在线 RL 形态。

DPO、IPO、KTO 这类离线偏好优化不需要 rollout 服务，工程形态更接近普通微调。

GRPO 和 RLVR 虽然可能去掉 critic 或把奖励换成可验证规则，但它们仍然需要“采样—打分—更新—同步”的闭环。

因此 PPO 编排是理解后训练基础设施的共同入口。

在 09｜RLHF 全链路中我们已经讨论过算法流水线；本文只关心系统如何把这条流水线跑起来。

二、采样侧与训练侧必须分开看

2.1 生成是自回归服务

LLM rollout 的核心操作是自回归解码。

给定 prompt \(x\)，策略生成回答 \(y=(y_1,\dots,y_T)\)：

\[ \pi_\theta(y\mid x)=\prod_{t=1}^{T}\pi_\theta(y_t\mid x,y_{<t}). \]

每个 token 都依赖前面已经生成的 token。

这让生成天然是串行的。

即使用 KV Cache，decode 阶段也要一 token 一 token 地走。

训练 forward 可以把整个序列并行放进矩阵乘。

生成 decode 不能把未来 token 提前并行算出来。

这就是 rollout 经常主导 wall-clock 的第一性原因。

2.2 训练是 dense forward + backward

训练侧拿到的是完整序列。

它可以一次性计算所有位置的 logits、value、loss mask 和 token-level objective。

PPO 的 token 级目标可以写成：

\[ L^{\mathrm{clip}}(\theta)=\mathbb{E}_t\left[\min\left(r_t(\theta)A_t,\mathrm{clip}(r_t(\theta),1-\epsilon,1+\epsilon)A_t\right)\right], \]

其中

\[ r_t(\theta)=\frac{\pi_\theta(a_t\mid s_t)}{\pi_{\theta_{\mathrm{old}}}(a_t\mid s_t)}. \]

这一步与 SFT 类似，是大 batch 的 dense 计算。

它的瓶颈通常是 GEMM、激活重算、ZeRO/FSDP 通信、optimizer state 和梯度同步。

它与 decode 侧的瓶颈不同。

2.3 一台引擎很难同时最优

推理引擎优化的目标是连续批处理、KV Cache 管理、请求调度、低延迟 decode。

训练后端优化的目标是参数分片、梯度通信、optimizer state、activation checkpointing。

这两套优化在内存布局、并行策略和 API 上都不一样。

因此工程上常见做法是：rollout 用 vLLM、SGLang 或类似推理引擎；learner 用 FSDP、Megatron-LM、DeepSpeed 或 NeMo 训练栈。

推理侧把 actor 当成服务。

训练侧把 actor 当成可更新参数集合。

两者之间通过权重同步和样本队列连接。

2.4 生成为何通常更慢

如果每个 prompt 生成 \(T\) 个 token，decode 至少需要 \(T\) 次模型调用。

训练侧对同一段序列只需要一次 forward，再加一次 backward。

backward 的 FLOPs 通常高于 forward，但它能在整段序列上并行。

decode 则有严格的时间步依赖。

此外，RL 采样通常需要探索。

为了估计优势或寻找正确答案，同一个 prompt 可能生成多个 candidate。

在 RLVR 场景，数学或代码题常用多样采样扩大搜索空间。

候选数从 1 变成 8，采样成本几乎按候选数放大。

2.5 用推理引擎做 rollout 的动机

vLLM 的 PagedAttention 论文指出，KV Cache 管理是 LLM serving 的关键瓶颈之一。

PagedAttention 把 KV Cache 组织成分页块，减少内存碎片并支持高效调度。

SGLang 也围绕高吞吐生成、结构化解码和服务编排做优化。

在线 RL 的 rollout 正好需要这些能力。

它不是离线跑一个固定 batch，而是要处理变长 prompt、变长回答、不同采样温度、停止条件和并发请求。

用训练框架直接 generate() 可以起步，但通常很快被吞吐和内存管理卡住。

三、actor、learner、reward 与 critic 的拓扑

3.1 四类模型角色

一个完整 RLHF/PPO 作业常常同时包含四类模型。

角色	是否更新	主要作用	常见瓶颈
Policy / Actor	更新	生成回答并在训练时计算新 logprob	rollout decode、训练 backward
Reference	固定	计算 KL 基准，约束策略远离初始模型	forward 显存与吞吐
Reward Model	固定或周期更新	给回答打偏好分或安全分	batch 打分、长序列显存
Critic / Value	更新	估计 value 或 advantage，降低方差	额外参数、value loss 稳定性

RLVR 可以把 reward model 换成规则验证器。

GRPO 可以去掉 critic，用组内相对分数构造优势。

但 policy 与 reference 的关系通常仍然存在，因为 KL 是控制策略漂移的核心工具。

3.2 拓扑图

flowchart LR
    P[Prompt pool] --> A[Rollout actors\nvLLM / SGLang]
    A --> S[Trajectory store\nprompt + response + logprob]
    S --> R[Reward service\nRM / verifier]
    S --> F[Reference model\nlogprob + KL]
    R --> B[Batch builder\nreturns + advantages]
    F --> B
    B --> L[Learner\nFSDP / Megatron / DeepSpeed]
    L --> C[Checkpoint / weights]
    C --> A
    L --> V[Critic update\noptional]
    V --> B
    L --> M[Metrics dashboard\nKL / reward / entropy]

这张图强调三条边。

第一条边是 actor 到 store：采样产生的数据必须携带足够的旧策略信息。

第二条边是 reward/reference 到 batch builder：奖励、KL 与优势需要对齐到同一条 trajectory。

第三条边是 learner 到 actor：权重同步决定采样策略是否足够新。

3.3 trajectory 里应该存什么

最小可训练样本不只是 prompt 和 response。

它通常需要包含：

prompt_ids：输入 token。
response_ids：生成 token。
attention_mask：区分 padding 与有效位置。
old_logprobs：采样时策略的 token logprob。
ref_logprobs：参考模型 token logprob，或稍后批量计算。
rewards：序列级或 token 级奖励。
values：critic 估计值，若使用 actor-critic。
advantages：GAE 或其他优势估计。
returns：value 目标。
stop_reason：EOS、长度截断、规则停止。
metadata：任务类型、难度、采样温度、验证器结果。

少存旧 logprob 会让 PPO ratio 无法正确计算。

少存停止原因会让长度偏置和截断问题难以诊断。

少存 metadata 会让不同任务混在一起，后续分析只能看总均值。

3.4 batch builder 是系统边界

很多框架把 rollout 与 training 之间的转换做成独立模块。

这个模块负责 padding、packing、mask、reward whitening、advantage normalization、micro-batch 切分和数据分发。

它看上去不如模型并行“高级”，但出错概率很高。

例如 response mask 少偏移一个位置，KL 和 advantage 就会对错 token。

例如 prompt token 没有从 policy loss mask 中排除，模型会被奖励驱动去改变 prompt 部分的似然。

例如 EOS 后 padding 没有 mask，value loss 会学习无意义位置。

四、权重同步：actor 与 learner 的关键缝合线

4.1 为什么要同步权重

PPO 要求用旧策略采样，再用新策略在旧样本上做有限步更新。

如果 rollout actor 的权重长期落后 learner，样本就会变得过旧。

PPO ratio 会偏离 1，clip fraction 会升高，有效更新变少。

如果 actor 每个 optimizer step 都同步，系统又会被权重传输拖慢。

因此同步频率是吞吐与 on-policy 程度之间的折中。

4.2 同步粒度

常见同步粒度有三种。

同步粒度	做法	优点	风险
每个 rollout batch	采样一批、训练若干 epoch、同步一次	on-policy 程度高，语义清楚	actor 等 learner，吞吐低
每 N 个 learner step	learner 连续训练，周期推送权重	减少同步开销	样本 stale，ratio 变大
异步流式	actor 持续采样，learner 消费队列并推送	设备利用率高	稳定性与归因更难

严格同步更接近论文算法。

异步更接近生产吞吐优化。

选择哪种，不是纯系统问题，也会影响训练动力学。

4.3 同步内容

同步不一定意味着传完整 checkpoint 文件。

可选内容包括：

完整 policy 权重。
LoRA adapter 权重。
张量并行切片后的权重。
推理引擎内部格式权重。
tokenizer 或 generation config 的版本标识。

若训练使用 LoRA，actor 侧可以加载固定 base model，再热更新 adapter。

若训练使用全参 FSDP，actor 侧可能需要从分片 checkpoint 聚合或转换成推理格式。

这一步若设计不好，会让“训练很快，发布很慢”成为主要瓶颈。

4.4 权重版本号不可省略

每条 trajectory 应该记录采样所用的 policy 版本。

每个 reward、ref logprob、advantage 也应该能追溯到对应数据版本。

否则你看到 reward 下降时，无法判断是新策略变差、reward service 改了、prompt 池换了，还是旧样本混进来了。

一个简单的版本字段就能避免很多复盘困难。

    # 简化示意：rollout 样本中的版本字段
sample = {
    "prompt_ids": prompt_ids,
    "response_ids": response_ids,
    "old_logprobs": old_logprobs,
    "policy_version": "actor-000184",
    "reward_version": "rm-2026-05-29",
    "ref_version": "sft-init-sha256-...",
}

4.5 推理格式转换的工程代价

训练 checkpoint 和推理权重格式经常不同。

训练侧可能是 FSDP shard、Megatron tensor-parallel shard 或 DeepSpeed ZeRO checkpoint。

推理侧可能需要 HuggingFace safetensors、vLLM 可加载格式、张量并行重切分后的文件。

如果每轮都从磁盘落 checkpoint 再转换，吞吐会很差。

高性能系统通常会减少磁盘中转，或只同步增量权重。

这也是 OpenRLHF、veRL 等框架要深入处理权重同步的原因。

五、多模型共驻：显存放在哪里

5.1 显存账本

PPO/RLHF 显存不只存 policy。

粗略账本如下。

项目	训练侧	推理侧	备注
Policy 参数	需要	需要	learner 与 actor 可能各一份
Policy 梯度	需要	不需要	只在 learner 上存在
Optimizer state	需要	不需要	Adam 常比参数更占显存
Activations	需要	少量	训练 backward 需要保留或重算
KV Cache	不需要或少量	需要	rollout decode 的主要动态显存
Reference 参数	可共驻	可独立	只 forward，不更新
Reward 参数	可共驻	可独立	序列级打分
Critic 参数	需要	通常不需要	可与 policy 共享 trunk 或独立

这张表解释了为什么“4 个模型都放同一张卡上”通常不可行。

哪怕模型参数能放下，KV Cache、optimizer state 和 activations 也会挤爆显存。

5.2 colocate 与 disaggregate

共驻（colocate）指多个角色共享同一批 GPU。

分离（disaggregate）指 rollout、reward、learner 使用不同 GPU 池。

共驻的优势是通信路径短、资源利用灵活、部署简单。

共驻的风险是显存竞争强，角色之间互相干扰。

分离的优势是每个池可以按 workload 单独优化。

分离的风险是跨池传输、调度和排障更复杂。

5.3 常见放置方案

小模型或 LoRA 实验可以把 policy、reference、reward、critic 都放在少量 GPU 上。

中等规模 PPO 常用独立 actor 池和 learner 池，reference/reward 作为批量服务部署。

大模型全参 RL 往往需要专门的推理集群做 rollout，训练集群做 learner，二者通过高吞吐队列连接。

RLVR 场景如果奖励是规则验证器，reward 池可能主要消耗 CPU 或沙箱资源，而非 GPU。

代码验证类 RLVR 还要考虑隔离执行、超时、文件系统和安全策略。

5.4 参考模型的优化

Reference model 固定不更新。

它的输出只用于 KL：

\[ \mathrm{KL}_t \approx \log \pi_\theta(a_t\mid s_t)-\log \pi_{\mathrm{ref}}(a_t\mid s_t). \]

因此 reference 可以：

与 policy 共享部分权重，若实现支持。
放在推理侧批量计算 ref logprob。
在 learner 侧与 policy forward 一起计算。
对固定数据缓存 ref logprob，但在线生成数据仍需及时计算。

缓存 ref logprob 要注意 tokenizer、模板和 truncation 版本一致。

任何一个不一致都会污染 KL。

5.5 reward model 的放置

Reward model 常常比 reference 更难放。

它可能需要完整 prompt+response 输入，序列较长。

它可能有多个头：helpfulness、安全、格式、拒答等。

它可能需要 ensemble 或 best-of-n 排序。

如果 reward 速度跟不上 actor，rollout 队列会堆积。

如果 reward 与 actor 共驻，reward forward 又会抢走 rollout decode 的显存和算力。

所以 reward service 经常被单独部署成批量打分服务。

5.6 critic 的两种设计

Critic 可以是独立 value model。

也可以与 policy 共享 trunk，只加 value head。

共享 trunk 省参数，但 policy 更新和 value 更新相互耦合。

独立 critic 更清楚，但多一份模型显存和训练成本。

GRPO 这类方法去掉 critic，本质上是在系统复杂度与样本效率之间做取舍。

这也是 12｜GRPO 值得单独讨论的原因。

六、同步 RL 与异步 RL

6.1 同步循环

同步 PPO 的循环可以写成下面的简化伪代码。

    # 简化示意：同步 PPO 编排
for iteration in range(num_iterations):
    actor.load_weights(learner.current_weights())
    trajectories = actor.generate(prompts, n_samples=k)
    rewards = reward_service.score(trajectories)
    ref_logprobs = reference.compute_logprobs(trajectories)
    batch = build_ppo_batch(trajectories, rewards, ref_logprobs)
    learner.update_policy(batch, ppo_epochs=epochs)
    metrics.log(iteration, batch, learner.state())

这段代码的优点是语义清楚。

第 \(i\) 轮的样本来自第 \(i\) 轮策略。

第 \(i\) 轮训练结束后再进入第 \(i+1\) 轮采样。

缺点也明显：actor 采样时 learner 可能闲着，learner 更新时 actor 可能闲着。

6.2 异步流水线

异步系统把 actor、reward、learner 做成持续运行的 worker。

    # 简化示意：异步 actor-learner
while True:
    if actor.has_capacity():
        actor.enqueue(prompt_source.next(), policy_version=current_actor_version)
    if trajectory_queue.has_items():
        reward_queue.put(reward_service.score(trajectory_queue.get()))
    if learner.can_step() and reward_queue.size() >= min_batch:
        batch = batch_builder.make(reward_queue.get_many())
        new_weights = learner.step(batch)
        weight_bus.publish(new_weights)

异步可以提高设备利用率。

但它引入样本陈旧、版本混合、指标归因和稳定性问题。

如果不限制最大 staleness，learner 可能一直在优化旧策略生成的数据。

6.3 staleness 的度量

可以用 policy version 差来度量样本陈旧：

\[ \Delta_{\mathrm{stale}} = v_{\mathrm{learner}} - v_{\mathrm{sample}}. \]

也可以直接看 PPO ratio 分布。

如果大部分 token 的 \(r_t\) 远离 1，说明样本与当前策略不再接近。

此时即使训练吞吐很高，有效学习也可能很低。

6.4 异步不是免费午餐

异步 RL 在 Atari、机器人和推荐系统中很常见。

LLM 后训练更敏感，因为每条 trajectory 成本高、模型巨大、KL 约束强、奖励模型可能被策略分布影响。

因此很多系统先做同步或半同步，再逐步引入流水线并行。

工程判断是：先保证指标可解释，再追求极限吞吐。

6.5 什么时候同步更合适

以下场景同步更稳。

新奖励函数还在调试。
KL、entropy、length 曲线尚不稳定。
模型规模不大，采样成本可以接受。
需要复现实验或对比算法。
团队还没有成熟的指标与回放系统。

6.6 什么时候异步值得做

以下场景异步更值得投入。

rollout 明显主导总时间。
actor 池和 learner 池资源比例固定。
权重同步链路已经稳定。
指标系统能按版本切片。
reward 或 verifier 能独立水平扩展。
训练目标允许少量 off-policy 偏差。

七、框架生态：它们分别解决什么

7.1 TRL

TRL 是 HuggingFace 生态中的强化学习与偏好优化库。

它适合在 Transformers、Datasets、Accelerate 生态里快速实现 SFT、PPO、DPO 等训练流程。

TRL 的优势是门槛低、API 与 HuggingFace 模型兼容、适合研究与中小规模实验。

它不是为最大规模 actor-learner 分离而生，但非常适合作为算法原型和教学入口。

von Werra 等人发布的 TRL 工作把 Transformer 语言模型上的 RL 训练流程产品化，是很多后续实践的基础之一。

7.2 OpenRLHF

OpenRLHF 关注把 RLHF 训练扩展到更大的模型和更复杂的集群形态。

它支持把训练后端、推理引擎和奖励模型服务组合起来。

Hu 等人 2024 年的 OpenRLHF 技术报告强调高性能 RLHF、Ray 编排、vLLM rollout、ZeRO/FSDP 等能力。

这类框架的价值在于减少“算法代码能跑但集群跑不满”的落差。

7.3 veRL / HybridFlow

veRL 来自 HybridFlow 思路，目标是给大模型 RL 提供灵活且高效的数据流编排。

Sheng 等人 2024 年的 HybridFlow 论文把 LLM RL 训练拆成不同 worker 角色，并强调把 generation、reward、training 这类异构 workload 统一调度。

它的关键词是 hybrid controller 和 flexible dataflow。

对工程团队来说，veRL 的启发是：RL 后训练不只是一个 trainer，而是一个可编排的分布式数据流系统。

7.4 NeMo-Aligner

NeMo-Aligner 属于 NVIDIA NeMo 生态，面向大模型对齐训练。

它依赖 Megatron-Core、张量并行和流水并行等训练能力。

对已经在 NeMo/Megatron 栈上训练基础模型的团队，NeMo-Aligner 的优势是与既有训练基础设施更接近。

它更像训练平台上的对齐扩展，而不是独立的轻量研究库。

7.5 DeepSpeed-Chat

DeepSpeed-Chat 是较早把 RLHF 三阶段流水线系统化的开源工作之一。

Yao 等人 2023 年的 DeepSpeed-Chat 报告把 SFT、reward model training、RLHF training 组织成完整流程，并利用 DeepSpeed 训练优化。

它的历史价值在于让很多工程师第一次看到端到端 RLHF 如何在开源栈中拼起来。

即使今天有更多框架，DeepSpeed-Chat 对“RLHF 是三阶段工程流水线”的表述仍然清楚。

7.6 框架选择的实际问题

选框架时不要只看是否支持 PPO。

更应该问：

是否支持目标模型规模所需的并行策略。
rollout 是否能接入 vLLM 或 SGLang。
权重同步是否避免反复落盘转换。
reward model 或 verifier 是否能水平扩展。
指标是否能按 prompt 集、任务类型、版本切片。
是否支持恢复训练和样本回放。
是否能在你的集群调度系统上稳定运行。

算法接口只是入口。

稳定地跑 1000 个 iteration 才是后训练基础设施的分水岭。

八、PPO 编排中的常见工程陷阱

8.1 old logprob 与新 logprob 混淆

PPO ratio 必须用采样时旧策略的 logprob 与当前训练策略的 logprob 比较。

如果 old logprob 在训练前重新计算，就等于把 ratio 人为拉回 1。

这会让 clip objective 失去意义。

8.2 KL mask 与 loss mask 不一致

KL 应该主要约束 response token。

如果 prompt token 被纳入 KL 或 policy loss，模型会为不可控输入承担惩罚。

如果 EOS 后 padding 没有排除，KL 均值会被 padding 稀释。

8.3 reward scale 漂移

Reward model 的输出尺度不是天然稳定的。

不同 prompt 集、不同长度、不同采样温度都会改变 reward 分布。

如果不做 normalization 或 whitening，advantage 方差会变大，PPO 更新会忽快忽慢。

8.4 rollout 队列无限增长

异步系统里，如果 actor 产出快于 learner 消费，队列会积累旧策略样本。

吞吐看起来很好，训练却越来越 off-policy。

队列长度、样本年龄、版本差都应该进入仪表盘。

8.5 reward service 成为隐形单点

Reward service 一旦超时或版本不一致，训练信号会变脏。

对于规则验证器，还要记录失败类型：编译错误、运行超时、答案格式错误、验证器异常。

把所有失败都记成 0 奖励，会把基础设施故障伪装成模型能力差。

8.6 checkpoint 与 actor 版本错配

训练恢复时，learner checkpoint、optimizer state、actor 权重和 rollout 队列必须一致。

只恢复 learner 而继续消费旧队列，会制造难以解释的 reward/KL 异常。

恢复策略应明确：丢弃旧队列、重算 logprob，还是继续但标注版本边界。

九、基础设施指标应该怎么分层

9.1 系统吞吐指标

系统层至少记录：

rollout tokens/sec。
learner tokens/sec。
reward samples/sec。
actor GPU 利用率。
learner GPU 利用率。
reward GPU 或 CPU 利用率。
权重同步耗时。
队列长度与样本年龄。
每轮 wall-clock 分解。

这些指标回答“卡在哪里”。

9.2 训练动力学指标

算法层至少记录：

mean reward。
reward minus KL 后的训练目标。
KL to reference。
policy entropy。
response length。
PPO ratio 均值与分位数。
clip fraction。
advantage 均值与方差。
value loss。
gradient norm。

这些指标回答“是不是在学，还是在崩”。

下一篇 18｜训练稳定性会把这些信号当成仪表盘展开。

9.3 数据质量指标

数据层至少记录：

prompt 来源和版本。
任务类型分布。
采样温度和 top-p。
拒答率。
格式错误率。
verifier 通过率。
超时率。
被截断比例。
重复 n-gram 或模板化回答比例。

RL 的坏结果经常不是算法坏，而是数据流里混入了错误分布。

9.4 指标必须可切片

全局均值经常掩盖问题。

数学题 reward 上升，写作题质量下降，总均值可能不变。

短回答 KL 稳定，长回答 KL 爆炸，总均值可能只是轻微上升。

因此所有关键指标都应该按任务、长度、prompt 版本、policy 版本、reward 版本切片。

十、和大模型推理基础设施的连接

10.1 rollout 继承推理系统问题

Rollout actor 本质上是高吞吐离线推理服务。

它继承了 Prefill/Decode 分离、KV Cache、continuous batching、张量并行、采样参数等问题。

这些内容在大模型基础设施系列中有更系统的讨论。

对 RL 工程来说，最重要的连接是：生成 token 的成本不是常数，它受 prompt 长度、response 长度、batch 调度和 KV Cache 显存共同影响。

10.2 RL 又改变推理服务的目标

普通在线推理追求低延迟和稳定 SLO；RL rollout 更追求总吞吐、可重复、版本可追踪和采样多样性。

temperature、top-p、max tokens、stop words 在这里都是训练超参。

温度太低会探索不足，温度太高会放大噪声，max tokens 太短会压制推理，太长会放大长度黑客和采样成本。

因此不能把生产聊天服务直接拿来当 RL actor，而不加 logprob、停止原因、采样配置和版本字段。

十一、一个实用的上线前检查表

上线前不要只问“PPO loss 能不能跑”。

更应该逐项确认闭环是否可解释。

算法一致性方面，old logprob 必须来自采样时 actor，ref logprob 必须与 policy 使用同一 tokenizer、模板和截断策略。

KL、policy loss、value loss 的 mask 要对齐 response token，并明确是否排除 prompt、EOS 后 padding 和工具返回。

Reward 的符号、尺度、归一化方式和 advantage whitening 作用域要写入配置。

系统一致性方面，actor、learner、reward、reference 都要有版本号。

权重同步耗时、rollout 队列长度、样本年龄和失败样本类型都要进入日志。

恢复训练时要明确旧队列是丢弃、重算字段，还是继续消费并标注版本边界。

显存与吞吐方面，actor 的 KV Cache 峰值、learner 的 optimizer state、reward model batch size、reference forward 成本都要单独估算。

每轮 wall-clock 应能拆成采样、打分、训练和同步四段。

评测与回滚方面，固定 eval prompt、checkpoint、actor 权重和指标版本要能互相对应。

指标异常时，应能回放对应 prompt、response、reward、logprob 和 policy version。

如果这些条件不满足，训练仍然可以启动，但它更像一次不可复盘的长跑。

十二、小结：先把闭环跑稳，再追求吞吐

LLM 在线 RL 的难点不在“会不会写 PPO loss”。

难点在于把自回归采样、奖励打分、参考模型 KL、critic、policy update 和权重同步组成一个可观测的闭环。

生成侧通常主导 wall-clock，因为 decode 是逐 token 串行过程，并且 RL 需要多样采样。

训练侧需要 FSDP、Megatron、DeepSpeed 这样的分布式后端，因为 backward、optimizer state 和并行通信仍然很重。

actor 与 learner 之间的权重同步，是算法 on-policy 假设与系统吞吐优化之间的缝合线。

多模型共驻时，显存账本比单模型训练复杂得多：policy、reference、reward、critic、KV Cache、optimizer state 都要算进去。

同步系统更容易解释，异步系统更容易跑满，但必须用版本号、样本年龄和 ratio 分布约束 staleness。

一个可靠的 RL 基础设施，最后应该让工程师看到三张图：系统耗时分解、训练动力学仪表盘、数据质量切片。

没有这三张图，任何 reward 上升都可能只是奖励黑客或系统错配。

参考资料

论文与技术报告

John Schulman, Filip Wolski, Prafulla Dhariwal, Alec Radford, Oleg Klimov, 2017, “Proximal Policy Optimization Algorithms”.
Long Ouyang et al., 2022, “Training language models to follow instructions with human feedback”, NeurIPS.
Woosuk Kwon et al., 2023, “Efficient Memory Management for Large Language Model Serving with PagedAttention”, SOSP.
Zhenyu Yao et al., 2023, “DeepSpeed-Chat: Easy, Fast and Affordable RLHF Training of ChatGPT-like Models at All Scales”.
Jian Hu et al., 2024, “OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework”.
Guangming Sheng et al., 2024, “HybridFlow: A Flexible and Efficient RLHF Framework”.

项目与文档

Hugging Face, TRL 项目文档与仓库。
veRL 项目文档与仓库。

← 上一篇：16｜奖励黑客与对齐税　|　下一篇：18｜训练稳定性 →

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-05-29 · rl-posttraining

文章导航

目录