【AI】Ollama 更新后 skipping CUDA 掉回 CPU

1. 【背景】升级后不是不能跑，是悄悄变慢

我这次看到的是 Ollama GitHub issue 里的一组对照日志，不是我在自己 3060 上复现出来的结果。

麻烦的地方在于，Ollama 升到 0.32.14 以后，三十系 / sm_86 显卡不是直接报"CUDA 不可用"，而是日志里跳过 CUDA 设备，最后静默掉回 CPU。

这篇文章只处理这一件事：看到 skipping CUDA device - compute capability not in compiled architectures 时，先判断是不是 0.32.14 的后端库选择问题，不要一上来重装驱动或 CUDA Toolkit。

来源 issue 是这里：

text 复制代码

https://github.com/ollama/ollama/issues/17841

issue 里的现象很典型：服务还能启动，模型还能回答，表面上不像坏了。但推理速度会明显变慢，日志里会显示 Ollama 最后用了 CPU 后端。对本地大模型来说，这种问题比直接报错更容易浪费时间，因为你可能会先去改模型、改量化、改上下文，结果真正的问题在 runner 选库。

我这里不假装已经拿自己的 3060 跑了一遍。下面的事实以 issue 里的对照日志为准，尤其是版本、compute capability、编译架构列表和最终 library 的变化。

2. 先看这几行日志

关键报错原文是这一句：

text 复制代码

skipping CUDA device - compute capability not in compiled architectures

伴随信息里有这一组：

text 复制代码

cc=860 archs="[750 890 1000 1200]"

这里的 cc=860 对应 compute capability 8.6，也就是 sm_86。RTX 30 系消费卡，以及一些 Ampere 专业卡，都会落在这一档。后面的 archs="[750 890 1000 1200]" 是当前 CUDA 后端编译进来的架构列表。问题就在这里：列表里没有 860。

0.32.14 后，issue 里看到的结果是：

text 复制代码

library=cpu

而 0.32.13 / 0.30.10 的对照日志里，会回退到 cuda_v12，并且能看到：

text 复制代码

library=CUDA compute=8.6

这组对照比单独看"有没有 GPU 占用"更可靠。它说明同一类硬件上，0.32.14 的 CUDA 后端没有覆盖 sm_86，并且没有像旧版本那样顺利回退到能跑 sm_86 的 CUDA 后端。

3. 不要先重装驱动和 CUDA Toolkit

很多本地大模型问题看起来都像 CUDA 坏了，但这一条不能先往驱动上修。

日志里已经能看到设备的 compute capability，说明问题不是系统完全看不见显卡。真正卡住的是 Ollama 当前加载的预编译后端库里，没有把 860 放进 compiled architectures。

驱动再装一遍，也不会把一个没编进发行包的架构补进去。CUDA Toolkit 也是同理。Ollama 用的是它自己发行包里的运行库和后端选择逻辑，不是你在机器上装一套 Toolkit，就能让 0.32.14 的预编译库突然支持 sm_86。

所以我会先按三步判断：

text 复制代码

ollama -v

确认是不是 0.32.14。然后去日志里找：

text 复制代码

skipping CUDA device - compute capability not in compiled architectures

再继续找：

text 复制代码

cc=860 archs="[750 890 1000 1200]"
library=cpu

如果这几行对上，就先别动驱动。这个问题更像 Ollama 版本和后端回退路径的问题。

4. Windows 和 Linux 怎么查日志

Windows 上，Ollama 日志通常在这个目录：

bat 复制代码

explorer %LOCALAPPDATA%\Ollama

可以直接搜关键字符串：

bat 复制代码

findstr /C:"skipping CUDA device" %LOCALAPPDATA%\Ollama\server.log
findstr /C:"library=" %LOCALAPPDATA%\Ollama\server.log

如果日志轮转了，也要看同目录下的 server-#.log。有时候你现在打开的日志不是出问题那一次启动的日志，最好按时间顺序看最近几份。

Linux 如果是 systemd 服务，可以这样搜：

bash 复制代码

journalctl -u ollama --no-pager | grep -E 'skipping CUDA device|library='

如果你是手动跑 ollama serve，就看当前终端输出。关键不是日志文件在哪里，而是要确认最终落到哪个后端。看到 library=CUDA compute=8.6 和看到 library=cpu，结论完全不同。

5. 为什么 0.32.13 还能跑，0.32.14 会掉 CPU

issue 里的对照很重要。0.32.13 / 0.30.10 也会对 cuda_v13 打出类似 skip，因为那套 archs 里同样没有 860。区别在于旧版本后面还能回退到 cuda_v12，于是最终仍然可以用 CUDA 跑 sm_86。

可以把这件事简单看成下面这样：

Ollama 版本	看到的现象	最终后端
0.30.10 / 0.32.13	cuda_v13 跳过 sm_86，但能回退	`library=CUDA compute=8.6`
0.32.14	cuda_v13 跳过 sm_86，回退没有接上	`library=cpu`

