“我这显卡能跑 32B 吗？“这是本地部署问得最多的问题。答案不用背表格——显存需求由三块组成：模型权重、上下文的 KV cache、运行开销，每块都能算出来。这篇把这笔账拆开算清楚，再给出买卡和下模型前的决策规则。
场景与需求
显存测算服务三类场景：
- 买卡前：预算定了，想知道 12GB 和 16GB 的分界线能换来哪档模型；
- 下模型前：卡已在手，判断某个模型是”流畅跑”还是”勉强跑”；
- 跑起来不对劲：速度突然变慢、报错显存不足，定位是权重、KV cache 还是系统占用出了问题。
对应的产出是一张测算表加一套决策规则，照着对号即可。
候选方案
显存不够时，本质只有四条路，按代价从小到大排：
| 路线 | 做法 | 代价 |
|---|---|---|
| 压上下文 | 调小 num_ctx，少喂长文 | 长对话、长文档能力下降 |
| 量化 KV cache | 开 q8_0 KV cache，KV 体积减半 | 精度损失极小，最便宜的省显存手段 |
| 降量化等级 | 模型从 Q8 换 Q4（默认已是 Q4） | 同参数量下体积近似减半，质量轻微下滑 |
| 换小参数量模型 | 32B 换 14B | 能力台阶式下降，但换来成倍余量 |
Ollama 还有一条”自动兜底”：显存放不下的层自动卸载到 CPU 内存，模型照样能跑，只是速度明显变慢【待补：本机全显存与部分卸载的实测速度对比】。所以”能不能跑”和”跑得爽不爽”是两道门槛，测算时分开看。
测算模型与假设
权重显存：参数量 × 每参数字节数
显存大头是模型权重，近似公式：权重显存 ≈ 参数量(B) × 每参数字节数。常见量化等级的换算结果：
| 参数量 | fp16（2 字节/参数） | Q8_0（约 1 字节/参数） | Q4_K_M（约 0.57 字节/参数） |
|---|---|---|---|
| 3B | 约 6GB | 约 3GB | 约 2GB |
| 7B | 约 14GB | 约 7.5GB | 约 4.5GB |
| 14B | 约 28GB | 约 15GB | 约 9GB |
| 32B | 约 64GB | 约 34GB | 约 20GB |
| 70B | 约 140GB | 约 75GB | 约 42GB |
Ollama 库默认分发的就是 4bit 量化（Q4_K_M 一类），这正是消费级显卡能跑 7B 以上模型的全部前提——一张 8GB 卡当然装不下 14GB 的 fp16 权重，但装得下 4.5GB 的 Q4。
KV cache：随上下文长度线性涨
权重之外的第二大头。近似公式：KV cache 字节数 ≈ 2 × 层数 × KV维度 × 上下文长度 × 每元素字节数（2 是 K 和 V 两份）。以 7B 级模型（采用 GQA 分组注意力）为例：上下文 4K 时约 0.20.5GB，32K 时涨到约 24GB。参数量越大层数越多，同一上下文下 KV cache 也越大。
两个可以直接抄的省显存开关：开启 flash attention，并把 KV cache 量化到 q8_0（体积减半、精度损失可忽略）：
# Windows（设完重启 Ollama 生效）
setx OLLAMA_FLASH_ATTENTION "1"
setx OLLAMA_KV_CACHE_TYPE "q8_0"
# macOS
launchctl setenv OLLAMA_FLASH_ATTENTION 1
launchctl setenv OLLAMA_KV_CACHE_TYPE q8_0
# Linux（服务版）：systemctl edit ollama.service 加 Environment= 后 daemon-reload 重启运行开销与总账
框架与运行时开销约 0.30.8GB；显卡如果同时在渲染桌面，再留 0.51.5GB 给系统。总账公式：
所需显存 ≈ 权重 + KV cache + 开销 + 系统占用
注意 Ollama 默认上下文只有 2048，要长上下文必须显式调大 num_ctx，KV cache 的账要按调大后的值算。交互里临时调：
ollama run qwen2.5:7b
>>> /set parameter num_ctx 8192两个容易误判的点
- “共享显存”救不了速度。 Windows 上 NVIDIA 驱动允许把部分内存借作显存（任务管理器里的”共享 GPU 内存”），看似上限翻了倍，实际带宽差一个量级，一借就开始明显掉速——测算时只认专用显存【待补：本机触发共享显存后的实测掉速幅度】。
- Mac 的统一内存是另一套账。 Apple Silicon 没有独立显存，GPU 与 CPU 共用统一内存，GPU 默认可用上限约为物理内存的七成上下；16GB 内存的 MacBook 实际能伺候 7B~8B 级的 Q4 模型【待补：实测上限与速度】。
测算结果表
把三块加总，得到 Q4 量化下”流畅跑”的显存档位（按常用 4K 上下文估算）：
| 参数量 | 权重（Q4） | 4K 上下文 KV | 总需求量级 | 32K 上下文再 + KV |
|---|---|---|---|---|
| 3B | 约 2GB | 约 0.1~0.2GB | 2~3GB | 约 +1~2GB |
| 7B | 约 4.5GB | 0.2~0.5GB | 5~8GB | 约 +2~4GB |
| 14B | 约 9GB | 约 0.5~1GB | 9~12GB | 约 +3~6GB |
| 32B | 约 20GB | 约 1~2GB | 20~24GB | 约 +6~12GB |
| 70B | 约 42GB | 约 2~4GB | 44GB 以上 | 建议直接双卡 |
读表规则：显存 ≥ 总需求约 1.1 倍算”流畅”档；显存低于总需求但超过权重大半，Ollama 会自动卸载部分层，属于”勉强”档；显存连权重都装不下一半，直接换小参数量模型。
决策框架
- 先算权重账，再算上下文账。 权重装不下一切免谈；权重装得下，上下文不够就压 num_ctx。
- 长上下文需求先开两个开关：OLLAMA_FLASH_ATTENTION 与 q8_0 KV cache，零成本省一半 KV 显存。
- 缺口 1~2GB 以内：压上下文或量化 KV cache 就能解决；缺口更大：换小一档参数量，不要硬扛部分卸载——能跑和流畅是两回事。
- 同参数量下换量化：默认 Q4 想提质量可试 Q8，代价是体积近似翻倍，8GB 卡跑 7B 的 Q8 已经贴线。
- 无独显也能跑：CPU + 内存路线，内存需求 ≈ 模型文件体积的 1.2 倍左右，速度比独显慢一个量级【待补：本机 CPU 路线的实测速度】，只适合不赶时间的批处理场景。
- 多卡不叠加显存跑同一个模型？会拆分。 Ollama 支持把模型分层拆到多块 GPU 上，两张 24GB 卡能伺候 70B 级的 Q4，但单卡能装下的模型没有必要拆，拆分本身有通信开销。
一句话记忆：Q4 权重体积 ×1.2 加上 KV cache，就是你要的显存。7B≈58GB、14B≈912GB、32B≈20~24GB 这三档背下来，能覆盖九成问答场景。
我的最终选择
我自己的配置与实测：【待补：显卡型号、实际运行模型档位、显卡驱动版本、实测 tokens/s 与显存占用截图】。通用建议：个人开发机 12GB 显存是入门甜点位（流畅跑 14B），24GB 是一步到位的选择（流畅跑 32B），16GB 适合长上下文重度用户。
显存测算完了就该挑具体型号，清单见按显存选型的模型推荐；模型装在哪、怎么搬家，见模型目录迁移。