跳到主要内容

论文解读：RLHFless — 用 Serverless 让 RLHF 训练又快又省

· 阅读需 12 分钟
Zhiyuan Pan
Blog Author

解读 RLHFless 论文，将 Serverless 计算引入 RLHF 训练流程，实现更高效的资源利用与成本优化。

论文：RLHFless: Serverless Computing for Efficient RLHF 作者：Rui Wei, Hanfei Yu, Shubham Jain, Yogarajan Sivakumar, Devesh Tiwari, Jian Li, Seung-Jong Park, Hao Wang 机构：Stevens Institute of Technology, Northeastern University, Stony Brook University, Missouri University of Science & Technology 时间：Preprint, Feb 2026 链接：arXiv:2602.22718v1

1. 一句话总结​

RLHFless 是第一个面向 RLHF 训练的 Serverless 框架，通过去重 Prefill、基于长度预测的 Prompt 分配以及动态 Actor 伸缩三大机制，在不牺牲训练质量的前提下，实现了最高 1.35 倍加速和 44.8% 的成本降低。

2. 研究背景与动机​

RLHF 为什么重要？​

大语言模型（LLM）虽然通过海量语料预训练获得了强大能力，但仍可能生成有害或不符合人类偏好的内容。RLHF（Reinforcement Learning from Human Feedback）是目前主流的对齐手段——通过奖励模型（Reward Model）引导策略模型优化，使输出更符合人类期望。DeepSeek-R1 等最新模型也证明了 RLHF 在提升复杂推理能力方面的巨大潜力。

现有 Serverful RLHF 系统的痛点​

RLHF 训练包含三个阶段：Generation（生成）-> Preparation（准备/打分）-> Learning（学习/更新）。现有框架（如 VERL、OpenRLHF）都跑在固定资源的 Serverful 集群上，带来三大低效问题：

  1. 阶段间空闲时间严重：Actor 生成完毕后要等 Learner 更新完才能进入下一轮，期间 GPU 白白闲置。论文图 2 形象展示了多节点场景下大量 IDLE 时间。
  2. 响应长度动态变化导致静态资源浪费：不同 prompt 的回复长度差异巨大（从几十到上千 token），且随训练轮次推进，平均回复长度会持续变化。固定资源分配完全无法适应这种动态需求。
  3. KV Cache 重复计算：很多 prompt 共享前缀（如 "What is the..."），且 GRPO 等算法对同一 prompt 会采样多条回复。并行 Actor 各自独立计算 KV Cache，造成约 22% 的 GPU 时间浪费（以 GRPO + Qwen2.5-3B + GSM8K 为例）。

这三个问题的本质是：Serverful 架构的静态资源分配与 RLHF 动态资源需求之间的根本矛盾。

3. 核心思路​

RLHFless 的核心洞察很直接：Serverless 天然适合 RLHF。

  • Serverless 的弹性伸缩和按需付费模型可以释放空闲组件，降低阶段间浪费；
  • 动态调整 Actor 数量可以追踪变化的工作负载，找到速度和成本的"甜蜜点"；
  • 通过前缀去重和共享 KV Cache，可以消除重复计算；
  • 将相似长度的 prompt 分配到同一 Actor，可以减少 Actor 内部的不均衡。

整体设计围绕一个目标：在每个训练步开始前，构建一个最优的执行计划，包括用多少 Actor、怎么分配 prompt、如何去重 prefill。

4. 方法详解​

4.1 系统总览​

RLHFless 在每个训练步执行五个关键步骤：

  1. 设置 Prefill Actor：分析 prompt 数据集，识别共享前缀，构建去重 batch；
  2. 遍历候选 Actor 数量：用成本感知模块估算不同 Actor 数下的时间和成本；
  3. Prompt 分配：按预测响应长度排序，将相似长度的 prompt 分配到同一 Decode Actor；
  4. Actor 伸缩决策：综合时间和成本，选择最优 Actor 数量 N'；
  5. 执行 RLHF 循环：依次完成 Generation、Preparation、Learning 三个阶段。

4.2 Deduplicated Prefill（去重 Prefill）​

问题：并行 Actor 各自独立做 prefill，对共享前缀的 KV Cache 重复计算。

方案：RLHFless 将 Prefill 和 Decode 解耦为两类 Actor：

  • Prefill Actor：专门负责 KV Cache 的一次性计算。它会分析所有 prompt 的前缀，选择一个最优的共享前缀长度 L，使得去重后的 prompt 数恰好填满 Prefill Actor 的容量。
  • Decode Actor：接收已计算好的 KV Cache，只负责自回归解码。

这样，每个唯一的 KV Cache 只计算一次，然后分发给多个 Decode Actor 复用。对于 GRPO 这种每个 prompt 采样多条回复的算法，节省尤为显著——例如每个 prompt 采样 3 条回复，理论上 prefill 成本直接降低 66%。

4.3 Prompt Assignment with Cut-and-Migrate（Prompt 分配 + 切割迁移）​

问题：如果一个 Actor 里既有短回复又有长回复的 prompt，短的早早结束后 GPU 就闲置了，但 Actor 还得等最长那条跑完。

