ollama windows 使用 gpu 配置

很多人装完 Ollama，Windows 任务管理器里显卡使用率一直是零，模型跑得比 CPU 还慢，于是到处翻参数。这篇不堆命令，按「先看有没有、再看用没用、最后调得动」三步给你排查顺序，还说明什么情况下确实用不了独显，别白折腾。

装完 Ollama，跑个模型风扇嗡嗡响，任务管理器里独显占用还是零，模型速度跟纯 CPU 似的——这是 Windows 上最常遇到的场景。很多人第一反应是翻一堆环境变量和启动参数，其实这个顺序反了。

正确做法是三步走：先看它有没有认出显卡，再看跑的时候有没有真占用，最后才去动配置项。这篇按这个顺序讲，每步都给判断标准和动作，顺便说清楚什么情况下独显确实用不了，省得你白折腾一晚上。

第一步：确认 Ollama 到底认没认出显卡

判断识别，优先看启动输出和日志，别只盯任务管理器。任务管理器是系统层面的整体占用，Ollama 有没有把这块卡当成可用设备，它不一定会反映出来。识别结果跟驱动版本、显卡代际、是否有对应后端直接相关，先把这个前提确认了再往下走。

• 看启动时的输出和日志里提到的设备名称，是否出现你的独显型号；如果只有 CPU 字样或者干脆没有设备信息，说明没走到显卡那条路。
• Windows 机器上集显和独显常常同时存在，系统默认渲染用哪块、Ollama 加载用哪块，可能不是同一块；这两个概念不是一回事，到 /ai-dict/category/hardware 把名词对齐再判断。
• 识别失败先按顺序排：驱动是不是太久没更新、卡是不是太老缺对应后端、是不是跑在虚拟机或远程桌面里被透传掩盖了真实设备。一次只查一项，别同时改一堆。

第二步：判断它是真在用显卡，还是只挂了个名

认出设备不等于跑起来真占用。三处信号经常对不上：任务管理器、显卡厂商自带的监控工具、Ollama 自己的输出。口径不一致时，以「加载和运行过程中显存有没有变化」为准，任务管理器的整体百分比参考价值最低。

另一个坑是拿小模型试。小模型本来纯 CPU 也能跑得挺快，看不出卸载到显存的差别。要挑一个明显超出纯 CPU 能力的任务来观察，比如上下文拉长、或者模型本身偏大，这时候速度差异才会暴露出来。

想看客观数字再谈调优，别凭感觉。先到 /tools/speed-test 量一遍延迟和生成速度基线，后面每改一步都重测同一个模型同一个提示词，不然你分不清是哪一步起的作用。

第三步：能动手调的就这几处，以及调不动的边界

真到调参数这一步，值得动的其实只有三类：让它用对设备、控制有多少层扔进显存、限制同时跑几个请求。其余参数对「到底用不用显卡」这件事影响很小，别在一堆无关变量上耗时间。

• 选对设备：多卡或者集显独显并存时，确认它加载的是你想要的那一块，改完看日志里的设备名是否跟着变。
• 控制卸载层数：显存够就多放几层，不够就少放几层，这是显存和速度之间最直接的旋钮。
• 限制并发请求数：同时跑多个请求会一起抢显存，串行测反而更容易看出真实速度。

显存不够时的正确动作顺序是：先降量化档位，再考虑减少卸载层数，最后才是换更小的模型。很多人一上来就换模型，其实降一档量化往往就够了。模型体积和显存的对应关系按当时的换算核对，别凭印象记，到 /models/deploy 按模型和量化方式填一遍就有数。

这几类场景偶尔会反复失效

笔记本双显卡切换、外接显卡坞、系统自动更新把驱动覆盖回旧版，这三种情况会让「昨天还好好的今天又不用显卡了」。这属于环境问题，不是参数问题，重装或回滚驱动往往比反复改配置有效。

排查清单：按这个顺序走，别跳步

1. 查驱动与设备识别确认驱动版本和卡型对得上，日志里能出现独显型号；不出现就停在这步。
2. 查进程是否真占用跑一个偏大的任务，盯显存变化，确认有卸载行为再往下。
3. 查显存够不够显存接近打满还卡，说明装不下，进入调档位环节。
4. 最后才动配置项前面三项都正常，再去调设备选择、卸载层数、并发数。

每一步都守好一个纪律：每改一处就重跑同一个模型同一个提示词，并且把改前的启动方式和输出记下来，方便回退。要横向比不同模型的资源占用，去 /models 查资料，别拿不同量化档位的数字互相比较，那是两码事。