大模型Ollama性能优化：从CPU到GPU的实用调优步骤
Ollama 默认配置能跑起来，但未必跑得快。
如果你发现模型回复慢、显存占用高或者多用户请求排队严重，通常不是模型本身的问题，而是硬件加速没生效、模型量化版本选错或并发参数不合理。
下面按零基础也能照做的顺序，讲清楚怎么检查、怎么调、怎么验证。
先确认瓶颈在CPU还是GPU
优化之前先别急着改参数，用系统命令看实际负载。
Linux 下执行：
nvidia-smi如果显存占用接近 0，而 CPU 占用很高，说明 Ollama 很可能还在用 CPU 推理。
再看 Ollama 日志确认加载设备：
journalctl -u ollama -n 50 --no-pager日志里出现 using CUDA 或 using ROCm 表示 GPU 已启用；
只出现 CPU 相关字样则说明加速未生效。
这一步是后续所有优化的前提，不要跳过。
让GPU真正参与推理
确认驱动和容器运行时正常后，重点检查两处。
第一，启动 Ollama 时是否传入了 GPU 设备。
如果你用 Docker 运行，启动命令要带 --gpus all：
docker run -d --gpus all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama第二，检查模型加载时是否被强制指定到 CPU。
Ollama 支持通过环境变量控制 GPU 层数，例如 OLLAMA_GPU_OVERHEAD 和模型参数 num_gpu。
在 Modelfile 中可显式设置：
PARAMETER num_gpu 99数字不是越大越好，设为 99 表示尽量把全部层放到 GPU。
如果显存不足，Ollama 会自动回退部分层到 CPU，此时需要换更小的量化模型。
选对量化版本比调参更有效
同一个模型，q4_0 和 q8_0 的显存占用和速度差异明显。
零基础用户优先用 Ollama 库中带 q4 标识的版本，例如：
ollama run llama3:8b-instruct-q4_0如果显存充足且对精度要求高，
再考虑 q8_0。不要盲目拉取最大参数版本，
先看 nvidia-smi 剩余显存，
模型文件大小加上上下文缓存不要超过可用显存，
否则会触发内存交换，
速度反而更慢。
调整并发和上下文参数
Ollama 默认并发数较低，多用户场景下请求会排队。
可通过环境变量调整：
export OLLAMA_NUM_PARALLEL=4
export OLLAMA_MAX_LOADED_MODELS=2OLLAMA_NUM_PARALLEL 控制同时处理的请求数，OLLAMA_MAX_LOADED_MODELS 控制常驻模型数量。
数值调大前先确认显存和内存余量，否则容易触发 OOM。
另外，请求时可通过 API 传入 num_ctx 控制上下文长度，短对话没必要开太大：
curl http://localhost:11434/api/generate -d '{
"model": "llama3:8b-instruct-q4_0",
"prompt": "你好",
"options": {"num_ctx": 2048}
}'上下文越长，显存占用越高，按实际对话长度设置即可。
验证优化是否生效
改完配置后重启服务，用同一个提示词对比前后耗时：
time curl http://localhost:11434/api/generate -d '{"model":"llama3:8b-instruct-q4_0","prompt":"写一句问候语"}'同时观察 nvidia-smi 中显存占用和 GPU 利用率是否上升。
如果耗时没有明显变化，回到日志检查模型是否仍加载在 CPU 上，或者量化版本是否选错。优化效果以实际请求耗时和资源占用为准，不要只看参数是否设置成功。
容易踩的坑
- 驱动版本与 CUDA 运行时不匹配时，Ollama 可能静默回退到 CPU，日志里不一定报错，务必用
nvidia-smi交叉确认。 - 在低显存机器上设置过大的
num_gpu会导致加载失败或频繁换页，建议从默认值逐步上调。 - 修改环境变量后忘记重启 Ollama 服务，配置不会生效。
- 多模型常驻会争抢显存，非必要不要同时加载多个大模型。
如果你正在处理大模型Ollama性能优化，建议先按本文步骤确认 GPU 是否真正参与推理，再调整量化版本和并发参数；
每次只改一个变量并记录耗时，遇到异常时优先回看日志和显存占用。
