Ollama 故障排查
Ollama 出问题时的通病是「没有明显报错」——模型能跑但慢、卡识别不到但不报错。所以排查的第一原则是：先看日志，再看现象。这一篇按「日志在哪 → 通用手段 → 分后端定位」的顺序组织。
版本基线 v0.40.12，官方
docs.ollama.com/troubleshooting。
一、第一步永远是拿日志
| 运行方式 | 日志命令 |
|---|---|
| macOS | cat ~/.ollama/logs/server.log |
| Linux（systemd） | journalctl -u ollama --no-pager --follow --pager-end |
| 容器 | docker logs <容器名>（docker ps 查名字） |
手动 ollama serve |
直接看该终端输出 |
| Windows | explorer %LOCALAPPDATA%\Ollama，看 server.log |
Windows 上有几个常去的目录，记住这四个路径能省很多时间：
explorer %LOCALAPPDATA%\Ollama # 日志：server.log、server-1.log
explorer %LOCALAPPDATA%\Programs\Ollama # 可执行文件
explorer %HOMEPATH%\.ollama # 模型与配置
explorer %TEMP% # 临时可执行文件 ollama* 目录二、打开调试日志
常规日志信息量不够时，加 OLLAMA_DEBUG=1：
macOS / Linux：
OLLAMA_DEBUG=1 ollama serveWindows（必须先退出托盘里的应用，再在 PowerShell 里启动）：
$env:OLLAMA_DEBUG="1"
& "ollama app.exe"调试日志会额外输出 GPU 发现过程、LLM 库选择、显存评估等关键信息。报 issue 时一定要附上这段日志。
三、通用手段：强制指定 LLM 库
Ollama 内置了多个为不同 GPU 和 CPU 指令集编译的推理库，启动时自动挑最合适的一个。自动选择出错时（典型表现是 GPU 上崩溃、或启动了但退回 CPU），可以手动指定。
日志里能看到当前可用的库：
Dynamic LLM libraries [rocm_v6 cpu cpu_avx cpu_avx2 cuda_v11 rocm_v5]手动指定：
OLLAMA_LLM_LIBRARY="cpu_avx2" ollama serve
性能排序是 cpu_avx2 > cpu_avx > cpu。cpu 最慢但兼容性最好，macOS 上跑 Rosetta 模拟时必须用它。
查本机 CPU 支持哪些指令集：
cat /proc/cpuinfo | grep flags | head -1四、按症状定位
症状 1：装完就是跑在 CPU 上
先确认现象：
ollama ps
PROCESSOR 列显示 100% CPU 就走下面的分支。
NVIDIA，按顺序排查：
## ① 容器场景先验证 runtime 是否正常
docker run --gpus all ubuntu nvidia-smi
## ② uvm 驱动加载了吗
sudo nvidia-modprobe -u
## ③ 重载 uvm 驱动（最常见有效）
sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm
## ④ 重启机器都不行就看内核日志：
sudo dmesg | grep -i nvrm
sudo dmesg | grep -i nvidia需要更详细的诊断日志时：
CUDA_ERROR_LEVEL=50 ollama serve日志里可能出现的错误码含义：
| 错误码 | 含义 |
|---|---|
| 3 | 未初始化 |
| 46 | 设备不可用 |
| 100 | 找不到设备 |
| 999 | 未知错误 |
AMD，最常见的是权限问题：
## 检查设备节点的组 ID
ls -lnd /dev/kfd /dev/dri /dev/dri/*
输出形如 crw-rw---- 1 0 44 226, 0 ... /dev/dri/card0，其中 44 就是组 ID。
- 宿主机：确认用户在
video和/或render组里 - 容器：必须额外传
--group-add 44（用实际组 ID）
## 打开 AMD 库详细日志
AMD_LOG_LEVEL=3 ollama serve
## 查驱动层错误
sudo dmesg | grep -i amdgpu
sudo dmesg | grep -i kfd症状 2：AMD 卡在 Linux 上完全发现不了，日志超时
日志里出现这两行，基本可以定性为驱动版本太旧：
msg="failure during GPU discovery" ... error="failed to finish discovery before timeout"
msg="bootstrap discovery took" duration=30s ...原因：Ollama 内置的是 ROCm 7 库，需要匹配的 ROCm 7 内核驱动。系统还停在 ROCm 6.x 或更早时，设备发现会挂住直到超时，然后退回 CPU。
解决办法是升级到 ROCm v7 驱动，然后重启再启动 Ollama：
## 用 amdgpu-install 安装/升级，具体命令见 AMD ROCm 文档
sudo amdgpu-install --usecase=rocm
sudo reboot症状 3：容器里的 GPU 一开始能用，过一会儿退回 CPU
这是 Docker 的 cgroup 管理冲突。编辑宿主机的 /etc/docker/daemon.json：
{
"exec-opts": ["native.cgroupdriver=cgroupfs"]
}改完重启 Docker。现象特征是日志里反复出现 GPU 发现失败。
症状 4：临时目录挂了 noexec
部分加固过的系统把 /tmp 设成 noexec，而 Ollama 会往临时目录写可执行文件，直接启动失败。换个可写目录：
OLLAMA_TMPDIR=/usr/share/ollama/ ollama serve症状 5：Windows 终端满屏乱码
老版本 Windows 10（如 21H1）的终端有控制字符渲染 bug，输出大量 ←[?25h←[?25l，有时伴随报错 The parameter is incorrect。
升级到 Win10 22H1 或更新版本即可，这是系统层面的问题，改 Ollama 配置没用。
症状 6：多 AMD 卡时输出乱码
Linux 上模型跨多块 AMD 卡拆分加载时，可能出现输出变成无意义字符。这是 ROCm 侧的已知限制，官方指向 AMD 的 multi-GPU 已知问题文档。实用做法是先用 ROCR_VISIBLE_DEVICES 限制到单卡，确认单卡正常后再试多卡。
症状 7：想降级或试用预发布版
Linux 上安装脚本支持指定版本：
curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.5.7 sh新版本引入回归时，这是最快回到可用状态的办法。
五、性能类问题的判断基准
「慢」是最难定性的问题，先量化再动手：
## ① 到底跑在哪
ollama ps
## ② 模型多大、占多少显存
ollama list判断基准：
- 100% GPU + 速度仍慢 → 模型本身就大，或上下文设太高（
num_ctx直接决定 KV 缓存大小） - 100% CPU → 后端没生效，回到「症状 1」
- CPU/GPU 混合（如
48%/52%）→ 模型超出显存，被拆开跑，速度会掉一半以上。换更小的量化版本比调参有效 - 首次请求慢、后续正常 → 正常的模型加载开销，可用预热请求规避
上下文与显存的关系见 6.1 Ollama 上下文长度，后端门槛见 10.1 Ollama 硬件支持。
六、报 issue 前的自检清单
官方维护者最需要的是这几项，缺一项排查就要多一轮往返：
ollama --version的完整版本号- 操作系统与内核版本（
uname -a） - GPU 型号与驱动版本（
nvidia-smi或rocminfo） OLLAMA_DEBUG=1下的完整启动日志- 复现步骤：用了什么命令、什么模型、预期与实际结果
动手试
下次再遇到「好像没用上 GPU」，用下面这一组命令做三分钟体检：
echo "=== 版本 ==="; ollama --version
echo "=== 当前加载 ==="; ollama ps
echo "=== 驱动 ==="; nvidia-smi 2>/dev/null || rocminfo 2>/dev/null | head -20 || echo "无独显驱动"
echo "=== 日志尾部 ==="; tail -50 ~/.ollama/logs/server.log 2>/dev/null || journalctl -u ollama -n 50 --no-pager四段输出贴出来，基本就能定位问题在哪一层。