[rollout] feat: support over sampling rollout in SGLang Rollout #2929

zhaochenyang20 · 2025-08-05T21:25:25Z

What does this PR do?

This PR introduces an over-sample strategy for verl's SGLang multi-turn rollout to address the long-tail problem, where a few slow requests disproportionately increase the overall rollout time. The core idea is to over-sample the number of requests at the start of the rollout and then aggressively cancel any requests that haven't finished once a target number of completions is met.

Improves rollout efficiency for multi-turn conversations by reducing total time spent waiting for slow requests.
Implements a new request monitoring and cancellation mechanism to cut off unnecessary computation.

wandb results is as follow:

https://wandb.ai/zhaochenyang20/benchmark_over_sample_2/workspace?nw=nwuserzhaochenyang20

Of course, this strategy has its share of issues. For example, many might question why the over-long requests that are dropped aren't simply saved and continued in the next round. This is certainly possible—it's a partial rollout strategy—but it would require verl to have a data buffer, which is beyond the scope of this PR. Furthermore, saving and continuing these requests would introduce an off-policy problem.

There is also a valid concern that this rather "brutal" dropping strategy could unfairly ignore very long requests. I agree this is a very reasonable point, but currently, we don't have a lossless solution. However, our dropping strategy is very flexible and could even change with our curriculum learning. For instance, in the example I gave, I just directly dropped the last 20% of requests. In practice, we can dynamically adjust this drop rate and even set different dropping methods. For example, we could record the return time (t) for the 80% of requests and then drop any requests that haven't returned after 1.5t.

We've provided an initial, validated idea and have completed its implementation. We welcome everyone to join the discussion on how to accelerate multi-turn rollouts with acceptable losses.

Test

The new over-sample strategy was tested with an 8-GPU setup on the gsm8k dataset, yielding the following results:

Rollout Time: Significant reduction in overall rollout time per step.
Training Rewards:
- The reward metric for training steps shows a positive bias. This is because we exclude the aborted requests (which are typically more difficult and have lower rewards) from the reward calculation.
- The reward metric for validation steps remains accurate and aligns with the baseline. This is because the cancellation logic is not triggered during validation, ensuring a fair and complete evaluation.

API and Usage Example

This feature modifies sglang_rollout.py and metric_utils.py. To use it, follow the standard setup and then run the training script with the over-sample parameters.

https://github.com/zhaochenyang20/Awesome-ML-SYS-Tutorial/blob/main/rlhf/verl/multi-turn/release_log/over_sample.md

Design & Code Changes

The design is centered on three main functions that orchestrate the over-sampling logic: run_with_cancellation, process_request_with_monitoring, and monitor_and_cancel. These functions rely on global variables, such as all_tasks and completion_lock, to manage state.

run_with_cancellation: This is the entry point. It launches all requests as process_request_with_monitoring tasks concurrently with a single monitor_and_cancel task. It uses asyncio.gather to wait for all tasks to complete (or be canceled) and converts any exceptions from canceled tasks into padding requests before returning the final output.
process_request_with_monitoring: This async function handles a single request. It waits for the request to complete using _async_rollout_a_request and then checks a shared counter, completed_count, using a completion_lock for thread safety. If the target completion count has not been reached, it returns the real result. If the target has been met, it returns padding data instead, effectively "discarding" the late result.
monitor_and_cancel: This is a separate async task that polls the completed_count. Once the count reaches the target_completion threshold, it immediately cancels all remaining tasks and sends an abort_requests signal to the SGLang engine, halting any ongoing GPU computation for those requests.

Key code changes:

sglang_rollout.py:
- Adds the three core asynchronous functions for the over-sample strategy.
- The AsyncEngine class now includes a new abort_request method that calls the synchronous abort_request in the tokenizer_manager.
metric_utils.py:
- The compute_data_metrics function is updated to exclude the aborted requests (identified by padding) from the denominator when calculating average rewards during training. This prevents the training reward from being artificially lowered by the zero-reward aborted requests.

This implementation is designed to be a straightforward and effective solution for the long-tail problem, though some aspects of the asynchronous design and the impact on training variance require further investigation.

WindowsXp-Beta · 2025-08-12T09:18:52Z