方案分两步走：

第一步：基于长度预测的排序分配。 RLHFless 用 EWMA（指数加权移动平均）预测每个 prompt 的响应长度——利用前几轮训练中该 prompt 的实际长度作为历史数据。然后将 prompt 按预测长度排序，均匀分配到各 Decode Actor，使同一 Actor 内的 prompt 长度尽可能接近。

关键洞察：RLHF 训练是对固定 prompt 集合的反复采样，约 70% 的 prompt 响应长度在相邻 epoch 间变化不超过 50 token，90% 变化不超过 100 token。所以历史长度是一个非常可靠的估计。

第二步：Cut-and-Migrate 动态纠错。 即使预测再准也会有误差。当一个 Actor 已经完成了 tau x 100% 的任务（tau 是一个阈值，默认 0.7）时，如果还有未完成的长回复，就把这些"拖后腿"的回复切割下来，迁移到其他已经空闲的 Actor 上继续执行。

与之前 RLHFuse 的全局一刀切不同，RLHFless 的迁移是细粒度的——只迁移确实被低估的那几条，而不是同时中断所有 Actor。这大幅减少了迁移开销。

4.4 Cost-Aware Actor Scaling（成本感知的 Actor 伸缩）​

问题：固定 Actor 数量要么浪费资源，要么处理不了突增的长回复。

方案：RLHFless 在每个训练步动态决定最优 Decode Actor 数量 N'。它通过以下公式进行权衡：

$$N' = \arg\min_{N} \left{ \lambda \cdot \tilde{T}^{total}(N) + (1-\lambda) \cdot \tilde{C}(N) \right}$$

其中：

  • $\tilde{T}^{total}(N)$ 是归一化的端到端执行时间（由最慢的 Actor 决定）
  • $\tilde{C}(N)$ 是归一化的总 GPU 成本
  • $\lambda$ 控制速度与成本的偏好（默认 0.7，略偏速度）

执行时间通过预先 profiling 的 TPOT（time-per-output-token）延迟曲线估算，成本则是所有 Actor 的 GPU 时间之和乘以单价。

4.5 Locality-Aware Actor Placement（局部性感知的 Actor 放置）​

为了减少模型同步和 KV Cache 传输的开销，RLHFless 还做了精细的放置策略：

  • Learner + Prefill Actor 同节点放置：两者都是 compute-bound，共享大模型并行策略，同节点可减少权重同步延迟。
  • 最重负载的 Decode Actor 与 Prefill Actor 同节点：这个 Actor 处理最长回复，需要最快拿到 KV Cache。
  • 其他 Decode Actor 按距离递减分配：负载重的近、负载轻的远，使传输延迟可以被执行时间掩盖。

5. 实验设置​

  • 基础框架：基于 VERL（广泛使用的开源 RLHF 框架）构建
  • 推理引擎：vLLM 0.8.3
  • 训练引擎：FSDP（PyTorch Fully Sharded Data Parallel）
  • 硬件：2 台 AWS EC2 g6e.48xlarge 实例，每台 8 张 NVIDIA L40S GPU（384GB 显存），共 16 GPU
  • 模型：Qwen2.5-3B 和 Qwen2.5-7B
  • 算法：PPO 和 GRPO
  • 数据集：GSM8K（数学推理）、GPQA（科学问答）、LiveCodeBench（代码生成）
  • 指标：单步执行时间（秒）和成本（GPU x 秒）
  • 大规模模拟：使用 Vidur 模拟器，模拟最多 20 节点、每节点 8 张 H100 的集群

6. 实验结果​

6.1 整体性能​

配置最大加速最大成本降低
物理集群（3B/7B, PPO/GRPO, 多数据集）1.35x44.8%
大规模模拟（Llama-70B, 最多20节点）1.23x38.7%

关键发现：

  • GRPO 获益更大，因为 GRPO 采样更多回复，Generation 阶段占比更高，优化空间更大。
  • GSM8K 上训练时间最长（因为回复长度变化大），RLHFless 的优化效果也最明显。

6.2 消融实验​

论文用 GRPO + Qwen2.5-3B + GSM8K 做了四组消融，逐步开启三个核心功能：

  1. Raw（无任何优化）：基线
  2. +Deduplicated Prefill：成本有适度降低，幅度取决于数据集和算法
  3. +Prompt Assignment：进一步降低成本，通过减少 Actor 内部的 padding 浪费
  4. +Actor Scaling（完整版）：在保持低成本的同时显著缩短执行时间

每个功能都有增量贡献，三者叠加效果最佳。

6.3 各功能单独效果​

  • Prompt Assignment：相比 RLHFuse 的全局 cut-and-migrate，RLHFless 的排序分配 + 细粒度迁移实现了 12.8% 的额外成本降低，且迁移开销几乎可以忽略。
  • Deduplicated Prefill：有效减少了 prefill token 总量。GRPO 每 prompt 采样 3 条回复时，理论降低 66% 的 prefill 成本。
  • Actor Scaling：能根据工作负载自动找到"加 Actor 带来的加速足以抵消额外成本"的甜蜜点。

