[XPU] Route grouped_topk to the fused _moe_C kernel on XPU - #53580
Merged
jikunshang merged 4 commits intoSep 7, 2026
Conversation
mfylcek
marked this pull request as ready for review
September 1, 2026 10:09
mfylcek
requested review from
mgoin,
pavanimajety and
zyongye
as code owners
September 1, 2026 10:09
Contributor
Author
|
@jikunshang @yma11 |
Contributor
|
Code change looks good to me. Can you provide data for model |
Contributor
Author
|
GLM-4.7-Flash, 128-in/128-out, concurrency 32, TP=4 on 4× B70:
|
yma11
approved these changes
Sep 2, 2026
Contributor
|
@jikunshang PTAL, thanks. |
Member
|
please rebase and fix dco issue. thanks. |
mayuyuace
approved these changes
Sep 2, 2026
vllm-xpu-kernels ships a fused grouped_topk (noaux_tc) kernel registered into the same `_moe_C::grouped_topk` op that CUDA uses, but both gates guarding it test `is_cuda()`, so XPU always fell back to the eager decomposition: 3 `aten::topk` launches plus ~10 elementwise ops per MoE layer per step. Measured on 1x BMG B70, arcee-ai/Trinity-Nano-Base (128 experts, topk=8, n_group=1, sigmoid + noaux_tc, 54 MoE layers), bf16, TP=1, eager: - routing device time 5.538 ms -> 2.469 ms over 3 steps (14.49% -> 7.25% of total device time), `aten::topk` disappears from the trace - mean TPOT 58.79 ms -> 56.70 ms (-3.6%), median ITL -4.3%, against a 0.5-0.65% run-to-run noise floor measured by repeating the baseline - fp32 selection is bit-identical to the eager reference (max weight delta 8.9e-8); bf16 differs only on biased-score ties The kernel's coverage matches vLLM's CUDA gate exactly (noaux_tc with a non-None e_score_correction_bias, n_group <= 32, topk <= 32), so no additional guard is needed on XPU. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Marceli Fylcek <marceli.fylcek@intel.com>
`_moe_C::grouped_topk` returns `(Tensor, Tensor)` and has no Meta kernel on either backend, so Dynamo cannot fake-tensor it and splits the routing graph around every call. Both backends allocate the outputs the same way (`new_empty` on `scores`, `(num_tokens, topk)`, float32 values and int32 indices), so one Python fake covers CUDA and XPU. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Marceli Fylcek <marceli.fylcek@intel.com>
mfylcek
force-pushed
the
xpu/enable-fused-grouped-topk
branch
from
September 2, 2026 08:12
6fb1ad2 to
b60a18d
Compare
Contributor
Author
|
@jikunshang 'verified' label is needed |
Member
|
/ci run |
|
✅ Triggered Buildkite CI #86958 for commit |
Contributor
Author
|
/ci run |
|
✅ Triggered Buildkite CI #87217 for commit |
Contributor
Author
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.
Purpose
vllm-xpu-kernels ships a fused grouped_topk (noaux_tc) kernel registered into the same
_moe_C::grouped_topkop that CUDA uses, but both gates guarding it testis_cuda(), so XPU always fell back to the eager decomposition.This PR routes grouped_topk to the fused _moe_C kernel on XPU and registers a fake (meta) implementation for _moe_C::grouped_topk, which previously had only device kernels and no meta kernel, so torch.compile could not trace through it resulting in graph breaks (not XPU-specific — adding the meta implementation helps on CUDA too).
Affects: every DeepSeek-V3-style (noaux_tc) MoE model — DeepSeek-V3/R1, Kimi-K2.6, Trinity-Nano, Ling/Bailing, GLM-4.5, Longcat-Flash
Test Result
Tested model: arcee-ai/Trinity-Nano-Base
Inputs: 4096-in / 1024-out, concurrency 48
B70 XPU