Fix Gemma4 NVFP4 MoE default attention backend - #26791
Conversation
There was a problem hiding this comment.
Code Review
This pull request refactors _handle_model_specific_adjustments in python/sglang/srt/server_args.py to cache model_config and introduces logic to detect Gemma4 models with modelopt_fp4 quantization and MoE enabled. For these models, the default attention backend is temporarily set to "triton" instead of "trtllm_mha" on SM100-supported hardware to avoid a known accuracy issue. The reviewer suggested explicitly casting the retrieved enable_moe_block attribute to a boolean to ensure robust logical checks.
I'm currently AFK, so I can't grab the For context on my run, I used the unmodified dependencies from |
4b043a7 to
eaa894c
Compare
|
/tag-and-rerun-ci |
pyc96
left a comment
There was a problem hiding this comment.
I think it makes sense to switch back to Triton given multiple reports of quality degradation with nvfp4 moe + trtllm_mha
|
Makes sense. But could you file a github issue for the accuracy issue so that I can ask @wenscarl to debug it? thanks! |
eaa894c to
01c1cd4
Compare
|
Merging for now until we have a clearer understanding of the issue and a verified fix in place |
Summary
I noticed that
nvidia/Gemma-4-26B-A4B-NVFP4is fully broken with the current SM10X defaulttrtllm_mhabackend. This is not just a small regression: MMLU drops from 0.622 withtritonto 0.037 with the default, and the outputs look nonsensical. This PR changes only the affected Gemma4 NVFP4 MoE default totriton; users can still explicitly pass--attention-backend trtllm_mha.Accuracy Comparison
nvidia/Gemma-4-26B-A4B-NVFP4trtllm_mhadefaultnvidia/Gemma-4-26B-A4B-NVFP4tritongoogle/gemma-4-26B-A4B-ittrtllm_mhadefaultnvidia/Gemma-4-31B-IT-NVFP4trtllm_mhadefaultNVFP4 MoE, Default TRTLLM MHA Attention
NVFP4 MoE, Triton Attention
BF16 MoE, Default TRTLLM MHA Attention
NVFP4 Dense, Default TRTLLM MHA Attention
CI States
Latest PR Test (Base): ✅ Run #26838018967
Latest PR Test (Extra): ❌ Run #26838018455