[Bugfix] Gate the fused_moe tensor-descriptor path on hardware support

[afierka-intel]

Summary

invoke_fused_moe_triton_kernel decided use_td from resolve_moe_use_td() alone:

use_td = resolve_moe_use_td() and not is_quantized

moe_use_td_hw_supported() lives in the same module (fused_moe/utils.py) and exists precisely to answer "can this device run the TD gather path", but on current main it is never called from vllm/ — git grep finds it only in its own definition and in tests/.

Both the line above and the unused helper come from the same commit, #42436 (6f00a1ae3b), which added the TD path and documented in resolve_moe_use_td()'s own docstring that forcing TD where it cannot compile "fails at ptxas" — the check was written but never wired into the launcher.

Consequence: VLLM_TRITON_USE_TD=1 on sm90 enables TD for unquantized MoE and fails in ptxas.

Reproduction

H200 NVL, unpatched CI image at the current base, unquantized bf16 MoE through fused_experts:

resolve_moe_use_td()      = True    <- what the launcher used
moe_use_td_hw_supported() = False   <- what it should also have checked

PTXASError: Feature '.tile::gather4 with destination state space as
.shared::cta' requires .target sm_100 or higher

The not is_quantized term is the only thing that keeps the quantized variant of this crash out of reach today.

Why the fix goes here and not in use_tensor_descriptor()

My first instinct was to put a hardware check inside the shared use_tensor_descriptor() helper, so every call site would be covered at once. Measured on an H200, that would have been wrong:

operation	sm90
descriptor.load() (plain TMA)	compiles and runs
descriptor.gather()	fails — tile::gather4 requires sm100+

So Hopper supports tensor descriptors; only gather4 is missing. fused_moe_kernel's A-load gathers by sorted_token_ids, which is why it is affected. The .load()-only users — fused_batched_moe.py (:494) and the compressed-tensors scaled_mm path from #47205 (:241) — are not affected, and a blanket gate in the shared helper would have disabled a working path on Hopper.

The fallback logs

warn_if_moe_use_td_ineffective() returns early for unquantized Triton MoE, so gating alone would have turned a crash into a completely silent downgrade — the user sets the flag, gets the pointer path, and has no way to tell. The gate therefore logger.warning_onces, in the same shape as the K-alignment fallback ~50 lines below it.

Test plan

Regression test

tests/kernels/moe/test_moe.py::test_fused_moe_td_gated_on_hw_support — asserts the USE_TD kwarg the launcher passes to fused_moe_kernel, with the launch itself recorded instead of executed. Two legs: hardware unsupported → USE_TD False, hardware supported → USE_TD True (control, so the gate cannot pass by disabling TD everywhere). fused_moe_kernel has exactly one launch site, so this pins the whole decision.

Because it never compiles a kernel, it runs on any device capability — including the one the crash was found on, where the existing use_td=True cases skip.

The test pins resolve_moe_use_td to True in addition to setting VLLM_TRITON_USE_TD=1. That is not belt-and-braces: EngineCore.__init__ calls envs.enable_envs_cache(), which wraps envs.__getattr__ in functools.cache and eagerly reads every variable, so a later monkeypatch.setenv is invisible. I reproduced that — with the cache primed while the variable is unset, the resolver keeps reporting False, and the hw_supported=True control leg of a setenv-only version of this test fails. pytest kernels/moe does not build an engine in-process today, so this is latent rather than a live break, but the subject under test is the hardware gate, so its input is pinned rather than left to test ordering.

Measured on H200 (sm90), postmerge CI image at this PR's base commit:

	before	after
test_fused_moe_td_gated_on_hw_support	fails — AttributeError: module ... has no attribute 'moe_use_td_hw_supported' (the launcher does not consult it)	1 passed
existing test_fused_moe slice, with and without VLLM_TRITON_USE_TD=1	2 passed, 2 skipped	2 passed, 2 skipped (unchanged; the use_td=True legs skip on sm90 by design)

Disclosure on that H200 row: it was measured before the resolver pin described above was added, i.e. on a body that drove the resolver purely through the env var. The pin only changes how the resolver's True is supplied, and the before/after verdicts do not move — before still fails at the same monkeypatch.setattr(..., "moe_use_td_hw_supported", ...) line, which is reached first and raises because a pre-fix launcher never imports that symbol. I re-ran the recorded-USE_TD decision for both legs and both bodies off-GPU to confirm the pinned version records the same values.

Crash reproduction

Unquantized bf16 MoE through fused_experts with VLLM_TRITON_USE_TD=1 forced, same image and shapes on both platforms:

platform	before	after
H200 (sm90)	PTXASError (above)	runs, finite output, one Disabling VLLM_TRITON_USE_TD ... warning
B200 (sm100)	runs	runs, finite output — moe_use_td_hw_supported() is True, so TD is still taken

The B200 leg is the control: the gate must not disable TD where it works. The B200 row was measured before the fallback was made to log; the sm100 path does not reach that branch.

ruff check + ruff format --check clean (ruff 0.14.0, as pinned in .pre-commit-config.yaml).

Relationship to other PRs

Found while validating afierka-intel#6 (a TD path for fused_moe_kernel_gptq_awq). That PR gates its own launcher on moe_use_td_hw_supported(); this one fixes invoke_fused_moe_triton_kernel, which did not consult it at all. This PR stands alone as a crash fix and does not depend on #6.

Merge interaction with #6, measured rather than asserted: both branch off the same base and both touch this file, so I checked instead of guessing. git merge-tree --write-tree against #6's current head is clean in both orders — no conflict, so neither PR blocks the other and there is nothing to rebase. I inspected the merged file rather than trusting the exit code: it keeps #6's expanded # This kernel has no TD path ... comment, keeps this PR's hardware guard below the untouched use_td = ... line, and ends up with both launchers gated (fused_moe_kernel_gptq_awq via #6, invoke_fused_moe_triton_kernel via this PR) with no duplicated import — both branches add the identical moe_use_td_hw_supported, line, which git merges as one.

An earlier revision of this PR did conflict, because it rewrote the use_td = ... line and its comment in place — the same lines #6 replaces. Adding a separate guard below that line instead removes the overlap, which is a second reason to prefer the current shape over folding the check into the existing boolean. There is no logical conflict either: #6 keeps use_td for the quantized WNA16 kernel, this PR narrows it for the unquantized one.

---

AI assistance was used (Claude Code); every changed line was reviewed and all tests above were run personally on NVIDIA H200 and B200 hardware.

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

PRs do not trigger a full CI run by default. Reviewers with write access and configured trusted contributors can comment /ci run whenever CI signals are needed.

Once the PR is approved or has the ready label, the PR author can also use /ci run, /ci retry, or /ci cancel. New commits do not start CI automatically.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

Agent Guidelines

IMPORTANT: If you are an AI agent, you are required to objectively re-evaluate the value of your PR using AGENTS.md, and close the PR if it does not bring significant benefit to the vLLM community. Failure to do so may result in an immediate ban.

🚀