使用 gpu 运行 ollama

很多人装完 Ollama 就跑模型，看着能出字就以为在吃显卡，其实一直在用 CPU 硬扛，速度慢还以为模型就这样。这篇不聊选哪个模型，只盯着「让 Ollama 用上 GPU」这一件事：先确认它到底认没认到卡，再按显存把卸载层数和并发定下来，最后给一套从慢到快的排查顺序，覆盖 N 卡、A 卡、核显和 Mac 这几种情况。

装完 Ollama 就跑模型，看它一个字一个字往外蹦，很多人默认觉得这就是显卡在工作。其实正好相反，最常见的情况是它一直在用 CPU 硬扛，显卡只是安静地待命。你感觉出来的「慢」和「卡」，往往不是模型本身的问题，而是没吃上卡。

这篇不挑模型、不比较谁家好用，只盯一件事：怎么让 Ollama 真的跑在 GPU 上。思路是三步——先确认它认没认到卡，再按显存把卸载层数和并发定下来，最后给一套从慢到快的排查顺序，N 卡、A 卡、核显和 Mac 都会覆盖到。

先确认它到底有没有用上 GPU

别用「能出字」当判断依据，出字只能说明模型跑起来了，跟走没走显卡没关系。真正的证据在加载日志和运行状态里：模型加载时会打印分层信息，能看出有多少层被放到了显卡上。如果显示全是 CPU，或者卸载层数是零，那就是没吃上卡。跑起来之后也能查当前加载详情，记得顺手看一眼。

• 看日志和运行状态：模型加载时打印的分层信息里，会写明多少层放到了显卡上；跑起来后也能查当前加载详情，层数为零就是没吃上
• 用系统层面交叉验证：同时开着显卡占用监控，发一条长一点的请求，看显存和算力有没有明显跳变；只涨一点或者完全不动，多半只是把权重读进来，计算还在 CPU 上
• 区分「加载了」和「在算」：显存被占住不等于每次推理都走显卡，短请求看不出来，要用长输出的任务去测才准

驱动和后端：能不能用 GPU 的前置条件

在排查「为什么没吃上卡」之前，先把方向分对：不同显卡走的是不同后端，经验不能照搬。N 卡和 A 卡、核显、Mac 统一内存，四条路线各有各的前置条件，用错方向会白折腾半天。

N 卡路线

看驱动和 CUDA 运行时是否装全，容器里跑还要把显卡设备透传进去，否则 Ollama 只能看到 CPU

A 卡与核显路线

走的是另一套后端，支持范围和模型格式都更窄，先确认自己的卡在不在支持列表里，别按 N 卡经验照搬

Mac 路线

统一内存架构，不存在显存够不够这一说，但内存被别的程序吃掉后，表现和显存不足很像

权限问题

Linux 上「装了驱动还是不认卡」，先查 Ollama 进程有没有权限访问显卡设备，这比驱动问题更常见

还有一种情况要专门提醒：笔记本双显卡机器，系统默认可能把 Ollama 分给了核显。这时候你驱动装得再全，独显也一直在打盹，表现和没装驱动几乎一样。所以「认卡」这件事，既要看驱动，也要看进程最终拿到的是哪一块。

卸载层数与显存：把「用上」变成「用满」

Ollama 跑 GPU 的核心机制是把模型切成若干层，能塞进显存的部分放显卡，剩下的留在内存交给 CPU 算。这个分界点决定了你是「用上卡」还是「用满卡」。层数给多了会爆显存，给少了等于白买卡，所以它不是越大越好，而是按可用显存算出来的。

判断标准很直接：如果模型能完整塞进显存，速度会明显跳一档；只能塞一半的话，提速有限但仍值得做。要注意留余量——显存总量减掉系统和别的进程占用之后，还要给上下文缓存留空间，一点不留的结果就是请求一长就崩。

Windows + N 卡：最常见的一套动作

这是最多人踩坑的组合，动作本身不复杂，问题多半出在装了非官方包、或者服务没重启导致配置没生效。按下面几步走，每步都能验证。