verl/workers/rollout/sglang_rollout/sglang_rollout.py

+                    except Exception as e:
+                        logger.error(f"Uncaught exception in process_request_with_monitoring: {e}")
+                        logger.error("This shall not happen, please check the code")
+                        raise e


I think this exception capture and logging are a bit unnecessary as the exception will be raised anyway.

WindowsXp-Beta · 2025-08-12T09:29:40Z

verl/workers/rollout/sglang_rollout/sglang_rollout.py

+                            if isinstance(result, Exception):
+                                # if it is an exception (including CancelledError), create padding
+                                logger.warning(f"Task {i} resulted in exception: {result}")
+                                output_req_list.append(self._create_padding_request(req_list[i]))


since all the exceptions are captured, why we still need this check here?

Just duplicated. Will remove this.

verl/workers/rollout/sglang_rollout/sglang_rollout.py

zhaochenyang20 · 2025-08-12T19:19:48Z

Additionally, I add the profile logic in https://github.com/zhaochenyang20/verl/tree/over_sample_profile, here I can share some results: It works right and padding time is minor

Great catch!

zhaochenyang20 · 2025-08-12T19:21:04Z

Additionally, I add the profile logic in https://github.com/zhaochenyang20/verl/tree/over_sample_profile, here I can share some results: It works right and padding time is minor

Could you also modify this docs?

https://github.com/zhaochenyang20/Awesome-ML-SYS-Tutorial/blob/main/rlhf/verl/multi-turn/tool_examples/profile.md

With your updated branch considering the over sample.

PopSoda2002 · 2025-08-12T19:33:54Z

Additionally, I add the profile logic in https://github.com/zhaochenyang20/verl/tree/over_sample_profile, here I can share some results: It works right and padding time is minor

Could you also modify this docs?

https://github.com/zhaochenyang20/Awesome-ML-SYS-Tutorial/blob/main/rlhf/verl/multi-turn/tool_examples/profile.md

With your updated branch considering the over sample.

ok will do this later

zhaochenyang20 · 2025-08-12T20:09:48Z

Co-authored by:

https://github.com/PrinsYin
[email protected]

huapeng (already in the commit)

ChangyiYang [email protected]

and https://github.com/WindowsXp-Beta

PopSoda2002 · 2025-08-13T00:03:22Z

Additionally, I add the profile logic in https://github.com/zhaochenyang20/verl/tree/over_sample_profile, here I can share some results: It works right and padding time is minor

Could you also modify this docs?

https://github.com/zhaochenyang20/Awesome-ML-SYS-Tutorial/blob/main/rlhf/verl/multi-turn/tool_examples/profile.md

With your updated branch considering the over sample.

Done in zhaochenyang20/Awesome-ML-SYS-Tutorial#186

ChangyiYang · 2025-08-14T04:15:52Z

Great work，chenyang！

PrinsYin · 2025-08-14T04:19:54Z

Thanks chenyang!

