win ollama gpu 启动

很多人在 Windows 上装完 Ollama，模型能跑但风扇不转、出字一个字一个字蹦，一查才发现全程在用 CPU。这篇不讲安装步骤，只讲怎么判断当前是不是 GPU 在干活、为什么没走 GPU、按什么顺序排，以及怎么用参数和环境变量把它掰回 GPU。每一步都给能自己动手验证的动作。

很多人装完 Ollama，对话能通，但风扇不转、出字像打字机，一问才发现全程 CPU 在扛。问题不是 Ollama 装错了，而是它默认不一定会把模型塞进显卡。Windows 这条路要排的东西比 Linux 多：驱动、核显独显抢活、环境变量没被进程读到，都会让 GPU 形同虚设。

这篇不教安装，只讲判断顺序：先搞清楚现在到底有没有用上 GPU，再按代价从低到高排驱动、显存、参数，最后用一套固定动作验证改了有没有用。每一步都给你能自己动手确认的办法，而不是让你盲调参数。

第一步：先确认 Ollama 到底有没有用上 GPU

别一上来就翻驱动或改参数。先确认当前这次推理走的是哪条路，否则后面全是瞎折腾。最快的入口是看 Ollama 自己的进程状态：它会把模型后面标成纯 GPU、纯 CPU 或混合卸载，这比任务管理器更直接反映 Ollama 的判断。

同时在任务管理器里盯两个指标：GPU 的「专用显存」占用，和 Compute 引擎的活动。跑推理的瞬间，显存数字不动、Compute 曲线平的，基本可以断定没上卡。两个办法互相印证，能避免被某一个指标误导。

• 用 ollama ps 看模型进程后面那列标注，它是纯 GPU、纯 CPU 还是混合卸载，先记下当前状态
• 任务管理器切到性能页，看专用显存占用和 Compute 引擎，跑一次推理观察是否波动
• 固定一条提示词，在当前状态下跑一遍并记下出字速度，作为后续对比的基线
• 把提示词换成更长的，再看一次标注有没有变化——长上下文更容易触发显存不足转 CPU

什么情况下这套判断不适用：当显存刚好在模型边界上，Ollama 会主动把一部分层留在内存里，显示混合但速度并不难看。这时把「混合等于没上卡」当成结论就错了，先看速度再决定要不要动。

驱动与运行时：Windows 上最常见的三个拦路点

确认没上卡之后，下一步看日志。Ollama 启动时如果报找不到可用设备，多半不是模型问题，而是驱动或运行时没到位。这一步给三条路线各自的检查点，别把三条混着排。

排查顺序建议是固定的：先看 Ollama 启动日志有没有识别到设备，再看驱动版本对不对，最后才怀疑模型和参数。顺序反过来会让你在参数上浪费大量时间，而真正的问题在更底层。

• 先翻启动日志，确认有没有设备识别相关的报错
• 再核对驱动版本与运行时是否匹配对应显卡路线
• AMD 用户先查型号在不在支持列表里，不在就别继续
• 核显用户把它当补充算力看，别指望它顶替独显
• 三条路线确认完再回头看模型，别提前跳到参数调整

环境变量：把 GPU 相关开关显式写死

Windows 上很多「改了没反应」都是因为变量设了但老进程还在跑。环境变量要设在系统级或用户级，设完之后必须完全退出 Ollama 托盘进程再重启，只关窗口不算退出，老进程还在用旧配置。

显存卸载层数类变量

控制有多少层放到 GPU 上，显存紧张时下调，等于用速度换稳定

模型常驻相关变量

决定模型被调用后多久还留在显存里，频繁调用时能省掉反复加载的开销

设备指定类变量

告诉 Ollama 用哪块卡，双显卡机器上尤其关键

1. 设变量在系统或用户级环境变量里写入需要的 GPU 相关开关，别只写在某个终端窗口里。
2. 彻底退出从托盘退出 Ollama，确认任务管理器里没有残留进程，窗口关闭不等于退出。
3. 重启服务重新启动 Ollama，让它重新读取环境变量。
4. 验证生效跑一次模型，再用查看进程状态的方式对照标注，标注变了才算真正生效。

这里最容易踩的坑是把变量设成临时会话级，结果换个终端就没效果。判断标准很简单：重启后标注没变，先怀疑变量没被进程读到，而不是怀疑显卡坏了。

