Bug: Native MMA FA kernel regresses prompt processing up to 2x at depth on RDNA4 (gfx1201) after rocWMMA removal

快速结论：该问题发生在 llama.cpp 移除 rocWMMA FlashAttention 内核后，RDNA4（gfx1201）显卡在深度上下文（深 KV cache）下进行 prompt processing 时性能严重回退，最深可达近 50% 的降速。优先排查你的模型注意力头维度是否为 256（这是受影响设备上触发回退的关键条件），并确认是否处于深度上下文预填充阶段。

适用环境：AMD Radeon R9700（Navi 48, RDNA4, gfx1201）或类似 RDNA3/RDNA4 显卡；ROCm 7.2.x；llama.cpp 在 commit fa72aecc（PR #26046）之后、且早于修复版本前的构建；受影响模型特征为注意力头维度大于 128（尤其是 256）。确认的 CPU 为 AMD Ryzen 7 7700，系统内存 61 GB。

最快修复方案：暂无官方确认的一步修复方案。当前已验证有效的权宜之计是暂时回退（reverse-apply）移除 rocWMMA 的 commit（fa72aeccb），或冻结在移除前的构建版本（如 c588c4f）用于预填充负载较重的工作。一位验证者报告，针对近期构建反向应用该 commit 可干净合并并完全恢复吞吐量（65k 深度下 569 vs 571 t/s），已本地运行数日无问题。

注意事项：直接提高代码中 DKQ 判断阈值（从 128 改到 256）虽能编译且输出正确，但性能反而比现有 tile kernel 更慢（65k 深度下 310 vs 344 t/s），说明该限制不仅是编译期限制，更是性能拐点，不能简单放宽。此外，直接回退可能影响其他 AMD 平台（如 gfx1151 上 rocWMMA 曾导致 -41% 预填充性能下降），且 rocWMMA 构建本身存在已知的测试失败问题，请自行权衡。

问题场景

用户在 llama.cpp 中加载 Qwen3.6-35B-A3B（Q4_K_M 量化，f16 KV cache）等模型进行长上下文 prompt processing 时触发。使用 llama-bench -p 4096 -n 64 -d 0,16384,65536,126976 -ngl 99 -r 3 基准测试可复现。回退幅度随 KV cache 深度增加而急剧扩大：在 16k 上下文时约慢 25%，在 127k 上下文时约慢 49%（几乎为 2 倍降速）。Token 生成（tg）阶段不受影响，甚至略有提升。

报错原文

Bug: Native MMA FA kernel regresses prompt processing up to 2x at depth on RDNA4 (gfx1201) after rocWMMA removal

# Benchmark: pp4096 @ d126976
# c588c4f (rocWMMA FA): 777.27 ± 0.15 t/s
# 42fc2430 (native FA): 394.81 ± 0.10 t/s
# Delta: -49.2%

该问题不伴随崩溃或显式错误信息，而是通过基准测试发现的静默性能回退。仅在尝试修改代码以放宽限制时会出现设备代码编译错误：

fattn-mma-f16.cuh:1763: ERROR: HIP kernel flash_attn_ext_f16 has no device code compatible with HIP arch 1300.

原因分析

可能原因：Commit fa72aecc（PR #26046）移除了 rocWMMA FlashAttention 内核路径后，新的原生 fattn-mma-f16 内核在 RDNA4（gfx1201）上存在一个未被覆盖的缺口。深入分析发现，影响范围并非所有 gfx1201 显卡，而是注意力头维度（head dim）大于 128 的模型（特别是 head dim = 256 的模型）。在 RDNA WMMA 硬件上，fattn-mma-f16.cuh 明确拒绝为 head dim 大于 128 的情况发射设备代码（CDNA 架构允许到 256），而宿主端调度逻辑也施加了相同的 128 上限。被移除的 rocWMMA 内核恰好覆盖了这一区间（处理 256 但排除 40/72/192/512/576）。因此，此类模型在移除后没有任何张量核心 FlashAttention 路径，只能回退到较慢的 flash_attn_tile 内核。Qwen 3.5 和 3.6 全系列（9B 至 122B，包括 dense 和 MoE）均使用 head dim 256，受影响范围较大。更深层的原因是原生内核的 tile 形状、LDS 使用和流水线可能是针对 CDNA/NVIDIA 架构调优的，在 RDNA4 的 wave32 和 V_WMMA_F32_16X16X16_F16 指令下，深度上下文时矩阵核心利用率不足。

