Repository navigation
🚨 Run MXFP4 GPT-OSS experts through ep_dispatch_experts - #49613
Open
IlyasMoutawwakil wants to merge 12 commits into
Open
IlyasMoutawwakil wants to merge 12 commits into
IlyasMoutawwakil wants to merge 12 commits into
Conversation
ep_dispatch_experts: experts take routed tokensep_dispatch_experts
|
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
ep_dispatch_expertsep_dispatch_experts: experts take routed tokens
IlyasMoutawwakil
force-pushed
the
ep-mxfp4-gpt-oss
branch
from
October 14, 2026 19:10
e5887b3 to
1f3a6b1
Compare
Contributor
|
[For maintainers] Suggested jobs to run (before merge) run-slow: llama4 |
IlyasMoutawwakil
force-pushed
the
ep-mxfp4-gpt-oss
branch
from
October 14, 2026 19:21
9517ef4 to
1f3a6b1
Compare
This was referenced Oct 14, 2026
IlyasMoutawwakil
force-pushed
the
ep-mxfp4-gpt-oss
branch
from
October 16, 2026 06:54
e67fc05 to
8b9dda1
Compare
ep_dispatch_experts: experts take routed tokensep_dispatch_experts
vasqu
approved these changes
Oct 19, 2026
vasqu
left a comment
Collaborator
There was a problem hiding this comment.
Yes fine for now, imo we should deprecate them all in a follow up with finegrained but better to fix for now indeed
Collaborator
|
Should be marked as 🚨 no? |
…on `ep_dispatch_experts` `Mxfp4GptOssExperts.forward` takes `(hidden_states, top_k_index, top_k_weights)` like every other experts class and builds the Triton routing metadata for its own experts from them (`routing_from_top_k`), skipping other ranks' routes. Under expert parallelism the patched MLP calls the router, then the experts, so every `ep_strategy` applies; single-device inference keeps the fused Triton routing through `forward_routed`. Replaces `routing_torch_dist`, which picked the local experts from `LOCAL_RANK` and the world size rather than the EP mesh. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
IlyasMoutawwakil
force-pushed
the
ep-mxfp4-gpt-oss
branch
from
October 27, 2026 21:49
8b9dda1 to
905d8b9
Compare
…ms 3-D so EP shards the scales Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ep_dispatch_expertsep_dispatch_experts
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
Author
|
yes done, the desc also lists the breaking changes now |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on #49607.
MXFP4 GPT-OSS did not run under expert parallelism on
main. Loadingopenai/gpt-oss-20bwithDistributedConfig(tp_size=2, ep_size=2)fails twice:IndexErrorinMxfp4Deserialize), and rank 0 gets every expert's scales. The expert params were declared with the 4-D shape of the blocks. So the loader took the 3-D scales for one expert's slice.ep_dispatch_expertsexpects(hidden_states, top_k_index, top_k_weights), so it fails withunexpected keyword argument 'scatter_idx'.Changes
All in
integrations/mxfp4.py:Mxfp4GptOssExperts.forwardtakes(hidden_states, top_k_index, top_k_weights), like every other experts class.routing_from_top_kbuilds the Triton routing metadata from them. It skips ids outside[0, num_experts), which are other ranks' routes. So everyep_implementationworks.mlp.experts.Mxfp4GptOssExperts.forward_routed.(experts, rows, packed bytes). EP now shards the checkpoint's blocks and scales the same way, on the expert dim.routing_torch_distis removed. It picked the local experts fromLOCAL_RANKand the world size, not from the EP mesh.🚨 Breaking changes
Mxfp4GptOssExperts.forwardtakes(hidden_states, top_k_index, top_k_weights). The old Triton routing call isforward_routed.routing_torch_distis removed.Mxfp4GptOssExperts.gate_up_projanddown_projare declared(experts, rows, packed bytes)before loading, not(experts, rows, blocks, 16).Tests
openai/gpt-oss-20bon 2 GPUs,ep_size=tp_size=2, against 1 GPU: 2 prompts, 48 greedy tokens"auto","all_reduce"and"all_to_all"mainand the parent PRtests/quantization/mxfp4on 1 GPU#49615 then removes the router-masked plan (
ep_router).🤖 Generated with Claude Code