-
Notifications
You must be signed in to change notification settings - Fork 2.7k
[https://nvbugs/5986434][fix] Fall back from TRTLLM MoE backend on pre-Blackwell GPUs #17570
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -98,6 +98,10 @@ class TRTLLMGenFusedMoE(MoE): | |
| onesided_workspace_dtype=torch.bfloat16, | ||
| ) | ||
|
|
||
| # SM versions the TRTLLM-Gen MoE kernels are built for (Blackwell family). | ||
| # Read by create_moe.get_moe_cls to fall back on other architectures. | ||
| _SUPPORTED_SM_VERSIONS = (100, 103) | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Two more hardcoded copies of this set remain in the same file: |
||
|
|
||
| # Supported quantization algorithms for TRTLLMGenFusedMoE | ||
| _SUPPORTED_QUANT_ALGOS = { | ||
| QuantAlgo.NVFP4, | ||
|
|
@@ -161,7 +165,7 @@ def can_implement( | |
| sm_version = get_sm_version() | ||
|
|
||
| # TRTLLMGenFusedMoE requires SM in {100, 103} | ||
| if sm_version not in {100, 103}: | ||
| if sm_version not in cls._SUPPORTED_SM_VERSIONS: | ||
| return _warn_and_return( | ||
| f"TRTLLMGenFusedMoE requires SM100 or SM103, got SM{sm_version}" | ||
| ) | ||
|
|
||
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.
Returning
CutlassFusedMoEhere without updatingmodel_config.moe_backendleaves the rest of the stack configured for TRTLLM-Gen. The concrete failure:modeling_gpt_oss.py:174picksoutput_dtype=torch.bfloat16for the routing method whenever the string is"TRTLLM", andmoe_scheduler.py:407assertsfloat32for Cutlass instead of casting — so GptOss with an explicitTRTLLMbackend on SM90/SM120 still dies at init after this change.Suggest doing the SM gate in
ModelConfig.resolve_moe_backend(or normalizingmodel_config.moe_backend = "CUTLASS"when falling back here) so the resolved name and the instantiated class agree for every string-based consumer.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.
Please do not add additional fallbacks here.
Fallbacks will soon be deprecated. Users should explicitly set CUTLASS rather than relying on fallbacks provided by TRTLLM.
The new MOE design should honor user‑provided configurations and throw an error when unsupported settings are encountered.
Please update the test case and close this PR.