qwen4exp (Qwen3.8-Flash-Next): severe decode slowdown beyond ~1K context on HIP / gfx1151 (Strix Halo)

快速结论：该报错发生在 AMD Strix Halo (gfx1151) 上使用 llama.cpp 运行 Qwen3.8-Flash-Next 模型时，一旦上下文超过约 1K tokens，解码速度会出现 3.5-4 倍的断崖式下降。优先排查 HIP 后端是否因缺少 hipCUB 支持而将 ggml_top_k/ARGSORT 操作回退到 CPU 执行。

适用环境：llama.cpp（包含 PR #27742 的构建）；AMD Strix Halo (Ryzen AI Max+ 395, gfx1151 iGPU, 128 GB 统一内存)；ROCm 7.2.4。

最快修复方案：暂无确认的一步修复方案。Issue 确认的修复路径是使用包含 hipCUB 补丁的构建（#27874），或等待 PR #27466 合并入主线。

注意事项：即使修复后，在超长上下文（52K+）下仍会存在较平缓的线性性能下降，这是完整的全 KV 流式处理开销。此外，该问题可能并非 HIP 独有——CPU 后端在超长上下文下同样存在明显性能衰减，并非单一后端缺陷。

问题场景

用户在 AMD Strix Halo (gfx1151) 设备上通过 llama.cpp 运行 Qwen3.8-Flash-Next GGUF 模型。问题表现为：短提示词（<512 tokens）时解码速度约 19-21 tok/s，但当总上下文超过约 1K tokens 后速度急剧下降，最终在 2K 以上稳定在约 5.5-6.1 tok/s，形成约 3.5-4 倍的性能悬崖。该问题可通过 llama-bench --n-depth 命令直接复现，无需启动服务器。

报错原文

qwen4exp (Qwen3.8-Flash-Next): severe decode slowdown beyond ~1K context on HIP / gfx1151 (Strix Halo)

原因分析

已确认的根本原因：在未启用 GGML_CUDA_USE_CUB 的情况下，HIP 后端的 supports_op 将 TOP_K/ARGSORT 操作限制为 ne[0] <= 1024 列。QSA 索引器在解码每一步都会执行 ggml_top_k（其中 ne[0] == n_kv，涉及 12 个 QSA 层），当上下文超过约 1K 阈值后，该操作会回退到 CPU 执行，导致每个 token 每层都产生 GPU→CPU→GPU 的同步开销。

可能的附加因素：社区数据显示 CPU 后端在超长上下文下也只达到约 7.71 tok/s，而 CUDA 在 131K 深度下解码速度下降约 70%（并非 Issue 标题所述的”轻微衰减”）。这可能意味着 QSA 解码图中的通用 ggml 操作（索引器分数 → top_k → 逐 token gather）仅由 CUDA 后端通过专用内核加速，CPU 和 HIP 均回退到通用慢速路径。

环境排查

确认使用包含 PR #27742 的 llama.cpp 构建版本
确认运行环境为 AMD Strix Halo (gfx1151) + ROCm 7.2.4
检查构建时是否启用了 GGML_CUDA_USE_CUB 宏（HIP 后端依赖此宏启用 hipCUB 支持）
确认模型为 Qwen3.8-Flash-Next GGUF（测试中使用了 IQ1_S 和 IQ3_XXS 量化版本）
在同一硬件上对比 llama-bench --n-depth 在不同上下文深度（0 / 256 / 512 / 1024 / 2048 / 4096 / 8192）下的解码速度

解决步骤

复现问题：使用 llama-bench -m <模型路径> -ngl 999 -fa 1 -lm none -r 1 -p 512 -n 128 -d 0,256,512,1024,2048,4096,8192 获取各深度的解码速度基线。
确认根因：检查构建配置中是否启用了 GGML_CUDA_USE_CUB。未启用时，HIP 后端的 supports_op 会将 TOP_K/ARGSORT 限制在 1024 列以内，超出后回退 CPU。
应用修复（可优先尝试）：使用包含 PR #27874 的补丁重建 llama.cpp（该补丁启用了 hipCUB 支持），或等待 PR #27466 合并入主线后升级。Issue 验证显示修复后：<1K 时为 20.2 t/s，18K 时为 20.1 t/s，52K 时为 11.7 t/s，性能悬崖消失。
检查 MTP 附加模型：如果使用 MTP draft sidecar 且设置 --n-cpu-moe 4，确认是否存在 ~1K 上下文的 prefill 崩溃。Issue 中有一例数据点：无 MTP 时 prefill 稳定在 340-380 t/s，挂载 MTP 后超过 ~1.2-1.7K tokens 时 prefill 从 362 t/s 骤降至 10 t/s 并持续崩溃。
验证修复：重新运行 llama-bench 对比各深度的解码速度，确认 1K 处的断崖是否消除。

验证方法

重新运行 llama-bench --n-depth 测试，观察从 512 到 1024 tokens 的过渡区间。如果修复成功，解码速度应保持平稳（如 20.2 → 20.1 t/s 从 <1K 到 18K），而非从此前的约 19.5 t/s 骤降至约 6 t/s。若在超长上下文（50K+）下仍有小幅下降，属于预期的全 KV 流式处理开销，不再构成报错条件。