Skip to content

Conversation

zhuzilin
Copy link
Collaborator

@zhuzilin zhuzilin commented Aug 1, 2025

Motivation

During colocated RL, we will use /release_memory_occupation to release all GPU allocations within model init, and we should not create GPU tensors that cannot be loaded through weight_loader.

This PR moves the creation of self.expert_map_gpu to forward and make sure self.expert_map_cpu is created on CPU (which was by default created on GPU).

Thank you for your time on reviewing this PR :)

Modifications

Accuracy Test

Benchmark & Profiling

Checklist

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary of Changes

Hello @zhuzilin, I'm Gemini Code Assist1! 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 introduces a critical memory optimization for the FusedMoE layer, particularly relevant when using Expert Parallelism (EP). My changes ensure that GPU memory is not prematurely allocated during model initialization, which is essential for efficient resource management in environments like colocated Reinforcement Learning.

Highlights

  • Memory Optimization: I've modified the initialization of self.expert_map_cpu to explicitly create it on the CPU, preventing it from defaulting to a GPU device during model setup.
  • Lazy GPU Tensor Creation: I've moved the creation and transfer of self.expert_map_gpu from the __init__ method to the forward method. This ensures the GPU tensor is only allocated when it's actually required for computation, significantly reducing the initial GPU memory footprint.
  • Support for Colocated RL: These changes specifically address memory management requirements in scenarios like colocated Reinforcement Learning (RL), where it's crucial to release GPU occupation and avoid creating GPU tensors that cannot be loaded via a weight loader.
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 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 or fill out our survey 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.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request addresses a critical memory management issue for FusedMoE with Expert Parallelism. The changes are logical, well-targeted, and align perfectly with the stated goal of avoiding premature GPU memory allocation. One minor suggestion is provided to refactor the lazy initialization logic for improved clarity.

@hebiao064
Copy link
Collaborator

Nice Catch, LGTM!

@ch-wan @fzyzcjy fyi, this is a interesting bug

topk_output = topk_output._replace(
topk_ids=self.expert_map_gpu[topk_output.topk_ids]
)
if not self.enable_flashinfer_cutlass_moe:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line does not follow the original logic. How about this?

Suggested change
if not self.enable_flashinfer_cutlass_moe:
if self.moe_ep_size > 1 and not self.enable_flashinfer_cutlass_moe:

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed.

@zhyncs zhyncs added high priority RLHF Using SGLang for post training labels Aug 3, 2025
@ch-wan ch-wan merged commit 3435a24 into sgl-project:main Aug 3, 2025
55 of 62 checks passed
htiennv pushed a commit to htiennv/sglang that referenced this pull request Aug 5, 2025
narutolhy pushed a commit to narutolhy/sglang that referenced this pull request Aug 17, 2025
narutolhy pushed a commit to narutolhy/sglang that referenced this pull request Aug 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
high priority RLHF Using SGLang for post training
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants