[Bugfix] Add regression test for MoE quant_config under torch.compile

[mgehre-amd]

Update: The fix landed separately via #34371 and this PR only adds the regression test.

Summary

After the MoE Refactor (#32344), w4a16 models fail with AssertionError: Hidden size mismatch 2048 != 1024 under torch.compile.
This is because ensure_moe_quant_config_init() is called in FusedMoE.forward_native(). When torch.compile is active, forward_native is traced by Dynamo, but the side effect of setting self.quant_method.moe_quant_config (an attribute mutation) is not replayed at runtime. This causes moe_quant_config to remain None when DefaultMoERunner.forward_impl executes inside the moe_forward custom op at runtime.

For W4A16-quantized MoE models (e.g. AWQ 4-bit), this means use_int4_w4a16 is False instead of True, causing the assertion hidden_states.size(1) == w1.size(2) to fail because packed 4-bit weights have half the expected dimension.

Fix: Call layer.ensure_moe_quant_config_init() at the start of DefaultMoERunner.forward_impl(), which runs inside the moe_forward custom op and is therefore not compiled by Dynamo.

Reproducer:

vllm serve RedHatAI/Qwen3-30B-A3B-Instruct-2507.w4a16 \
  --max-model-len 1024 --gpu-memory-utilization 0.85
# Without --enforce-eager, this hits:
# AssertionError: Hidden size mismatch 2048 != 1024
# With --enforce-eager it works because forward_native runs eagerly
# and the attribute mutation takes effect.

Test plan

• Added regression test test_w4a16_moe_torch_compile that loads a tiny W4A16 MoE model (nm-testing/tinysmokeqwen3moe-W4A16-first-only-CTstable) with enforce_eager=False and verifies inference succeeds.
• Verified the test fails without the fix (AssertionError: Hidden size mismatch) and passes with it.
• Ran tests/kernels/moe/test_moe.py (537 passed, 1 unrelated OOM skip).

[gemini-code-assist]

Code Review

This pull request correctly fixes a bug where the MoE quantization configuration was not being initialized at runtime when using torch.compile. The issue stems from Dynamo not replaying attribute mutation side effects from a traced function. The fix, which involves moving the initialization call into DefaultMoERunner.forward_impl (a function executed eagerly within a custom op), is sound and directly addresses the problem. The addition of a targeted regression test (test_w4a16_moe_torch_compile) is excellent, as it successfully reproduces the failure and validates the fix. The changes are minimal, well-commented, and effective.

[bnellnm]

Can you try putting this in _moe_forward and _moe_forward_shared instead?

[bnellnm]

This should be fixed on main now.

[mgehre-amd]

This should be fixed on main now.

Right, the fix landed on main via #34371 (31d992d).
However, #34371 did not add a regression test. This PR's test_w4a16_moe_torch_compile test case is still valuable to prevent future regressions.
@bnellnm, should I rebase this PR onto main (dropping the now-redundant code change) and merge it for just the test?

[bnellnm]

This should be fixed on main now.

Right, the fix landed on main via #34371 (31d992d). However, #34371 did not add a regression test. This PR's test_w4a16_moe_torch_compile test case is still valuable to prevent future regressions. @bnellnm, should I rebase this PR onto main (dropping the now-redundant code change) and merge it for just the test?

Sure, sounds good to me.

[mgehre-amd]

This should be fixed on main now.

Right, the fix landed on main via #34371 (31d992d). However, #34371 did not add a regression test. This PR's test_w4a16_moe_torch_compile test case is still valuable to prevent future regressions. @bnellnm, should I rebase this PR onto main (dropping the now-redundant code change) and merge it for just the test?

Sure, sounds good to me.

Done. This PR now only brings in the regression test.

[yewentao256]

LGTM, thanks for the work!