Efficient Resource-Shiftable RL Post-training with Generative Rewards
Listen
Radio episode about this paper
Transcript
Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.
Tom: I'm Tom.
Jane: And I'm Jane, here with Lu, Meng and our in-house large language model, Lalam.
Tom: Today's paper: "Efficient Resource-Shiftable RL Post-training with Generative Rewards".
Jane: The gist The paper presents PivotRL, an RL post-training system that dynamically shifts resources among different roles according to their runtime demands to improve end-to-end throughput.
Tom: First, who's behind it and why it matters.
Title and authors: Tom: The paper’s title, "Efficient Resource-Shiftable RL Post-training with Generative Rewards", just tells you the main mechanics: it’s about making resource shifting efficient while dealing with reward models in reinforcement learning post-training.
Jane: It's aiming to solve that mismatch between the fixed hardware setup and the fluctuating demands of those different stages—rollout, reward, and training. They want to show how you can move resources around at runtime to keep things running smoothly.
Lu: They introduce a system built on a Global Parameter Storage that lets any GPU fetch any model's parameters on demand, which is the first big piece for enabling this shift. Then they have a unified mechanism for shifting those role-specific contexts between different resources.
Meng: So, it sounds like the main innovation isn't just having some new hardware; it’s building a flexible runtime that lets the system decide what to do with its GPUs moment by moment. That flexibility is something I need when I'm trying to deploy models that are unpredictable in their needs.
Lalam: It essentially creates a dynamic way for the system to reallocate GPUs based on real-time workload demands, which they describe as matching the instantaneous stage load. This dynamic reallocation is what they show can improve end-to-end throughput by one point eight one to two point zero five times over colocated deployment and one point five zero to one point nine five times over disaggregated deployment, according to their comparison of different paradigms in Figure two >
Tom: That throughput gain number is pretty significant, especially when you look at the comparison between colocated, which shares everything sequentially, and resource-shiftable deployment >
Jane: It's a lot of time saved because they are moving away from static allocation where things get stuck waiting for the next batch to start. They are showing that dynamic reallocation can reduce that "tail effect" where reward evaluation waits for rollout production rates >
Lu: The paper shows this clearly in Figure three looking at the per-GPU throughput under different deployment paradigms on thirty-two GPUs, using models like Qwen2 point 5-7B for policy and Qwen3-30B-A3B as the GenRM > <ref:2610.16866#pg1>
Meng: I'm interested in how they handle that shift itself. If you're moving resources, there has to be a plan for what happens to the sequences currently running, right? Because if you just cut things off randomly, you might lose a lot of progress.
Lalam: That’s where the shift-aware scheduler comes in; it handles rescheduling after a shift by maintaining a shared waiting queue and models per replica throughput to continuously dispatch sequences using a throughput-maximizing mechanism >
The paper's summary: Tom: So, to summarize what they did with PivotRL, they focused on solving the static allocation problem by introducing three main innovations for resource-shiftable deployment.
Jane: They have the Global Parameter Storage and the unified role-shifting mechanism which allows parameters to be fetched on demand and contexts to shift efficiently >
Lu: Then there's the shift-aware scheduler which handles sequence migration during a shift, and finally, they have a planner that decides when and how much to shift. This planner looks at things like generation latency τRole = NSeqRole/TRole >
Meng: A planner sounds complex to implement, but if it correctly calculates the trade-off between the expected throughput gain and the overhead of making a shift, then it could really optimize resource use across all three RL stages >
Lalam: The planner involves a five-step procedure: first determining the shift-up role based on generation latency; then preparing shift pairs by assigning a penalty phi that captures opportunity cost during the shift; then constructing a candidate set using dynamic programming to find the most beneficial candidate >
Tom: And finally, it selects the plan with the largest positive estimated benefit, which they define as B equals G minus phi, where G is expected token gain over time H >
Jane: It’s essentially a sophisticated decision-making process that tries to figure out exactly when and how to move resources between roles to maximize performance, rather than just letting the hardware sit there doing whatever it's told.
Lu: What this means is they are moving beyond just having different ways of deploying models and are building an intelligent system that actively manages the resource allocation based on runtime demands >
Meng: I like the idea of a planner evaluating candidate shift plans against their expected benefit versus the overhead; that makes sense for production systems where you can’t afford to make big, risky moves without knowing the outcome >
The paper's improvements: Tom: The main improvement they highlight is this resource-shiftable deployment, which lets them dynamically reallocate GPUs to match instantaneous workload demands. That's what gives them that throughput boost we talked about earlier >
Jane: They are showing that this dynamic reallocation isn't just theoretical; they demonstrate it with concrete numbers comparing the performance across those different deployment paradigms >
Lu: And the second major improvement is using a planner to optimize resource allocation across rollout, reward, and training stages by evaluating candidate shift plans based on expected throughput benefit and the shift overhead >
Meng: So they’re not just shifting resources randomly; they have a strategy for *when* to shift and *what* role should give up resources to another one >
Lalam: And the third improvement is how they handle sequence migration during a resource shift. They use operations called "Abort" and "Dispatch" which are shared by both shift-down and shift-up migration >
Tom: So, for a listener who just wants the practical implications: it means that instead of having static bottlenecks, you can have a system that actively manages its hardware to keep all three stages running as fast as possible >
Jane: It points toward systems where the computational demands are highly variable, like complex generative tasks, where a fixed setup would just underperform constantly >
Lu: The complexity analysis they provide shows that the sequence migration during shift up is bounded by O(I · NSeq + I log I) and during shift down it’s O(I · NSeq) >
Meng: From an engineering standpoint, that complexity bound tells me how much computation we need to budget for the planning and migration logic itself; it sounds manageable if the constant factors are small enough >
Conclusion: Tom: So, to wrap up the paper "Efficient Resource-Shiftable RL Post-training with Generative Rewards", they show that dynamic resource reallocation based on runtime demands can significantly improve end-to-end throughput in RL post-training systems.
Jane: The key takeaway is that moving from static allocation to a system with a planner and shift mechanism allows the AI workflow to adapt to fluctuating workload requirements across different stages, leading to substantial performance gains >
Lu: It moves the focus toward building intelligent runtime environments that can make real-time decisions about hardware utilization based on expected future needs, which is important for scaling up these complex models >
Meng: For me, what matters is that the complexity of the planner and migration operations is bounded by things like O(I · NSeq + I log I), suggesting it’s computationally feasible to implement in a production setting without causing too much latency during the shift itself >
Lalam: They show that sequence migration during both shift up and down uses "Abort" and "Dispatch" operations to reschedule sequences across replicas to maximize throughput under the new allocation >
Tom: That's what they did. We’re looking at a system where the hardware isn't just sitting there; it’s actively shifting itself around to meet the demands of rollout, reward evaluation, and training simultaneously >
Jane: It really shows that when you are dealing with generative reward models in RL, static resource planning is a bottleneck, and this PivotRL paper gives us a blueprint for how to build something more adaptive >
Yanfeng Zhao, Haoyang Li, Sheng Lin, Yuming Zhou, Jiawei Jiang, Bin Cui, Fangcheng Fu
Shanghai Jiao Tong University · Peking University · Central China Normal University
cs.LG, cs.DC
Submitted: 2026-10-12
Updated: 2026-10-12
Code: https://github.com/ai-dynamo/nixl
License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
The gist: The gist The paper presents PivotRL, an RL post-training system that dynamically shifts resources among different roles according to their runtime demands to improve end-to-end throughput.
Key concepts
- Global Parameter Storage (GPS)
- This component allows any GPU to access the parameters of any model on demand by fetching them from CPU memory. It acts as a centralized, flexible repository for model weights, enabling seamless and on-demand parameter transfer between different computational roles during resource shifts.
- Role-Shifting Mechanism
- This mechanism categorizes data into 'stateless' and 'stateful' types to manage resources efficiently. It applies actions like discard, offload, or preserve to minimize memory usage while reducing the startup time required when switching between different operational roles.
- Planner
- The planner is the decision-making core of PivotRL. It uses a five-step procedure involving latency analysis and opportunity cost calculation to determine which role should donate resources and how much to move, aiming for the plan with the largest estimated benefit (Gain minus penalty).
- Shift-Aware Scheduler
- This scheduler redesigns sequence handling to manage workloads while resources are actively shifting. It uses a shared waiting queue and throughput-maximizing dispatching to continuously assign tasks to replicas, handling sequence migration through 'Abort' and 'Dispatch' operations.
Summary
The gist The paper presents PivotRL, an RL post-training system that dynamically shifts resources among different roles according to their runtime demands to improve end-to-end throughput.
Motivation and Problem Statement
Reinforcement learning (RL) post-training with generative reward models (GenRM) has become increasingly resource-intensive because reward evaluation is no longer a lightweight scalar computation, but a full LLM inference workload
. Existing systems rely on static resource allocation, which cannot adapt to the dynamic workload demands across stages. This static allocation causes resource allocation to mismatch dynamic workload demands and leaving substantial throughput headroom
. The paper argues that resolving this mismatch requires a more flexible deployment paradigm in which resources can shift across stages at runtime
.
PivotRL Architecture and Core Innovations
PivotRL introduces three key innovations to realize resource-shiftable deployment:
-
Supporting resource shifting, which is achieved through a
Global Parameter Storage that lets any GPU fetch the parameters of any model on demand
and aunified role-shifting mechanism
. -
Rescheduling workload after a shift, addressed by a
shift-aware scheduler that supports shift-time sequence migration across replicas
. -
Deciding when and how to shift, managed by a
planner to determine when to trigger a shift, which role should donate resources to another, and exactly which resources to move
.
System Components in Detail
The system runtime includes the Global Parameter Storage (GPS) and the Role-Shifting Mechanism. GPS mediates parameter transfer through CPU memory, exposing Read and Write
operations that are general to arbitrary resource shifts. The Role-Shifting Mechanism categorizes role context into stateless and stateful
data types, applying actions like discard, offload, or preserve
to minimize memory consumption while reducing cold-start overhead.
The Shift-Aware Scheduler redesigns the scheduler to handle rescheduling under shifting by maintaining a shared waiting queue and models per-replica throughput to continuously dispatch sequences using a throughput-maximizing mechanism
. Sequence migration during shifts is decomposed into two operations: "Abort, which selects sequences to abort from a replica and returns them to the shared waiting queue, and Dispatch, which leverages the aforementioned throughput-maximizing dispatch mechanism to assign sequences to new replicas".
The Planner determines shift decisions through a five-step procedure:
**: Determine the shift-up role by selecting the role with a larger generation latency τRole = NSeqRole/TRole
. If training is not ready, it selects between rollout and reward evaluation based on this latency. Prepare shift pairs by assigning a penalty phi that captures the opportunity cost (i.e., the tokens that fail to be generated) during this shift period
. Construct a candidate set using dynamic programming to select the most beneficial candidate by jointly considering its throughput gain and shifting overhead
. Finally, it selects the plan with the largest positive estimated benefit
. The final benefit is calculated as B = G − phi, where G is the expected token gain over time H. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration is bounded by the upper-bound of O(I · NSeq + I log I)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift down is O(I · NSeq)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift up is O(I · NSeq + I log I)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift down is O(I · NSeq)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift up is O(I · NSeq + I log I)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift down is O(I · NSeq)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift up is O(I · NSeq + I log I)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift down is O(I · NSeq)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift up is O(I · NSeq + I log I)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift down is O(I · NSeq)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift up is O(I · NSeq + I log I)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift down is O(I · NSeq)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift up is O(I · NSeq + I log I)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift down is O(I · NSeq)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
. The complexity of sequence migration during shift up is O(I · NSeq + I log I)
. The total planner overhead ranges from 0.31 to 2.95 s across different cluster sizes
Improvements for AI systems
-
Resource-shiftable deployment allows for dynamic reallocation of GPU resources to match instantaneous workload demands, which
dynamically reallocates GPUs to match workload demand
as described in Section 2.3. This enables a system to improve end-to-end throughput by1.81–2.05× over colocated deployment and 1.50–1.95× over disaggregated deployment.
-
The PivotRL system can optimize resource allocation across the three RL stages (rollout, reward, and training) by utilizing a planner that
evaluates candidate shift plans based on their expected throughput benefit and the shift overhead to determine when and how to shift.
This allows the system to avoid static resource bottlenecks. -
The system can achieve sequence migration during a resource shift by leveraging
Abort
andDispatch
operations, which are shared by both shift-down and shift-up migration, ensuring that sequences arerescheduled across replicas to maximize the role’s throughput under the new allocation.
Sources
- DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning
- AReaL: A Large-Scale Asynchronous Reinforcement Learning System for Language Reasoning
- RollPacker: Mitigating Long-Tail Rollouts for Fast, Synchronous RL Post-Training
- GLM-5: from Vibe Coding to Agentic Engineering
- AsyncFlow: An Asynchronous Streaming RL Framework for Efficient LLM Post-Training
- History Rhymes: Accelerating LLM Reinforcement Learning with RhymeRL
- OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework
- The Art of Scaling Reinforcement Learning Compute for LLMs
- R-Align: Enhancing Generative Reward Models through Rationale-Centric Meta-Judging
- StaleFlow: Staleness-Aware Data Management for Mitigating Data Skewness in Fully Disaggregated RL Post-Training
- TorchTitan: One-stop PyTorch native solution for production ready LLM pre-training
- Part II: ROLL Flash -- Accelerating RLVR and Agentic Training with Asynchrony
- Generative Reward Models
- Asynchronous RLHF: Faster and More Efficient Off-Policy RL for Language Models
- Seer: Online Context Learning for Fast Synchronous LLM Reinforcement Learning
- Qwen2.5 Technical Report
- TideRL: Boosting Agentic RL Goodput with Readiness-Aware Scheduling
- Proximal Policy Optimization Algorithms
- DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models
Related papers
- Polynomial-Augmented Neural Networks (PANNs) with Weak Orthogonality Constraints for Enhanced Function and PDE Approximation
- AIRL-S: Unifying Reinforcement Learning and Search-Based Test-Time Scaling via Adversarial Inverse Reinforcement Learning
- Transformers as Bayesian In-Context Experimenters: Smoothness-Adaptive Efficient ATE Estimation
- Convergence issues in Relational Concept Analysis based on AOC-posets
- Beliefs Beyond Posteriors: The Predictive Cost of ELBO Binding
- Understanding Diffusion Models via Ratio-Based Function Approximation with SignReLU Networks