6.4 鲁棒性与敏感度​

  • 对预测精度的容忍度高：即使换成精度仅 44% 的模型预测器（RLHFless*），仍能达到 1.22x 加速和 28.9% 成本降低。鲁棒性来源于三点：(1) prompt 分配只依赖相对排序而非绝对值；(2) cut-and-migrate 可以运行时纠错；(3) actor scaling 用的是 profiled TPOT 曲线，削弱了单条预测误差的影响。
  • EWMA 窗口大小：设为 1（只用上一轮数据）就够了，因为早期 epoch 的长度趋势通常是单调的。
  • Cut-and-migrate 阈值 tau：tau=0.7 在成本和速度间取得最佳平衡。更小的 tau 触发更早的切割，减少空闲但增加迁移开销。
  • Actor Scaling 权重 lambda：lambda=0.7 表现最优，略偏向速度优先。

7. 与现有工作的对比​

特性VERL / OpenRLHFRLHFuseRLHFless
资源分配静态静态动态（Serverless）
KV Cache 重复计算有有去重 Prefill 消除
Actor 数量固定固定动态伸缩
Prompt 分配无/随机全局 cut-and-migrate排序分配 + 细粒度迁移
异步训练部分支持否否（同步，保证训练质量）

与异步 RLHF 方案（如 A3PO、AsyncFlow）的区别：异步方法虽然提高吞吐，但会引入 stale data，可能降低训练质量。RLHFless 坚持同步训练，通过优化资源利用来提速，不牺牲收敛性。

8. 核心亮点与局限​

亮点​

  • 首创性：第一个将 Serverless 理念系统性应用于 RLHF 训练的框架。
  • 模块化设计：Deduplicated Prefill、Prompt Assignment、Actor Scaling 三个模块彼此正交，可独立使用，也可集成到其他同步 RLHF 系统（如 OpenRLHF）。
  • 轻量级开销：所有核心组件都是 model-free 的（不需要额外模型训练），Prompt 去重、长度预测、成本估算的开销在总延迟中几乎可以忽略（见论文图 17）。
  • 鲁棒性好：对响应长度预测的精度要求不高，系统仍能稳定获益。

局限​

  • 仅面向同步 RLHF：Actor Scaling 和 Prompt Assignment 的设计原则上可以扩展到异步场景，但论文未做验证。
  • 大规模实验依赖模拟器：受预算限制，70B 模型和 20 节点集群的实验是通过 Vidur 模拟器完成的，与真实部署可能存在差异。
  • 超参数可能需要按场景调优：虽然 tau=0.7、lambda=0.7 在多数场景表现良好，但论文也指出 min-max 归一化的局限性，这些超参数不一定能在所有工作负载上通用。

9. 个人思考​

为什么这篇工作有价值？​

RLHF 训练的成本问题是当前 LLM 开发的核心痛点之一。这篇论文的贡献不在于某个单点技术有多惊艳，而在于系统性地识别了 RLHF 训练中的三大资源浪费模式，并给出了一套协调一致的解决方案。

特别值得注意的是"响应长度可预测"这个洞察——RLHF 训练与 LLM serving 的本质区别在于：训练是对固定 prompt 集合的反复采样，历史长度数据天然可用。论文利用这一特性用极简的 EWMA 就替代了复杂的长度预测模型，既优雅又实用。

未来方向猜想​

  • 与异步 RLHF 的结合：如果能在异步场景中应用 Actor Scaling，可能同时获得异步的吞吐优势和 Serverless 的成本优势。
  • 更大规模验证：当前物理实验最大只到 16 GPU + 7B 模型，在真实的数百 GPU + 70B+ 模型场景下的表现仍需验证。
  • 与 MoE 模型的适配：MoE 模型的推理负载分布更不均匀，Serverless 的弹性可能带来更大收益。

10. 关键术语表​

术语含义
RLHFReinforcement Learning from Human Feedback，基于人类反馈的强化学习
Serverless无服务器计算，按需分配资源、按用量计费
Actor采样 Actor，持有策略模型副本，负责生成回复
Learner训练引擎，负责根据奖励信号更新策略模型权重
KV CacheKey-Value Cache，Transformer 推理时缓存的注意力键值对，避免重复计算
Prefill推理的第一阶段，处理整个输入 prompt 并生成 KV Cache
Decode推理的第二阶段，利用 KV Cache 逐 token 自回归生成
PPOProximal Policy Optimization，近端策略优化算法
GRPOGroup Relative Policy Optimization，用组内相对排名替代 Critic 模型的 RL 算法
EWMAExponentially Weighted Moving Average，指数加权移动平均
Cut-and-Migrate切割并迁移，将超时未完成的回复从一个 Actor 迁移到空闲 Actor
TPOTTime Per Output Token，每个输出 token 的平均生成时间
VERL广泛使用的开源 RLHF 框架，RLHFless 的实现基础
FSDPFully Sharded Data Parallel，PyTorch 的全分片数据并行训练策略