Ollama 更新后降级到 CPU 运行：RTX 30 系列缺失 sm_86 CUDA 内核

Ollama 更新后降级到 CPU 运行：RTX 30 系列缺失 sm_86 CUDA 内核 | 前端进阶之旅

Full translation

完整中文译文

你更新了 Ollama，拉取了每天都在用的模型，然后一切都变慢了。不是坏了，不是报错，就是慢。ollama ps 显示的大概是 12% CPU / 88% GPU，于是你耸耸肩继续用。然后你在生成过程中打开 nvidia-smi，发现 Ollama 使用了 0 MiB 的 VRAM。

它全程都在 CPU 上运行。没人告诉过你。

这是很多 RTX 30 系列用户在 Ollama 0.32.14 之后遇到的情况，A40/A6000/A10 卡的用户也一样。

露馅的地方藏在服务器日志里。就在一堆噪音中间：

msg="skipping CUDA device - compute capability not in compiled architectures"
device="NVIDIA RTX A6000" cc=860 archs="[750 890 1000 1200]"

cc=860 意味着你的 GPU 计算能力是 8.6。arch 列表是绑定的 CUDA 内核编译时所针对的架构集合：7.5（RTX 20 系列）、8.9（RTX 40 系列）、10.0 和 12.0。没有 8.6。你的卡不在这个构建里。

受影响的硬件：所有 sm_86 卡。RTX 3090、3080、3070、3060，还有 A40、A6000、A5000、A10 及其同类。跑本地 LLM 的人有很大一部分用的正是这些卡。

缺失的 sm_86 内核并不是新问题。老版本同样跳过了这个架构。但它们有一个安全网：当 CUDA 13 内核没有覆盖这张卡时，它们会回退到绑定的 CUDA 12 库，而 CUDA 12 确实包含了 sm_86。同样的跳过行，然后：

msg="inference compute" ... library=CUDA compute=8.6

在 0.32.14 中，那个回退路径坏了。所以 runner 没有降级到 CUDA 12 库，而是直接跳到了 library=cpu。没有任何报错，所以你不会注意到，直到生成速度开始让人痛苦。

写这篇文章的时候上游还没有发布修复。问题已经开放，唯一一个维护者的回复是请求更多日志。可靠的做法：回退到最后一个 CUDA 12 回退正常工作的版本，这个版本是 0.32.13。

从 GitHub v0.32.13 发布页获取 OllamaSetup.exe。

安装，如果你是把 ollama 当服务跑的，重启 ollama 服务。

sudo systemctl stop ollama
# 从发布页安装 v0.32.13 的 .deb / .rpm / tarball
sudo systemctl start ollama

这是所有人都跳过的步骤，也是这篇文章存在的真正原因。ollama ps 可能会骗人。它显示了 GPU 分成，而 GPU 却闲置着。可靠的检查方式：

生成过程中运行 nvidia-smi。VRAM 分配给 ollama 进程且非零，意味着真正的 GPU 在用。

日志应该再次显示 library=CUDA compute=8.6，而不是 library=cpu。

观察 token 速度。27B 模型以 7 tok/s 爬行就是 CPU 的信号。

CUDA_VISIBLE_DEVICES=0。GPU 是可见的。它在架构检查时被跳过了，而那是编译时的事情。没有任何环境变量能让一个缺失的架构重新回来。

用 OLLAMA_LOAD_LIBRARY 强制使用 CUDA 12 库。有些构建会尊重这个设置，但在 0.32.14 中回退路径本身就是坏掉的部分，所以不要指望这个版本能用它。

在任何本地模型栈更新之后（Ollama、llama.cpp、LM Studio、诸如此类），花 30 秒证明加速在正常工作，然后再信任它。生成过程中运行一次 nvidia-smi 是最便宜的冒烟测试。

静默降级比报错更糟糕。报错会告诉你出了问题。静默的 CPU 回退只会让一切变卡，然后你开始怪罪模型。

而且预编译内核的覆盖范围是在构建时决定的。当一个版本发布时你的 GPU 架构被漏掉了，没有任何标志能修复它。回退到最后一个正常工作的版本，关注发布说明，等到覆盖范围恢复时再升级回来。