Vulkan backend does not reload model into vram if kicked out by other uses. Massive slowdown.

该问题通常出现在使用 llama.cpp 的 Vulkan 后端、模型被其他进程挤占显存后从 VRAM 迁到 GTT 的场景;模型不会被自动搬回 VRAM,导致推理速度从约 10 tokens/s 跌到约 1 token/s。优先排查是否由 AMD amdgpu 驱动的显存迁移/运行时电源管理行为导

快速结论:该问题通常出现在使用 llama.cpp 的 Vulkan 后端、模型被其他进程挤占显存后从 VRAM 迁到 GTT 的场景;模型不会被自动搬回 VRAM,导致推理速度从约 10 tokens/s 跌到约 1 token/s。优先排查是否由 AMD amdgpu 驱动的显存迁移/运行时电源管理行为导致,而不是先从 llama.cpp 参数下手。

适用环境:llama.cpp Vulkan 后端;Debian 11、内核 5.10.0-27-amd64、amdgpu 开源驱动;AMD RX 580 8GB(Ellesmere);Ryzen 5 3600、32GB 内存。评论中另有 RX 570 8GB、双 GPU amdgpu 环境,以及 Windows 11 + Vulkan + 无显示器 RX 7900 XTX 的报告。

最快修复方案:暂无确认的一步修复方案。llama.cpp 维护者认为这是驱动侧行为,程序内只能分配设备内存;可优先尝试的是内核启动参数 amdgpu.runpm=0(评论中在第二块 GPU 场景下验证有效),以及给无显示器 GPU 接上显示器或假负载(评论中在 Windows 无头显卡场景下立即生效)。

注意事项:amdgpu.runpm=0 会关闭 amdgpu 运行时电源管理,可能增加空闲功耗,且并非在本文 RX 580 主场景中验证。问题单中提到的内核补丁(patchwork #129196)是面向内核 6.x 的 amdgpu 驱动改动,提交者本人也未能适配到 Debian 5.10 内核,属于未在 llama.cpp 内验证的推测方向。调高 moverate 等 amdgpu 启动参数在原作者处未解决问题。

问题场景

用户在 llama.cpp 中使用 Vulkan 后端运行 ./server 加载模型。切换后速度优于 clBLAST,但当另一个程序(例如运行 ./llava 加载多模态模型)占用大量 GPU 显存时,./server 的模型权重被 amdgpu 驱动从 VRAM 挤到 GTT。此后 llama.cpp 不会把权重重新加载回 VRAM,推理速度从约 10 tokens/s 降到约 1 token/s,直到杀掉并重启 ./server 才恢复。用 radeontop 可观察到 VRAM 占用不再超过约 1GB、GTT 持续偏高。

报错原文

Vulkan backend does not reload model into vram if kicked out by other uses. Massive slowdown.

原因分析

可能原因在 AMD amdgpu 驱动一侧,而非 llama.cpp 的 Vulkan 后端逻辑。维护者说明:Vulkan 后端只负责分配设备内存,内存被驱动迁移到系统内存(GTT)后,应由驱动在 VRAM 重新可用时搬回;这一回迁在当前驱动/内核下没有发生。评论中验证了相关触发条件:无显示器或处于运行时挂起的 GPU 更容易被驱动整块迁出显存,并且不会自动迁回。clBLAST 路径未出现同样问题,原作者推测是因为当时 clBLAST 走的是 amdgpu-pro 的 OpenCL 驱动,而 Vulkan 走开源 amdgpu Vulkan 接口,属于不同驱动路径——该解释为推测,未经确认。--mlock 只作用于系统内存,无法阻止显存被迁出。

环境排查

  • 确认 llama.cpp 构建版本与是否使用 Vulkan 后端(Issue 中对比了旧构建 1662 与新构建 2061)。
  • 确认 GPU 型号与显存容量,以及 radeontop 中 VRAM/GTT 占用变化是否呈此消彼长的关系。
  • 确认内核版本与 amdgpu 驱动来源(Issue 为 Debian 11、5.10.0-27-amd64、开源 amdgpu)。
  • 确认 GPU 是否处于无显示器、空闲挂起或运行时电源管理状态。
  • 确认是否有第二个进程会大量占用显存(如 llava 或其他推理程序)。
  • 确认是否安装过 amdgpu-pro / AMDVLK 等驱动,并注意版本兼容性(RX 580 已被 AMDVLK 放弃支持)。
  • 运行 vulkaninfo 收集后端信息(Issue 附有 vulkaninfo.txt)。

解决步骤

  1. 先用 radeontop 复现状态:记录正常推理时的 VRAM/GTT 占用,再启动占用显存的第二个进程,确认 VRAM 下降、GTT 上升且速度同步下降。
  2. 若 GPU 没有接显示器或被系统挂起,先尝试让它保持活跃:接上真实显示器或假负载转接头,再重新启动 ./server 验证显存是否保持满载。
  3. 可优先尝试在内核启动参数中加入 amdgpu.runpm=0,关闭 amdgpu 运行时电源管理,重启后重新测试。该方案来自双 GPU 场景的评论报告,主场景未经确认。
  4. 若在多 GPU 或桌面环境下需要保活,可在启动 llama.cpp 前对该 GPU 运行轻量图形负载(评论中示例为 glxgears),促使驱动先把分配放入 VRAM。
  5. 不要期待通过 llama.cpp 参数解决:--mlock 针对系统内存无效;调高 amdgpu moverate 在原作者处也未解决问题。
  6. 使用内核 6.x 的用户可关注 patchwork 补丁系列 129196 是否合入 amdgpu/TTM 驱动;该补丁针对 GTT 分配设置 busy 标志以促使 VRAM 被重新填充,但本文场景未验证。
  7. 临时绕过方式:确认另一进程退出、显存释放后,重启 ./server,驱动会重新把完整模型加载进 VRAM。

验证方法

在同样条件下再次运行推理,同时观察 radeontop:若 VRAM 占用保持在高位、GTT 占用接近空、速度恢复到约 10 tokens/s(而非约 1 token/s),说明问题已缓解。接显示器或使用 amdgpu.runpm=0 后,还需检查系统是否稳定、GPU 是否不再进入挂起状态。

参考来源

ggml-org/llama.cpp #5380

GamsGo AI

AI 工具推荐

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

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

了解 GamsGo AI

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

这个方案解决了吗?

celebrityanime
celebrityanime
文章: 29342

发表回复

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