[RL] Fix illegal memory for _import_static_state

[hebiao064]

Motivation

Thanks @nanjiangwill for reporting this issue

To Reviewers:

• Please wait for Nan Jiang to verify the fix

To fix below issue in verl + sglang

Modifications

Test

Checklist

• Format your code according to the Code Formatting with Pre-Commit.
• Add unit tests as outlined in the Running Unit Tests.
• Update documentation / docstrings / example tutorials as needed, according to Writing Documentation.
• Provide throughput / latency benchmark results and accuracy evaluation results as needed, according to Benchmark and Profiling and Accuracy Results.
• For reviewers: If you haven't made any contributions to this PR and are only assisting with merging the main branch, please remove yourself as a co-author when merging the PR.
• Please feel free to join our Slack channel at https://slack.sglang.ai to discuss your PR.

[gemini-code-assist]

Summary of Changes

Hello @hebiao064, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an illegal memory access issue that was observed during the import of static model states, specifically within the verl + sglang context. The core change involves adding a synchronization barrier to ensure proper memory handling and prevent race conditions in distributed operations.

Highlights

• Memory Management & Distributed Synchronization: Introduced a torch.distributed.barrier call before the _import_static_state function. This synchronization step is crucial to prevent illegal memory access issues, particularly when resuming memory occupation for GPU weights in a distributed environment, ensuring all processes are aligned before state import.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to fix an illegal memory access error that occurs when resuming memory occupation. The proposed change adds a distributed barrier to synchronize processes before accessing model state. While this is the right approach, the implementation uses a CPU-based process group for the barrier, which does not guarantee synchronization of GPU operations. I've suggested using the GPU-based process group instead to ensure a correct and robust fix.

[zhaochenyang20]

amazing!

[hebiao064]

Repro steps:

1. Checkout latest verl + my branch: [sglang] chore: Upgrade SGLang 0.4.9 with multi-stage awake feature verl-project/verl#2187, pip install from source
2. Checkout latest sglang, pip install from source
3. Go back to verl, run bash examples/sglang_multiturn/run_qwen2.5-3b_gsm8k_multiturn.sh

Both Single Node and Multi Node would hit this issue. Seems like its easier to repro with multi node setup. For multinode setup, pls refer to: https://verl.readthedocs.io/en/latest/start/multinode.html