RuntimeError: wrong! device_gemm with the specified compilation parameters does not support this GEMM problem` that there used to be for some models using problem sizes not supported by aiter.

快速结论：该报错通常发生在 AMD ROCm 平台（gfx950/MI355）运行 Quark MXFP4 量化模型时，vLLM 将 `w_mxfp4_a_mxfp4` 量化路径调度到 AITER 原生 MXFP4 内核后输出损坏。优先排查 vLLM 中 `QuarkOCP_MX` 和 `QuarkOCP_MX_MoEMethod` 的权重/scale 预洗牌（shuffle）逻辑与 AITER 内核期望输入布局是否匹配。

适用环境：Ubuntu 22.04.5 LTS、Python 3.12.13、PyTorch 2.10.0+git（ROCm 7.2.53211 构建）、ROCm/HIP 7.2.53211、AMD EPYC 9575F、GPU 为 gfx950（MI355，sramecc+:xnack-），vLLM 环境通过 `docker pull rocm/vllm-dev:nightly_main_20260427` 复现。

最快修复方案：暂无确认的一步修复方案。Issue 中给出的临时绕过方法是修改代码强制 `emulate=True`（在 `QuarkOCP_MX_MoEMethod.__init__()` 和 `QuarkOCP_MX.create()` 中），这会切换到反量化后计算路径，但会损失性能。此方案需要代码改动，且未被直接验证。

注意事项：强制 emulate 路径仅是性能妥协，并非修复根本问题；Issue 已确认该问题由 vLLM 的 Quark MXFP4 集成引起，而非 ROCm 底层栈缺陷。若计划长期使用，建议等待上游修复，并关注 PR #39136 的进展。

问题场景

在 ROCm 平台（gfx950/MI355）上通过 vLLM 加载 Quark 量化的 `fxmarty/qwen_1.5-moe-a2.7b-mxfp4` 模型（`w_mxfp4_a_mxfp4` 量化方案，动态权重量化+动态激活量化）。触发路径涉及两类层：MoE 层（`FusedMoE`）和线性层（`qkv`、`out_proj`、`lm_head` 等），问题从生成第一个 token 起就开始出现。

报错原文

RuntimeError: wrong! device_gemm with the specified compilation parameters does not support this GEMM problem

（注：Issue 中同时指出，即使没有立即抛出该错误，模型也会从首个生成 token 开始产生损坏的乱码输出。）

原因分析

可能原因是 vLLM 的 Quark MXFP4 集成在 gfx950 上与 AITER 原生 MXFP4 内核存在布局不匹配。在 gfx950 上，`current_platform.supports_mx()` 返回 True，AITER 融合 MoE 被启用，因此调度直接进入原生 AITER MXFP4 内核路径（永远不会走模拟/仿真路径）。具体涉及两条代码路径：

MoE 层：`QuarkOCP_MX_MoEMethod` 在 `process_weights_after_loading` 中应用 `e8m0_shuffle`（来自 `aiter.utility.fp4_utils`）和 `rocm_aiter_ops.shuffle_weights` 预洗牌权重/scale，然后调用 `rocm_aiter_fused_experts()`，量化配置为 `quant_dtype=”mxfp4″`。
线性层：`QuarkOCP_MX` 对 `weight_scale` 应用 7D reshape+permute，权重应用 `shuffle_weight(layout=(16,16))`，随后调用 `gemm_with_dynamic_quant` → `gemm_a4w4`、`gemm_afp4wfp4_preshuffled_weight_scales`（ASM 路径）或 `gemm_afp4wfp4`（Triton 路径）。

最可能的根因是：预洗牌后的权重/scale 张量布局与 gfx950 上 AITER MXFP4 内核期望的输入布局不一致，导致内核从错误的内存地址读取数据。Issue 分析排除了 ROCm 底层（aiter、flydsl、TheRock、rocm-libraries、rocm-systems）中存在相关修复 PR 或已知正确性问题，并明确指出问题出在 vLLM 的 Quark MXFP4 集成代码中。

环境排查

确认 GPU 架构为 gfx950（通过 `rocminfo | grep gfx` 验证），系统是否已安装 ROCm 7.2 及以上版本。
确认 vLLM 是通过官方 ROCm nightly Docker 镜像（如 `rocm/vllm-dev:nightly_main_20260427`）安装，以便复现此问题。
确认量化包 amd-quark 版本 ≥ 0.8.99 已安装——注意 CI 中的 `test_ocp_mx_wikitext_correctness` 测试依赖 `QUARK_MXFP4_AVAILABLE` 标志，若包缺失会 静默跳过，使该 bug 在 CI 中结构性地不可见。
确认 Python 3.12、PyTorch 2.10.0+ ROCm 7.2 构建、HIP runtime 7.2.53211 与问题环境一致。

解决步骤

临时绕过（性能有损）：修改 vLLM 源码，在 `QuarkOCP_MX_MoEMethod.__init__()` 和 `QuarkOCP_MX.create()` 中强制设置 emulate=True，切换到反量化后计算路径。此方案仅用于临时规避，无环境变量开关可直接启用。
审计权重/scale 洗牌逻辑（建议优先）：对比验证 e8m0_shuffle + rocm_aiter_ops.shuffle_weights 的输出布局是否与 rocm_aiter_fused_experts 在 gfx950 上对 quant_dtype="mxfp4" 期望的输入布局一致；可对照 emulate=True 路径作为参考基准。
审计 7D scale 排列：检查 `QuarkOCP_MX.process_weights_after_loading` 中的 7D scale permutation 是否与 gfx950 上 gemm_a4w4/gemm_afp4wfp4_preshuffled_weight_scales 的实际内存访问模式匹配。
交叉参考相关 PR：查看 PR #39136（重构相邻的 quark_moe oracle 路径），其作者可能掌握额外上下文，有助于定位布局约定。
补充测试覆盖：在 test_ocp_mx_wikitext_correctness 中显式添加 xfail 或 skip（带明确的 ROCm 说明），而不是依赖包存在性的静默跳过，以便 CI 能暴露该问题。

验证方法

运行 `test_ocp_mx_wikitext_correctness`（确保 amd-quark 已安装且该测试不再被静默跳过），检查生成文本是否正确。或使用 `vllm serve` 加载 `fxmarty/qwen_1.5-moe-a2.7b-mxfp4` 模型，观察首个生成 token 开始是否出现乱码。若修改权重/scale 洗牌逻辑或 AITER 内核后，生成质量恢复正常且无 `RuntimeError: wrong! device_gemm…` 异常，即可确认问题解决。