Eval bug: Step 3.7 fails to run on versions b10509+

快速结论：Eval bug: Step 3.7 fails to run on versions b10509+ 这个报错发生在 llama.cpp 更新到 b10509 或更高版本后，使用 AMD Strix Halo 集成显卡（Vulkan 后端）加载 Step-3.7-Flash 模型时，进程卡死在 llama threadpool init 阶段。最优先排查是否等待时间过短，以及在当前版本的 Vulkan 驱动上运行 test-backend-ops -o ROPE 验证后端兼容性。

适用环境：Linux x86_64 操作系统；llama.cpp 构建版本 b10507（正常）与 b10509（异常）；GGML Vulkan 后端；AMD Strix Halo 硬件；Step-3.7-Flash-Q4_K_M（bartowski 量化版，GGUF 分片格式）。

最快修复方案：暂无确认的一步修复方案。根据 Issue 讨论，维护者与多位用户在其他硬件（如 RTX 显卡、CUDA 后端）上复现相同或相近的启动参数均能正常加载，目前问题仅在与 Strix Halo 相关的 Vulkan 路径上复现，尚未明确验证 b10509 变更中的具体触发点。

注意事项：所有复现测试均使用相同或高度接近的启动参数，包括 --spec-type ngram-mod,draft-mtp、--kv-unified、--load-mode dio，且模型均来自相同的 Step-3.7 系列量化版本，不能排除 MTP 草稿模型在特定 GPU 上的兼容性问题；日志中的 read_raw_unsafe: Falling back to buffered IO due to Bad address 并非核心原因，属于 --load-mode dio 的后备 IO 机制提示。

问题场景

用户在 Linux 系统上使用 llama.cpp 的 llama-server 加载 Step-3.7-Flash 模型的 Q4_K_M 量化版（GGUF 分片格式），并通过带 MTP 与 ngram 的推测解码参数启动服务。模型文件可以正常加载，但加载日志停留在 init: llama threadpool init, n_threads = 16，服务无法进入监听状态。用户在构建版本 b10507 上运行正常，更新到 b10509 后复现该问题。

报错原文

Eval bug: Step 3.7 fails to run on versions b10509+
init: llama threadpool init, n_threads = 16
（进程在此处卡住，不再输出后续加载日志）

原因分析

可能原因一（高概率）：b10509 版本中引入的代码变更影响了 Vulkan 后端在 AMD Strix Halo 上的线程池或推理初始化路径。由于维护者在 RTX 显卡的 Vulkan 后端上未复现，且 CUDA 后端也正常，可以认为是特定硬件/驱动组合与新版后端的兼容性问题。

可能原因二：MTP（Multi-Token Prediction）推测解码相关代码在 b10509 中针对特定 GPU 架构出现异常。加载日志卡死的位置在 threadpool 初始化之前，但这并不完全排除 MTP 上下文创建阶段的影响，尤其是多个测试环境在移除 MTP 参数后可以正常加载。

可能原因三：用户过早按下 Ctrl+C，加载过程可能仍在继续。维护者在回复中询问“Did you CTRL + C after only 30 seconds?”，指出大型 GGUF 分片文件的加载时间可能超过 30 秒，但日志显示卡死超过 12 秒仍未完成，且在其他硬件上同参数能完成加载，因此该因素可能只是次要诱因。

环境排查

GPU 型号与驱动：确认是否为 AMD Strix Halo（Radeon 800M 系列集显），并检查 Vulkan 驱动版本是否最新。
llama.cpp 构建版本：确认本地版本是否为 b10509 或更高，可在 llama-cli --version 中查看 commit 号。
Python/CUDA：本 Issue 未涉及 Python 调用或 CUDA 后端，勿需排查；但如果切换 CUDA 后端可对比是否与 Vulkan 后端相关。
模型文件完整性：确认所有 GGUF 分片文件（共 4 个）完整且哈希一致，避免因文件损坏导致的加载挂起。
启动参数：重点核对 --spec-type ngram-mod,draft-mtp、--n-cpu-moe、--load-mode dio 等参数的组合影响。

解决步骤

延长等待时间验证：在 b10509 上重新启动服务，等待至少 60 秒再观察日志，确认是否仅是加载时间较长，而非真正卡死。
运行后端算子测试：按照维护者建议执行 test-backend-ops -o ROPE，确认 Vulkan 后端的 RoPE 算子是否正常；若失败，则说明问题与后端算子实现有关。
交叉验证其他后端：在不修改其他参数的前提下，将 --n-gpu-layers 改为 CPU 运行（或使用 CUDA 后端），确认是否能通过 threadpool 初始化阶段，以判断是否为 Vulkan 后端专有问题。
切换推测解码参数：移除 --spec-type ngram-mod,draft-mtp 相关参数，仅用 --spec-type ngram-mod 或关闭推测解码（去掉 --spec-type 与相关 MTP 参数）后重启，判断是否由 MTP 草稿模型引用引发。
回滚至正常版本：如果不能快速定位，回退到 b10507（或更早的最后一个正常工作版本），等待后续修复版本发布，这是目前最稳妥且已在本地验证可行的方案。
升级 GPU 驱动：检查是否有针对 Strix Halo 的 Vulkan 驱动更新（如 Mesa RADV 或 AMD 官方驱动），升级后重新测试；此步骤为可优先尝试的补救措施，但 Issue 中尚无验证证据。

验证方法

重新运行 llama-server，并观察日志是否越过 llama threadpool init 阶段，后续出现 model loaded 与 listening on http://... 等提示，即代表问题解决。若使用 test-backend-ops -o ROPE，该命令应返回 OK（或全部测试项通过）而不报错。