Bug: Vulkan buffer allocation fails (~900MB-1GB) with a larger prompt, despite >14GB VRAM free

快速结论：当 AMD 显卡（如 RX 9060 XT）本应走 ROCm 却静默回退到 Vulkan 后端时，较长的 system prompt 会触发 Vulkan buffer 分配失败；优先检查环境变量 HIP_VISIBLE_DEVICES 是否被误设为 -1，而不是先去调 Vulkan 分配器。

适用环境：Ollama 0.33.2（干净重装后仍复现）；Windows 11 25H2 build 26200.9278；AMD Radeon RX 9060 XT 16GB（RDNA4 / gfx1200）；驱动 AMD Adrenalin 26.8.1（上一版本亦复现）。

最快修复方案：清除用户级环境变量 HIP_VISIBLE_DEVICES：在 PowerShell 执行 [Environment]::SetEnvironmentVariable("HIP_VISIBLE_DEVICES", $null, "User")，然后重启。重启后 Ollama 通过原生 ROCm 识别显卡（启动日志出现 library=ROCm compute=gfx1200），不再回退 Vulkan。

注意事项：该修复只是绕开了 Vulkan 回退路径，并没有修复 Vulkan 分配器本身的 bug（对没有完整 ROCm 支持的 RDNA4 卡而言，Vulkan 仍是官方回退方案，该 bug 仍值得单独修复）。变量来源未查明，可能是早期驱动排查遗留；同一机器的 ComfyUI 也在同一时间恢复识别 GPU，说明是环境级问题而非 Ollama 独有。

问题场景

用户在 Ollama 0.33.2 上加载 14GB 的 gemma4-apex（基于 Gemma）模型。通过命令行 ollama run gemma4-apex:latest 配合短 prompt 可以正常加载和推理；但改用 Python ollama 客户端调用 ollama.chat(...) 并传入较长的 system prompt（一段工具/函数描述块）时，抛出 Vulkan buffer 分配失败。同一模型、同一机器、同一 prompt 规模，仅调用方式和 prompt 长度不同，结果就不同。用户原文标题指出：

Bug: Vulkan buffer allocation fails (~900MB-1GB) with a larger prompt, despite >14GB VRAM free — same model/GPU/prompt size succeeds via ollama run but fails when called via API with a longer system prompt

作者数天后在帖首补充：找到的真正根因并非 Vulkan 分配器，而是环境变量在静默地把运行强制到 Vulkan。

报错原文

Bug: Vulkan buffer allocation fails (~900MB-1GB) with a larger prompt, despite >14GB VRAM free

hipGetDeviceCount failed: 100

切换到 ROCm 后另有一个不同签名的崩溃（仅在连续短调用同一已加载模型时出现）：

model runner has unexpectedly stopped

原因分析

已确认的根因是环境变量 HIP_VISIBLE_DEVICES=-1 被设置在用户环境级别。该值告诉 HIP runtime 暴露零块 GPU，于是 ROCm 完全看不到显卡（对应 hipGetDeviceCount failed: 100）。ROCm 不可见后，Ollama 回退到 Vulkan 后端，而该 buffer 分配失败正是 Vulkan 后端特有的失败模式。

因此：HIP_VISIBLE_DEVICES=-1 是“上游”阻塞点，Vulkan 分配失败只是其后果；变量来源未查明，可能是早前安装/驱动排查步骤遗留。作者也明确说明，此结论并未诊断 Vulkan 分配器本身的底层 bug，只是说明自己不再受其影响。

至于切换到 ROCm 后出现的 model runner has unexpectedly stopped，作者未能用原始 server 日志在该崩溃瞬间确认根因，因此仅作为“可缓解”而非“已诊断”，可能与 16GB 显存中约 15GB 已被模型本身占用、余量紧张有关。

环境排查

确认 Ollama 版本（案例为 0.33.2，且已完成干净重装：卸载、删除 %LOCALAPPDATA%\Ollama、重装）。
确认操作系统与版本（Windows 11 25H2，build 26200.9278）。
确认显卡型号与 VRAM（AMD Radeon RX 9060 XT 16GB，RDNA4 / gfx1200）。
确认驱动版本（AMD Adrenalin 26.8.1，上一版本亦复现）。
检查用户级 HIP_VISIBLE_DEVICES：PowerShell 执行 echo $env:HIP_VISIBLE_DEVICES。
查看 Ollama 启动日志中的后端选择，确认是否出现 library=ROCm compute=gfx1200，还是回退到了 Vulkan。
如需强制指定后端，可用 OLLAMA_LLM_LIBRARY=rocm_v7_1 测试观察 ROCm 是否能枚举到设备（本案例中该测试即返回 hipGetDeviceCount failed: 100）。
若遇到连续调用崩溃，可留意 VRAM 余量（案例中约 15GB/16GB 被模型占用）。

解决步骤

在 PowerShell 中确认 HIP_VISIBLE_DEVICES 当前值：echo $env:HIP_VISIBLE_DEVICES。若为 -1，即命中本案例的根因。
清除该用户级环境变量：[Environment]::SetEnvironmentVariable("HIP_VISIBLE_DEVICES", $null, "User")。
重启机器，使环境变量变更生效。
重启 Ollama，并查看服务器启动日志，确认已走原生 ROCm 而非 Vulkan：日志应出现 library=ROCm compute=gfx1200。
用原先会触发失败的长 system prompt 重新调用 ollama.chat(...)，观察是否还出现 Vulkan buffer 分配失败。
若切换到 ROCm 后在“连续多次短调用同一已加载模型”的场景出现 model runner has unexpectedly stopped，可优先尝试设置 OLLAMA_NUM_PARALLEL=1（作者在相同突发模式下反复测试可用，但未确认根因，属工作性缓解）。

验证方法

最直接的验证是：重启后 Ollama 启动日志显示 library=ROCm compute=gfx1200，不再有 Vulkan fallback；随后用同一模型、同一较长的 system prompt 通过 Python ollama.chat(...) 再次调用，原 Bug: Vulkan buffer allocation fails (~900MB-1GB) with a larger prompt, despite >14GB VRAM free 不再出现。若同时使用其他 ROCm 工具（如本案例中的 ComfyUI），可一并确认它们是否恢复原生识别 GPU，作为环境级修复的旁证。