[Bugfix][MoE] Fix fused block-scale orientation

[AndreasKaratzas]

PR #50137 fixed fused per-channel scale loading, but shape-based orientation inference cannot reliably recover the checkpoint layout after both dimensions have been divided by the quantization block size. This causes Qwen3-VL's fused gate/up and down-projection block scales to load in the wrong orientation, producing this large-model acceptance failure.

Represent the fused checkpoint layout explicitly instead of inferring it from tensor shapes.

• Add an is_fused_checkpoint_transposed setting from the model layer through FusedMoEFactory to RoutedExperts.
• Enable the transposed layout for Qwen3-VL MoE while preserving the decoder-layer override used by downstream models such as InternS1Pro.
• Transpose fused weights and canonical block scales, while leaving per-channel scales and other independently laid-out quantization metadata unchanged.
• Cover standard and transposed w1/w2 weights and scales, including rectangular and square block-scale layouts.

Validation

• .venv/bin/pre-commit run --files vllm/model_executor/models/qwen3_vl_moe.py
• .venv/bin/python -m py_compile vllm/model_executor/models/qwen3_vl_moe.py
• Buildkite CI #82908 is running for commit fc82db14f0686d5709965f868c82d21f5b6b3e5b.
• No additional model evaluation was run for the constructor compatibility follow-up because it restores the existing decoder-layer injection contract and does not change inference outputs.

Duplicate work

This extends #50137 by handling explicitly transposed fused checkpoints and is not a duplicate of another open fix.

AI assistance

OpenAI Codex was used to inspect the Buildkite failures and prepare the constructor compatibility fix.

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}

[shen-shanshan]

Others LGTM.

[shen-shanshan]

This line is duplicate with https://github.com/vllm-project/vllm/pull/50727/changes?diff=split#diff-2c0390799c7c17903d1964888f6639f745335ccf4d13cb28b3dcf3f2316c8a2aR440-R443.
We can directly use intermediate_axis above as tp_shard_axis.

[AndreasKaratzas]

/ci run

[github-actions]

✅ Triggered Buildkite CI #82542 for commit c4b51da49a52.

[mgoin]

I’m concerned this patch is adding another shape heuristic over the underlying layout problem.

Before #47058, the Qwen3-VL loader explicitly knew that fused expert tensors were transposed. After that logic was centralized, RoutedExperts began inferring orientation from tensor dimensions. #50137 fixed one consequence of that inference for per-channel scales, and this PR adds a destination-shape fallback for block scales. The fallback in the PR works for the reported rectangular, unpadded shapes, but it is not generally safe. For instance, square block-scales would be not handled correctly.

My recommendation is to represent the fused checkpoint layout explicitly rather than infer it from shapes. For example, a fused_checkpoint_layout / is_fused_checkpoint_transposed property passed through FusedMoE to RoutedExperts, set by Qwen3-VL or the quantization scheme.

[AndreasKaratzas]

I’m concerned this patch is adding another shape heuristic over the underlying layout problem.

Before #47058, the Qwen3-VL loader explicitly knew that fused expert tensors were transposed. After that logic was centralized, RoutedExperts began inferring orientation from tensor dimensions. #50137 fixed one consequence of that inference for per-channel scales, and this PR adds a destination-shape fallback for block scales. The fallback in the PR works for the reported rectangular, unpadded shapes, but it is not generally safe. For instance, square block-scales would be not handled correctly.

My recommendation is to represent the fused checkpoint layout explicitly rather than infer it from shapes. For example, a fused_checkpoint_layout / is_fused_checkpoint_transposed property passed through FusedMoE to RoutedExperts, set by Qwen3-VL or the quantization scheme.

Ok, that actually makes sense, I wanted minimal diff tbh 😅 But instead of just patching this, I took upon your direction, lmk if the new is_fused_checkpoint_transposed makes sense :) Also, should we run all tests on this? Or generally enable some optional ones cause it's a wider diff now.

[AndreasKaratzas]

/ci run

[AndreasKaratzas]

/ci run

[github-actions]

✅ Triggered Buildkite CI #82795 for commit 54307aad7f00.

[AndreasKaratzas]

/ci retry

[github-actions]

✅ Queued 4 failed job(s) for retry in Buildkite CI #82795.

[AndreasKaratzas]

/ci run

[github-actions]

✅ Triggered Buildkite CI #82908 for commit fc82db14f068.

[AndreasKaratzas]

/ci run

[github-actions]

✅ Triggered Buildkite CI #83187 for commit 6e2345697d99.

[AndreasKaratzas]

/ci run

[github-actions]

✅ Triggered Buildkite CI #83382 for commit b16e4a94584c.