Ollama 跑不动模型？先算一下显存到底要多少

下载了一个模型，运行起来要么报错，要么慢得没法用。

网上查，答案往往是"显存不够"。但多少才算够？ 很少有人给出可计算的方法。

其实 Ollama 这笔账不难算。搞清楚占显存的到底是哪几部分，选模型时心里就有数了。

显存用在三个地方

推理时，显存主要被三样东西占用：

• 模型权重：模型文件本身，占大头
• KV Cache：对话上下文的缓存，随对话变长而增长
• 运行时开销：计算中间值、框架本身的占用

后两项容易被忽略，但它们是"明明模型能装下，运行却报错"的常见原因。

第一部分：权重，看量化和参数量

这部分最好算。

权重的体积 = 参数量 × 每个参数占用的字节数。

"每个参数占多少字节"，由量化等级决定：

• FP16 / BF16（每参数字节：2 字节；说明：原始精度）
• INT8 / Q8（每参数字节：1 字节；说明：压缩一半）
• INT4 / Q4（每参数字节：约 0.5 字节；说明：压缩到四分之一）

所以一个 7B 参数的模型：

• FP16 精度：7 × 2 ≈ 14 GB
• Q8 精度：7 × 1 ≈ 7 GB
• Q4 精度：7 × 0.5 ≈ 3.5 GB

量化做的事，就是用更少的位数来表示同一个参数。

这是为什么同一个模型，不同版本的文件大小能差好几倍。

量化为什么能用

把 16 位的浮点数压到 4 位，听起来精度损失很大。

但实际效果没那么糟，因为不是所有参数都平均地砍。

主流的 K-Quants 方案（比如常见的 Q4_K_M）采用的是分组量化：

1. 把权重切成小块
2. 每一块单独计算缩放系数
3. 根据这一块的数据分布来分配精度

对于数值集中的部分用较少的位数，对分布特殊的部分保留更多信息。

这样比"一刀切"地压缩，精度损失小得多。

实际体验是：Q4 量化的模型，体积只有 FP16 的三分之一左右，但生成质量下降通常不明显。

第二部分：KV Cache，容易被低估

这部分是很多人算漏的地方。

模型处理对话时，需要把上下文的历史信息缓存起来——这就是 KV Cache。

它的特点是：随上下文长度线性增长。

大致关系是：

KV Cache ≈ 2 × 层数 × KV头数 × 头维度 × 序列长度 × 字节数

不用记这个公式，记住一个结论就够了：

上下文开得越大，KV Cache 涨得越快。

举个例子：一个 8B 模型，在 4K 上下文下 KV Cache 可能只占几百 MB；但如果开到 32K，这部分就会涨到几个 GB。

这就是为什么"模型明明装得下，对话一长就崩" ——增长的是 KV Cache，不是权重。

另外一个影响因素是模型架构：

• MHA（多头注意力）：每个注意力头都有独立的 KV，占用大
• GQA（分组查询注意力）：多个查询头共享一组 KV，占用小得多

现在的模型大多用 GQA，这也是同样参数量下，新模型比老模型更省显存的原因之一。

第三部分：留出余量

权重和 KV Cache 加起来，还不是最终数字。

实际还要加上 10%–20% 的余量，用于：

• 推理过程中的中间计算结果
• 框架自身的显存开销
• 避免临界值附近触发 OOM

按 1.2 倍估算比较稳妥。

完整算一遍

以常见的配置为例：8B 模型 %2B Q4 量化 %2B 4K 上下文。

• 权重：8 × 0.5 ≈ 4 GB
• KV Cache：约 0.5 GB
• 小计：4.5 GB
• 加 20% 余量：≈ 5.4 GB

结论：6GB 显存基本够用，8GB 比较从容。

如果换成 FP16 精度，权重直接变成 16GB，8GB 显卡就跑不动了。

怎么确认实际占用

算完是估算，实际跑起来可以用命令看。

查看运行状态

Ollama 提供了 ollama ps 命令，能看到当前模型的加载情况：

ollama ps

输出里有一列 PROCESSOR，显示模型的加载分布：

• 100% GPU：全部加载到显存，速度最快
• 100% CPU：全在内存里跑，慢
• 48%/52% 这类比例：部分在显存、部分在内存

看到混合比例，说明显存不够装下全部，多出来的层回退到内存处理了。

这种情况下速度会明显下降——原因在下一节。

为什么混合加载会慢

内存带宽远低于显存带宽。

当模型被拆到两处，数据需要在显存和内存之间来回搬运。每次推理都要搬，瓶颈就卡在这条通道上。

所以"能跑起来"和"跑得动"是两回事。 一个模型被切分后虽然能出结果，但速度可能是全 GPU 加载的几分之一。

显存不够时的四个调整方向

按调整成本从低到高排。

方向一：换更小的量化版本

这是最直接的。

同一个模型，Q4 版本比 Q8 版本省一半显存，比 FP16 省四分之三。

如果是显存吃紧，优先考虑 Q4 级别的量化，比如常见的 Q4_K_M。这是体积和质量之间比较平衡的一档。

方向二：调低上下文长度

如果显存够装权重，但对话长了就崩，问题多半在 KV Cache。

降低上下文长度能直接压缩这部分占用。对于简单问答类任务，不需要开很大的上下文。

在对话中可以用这个命令调整：

/set parameter num_ctx 4096

方向三：控制加载到 GPU 的层数

如果显存实在不足，可以有意识地让一部分层留在 CPU 上。

/set parameter num_gpu 20

参数含义是"加载到 GPU 的层数"：数值越小，显存占用越低，但速度越慢。

这是在"跑不动"和"跑得慢"之间的取舍 ——有时候慢一点能用，比完全用不了好。

方向四：换更小的模型

如果上面都试过还是不行，说明这个尺寸的模型不适合这块显卡。

降一档参数规模（比如从 8B 换到 3B），往往比硬撑着调参数更实际。

让参数固定下来

上面那些 /set 参数只在当前会话有效，退出就没了。

如果每次都要用同样的配置，可以写进 Modelfile。

先导出现有模型的配置：

ollama show 模型名 --modelfile > Modelfile

然后编辑这个文件，加上参数行：

FROM 模型名

PARAMETER num_ctx 4096

PARAMETER num_gpu 20

最后基于这个文件创建一个自定义模型：

ollama create 我的模型 -f Modelfile

以后直接运行这个自定义模型，参数就是配置好的。

一句总结

"这个模型能不能跑"，是可以提前算出来的。

权重看参数量乘量化位数，KV Cache 看上下文长度，再留两成余量——加起来的数字，和你的显存比一比就有答案了。

比下载完再报错，省事得多。

Ollama 把这些复杂度封装成了几条命令，但底层跑的还是这套账。

安装包：

https://dubapkg.cmcmcdn.com/cs/257def/ollama.exe