Frontier-Group Dispatch (FGD) in RLVR

• FGD is a group-aware admission controller that prioritizes complete prompt groups in on-policy RLVR, ensuring each group’s responses are processed together for training.
• By maintaining a frontier set based on submission order, FGD coordinates group-level scheduling within the RolloutPipe framework to preserve fixed rollout weights and statistical correctness.
• Empirical results demonstrate that FGD, when combined with Complete-Group Pipelining, reduces rollout-to-train end times by up to 42.3%, significantly decreasing trainer idle time.

Searching arXiv for the specified paper and closely related work on disaggregated on-policy RLVR systems. Frontier-Group Dispatch (FGD) is a rollout-side scheduling and admission policy introduced in the RolloutPipe framework for disaggregated, on-policy GRPO-style reinforcement learning with verifiable rewards (RLVR). In this setting, a Rollout node or GPU pool running SGLang generates $K$ sampled responses per prompt with fixed policy weights and computes verifiable rewards, while a Trainer node or GPU pool using Megatron-LM consumes rollout data to perform GRPO updates. FGD operates under the constraint that the trainable unit is not an individual response but a complete group: a prompt group becomes trainable only after all $K$ responses have finished generation, verification, reward computation, and group-level materialization. Within RolloutPipe, FGD complements Complete-Group Pipelining (CGP) by prioritizing the groups needed to form the next training batch, thereby enabling earlier and steadier trainer input while preserving strict on-policy correctness (Chen et al., 25 Jun 2026).

1. System setting and the motivation for group-aware dispatch

FGD arises from a specific bottleneck in disaggregated on-policy RLVR. A rollout round consists of $R$ groups, each with $K$ sampled responses. If the GRPO global batch size is $B$ samples, one logical update consumes

$U = B / K$

complete groups. In the serial baseline exemplified by Slime, the system first rolls out all $R$ groups under fixed weights, then waits until all groups are complete and materialized, and only then sends the entire round to the trainer. The trainer performs $R/U$ logical updates and publishes new weights after the round is fully consumed. The result is prolonged trainer idleness even when many groups have already become trainable (Chen et al., 25 Jun 2026).

The motivation for FGD depends on a core GRPO property: group-level statistics are required before training can begin on a group. The paper states that no single response is trainable until the entire group has finished reward and verifier processing together with group statistics, so the complete group is the minimum trainable unit. CGP exploits this by dispatching complete groups to the trainer as soon as they materialize, but CGP alone is blind to which groups will finish first. FGD addresses that rollout-side uncertainty by shaping completion order so that the groups required for the next $U$-group training batch arrive earlier and more steadily.

The terminology is exact. A complete group is one prompt group whose $K$ responses have been generated, verified, reward-scored, and converted into GRPO-ready examples with materialized statistics and advantages. A trainable group is the same object. Frontier groups are the subset of not-yet-serving-complete groups currently admitted into the rollout engine by FGD. Group materialization is the post-generation step that includes reward or verifier processing, group statistics, and conversion to training examples.

2. Formal definition of Frontier-Group Dispatch

FGD is defined as an admission controller inside the rollout system. Let $K$0 denote the set of groups that have arrived but are not yet serving-complete, and let $K$1 denote the submission order of group $K$2, with smaller values meaning earlier submission. FGD maintains a frontier set $K$3 of at most $K$4 groups currently in service:

$K$5

A request $K$6 belonging to group $K$7 is admitted if and only if its group lies in the frontier:

$K$8

Otherwise the request is deferred. When a group completes all $K$9 requests, it leaves $R$0, which frees a slot. In the next scheduling cycle, the lowest-order deferred group is admitted to refill the frontier (Chen et al., 25 Jun 2026).

Operationally, FGD keeps a frontier window size $R$1 that bounds the number of groups concurrently in service. Only groups in $R$2 can have their requests scheduled and decoded by SGLang. The policy is therefore simple and monotone: always fill the frontier with the earliest groups by submission order up to $R$3, and do not start groups beyond that frontier until a slot opens. In the reported experiments, the system uses $R$4, so the frontier corresponds exactly to the groups needed to form the next logical training batch.

This makes FGD a group-aware scheduler rather than a request-level throughput heuristic. The paper explicitly characterizes it as an admission controller between the rollout worker and SGLang’s internal scheduler. A plausible implication is that FGD moves scheduling control to the level at which GRPO semantics are actually defined: the group rather than the individual sampled response.

3. Coupling with Complete-Group Pipelining

FGD is not a standalone training pipeline. Its effect depends on CGP, which is the mechanism that allows early handoff of complete groups to the trainer. Under CGP, each group that finishes materialization is appended to a Pending Complete Groups FIFO queue in the ActorGroup control component. A Feasible Batch Selector takes the maximal group prefix that fits within the per-GPU token budget, with at least one group; if a large group exceeds the budget, it may be dispatched alone with micro-batching. The selected batch is forwarded via CGP Handoff into the $R$5-group Ready Queue. The trainer consumes groups from the ready queue, and every $R$6 consumed groups constitute one logical update matching the baseline semantics $R$7 (Chen et al., 25 Jun 2026).