1. 确认安装包来源用官方安装包，不要用某些绿色版或精简版，这类包经常缺运行时组件，显卡认不到就是这么来的；装完先在终端里跑一下版本命令，能正常返回说明基础环境没问题
2. 打开显卡相关开关在服务端配置里如果有显卡相关的开关，先把它打开，然后重启服务，让进程重新读一次硬件信息；配置改了不重启，等于没改
3. 跑对比测试找同一个模型、同一条提示词，分别记录开启前后的输出速度。用速度差来验证，比只看任务管理器里有没有占用靠谱得多
4. 处理双显卡机器笔记本这类双显卡设备，要到显卡控制面板里明确指定独显给这个程序用，否则系统可能默认给核显，表现和没配一样

Linux 和容器环境：权限与设备映射

Linux 上最常见的问题不是驱动没装，而是服务用户没权限碰显卡。以 root 跑就正常、普通用户跑就没 GPU，这种「只有 root 能用」的尴尬，基本都能通过把服务用户加进显卡访问组来解决。

• 裸机安装时，把运行 Ollama 的服务用户加进显卡访问组，避免只能以 root 跑才有 GPU
• 容器里跑，要把显卡设备和驱动库按官方给的参数映射进去，只拉镜像不映射设备是最常见的返工原因
• 多卡机器要明确哪张卡给谁用，不然会出现插了三张卡只有一张在干活的情况，排查时先看每张卡的占用分布
• 纯跑通接口、测功能、做小批量校验这类场景，CPU 也能过，别在显卡适配上浪费时间

多卡环境还有个隐蔽坑：并发请求默认可能全压到同一张卡上。如果你感觉「明明卡不少但还是慢」，先看每张卡的占用是不是均衡，再决定要不要手动分流。

Mac 与核显：另一条路线

Mac 用的是统一内存，没有独立显存的概念，能不能跑顺关键看整机内存装不装得下模型。内存不够时会走交换分区，表现是卡顿而不是报错，所以别指望日志里能直接看到「显存不足」。

• Mac 上没有显存这一说，关键是整机内存够不够装下模型，不够时系统开始换页，表现就是卡顿
• 核显能跑小模型，带宽和算力上限明显，适合轻量分类、摘要这类任务，不适合当主力对话模型
• 判断标准：同一条提示词在核显上要等很久，先怀疑模型选大了，而不是继续调参数
• 这类设备上更值得关注的是「能不能稳定跑」，而不是「能不能跑得快」

什么情况下不适用：如果你本来就想在 Mac 或核显上跑大模型做主力生产，那调参帮不了你太多，这是硬件上限的问题，换设备比调参数更实际。

排查顺序：从慢到快按这五步走

遇到「明明有卡还是慢」，别东改一处西改一处。按固定顺序走，每一步只改一个变量，改完用同一条提示词对比输出速度，这样才能分清是哪一项起了作用。

1. 看有没有认到卡先看日志确认 Ollama 有没有识别到显卡，没认到就先解决驱动和权限，后面的步骤都不用做
2. 看卸载了多少层看模型加载时有多少层放到了显卡上，层数为零说明配置没生效，回去检查重启和开关
3. 看推理时有没有在动发长输出请求，同时观察显存和算力有没有持续变化，只在开头跳一下说明计算还在 CPU
4. 看内存有没有被吃满检查系统内存占用，被吃满走交换分区时，就算显卡在干活整体也会被拖慢
5. 看模型和量化是否匹配上面都正常还是慢，就怀疑模型本身太大或量化档位不合适，换小一档试试，别先怀疑硬件坏了

把「接口测速」当成基线：先量一次没开 GPU 时的速度，再量开了之后的速度，差值就是这一步的收益。至于各个模型在不同显卡上的实际表现，站内会持续更新当时的数字，到具体页面对照看更靠谱，别拿别人的配置套在自己机器上。

先确认它在不在用显卡，再谈怎么用得更好；顺序错了，调多少参数都是白费。