Misc. bug: generation started to crawl after update

该问题通常出现在升级到含 Vulkan 多设备相关改动的 llama.cpp 版本后(Issue 中指向 b11594 及之后的构建),在多块 Vulkan 设备(尤其双 RADV/AMD 显卡,或 NVIDIA + AMD 混合环境)上跑模型时生成速度骤降。优先排查是否处于多设备 Vulkan 环

快速结论:该问题通常出现在升级到含 Vulkan 多设备相关改动的 llama.cpp 版本后(Issue 中指向 b11594 及之后的构建),在多块 Vulkan 设备(尤其双 RADV/AMD 显卡,或 NVIDIA + AMD 混合环境)上跑模型时生成速度骤降。优先排查是否处于多设备 Vulkan 环境,并尝试只暴露一块设备。

适用环境:Issue 中已确认的环境为 Linux;涉及 llama.cpp Vulkan 构建(b11592 正常,b11594 起出现退化,b11624、b11610 仍有问题);显卡包括 RX 7600 XT + Renoir iGPU(双 RADV)、双 R9700、RTX 3090 + RX 7900 XT(RADV NAVI31)、2x FirePro D700(Tahiti,GCN 1.0);Mesa/RADV 26.2.4、Vulkan loader 1.4.363(仅 FirePro D700 的报告中给出)。Issue 未提供 Python、CUDA、PyTorch 版本信息。

最快修复方案:Issue 评论中验证有效的处理是设置环境变量 GGML_VK_VISIBLE_DEVICES=0,让 Vulkan 后端只使用一块设备;评论同时指出 GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 无效。

注意事项:该方案只是绕过多设备路径,代价是无法利用多 GPU 进行 layer split;若模型依赖多卡才能放下,需改用回退到 b11592 或回退相关提交。该修复仅在部分报告者环境验证通过,不同硬件与构建上的效果可能不一致。

问题场景

用户在 Linux 下使用 llama.cpp 的 Vulkan 后端(Issue 中为 llama-server,模型为 Qwen3.6-35B-A3B 的 GGUF,使用 -ncmoe、MTP draft 推测解码、--load-mode none 等参数)运行推理。升级到 llama-b11594-vulkan-x64 及之后版本后,生成速度从约 37 t/s 跌到 0.07 t/s,仅处理 prompt 就要约 40 秒;回退到 b11592 则正常。后续评论在双 R9700、NVIDIA + AMD 混合组合、以及 2x FirePro D700 上复现了同类退化。

报错原文

Misc. bug: generation started to crawl after update

原因分析

根据 Issue 评论中的定位,根因是非 b11596(该版本仅为测试代码),而是 b11594 引入的“允许多个设备访问 GPU 可见主机内存”改动。该改动在检测到多块 Vulkan 设备且均支持 VK_EXT_external_memory_host 时,把设备标记为 multi_device,并让 ggml_vk_host_malloc() 不再分配 Vulkan pinned memory,而改用普通的 aligned malloc。模型中有大量权重位于 Vulkan_Host 缓冲区,这些权重因此从真实 Vulkan 内存变成普通匿名内存,再按设备惰性导入;在 RADV 上导入页的 GPU 读取速度极慢(评论给出约 230 MB/s),导致加载张量时间从约 0.75 秒涨到约 41 秒,且每次图执行都出现约 41 秒的固定开销,与 batch 大小无关。

其他评论报告了相似现象:解码速度均匀下降、预填充反而略快、amdgpu GTT 占用升高并在生成过程中增长、minor faults 大幅增加,说明问题出在分配路径本身,而非张量放置。在 2x FirePro D700 上仅回退提交 e0bcaccbe(#29741)即可恢复旧速度,进一步印证该结论。

环境排查

  • 确认 llama.cpp 构建版本:b11592 正常,b11594 起出现退化;需核实当前所用构建是否包含该提交。
  • 确认 Vulkan 设备数量与型号:是否存在两块及以上 GPU(包括核显),以及每块设备是否都暴露 VK_EXT_external_memory_host。
  • 确认 AMD 驱动栈:Issue 中为 Linux + Mesa/RADV;不同 Mesa 版本表现可能不同。
  • 确认日志中 Vulkan_Host 模型缓冲区大小、load_tensors 耗时、每次图执行耗时是否出现固定的大额开销。
  • 确认是否使用了 --split-mode layer、-ot(把部分层放到 CPU)、--moe-cache-mib 等参数;评论显示多设备 + --split-mode layer 时退化明显,配合 --moe-cache-mib 会进一步恶化。
  • Issue 未提供 Python、CUDA、PyTorch 版本信息,无需按这些项排查。

解决步骤

  1. 先确认当前是否处于多 Vulkan 设备环境:在同一容器/主机上对比只启用一块设备时的生成速度。
  2. 可优先尝试设置 GGML_VK_VISIBLE_DEVICES=0,让 Vulkan 后端只使用编号为 0 的设备,然后重新启动 llama-server 并复测。这是 Issue 评论中验证有效的方案。
  3. 若模型必须依赖全部显存才能加载,可回退到 b11592 或回退 b11594 对应提交后再验证。
  4. 不要依赖 GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1:评论中该设置对退化无效。
  5. 如保留多设备结构,可测试去掉 --split-mode layer、将全部层放在单卡(如 --device Vulkan0 --split-mode none),以及移除以 CPU 放置层为主的 -ot 与 --moe-cache-mib 组合,观察生成速度是否恢复。

验证方法

在相同容器/主机、相同模型和参数下对比修改前后的生成速度(token/s)与 prompt 处理耗时;同时观察 llama.cpp 日志中 load_tensors 耗时是否从数十秒回落到秒级、每次图执行是否仍有固定的大额延迟。若设置 GGML_VK_VISIBLE_DEVICES=0 后生成速度回到接近 b11592 的水平,即可认为问题已被绕过。

参考来源

ggml-org/llama.cpp #30552

GamsGo AI

AI 工具推荐

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

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

了解 GamsGo AI

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

这个方案解决了吗?

celebrityanime
celebrityanime
文章: 29357

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注