[aoshen02]

Summary

Trying to start DeepSeek-V4.1-Flash with VLLM_BATCH_INVARIANT=1 on a GB200,
every worker died with exactly this and nothing else:

NotImplementedError: No MXFP4 MoE backend supports the deployment configuration.

The generic MXFP4 selector in the same file raises with the diagnosis attached:

raise NotImplementedError(
    "No MXFP4 MoE backend supports the deployment configuration. "
    f"weight_key=kMxfp4Static, activation_key={activation_key}. "
    f"Candidate backends were: {[b.value for b in AVAILABLE_BACKENDS]}. "
    f"Unsupported reasons: {unsupported_log}. "
)

select_deepseek_v4_mxfp4_moe_backend collects the same per-backend reasons,
logs them at debug_once, and then throws them away. So on the models most
likely to land in an unusual configuration, the failure says the least.

In my case the reason was the batch-invariance gate in
modular_kernel.is_supported_config (envs.VLLM_BATCH_INVARIANT and not cls._supports_batch_invariance()), which I could only find by reading the
source. With this PR the error says it.

Change

Collect the rejection reasons in the DeepSeek-V4 path and include them in the
error, with the wording the generic path already uses.

Not a duplicate

gh pr list --search "mxfp4 backend selection error" returns backend additions
and unrelated fixes (#55232, #54032, #55275, #54109); none of them touches the
error path.

Test plan

pytest tests/kernels/moe/test_dsv4_mxfp4_backend_error.py -q   # 1 passed
pytest tests/kernels/moe/test_b12x.py -q -k deepseek           # 3 passed

CPU-only. The new test stubs a kernel class that refuses with a known reason and
asserts both the candidate list and that reason reach the exception.

pre-commit run --files vllm/model_executor/layers/fused_moe/oracle/mxfp4.py \
  tests/kernels/moe/test_dsv4_mxfp4_backend_error.py
# passed

No behavior change beyond the message: the same configurations succeed and the
same ones fail.

AI assistance

Developed with AI assistance (Claude). This came out of an actual multi-node run
on DeepSeek-V4.1-Flash, not a code read — the empty message is what cost the
time. I reviewed every changed line, ran the tests above, and I am the
accountable submitter.

🤖 Generated with Claude Code

Review rounds

An adversarial automated review was run over this diff against origin/main,
asked specifically whether the collection loop changes which backend is
selected, whether the new error path is reachable where the old code succeeded
(or vice versa), whether each reported reason is the actual rejection cause,
whether any backend is now probed that was previously skipped (import side
effects, CUDA init), and whether the report can leak an internal name or come
out empty or duplicated. It found no defects.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[aoshen02]

/ci run

[github-actions]

❌ This PR is 2 commits behind upstream main. Your branch must contain every commit currently on upstream main. No new CI build was started. Merge or rebase onto the latest main, then rerun /ci run. To test this branch at your own risk, use /ci run --allow-stale.

[aoshen02]

/ci run

[github-actions]

❌ This PR is 2 commits behind upstream main. Your branch must contain every commit currently on upstream main. No new CI build was started. Merge or rebase onto the latest main, then rerun /ci run. To test this branch at your own risk, use /ci run --allow-stale.

[aoshen02]

/ci run

[github-actions]

❌ This PR is 2 commits behind upstream main. Your branch must contain every commit currently on upstream main. No new CI build was started. Merge or rebase onto the latest main, then rerun /ci run. To test this branch at your own risk, use /ci run --allow-stale.