环境排查

确认 GPU 是否为 RDNA 架构（gfx1201 = Radeon R9700 / Navi 48），而非 CDNA 数据中心卡。
确认模型注意力头维度是否大于 128（尤其注意 Qwen 3.5/3.6 系列，均为 256）。可通过 GGUF 模型元数据或推理日志确认。
确认 llama.cpp 构建时间：如果是在 commit fa72aecc（PR #26046）之后且尚无修复的版本，则受影响。
检查构建参数：CMAKE_HIP_ARCHITECTURES=gfx1201、GGML_HIP=ON；为公平对比应关闭 GGML_HIP_NO_VMM（或对比时保持一致）。
确认 ROCm 版本 7.2.x，以及是否启用 HIP Graph（GGML_HIP_GRAPHS），因为 HIP Graph 与 rocWMMA FA 存在已知冲突。
执行 rocprofv3 --kernel-trace 确认实际执行的内核名称：受影响时运行的是 flash_attn_tile<256, 256, 4, 8, false>，而非快速的 flash_attn_ext_f16<256, 16, 4, 64, float, false>。

解决步骤

确认受影响范围：先确认模型 head dim > 128。如果不是，此问题可能不适用。如果 head dim = 256 且使用 RDNA3/RDNA4，则按以下步骤处理。
方案一（临时但可靠）：回退移除 rocWMMA 的 commit。对当前构建执行 git revert fa72aeccb（或反向应用该补丁）。一位验证者报告该 revert 可干净应用到 b10154 和 b10182 且无冲突，能完全恢复预填充吞吐量，已本地运行数日无问题。这是当前数据支撑最强的临时方案。
方案二（冻结构建）：如果你不需要最新功能，可保留移除去年前的构建版本（如 c588c4f），并启用 GGML_HIP_ROCWMMA_FATTN=ON 构建。此方案适合以预填充为主要负载的工作场景。
临时排查基准：在同一硬件上使用 llama-bench 对比当前版本和历史版本，设置 -d 0,16384,65536,126976 深度序列，确认回退幅度是否与此 Issue 数据一致。
对维护者/高级用户的建议：不要尝试简单放宽 fattn-mma-f16.cuh 中的 DKQ > 128 限制——实测放宽到 256 后性能反而低于现有 tile kernel（65k 深度下 310 vs 344 t/s）。需要真正的 tile/LDS 调优才能实现 MMA kernel 在 RDNA 上支持 head dim 256。长期修复方向是扩展 fattn-mma-f16.cuh 以高效支持 DKQ 至 256，或恢复 fattn-wmma-f16.cu 但仅限定 RDNA 的 head dim > 128 场景，避免影响 gfx1151 等平台（见 #24437 中 rocWMMA 在这些平台上反而导致 -41% 性能回退）。

验证方法

在相同硬件和相同条件下运行 llama-bench -p 4096 -n 64 -d 0,16384,65536,126976 -ngl 99 -r 3，对比回退处理前后的结果。恢复后应看到 pp4096 @ d65536 与 d126976 的吞吐量显著提升（例如从 344 恢复到 569 t/s @ d65k，从约 395 恢复到约 777 t/s @ d127k）。也可使用 rocprofv3 --kernel-trace 确认实际调度的内核已从 flash_attn_tile 变回快速的 flash_attn_ext_f16。同时请确认 token 生成（tg）性能没有回退，且多次运行结果稳定（建议 -r 3 取多次平均值）。