所以修法不是"让 cuda_v13 立刻支持 860"。发行包没有编进去的架构，运行时变不出来。更现实的处理是先回到仍能回退 cuda_v12 的版本。

这里也解释了为什么同事的 40 系显卡可能没事。40 系是 sm_89，对应 archs 里的 890。你的 3060、3070、3080、3090 走的是 sm_86，不能拿 4090 的正常结果来判断三十系没问题。

6. 为什么不要只信 ollama ps

这个 issue 里还有一个容易误导人的点：不要只看 ollama ps 里的 GPU 百分比。

它可以当参考，但不能当最终证据。因为这类问题真正要确认的是 runner 最终加载了什么 library，而不是界面上显示一个看起来像 GPU 切分的比例。

如果日志已经显示：

text 复制代码

library=cpu

那就按 CPU 后端处理。即使别的监控里偶尔看到一点 GPU 活动，也不能证明模型推理真的在 CUDA 上跑。Windows 桌面、浏览器、其它程序、驱动后台，都可能让 GPU 指标动一下。

更可靠的确认方式是两条一起看：日志里的 library=CUDA compute=8.6，以及推理时 nvidia-smi 里 Ollama 进程显存不再是 0。只看其中一条，都容易误判。

7. 修法是钉回 0.32.13

目前更稳的处理方式是把 Ollama 钉回 0.32.13。

不要低于 0.32.12，因为新的 Qwen GGUF 会要求 0.32.12。也就是说，这里不是越旧越好，而是在"避开 0.32.14 掉 CPU"和"保持新模型格式可用"之间选一个能工作的版本点。

Windows 上可以这样处理：

先关掉 Ollama 的自动更新，避免刚装回 0.32.13 又被拉回 0.32.14。
卸载当前 Ollama。一般模型目录不会被安装器直接删掉，但动手前最好自己确认一下。
下载 v0.32.13 的安装包，不要点官网默认最新下载：https://github.com/ollama/ollama/releases/download/v0.32.13/OllamaSetup.exe
安装后执行：

bat 复制代码

ollama -v

确认版本确实回到了 0.32.13。

Linux 上，如果使用官方安装脚本，可以钉版本：

bash 复制代码

sudo systemctl stop ollama
curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.13 sh
sudo systemctl start ollama
ollama -v

以后再升级时也不要裸跑安装脚本。裸跑通常会装最新版本，如果最新版本正好有这种架构覆盖问题，就会把刚修好的环境又带回去。

如果你使用 Open WebUI 或其它前端，只是连接本机 Ollama API，那么通常不用先动前端。这个问题卡在 Ollama 后端 runner 选库，不是聊天界面本身导致的。

8. 回退后怎么确认修好了

回退 0.32.13 后，不要只看模型能不能回答。模型能回答只能说明服务还活着，不能说明 GPU 已经回来。

我会先重新启动 Ollama，然后看日志里有没有恢复到：

text 复制代码

library=CUDA compute=8.6

如果前面仍然看到 cuda_v13 的 skip 行，不一定代表失败。关键是后面有没有继续落到 CUDA，而不是最后变成 CPU。

推理时再开一个窗口看显存：

bash 复制代码

nvidia-smi -l 2

然后跑一条你平时会用的模型：

bash 复制代码

ollama run qwen3.8:27b "用一句话说明什么是 CUDA compute capability"

没有这条模型就换成自己的模型。重点是生成过程中看显存和日志，不是空闲时看。修好后，至少应该同时满足三件事：Ollama 版本是 0.32.13；日志里有 library=CUDA compute=8.6；推理时 Ollama 进程显存不再一直是 0。

如果仍然是 library=cpu，先确认当前运行的 Ollama 服务到底是不是刚装的那个版本。有些机器上可能残留多个安装位置，或者服务进程没有重启干净。不要只看安装器跑完了，就以为服务已经切到新版本。

9. 什么时候才考虑别的路

如果你必须留在 0.32.14，那就不是这篇文章的默认修法。比较现实的路只有两条：等上游修复预编译架构覆盖或回退路径，或者自己从源码编译并显式带上 sm_86。

自编不是排查入口。它需要 CUDA 编译环境、构建时间和自己的回归验证。对只是想把本地大模型先跑回 GPU 的人来说，先钉 0.32.13 更直接。

也不要把 OLLAMA_LLM_LIBRARY 这类变量当成稳定修法。部分旧构建可能认实验开关，但这次问题的重点是 0.32.14 的回退路径和发行包覆盖范围。排查时先用版本对照把 GPU 抢回来，再决定要不要继续折腾自编。

可以带走的判断

这次问题不要先按"驱动坏了"处理。

如果 Ollama 0.32.14 日志里同时出现：

text 复制代码

skipping CUDA device - compute capability not in compiled architectures
cc=860 archs="[750 890 1000 1200]"
library=cpu

而 0.32.13 / 0.30.10 能回到：

text 复制代码

library=CUDA compute=8.6

那就先把 Ollama 钉回 0.32.13，并且不要低于 0.32.12。发行包没有编进去的架构，运行时变不出来；先看 archs= 和 library=，再决定要不要动系统环境。