排查 Ollama 在 AMD 显卡上的静默回退
作者基于 RX 7900 XTX 在 Windows、Linux 与 WSL2 下的测试，总结五类使 Ollama 静默回退 CPU 的故障。其环境中吞吐量从 132.48 降至 15.89 tokens/s，文章强调核对启动时的 GPU 探测与后端信息。
原文暂未完整获取，基于公开信息的快读
Ollama 能启动、能回答，推理也可能一直跑在 CPU 上。dev.to 作者用 RX 7900 XTX 在 Windows、原生 Linux 和 WSL2 下测试，记录了这种静默回退：其环境中的吞吐量从 132.48 降到 15.89 tokens/s。排障的起点，是确认服务实际选了哪个后端、模型实际加载到哪里。
目前能确认什么
作者测试持续三周，使用 24 GB RX 7900 XTX 和 Ryzen 9 7950X3D。上述速度只属于这套测试环境，不能直接套到其他机器上。
节选给出两个检查入口：
- 启动日志：查看
library=。作者展示了cpu、ROCm、Vulkan等结果；如果是cpu，就没有使用 GPU 后端。 ollama ps：查看PROCESSOR列，确认是否为100% GPU。服务能响应，并不能证明模型完全在 GPU 上运行。
GPU 与 CPU 分担模型计算，不一定会触发报错。作者还提醒，Vulkan 后端可能正常报告 compute=0.0，不能照搬 ROCm 的字段预期来判断故障。
标题提到五类故障，但现有节选只涉及前三类，第三类也未完整展开。其中，核显被错误选中的案例发生在 llama.cpp 二进制程序中；作者明确说，同机 Ollama 会自行屏蔽核显，不能把两者混为一谈。
我的判断
本地推理服务的健康检查，应包含实际后端和模型加载位置。
作者在重装驱动后遇到 CPU 回退，重启 Ollama 才恢复 GPU。因此，改动驱动、BIOS 或 Ollama 后，重新检查这两项，比凭聊天速度判断更可靠。
WSL2 部分需要保留边界。作者将失败归因于 GPU 枚举路径，并报告他人的修复方法在其环境中未能复现；这些材料不足以证明所有版本都无法使用 GPU。适用版本、完整排查过程，以及剩余两类故障，都还要等完整原文或官方文档确认。