[Bugfix][Quantization][XPU] Fix moe_wna16 linear weight loading

[afierka-intel]

Bug

--quantization moe_wna16 cannot load a GPTQ MoE checkpoint.

MoeWNA16Config.get_quant_method rebuilds the linear delegate from self.full_config — the raw HF quantization dict, which lists shard names and never fused ones. The delegate matches nothing for qkv_proj/gate_up_proj, returns UnquantizedLinearMethod, and loading dies in linear.py:

AttributeError: 'MergedColumnParallelLinear' object has no attribute 'data'

Same failure as #53107. On XPU the flag is rejected even earlier, in Platform.verify_quantization, because moe_wna16 is missing from XPUPlatform.supported_quantization.

Fix

• moe_wna16.py — forward packed_modules_mapping to the linear delegate.
• xpu.py — add moe_wna16 to XPUPlatform.supported_quantization.

Two production files, +12/-6. No backend selection and no weight layout change: --quantization auto behaves identically on every platform, so the native XPU kernel keeps serving GPTQ MoE checkpoints exactly as it does today.

CudaPlatform defines no supported_quantization, so on CUDA only the mapping hunk applies.

Scope

The bug only occurs when MoeWNA16Config is the top-level resolved config, because only then does it handle LinearBase layers:

path	what handles the linear layers	affected
auto, Marlin-eligible shard	AutoGPTQConfig — native kernel, unchanged	no
auto, Marlin-ineligible shard (AutoGPTQConfig.get_quant_method falls back per layer)	AutoGPTQConfig; the per-layer MoeWNA16Config is built for RoutedExperts only, so it never sees a linear layer	no
--quantization moe_wna16	MoeWNA16Config	yes

That is why this is a fix for the explicit flag and not for auto-detection: on the auto paths the delegate is never asked to build a linear method, so packed_modules_mapping is not consulted there.

Test

pytest tests/quantization/test_moe_wna16.py — 2 new tests, both CPU-only (no GPU needed to review).

A/B on Intel Arc Pro B70, Qwen/Qwen1.5-MoE-A2.7B-Chat-GPTQ-Int4, --quantization moe_wna16 --moe-backend triton, one variable added at a time:

tree	result
main	moe_wna16 quantization is currently not supported in xpu.
+ allowlist	AttributeError: ... has no attribute 'data'
+ allowlist + mapping	weights load, Using 'TRITON' WNA16 MoE backend

Both hunks are therefore necessary, and together sufficient, to reach the Triton WNA16 MoE kernel for this checkpoint at TP=1.

Changed since the previous revision

The previous revision also changed WNA16 backend selection on XPU (_get_priority_backends plus a layout rejection in _backend_incompatibility_reason). Both hunks are dropped: they are not needed for the loading fix, and backend selection deserves its own change.

[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.

[yma11]

@afierka-intel Why do we need to add --quantization moe_wna16 when using this model? vLLM will auto detect the quantized model format and route to correct path. As I tried, w/o this flag, this model can serve properly.
python3 examples/basic/offline_inference/generate.py --model Qwen/Qwen1.5-MoE-A2.7B-Chat-GPTQ-Int4 --enforce-eager --max-model-len 8192

[afierka-intel]

@yma11 Thank you for your review!

You are right and thank you for the finding. I'll update the PR description accordingly.

For Qwen/Qwen1.5-MoE-A2.7B-Chat-GPTQ-Int4 specially, with no tensor parallelism and no explicit --quantization flag, auto-detection already works on XPU; AutoGPTQConfig's Marlin-support check passes for this checkpoint's shape, so it routes through AutoGPTQMoEMetod straight to the native XPU kernel. None of this PR's three fixes are exercised on that path.

They are still needed for two real cases:

1. --moe-backend triton on the same checkpoint, quantization left on auto, fails unconditionally. AutoGPTQMoEMethod always reports may_have_bias=True to the backend-selection oracle, and the triton backend rejects any config with expert bias (WNA16 MoE backend triton does not support the deployment configuration since expert bias is not supported). MoeWNA16Config is the only quantization path that reports may_have_bias=False, so it's the only way to reach the triton backend for a GPTQ MoE checkpoint at all - which matters because the companion PR [Kernel][Quantization][XPU] Tensor-descriptor path for fused_moe_kernel_gptq_awq (int4) #52652 adds a tensor-descriptor path to exactly that Triton kernel, and needs --quantization moe_wna16 to exercise it end to end.
2. The same checkpoint under TP=2, zero explicit flags. In this case intermediate_size_per_partition becomes 1408/2=704, not a multiple of the Marlin group size, i.e. 128, so AutoGPTQConfig falls back to MoeWNA16Config on its own <- no flag involved. On current main this crashes (ptr_A.size(1) must match ptr_b.size(1), the native XPU kernel handed a layout it doesn't understand); with this PR it falls back further to the Triton kernel instead and the crash goes away.

I hope this explains better the bug fix PR motivation. I'll update the description to keep the PR clear at first glance :)

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @afierka-intel.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[yma11]

LGTM to me. @jikunshang PTAL, thanks.

[afierka-intel]

/ci run

[github-actions]

✅ Triggered Buildkite CI #87513 for commit aa3b256c1119.