…engine#2929) ### What does this PR do? This PR introduces an **over-sample strategy** for verl's SGLang multi-turn rollout to address the long-tail problem, where a few slow requests disproportionately increase the overall rollout time. The core idea is to over-sample the number of requests at the start of the rollout and then aggressively cancel any requests that haven't finished once a target number of completions is met. - **Improves rollout efficiency** for multi-turn conversations by reducing total time spent waiting for slow requests. - **Implements a new request monitoring and cancellation mechanism** to cut off unnecessary computation. wandb results is as follow: https://wandb.ai/zhaochenyang20/benchmark_over_sample_2/workspace?nw=nwuserzhaochenyang20 ----- Of course, this strategy has its share of issues. For example, many might question why the over-long requests that are dropped aren't simply saved and continued in the next round. This is certainly possible—it's a partial rollout strategy—but it would require verl to have a data buffer, which is beyond the scope of this PR. Furthermore, saving and continuing these requests would introduce an off-policy problem. There is also a valid concern that this rather "brutal" dropping strategy could unfairly ignore very long requests. I agree this is a very reasonable point, but currently, we don't have a lossless solution. However, our dropping strategy is very flexible and could even change with our curriculum learning. For instance, in the example I gave, I just directly dropped the last 20% of requests. **In practice, we can dynamically adjust this drop rate and even set different dropping methods. For example, we could record the return time (t) for the 80% of requests and then drop any requests that haven't returned after 1.5t.** We've provided an initial, validated idea and have completed its implementation. We welcome everyone to join the discussion on how to accelerate multi-turn rollouts with acceptable losses. ### Test The new over-sample strategy was tested with an 8-GPU setup on the **gsm8k** dataset, yielding the following results: - **Rollout Time:** Significant reduction in overall rollout time per step. - **Training Rewards:** - The reward metric for training steps shows a positive bias. This is because we exclude the aborted requests (which are typically more difficult and have lower rewards) from the reward calculation. - The reward metric for validation steps remains accurate and aligns with the baseline. This is because the cancellation logic is not triggered during validation, ensuring a fair and complete evaluation. ### API and Usage Example This feature modifies `sglang_rollout.py` and `metric_utils.py`. To use it, follow the standard setup and then run the training script with the over-sample parameters. https://github.com/zhaochenyang20/Awesome-ML-SYS-Tutorial/blob/main/rlhf/verl/multi-turn/release_log/over_sample.md ### Design & Code Changes The design is centered on three main functions that orchestrate the over-sampling logic: `run_with_cancellation`, `process_request_with_monitoring`, and `monitor_and_cancel`. These functions rely on global variables, such as `all_tasks` and `completion_lock`, to manage state. - **`run_with_cancellation`:** This is the entry point. It launches all requests as `process_request_with_monitoring` tasks concurrently with a single `monitor_and_cancel` task. It uses `asyncio.gather` to wait for all tasks to complete (or be canceled) and converts any exceptions from canceled tasks into padding requests before returning the final output. - **`process_request_with_monitoring`:** This async function handles a single request. It waits for the request to complete using `_async_rollout_a_request` and then checks a shared counter, `completed_count`, using a `completion_lock` for thread safety. If the target completion count has not been reached, it returns the real result. If the target has been met, it returns padding data instead, effectively "discarding" the late result. - **`monitor_and_cancel`:** This is a separate async task that polls the `completed_count`. Once the count reaches the `target_completion` threshold, it immediately cancels all remaining tasks and sends an `abort_requests` signal to the SGLang engine, halting any ongoing GPU computation for those requests. Key code changes: - **`sglang_rollout.py`**: - Adds the three core asynchronous functions for the over-sample strategy. - The `AsyncEngine` class now includes a new `abort_request` method that calls the synchronous `abort_request` in the `tokenizer_manager`. - **`metric_utils.py`**: - The `compute_data_metrics` function is updated to exclude the aborted requests (identified by padding) from the denominator when calculating average rewards during training. This prevents the training reward from being artificially lowered by the zero-reward aborted requests. This implementation is designed to be a straightforward and effective solution for the long-tail problem, though some aspects of the asynchronous design and the impact on training variance require further investigation. --------- Co-authored-by: zhaochenyang <[email protected]> Co-authored-by: PopSoda2002 <[email protected]> Co-authored-by: ChangyiYang <[email protected]> Co-authored-by: PrinsYin <[email protected]> Co-authored-by: WindowsXp-Beta <[email protected]> Co-authored-by: zhaochenyang20 <[email protected]>

