Eval bug: Vulkan: MiniMax-M2 prompt processing collapses at long context with ubatch above 128 on Strix Halo (gfx1151); long submits trigger

问题场景

在 Strix Halo（gfx1151）上使用 Vulkan 后端运行 llama.cpp，加载 MiniMax-M2.7 UD-IQ4_XS 模型，通过 llama-bench 进行 pp512 长上下文测试。默认设置下（Flash Attention auto、f16 KV cache），随着 ubatch 增大，32k 深度下的 prompt processing 速度不升反降；ubatch 512 时单次 GPU 提交时间过长，触发 amdgpu job timeout，最终表现为 device lost 崩溃。

报错原文

radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent.
ggml_vulkan: device lost on Vulkan0
terminate called after throwing an instance of 'vk::DeviceLostError'
  what():  vk::Queue::submit: ErrorDeviceLost

原因分析

Issue 最终定位：慢路径是 Flash Attention 配合 f16 KV cache 时的 strided f16 KV 读取。在长上下文、大 ubatch 下，这种读取模式导致单次 GPU 提交耗时异常增长，既造成吞吐崩塌，也触发 amdgpu 默认 job timeout，进而报 device lost。切换到 q8_0 KV cache 后速度恢复正常，说明问题与 f16 KV 的访存方式有关。PR #27703 针对该问题做了修复，Issue 中验证 f16 从 15.2 t/s 提升到 130.8 t/s，基本与 q8_0 持平。

另需注意：Issue 讨论中曾误判为 llama-bench 默认关闭 Flash Attention，后确认默认是 auto（对应用户环境即为开启）。原始测试的慢速路径实际是 fa auto + f16 KV。llama-server 中 Qwen3.8 27B 在 82k 上下文的崩溃发生在服务默认 Flash Attention 设置下，作者认为可能仍是单独问题，Issue 未进一步确认。

环境排查

• 确认 llama.cpp 构建版本，Issue 中问题版本为 23b0202a1 (11552)，修复版本为 3fdbb7132（含 #27703）。
• 确认后端为 Vulkan，设备为 Radeon 8065S（RADV STRIX_HALO，gfx1151）。
• 确认操作系统为 Linux，Issue 环境为 Ubuntu 26.04.1、kernel 7.0.0-38、Mesa RADV 26.0.8。
• 确认 llama-bench 或 llama-server 当前使用的 KV cache 类型（f16 还是 q8_0）。
• 确认 Flash Attention 设置（auto/0/1），Issue 中慢路径为 fa auto 或 fa 1 配合 f16 KV。
• 确认 ubatch 值，Issue 中 ubatch 512 触发崩溃，ubatch 128 明显更快。
• 确认是否设置了 amdgpu.lockup_timeout，默认超时下长提交会崩溃。

解决步骤

1. 升级 llama.cpp 到包含 #27703 的构建。Issue 中验证的修复构建为 3fdbb7132，修复后 f16 KV 在 Flash Attention 下 d32768、ubatch 512 的 pp512 从 15.2 t/s 提升到 130.8 t/s。
2. 如果暂时无法升级，可先将 KV cache 改为 q8_0。Issue 中 q8_0 在 stock 构建上 d32768、ubatch 512、fa 1 下为 132.8 t/s，且 q8_0 下更大的 ubatch 仍然有效（ubatch 2048 时 pp2048 @ d32768 为 174.2 t/s）。
3. 或者降低 ubatch 到 128。Issue 中默认 fa auto + f16 KV 下，ubatch 128 在 d32768 为 77.5 t/s，而 ubatch 512 只有 13.3 t/s。
4. 如仍遇到 device lost，可临时加上内核参数 amdgpu.lockup_timeout=60000，避免默认超时导致崩溃。Issue 中该参数使同一运行能完成，但速度仍受慢路径影响。
5. 使用 llama-bench 复测相同模型与深度，对比修复前后或不同 KV cache 下的 t/s，确认是否落入慢路径。

验证方法

在修复后的构建上，使用 MiniMax M2.7 UD IQ4_XS、pp512 @ d32768、ubatch 512、fa 1、f16 KV cache 复测，若 pp512 达到约 130 t/s（Issue 中为 130.8 t/s），且不再出现 device lost，即可确认问题已解决。Issue 中进一步验证了 d65536 下 f16 从 5.59 t/s 提升到 88.44 t/s，并且 d32768 下 f16 与 q8_0 表现一致。

参考来源

ggml-org/llama.cpp #30364

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。