The key timing quantities are also defined precisely. Let $R$8 denote the time when the first $R$9 groups have all finished materialization, and let $K$0 denote the time when the entire rollout is serving-complete and materialized. Then

$K$1

and CGP recovers

$K$2

of what would otherwise be trainer idle time.

FGD alters how quickly $K$3 is reached and how regular subsequent group arrivals are. CGP alone allows training to begin before rollout end, but if all $K$4 requests enter SGLang at once under simple request-level FIFO, the first $K$5 groups may still complete at irregular times because of variance in prompt length, response length, and verifier time. FGD limits the active set to the earliest groups, so those groups consume rollout capacity first, complete earlier, and arrive at the CGP FIFO with smaller inter-group gaps. The division of labor is therefore exact: FGD determines which groups complete first, whereas CGP determines how soon completed groups can be converted into training work.

Configuration	Rollout-side behavior	Trainer-side consequence
Slime	Groups admitted FIFO by SGLang without group-aware constraints; no early handoff	Training starts only after all $K$6 groups are complete
CGP only	Early handoff enabled, but rollout admission remains simple request-level FIFO	Training starts when the first $K$7 groups materialize
CGP + FGD	Frontier-group admission with $K$8	The first $K$9 groups arrive earlier and more steadily

The paper states that, given the described behavior, FGD can be seen as a group-aware, frontier-width-constrained variant of FIFO prioritized for batch formation.

4. On-policy correctness and the absence of stale data

A central design requirement is strict on-policy correctness. All $B$0 groups in a rollout round must be generated under a single fixed policy snapshot, and training for that round must use exactly that data. RolloutPipe preserves this in two ways. First, the rollout node uses one snapshot from the Weight Publisher and does not refresh rollout weights until the trainer has consumed all $B$1 groups of the round. Second, optimizer steps and weight publication occur only when the round’s groups have been consumed according to the same logical update structure as the baseline: every $B$2 groups produce one logical update, and only after the last logical update of the round are new weights published to SGLang (Chen et al., 25 Jun 2026).

FGD does not introduce staleness because it changes only the admission order and concurrency of generation within a single fixed-weight rollout. The frontier set $B$3 is reset each round, and all groups in the same round share the same rollout weights regardless of when training begins relative to rollout progress. CGP also avoids staleness: training may begin before rollout completes, but all data being consumed by the trainer were generated under the current round’s fixed rollout weights, and those updated trainer weights are not published back to the rollout system until the round is fully consumed.

This point is important because overlap is often associated with asynchronous pipelines trained on stale data. In RolloutPipe, overlap and staleness are deliberately separated. The paper emphasizes that CGP and FGD change only dispatch timing and group order, not samples, advantages, or gradient computation. It further states that training dynamics and convergence behavior remain consistent with Slime because optimizer-step boundaries and per-round fixed-weight semantics are preserved.

5. Empirical behavior and performance characteristics

The evaluation uses Qwen3-1.7B on four reasoning and science workloads—LSAT-AR, Sci-XW, Sci-JL, and OlyPhys—across three group counts $B$4, giving twelve rollout settings. The primary end-to-end metric is rollout-to-train-end main time, defined as the time from rollout start to training end for a round. The analysis also tracks dispatch timing for the first $B$5-group logical batch and the trainer waiting ratio:

$B$6

where the numerator is trainer idle time waiting for data and the denominator is total wall time from rollout start to train end (Chen et al., 25 Jun 2026).

Across the twelve settings, CGP+FGD reduces rollout-to-train-end time by 30.7%–42.3% relative to Slime. The gains are larger for larger $B$7, because larger rollouts leave more early groups trapped behind the serial rollout barrier in Slime. When the total reduction is decomposed, CGP accounts for 71%–96% of the reduction, while FGD contributes an additional 2.5%–11.4% over CGP alone. The paper reports that CGP’s share grows with $B$8: roughly 71–79% at $B$9 and 92–96% at $U = B / K$0.

Dispatch timing illustrates FGD’s specific role. At $U = B / K$1, Slime’s first legal dispatch of a $U = B / K$2-group batch occurs at 509–543s, because rollout and materialization for the full round must finish first. CGP reduces that to 46–90s. CGP+FGD further narrows the dispatch interval to 52–61s, which the paper interprets as evidence that frontier groups are completing at more concentrated times. That is, FGD not only enables earlier dispatch through its interaction with CGP, but also stabilizes the arrival process of trainable groups.

The trainer waiting ratio shows the utilization effect directly. Slime’s waiting ratio is 47%–52%, meaning that nearly half of total end-to-end time leaves training GPUs idle. CGP+FGD reduces this to 14%–33% across the twelve settings, reaching approximately 14% at $U = B / K$3. The reported speedup therefore comes predominantly from reduced trainer idle waiting rather than from reduced total compute.

6. Implementation details, workload effects, and scope

