Ollama凭借一条命令就能跑起本地大模型的便捷性，成了不少人入门本地推理的首选工具。但很多人装好之后发现，生成速度只有每秒几个token，明显不对劲。十有八九，问题出在两个地方：一是Ollama根本没有用上你的N卡，推理全靠CPU硬扛；二是模型量化等级选得不合适，要么超出显存导致频繁换页，要么过度追求精度拖慢了速度。这篇文章就把这两件事彻底讲清楚。
第一步：确认Ollama是否真的在用GPU
排查任何性能问题，第一步都是搞清楚现状。Ollama在启动模型时会把推理用的硬件信息打印到日志里，通过ollama ps命令可以快速查看。执行后重点看PROCESSOR这一列，如果显示的是100% CPU，说明模型完全跑在CPU上，显卡处于闲置状态；正常情况下应该显示100% GPU，或者类似70%/30% CPU/GPU的混合模式。
ollama ps # NAME ID SIZE PROCESSOR UNTIL # qwen2.5:7b xxxxxxxx 5.2 GB 100% GPU 4 minutes from now
如果想看更详细的加载日志，可以在服务端日志里查找关键字。Windows用户查看Ollama的运行日志，Linux用户执行journalctl -u ollama。日志中出现offloaded 33/33 layers to GPU字样表示所有层都成功放进了显存，这是最理想的状态；如果只offload了一部分层，说明显存不够，模型被切成了GPU和CPU两部分，速度会大打折扣。
还有一种情况容易被忽略：驱动问题。Linux下Ollama依赖CUDA或ROCm运行时，如果内核驱动和CUDA版本不匹配，Ollama会静默回退到CPU模式，只在日志里留一行不起眼的警告。所以看到CPU满载而GPU占用率为零时，别急着怀疑Ollama，先用nvidia-smi确认驱动本身工作正常，再检查Ollama版本是否支持你当前的显卡架构。
让Ollama正确调用GPU的关键配置
对于大多数N卡用户来说，只要装好了官方驱动，Ollama开箱就能用上GPU，它自带了CUDA运行时，不需要你单独安装完整的CUDA Toolkit。但有些场景需要手动干预。比如服务器上有多块显卡，想让特定模型固定跑在某一块卡上，可以通过环境变量CUDA_VISIBLE_DEVICES来指定设备编号。编号从0开始，和nvidia-smi列出的顺序一致。
# Linux 下设置环境变量后重启服务 export CUDA_VISIBLE_DEVICES=1 sudo systemctl restart ollama # Windows 下通过系统环境变量设置后重启 Ollama # setx CUDA_VISIBLE_DEVICES 1
另一个实用参数是num_gpu，它控制加载到GPU上的层数，可以在Modelfile中设置。对于显存刚好差一点的模型，手动降低这个值能避免加载失败，代价是一部分计算落到CPU上。此外，Windows笔记本用户要特别注意双显卡切换问题：Ollama默认可能调用的是核显而不是独显，需要在系统显卡设置里把Ollama指定为高性能GPU运行，否则跑的是Intel核显的OpenCL，速度反而不如CPU。
显存占用还有一个隐形杀手——上下文长度。Ollama默认的num_ctx是2048，一旦你把上下文调到16K甚至32K，KV缓存会额外吃掉几个GB的显存，可能直接把原本能装下的模型挤出一部分到内存。建议按实际需要设置上下文，不要盲目调大。
量化等级怎么选：速度、显存与质量的三方权衡
解决了GPU问题，接下来就是量化模型的选择。量化的本质是把模型权重从16位浮点数压缩成更低精度的整数表示，代价是轻微的精度损失，收益是显存占用大幅下降、推理速度明显提升。Ollama模型库里同一个模型往往有q4_0、q4_K_M、q5_K_M、q8_0等多个标签，它们的含义需要分清楚。
q4_0和q4_1是最早期的4bit量化方案，实现简单但精度损失偏大，目前基本被K系列量化取代。q4_K_M是目前公认的性价比之王，K代表k-quant混合量化技术，它对不同层使用不同位宽，重要层用更高精度保住关键信息。q5_K_M在质量上更接近原始FP16，显存占用比q4_K_M多出约三成。q8_0几乎是“视觉无损”的量化，和FP16的输出差异非常小，但显存占用也接近FP16的一半以上。
| 量化等级 | 7B模型显存占用 | 相对质量 | 适用场景 |
|---|---|---|---|
| q4_K_M | 约4.5 GB | 很好 | 大多数用户的默认选择 |
| q5_K_M | 约5.5 GB | 优秀 | 显存充裕、对质量敏感 |
| q8_0 | 约8 GB | 接近无损 | 8GB以上显存或做对比测试 |
选择的原则很简单：先确认可用显存，再倒推能装下的最大模型和最高量化等级。拿8GB显存的显卡来说，跑7B模型用q6_K甚至q8_0都绰绰有余；想上14B模型就只能选q4_K_M。宁可跑小一号模型的高量化版本，也不要硬撑大模型的极限量化，因为质量衰减在指令遵循和数学推理任务上会被放大。
如果你自己从HuggingFace下载GGUF模型文件，还可以在Modelfile里直接引用本地文件导入，灵活度更高：
# 从本地 GGUF 文件创建模型 ollama create mymodel -f Modelfile # Modelfile 内容示例： # FROM ./qwen2.5-7b-instruct-q5_k_m.gguf # PARAMETER num_ctx 8192
进阶优化与常见踩坑点
模型选对、GPU跑满之后，还有一些细节值得打磨。首先是保持Ollama版本更新，新版本经常带来推理后端的性能优化，尤其是对Apple Silicon和AMD显卡的支持一直在改进。其次，如果并发请求较多，可以考虑适当调大OLLAMA_MAX_LOADED_MODELS，让多个模型常驻显存，避免反复加载带来的冷启动延迟。
显存不足时不要直接放弃。除了换更低的量化等级，还可以接受部分offload：模型70%跑GPU、30%跑CPU，速度虽然不如全GPU，但通常仍比纯CPU快一倍以上。判断标准很简单，看ollama ps的输出，只要GPU占比在60%以上，体验 generally是可以接受的。
最后提醒三个高频踩坑点。第一，Windows系统装了Nvidia App或GeForce Experience后驱动自动更新，偶尔会把CUDA运行时搞坏，出现Ollama突然变慢的情况，重装驱动一般能解决。第二，Docker部署Ollama时如果没加--gpus all参数，容器里根本看不到显卡，这是容器用户最常犯的错误。第三，生成速度慢和首token延迟高是两回事：前者是纯算力问题，后者多半和模型加载、提示词过长有关，不要混为一谈。把这几个点逐一排查下来，绝大多数Ollama推理慢的问题都能迎刃而解。