…engine#2929) This PR introduces an **over-sample strategy** for verl's SGLang multi-turn rollout to address the long-tail problem, where a few slow requests disproportionately increase the overall rollout time. The core idea is to over-sample the number of requests at the start of the rollout and then aggressively cancel any requests that haven't finished once a target number of completions is met. - **Improves rollout efficiency** for multi-turn conversations by reducing total time spent waiting for slow requests. - **Implements a new request monitoring and cancellation mechanism** to cut off unnecessary computation. wandb results is as follow: https://wandb.ai/zhaochenyang20/benchmark_over_sample_2/workspace?nw=nwuserzhaochenyang20 ----- Of course, this strategy has its share of issues. For example, many might question why the over-long requests that are dropped aren't simply saved and continued in the next round. This is certainly possible—it's a partial rollout strategy—but it would require verl to have a data buffer, which is beyond the scope of this PR. Furthermore, saving and continuing these requests would introduce an off-policy problem. There is also a valid concern that this rather "brutal" dropping strategy could unfairly ignore very long requests. I agree this is a very reasonable point, but currently, we don't have a lossless solution. However, our dropping strategy is very flexible and could even change with our curriculum learning. For instance, in the example I gave, I just directly dropped the last 20% of requests. **In practice, we can dynamically adjust this drop rate and even set different dropping methods. For example, we could record the return time (t) for the 80% of requests and then drop any requests that haven't returned after 1.5t.** We've provided an initial, validated idea and have completed its implementation. We welcome everyone to join the discussion on how to accelerate multi-turn rollouts with acceptable losses. The new over-sample strategy was tested with an 8-GPU setup on the **gsm8k** dataset, yielding the following results: - **Rollout Time:** Significant reduction in overall rollout time per step. - **Training Rewards:** - The reward metric for training steps shows a positive bias. This is because we exclude the aborted requests (which are typically more difficult and have lower rewards) from the reward calculation. - The reward metric for validation steps remains accurate and aligns with the baseline. This is because the cancellation logic is not triggered during validation, ensuring a fair and complete evaluation. This feature modifies `sglang_rollout.py` and `metric_utils.py`. To use it, follow the standard setup and then run the training script with the over-sample parameters. https://github.com/zhaochenyang20/Awesome-ML-SYS-Tutorial/blob/main/rlhf/verl/multi-turn/release_log/over_sample.md The design is centered on three main functions that orchestrate the over-sampling logic: `run_with_cancellation`, `process_request_with_monitoring`, and `monitor_and_cancel`. These functions rely on global variables, such as `all_tasks` and `completion_lock`, to manage state. - **`run_with_cancellation`:** This is the entry point. It launches all requests as `process_request_with_monitoring` tasks concurrently with a single `monitor_and_cancel` task. It uses `asyncio.gather` to wait for all tasks to complete (or be canceled) and converts any exceptions from canceled tasks into padding requests before returning the final output. - **`process_request_with_monitoring`:** This async function handles a single request. It waits for the request to complete using `_async_rollout_a_request` and then checks a shared counter, `completed_count`, using a `completion_lock` for thread safety. If the target completion count has not been reached, it returns the real result. If the target has been met, it returns padding data instead, effectively "discarding" the late result. - **`monitor_and_cancel`:** This is a separate async task that polls the `completed_count`. Once the count reaches the `target_completion` threshold, it immediately cancels all remaining tasks and sends an `abort_requests` signal to the SGLang engine, halting any ongoing GPU computation for those requests. Key code changes: - **`sglang_rollout.py`**: - Adds the three core asynchronous functions for the over-sample strategy. - The `AsyncEngine` class now includes a new `abort_request` method that calls the synchronous `abort_request` in the `tokenizer_manager`. - **`metric_utils.py`**: - The `compute_data_metrics` function is updated to exclude the aborted requests (identified by padding) from the denominator when calculating average rewards during training. This prevents the training reward from being artificially lowered by the zero-reward aborted requests. This implementation is designed to be a straightforward and effective solution for the long-tail problem, though some aspects of the asynchronous design and the impact on training variance require further investigation. --------- Co-authored-by: zhaochenyang <[email protected]> Co-authored-by: PopSoda2002 <[email protected]> Co-authored-by: ChangyiYang <[email protected]> Co-authored-by: PrinsYin <[email protected]> Co-authored-by: WindowsXp-Beta <[email protected]> Co-authored-by: zhaochenyang20 <[email protected]>