显存不够时的三个动作，按代价从低到高

显存不够时的表现不是报错，而是悄悄退回 CPU 或频繁在显存和内存之间倒腾，最后体感就是「能用但很慢」。处理动作按代价排序，先从便宜的开始。

• 先降量化档位：同一模型换更小的量化版本，具体占用和速度的取舍到 /tools 和 /models/deploy 页面按当时的数字核对
• 再降上下文长度：上下文是显存里最容易被忽视的一块，长对话场景先把窗口调小试
• 最后才考虑换更小的模型或加卡
• 别硬撑着混跑，那会停在「能用但很慢」的中间状态

不适用的情况要讲清楚：如果你的任务本身就要长上下文加高精度，降档之后效果可能达不到预期。这时正确的做法不是硬降，而是先算清楚需要多大显存，再决定硬件，别在软件参数上反复拉扯。

多张卡怎么指定用哪一张

只有一张独显加一张核显的机器，出问题的方式很典型：明明有独显却特别慢，原因是任务被分到了核显上。Windows 的多显卡切换逻辑不总是按你期望的方式走，所以设备要显式指定。

1. 先看清有哪几张卡在任务管理器里确认独显和核显各自的编号和当前占用，别默认系统会优先用独显。
2. 显式指定设备通过环境变量或启动参数指定要用哪张卡，改完同样要重启服务才生效。
3. 前后对比指定前后各跑一次同一条提示词，对比速度，并在任务管理器里确认是哪张卡在吃显存。

多张同型号卡可以一起用，但别把显存当简单相加。卡之间的通信和切分会吃掉一部分，实际可用的比加总少。显存本来就紧的情况下，多加一张卡的收益可能不如把单卡上的模型降一档来得实在。

让模型常驻显存，别每次都冷启动

默认情况下模型空闲一段时间会被卸载，下次调用重新加载。体感就是「第一次问很慢、后面正常」，很多人误以为是 GPU 没配好，其实只是冷启动。

把常驻时间调长，适合连续对话或本地应用高频调用。但如果平时只是偶尔用一次，常驻反而白占显存，让别的任务没地方放。常驻和并发是互相挤占的关系，显存紧的时候先别开。

• 连续对比两次同样的调用，第二次明显快很多，说明第一次是冷启动
• 高频调用场景把常驻时间调长，省掉反复加载
• 显存本来就紧的机器，优先保显存而不是保常驻
• 常驻设好之后同样要重启服务并重新验证标注

验证与常见故障的排查顺序

改完之后不能凭感觉说「好像快了」。固定一条提示词，记录出字速度和显存占用，把它当成你自己的基线，之后任何改动都拿它对比，这样才有判断依据。

1. 看进程状态标注确认现在是纯 GPU、纯 CPU 还是混合，先定性。
2. 翻日志找设备报错看启动日志有没有设备识别相关的问题，这决定后面往哪个方向排。
3. 核对驱动版本确认驱动与显卡路线匹配，AMD 用户先查型号支持。
4. 检查环境变量确认变量确实被进程读到了，重启后标注没变就往这里查。
5. 看显存是否够显存不足会导致频繁倒腾，表现为越改越慢。
6. 调模型量化档位前面都正常还慢，降量化档位试。

如果改完反而更慢，先怀疑显存不足导致的频繁倒腾，而不是以为 GPU 坏了。接口层面的延迟基线可以到 /tools/speed-test 先量一遍，避免把网络问题和本地推理问题混在一起排，方向错了会白折腾很久。

什么情况下不值得折腾 GPU

不是所有场景都值得为 GPU 花时间。判断标准很简单：先跑一次记录速度，如果目前的体感你不难受，就没有必须上 GPU 的理由。下面这些情况尤其别硬上。

• 模型本身很小、任务以短问答为主时，CPU 出的速度已经够用
• 笔记本双显卡切换机型驱动问题多，只是想试跑的话用小量化模型比修驱动划算
• 公司统一发放的办公机往往锁驱动版本，装不了对应运行时，别硬上
• 硬件受限时，把时间花在选合适的模型上，比修驱动收益更直接

这些判断也不是绝对的：如果你的任务从短问答变成了长文档处理或者本地应用高频调用，之前够用的速度可能就不够了，这时候再回头排 GPU 也不迟。关键是先有基线，再决定要不要动。