[ROCm][Bugfix] Fix MXFP4 MoE emulate fallback logic on MX-capable hardware

[ChuanLi1101]

Summary

Fix a Boolean logic regression in QuarkOCP_MX_MoEMethod.__init__ that prevented fallback to emulation mode on MI350X (gfx950) and other MX-capable hardware, causing gibberish output when AITER CK kernels are incompatible (e.g. ROCm version mismatch between quantization-time and serving-time).

Root Cause

The emulate dispatch logic introduced in PR #29008 had a Boolean expression that always evaluated to False on MX-capable hardware with w_mxfp4 schemes:

# OLD (buggy):
self.emulate = (
    not current_platform.supports_mx()           # False on MI350X
    or not self.ocp_mx_scheme.startswith("w_mxfp4")  # False for w_mxfp4_*
) and (self.mxfp4_backend is None or not self.use_rocm_aiter_moe)
# => (False or False) and (...) => False — always!

This made it impossible to fall back to emulation, even when:

• AITER CK kernels are incompatible (ROCm version mismatch)
• The user explicitly sets VLLM_ROCM_USE_AITER_MOE=0

Fix

Restructured the logic to be explicit and correct:

# NEW:
can_use_native_ck = (
    current_platform.supports_mx()
    and self.ocp_mx_scheme is not None
    and self.ocp_mx_scheme.startswith("w_mxfp4")
    and self.use_rocm_aiter_moe
)
can_use_mxfp4_backend = self.mxfp4_backend is not None
self.emulate = not (can_use_native_ck or can_use_mxfp4_backend)

Additional changes

• AITER version logging: Logs AITER version during weight processing to aid debugging version-mismatch issues
• Improved warning message: Added workaround hint (VLLM_ROCM_USE_AITER_MOE=0) to emulation warning
• Unit test: Added parametrized test covering 14 cases across the full dispatch matrix (hardware × scheme × AITER × backend). No GPU required, runs in <0.2s.

Fixes #36337

Test plan

• Unit test test_quark_moe_emulate.py passes (14/14 cases, 0.13s, no GPU needed)
• Verify amd/Kimi-K2.5-MXFP4 on MI350X with VLLM_ROCM_USE_AITER_MOE=0 produces coherent output (emulation path)
• Verify native CK path still works when AITER version is compatible
• Existing MXFP4 tests remain green

[mergify]

Hi @ChuanLi1101, the pre-commit checks have failed. Please run:

uv pip install pre-commit
pre-commit install
pre-commit run --all-files

Then, commit the changes and push to your branch.

For future commits, pre-commit will run automatically on changed files before each commit.

Tip

Is mypy or markdownlint failing?

mypy and markdownlint are run differently in CI. If the failure is related to either of these checks, please use the following commands to run them locally:

# For mypy (substitute "3.10" with the failing version if needed)
pre-commit run --hook-stage manual mypy-3.10
# For markdownlint
pre-commit run --hook-stage manual markdownlint

[ChuanLi1101]

cc @zejunchen-zejun @dllehr-amd @fxmarty-amd @maleksan85 — would appreciate a review since this touches the MXFP4 MoE emulate dispatch logic you've worked on. The fix is a one-line Boolean logic change + unit test.

[gemini-code-assist]

Code Review

This pull request correctly fixes a boolean logic regression that prevented fallback to emulation mode for MXFP4 MoE on MX-capable hardware. The new logic is clearer and more robust. The addition of comprehensive unit tests is excellent and ensures the correctness of the fix across various configurations. I've added one comment regarding exception handling for improved robustness.

[gemini-code-assist]

Using a broad except Exception: can mask underlying issues. For example, if the aiter module is present but fails to import due to an internal error (other than ImportError), this exception will be silently caught, making debugging more difficult. It's better to be more specific and catch only the expected ImportError.

Suggested change

	except Exception:
	aiter_version = "unknown"
	except ImportError:
	aiter_version = "unknown"

[ChuanLi1101]

Also cc @ganyi1996ppo @wuhuikx for review.

[fxmarty-amd]

LGTM. I think the test might be slightly overkill

[fxmarty-amd]

Suggested change

	and self.ocp_mx_scheme.startswith("w_mxfp4")
	and self.use_rocm_aiter_moe
	and self.ocp_mx_scheme.startswith("w_mxfp4")
	and self.ocp_mx_scheme.endswith("a_mxfp4")
	and self.use_rocm_aiter_moe

Fixes the same bug as #35855 (comment), introduced in introduced in #29008 (https://github.com/vllm-project/vllm/pull/29008/changes#r2877732813).

[BowenBao]

LGTM

[BowenBao]

thanks, fyi I plan to refactor emulate into a backend after #34285 is landed, so the logic can be merged and cleaned up.

[dllehr-amd]

Can we move this under https://github.com/vllm-project/vllm/blob/main/vllm/_aiter_ops.py maybe? pulling the version seems like something we probably want to have more generally available?