…engine#2929) ### What does this PR do? This PR introduces an **over-sample strategy** for verl's SGLang multi-turn rollout to address the long-tail problem, where a few slow requests disproportionately increase the overall rollout time. The core idea is to over-sample the number of requests at the start of the rollout and then aggressively cancel any requests that haven't finished once a target number of completions is met. - **Improves rollout efficiency** for multi-turn conversations by reducing total time spent waiting for slow requests. - **Implements a new request monitoring and cancellation mechanism** to cut off unnecessary computation. wandb results is as follow: https://wandb.ai/zhaochenyang20/benchmark_over_sample_2/workspace?nw=nwuserzhaochenyang20 ----- Of course, this strategy has its share of issues. For example, many might question why the over-long requests that are dropped aren't simply saved and continued in the next round. This is certainly possible—it's a partial rollout strategy—but it would require verl to have a data buffer, which is beyond the scope of this PR. Furthermore, saving and continuing these requests would introduce an off-policy problem. There is also a valid concern that this rather "brutal" dropping strategy could unfairly ignore very long requests. I agree this is a very reasonable point, but currently, we don't have a lossless solution. However, our dropping strategy is very flexible and could even change with our curriculum learning. For instance, in the example I gave, I just directly dropped the last 20% of requests. **In practice, we can dynamically adjust this drop rate and even set different dropping methods. For example, we could record the return time (t) for the 80% of requests and then drop any requests that haven't returned after 1.5t.** We've provided an initial, validated idea and have completed its implementation. We welcome everyone to join the discussion on how to accelerate multi-turn rollouts with acceptable losses. ### Test The new over-sample strategy was tested with an 8-GPU setup on the **gsm8k** dataset, yielding the following results: - **Rollout Time:** Significant reduction in overall rollout time per step. - **Training Rewards:** - The reward metric for training steps shows a positive bias. This is because we exclude the aborted requests (which are typically more difficult and have lower rewards) from the reward calculation. - The reward metric for validation steps remains accurate and aligns with the baseline. This is because the cancellation logic is not triggered during validation, ensuring a fair and complete evaluation. ### API and Usage Example This feature modifies `sglang_rollout.py` and `metric_utils.py`. To use it, follow the standard setup and then run the training script with the over-sample parameters. https://github.com/zhaochenyang20/Awesome-ML-SYS-Tutorial/blob/main/rlhf/verl/multi-turn/release_log/over_sample.md ### Design & Code Changes The design is centered on three main functions that orchestrate the over-sampling logic: `run_with_cancellation`, `process_request_with_monitoring`, and `monitor_and_cancel`. These functions rely on global variables, such as `all_tasks` and `completion_lock`, to manage state. - **`run_with_cancellation`:** This is the entry point. It launches all requests as `process_request_with_monitoring` tasks concurrently with a single `monitor_and_cancel` task. It uses `asyncio.gather` to wait for all tasks to complete (or be canceled) and converts any exceptions from canceled tasks into padding requests before returning the final output. - **`process_request_with_monitoring`:** This async function handles a single request. It waits for the request to complete using `_async_rollout_a_request` and then checks a shared counter, `completed_count`, using a `completion_lock` for thread safety. If the target completion count has not been reached, it returns the real result. If the target has been met, it returns padding data instead, effectively "discarding" the late result. - **`monitor_and_cancel`:** This is a separate async task that polls the `completed_count`. Once the count reaches the `target_completion` threshold, it immediately cancels all remaining tasks and sends an `abort_requests` signal to the SGLang engine, halting any ongoing GPU computation for those requests. Key code changes: - **`sglang_rollout.py`**: - Adds the three core asynchronous functions for the over-sample strategy. - The `AsyncEngine` class now includes a new `abort_request` method that calls the synchronous `abort_request` in the `tokenizer_manager`. - **`metric_utils.py`**: - The `compute_data_metrics` function is updated to exclude the aborted requests (identified by padding) from the denominator when calculating average rewards during training. This prevents the training reward from being artificially lowered by the zero-reward aborted requests. This implementation is designed to be a straightforward and effective solution for the long-tail problem, though some aspects of the asynchronous design and the impact on training variance require further investigation. --------- Co-authored-by: zhaochenyang <[email protected]> Co-authored-by: PopSoda2002 <[email protected]> Co-authored-by: ChangyiYang <[email protected]> Co-authored-by: PrinsYin <[email protected]> Co-authored-by: WindowsXp-Beta <[email protected]> Co-authored-by: zhaochenyang20 <[email protected]>

zhaochen20 added 26 commits August 4, 2025 16:24

change the default bash of qqwen 2.5

953eae6

add engine support

0384aef

OVER_SAMPLE_RATE

a0ab8b0

update sgl rollout

652f0f7

is val

3fdfd00

self.abort

