AMD Radeon 780M Vulkan regression in Ollama >=0.32.10

问题场景

用户在以 systemd 服务方式运行的 Ollama 中开启 Vulkan 后端与 iGPU 支持（OLLAMA_VULKAN=1、OLLAMA_IGPU_ENABLE=1、GGML_VK_VISIBLE_DEVICES=0，并设置 OLLAMA_FLASH_ATTENTION=1、OLLAMA_CONTEXT_LENGTH=8192、OLLAMA_KV_CACHE_TYPE=q8_0），在 AMD Radeon 780M 核显上执行 ollama run qwen3-coder:30b。Ollama 0.32.9 可正常以 GPU 推理，升级到 0.32.10 及以上后，较大模型在 llama-server 启动阶段即失败。较小模型（如约 5.7 GB 的 qwen3:8b）仍能正常走 GPU。类似症状也在 RENOIR iGPU 上运行 gpt-oss-safeguard:120b（约 66 GB）时复现。

报错原文

radv/amdgpu: Not enough memory for command submission
vk::Queue::submit: ErrorDeviceLost

Error: 500 Internal Server Error: llama-server process has terminated: exit status 1: radv/amdgpu: Not enough memory for command submission.
error loading model: vk::Queue::submit: ErrorDeviceLost

原因分析

根据评论区的隔离测试，回归来自 Ollama 随附的 llama.cpp 构建，而非 Ollama 自身的 Go 代码或启动器：在 v0.34.4 / v0.35.0 上仅替换 /usr/local/lib/ollama 中的 runner 库为 0.32.9 版本即可恢复正常，换回新库则再次崩溃。

该 vendor 升级跨过了 llama.cpp b10380，引入 ggml-org/llama.cpp#26081（--load-mode auto，现为默认值）。在 iGPU 上该模式会跳过 mmap，要求一次性通过 RADV 预分配整个模型与 KV cache。核显使用共享内存，可分配额度受 GTT 等上限约束；大模型所需分配无法满足，队列提交随即以 ErrorDeviceLost 终止整个 Vulkan 设备。这也解释了“小模型正常、大模型失败”以及 0.32.9 正常的分界。

可能原因层面，用户也可先判断是否为 GTT 上限过小（有用户指出默认 iGPU 只能使用约一半系统内存）。上游 ggml-org/llama.cpp#27360、#29455 在讨论时仍处于打开状态，尚未合并修复。

环境排查

• 确认 Ollama 版本：0.32.9 为可工作的基准，0.32.10 及之后均可能受影响。
• 确认服务环境变量：OLLAMA_VULKAN、OLLAMA_IGPU_ENABLE、GGML_VK_VISIBLE_DEVICES 是否符合预期（排查时可用 OLLAMA_VULKAN=0 / OLLAMA_IGPU_ENABLE=0 对照测试）。
• 确认模型规模：失败的均为较大的模型，失败发生在 llama-server 启动加载阶段。
• 确认显卡与驱动：核显型号、RADV 驱动、系统内存实际容量，以及 iGPU 可用的 GTT / 共享内存上限（可参考内核 amdgpu/ttm 参数与系统内存总量）。
• 确认所用 runner 库来源：是否被手动替换过（/usr/local/lib/ollama），混装库可能导致行为与官方版本不一致。

解决步骤

1. 先做对照确认。保持硬件、模型与配置不变，将 Ollama 降级到 0.32.9 后再次运行同一模型。若恢复 GPU 推理，即确认是该回归。
2. 方案 A：降级 Ollama。将 Ollama 回退至 0.32.9，并固定版本，避免被自动升级覆盖。
3. 方案 B：仅替换 runner 库（可优先尝试）。保留当前新版 Ollama 二进制与启动器，仅把 /usr/local/lib/ollama 下的 runner 库替换为 0.32.9 随附版本。评论中报告该做法恢复了 59/41 的 CPU/GPU 切分。替换前建议备份原库，注意 Ollama 升级后可能覆盖。
4. 方案 C：提高 GTT 上限（可优先尝试）。新建 /etc/modprobe.d/amdgpu-gtt.conf，按本机内存设置大小（评论中 64 GB 机器使用 48 GiB 的示例）：

   # GPU-mappable memory limit in 4 KiB pages: 48 GiB = 48 * 262144
   options ttm pages_limit=12582912
   # GTT size in MiB, needed on some kernels
   options amdgpu gttsize=49152

   然后执行 sudo update-initramfs -u 并重启。数值需按实际内存自行换算，不要直接照搬。

5. 方案 D：按模型回退 CPU（保留小模型 GPU 加速）。为无法加载的模型新建 Modelfile，仅设置该模型的 GPU 层数：

   FROM qwen3.8:latest
   PARAMETER num_gpu 0

   然后执行 ollama create qwen3.8-tuned -f qwen3.8-tuned.Modelfile，再运行 ollama run qwen3.8-tuned。有多名用户确认此方案有效；视硬件与 num_ctx 情况，num_gpu 也可尝试非 0 值。注意这会让该模型完全不走 GPU。

6. 临时全局回退：设置 OLLAMA_VULKAN=0 与 OLLAMA_IGPU_ENABLE=0，模型可在 CPU 上加载运行。这能证明模型本身可用，但会牺牲所有模型的 GPU 加速。

验证方法

采用任一方案后重启 Ollama 服务，再次以原配置运行同一大模型（如 ollama run qwen3-coder:30b）。若 llama-server 能正常启动并开始生成，不再出现 radv/amdgpu: Not enough memory for command submission 与 vk::Queue::submit: ErrorDeviceLost，即说明规避生效。若使用了 runner 库替换或 GTT 调整，可观察日志中是否恢复 CPU/GPU 混合切分（评论示例为 59/41），以确认 GPU 仍在参与推理；同时用一个较小模型确认其 GPU 路径未被破坏。

参考来源

ollama/ollama #17748

AI 工具推荐

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

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

了解 GamsGo AI

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