显存不够时最难受的不是买不起卡而是不知道先动哪一刀量化、收并发、换模型、卸载网上清单列了一堆名词却没人把省多少和代价是什么写在一起。这篇把 7 个手段逐个摊开——大模型显存的每一笔占用、对应的算式、真实数字以及每个手段不适用的情形最后给一条从 120.9GB 压到 45.7GB 的四步路径。1. 先说动手顺序从代价最小的一刀开始调整顺序比记住手段更重要。按代价从低到高排先动运行参数并发、上下文→ 再动数值精度KV 量化、权重位宽→ 最后才动模型结构与部署方式换注意力结构、卸载。理由前面说过前者是纯软件开关改完随时能回滚后者要动模型权重或部署链路回滚成本高。划重点容量不够时先问一句——是权重装不下还是KV 装不下两者对应完全不同的刀前者只能压权重位宽或换更小的模型后者在运行参数里就能解决。能不能在现有机器上跑起来只取决于三个数权重位宽、KV 精度、并发数上下文长度作为第四个变量单独看。把这三个数摆出来能压的空间基本就自己出来了——剩下的才是要不要换机器。这类返工我们当时处理过一次。有个 8GB 显存的配置模型权重只有 4GB纸面上绰绰有余但现场还是 OOM排查后发现容量是按 batch1 估的而实际是 4 个人在同时用——按 GQA 8B、32K 上下文重算KV 从 4.3GB 涨到 17.2GB总占用冲到 21GB超标一倍多。结论是报容量时如果不说明并发那个数字基本没有参考价值。这也是我们把并发口径写进第 5 节的原因。顺带说一个容易忽略的事实这些占用从来不写在厂商标称的容量里——你买到的是标称容量实际可用要再扣运行时开销、显存碎片与 KV这也是标称 8GB 却跑不动 4GB 权重模型的常见原因。2. 不换模型就能做的 4 个手段2.1 手段一降权重位宽省最多也最需要评测算式权重(GB) 参数量(B) × 位宽(bit) ÷ 8。效果70BFP16 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 70B32K 上下文batch8FP16 85.9GB → INT8 42.9GB省 43.0GB→ INT4 21.5GB再省 21.4GB。它按位宽等比例降是唯一线性可控的一刀。代价KV 量化会影响长上下文的一致性越长的上下文越敏感且需要框架支持相应算子。边界精度敏感的场景先做小流量对照别直接全量上线。2.3 手段三收并发batch效果GQA 70B32KKV 用 INT8batch8 时 42.9GB → batch2 时约 10.7GB → batch1 时 5.4GB。并发从 8 收到 2KV 直接省掉约 32GB。代价吞吐与排队时间。这是最便宜的一刀不需要任何额外算子却常常是最后才被想到的——因为它直接影响能同时服务几个人这个业务指标。边界对外提供在线服务、且有并发 SLA 时不能靠它兜底。2.4 手段四压上下文长度效果GQA 70BFP16batch132K 10.7GB → 8K 2.7GB省 8.0GB128K 则要 42.9GB。代价能处理的文档长度与对话轮数下降。边界长文档摘要、代码库级理解这类任务压上下文等于砍功能此时应该改用检索/分块方案而不是硬压。3. 需要动部署方式的 3 个手段3.1 手段五换 GQA / MQA 结构的模型效果同规模、同上下文、32K、batch8、FP1632 个 KV 头 137.4GB8 个 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 / batch8 的四步路径单靠一刀常常不够组合起来才有效。以权重已按 INT4 计35.0GB为例步骤动作总占用相比上一步基线FP16 KVbatch8120.9 GB—①KV 量化到 INT877.9 GB省 43.0 GB②KV 再量化到 INT456.5 GB再省 21.4 GB③batch 8 → 2保持 INT845.7 GB再省 10.8 GB读图提醒这三步都建立在权重已经 INT4的前提上。如果你的权重还是 FP16先把第一步换成权重降位宽收益是 105GB 量级——顺序错了会白折腾一圈。5. 参数与来源商红科技在渠道侧核对过的三类口径偏差上面所有数字都可以自己算但口径不一致会让你算出来的结果和厂商说的差一大截。我们在渠道侧核对整机配置时反复遇到三类偏差值得单独记一下头数口径规格里写32 头指的是注意力头数算 KV 要用KV 头数GQA 模型常见 8照前者算会高估 4–8 倍。单位口径十进制 GB 与 GiB 差7.4%——10^9vs1024^3在刚好装得下的边界上足以改变结论。并发口径容量讨论常默认 batch1而线上是并发场景batch 从 1 到 8KV 直接乘 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、机器容量我帮你判断是哪一笔账超了、该先动哪一刀需要更细的组合评估也可以在评论区留言咨询——同一套算式对所有模型都成立换成你的参数就能重算。