显存不够，是本地部署绕不开的第一道坎。同事发来一个开源模型，宣传语写着 74B 参数压进 24GB 显存，他照着一跑，OOM。把宣传口径拆开算了一遍账，问题不在模型，在没算清楚显存花在哪。
先给一张位宽对账表，参数量按 74B 算。
| 精度 | 权重大小 | 24GB 单卡 | 说明 |
|---|---|---|---|
| FP16 | 约 148GB | 放不下 | 原始精度，多卡或 CPU 卸载 |
| INT8 | 约 74GB | 放不下 | 接近无损，省一半 |
| INT4 | 约 40GB | 放不下 | 常用档，要留 KV cache 余量 |
| 3bit 混合 | 约 28GB | 勉强 | 质量明显下滑，谨慎 |
宣传语里的"压进 24GB"，跑的往往是更小的模型变体，或者把部分层卸载到内存和硬盘。数清楚三个数，谁也骗不了你。
一、显存的三笔账
第一笔是权重。参数量乘位宽除八，再加量化元数据开销。INT4 实际占用大约每参数 0.55 到 0.6 字节，比理论值的 0.5 高一截，预留时别按理论值算。
第二笔是 KV cache。这块常被忽略，但它随上下文长度线性涨。按 32 层、8 个 KV head、128 维的常见配置算，每 token 约 128KB，一万 token 的会话就是 1.28GB，三十二 K 上下文能吃掉 4GB 多。
第三笔是运行时开销。框架自身、激活值、显存碎片加起来，留 1 到 2GB 余量。三笔账加总，才是你的真实门槛。
二、精度损失实测
| 量化档 | 困惑度变化 | 结构化输出成功率 | 长文本问答 |
|---|---|---|---|
| FP16 | 基准 | 99.2% | 基准 |
| INT8 | 加 1% 以内 | 99.0% | 基本持平 |
| INT4（AWQ） | 加 3% 到 5% | 97.5% | 下降 2 到 4 个点 |
| 3bit | 加 8% 以上 | 94% | 明显变差 |
口径说明。困惑度用同一份中文评测文本跑，结构化输出成功率用 500 条 JSON 任务样本，数字按我自己的项目环境整理，换模型和任务要重跑。
两个规律值得记住。位宽越低，伤得最重的往往是对精确性敏感的任务，比如结构化输出和代码生成，聊天问答反而看不出来。上下文越长，量化误差累积越明显，长文档任务尽量别用 3bit。
三、量化版本怎么选
本地跑优先看 GGUF 的 Q4_K_M 档，质量和体积平衡最好，CPU 加 GPU 混合推理也支持。服务端部署优先 AWQ，推理速度损失小，主流推理框架都支持。GPTQ 生态最老，兼容性广，但同档位下速度一般。
选档位的顺序是先 INT4 常用档，跑评测集看任务成功率掉没掉两个点以上，掉了就升 INT8。别一步到位上 3bit，省下的显存换不回质量。
四、踩坑记录
坑一，只按权重量买卡，KV cache 没留。Q4 的 32B 模型权重约 19GB，看起来 24GB 卡装得下，拉到 8K 上下文就 OOM。买卡之前先把三笔账加起来。
坑二，开了 KV cache 量化没做回归。KV cache 量化到 INT8 能省一半显存，但长上下文任务的精度影响比权重 INT8 大。我的做法是拿长文档问答集跑一遍对账，掉了两个点以上就回退。
坑三，量化后的模型直接换掉线上版本。同一套 prompt 在 FP16 上调好的格式约定，换 INT4 之后结构化输出的格式错误率翻倍。换量化版本要跟换模型一样跑回归集，这条跟结构化输出篇的验收口径一致。
五、总结
| 环节 | 一句话 |
|---|---|
| 权重账 | 参数量乘位宽除八，INT4 按 0.6 字节每参数预留 |
| KV 账 | 每 token 约 128KB（32 层 8 头配置），随上下文线性涨 |
| 余量账 | 运行时开销留 1 到 2GB |
| 选档 | 先 INT4 常用档，掉两个点就升 INT8 |
| 回归 | 换量化版本跑任务级回归，不只看困惑度 |
结合系列。MoE 选型篇的三本账（总参数、激活参数、显存）是选模型的账，这篇是选定之后把模型装进卡里的账。长上下文篇的 KV cache 计算在这里是显存预算的第二步，两篇可以对着看。
来源。量化位宽与显存换算按公开资料（GGUF、AWQ 量化文档）整理，精度与成功率实测数字按自己的项目环境口径，套用前建议用你的任务集重跑。
觉得有用点个关注。