很多人装完 Ollama、拉完模型，只看到能出字就以为已经用上显卡了，实际上任务可能全压在 CPU 上，慢得离谱还占满内存。这篇给一套能自己动手核对的顺序：先确认驱动和显卡被认到，再看模型到底加载进显存多少层，不够时怎么按显存反推该调哪些参数，最后给常见「显卡明明有却没加速」的排查路径。
装完 Ollama、拉完模型，终端能出字，很多人就默认自己在用显卡了。其实不一定：任务可能整块压在 CPU 上，风扇不吵、显存不动，但内存吃满、速度慢得离谱。这篇不讲原理，只给一套能自己动手核对的顺序：先确认驱动和卡被认到，再看模型加载进显存多少层，显存不够时按什么逻辑调参，最后给「卡明明在却没加速」的排查路径。每一步都能自己验证，不依赖别人告诉你结论。
先说清楚适用范围：这套流程针对 NVIDIA 独显、驱动正常安装的环境。纯 CPU 机器、核显、显卡被虚拟机切走、或者跑在云主机的共享卡上，核对方式不成立，直接按 CPU 推理的预期估速度就行。另外速度高低没有统一标准，同一张卡换模型、换量化档位差很多，要横比就去 /tools/speed-test 看当时的方法和数字，别拿别人帖子里的数当自己的基线。
先确认 Ollama 到底认没认到你的 N 卡
第一步不是调参，是确认现状。跑一次短推理，同时盯两个地方：一看 Ollama 的输出日志有没有提到 CUDA、显卡型号、显存容量这类信息；二看系统侧显存占用有没有在推理期间上涨。这两条对着看，基本就能判断它是不是真的走了 GPU。渠道不同日志位置不一样，Windows 直接看服务窗口或后台程序输出，Linux 看服务日志。以 Ubuntu 上跑 systemd 服务为例，可以边跑模型边跟日志，看有没有加载到显卡的迹象。
# 另开一个终端，边推理边看服务日志
journalctl -u ollama -f
# 另一个终端跑一次短推理
ollama run <你本地已有的模型:标签>
# 再看显存占用（NVIDIA 自带工具）
nvidia-smi- 日志里没有任何显卡相关的字样：多半是驱动没装好，或服务启动时没读到 CUDA 运行时，先回去查驱动
- 日志提到了显卡，但 nvidia-smi 里显存几乎不动：模型可能整个留在内存里，进入下一节的层卸载检查
- 容器里跑 Ollama：必须把显卡设备透传进容器，否则容器内部看不到卡，日志和显存两边都会显得「正常但其实没卡」
- 有卡但推理直接报错退出：先确认驱动版本和显卡是否被系统认到，不要急着改 Ollama 参数
显存装不下怎么办：层卸载与量化档位的取舍
- 卸载层数
- 模型的一部分层放进显存、剩下的留在内存里，显存能放多少就尽量多放
- 量化档位
- 同样参数规模的模型，量化越激进占用越小，但质量损失要自己验，别只看能不能跑起来
层卸载是折中，不是万能开关。显存够就尽量多放层，放得太少速度会掉一个量级，感觉像没加速；但层放够了之后，新的瓶颈会变成内存带宽，这时候再加显存也未必更快。比较稳的做法是先拿一个明显能全放进显存的小模型或更小的量化档位，确认「确实变快了」，再逐步往上加模型规模，而不是一上来就上最大的那个。想看某个模型在当前参数下的显存占用大概是多少，可以到 /models/deploy 按当时的参数算一遍，别拿记忆里的数当依据。
- 定基线先用一个能全塞进显存的小配置跑通，记录提示词固定、输出长度固定下的耗时，作为「加速成功」的参照
- 逐级加码每次只换一个变量（模型规模或量化档位），重复同样的提示词和输出长度，看耗时和显存占用怎么变
- 验证层数每次调整后都回看日志里加载进显存的层数有没有变化，没变化说明参数根本没生效，先解决这个再谈速度
不适用的情况也要说清楚：多卡但要跨卡切分一个超大模型时，靠改层卸载解决不了，得看部署框架本身支不支持张量并行；显存被其他程序长期占着（比如桌面环境、别的推理服务），调层数也换不出空间，先腾显存再调。
多卡机器上指定用哪张、用完怎么释放
一台机器插好几张卡时，Ollama 未必挑到你希望的那张，可能正好是被别的任务占满的那张，结果就是「有卡但慢」。这时候可以用环境变量限定可见显卡，等于只让它用其中一张或几张。改完必须重启服务，再跑一次推理，看目标卡的显存占用有没有变化，才算验证生效。
# 只让 Ollama 看到 0 号卡（按实际卡序调整）
export CUDA_VISIBLE_DEVICES=0
# 重启服务后验证
nvidia-smi
ollama run <你本地已有的模型:标签>| 使用场景 | 建议策略 | 验证方式 |
|---|---|---|
| 持续对话、频繁调用 | 模型常驻，省掉反复加载的时间 | 常驻后显存占用稳定不回落 |
| 偶尔跑一次、机器还要干别的 | 用完释放，别长期占显存 | 下次调用首字延迟明显变长属正常 |
| 共享服务器、别人也在用同一张卡 | 先谈好显存分配再指定卡 | 指定卡后显存占用是否真的落在目标卡上 |
常驻和释放是权衡：常驻省加载时间但长期占显存，不常驻每次首字延迟高。按你是哪种用法来定，没有通用答案。多卡环境里还有一个不适用的情况：别人也在用你要指定的那张卡，光改环境变量没用，得先把显存分配谈清楚。
排查顺序：有显卡但速度没变化
遇到「卡在、但速度跟以前一样」，不要一次改一堆参数。按从下往上的顺序逐层排除：驱动版本是否匹配 → 服务启动时是否读到驱动 → 模型是否真的加载进显存 → 是不是被 CPU 内存带宽拖住。前一层没确认干净，就别动下一层，否则改完你也不知道是哪一步起的作用。
- 先查驱动：版本不匹配时，日志里通常看不到关键信息，先把它修好
- 再查服务：重启后看日志，确认启动阶段就认到了卡
- 再看模型加载：回看加载进显存的层数，层数太少等于没加速
- 最后看瓶颈：显存够了但速度仍慢，可能是内存带宽或磁盘加载拖后腿
- 换小配置验证方向：同一模型换更小量化档位，如果明显变快，说明方向对了，再逐步加大
测速时固定提示词和输出长度，否则不同长度下的对比没有意义；第一次跑还要区分「加载时间」和「推理时间」，很多人把首次加载的等待当成了推理慢。要是想有个可对照的测法，先照 /tools/speed-test 的做法量出基线，再看调整之后有没有变化。还有一个不适用场景：模型很小、瓶颈在磁盘读取或网络拉取时，显卡加速救不了首次启动的等待，这种情况该优化的是存储和网络，不是显存。
下一步把本文的核对顺序走一遍，再去看站内收录的部署与硬件资料，按当时的参数和数字对照，别用记忆里的规格估。→常见问题
怎么判断 Ollama 现在是不是在用显卡跑？
看两处：一是推理时系统显卡工具的显存占用是否明显上涨，二是服务日志里有没有报出显卡和 CUDA 相关信息。两处都对不上，基本就是掉回 CPU 了，接着按驱动、服务、模型加载顺序逐层排查。
显存不够，是换小模型还是调卸载层数？
先调层数，这是成本最低的一步，能榨出多少显存就放多少层。如果调完速度还是不能接受，再考虑换更小的参数量或更激进的量化档位，具体该选哪档可以到 /models/deploy 按自己的显存算一遍再决定。
改完显卡相关配置要重启吗？
要。环境变量类的改动只在服务启动时读取，不重启等于没改。改完重启服务，再跑一次固定提示词的推理，对比显存占用和出字速度，确认这次改动真的生效了再继续下一步。
