先定死判断标准:Ollama 有没有用 GPU,不看装了哪个安装包,只看两处——ollama ps 输出里 PROCESSOR 这一列,以及 ollama serve 启动日志里有没有出现带 library=cuda(NVIDIA)、library=rocm(AMD)或 library=metal(Apple)的 inference compute 行。显示 100% GPU 才算真正跑在显卡上;显示 100% CPU 或 xx%/xx% CPU/GPU 的混合值,说明显存没吃下全部模型层,速度会明显掉下来,但进程不会报错——这是最常被误判成“已经用上 GPU”的地方。
Ollama 在纯 CPU 上也能跑,所以 GPU 没生效时通常不报错,只是变慢。可核对的顺序是:先看ollama `--version`和启动日志识别到的计算设备,再用ollama ps看进程层 GPU 占比,最后才调 num_gpu 和 num_ctx。显存不够时调参救不回来,先换更小的量化模型或缩短上下文。
Ollama怎么用GPU跑模型
在 Ollama 里,“用 GPU 跑”对应的不是安装步骤,而是模型加载时决定把多少层放到显存这一步。这个决定发生在服务端加载模型时,由可用显存、模型体积和 num_gpu 参数共同决定,客户端只负责发请求。所以要看结果,必须看服务端的运行状态,而不是看请求有没有返回。
可核对的位置有两个,都在本机执行:
# 终端 A:前台启动,观察日志
OLLAMA_DEBUG=1 ollama serve
# 终端 B:加载模型后查进程状态
ollama run qwen2.5:7b "说一句话"
ollama ps
# 也可以直接查接口
curl -s http://127.0.0.1:11434/api/ps
ollama ps 返回一张表,列名通常是 NAME、ID、SIZE、PROCESSOR、UNTIL。PROCESSOR 为 100% GPU 表示全部层在显存;100% CPU 表示完全没走显卡;70%/30% CPU/GPU 这种则是部分卸载。终端 A 的日志里,加载阶段会出现 inference compute 一行,写明识别到的设备名、library 和可用显存总量;如果这一行的 library 是 cpu,或者压根没出现 GPU 设备,那么后面怎么调参数都不会进显存。不同版本的日志字段和措辞会有差异,以本机实际输出为准。
Ollama之前先确认这三件事
这三条缺一条,后面的命令都会“看起来成功、实际在跑 CPU”。
- 版本与服务方式:执行
ollama `--version`记录版本号。再确认 Ollama 是手动ollama serve启动,还是系统服务启动:Linux 上看systemctl status ollama,Windows 看托盘的 Ollama 图标与“服务”列表。两者用的环境变量可能不是同一套,改过配置要重启对应服务才生效。 - 权限:在同一个用户下执行
nvidia-smi(AMD 用rocm-smi),能列出显卡和显存才算驱动就绪。容器里跑的,需要启动时带`--gpus` all,并且宿主机装了对应的容器运行时支持;Linux 上有些驱动安装方式会要求当前用户在有显卡设备访问权限的用户组里,具体以ls -l /dev/nvidia*的属组为准。 - 入口位置:客户端默认连
127.0.0.1:11434。如果你在另一台机器上调用,或者改过OLLAMA_HOST,那么ollama ps查的必须是同一个服务实例,否则看到的是空表或有进程但设备对不上。
Ollama:最短可用路径
- 确认驱动可用:执行
nvidia-smi。应看到显卡型号、驱动版本和一列显存占用;命令不存在或报错就先解决驱动。 - 带调试日志启动服务:
OLLAMA_DEBUG=1 ollama serve(服务方式启动的用systemctl restart ollama后看journalctl -u ollama -n 50)。应看到 inference compute 行,library 为 cuda 或 rocm。 - 拉一个能放进显存的小模型:
ollama pull qwen2.5:7b。应看到分层拉取完成、模型出现在ollama list。 - 显式指定卸载层数跑一次:
ollama run qwen2.5:7b后另开终端ollama ps。若显示非 100% GPU,用 Modelfile 固定参数重建模型:
# Modelfile
FROM qwen2.5:7b
PARAMETER num_gpu 99
PARAMETER num_ctx 8192
ollama create qwen2.5-7b-gpu -f Modelfile
ollama run qwen2.5-7b-gpu
ollama ps
num_gpu 99 是“尽量全部层放显存”的写法,实际能放多少由显存决定;num_ctx 直接吃显存,写死一个够用的值比让它自动放大更稳。第 4 步做完应看到 PROCESSOR 列为 100% GPU。
Ollama:一个真实场景的完整做法
场景:一台单卡 24GB 显存的 Linux 工作站,用中文模型做合同条款摘要,单次输入约 3000 字中文(大致对应三四千 token),输出控制在 200 字以内,要求连续处理一批文件时响应稳定。
配置落在 Modelfile 里,不用每次请求带参:
FROM qwen2.5:14b
PARAMETER num_ctx 8192
PARAMETER num_gpu 99
PARAMETER temperature 0.2
ollama create contract-sum -f Modelfile
ollama run contract-sum
这段配置写在任意目录下的文本文件 Modelfile 里,在该目录执行 ollama create。验证动作有两步:一是 ollama ps 里进程的 SIZE 应明显小于模型文件体积对应的 CPU 占用形态,PROCESSOR 为 100% GPU;二是跑一条 3000 字输入时执行 nvidia-smi,应看到 ollama 相关进程占用显存,而不是只有显存占用为 0。若 ollama ps 出现 CPU 占比,先把 num_ctx 降到 4096 再看,仍然混合就说明 14b 这个体量在你的显存余量下放不全,换更小的参数量或更低比特的量化版本更实际。
走接口批处理时把同一组参数放进 options,便于逐次调整:
curl -s http://127.0.0.1:11434/api/generate -d '{
"model": "contract-sum",
"prompt": "摘要以下条款:……",
"options": {"num_ctx": 8192, "num_gpu": 99},
"stream": false
}'
注意 num_ctx 是在加载时生效的,同一模型用不同 num_ctx 请求会触发重新加载,批处理时保持这个值不变,避免反复换入换出。
Ollama:跑不通先查这三处
一、进程在跑但 PROCESSOR 显示 CPU 占比。典型表现是 ollama ps 出现 100% CPU 或 xx%/xx% CPU/GPU,请求正常返回只是慢。检查位置:nvidia-smi 看当前显存是否被别的进程占满,以及启动日志 inference compute 行给出的可用显存与模型实际体积的对比。处理方向是缩小 num_ctx、降低 num_gpu,或换更小的模型。
二、启动日志里没有 GPU 设备。表现为日志只有 CPU 相关输出,或出现类似 no compatible GPUs were discovered 的提示。检查位置:先在同一个 shell 里跑 nvidia-smi 确认驱动;容器里跑的要确认启动参数带 `--gpus` all;systemd 启动的要确认服务单元里没有把环境变量覆盖掉,可用 systemctl show ollama -p Environment 查看。
三、加载直接失败。常见报错是 CUDA error: out of memory,或提示模型所需内存超过可用内存(类似 model requires more system memory than is available)。这类不是配置优化问题,先 ollama stop 模型名 释放已加载实例,再把 num_ctx 或 num_gpu 调低后重试;同时用 nvidia-smi 确认没有残留进程占着显存。如果日志里出现 llama runner process has terminated 这类字样,通常伴随上面的显存或内存错误一起看,单看这一行判断不了原因。