FGD is implemented on the rollout node. A Prompt Group Buffer holds the $U = B / K$4 prompt groups of the current rollout. Admission Control implements FGD by maintaining the frontier $U = B / K$5 and the Deferred Groups pool. Requests whose group lies in $U = B / K$6 enter the Admitted Queue; all others remain deferred. The SGLang engine, including Token Scheduler and Decode Workers, operates only on requests in the Admitted Queue. When a group becomes serving-complete after all $U = B / K$7 requests finish, it is removed from $U = B / K$8, and the next earliest deferred group is admitted. On the control node, a Response Collector receives completed responses, a Reward Verifier computes rewards, and Build Trainable Group performs materialization, including dynamic filtering, advantage computation, and loss-mask construction. Materialized groups enter the Pending Complete Groups FIFO and may then be pushed by CGP Handoff into the $U = B / K$9-group Ready Queue. On the training node, Pipelined Train RPC consumes those batches, the Gradient Accumulator tracks how many groups have been consumed, every $R$0 groups trigger an optimizer step, and the Weight Publisher sends updated weights to the rollout side only after all $R$1 groups of the round are consumed (Chen et al., 25 Jun 2026).

The paper also reports that training workload remains essentially unchanged. Response length across Slime, CGP, and CGP+FGD stays in the same range, 3.3k–3.6k tokens, for each $R$2 and workload. Table 1 examples at $R$3 show nearly identical trainer compute time per round: LSAT-AR is 587.4s for Slime, 589.0s for CGP, and 586.4s for CGP+FGD; Sci-XW is 572.2s, 573.0s, and 577.3s; Sci-JL is 584.5s, 584.1s, and 584.1s; OlyPhys is 640.0s, 640.0s, and 644.4s. The paper’s interpretation is that RolloutPipe changes when the same work is done rather than reducing the amount of training work. It further notes that OlyPhys exhibits longer response length under CGP+FGD while still achieving shorter wall-clock time than Slime, which supports the claim that the improvement derives from overlap and scheduling rather than from lighter workloads.

The stated limitations are mostly scheduling and systems trade-offs. Choosing $R$4 too small may overly constrain rollout concurrency and reduce rollout GPU utilization; choosing $R$5 too large causes more groups to compete simultaneously, which weakens the frontier effect. The experiments set $R$6, motivated by memory constraints and pipeline behavior. The benefits also depend on the rollout-to-training speed ratio: if rollout is much faster than training, the trainer becomes the bottleneck and FGD matters less; if training is faster, FGD helps prevent trainer idleness until the trainer saturates. The design further assumes fixed per-round weights in a Slime-style round-based update regime, which is natural for on-policy GRPO but means that adaptation would be needed in more continuous online RL settings with frequent weight refreshes. The paper also notes nontrivial implementation complexity because FGD requires admission control integrated with SGLang’s router and token scheduler, together with cross-node coordination for group completion and frontier maintenance.

On generalization, the paper argues that any on-policy algorithm whose trainable unit is group-level or trajectory-level can benefit from a frontier scheduling concept. It specifically mentions on-policy PPO with trajectory batch dependencies and GRPO variants with different $R$7, $R$8, and reward shaping. It also states that the scheduling logic is independent of model size and internal architecture because it operates at the control plane, implying applicability to larger models such as Qwen3-72B provided sufficient GPU memory and network bandwidth are available. A plausible implication is that FGD is best understood not as a model-specific optimization but as a control-plane discipline for aligning rollout admission with optimizer-update formation.

7. Conceptual significance

FGD is best characterized as a group-aware admission controller for disaggregated on-policy RLVR. Its conceptual contribution is to make the rollout system prioritize the groups that are immediately relevant to the next logical update, rather than exposing all requests to the rollout engine at once and leaving completion order to request-level variance. In the reported configuration, setting $R$9 makes the frontier identical to the groups needed for the next trainer batch, so rollout capacity is explicitly allocated to minimizing batch-formation latency rather than maximizing unconstrained request concurrency (Chen et al., 25 Jun 2026).

The broader significance lies in the way FGD resolves a tension between utilization and on-policy semantics. Classical serial designs preserve correctness but waste trainer time; asynchronous overlap can improve utilization but introduces stale data. FGD, together with CGP, occupies a different point in the design space: it overlaps rollout and training while preserving fixed-weight round semantics. That makes it orthogonal to optimizer design, reward design, and GRPO objective specification. Within RolloutPipe, FGD does not alter samples, rewards, advantages, or logical update boundaries; it alters only which groups are allowed to progress through rollout at any given time.

For on-policy LLM post-training systems built around verifiable rewards, this places FGD at the interface between scheduler design and statistical correctness. The paper’s results indicate that substantial wall-clock gains can be obtained by changing only admission order and concurrency at the group level, with no change in training objective and no measured increase in trainer compute. In that sense, FGD formalizes a systems principle specific to group-dependent RLVR workloads: when the optimizer consumes complete groups, the rollout scheduler should privilege complete-group formation rather than request-level immediacy.