Misc. bug: Vulkan ~12% prefill regression on RDNA4 (RX 9070 XT) since #29182 (MoE-aware mul_mat_id tile selection)

快速结论：这是 llama.cpp Vulkan 后端在 RDNA4（RX 9070 XT）以及 Strix Halo iGPU 上出现的 prefill 性能回退，报错 / 报障核心为 “Misc. bug: Vulkan ~12% prefill regression on RDNA4 (RX 9070 XT) since #29182 (MoE-aware mul_mat_id tile selection)”。通常发生在运行 llama-bench 或使用 llama.cpp Vulkan 后端对 MoE 模型做 prompt processing 时，优先排查是否命中了 #29182 引入的 MoE-aware mul_mat_id tile selection 逻辑。

适用环境：Linux；Vulkan 后端（GGML_VULKAN=ON）；AMD Radeon RX 9070 XT（RADV GFX1201，Mesa 26.0.8，kernel 7.0.0-31-generic）；Ryzen 7 7700X；同时对 Strix Halo 的 Radeon 8060S（RADV STRIX_HALO，gfx1151，Mesa 26.0.8，Linux 7.0）确认复现。模型包括 Qwen3.6-35B-A3B UD-IQ3_S（256 experts，top-8）和 gpt-oss-120b MXFP4（128 experts，top-4）。

最快修复方案：升级到包含 #29936（3c9e747f7）的版本；该提交对 #29182 做了回退，Issue 中确认修复生效。

注意事项：回退仅恢复 -ub 1024 场景下的 prefill，-ub 2048 表现基本不变。若无法升级，#29182 的父提交 da89bb3cc 性能正常，可作为临时回退参照；但这不是长期方案，且其他量化类型 / 小 batch 的混合结果在 #29182 评审时已被提及。

问题场景

用户在 Linux 上使用 llama.cpp Vulkan 后端运行 llama-bench 对 MoE 模型进行 prefill 基准测试。在 RX 9070 XT 上使用 Qwen3.6-35B-A3B（unsloth UD-IQ3_S，256 experts，top-8）时，自 #29182（MoE-aware mul_mat_id tile selection）之后，pp2048 @ d48000、-ub 1024 的 prompt processing 从约 2148–2154 t/s 降到约 1875–1899 t/s，回退约 12%。Strix Halo iGPU（Radeon 8060S，RDNA3.5，UMA）也出现类似回退；在 pp384 下约慢 6%，pp512 / pp2048 约慢 6% 左右。Token generation 不受影响。

报错原文

Misc. bug: Vulkan ~12% prefill regression on RDNA4 (RX 9070 XT) since #29182 (MoE-aware mul_mat_id tile selection)

94a0ae3e7 (#29182) reduces prompt processing by ~12% on an RX 9070 XT
94a0ae3e7298127b74d5b31370e83a1b4f143070 — vulkan: MOE aware mat_mul_id tile selection (#29182)

原因分析

根据 Issue 分析，#29182 在 MoE 场景下根据每专家平均行数选择 mul_mat_id 的 tile。使用 -ub 1024、top-8 路由、256 experts 时，n_per_expert = ceil(8*1024/256) = 32，选择器因此选了比之前更小的 tile（原先 n = 1024）。但专家路由并不均匀，最常用的专家实际行数远高于 32，在 RDNA4 上大 coopmat tile 对它们明显更快，于是整体 prefill 变慢。当 -ub 2048（n_per_expert = 64）时平均行数超过选择器阈值，回落到旧 tile，master 与父提交性能相同。可能原因还包括该选择逻辑仅按均值估算、未考虑 n_as 较大或小 batch 下的收益差异。

环境排查

确认 llama.cpp 构建版本，是否包含 94a0ae3e7（#29182）及之后提交；可用 git bisect 定位首次出现回退的提交。
确认 Vulkan 后端已启用（-DGGML_VULKAN=ON），并检查 ggml_vulkan 报告的设备与特性，例如 RADV GFX1201、fp16 / bf16、warp size、shared memory、KHR_coopmat。
确认 Mesa 版本与内核版本（Issue 中为 Mesa 26.0.8、kernel 7.0.0-31-generic），以及是否存在 UMA（Radeon 8060S 为 UMA）。
确认 -ub 取值（1024 / 2048 / 默认 512）以及模型 experts 数与 top-k 路由，因为这些会影响 n_per_expert 与 tile 选择。
确认问题只影响 prefill（pp），token generation（tg）基本不变。

解决步骤

先升级到包含 #29936（3c9e747f7）的版本；该提交回退了 #29182，Issue 中报告者确认 prefill 恢复。
若无法升级，可在本地对 94a0ae3e7 执行 git revert（Issue 中报告者使用 git revert –no-commit 验证），重新构建 Vulkan 后端后再测试。
仅在验证阶段，可将 -ub 改为 2048 观察是否回到正常水平；Issue 指出 -ub 2048 下表现基本不变，因此这只用于辅助定位，不是修复。
如仍需保留 #29182，可优先尝试按 Issue 建议方向评估补丁：使用每专家行数的最大值或高分位数替代均值、对大的 n_as 做缩放，或将改动限制在小 batch 场景；这些均为推测性方向，需自行验证。

验证方法

在相同硬件与模型下，使用与 Issue 相同的 llama-bench 参数复测 pp2048 @ d48000、-ub 1024：修复后应回到约 2145–2149 t/s 量级（Issue 中 3c9e747f7 为 2149.12 ± 3.69 t/s），而 -ub 2048 应基本不变（约 2180 t/s）。Strix Halo iGPU 上回退后 pp384 / pp512 / pp2048 应恢复到 #29182 之前的水平，同时 tg 无明显变化。