[Vulkan] GGML_ASSERT(neq0 == HSK) failed in ggml-vulkan.cpp during speculative draft decoding (MTP) with tensor split

快速结论：这个报错通常出现在 llama.cpp 使用 Vulkan 后端、开启 MTP 推测解码（--spec-type draft-mtp）并配合 tensor split / 多 GPU 或 KV unified cache 的场景下。优先排查方向是：先确认是否与 MTP 实现本身相关，再缩小到 FA（flash attention）输入构造和 tensor split 的影响。

适用环境：Issue 中已确认的环境为 Linux，使用 llama.cpp llama-server，Vulkan 后端；CPU 为 Ryzen 9700X；显卡组合为板载 iGPU + 两张 Intel Arc B580 12GB。报告版本为 b1175（commit 4de092659663c1f74c80f8e8f6ade33e87d50077）。模型为 unsloth/gemma-4-31B-it-qat-GGUF:UD-Q4_K_XL，搭配 MTP draft 模型 mtp-gemma-4-31B-it.gguf。

最快修复方案：Issue 作者最终确认的稳定触发条件是 MTP 开启：禁用 MTP（不要使用 --spec-type draft-mtp）后不再崩溃。因此可优先尝试关闭 MTP 推测解码。

注意事项：该 Issue 被标记为 bug-unconfirmed，并被视为 #29419 的重复。Issue 中没有给出官方代码修复或补丁；关闭 MTP 只属于规避手段，不代表根因已在源码层修复。另外，另一位使用 AMD RX 7900 XTX 的用户在类似参数下未能复现，说明该问题可能还与 Intel Arc / 特定 Vulkan 驱动路径有关，但这一点未最终确认。

问题场景

用户在 Linux 上运行 llama-server，加载 Gemma 4 31B QAT GGUF 模型，同时启用 MTP draft 模型进行推测解码，并使用 Vulkan 后端、tensor split 到两块 Intel Arc B580（-sm tensor -dev Vulkan1,Vulkan2）、KV unified cache（--kv-unified，-ctk bf16 -ctv bf16）。在多轮对话任务后，发生 slot 复用（LCP similarity）并跳过 prompt state cache，随后在生成约 156 个 token 时崩溃。

报错原文

~/.cache/paru/clone/llama.cpp-vulkan-git/src/llama.cpp/ggml/src/ggml-vulkan/ggml-vulkan.cpp:8025: GGML_ASSERT(neq0 == HSK) failed

[Vulkan] GGML_ASSERT(neq0 == HSK) failed in ggml-vulkan.cpp during speculative draft decoding (MTP) with tensor split

#8  ggml_backend_sched_graph_compute_async ()
#9  llama_context::graph_compute(ggml_cgraph*, bool)
#10 llama_context::process_ubatch(...)
#11 llama_context::decode(...)

原因分析

Issue 作者在后续观察中明确指出，跨后端测试（Vulkan 与 SYCL）后，共同点是 MTP 实现：开启 MTP 时稳定崩溃，关闭 MTP 后不再崩溃；量化格式（q8_0、f16、bf16）、上下文长度和后端类型都不影响是否复现。

从崩溃位置看，断言位于 ggml_vk_flash_attn() 入口附近，检查 Q 的 dim0 与 K 的 dim0 是否一致，二者本应是模型固定的 head size 属性。由于崩溃发生在运行中（slot 复用、跳过 prompt state cache 之后、生成中途），可能原因不是静态模型布局错误，而是某个图变体在 MTP 推测解码过程中向 flash attention 传入了非规范形状的 Q 或 K。另一位 AMD 用户在结构相同但 GPU 不同的环境下无法复现，因此该问题可能还依赖 Intel Arc（Xe2）特定的 Vulkan 管线路径，但 Issue 中未最终确认。

环境排查

确认 llama.cpp 版本与构建方式：Issue 使用 b1175 - 4de092659663c1f74c80f8e8f6ade33e87d50077，Vulkan 后端；另一复现测试使用 a02c7f58c，二者 ggml-vulkan 源码一致。
确认是否启用 MTP：即命令行是否包含 --spec-type draft-mtp，并加载了 MTP draft 模型。
确认 GPU 与 Vulkan 驱动：本 Issue 为 Intel Arc B580（Xe2）；对照测试为 AMD RX 7900 XTX + 7800X3D iGPU（RADV Mesa 26.2.3）。
确认是否使用 tensor split：-sm tensor -dev Vulkan1,Vulkan2。
确认 KV cache 与 attention 相关参数：--kv-unified、-ctk bf16 -ctv bf16、-fa 状态。
确认模型与 draft 模型文件：unsloth/gemma-4-31B-it-qat-GGUF:UD-Q4_K_XL 与 mtp-gemma-4-31B-it.gguf。

解决步骤

优先做 MTP 开关对照：在同样模型、同样量化、同样上下文设置下，分别运行一次包含 --spec-type draft-mtp 与不包含该参数的推理，确认崩溃是否只在开启 MTP 时出现。Issue 作者已验证：MTP 开启稳定崩溃，MTP 关闭不崩溃。
如果确认是 MTP 触发，可优先尝试临时移除或禁用 MTP 推测解码，作为规避方案继续使用服务。
若需要继续使用 MTP，可尝试 Issue 中建议的隔离步骤：临时设置 -fa off 并重跑触发序列，观察是否仍崩溃；若不崩溃，说明问题更可能位于 flash attention 输入构造环节。
可做单设备对照：仅使用 -dev Vulkan1 且 -sm none，确认崩溃是否依赖 tensor split。Issue 中仅作为建议提出，尚未确认结果。
如需进一步定位，可在 ggml-vulkan.cpp:8025 附近打印实际的 neq0 与 nek0 值，用于判断是模型布局错误还是图变体传入了错误形状。
如果问题与 Intel Arc / Xe2 特定路径相关，可关注 ggml-vulkan 中 GQA packing 与 Xe 双阶段 FA 管线相关代码是否后续更新；Issue 中提及 #26358，但未给出合并修复。

验证方法

在关闭 MTP 后，用相同的模型、相同的 KV 设置和相同的多轮对话 / slot 复用序列重复运行，确认不再出现 GGML_ASSERT(neq0 == HSK) failed，且生成任务可以正常完成。如果保留 MTP，则至少需要在原先崩溃的触发序列下稳定跑过崩溃点（例如超过 156 token）并完成多轮推理，才算验证规避成功。