-
Notifications
You must be signed in to change notification settings - Fork 2.8k
[2/N][Bug] Fix w4afp8 MoE NaN issue (python) #9918
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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 @yuhyao, 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 resolves a critical numerical stability problem affecting the DeepSeek-R1 w4afp8 Mixture-of-Experts (MoE) inference. By upgrading the precision of intermediate computations, it ensures that model activations remain within a valid numerical range, thereby preventing the propagation of NaN values and maintaining the integrity of the inference process.
Highlights
- Numerical Stability Fix: Addresses a NaN (Not-a-Number) issue observed during DeepSeek-R1 w4afp8 MoE inference, caused by float16 overflow in grouped GEMM kernel outputs.
- Data Type Transition: The core solution involves switching the output data type of the grouped GEMM kernel from float16 to bfloat16 to leverage its wider dynamic range and prevent overflow.
- Accuracy Verification: Post-fix accuracy tests show improved results for EP8, with mmlu at 87.0 and AIME24 at 80.0, confirming the resolution of the issue without negative impact on model performance.
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. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
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
-
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. ↩
There was a problem hiding this 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 effectively resolves a NaN issue in the w4afp8 MoE kernel by switching the intermediate computation and output data types from float16
to bfloat16
. This change leverages bfloat16
's wider dynamic range to prevent overflows that were causing Inf
values and subsequent NaN
s. The fix is consistently applied across the Python layer, the C++/CUDA kernel definitions, and the test files. Additionally, the test suite's reference implementation has been improved to use float32
for intermediate calculations, enhancing its robustness and reliability. The changes are correct and well-implemented.
please provide the performace drop data |
Great work! I've just addressed this problem too, the same solution~ |
Just added, thanks for reviewing! |
we need to release a new sgl-kernel to pass the CI and get this PR merged cc @zhyncs |
Motivation
As reported in Issue#8493, NaNs may appear in the activations during DeepSeek-R1 w4afp8 inference. You can easily reproduce this issue with the following commands.
Command to launch server:
Command to send request:
Modifications
The root cause is that the w4afp8 grouped GEMM kernel uses float16 as the output type to improve throughput. However, in some cases the results exceed the maximum value of float16, producing Infs in the output, which then propagate through RMSNorm and turn into NaNs.
To resolve this, we switch the output type from float16 to bfloat16, which provides a wider dynamic range and avoids overflow in this scenario.
Note: the sgl-kernel changes are in PR#9953.
Accuracy Tests
After fix, EP8 achieves the following:
mmlu (sglang): 87.0
AIME24 (evalscope): 80.0 (43.33 before fix, probably crash if you set bs > 1.)
Benchmarking and Profiling
As noted earlier, using bfloat16 as the output type prevents overflow, but it comes at the cost of lower throughput in the GEMM kernel epilogue. Below, we present the benchmark results.
Benchmark configuration: ISL/OSL = 1000/1000, num_prompts=256, qps=64, max_concurrency=64.
Launching server using EP8:
Launching server using TP8:
The following results were obtained on 8×H800 GPUs.
EP8 results
Before fix:
After fix:
TP8 results
Before fix:
After fix:
Checklist