想在自己机器上跑大模型，第一个问题永远是「我这卡能跑多大」。网上的答案从「7B 要 14G」到「7B 4G 就够」都有，都不算错——因为它们说的不是同一件事。
显存占用由三块组成，只有第一块跟参数量直接相关。
一、显存 = 权重 + KV cache + 框架开销
显存 ≈ 参数量 × 每参数字节 × 1.1 + KV cache + 0.5～1.5 GB
└────── 权重 ──────┘ └─ 上下文 ─┘ └─ 运行时 ─┘
三块的特点完全不同：
| 部分 | 由什么决定 | 会不会随时间增长 |
|---|---|---|
| 权重 | 参数量 × 量化精度 | 不变 |
| KV cache | 上下文长度 × 层数 × 头数 | 随对话变长持续增长 |
| 框架开销 | 推理框架、批大小 | 基本固定 |
多数人的估算只算第一块，然后就遇到了「模型加载成功，一问长文档就 OOM」。
二、第一笔账：权重
每参数字节取决于量化精度：
| 精度 | 每参数字节 | 7B 实际大小 | 质量损失 |
|---|---|---|---|
| FP16 / BF16 | 2.0 | 约 14 GB | 无（原始精度） |
| INT8 / Q8 | 1.0 | 约 7 GB | 几乎无损 |
| Q6_K | 0.8 | 约 5.8 GB | 极小 |
| Q5_K_M | 0.7 | 约 4.9 GB | 很小 |
| Q4_K_M | 0.55 | 约 4.2 GB | 小，性价比最高 |
| Q3_K_M | 0.45 | 约 3.4 GB | 明显下降 |
| Q2_K | 0.35 | 约 2.6 GB | 严重退化，不建议 |
注意 Q4 为什么是 0.55 而不是 0.5：量化除了存权重，还要存每组权重的缩放系数（scale）和零点（zero point），这部分开销随 group size 变化，实际约多出 10%。
Q4_K_M 是绝大多数场景的默认选择。 相比 FP16 省 73% 显存，质量损失在多数任务上感知不到；再往下压到 Q3，回答质量会肉眼可见地变差，尤其是数学和代码。
三、第二笔账：KV cache，这才是隐形大头
KV cache 是模型为了「记住上文」而缓存的中间结果。它的公式：
每 token 的 KV 字节 = 2 × 层数 × KV头数 × head维度 × 每元素字节
乘上上下文长度，就是总占用。
以三个常见模型为例（FP16 精度的 KV）：
| 模型 | 层数 | KV 头数 | head 维度 | 每 token | 8K 上下文 | 32K 上下文 |
|---|---|---|---|---|---|---|
| Llama-3-8B | 32 | 8 (GQA) | 128 | 128 KB | 1.0 GB | 4.0 GB |
| Qwen2.5-7B | 28 | 4 (GQA) | 128 | 56 KB | 0.45 GB | 1.8 GB |
| Llama-3-70B | 80 | 8 (GQA) | 128 | 320 KB | 2.5 GB | 10 GB |
两个结论：
一、架构差异比参数量差异更大。 Qwen2.5-7B 的 KV 头只有 4 个（GQA 压得更狠），每 token 的 KV 只有 Llama-3-8B 的 44%。所以「7B 和 8B 差不多」在长上下文场景下完全不成立。
二、70B 在 32K 上下文下，光 KV 就要 10GB。 这是很多人算漏的部分：70B Q4 权重 40GB，加 32K 上下文的 10GB，再加开销，48GB 的卡直接不够。你以为「70B Q4 刚好塞进 48G」，实际只能跑 8K 上下文。
老一代模型用的 MHA（每个头都有独立 KV）更夸张：Llama-2-70B 的每 token KV 是 2.5MB，8K 上下文就 20GB。GQA / MQA 这类架构改进，对长上下文的内存节省是数量级的。
KV cache 也能量化
# llama.cpp：KV cache 用 8 位存，直接省一半
./llama-server -m model.Q4_K_M.gguf --cache-type-k q8_0 --cache-type-v q8_0 -c 32768
Q8 的 KV 量化质量损失极小，几乎无感；Q4 的 KV 量化在长上下文下会有可感知的退化，但能省 75%。上下文吃紧时，优先量化 KV，而不是把权重降到 Q3。
四、合起来算：常见配置的实际需求
按「权重 × 1.1 + KV(8K) + 1GB 开销」算：
| 模型 + 量化 | 权重 | KV(8K) | 合计 | 最低卡 |
|---|---|---|---|---|
| 7B Q4_K_M | 4.6 | 1.0 | 约 6.6 GB | 8 GB 勉强 |
| 7B Q4 + 32K | 4.6 | 4.0 | 约 9.6 GB | 12 GB |
| 8B Q8 | 8.8 | 1.0 | 约 10.8 GB | 12 GB |
| 14B Q4_K_M | 9.4 | 1.2 | 约 11.6 GB | 12 GB 紧 |
| 14B Q4 + 32K | 9.4 | 4.8 | 约 15.2 GB | 16 GB |
| 32B Q4_K_M | 20.5 | 1.5 | 约 24.1 GB | 24 GB（几乎占满） |
| 32B Q4 + 16K | 20.5 | 3.0 | 约 26 GB | 32 GB |
| 70B Q4_K_M | 42 | 2.5 | 约 49 GB | 48 GB 不够 |
| 70B Q4 + 4K | 42 | 1.25 | 约 47.5 GB | 48 GB 刚好 |
「刚好」这两个字很危险。显存占用到 95% 以上时，推理框架会开始碎片化分配失败，实际表现是随机 OOM。留 10%～15% 余量是硬要求。
直接算：
👉 在线计算器
五、消费级显卡能跑什么
| 显存 | 典型卡 | 舒适区 | 极限 |
|---|---|---|---|
| 8 GB | RTX 3060 Ti / 4060 | 7B Q4，8K 上下文 | 8B Q4，4K |
| 12 GB | RTX 3060 12G / 4070 | 14B Q4，8K | 8B Q6，32K |
| 16 GB | 4060 Ti 16G / 4080 | 14B Q5，16K | 32B Q4，4K（很紧） |
| 24 GB | 3090 / 4090 | 32B Q4，16K | 14B Q8，32K |
| 48 GB | 2×24G / A6000 | 70B Q4，8K | 32B Q8，32K |
| 80 GB | A100 80G | 70B Q8，32K | 70B Q4，128K |
两卡的组合有个坑：张量并行要求模型能均分到两张卡，实际可用显存不是简单相加，第二张卡的利用率通常低 10%～20%。24G × 2 跑 70B Q4（需 49G）会很紧张。
六、显存不够怎么办：四条路，按代价排
| 方案 | 速度 | 适用 |
|---|---|---|
| 降量化（Q4 → Q3） | 不变 | 最省事，但质量掉 |
| 降上下文（32K → 8K） | 不变 | 语义任务够用 |
| KV cache 量化 | 略降 | 性价比最高 |
| 部分层卸载到 CPU 内存 | 慢 5～10 倍 | 应急，不能常用 |
CPU 卸载（--n-gpu-layers 调小）是最后的办法。现代推理框架在「显存 + 内存」混合模式下能跑起来，但每生成一个 token 都要走 PCIe 搬运，速度从几十 tok/s 掉到几 tok/s，交互体验基本不可用。
Mac 的统一内存是个例外：M 系列的内存和显存共享，128GB 的 Mac Studio 能跑 70B Q4。代价是内存带宽低（M2 Ultra 约 800 GB/s，M4 Max 约 546 GB/s），比 4090 的 1008 GB/s 慢，但比 CPU 卸载快得多。
七、怎么估生成速度
decode 阶段（一个接一个吐 token）是内存带宽瓶颈，不是算力瓶颈。粗算：
理论 tok/s ≈ 显存带宽 ÷ 模型字节数
| 卡 | 带宽 | 7B Q4 (4.2GB) | 32B Q4 (20.5GB) |
|---|---|---|---|
| RTX 4090 | 1008 GB/s | 240（实际 80～120） | 49（实际 20～30） |
| RTX 3090 | 936 GB/s | 223（实际 70～110） | 46（实际 18～28） |
| RTX 4060 Ti | 288 GB/s | 69（实际 30～45） | 14（跑不动） |
| M2 Ultra | 800 GB/s | 190（实际 50～70） | 39（实际 15～22） |
理论值要打 3～5 折，因为实际还有 attention 计算、采样、调度开销。这个公式最大的价值是判断「值不值得升级显卡」：换带宽更高的卡，速度线性提升；换显存更大但带宽一样的卡，只解决「能不能跑」，不解决「快不快」。
八、几个实际踩过的坑
模型加载成功但一问就 OOM。 原因是只算了权重，没算 KV。先看框架日志里的实际显存分配，再对照上面的表。
上下文设 32K，实际只能用到 8K。 有些框架的 -c 参数是「总上下文」，要同时容纳输入和输出。设 32768 实际输入只能给 24K 左右。
多轮对话越聊越慢、最后崩。 KV cache 一直在涨，不会自动回收。要么限制历史轮数，要么定期重启会话。
量化格式选错导致速度差一倍。 GGUF 适合 CPU / 混合推理，GPTQ / AWQ 适合纯 GPU，EXL2 适合极致低比特。同一模型换格式，速度能差 2 倍。
小模型 + 长上下文 ≠ 大模型。 7B 塞 128K 上下文，虽然塞得进去，但「中间信息丢失」（lost in the middle）非常严重，长文档问答准确率会崩。上下文窗口大，不代表能用好。
九、速查
权重显存 ≈ 参数量(B) × 每参数字节 × 1.1
FP16: 2.0 Q8: 1.0 Q6: 0.8
Q5: 0.7 Q4: 0.55 Q3: 0.45
每 token KV 字节 = 2 × 层数 × KV头数 × head维度 × 2
总显存 ≈ 权重 + KV × 上下文长度 + 1GB，再留 15% 余量
速度 ≈ 带宽 ÷ 模型字节数 × 0.25
记住一句：参数量决定「装不装得下」，上下文长度决定「能聊多久」，显存带宽决定「快不快」。 三个问题，三个变量，别用一个数字回答。