Ollama显存溢出？三个默认设置正在偷偷倍增内存占用

模型能装下，但默认设置装不下

很多本地部署大模型的用户都遇到过这样的困惑：明明模型大小和显存容量匹配，推理速度却慢得离谱，甚至频繁溢出到CPU。问题往往不在模型本身，而在于Ollama的几个默认参数——它们会在模型真正加载之前，就悄悄把你的显存需求翻倍。

这里需要理解一个关键概念：本地部署大模型时，显存的占用由两部分组成——模型权重和运行时内存（主要是KV缓存）。模型权重是固定开销，取决于参数量和量化精度；而运行时内存是动态开销，随上下文长度、并行请求数等参数线性甚至倍数增长。很多人只关注了前者，却忽略了后者往往才是压垮显存的最后一根稻草。

这篇分析来自Reddit社区一位深度使用Ollama的用户，其核心观点是：大多数人在调整模型量化（quant）之前，从来没有运行过 ollama ps 这一行命令，而这行命令恰恰能一眼定位问题所在。

一行命令看清Ollama显存占用真相

运行 ollama ps，重点看 PROCESSOR 这一列，它只会报告三种情况之一：

• 100% GPU —— 所有层都在GPU上，理想状态
• 100% CPU —— GPU完全没用上
• 类似 48%/52% CPU/GPU —— 部分层被卸载到CPU

如果不是 100% GPU，答案就到此为止了——问题不在模型本身。

这里有一个关键的性能认知：一个跑在90% GPU上的模型，并不会以90%的速度运行。因为每生成一个token，都要等待那些跑在CPU上的慢速层。现代大模型由数十层Transformer块堆叠而成，自回归生成是严格串行的——每一层的输出是下一层的输入。即使只有少数几层在CPU上，每个token的生成都会被这些层的速度拖慢，而且数据需要通过PCIe总线在GPU显存和系统内存之间反复搬运，PCIe的带宽通常只有GPU显存带宽的1/10到1/20。一个溢出到CPU的层，对吞吐量的损害，比整整降一档量化还要严重。 这也是为什么很多人拼命降低模型精度却依然慢的根本原因。

三个偷偷倍增内存的Ollama默认值

真正让人踩坑的地方在于：以下三个设置都是默认值，而不是任何人主动选择的结果。

默认上下文窗口仅4096 tokens

Ollama的默认上下文窗口是 4096 tokens，无论模型卡片上宣传的是多少。一个标称128k上下文的模型，如果你不设置 OLLAMA_CONTEXT_LENGTH 或使用 /set parameter num_ctx，实际能用的就只有4096。

这里需要理解上下文窗口的工作机制：大语言模型的上下文窗口决定了它一次能"看到"多少token。在典型的对话场景中，上下文由系统提示词、历史对话和当前用户输入拼接而成，系统提示词通常被放在最前面。当总token数超出上下文窗口限制时，Ollama采用的是截断最早内容的策略（即滑动窗口），而不是报错或压缩。

这种静默截断极具欺骗性——当你的prompt超出真实窗口时，最前面的部分会被丢弃——而系统提示词（system prompt）恰恰就在最前面。所以模型并不是「无视了你的指令」，也不是「输入一长就变笨」，而是那条指令根本就没进入窗口。用户看不到任何错误提示，只会感觉模型表现异常。这个误解在社区里极其普遍。

值得注意的是，上下文窗口的显存开销与模型权重是完全独立的。即使你的模型权重只占了显存的60%，一旦设置了过大的上下文长度，KV缓存的开销就可能把剩余的40%全部吃光甚至溢出。

并行请求会成倍放大显存需求

所需显存的计算公式是：OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH。

Ollama官方文档给出的示例很直观：2K上下文配合4个并行请求，实际会变成8K上下文的显存分配。

