[johncalesp]

Overview

The mixed-precision Qwen test expects four compiler-generated activation/quantization fusions—one per MLP—but the current NVIDIA Qwen implementation uses CompilationMode.NONE and performs these fusions
explicitly through maybe_fused_act_quant.

The test still reads the compiler’s fusion counter, which remains zero because the compiler pass does not run. Consequently, it fails with: Could not find 4 act_quant_fusion (found 0)

This is an outdated test expectation, rather than evidence of missing runtime fusion or a numerical mismatch. The original assertion reproduces on both Rubin and GB200.

This change updates the test to validate the current implementation:

• Require exactly one _C.silu_and_mul_nvfp4_quant operation in each of the four real MLPs, using inputs with 1 and 17 tokens.
• Verify that the downstream projection receives the expected packed QuantizedActivation, including its quantization key, dtype, and shapes.
• Compare each MLP’s output against the unfused activation/projection chain using the existing NVFP4 correctness criterion.
• Correct the fixture comment that incorrectly states the model has no manual fusion.

The original model configuration and both test parameterizations remain. No production code or existing numerical tolerances are changed.

Following #51012 and #61107, NVIDIA Qwen uses explicit activation/quantization fusion with compilation disabled. This test retained its compiler-pass expectation, causing it to report zero matches despite runtime fusion executing correctly. Update it to validate the model’s actual fusion path.

Validation

Validation on Rubin and GB200 produced 37 passed per GPU: two adapted E2E cases and 35 existing compiler, manual-fusion, and ModelOpt detection checks. A negative control disabling fusion in one layer correctly failed on both GPUs, confirming that the test detects missing fusion.

---

Pull Request Checklist

• I used vLLM's /pr-checklist skill. (Mandatory for agents, optional for humans).

• AI assistance was used during the creation of this PR.

• Design Fit: Minimizes impact on core components, reuses existing functionality, and justifies added complexity.

• Testing and Validation: Validates the change and ensures any added tests are meaningful and reliable, with CI coverage or documented CI resource constraints and validation performed outside CI.

• Code Quality and Style: Keeps code and comments clear and concise, and updates relevant documentation and examples.

• Pull Request Contents: Includes a brief summary and relevant links, supports claims with evidence, explains root causes and implementation trade-offs, and follows the contributing guide.

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

[arpera]

/ci run

[github-actions]

✅ @johncalesp, CI is now available for this PR.

• /ci run starts upstream CI; /amd-ci run starts AMD CI only.
• Run commands test your branch with every commit currently on its upstream target branch. If it is behind, the bot merges the target branch into it first (pull before pushing again). Append --allow-stale to a run command to test an outdated branch as is, at your own risk.
• /ci retry retries failed jobs in the CI build for the current PR head. If the current head has no CI build, it starts a new CI build for the current head containing only jobs that failed in the latest earlier CI build for this PR.
• /amd-ci retry retries failed jobs in AMD CI for the current PR head. Use /amd-ci run when the current head has no AMD CI build.
• /ci cancel cancels scheduled or running CI builds for this PR branch; /amd-ci cancel does the same for AMD CI only.

[github-actions]

✅ Triggered Buildkite CI #99682 for commit cfc1b3610971.