d37f51d

cancel task

51410e7

cancel then abort

de8feb3

fix await

da37e6a

finish over sample

5308507

Merge branch 'main' of https://github.com/zhaochenyang20/verl

25a15b9

Merge branch 'main' into over_sample_sgl

07ad3f9

add log to over sample

1b8bfa9

Add benchmakr script

519a1b0

increase to 45

ae43c5a

incrse

45265ec

add over sample

ef6ab93

Merge branch 'main' of https://github.com/zhaochenyang20/verl

264bed6

Merge branch 'main' into over_sample_sgl

0c63925

fix reward and loss cal

5d3b970

revert loss agg

89da6d7

revert reward padding

614f0ad

revert reward padding

08b7e02

finish

36abd78

revert non_aborted_mask

b979a73

clean up codes

b4fdfcf

zhaochenyang20 requested review from SwordFaith, chenhaiq, eric-haibin-lin and vermouth1992 as code owners August 5, 2025 21:25

WindowsXp-Beta reviewed Aug 12, 2025

View reviewed changes

verl/workers/rollout/sglang_rollout/sglang_rollout.py Outdated Show resolved Hide resolved

zhaochen20 added 14 commits August 13, 2025 15:26

Merge branch 'main' of https://github.com/zhaochenyang20/verl

4822564

Merge branch 'main' into over_sample

b28f178

fix rollout config

a794b29

do not capture all

cdc2eff

clean up validation

77e8491

fix conflicts register

4fd6b36

fix future

58f3570

use event loop

23452ed

get event loop

3ce9b1f

upd, fix up

d6128a2

fix up

ba87964

delete comment

96c5d75

Merge branch 'main' of https://github.com/zhaochenyang20/verl

c1e8884

Merge branch 'main' into over_sample

06beaf0

zhaochenyang20 merged commit ea885f3 into volcengine:main Aug 14, 2025
47 of 52 checks passed

Hecate0821 mentioned this pull request Sep 17, 2025

[trainer] feat: Upstream Dynamic Sampling #2988

Open

7 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[rollout] feat: support over sampling rollout in SGLang Rollout #2929

[rollout] feat: support over sampling rollout in SGLang Rollout #2929

Uh oh!

zhaochenyang20 commented Aug 5, 2025 •

edited

Loading

Uh oh!

WindowsXp-Beta Aug 12, 2025

Uh oh!

WindowsXp-Beta Aug 12, 2025

Uh oh!

zhaochenyang20 Aug 12, 2025

Uh oh!

Uh oh!

zhaochenyang20 commented Aug 12, 2025

Uh oh!

zhaochenyang20 commented Aug 12, 2025

Uh oh!

PopSoda2002 commented Aug 12, 2025

Uh oh!

zhaochenyang20 commented Aug 12, 2025

Uh oh!

PopSoda2002 commented Aug 13, 2025

Uh oh!

Uh oh!

ChangyiYang commented Aug 14, 2025

Uh oh!

PrinsYin commented Aug 14, 2025 •

edited

Loading

Uh oh!

Uh oh!

[rollout] feat: support over sampling rollout in SGLang Rollout #2929

[rollout] feat: support over sampling rollout in SGLang Rollout #2929

Uh oh!

Conversation

zhaochenyang20 commented Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Test

API and Usage Example

Design & Code Changes

Uh oh!

WindowsXp-Beta Aug 12, 2025

Choose a reason for hiding this comment

Uh oh!

WindowsXp-Beta Aug 12, 2025

Choose a reason for hiding this comment

Uh oh!

zhaochenyang20 Aug 12, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

zhaochenyang20 commented Aug 12, 2025

Uh oh!

zhaochenyang20 commented Aug 12, 2025

Uh oh!

PopSoda2002 commented Aug 12, 2025

Uh oh!

zhaochenyang20 commented Aug 12, 2025

Uh oh!

PopSoda2002 commented Aug 13, 2025

Uh oh!

Uh oh!

ChangyiYang commented Aug 14, 2025

Uh oh!

PrinsYin commented Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

zhaochenyang20 commented Aug 5, 2025 •

edited

Loading

PrinsYin commented Aug 14, 2025 •

edited

Loading