把权重从 FP16 压到 INT4，模型文件常常能缩小到原来的四分之一。这很容易制造一种错觉：显存问题解决了，推理也必然快四倍。实际系统里，权重、KV Cache、中间激活、运行时工作区和并发调度共同占用资源；量化格式是否被硬件内核真正加速，也比位宽数字本身更重要。

先把显存账算完整

仅估算权重时，可以用“参数量 × 每参数字节数”。例如 7B 模型的 FP16 权重大约需要 14 GB，理想 INT4 权重大约 3.5 GB，但真实文件还包含分组缩放因子、零点和元数据。推理时还需要模型运行时、临时张量与 KV Cache。

KV Cache 与层数、上下文长度、并发序列数和键值头维度近似线性增长。长上下文服务中，权重量化后省下的显存很快会被 KV Cache 吃掉。因此容量规划应分别测量空载权重、单请求峰值、不同上下文长度和不同并发下的峰值，而不是只看模型下载页面上的文件大小。

GPTQ、AWQ 与运行时格式

GPTQ 通常通过近似二阶信息逐层量化权重，目标是减小量化引入的重构误差。AWQ 更关注激活显著的权重通道，通过缩放保护少量重要权重。两者都是部署方法族，不是单一固定实现；分组大小、校准集、对称或非对称量化都会影响结果。

选择格式时，应先看目标运行时和硬件支持。某种 INT4 文件能被加载，不等于存在高效内核。如果运行时在推理时频繁反量化，吞吐可能不升反降。最终判断依据应是目标机器上的首字延迟、生成速度、峰值显存和稳定并发数。

精度评测必须贴近任务

通用困惑度可以发现明显退化，却不足以代表业务能力。代码模型要测试编译或单元测试通过率；RAG 服务要测试引用忠实度、无答案拒答和长上下文中的证据定位；中文助手则要覆盖中文生成、数字、表格和专业术语。

校准数据同样重要。若量化校准集只有英文网页，而生产请求主要是中文电气技术文本，某些通道的激活分布可能不匹配。更稳妥的做法是从脱敏后的真实流量中构造代表性样本，并保留困难样例、长提示词和工具调用格式。

评测结果应按任务拆分，不要只给一个总分。平均损失很小，也可能掩盖少数关键能力的大幅下降，例如数值推理、结构化输出或低频专业词汇。

吞吐与延迟不是同一个目标

连续批处理能提高 GPU 利用率和总吞吐，但请求排队会增加尾延迟。面向交互式对话，应重点关注 TTFT（首 token 时间）、TPOT（每个输出 token 时间）与 P95/P99 延迟；面向离线摘要，则可以接受更大批量来换取吞吐。

容量压测需要固定输入和输出长度分布，逐步增加并发，直到错误率、排队时间或显存到达阈值。测得的安全容量还应留出余量，用于流量突发、上下文变长和运行时碎片。

一条可复现的量化流程

  1. 冻结基准模型、分词器、提示模板和评测集版本。
  2. 在目标领域校准集上生成多个量化候选，包括不同位宽与分组大小。
  3. 比较任务精度、拒答行为和结构化输出成功率。
  4. 在目标硬件上测量 TTFT、TPOT、吞吐、显存与功耗。
  5. 做并发和长上下文压力测试，确认不会在临界负载下频繁 OOM。
  6. 为量化模型保留灰度、回滚与版本审计能力。

量化的目标不是得到最小的模型文件，而是在质量、延迟、吞吐和成本之间找到可验证的工作点。位宽只是配置项，真正的产品指标始终发生在完整链路上。

参考资料