Rui Wei (Stevens Institute of Technology), Hanfei Yu (Stevens Institute of Technology), Shubham Jain (Stevens Institute of Technology), Yogarajan Sivakumar (Stevens Institute of Technology), Devesh Tiwari (Northeastern University), Jian Li (Stony Brook University), Seung-Jong Park (Missouri University of Science & Technology), Hao Wang (Stevens Institute of Technology)
核心问题与动机:大型语言模型(LLM)通常通过人类反馈强化学习(RLHF)进行后训练,以使其输出与人类偏好对齐。RLHF训练比传统RL资源消耗更大、更复杂,尤其在模型规模增大、分布式训练时,数据传输和模型权重同步成为主要瓶颈。现有的RLHF框架依赖于“有服务器” (serverful) 的基础设施,这种静态资源分配方式难以应对RLHF工作流中动态的资源需求,导致在同步训练过程中,不同组件之间或内部经常出现空闲时间,造成开销和资源浪费。此外,异步或离策略的RLHF方法虽然能提高利用率,但可能因使用过时数据而损害收敛稳定性和最终训练质量。
研究目标与关键洞察:本文旨在解决同步RLHF训练中的资源效率问题。通过分析同步RLHF工作负载,我们发现了三个关键洞察:
1. 采样和学习之间的紧密依赖性,以及并行生成过程中的重复键值(KV)缓存计算,导致了大量不必要的资源浪费。
2. 响应长度的长尾分布导致序列生成过程中出现“掉队者”(stragglers),使得已分配的资源处于空闲状态。
3. 随着训练的进行,同一提示的响应长度可能会变化,使得静态资源分配效率低下。
创新点与主要贡献:基于以上观察,本文提出了RLHFless,这是首个基于无服务器(serverless)计算环境的可扩展同步RLHF训练框架,旨在提高效率并降低成本。其主要贡献如下:
* 提出RLHFless框架:这是首个用于RLHF的无服务器训练框架,能够在加速训练的同时降低成本。
* 设计去重预填充机制(Deduplicated Prefill):通过预先计算共享前缀的KV缓存,避免了RLHF中并行的重复计算。
* 提出响应长度预测与调度策略:利用响应长度预测方法和一种“剪切-迁移”(cut-and-migrate)的回退策略,来指导工作负载调度和Actor的动态扩展。
* 实现与评估:在VERL【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】框架之上实现了RLHFless,并在物理集群和大规模模拟集群上进行了评估。实验表明,与最先进的基线相比,RLHFless最多可实现1.35倍的加速和44.8%的成本降低。
方法局限性:RLHFless主要关注同步RLHF训练。尽管其Actor扩展和提示分配设计是正交的,可以适度调整后集成到异步RLHF系统中,但本文未进行此扩展,将其留作未来工作。
RLHF训练流程:从人类反馈中进行强化学习(RLHF)是一种通过将反馈纳入训练循环来使语言模型行为与人类偏好对齐的方法。它将对齐任务构建为一个RL问题,其中策略模型(即LLM)$π_θ$被优化以生成能够最大化预训练奖励模型(RM)$r_ϕ(x, y)$预测奖励的输出。RLHF训练包含多个迭代步骤,每个步骤包括三个主要阶段,如图1所示:
1. 阶段1 生成(Generation):对于一批来自提示数据集的提示$x$,会启动多个采样Actor,使用策略$π_θ$生成一个或多个候选响应$y$。每个Actor都维护着策略模型的副本。
2. 阶段2 准备(Preparation):RM $r_ϕ(x, y)$为每个生成的响应分配一个标量分数。为了防止策略偏离其原始行为太远,许多算法【31, ReMax: A Simple, Effective, and Efficient Reinforcement Learning Method for Aligning Large Language Models, 2024, arXiv】【54, DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, 2024, arXiv】【81, Secrets of RLHF in Large Language Models Part I: PPO, 2023, arXiv】会引入当前策略$π_θ$与参考模型$π_0$之间的KL散度惩罚。
3. 阶段3 学习(Learning):一个配备了训练引擎【48, DeepSpeed: System Optimizations Enable Training Deep Learning Models with Over 100 Billion Parameters, 2020, KDD】【78, PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel, 2023, arXiv】的学习器(Learner)负责计算梯度并使用前几个阶段产生的数据更新策略模型。
现有RL框架为何不适用:现有的RL框架【33, RLlib: Abstractions for Distributed Reinforcement Learning, 2018, arXiv】【37, SRL: Scaling Distributed Reinforcement Learning to Over Ten Thousand Cores, 2024, arXiv】【63, AgileRL】【71, Nitro: Boosting Distributed Reinforcement Learning with Serverless Computing, 2025, VLDB】【73, Cheaper and Faster: Distributed Deep Reinforcement Learning with Serverless Computing, 2024, AAAI】【74, Stellaris: Staleness-Aware Distributed Reinforcement Learning with Serverless Computing, 2024, SC】【85, MSRL: Distributed Reinforcement Learning with Dataflow Fragments, 2023, USENIX ATC】并非为支持LLM规模和复杂度的RLHF而设计。传统RL工作负载涉及可在少量GPU上训练的小模型,并依赖于简单的同步架构。相比之下,LLM训练需要使用数据、张量和流水线并行【25, OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework, 2024, arXiv】【48, DeepSpeed: System Optimizations Enable Training Deep Learning Models with Over 100 Billion Parameters, 2020, KDD】【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】【78, PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel, 2023, arXiv】等技术将模型分布在多个GPU上,并配合专门的推理【29, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023】【57, Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism, 2020, arXiv】【80, SGLang: Efficient Execution of Structured Language Model Programs, 2024, arXiv】和训练【48, DeepSpeed: System Optimizations Enable Training Deep Learning Models with Over 100 Billion Parameters, 2020, KDD】【78, PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel, 2023, arXiv】引擎。此外,在RLHF中扩展采样Actor的数量会增加对同步副本的需求,导致昂贵且缓慢的权重同步【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】。因此,各种针对RLHF优化的框架【25, OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework, 2024, arXiv】【55, NeMo-Aligner: Scalable Toolkit for Efficient Model Alignment, 2024, arXiv】【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】【65, TRL: Transformer Reinforcement Learning, 2020】【70, DeepSpeed-Chat: Easy, Fast and Affordable RLHF Training of ChatGPT-like Models at All Scales, 2023, arXiv】被实现以应对这些新挑战。
图1: RLHF在一个训练步骤中的数据流,包括生成阶段、准备阶段和学习阶段。一些细节,如Critic模型的使用,可能因具体算法而异。
RLHF面临的关键挑战源于其RL特性和LLM的使用。RL循环继承了传统RL中常见的资源效率低下问题,这主要是由依赖组件之间的空闲时间造成的。对于LLM,策略模型生成的响应长度各不相同,并且模型不断更新,导致工作负载和资源需求动态变化。现有的RLHF框架【25, OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework, 2024, arXiv】【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】【86, slime: An LLM post-training framework for RL Scaling, 2025】依赖于Serverful基础设施,无法解决RL循环和单个RLHF组件内部的问题。
1) 从外部RL循环看:Serverful平台上的空闲组件导致资源浪费。 在这种设置中,不同RLHF阶段的组件相互依赖,常常导致某些阶段GPU资源闲置。图2(a)展示了GRPO【54, DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, 2024, arXiv】算法在独立部署(每个模型使用一组独立的GPU)下的工作流程,该算法是DeepSeek R1【12, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, 2025, arXiv】的默认RLHF算法。图2(b)展示了在使用VERL【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】(一种广泛采纳的RLHF框架)提供的GRPO模型放置方案之一时,使用Qwen2.5-3B模型【4, Qwen2.5 Technical Report, 2025, arXiv】和GSM8k数据集【7, Training Verifiers to Solve Math Word Problems, 2021, arXiv】的单步训练延迟分解。虽然一些RLHF工作【14, AReaL: A Large-Scale Asynchronous Reinforcement Learning System for Language Reasoning, 2025, arXiv】【19, Evolving SkyRL into a Highly-Modular RL Framework, 2025】【20, AsyncFlow: An Asynchronous Streaming RL Framework for Efficient LLM Post-Training, 2025, arXiv】【86, slime: An LLM post-training framework for RL Scaling, 2025】试图通过将阶段性RLHF转为异步工作来解决此问题,但先前研究表明,异步训练会因过时数据引入的不一致性而降低最终训练质量【14, AReaL: A Large-Scale Asynchronous Reinforcement Learning System for Language Reasoning, 2025, arXiv】【30, A-3PO: Accelerating Asynchronous LLM Training with Staleness-aware Proximal Policy Approximation, 2026, arXiv】【41, Asynchronous RLHF: Faster and More Efficient Off-Policy RL for Language Models, 2025, arXiv】【79, Prosperity before Collapse: How Far Can Off-Policy RL Reach with Stale Data on LLMs?, 2025, arXiv】。现有的先进同步RLHF解决方案【25, OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework, 2024, arXiv】【55, NeMo-Aligner: Scalable Toolkit for Efficient Model Alignment, 2024, arXiv】【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】通过优化模型放置策略——选择性地将不同组件共置在同一组资源上——来解决此问题。然而,这带来了一个困难的权衡:分开部署组件会导致GPU利用率不足,而共置它们则容易导致内存溢出(OOM)错误、模型上下文切换延迟或组件间的性能干扰【55, NeMo-Aligner: Scalable Toolkit for Efficient Model Alignment, 2024, arXiv】【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】【83, DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, 2024, arXiv】。
2) 跨训练步骤:动态响应长度使静态资源分配效率低下。 近期研究表明,在RLHF的生成阶段,每个训练步骤的平均响应长度会随着训练轮次的增加而呈现增长或减少的趋势【12, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, 2025, arXiv】【58, A Long Way to Go: Investigating Length Correlations in RLHF, 2024, arXiv】【60, Kimi k1.5: Scaling Reinforcement Learning with LLMs, 2025, arXiv】。我们使用GSM8k数据集对不同的RLHF算法和模型组合进行了实验,以验证这一模式,结果如图4(b)所示。对于大多数大规模推理模型,响应长度会随着训练轮次的增加而变长【12, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, 2025, arXiv】【60, Kimi k1.5: Scaling Reinforcement Learning with LLMs, 2025, arXiv】。更长的响应长度会由于LLM的逐个token自回归生成而延长推理时间,这表明每个训练步骤都存在动态的资源需求。而Serverful平台通常采用静态资源分配且启动时间较长,无法适应这种动态的资源需求。
3) 在每个训练步骤中:冗余的KV缓存计算导致不必要的成本。 当LLM生成响应时,首先会处理一次提示以在预填充(prefill)阶段构建KV缓存,然后在解码(decoding)阶段使用该缓存生成token【11, Transformer-XL: Attentive Language Models Beyond a Fixed-Length Context, 2019, arXiv】【64, Attention Is All You Need, 2023, arXiv】。许多RLHF算法会为每个提示生成多个响应【54, DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, 2024, arXiv】【75, DAPO: An Open-Source LLM Reinforcement Learning System at Scale, 2025, arXiv】【77, VAPO: Efficient and Reliable Reinforcement Learning for Advanced Reasoning Tasks, 2025, arXiv】【81, Secrets of RLHF in Large Language Models Part I: PPO, 2023, arXiv】,并且许多数据集中的提示共享大量前缀。因此,相同或相似的预填充计算经常被不必要地重复。之前的LLM服务工作通过为具有共享前缀的提示重用KV缓存来降低此成本【29, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023】【35, CacheGen: KV Cache Compression and Streaming for Fast Large Language Model Serving, 2024, arXiv】【59, You Only Cache Once: DecoderDecoder Architectures for Language Models, 2024, arXiv】【67, Efficient Streaming Language Models with Attention Sinks, 2024, arXiv】。一些RLHF系统,如VERL【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】,也应用了这一思想,将提示分成更小的批次,计算一次KV缓存,并在同一训练步骤内的不同批次间重用它,如图3(a)所示。虽然这种方法减少了重复的预填充计算,但它强制了批次间的顺序执行。在静态GPU资源分配下,这种串行化增加了总生成时间并限制了并行性。有人可能会尝试并行化生成以提高吞吐量;然而,这会导致相同的KV缓存被不同的并行工作者独立地重新计算,从而导致不必要的GPU资源浪费,如图3(b)所示。图3(c)显示,在GSM8K上使用Qwen2.5-3B运行GRPO并为每个提示生成四个响应时,大约22%的总GPU时间用于冗余的KV缓存计算。
图2: (a) RLHF的阶段性工作流导致组件间出现空闲时间。(b) 空闲组件和 (c) RLHF中的重复计算导致资源浪费。
图3: 现有的针对采样密集型RLHF工作负载的生成策略【25, OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework, 2024, arXiv】【29, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023】【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】【80, SGLang: Efficient Execution of Structured Language Model Programs, 2024, arXiv】,包括(a) 迭代生成,这会引入额外延迟,和(b) 并行生成,这会导致(c) 不必要的KV缓存重计算。
图4: 由以下原因导致的动态资源需求:(a) 在不同类型的数据集(如数学问题【36, American Invitational Mathematics Examination (AIME) 2024 Dataset, 2025】、一般科学问题【50, GPQA: A Graduate-Level Google-Proof Q&A Benchmark, 2024, First Conference on Language Modeling】和编程任务【28, LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code, 2024, arXiv】)之间和内部,响应长度差异显著;(b) RLHF训练期间响应长度的变化。
4) 在Actor内部:变化的响应长度导致GPU利用率不足。 由于响应长度的巨大差异,采样Actor可能会消耗截然不同的计算资源。在单个Actor内部,一些响应可能仅在几个解码步骤后就提前终止,而其他响应则可能持续更长时间,即使大多数响应已经完成,也会延长生成阶段【84, Optimizing RLHF Training for Large Language Models with Stage Fusion, 2024, arXiv】。这种不平衡导致GPU利用率低下,因为某些计算资源在等待最长响应完成时处于空闲状态。图4(a)展示了使用Qwen2.5-3B模型在三个不同训练数据集(包括AIME2024【36, American Invitational Mathematics Examination (AIME) 2024 Dataset, 2025】、GPQA【50, GPQA: A Graduate-Level Google-Proof Q&A Benchmark, 2024, First Conference on Language Modeling】和LiveCodeBench【28, LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code, 2024, arXiv】)上的响应长度不平衡情况,最大响应长度为1024。
我们通过识别以下机遇来解决§2.2中提到的问题,并提出了首个无服务器RLHF系统。
无服务器可以按时释放空闲组件以减少浪费。 无服务器的弹性和“按使用付费”的执行模式可以通过仅在需要时启动组件并在其空闲时迅速释放来降低训练成本,正如先前的无服务器RL系统【71, Nitro: Boosting Distributed Reinforcement Learning with Serverless Computing, 2025, VLDB】【73, Cheaper and Faster: Distributed Deep Reinforcement Learning with Serverless Computing, 2024, AAAI】【74, Stellaris: Staleness-Aware Distributed Reinforcement Learning with Serverless Computing, 2024, SC】所示——这激发了无服务器RLHF的设计。
扩展Actor以适应变化的资源需求。 无服务器使得根据变化的工作负载调整Actor数量,并寻找“最佳点”(sweet spots)成为可能,即额外的并行性足以缩短步骤时间以降低总成本;实现这一点需要一个成本模型来指导扩展决策,而在Serverful平台上由于启动延迟长【3, AWS Elastic Compute Cloud, 2025】【17, GCP Compute Engine Instance, 2025】【39, Microsoft Azure Virtual Machines, 2025】,这更加困难。
在无服务器环境中通过去重预填充来减少重复计算。 通过预先将具有共享前缀的提示分组,并利用那些为每个提示采样多个响应的算法(例如,GRPO【54, DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, 2024, arXiv】),我们可以计算一次预填充并将其在多个响应中重用——目标是减少冗余计算(而不是提高服务吞吐量)。
将长度相似的提示分组到同一Actor中以解决工作负载不平衡问题。 由于Actor的成本取决于执行时间,少数长响应会使一个Actor保持活动状态,而其他资源则处于空闲状态;预测响应长度并将长度相似的提示共置可以让一些Actor更快完成并提前释放。
我们设计了一个无服务器RLHF训练系统,RLHFless,以实现三个主要目标:
1. 加速端到端的RLHF训练过程。 由于响应长度的变化导致生成阶段存在动态资源需求,我们旨在通过调整Actor数量以满足这些变化的资源需求来加速该过程。
2. 减少每个训练步骤中的冗余计算。 许多RLHF算法【54, DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, 2024, arXiv】【75, DAPO: An Open-Source LLM Reinforcement Learning System at Scale, 2025, arXiv】【77, VAPO: Efficient and Reliable Reinforcement Learning for Advanced Reasoning Tasks, 2025, arXiv】中的共享提示前缀和多响应生成导致生成过程中的KV缓存计算重复,从而产生不必要的成本。我们旨在通过去重预填充来减少这种开销。
3. 提高RL组件内部的资源效率。 分配给单个Actor的响应长度可能差异很大,异常长的响应会延长Actor的执行时间,同时导致GPU利用率低下。我们的目标是减少由各Actor内部工作负载不平衡造成的资源浪费。
图5: RLHFless概览。
为实现这些目标,必须解决三个挑战:
* 如何在加速与成本之间进行权衡? 增加Actor数量可以加速生成阶段,但通常会增加资源成本。为了找到成本最低、时间最短的平衡点甚至最佳点,需要准确估计成本和执行时间。
* 如何提高RLHF中的预填充效率? 使用资源较少的去重预填充Actor可以通过仅计算每个提示一次来降低成本。然而,分配过少的资源可能会减慢预填充阶段,从而给整个RLHF训练过程带来延迟。
* 如何最小化每个Actor内部的空闲时间? 将响应长度相似的提示分组到同一个解码Actor中可以减少GPU利用率不足并节省成本。为了有效地做到这一点,我们需要在分配前对响应长度进行估计。
RLHFless是首个专为无服务器平台设计的RLHF训练系统。它利用无服务器计算的弹性和细粒度资源管理来促进RLHF训练。图5展示了RLHFless的架构和工作流程。在每个训练步骤中,RLHFless执行五个主要步骤:
1. 步骤1:设置预填充Actor。 RLHFless分析提示数据集或算法特定的超参数,以识别出一批去重后的共享前缀。这些共享的提示被分配给一个专用的预填充Actor,该Actor计算初始的KV缓存,供所有解码Actor在解码阶段重用。
2. 步骤2:迭代所有可用的Actor数量。 RLHFless采用一个成本感知规划模块,来估计在一系列可能的Actor数量下,以及相应的提示分配策略下的执行时间和总成本。
3. 步骤3:在解码Actor之间分配提示。 在计算给定Actor数量和工作负载的扩展分数时,RLHFless首先生成一个相应的提示分配计划,以便更好地估算成本和时间。RLHFless利用历史训练数据来预测当前训练批次中每个提示的响应长度。然后,它按估计的长度对提示进行排序,并将它们均匀地分配到$N'$个解码Actor中,将长度相似的提示分组,以最小化资源浪费并提高Actor效率。
4. 步骤4:扩展解码Actor。 提示分配模块返回给定Actor数量的工作负载分配计划及其对应的执行时间和成本估算。基于这些结果,RLHFless的Actor扩展模块通过平衡加速与资源效率,选择最优的Actor数量$N'$及其相应的工作负载分配计划。
5. 步骤5:执行RLHF循环。 在为下一个训练步骤的生成阶段生成执行计划后,RLHFless启动该步骤并执行三个RL阶段,包括5a生成、5b准备和5c学习,遵循传统RLHF系统的结构。训练过程重复这五个步骤直至完成。
图6: RLHFless的去重预填充设计。
重复计算的来源与解决方案。RLHF算法【2, Back to Basics: Revisiting REINFORCE Style Optimization for Learning from Human Feedback in LLMs, 2024, arXiv】【24, REINFORCE++: An Efficient RLHF Algorithm with Robustness to Both Prompt and Reward Models, 2025, arXiv】【54, DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, 2024, arXiv】【75, DAPO: An Open-Source LLM Reinforcement Learning System at Scale, 2025, arXiv】【77, VAPO: Efficient and Reliable Reinforcement Learning for Advanced Reasoning Tasks, 2025, arXiv】在一个训练步骤的生成阶段存在重复的KV缓存计算,原因有二:1)训练数据集中提示之间存在共享前缀,2)为单个提示生成多个响应。因此,预填充阶段所需的唯一KV缓存计算次数通常少于解码阶段执行的响应生成次数。现有的serverful RLHF框架【25, OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework, 2024, arXiv】【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】忽略了这一特性,并在整个训练过程中分配静态资源。相比之下,无服务器计算提供了按使用付费的模型,使我们能够通过应用去重预填充-解码设计来降低成本。这使得我们能够仅为预填充Actor分配必要的资源,并精确地计算每个唯一的KV缓存一次。由于预填充Actor与学习器一样是计算密集型【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】【83, DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, 2024, arXiv】,我们为这两个组件统一了资源分配和模型并行策略。
确定目标共享前缀长度。我们接下来使用基于性能分析的容量模型来估算其最大预填充批次大小 $B_{\text{prefill}}$。然后,RLHFless选择一个目标共享前缀长度L,以便预填充Actor能够被去重后的提示填满容量。具体来说,设$X$为训练提示集,定义一个候选前缀长度$L \in [L_{\min}, L_{\max}]$,其中
对于一个候选前缀长度$L$,设$D(L)$为$X$中长度为$L$的唯一前缀数量(即,前缀长度为$L$时的去重提示数量)。RLHFless遍历$L \in [L_{\min}, L_{\max}]$并选择最大的$L$,使得
$$D(L) \leq B_{\text{prefill}}$$随着$L$的增加,$D(L)$会减少;当$D(L)$首次满足$D(L) \le B_{\text{prefill}}$时,预填充Actor被充分利用,并在其容量内计算了最大数量的去重KV缓存。
现有策略的局限性与RLHFless的改进。由于在单个采样Actor内生成的响应长度各不相同,当大多数序列提前完成而只有少数长响应仍在进行时,GPU利用率会下降。先前的工作【84, Optimizing RLHF Training for Large Language Models with Stage Fusion, 2024, arXiv】提出了一种“剪切-迁移”(cut-and-migrate)策略,即在序列生成中途打断,并将所有未完成的响应迁移到一个Actor中,以便为其他任务(如准备阶段的任务)节省资源。然而,这种剪切-迁移方法由于在迁移未完成响应时需要进行数据传输,会引入额外的开销。此外,该方法同时中断所有Actor,只能以粗粒度的方式回收资源,这与无服务器计算的细粒度资源管理原则相冲突。
动态排序的提示分配策略。为了在无服务器环境中实现高效的剪切-迁移,我们提出了一种新颖的基于动态排序的提示分配策略,如图7(a)所示,该策略通过最小化被剪切的响应数量,显著降低了传输成本。这种方法通过允许Actor在不同时间终止,以更细的粒度释放空闲资源,同时保持每个Actor内部的工作负载平衡。如图7(b)所示,将具有相似预测响应长度的提示分组到同一个Actor中,可以通过允许每个Actor提前终止来减少这种低效率,从而节省GPU时间和成本。为了实现这一点,我们需要一个响应长度预测器来提前估算工作负载。
图7: (a) RLHFless的提示分配设计,以及(b) 在使用Qwen2.5-3B【4, Qwen2.5 Technical Report, 2025, arXiv】模型和GSM8k【7, Training Verifiers to Solve Math Word Problems, 2021, arXiv】数据集的GRPO训练下可以实现的潜在收益。
响应长度估计。提前准确估计响应生成工作负载对于以成本效益的方式将提示分配给Actor至关重要。具体来说,我们需要在启动处理提示的Actor之前,预测每个提示的预期响应长度。最近的一些工作提出了响应长度预测方法以提高LLM服务效率【16, Efficient LLM Scheduling by Learning to Rank, 2024, arXiv】【46, Efficient Interactive LLM Serving with Proxy Model-based Sequence Length Prediction, 2024, arXiv】【82, Response Length Perception and Sequence Scheduling: An LLMEmpowered LLM Inference Pipeline, 2023, arXiv】。然而,这些方法通常需要对LLM进行微调以执行自我预测【82, Response Length Perception and Sequence Scheduling: An LLMEmpowered LLM Inference Pipeline, 2023, arXiv】,或者训练一个外部代理模型【16, Efficient LLM Scheduling by Learning to Rank, 2024, arXiv】【46, Efficient Interactive LLM Serving with Proxy Model-based Sequence Length Prediction, 2024, arXiv】。这两种选择都会产生不可忽视的训练和预测成本,通过引入一个额外的预测器训练阶段而增加了复杂性。此外,由于LLM输出的随机性,响应长度预测本身就很困难。即使是为LLM服务提高吞吐量的最先进(SOTA)方法,其token长度预测准确性仍然有限【16, Efficient LLM Scheduling by Learning to Rank, 2024, arXiv】【46, Efficient Interactive LLM Serving with Proxy Model-based Sequence Length Prediction, 2024, arXiv】【82, Response Length Perception and Sequence Scheduling: An LLMEmpowered LLM Inference Pipeline, 2023, arXiv】。
利用历史数据进行预测。在RLHF的背景下,一个关键优势是我们既可以访问训练数据集,也可以访问先前训练步骤的历史响应长度数据。与LLM服务中必须为每个用户输入从头进行预测不同,RLHF训练涉及对一组固定提示的重复采样。此外,我们的系统设计不需要精确的响应长度估计;相反,它仅依赖于按预期响应长度对提示进行的相对排序。只要这个排序在不同步骤之间保持相对稳定,我们就可以做出有效的分配决策。为了验证这一点,我们使用Qwen2.5-3B模型在GSM8K数据集上跟踪了PPO训练过程中每个提示的响应长度变化,最大token限制为2048。大多数响应长度随时间表现出一致的趋势,并且在步骤之间没有剧烈波动。大约70%的响应长度在两个连续的epoch中变化不超过50个token,约90%的变化不超过每个epoch 100个token。这表明我们可以使用前一个训练步骤中观察到的历史响应长度作为当前步骤的可靠估计器,从而无需使用昂贵的基于模型的预测器【16, Efficient LLM Scheduling by Learning to Rank, 2024, arXiv】【46, Efficient Interactive LLM Serving with Proxy Model-based Sequence Length Prediction, 2024, arXiv】【82, Response Length Perception and Sequence Scheduling: An LLMEmpowered LLM Inference Pipeline, 2023, arXiv】。至于没有历史长度数据的第一个epoch,我们可以利用训练数据集中的真实答案作为临时估计。我们采用常见的指数加权移动平均(EWMA)算法,将历史数据作为输入,并输出每个提示的长度估计。
RLHFless中的剪切与迁移。即使有相当准确的响应长度估计,错误的分配仍然可能发生。例如,如果实际响应很长的提示被错误地分配给了为短响应设计的Actor,由此产生的执行延迟会降低整体成本效率。为解决此问题,我们提出了一种新颖的剪切-迁移策略。与现有方法同时终止所有Actor的执行不同,RLHFless在执行期间动态纠正预测错误,保留了提示分配的好处。
处理预测错误。我们将预测错误分为两类:1) 高估:当一个实际响应较短的提示被放置在为长响应设计的Actor中时,由于提示提前完成,剩余时间被浪费,导致GPU利用率不足。2) 低估:当一个响应较长的提示被放置在分配给短响应的Actor中时,它会延长Actor的执行时间。为了减轻预测错误的影响,我们应用了一种受现有工作【84, Optimizing RLHF Training for Large Language Models with Stage Fusion, 2024, arXiv】启发的剪切-迁移策略,如图8所示。在执行期间,如果一个Actor因长时间运行的提示而延迟,并且有其他可用的正在运行的Actor,我们会终止这些生成,并将它们迁移到有可用空位的Actor中,这些空位是由已完成生成的高估响应释放出来的。这种方法有助于减少尾部延迟并提高整体GPU利用率。终止一个Actor的时机由一个剪切阈值$τ \in (0, 1]$控制。当一个Actor分配的响应中有$τ \times 100\%$完成生成时,该Actor将被终止。该阈值在等待掉队者和最小化资源浪费之间取得了平衡,使系统能够释放大部分GPU资源,同时将剩余的长响应卸载到其他Actor。
图8: RLHFless的剪切-迁移策略。RLHFless剪切未完成的被低估的响应,并将它们迁移到有空闲槽位的可用解码Actor中,这些槽位由已完成的、被高估的响应释放出来。
动态扩展的必要性。在RLHF训练过程中,平均响应长度不断变化,导致传统RLHF框架中各训练步骤的执行时间动态变化。在静态资源分配下,这要么在需要较少资源时导致资源浪费,要么在长响应无法被高效处理时导致解码缓慢。因此,即使现有的serverful RLHF系统能够优化生成策略,它们也无法持续达到低成本和高速度的最佳点,因为工作负载在每个步骤都在变化,而资源和Actor数量保持不变。这突显了动态调整Actor数量以匹配不断变化的资源需求的机会。
RLHF中Actor扩展的独特性。先前的研究【71, Nitro: Boosting Distributed Reinforcement Learning with Serverless Computing, 2025, VLDB】【73, Cheaper and Faster: Distributed Deep Reinforcement Learning with Serverless Computing, 2024, AAAI】已经展示了无服务器计算的弹性在传统RL训练中进行Actor扩展的潜力,这表明在无服务器RLHF系统中实现成本感知的Actor扩展是可行的。然而,在RLHF中扩展Actor数量与传统RL有所不同。以前的Actor扩展方法要么依赖于一个预训练的调度器【73, Cheaper and Faster: Distributed Deep Reinforcement Learning with Serverless Computing, 2024, AAAI】,这会引入额外成本,要么利用策略模型的Hessian矩阵来评估数据需求【71, Nitro: Boosting Distributed Reinforcement Learning with Serverless Computing, 2025, VLDB】。后一种方法随着策略模型大小增加到数十亿参数,可能会产生巨大的计算开销。此外,在典型的RL中,Actor扩展通过调整Actor数量来改变训练数据的量,而在RLHF中,改变Actor数量主要是为了调整生成阶段分配的GPU资源,以适应每个训练步骤中不断变化的资源需求。
数据并行与Actor数量。先前的工作已经充分证明,生成阶段是内存密集型的,通过部署更多的模型副本来并发处理提示,可以实现更高的数据并行度,从而获得更高的性能【32, AlpaServe: Statistical Multiplexing with Model Parallelism for Deep Learning Serving, 2023, arXiv】【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】【83, DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, 2024, arXiv】【84, Optimizing RLHF Training for Large Language Models with Stage Fusion, 2024, arXiv】。在RLHF中,每个采样Actor都维护策略模型的一个副本,这意味着Actor的数量实际上决定了数据并行的大小。因此,增加数据并行度直接对应于扩展Actor的数量。然而,通过扩展Actor数量实现的速度提升可能会以资源消耗显著增加为代价,这会进一步导致训练成本的指数级增长。这表明需要一个成本感知的Actor扩展设计。
平衡加速与最终成本。在扩展Actor数量之前估算资源消耗对于避免引入不必要的成本至关重要。$N$个解码Actor的总成本,记为$C_{\text{Decode}}$,可以估算为
其中,$ρ$是GPU使用的单位成本,以美元/GPU/单位时间计量。$X_i$表示分配给第$i$个解码Actor的提示集,而$G_i$表示分配给它的GPU数量。$T(X_i, G_i)$是使用$G_i$个GPU处理工作负载$X_i$的估计执行时间。为了估计执行时间$T(X_i, G_i)$,我们利用在训练前使用虚拟批次收集的性能分析数据。具体来说,我们遵循先前工作【6, LLM-Inference-Bench: Inference Benchmarking of Large Language Models on AI Accelerators, 2024, arXiv】【83, DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, 2024, arXiv】的方法,在不同的最大响应长度下,测量解码步骤中每个输出token的时间(TPOT)延迟。对于每个提示$x \in X_i$,其对应的序列长度是使用§4.3中描述的响应长度预测模块估算的。
$N$个解码Actor的端到端执行时间,记为$T^{\text{total}}(N)$,由最慢(即运行时间最长)的Actor决定,计算公式为
$$T^{\text {total }}(N):=\max _{i \in[1, N]} T\left(X_{i}, G_{i}\right).$$对于所有候选的Actor数量$N \in [N_{\min}, N_{\max}]$,其中$N_{\min}$和$N_{\max}$分别代表预定义的最小和最大解码Actor数量,我们将执行时间和成本进行归一化,得到
$$\tilde{T}^{\text{total}}(N) := \frac{T^{\text{total}}(N) - T^{\text{total}}_{\min}}{T^{\text{total}}_{\max} - T^{\text{total}}_{\min}}, \quad \tilde{C}(N) := \frac{C_{\text{Decode}}(N) - C_{\min}}{C_{\max} - C_{\min}},$$其中,$T_{\min}^{\text{total}}$和$T_{\max}^{\text{total}}$是在$N$的范围内观察到的最小和最大执行时间,而$C_{\min}$和$C_{\max}$是相应的成本界限。为了确定最优的Actor数量$N'$,我们将目标制定为归一化时间和成本的加权和:
$$N^{\prime}:=\underset{N \in\left[N_{\min }, N_{\max }\right]}{\arg \min }\left\{\lambda \cdot \tilde{T}^{\text {total }}(N)+(1-\lambda) \cdot \tilde{C}(N)\right\},$$其中,$λ \in [0, 1]$是一个用户定义的权重,用于控制执行时间与成本之间的权衡。较大的$λ$优先考虑更快的执行速度,而较小的$λ$则强调更低的成本。
模型同步开销。模型同步开销是RLHF训练中的主要瓶颈之一【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】【84, Optimizing RLHF Training for Large Language Models with Stage Fusion, 2024, arXiv】。这个开销发生在上一训练步骤的学习阶段和当前步骤的生成阶段之间。在同步过程中,模型权重从学习器传输到所有采样Actor,引入了不可避免的传输延迟。此外,应用RLHFless的Actor扩展策略来增加Actor数量,以及将Actor分为一个预填充Actor和多个解码Actor的分解式预填充设计,都可能因通信增加而进一步放大数据传输开销。为了解决模型同步延迟和KV传输延迟,RLHFless引入了一种局部性感知的Actor放置策略,该策略结合了提示分配机制来适当地放置Actor,从而最小化每个训练步骤的端到端执行时间。
图9: RLHFless的局部性感知Actor放置。
放置策略。如§4.3所述,RLHFless利用提示分配将具有相似预期工作负载的提示分组到同一个解码Actor中。在这种设置下,每个Actor的执行时间由该组内响应最长的提示决定。因此,一个训练步骤的端到端生成时间由生成工作负载最长的Actor决定。为了对此进行优化,我们首先将预填充Actor与学习器共置在同一组GPU资源上。这减少了学习器和预填充Actor之间模型权重同步的传输开销。此外,由于学习器和预填充Actor都是计算密集型组件,它们都受益于更大的模型并行规模【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】【83, DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, 2024, arXiv】,因此共置它们不需要改变现有的并行策略。接下来,我们将处理最长响应的解码Actor与预填充Actor共置,使其能够立即开始,而不会产生模型权重和KV缓存传输的延迟。对于通过Actor扩展(§4.4)引入的额外解码Actor,我们优先将工作负载较重的Actor放置在物理上更接近学习器和预填充Actor的GPU节点上(例如,在同一个GPU节点内)。较轻的工作负载则分配给更远的GPU资源。由于模型权重同步可以在学习器完成模型更新后立即开始,而KV缓存传输只能在预填充阶段完成后开始,我们可以将传输与执行重叠。如图9所示,只要以下条件对所有$i \in \{2, \ldots, N\}$成立,传输延迟就可以被有效地隐藏:
其中,$N$是解码Actor的总数,${L^i_{\text{Model}}}$和${L^i_{\text{KV}}}$分别表示第$i$个解码Actor的模型权重和KV缓存的传输延迟。${L^i_{\text{Decode}}}$是第$i$个解码Actor的执行时间,而${L^1_{\text{Decode}}}$是与学习器和预填充Actor共置的解码Actor的执行时间。$L_{\text{Prefill}}$表示预填充Actor的执行时间。我们在扩展Actor时加入此约束,以实现更好的实际性能,减轻因大规模数据传输导致的执行时间延长。
硬件配置:
* 物理测试平台:使用了两个AWS EC2 g6e.48xlarge实例。每个实例配备8个NVIDIA L40S Tensor Core GPU(共384GB VRAM),192个AMD EPYC 7R13 vCPU,以及384GB系统内存。
* 模拟集群:使用Vidur【1, Vidur: A Large-Scale Simulation Framework For LLM Inference, 2024, arXiv】模拟了一个多达20个节点的大规模集群,每个节点配备8个通过NVLink连接的NVIDIA H100 GPU。
软件配置:
* 实现基础:RLHFless基于VERL 0.3.1.dev【56, HybridFlow: A Flexible and Efficient RLHF Framework, 2025, EuroSys】构建,集成了vLLM 0.8.3【29, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023】作为推理引擎和PyTorch FSDP【78, PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel, 2023, arXiv】作为训练引擎。
* 系统环境:操作系统为Ubuntu 22.04,NCCL版本为2.27,CUDA版本为12.8。
* 无服务器环境:使用Docker【38, Docker: Lightweight Linux Containers for Consistent Development and Deployment, 2014, Linux Journal】构建无服务器集群,并由Ray框架【40, Ray: A Distributed Framework for Emerging AI Applications, 2018, arXiv】管理计算资源和通信。
* 数据传输:使用Redis【49, Redis Official Website, 2025】作为外部分布式缓存,使用NVIDIA NCCL【42, NVIDIA Collective Communications Library, 2025】进行模型同步和KV缓存传输。
模型与数据集:
* 算法:Proximal Policy Optimization (PPO)【81, Secrets of RLHF in Large Language Models Part I: PPO, 2023, arXiv】和Group Relative Policy Optimization (GRPO)【54, DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, 2024, arXiv】。
* 模型:
* 物理测试:Qwen2.5架构【4, Qwen2.5 Technical Report, 2025, arXiv】模型,规模从3B到7B。
* 大规模模拟:Llama模型【18, The Llama 3 Herd of Models, 2024, arXiv】【62, Llama 2: Open Foundation and Fine-Tuned Chat Models, 2023, arXiv】(如Llama2-70B)。
实验参数与基线:
总体性能(6.2节)
* 实验内容:将完整功能的RLHFless与禁用所有核心功能的版本(基于VERL)进行比较,评估其在不同算法(PPO, GRPO)、模型大小(Qwen2.5-3B, 7B)和数据集(GSM8k, GPQA, L.C.B.)上的速度和成本效益。
* 实验结果:RLHFless在所有配置下都展现出显著的性能提升。与基线相比,RLHFless最多可实现1.35倍的加速和44.8%的成本降低。
* 分析结论:性能提升源于动态扩展Actor、消除重复计算以及及时释放空闲资源。对于采样密集型的GRPO算法,以及在处理长响应较多的GSM8k数据集时,RLHFless的优势更为明显,表明其能有效适应更大规模和更复杂的工作负载。
图10: RLHFless的总体性能评估。
消融研究(6.3节)
* 实验内容:通过逐步启用RLHFless的核心功能(去重预填充DP、提示分配PA、Actor扩展AS),评估每个模块的独立贡献。
* 实验结果:
1. 仅启用去重预填充(DP),相比原始版本降低了GPU成本。
2. 再启用提示分配(PA),通过将相似长度的提示分组,进一步降低了成本。
3. 最后启用Actor扩展(AS),通过动态调整Actor数量,显著缩短了执行时间,同时总成本增长缓慢或保持相当。
图11: RLHFless的消融研究(DP:去重预填充;AS:Actor扩展;PA:提示分配)。每个点显示一个训练步骤的GPU成本和执行时间。点越靠近左下角表示成本越低、执行越快。子图(a)显示了禁用所有核心功能的RLHFless。从(b)到(d),我们每次启用一个额外的核心功能,展示了每个设计的增量效益。
核心功能有效性分析(6.4节)
* 提示分配:与RLHFuse【84, Optimizing RLHF Training for Large Language Models with Stage Fusion, 2024, arXiv】的全局剪切-迁移策略相比,RLHFless基于排序的提示分配能更好地均衡负载,使部分Actor能提前完成并释放资源,实现了12.8%的端到端成本降低(见图12)。
* Actor扩展:通过动态调整Actor数量,RLHFless能找到“最佳点”,即增加Actor带来的加速足以抵消资源增加的成本,从而在不增加(有时甚至降低)成本的情况下加快训练速度(见图13a)。
* 去重预填充:该功能通过只计算一次共享前缀的KV缓存,有效减少了预填充阶段的计算量和成本。成本降低的幅度与配置相关,例如在GRPO(每提示3个响应)的设置下,理论上可减少66%的预填充成本(见图13b)。
图12: RLHFless提示分配的有效性。(DP:去重预填充;AS:Actor扩展;PA:提示分配。)
图13: RLHFless的(a) Actor扩展和(b)去重预填充的有效性。(DP:去重预填充;AS:Actor扩展;PA:提示分配。)
敏感性分析(6.5节)
* 对响应长度预测准确性的敏感性:即使使用准确率较低的基于模型的预测器(约44%准确率),RLHFless(表示为RLHFless)仍能实现1.22倍的加速和28.9%的成本降低。这表明RLHFless的设计具有鲁棒性,不强依赖于高精度的预测,其排序机制和剪切-迁移回退策略能有效容忍预测误差(见图14)。
* 对超参数的敏感性:
* EWMA窗口大小:窗口大小为1(仅使用上一轮数据)已足够,更大的窗口带来的收益微乎其微(见图15a)。
* 剪切-迁移阈值 $τ$:$τ = 0.7$ 在执行时间和成本之间取得了最佳平衡(见图15b)。
* Actor扩展权重 $λ$*:$λ = 0.7$ 在实验中提供了最佳的速度与成本权衡(见图15c)。
图14: RLHFless响应长度预测的敏感性分析。
图15: RLHFless超参数敏感性:(a) 用于长度预测的EWMA窗口大小,(b) 剪切-迁移阈值$τ$,以及(c) Actor扩展权重$λ$。
可扩展性分析(6.6节)
图16: RLHFless可扩展性分析。(a) 在不同集群规模下,生成2k到8k token响应的执行时间以及调度开销。(b) 大规模模拟实验的平均归一化性能提升。
延迟分解(6.7节)
* 实验内容:分析RLHFless核心组件(去重、扩展决策等)在单个训练步骤中引入的延迟。
* 实验结果:由RLHFless核心功能引入的开销(包括去重、响应长度预测和成本/时间估算)相对于总步骤时间而言可以忽略不计。
* 分析结论:RLHFless的核心组件都是无模型且轻量级的,几乎不给训练流水线增加计算负担。
图17: RLHFless在一个训练步骤中的延迟分解,包括准备、生成和学习阶段,以及去重延迟、扩展延迟(响应长度预测和成本/时间估算)和I/O延迟。
本文提出了RLHFless,这是首个用于RLHF训练的无服务器框架。通过针对“有服务器”(serverful)RLHF系统中的关键低效问题——包括依赖训练阶段间的空闲时间、动态变化的响应长度以及冗余的KV缓存计算——RLHFless利用无服务器计算的特性实现了细粒度的资源自适应。通过其核心设计,包括去重预填充、提示分配和成本感知的Actor扩展,RLHFless在RLHF循环的宏观层面和单个组件的微观层面都减少了资源浪费。实验结果表明,RLHFless在物理集群上最高可实现1.35倍的加速和44.8%的成本降低,在模拟的大规模GPU集群上平均实现了1.23倍的加速和38.7%的成本降低,这证明了无服务器RLHF训练的有效性。