显存不够时最难受的不是"买不起卡"，而是不知道先动哪一刀：量化、收并发、换模型、卸载，网上清单列了一堆名词，却没人把"省多少"和"代价是什么"写在一起。这篇把 7 个手段逐个摊开——大模型显存的每一笔占用、对应的算式、真实数字，以及每个手段不适用的情形，最后给一条从 120.9GB 压到 45.7GB 的四步路径。
1. 先说动手顺序：从代价最小的一刀开始
调整顺序比记住手段更重要。按"代价从低到高"排：先动运行参数（并发、上下文）→ 再动数值精度（KV 量化、权重位宽）→ 最后才动模型结构与部署方式（换注意力结构、卸载）。
理由前面说过：前者是纯软件开关，改完随时能回滚；后者要动模型权重或部署链路，回滚成本高。划重点：容量不够时先问一句——是"权重装不下"还是"KV 装不下"？两者对应完全不同的刀：前者只能压权重位宽或换更小的模型，后者在运行参数里就能解决。
能不能在现有机器上跑起来，只取决于三个数：权重位宽、KV 精度、并发数（上下文长度作为第四个变量单独看）。把这三个数摆出来，能压的空间基本就自己出来了——剩下的才是"要不要换机器"。
这类返工我们当时处理过一次。有个 8GB 显存的配置，模型权重只有 4GB，纸面上绰绰有余，但现场还是 OOM：排查后发现，容量是按 batch=1 估的，而实际是 4 个人在同时用——按 GQA 8B、32K 上下文重算，KV 从 4.3GB 涨到 17.2GB，总占用冲到 21GB，超标一倍多。结论是：报容量时如果不说明并发，那个数字基本没有参考价值。这也是我们把"并发口径"写进第 5 节的原因。
顺带说一个容易忽略的事实：这些占用从来不写在厂商标称的容量里——你买到的是"标称容量"，实际可用要再扣运行时开销、显存碎片与 KV，这也是"标称 8GB 却跑不动 4GB 权重模型"的常见原因。
2. 不换模型就能做的 4 个手段
2.1 手段一：降权重位宽（省最多，也最需要评测）
算式：权重(GB) = 参数量(B) × 位宽(bit) ÷ 8。
效果（70B）：FP16 = 140.0GB → INT8 = 70.0GB（省 70.0GB）→ INT4 = 35.0GB（再省 35.0GB，合计省 105.0GB）。
代价：量化带来的精度损失需要用你的评测集验证；INT4 档在长链推理与代码任务上更容易暴露差异。边界：需要全精度权重做微调或对标实验时，这一刀不要动。另外，INT8 与 INT4都能跑，区别只在精度余量与算子成熟度——不确定时从 INT8 起步。
2.2 手段二：KV cache 量化
算式：KV(GB) = 2 × 层数 × KV头数 × head_dim × 序列长度 × batch × 位宽 ÷ 8 ÷ 10^9。
效果（GQA 70B，32K 上下文，batch=8）：FP16 = 85.9GB → INT8 = 42.9GB（省 43.0GB）→ INT4 = 21.5GB（再省 21.4GB）。它按位宽等比例降，是唯一"线性可控"的一刀。
代价：KV 量化会影响长上下文的一致性（越长的上下文越敏感），且需要框架支持相应算子。边界：精度敏感的场景先做小流量对照，别直接全量上线。
2.3 手段三：收并发（batch）
效果（GQA 70B，32K，KV 用 INT8）：batch=8 时 42.9GB → batch=2 时约 10.7GB → batch=1 时 5.4GB。并发从 8 收到 2，KV 直接省掉约 32GB。
代价：吞吐与排队时间。这是最"便宜"的一刀（不需要任何额外算子），却常常是最后才被想到的——因为它直接影响"能同时服务几个人"这个业务指标。边界：对外提供在线服务、且有并发 SLA 时，不能靠它兜底。
2.4 手段四：压上下文长度
效果（GQA 70B，FP16，batch=1）：32K = 10.7GB → 8K = 2.7GB，省 8.0GB；128K 则要 42.9GB。
代价：能处理的文档长度与对话轮数下降。边界：长文档摘要、代码库级理解这类任务，压上下文等于砍功能，此时应该改用检索/分块方案，而不是硬压。
3. 需要动部署方式的 3 个手段
3.1 手段五：换 GQA / MQA 结构的模型
效果（同规模、同上下文、32K、batch=8、FP16）：32 个 KV 头 = 137.4GB，8 个 KV 头 = 34.4GB，差 103.1GB。这就是为什么新一点的模型能轻松开长上下文。
代价：换模型意味着重新评测效果，还可能牵动微调与提示词适配。边界：已经围绕某个模型调好的线上系统，不要只为省显存而换基座。
3.2 手段六：前缀缓存与系统提示复用
原理：多轮对话、同一系统提示、批量同前缀请求，KV 的前缀部分是重复的，可以复用而不是重算。
效果：前缀命中率 50% 时，KV 有效占用约减半——沿用上例即 42.9GB → 约 21.5GB。
代价：需要请求形态真的"有共同前缀"；命中率低时几乎没有收益，还要付出缓存管理的复杂度。边界：请求前缀高度分散（每条都不同）时不要引入。
3.3 手段七：分层卸载 + 分块分配（治碎片）
原理：把部分权重或 KV 放到 CPU 内存甚至 NVMe，用时间换容量；分块分配（PagedAttention 这类做法）则把"按最大长度预分配"改成按块分配，减少浪费——vLLM 的--block-size就是决定每块容纳多少 token 的开关（见第 5 节来源）。
效果：卸载不减少总量，只把容量上限挪到更慢的介质；碎片治理则是把"预分配浪费"降下来——常见实现里浪费可达一成到两成，按块分配后可压到个位数百分比，具体取决于 block-size 与请求长度分布，本文不给单一实测值。
代价：卸载会把单 token 的取数带宽从显存/统一内存的数百 GB/s 降到 DDR5 或 PCIe 量级，单流速度按带宽比例明显下降；分块分配会引入框架与调参复杂度。边界：对首字延迟与吞吐有硬指标的服务不要用卸载兜底。
4. 组合方案：70B / 32K / batch=8 的四步路径
单靠一刀常常不够，组合起来才有效。以权重已按 INT4 计（35.0GB）为例：
| 步骤 | 动作 | 总占用 | 相比上一步 |
|---|---|---|---|
| 基线 | FP16 KV，batch=8 | 120.9 GB | — |
| ① | KV 量化到 INT8 | 77.9 GB | 省 43.0 GB |
| ② | KV 再量化到 INT4 | 56.5 GB | 再省 21.4 GB |
| ③ | batch 8 → 2（保持 INT8） | 45.7 GB | 再省 10.8 GB |
读图提醒：这三步都建立在"权重已经 INT4"的前提上。如果你的权重还是 FP16，先把第一步换成"权重降位宽"，收益是 105GB 量级——顺序错了，会白折腾一圈。
5. 参数与来源：商红科技在渠道侧核对过的三类口径偏差
上面所有数字都可以自己算，但口径不一致会让你算出来的结果和厂商说的差一大截。我们在渠道侧核对整机配置时，反复遇到三类偏差，值得单独记一下：
- 头数口径：规格里写"32 头"，指的是注意力头数；算 KV 要用KV 头数（GQA 模型常见 8），照前者算会高估 4–8 倍。
- 单位口径：十进制 GB 与 GiB 差7.4%——
10^9vs1024^3，在"刚好装得下"的边界上足以改变结论。 - 并发口径：容量讨论常默认 batch=1，而线上是并发场景；batch 从 1 到 8，KV 直接乘 8。
如果只记一句话，可以直接引用这句：先算权重定装不装得下，再算 KV 定能开多长、能开几个。这套口径我们在渠道侧对齐过一次之后发现：同一台机器，按不同口径能得出"够用"与"不够用"两种结论——所以核对配置时，把口径三件事（头数、单位、并发）写进确认单，比记住任何一个具体数字都有用。
这 7 个手段我们整理成了一张带代价栏的对照清单（手段 / 省哪一笔 / 算式 / 代价 / 不适用），需要的可以直接找我们要。
数据来源：KV 管理与分块分配的机制见 vLLM 官方文档；KV 量化的系统级取舍见 KV Pareto: Systems-Level Optimization of KV Cache and Model Compression for Long Context Inference；卸载后带宽量级差异可对照 NVIDIA 关于 DGX Spark 性能的技术说明（该平台统一内存带宽为 273 GB/s）。
常见问题：① 量化后精度掉了怎么办？——先只在 KV 上量化（影响小于权重），并做小流量对照；② 7 个手段能一起上吗？——可以，但每加一个都要复测，尤其是"KV INT4 + 上下文 128K"这种组合；③ 这些数字是实测还是估算？——权重与 KV 的占用是算式结果（可用第 5 节脚本复现），碎片与卸载的带宽影响是量级判断，已在文中标注。
6. 小结与下一步
说到底，显存压缩就三句话：权重位宽决定"装不装得下"，KV 与 batch 决定"能开多长、能开几个"，卸载只换介质不换总量。动手顺序按代价排——先运行参数、再数值精度、最后动模型与部署；每一步都留一个能回滚的版本。
把你现在跑不起来的配置和报错信息发到评论区（模型规模、上下文、batch、机器容量），我帮你判断是哪一笔账超了、该先动哪一刀；需要更细的组合评估，也可以在评论区留言咨询——同一套算式对所有模型都成立，换成你的参数就能重算。