这背后的原因在于KV缓存的工作机制：Transformer架构中的注意力机制需要为每个请求独立维护Key和Value向量缓存。在自回归生成过程中，每生成一个新token都需要与之前所有token计算注意力关系，如果每次都重新计算则开销巨大，因此已计算的Key-Value对会被缓存在显存中。每个并行请求都需要自己独立的KV缓存空间，这些缓存无法共享。所以当并行度大于1时，把 num_ctx 提高4倍，成本不是4倍——而是4倍乘以并行数。这通常就是把你从「刚好装下」推到「溢出」的那一步。很多人在调大上下文时完全忽略了这个乘法关系。

多模型同时驻留VRAM

OLLAMA_MAX_LOADED_MODELS 默认值是 GPU数量的3倍（CPU推理时为3）。而且每个模型在最后一次使用后，会继续驻留5分钟。

这正好解释了那个经典问题：「早上还能跑，下午就溢出了」——一小时前你试过的某个模型，此刻还静静地占着VRAM。用 ollama stop <model> 可以立即将其驱逐。

另一个容易被忽视的显存占用来源是开启了硬件加速的浏览器（如Chrome）、视频播放器，甚至桌面合成器。这些程序可能占用数百MB到数GB的显存，而在你查看模型大小时完全不会被考虑在内。

Ollama显存溢出的正确排查顺序

大多数人的排查顺序是反的：第一步就牺牲模型质量去降量化，结果依然溢出，因为从头到尾都没碰真正吃显存的东西。

这里补充一下量化的背景知识：量化是将模型参数从高精度浮点数（如FP16/BF16的16位）压缩到更低位宽（如8位、4位甚至2位）的技术。常见的量化格式后缀如Q4_K_M、Q5_K_S、Q8_0等，数字代表位宽，字母代表分组策略和精度保留方式。GGUF格式是目前本地部署生态中最流行的量化格式，由llama.cpp项目推动，Ollama底层正是基于llama.cpp构建的。量化的核心权衡是：位宽越低，模型文件越小、显存占用越少，但模型的表达能力和输出质量也会相应下降。因此，在其他更低代价的优化手段用尽之前就急于降量化，是典型的本末倒置。

正确的顺序应该是从代价最小的操作开始：

1. 先跑 ollama ps ——在改任何设置之前，确认你真的在溢出。
2. 停掉不用的模型（ollama stop），并检查其他程序是否占用了VRAM。开启硬件加速的浏览器是常见元凶。
3. 把上下文降到你实际需要的大小。大多数本地聊天场景根本用不到默认设置的那么多。日常对话通常2048-4096就足够，只有处理长文档或复杂多轮对话时才需要更大窗口。
4. 量化KV缓存。OLLAMA_KV_CACHE_TYPE=q8_0 大约只占f16默认值一半的内存，质量损失极小；q4_0 约为四分之一，损失稍明显。注意需要开启Flash Attention（通过设置 OLLAMA_FLASH_ATTENTION=1）。Flash Attention是由斯坦福大学Tri Dao等人提出的高效注意力计算算法，它通过分块计算（tiling）和内核融合（kernel fusion），让大部分计算在GPU的高速SRAM中完成，极大减少了对显存带宽的依赖。量化KV缓存的实现正是依赖Flash Attention的分块计算框架，因此两者需要同时启用。
5. 最后才考虑降低模型量化等级。

把宝贵的模型质量留到最后再动，才是理性的取舍。

养成查文档的习惯比记住参数更重要

说个细节，以上每一个数字都来自Ollama官方FAQ。这些默认值过去改过，将来也还会改。

这一点对所有本地AI部署者都是重要提醒——工具的默认行为在迭代中会变化，与其相信一篇几个月前的教程或帖子，不如养成查阅官方文档、亲自运行诊断命令的习惯。对于关心显存分配的用户，理解「模型权重 vs 上下文内存（KV缓存）」的区别、以及各种量化后缀（如Q4_K_M中的4代表4位量化、K代表K-quant分组策略、M代表中等精度保留）的真实含义，是本地部署绑不开的基本功。随着模型规模持续增长、量化技术不断演进（如GPTQ、AWQ、GGUF等不同量化方案各有侧重），保持对底层机制的理解，远比死记一组参数数值更有长期价值。

核心要点