Ollama 量化与显存规划指南：用公式算出你的显卡能跑多大的模型
Ollama 量化与显存规划指南
Ollama 拉模型很方便，但「该拉多大、选什么量化」没人替你算：这篇文章把显存换算公式、量化档位怎么选、装不下怎么办一次讲清楚，让你买显卡前就能算出能不能跑。
一、先搞懂模型大小：参数不是体积
很多人把「7B 模型」理解成 7GB，这是最大的误区。B 是 Billion（十亿），7B 表示模型有 70 亿个参数。参数只是神经元数量，真正占空间的，是这些参数「用什么精度存」。
模型权重的原始精度是 FP16（半精度），每个参数占 2 字节。所以一个 7B 模型的原始体积是：
1 | 7B × 2 字节 ≈ 14GB |
这还只是权重，跑起来还要算上 KV Cache（键值缓存）和运行时开销。所以「7B 模型要 14GB 显存」的说法，指的是 FP16 原版。绝大多数人用的是量化版，体积小得多，这也是 Ollama 默认帮你做的事。
为什么 Ollama 会默认用量化？因为对普通用户来说，「体积小、能装进显存、速度够快」比「理论上更准的那几个百分点」重要得多。官方库里的标签如 qwen3:8b，拉下来基本都是 Q4_K_M，体积 4.9GB 左右，8GB 显卡就能装下。
二、量化是什么：把参数从 16 位压到 4 位
量化（Quantization）就是把参数的精度降低，用更少的比特数去近似原来的数值。可以这样理解：原来每个参数用 16 位（2 字节）精确存储，量化后用 4 位（0.5 字节）去表示一个「比较接近」的值，就像把一张高清照片压缩成 JPEG——细节少了，但整体画面还在。GGUF 格式支持从 Q2 到 Q8 各种档位，Ollama 默认拉取的模型多数是 Q4_K_M。
不同量化档位每个参数占的位数：
| 量化档位 | 每参数位数 | 7B 模型体积 | 质量损失 | 适用场景 |
|---|---|---|---|---|
| Q2_K | 2.7 bit | 约 2.4GB | 明显 | 显存极度紧张，只求能跑 |
| Q3_K_M | 3.7 bit | 约 3.1GB | 中等 | 6GB 显卡最后的挣扎 |
| Q4_0 | 4.0 bit | 约 3.5GB | 较小 | 速度快，质量尚可 |
| Q4_K_M | 4.8 bit | 约 4.2GB | 小 | Ollama 默认，性价比最高 |
| Q5_K_M | 5.7 bit | 约 4.8GB | 很小 | 显存宽裕时的质量档 |
| Q6_K | 6.6 bit | 约 5.6GB | 极小 | 接近原版质量 |
| Q8_0 | 8.0 bit | 约 7.0GB | 几乎无损 | 显存充足、要保质量 |
| FP16 | 16 bit | 约 14GB | 无 | 只在评测/微调时用 |
关于质量损失的量化，很多评测做过对比：Q4_K_M 相对 FP16 的困惑度（perplexity）损失通常在 2~5% 以内，这个量级在人耳/人眼感知上很难察觉；但到了 Q2_K，损失可能超过 15%，模型会出现明显的「中文变怪、逻辑变弱、代码错误变多」。所以档位越低，代价不是线性的，而是悬崖式的——Q4 到 Q5 的差别很小，Q3 到 Q2 的差别却很大。
三、显存换算公式：一条公式打天下
核心公式其实很朴素，自己动手 30 秒能算出来：
1 | 模型显存 ≈ 参数量 × 每参数字节数 × 1.2 |
这里的 1.2 是经验系数，用来补偿 KV Cache 和运行时开销。把上表每参数字节数代进去：
7B + Q4_K_M：7 × 4.8 / 8 × 1.2 ≈ 5GB
8B + Q4_K_M：8 × 4.8 / 8 × 1.2 ≈ 5.8GB
14B + Q4_K_M：14 × 4.8 / 8 × 1.2 ≈ 10GB
32B + Q4_K_M：32 × 4.8 / 8 × 1.2 ≈ 23GB
这里再补充一个进阶概念：上下文长度也会影响显存。上面的公式假设了常见的上下文设置，但如果你的对话很长（比如 32K 上下文），KV Cache 会额外吃 24GB。所以公式里那个「1.2」系数不是铁打的，上下文开得越大，越要把系数往 1.31.4 调。
顺手把常见显卡能承载的模型档位列成表，对照你自己的显存：
| 显存 | 能装下的最大模型（Q4_K_M） | 日常推荐 |
|---|---|---|
| 6GB | 7B 勉强 / 4B 舒适 | 4B（如 Qwen3-4B） |
| 8GB | 8B 基本刚好 | 7B~8B |
| 12GB | 14B | 8B 舒服 |
| 16GB | 14B 宽敞 | 14B |
| 24GB | 32B / 30B-A3B（MoE） | 14B~32B |
| 48GB | 70B 部分档 | 32B |
怎么精确看模型实际占多少
公式给的是估算，实际占用可以精确查。Ollama 下载模型时会显示体积，运行后可以用系统工具看：
Windows：任务管理器 → 性能 → GPU → 专用 GPU 内存
Linux：
nvidia-smi看每一行的 Memory-UsagemacOS：
top或活动监视器看内存压力
跑一个模型，记下空闲时的显存和跑起来之后的显存，差值就是真实占用。这个方法比任何公式都准。
四、在 Ollama 里指定量化档位
Ollama 的模型标签里带 :q4、:q8 这种后缀，就是量化档位：
1 | ollama pull qwen3:8b # 默认 Q4_K_Mollama pull qwen3:8b-fp16 # 无量化原版（14GB+）ollama pull qwen3:8b-q5_k_m # 手动指定 Q5_K_Mollama pull qwen3:8b-q8_0 # Q8，几乎无损 |
查看某个模型有哪些量化档位可拉：
1 | ollama show qwen3:8b |
ollama show 会列出模型的基本信息，包括参数量、量化类型、上下文长度，甚至自动评估的硬件要求（比如显示「需要多少显存」）。这是个被很多人忽略的好工具，装模型前先 show 一下能避免踩坑。
如果某个档位 Ollama 官方库没有，就去 HuggingFace 找 GGUF 版本，自己导入：
1 | ollama create qwen3-8b-q6 -f Modelfile |
Modelfile 内容一行即可：
1 | FROM /path/to/qwen3-8b-q6_k.gguf |
HuggingFace 上 GGUF 文件的命名有规律：qwen3-8b-Q4_K_M.gguf、qwen3-8b-Q5_K_M.gguf 这种，大写 Q 后跟档位。挑选时认准「模型名-档位.gguf」的格式，别下错了模型版本。
五、显存不够的三个务实方案
模型拉下来发现跑不动，别急着换显卡，按顺序试这三个办法：
1. 换更低的量化档位
8GB 显卡跑 14B Q4 不行，但 Q2_K 版只有 6GB 左右，能跑起来。质量差点，总比跑不了强。这是零成本第一招。
不过要提醒：Q2_K 的 14B 在中文、代码任务上的表现可能反而不如 Q4_K_M 的 8B。所以降档有个「底线思维」——如果降到 Q3 还不行，不如换个更小的模型，质量反而更稳。
2. 减小上下文长度
KV Cache 的大小正比于上下文长度。OLLAMA_CONTEXT_LENGTH 从默认 2048 收到 1024，能省出 1~2GB。长对话场景再调回去。
1 | export OLLAMA_CONTEXT_LENGTH=1024 |
这个变量是环境变量，启动 ollama serve 之前设置才生效。如果用的是 systemd 或 docker，需要在对应的服务配置里加。短问答场景 1024 完全够用，只有长文档总结、长代码分析才需要 8K 以上。
3. 分层 Offload（GPU+CPU 混跑）
显存差一点时，可以让一部分层跑在 GPU、一部分跑在 CPU。Ollama 里这是自动的（num_gpu 参数控制，默认-1 自动判断），速度会降，但能跑。想完全掌控就用 llama.cpp，后面会专门写一篇。
分层 offload 有个反直觉的点：速度损失不完全等于「GPU 层占比」。因为 GPU 和 CPU 之间有数据交换的固定开销，层切得越碎，交换越频繁，速度掉得越狠。所以实际操作中「要么全 GPU，要么尽量多放」比「刚好够用」的层数往往更快。这个细节在 llama.cpp 篇里展开讲。
六、实测：Q4 与 Q8 到底差多少
用同一台 24GB 显卡测 Qwen3 8B，看量化对速度和质量的真实影响：
| 量化 | 体积 | 显存占用 | 输出速度 | 中文质量（人工打分） |
|---|---|---|---|---|
| Q4_K_M | 4.9GB | 6.2GB | 42 token/s | 8/10 |
| Q5_K_M | 5.5GB | 6.9GB | 41 token/s | 8.5/10 |
| Q6_K | 6.5GB | 7.8GB | 40 token/s | 9/10 |
| Q8_0 | 8.5GB | 9.9GB | 39 token/s | 9.5/10 |
| FP16 | 16GB | 17.8GB | 34 token/s | 10/10 |
结论很直白：Q4_K_M 到 Q8_0，速度基本没差，质量提升也有限；但 FP16 体积翻倍、速度还降，日常使用毫无必要。8B 这个体量，Q4_K_M 就是甜点，省下显存给 KV Cache 和更长上下文，体验反而更好。
提示：质量打分是人工试读「写一首诗 + 逻辑推理 + 代码」三组题目的主观判断，不同任务差异可能更大。代码任务对量化更敏感，追求代码质量建议至少 Q5_K_M。
分任务的量化敏感性
不同任务对量化的敏感度差别很大，值得单独展开：
| 任务类型 | 对量化敏感度 | 建议 |
|---|---|---|
| 闲聊、问答 | 低 | Q4 完全够 |
| 翻译、摘要 | 低~中 | Q4~Q5 |
| 逻辑推理、数学 | 中 | Q5 起步 |
| 代码生成、补全 | 高 | Q5_K_M 以上 |
| 结构化输出（JSON 等） | 高 | Q5~Q6 |
这个规律的核心原因：代码和结构化输出对「精确的 token 序列」要求极高，一个符号错了整个输出就废了；而闲聊只要语义对就行。所以如果你的主要任务是写代码，量化档位宁可高一点、模型小一点。
七、选模型的完整决策路径
把上面串起来，面对「我该跑什么模型」这个问题，一条路径走到底：
看显存：8GB 以下 → 4B8B；1216GB → 8B14B；24GB → 14B32B；更多 → 往 70B 想。
看任务：聊天问答用通用模型（Qwen3、Llama）；代码用 Coder 系列；长文档用大上下文版。
看量化：默认 Q4_K_M 起步，显存宽裕升 Q6，代码重度用户考虑 Q8。
装不下就降档：Q4→Q2，或者缩短上下文，再不行才考虑分层 offload。
记住一个原则：显存优先保证「模型完整装下」，其次才是追求更高的量化档位。一个 Q4 完整装进显存的 14B，永远比一个 Q8 装不下、只能 CPU 硬跑的 14B 好用。
常见的选型场景速查
| 你的情况 | 建议方案 |
|---|---|
| 8GB 显卡、日常聊天 | Qwen3-8B Q4_K_M |
| 8GB 显卡、写代码 | Qwen3-Coder-8B Q5_K_M |
| 12GB 显卡、全能 | Qwen3-14B Q4_K_M |
| 24GB 显卡、要速度要质量 | Qwen3-30B-A3B Q4（MoE） |
| 24GB 显卡、追求极致质量 | Qwen3-32B Q4（可接受略慢） |
| 32GB 内存、没独显 | Qwen3-8B Q4 纯 CPU（约 4~6 token/s） |
显存规划之外的隐性成本
除了显存，还有两个「看不见的账」会影响实际体验，很多人在买卡后才后知后觉：
第一是磁盘空间。模型文件本身不小：7B 约 5GB，14B 约 8GB，32B 约 18GB，70B 约 40GB。如果你喜欢「模型常驻多个」，300GB 的固态盘很快就满了。规划显存的同时，顺手看看磁盘剩余空间——装好几个模型，磁盘占用可能比显存还夸张。
第二是内存与 Swap。分层 offload 或纯 CPU 场景下，模型会占用系统内存（RAM）。8GB 内存的机器跑 14B 模型，内存交换（Swap）会导致速度断崖式下跌——不是慢一半，是慢十倍。所以「显存不够靠内存补」是有上限的：内存至少要有「模型体积 + 4GB 系统余量」。
这两个隐性成本的提醒很简单：规划模型方案时，把「显存 + 内存 + 磁盘」三者一起看。只盯着显存数字，装完发现跑不动，返工成本很高。
什么时候该考虑更大显存
如果你发现自己在重复这几个动作——「降量化档位 → 质量不满意 → 换小模型 → 功能不够用」，那说明显存已经成了瓶颈，该考虑升级了。反过来，如果 Q4_K_M 的 8B 已经能满足 90% 的需求，那升级显卡带来的收益很小，不如把钱花在别处。显存规划的本质是「够用就好，不迷信大」。
八、常见问题速答
Q：Ollama 拉下来的模型到底默认是哪个量化？
官方库里的模型基本默认 Q4_K_M。用 ollama show 模型名 可以在 Quantization 一栏看到确切的档位。不同模型略有差异，少数模型可能默认 Q5，下载前 show 一下最稳。
Q：同一个模型可以同时装两个量化版本吗？
可以。qwen3:8b 和 qwen3:8b-q8_0 是两条独立标签，互不覆盖，只是磁盘上各占一份空间。想省空间就只留一个。
Q：量化会影响「推理准确性」以外的能力吗？
量化主要影响输出的「精确度」，对话流畅度、长文本组织这类「语义级」能力几乎不受影响。但数学计算、代码输出这类「必须精确」的任务会受明显影响，这就是前文「分任务敏感性」一节想说明的。
Q：显存数字够了，为什么启动还是报错？
报错通常是「显存刚好够，但上下文 + 运行时超过了」。把上下文从 8K 收到 2K，或者给 OLLAMA_CONTEXT_LENGTH 设小，90% 的 OOM 都能解决。
Q：有必要上 Q8 或 FP16 吗？
除非你是做评测、微调，或者对输出精确度有极其严格的要求，否则没必要。Q4_K_M 到 Q6_K 覆盖了 99% 的使用场景，省下的显存换成更长上下文，收益更大。
小结
量化的本质是用精度换体积，Q4_K_M 是大多数人的甜点；显存公式「参数量 × 每参数字节数 × 1.2」30 秒能算出任何模型占多少；装不下的优先级是「降档 → 缩上下文 → 分层 offload」。把这三点吃透，选显卡、选模型都不再靠猜。规划时把显存、内存、磁盘一起算进去，就能避开大多数「装完跑不动」的坑。
延伸阅读：
