大模型量化是不是只要把权重从FP16改成INT4？

不是。生产推理要同时考虑权重量化、激活量化、KV Cache精度、内核支持、校准数据和业务评测，不能只看模型文件大小。

FP8和INT4应该怎么选？

FP8更适合追求吞吐和稳定性的GPU服务场景，INT4/AWQ更适合显存受限或边缘部署场景，但必须用业务数据验证准确率。

量化模型上线前最重要的检查是什么？

必须同时检查质量回归、延迟、吞吐、显存、长上下文稳定性、不同输入分布下的退化，以及推理框架是否有对应高性能kernel。

大模型量化实战：FP8、INT4、AWQ 与生产推理的取舍

背景：量化解决的不是”模型变小”这么简单

大模型上线后，最容易被低估的成本不是模型文件本身，而是推理时持续消耗的显存、带宽、计算 kernel 和 KV Cache。一个模型用 BF16 或 FP16 训练，并不意味着上线也必须保持同样精度。很多生产系统会通过量化把权重、激活或 KV Cache 从高精度表示转换为低精度表示，从而降低显存占用、提高吞吐，或者让更大的模型跑在更少的设备上。

但量化不是”把参数压缩一下”那么简单。vLLM 文档把量化描述为用精度换取更小内存占用，使更大的模型可以在更多设备上运行，并列出了 AWQ、GPTQ、bitsandbytes、FP8、INT4、INT8、量化 KV Cache 等多种格式。TensorRT-LLM 也把量化归为推理优化核心能力，覆盖 FP4、FP8、FP8 KV Cache、W4A16 GPTQ、W4A8 GPTQ、W4A16 AWQ、W4A8 AWQ 等配方。换句话说，生产量化已经不是单一算法问题，而是模型格式、校准方法、推理引擎、硬件 kernel 和业务质量评估的组合工程。

本文不讨论”某个量化方法理论上最强”，而是从工程上线角度讲清楚：什么时候用 FP8，什么时候用 INT4/AWQ，为什么 KV Cache 也要纳入量化决策，以及上线前必须做哪些检查。

核心概念：权重、激活和 KV Cache 是三类不同对象

量化前先分清楚被量化的对象。不同对象影响不同，风险也不同。

权重量化：最直观的显存收益

权重量化是最常见的入口。例如把权重从 FP16/BF16 转成 INT8、INT4 或其他格式。它最直接的收益是模型权重体积更小，加载显存更低。对于显存紧张的部署环境，权重量化常常决定一个模型能不能放进单卡。

但权重量化不一定自动带来端到端加速。如果推理框架没有对应的高性能 kernel，或者量化格式在运行时需要频繁反量化，模型文件虽然变小，实际延迟和吞吐未必改善。因此选型不能只看”4-bit”这样的标签，还要看服务框架是否原生支持该格式。

激活量化：收益更大，风险也更高

激活量化会影响运行时中间结果。它可以进一步减少带宽和计算成本，但对数值稳定性更敏感。NVIDIA 的 PTQ 资料强调，量化性能收益取决于量化范围、原始精度与目标精度差异以及使用的算法；校准会通过代表性输入数据确定 scaling factor。激活里常见的问题是 outlier——少量异常大值会拉宽量化范围，导致大部分普通值的有效精度变差。

这也是 SmoothQuant、AWQ 等方法存在的原因。它们不是简单粗暴地把所有数压到低 bit，而是通过缩放、校准或保护关键通道来降低误差。

KV Cache 量化：长上下文服务不能忽略

很多团队刚开始量化时只看模型权重，忽略了 KV Cache。在长上下文、多轮对话和高并发服务中，KV Cache 可能成为显存增长的主要来源。TensorRT-LLM 已经明确提供 FP8 KV Cache 和 NVFP4 KV Cache 选项，说明 KV Cache 精度已经成为推理配置的一部分。

KV Cache 量化的收益通常体现在长上下文吞吐和并发能力上，但风险也明显：如果缓存精度太低，长文本后半段的注意力质量可能退化，表现为引用错乱、细节丢失、代码补全不稳定或多轮对话记忆变差。因此 KV Cache 量化不能只跑短 prompt benchmark，必须加入长上下文和多轮样例。

主流路线：FP8、INT4、AWQ、GPTQ 各自适合什么场景

FP8：面向数据中心 GPU 的稳健选择

FP8 的优势是更接近现代 GPU 的硬件优化方向。相比 INT4，它通常保留更好的动态范围；相比 FP16/BF16，它又能降低带宽和存储压力。TensorRT-LLM 文档中列出了 FP8 Per Tensor、FP8 Block Scaling、FP8 Rowwise、FP8 KV Cache 等配方，并说明默认 PyTorch 后端在较新的 Hopper 和 Blackwell GPU 上支持 FP4 和 FP8 量化。

如果你的目标是生产服务、GPU 资源相对充足、业务质量稳定性优先，FP8 往往比极限 INT4 更容易落地。尤其在 H100/H200/B200 这类设备上，FP8 的工具链和 kernel 支持越来越完善。

适用场景：

在线推理服务，需要稳定吞吐和较低质量风险
模型较大，但还没有显存紧张到必须 INT4
使用 TensorRT-LLM、vLLM、SGLang 等现代推理框架
团队有能力做业务回归，但不希望量化策略过于复杂

INT4：显存压力大时的强压缩方案

INT4 的吸引力很直接：压缩率高。vLLM 的 INT4 W4A16 文档说明，INT4 权重量化可用于节省内存和加速推理，尤其适合降低模型大小，并在低 QPS 工作负载中维持低延迟。Hugging Face 的量化选择文档也把 GPTQ 和 AWQ 归入需要校准的量化方法，并指出 AWQ 在 4-bit 下通常有较高准确率，GPTQ 也常用于高准确率量化。

不过 INT4 不是”默认更快”。它依赖硬件、kernel、batch size、序列长度和服务框架。低 QPS 单请求可能受益于更小显存和更低内存带宽；高并发场景则要看 kernel 是否足够成熟。

适用场景：

单卡显存紧张，需要部署更大模型
边缘设备、本地推理、成本敏感服务
可接受较重的校准和回归测试
推理框架对目标 INT4 格式有原生高性能支持

AWQ：保护少数关键通道，而不是平均压缩所有权重

AWQ（Activation-aware Weight Quantization） 的核心思想是：并不是所有权重同等重要。AWQ 论文指出，保护约 1% 的显著权重可以显著降低量化误差，而且识别关键通道时要参考激活分布，而不是只看权重本身。它通过对显著通道做等价缩放，避免硬件低效的混合精度，同时降低量化误差。

这对工程部署很有价值。传统”全层统一量化”的风险是某些关键通道被压坏后，模型在数学、代码、复杂指令等任务上出现隐性退化。AWQ 的思路更贴近生产需求：用少量校准数据识别敏感部分，在保持硬件友好的同时尽量降低质量损失。

适用场景：

需要 4-bit 权重量化，但不希望质量下降太明显
有代表性校准数据
模型包含代码、数学、推理类任务，不能只用通用闲聊样例评测
服务框架支持 AWQ checkpoint 和对应 kernel

GPTQ：成熟，但要警惕校准集过拟合

GPTQ 也是常见的后训练量化路线。Hugging Face 文档把 GPTQ/GPTQModel 归为 calibration-based quantization，并提醒它需要校准数据和单独校准步骤，优点是通常准确率较高，也可能带来推理加速。

GPTQ 的风险在于校准数据选择。如果校准集过窄，模型可能在测试集上看起来正常，但在真实业务输入上退化。对于客服、代码、金融、保险、法律等垂直场景，不能只用通用英文语料做校准，至少要加入真实业务 prompt 的脱敏样本。

各量化路线对比速览

方法	典型精度	显存收益	质量风险	校准需求	最佳场景
FP8	W8A8	中等	低	轻量	数据中心 GPU 在线服务
INT8	W8A16	中等	低	轻量	通用推理，保守首选
INT4	W4A16	高	中高	需要	显存极度受限
AWQ	W4A16	高	中	需要	4-bit 中追求质量
GPTQ	W4A16	高	中	需要	成熟方案，注意校准泛化
FP8 KV Cache	KV FP8	随上下文增长	中	轻量	长上下文高并发

一个可落地的选型框架

生产环境可以按下面顺序做判断。

第一步：先确定瓶颈类型

如果瓶颈是模型放不进显存，优先考虑权重量化，比如 INT8、INT4、AWQ 或 GPTQ。
如果瓶颈是吞吐和 GPU 利用率，优先检查推理框架、batching、kernel、FP8、PagedAttention、连续批处理，而不是只盯模型文件大小。
如果瓶颈是长上下文并发，必须把 KV Cache 量化、prefix cache、paged cache、chunked prefill 纳入同一套测试。

第二步：先从保守方案开始

一个合理的生产路径通常是：

BF16/FP16 baseline → FP8 weight/activation 或 INT8
    → INT4 AWQ/GPTQ → KV Cache FP8/NVFP4
    → 混合精度与层级敏感性优化

不要一开始就追求 2-bit、binary 或极限低精度。2026 年 6 月 26 日修订的 OpenPangu 量化实证研究在 Ascend 910B1 NPU 上评估了 RTN、GPTQ、AWQ、SmoothQuant、GPTAQ、BiLLM、SliM-LLM 等方法，结论显示 8-bit weight-only 对 OpenPangu 1B/7B 基本无损，4-bit 对 7B 仍然实用，但对 1B 的推理、数学和代码任务伤害更明显；多数 2-bit 和二值化设置接近随机表现。这类结果提醒我们：低 bit 不等于免费收益，模型规模和任务类型会显著影响结果。

第三步：让推理框架决定可用格式

量化格式必须和运行时绑定。各类框架的支持矩阵如下：

框架	支持的量化格式
vLLM	AWQ、GPTQ、bitsandbytes、FP8、INT4、INT8、GGUF、TorchAO、量化 KV Cache
TensorRT-LLM	FP4、FP8、AWQ、GPTQ、KV Cache 量化（含 NVFP4）
Hugging Face Transformers	模型加载、离线转换、实验和部分在线推理

因此不要只问”哪个量化算法最好”，应该问：

我的 GPU/CPU/NPU 是否支持？
推理引擎是否原生支持？
有没有高性能 kernel？
是否支持当前模型结构？
是否支持张量并行、流水并行、LoRA、工具调用、长上下文？
是否能导出和回滚？

工程落地：一套可执行流程

1. 建立 FP16/BF16 基线

量化前先固定基线，包括：

模型版本、tokenizer 版本、推理框架版本
temperature、top_p、max_tokens 等生成参数
业务评测集
延迟、吞吐、显存、首 token 延迟、每秒 token 数
长上下文和多轮对话样例

没有基线就没有量化收益评估。 很多”量化后变差”的争议，其实来自测试条件不一致。

2. 准备校准集和评测集

校准集用于确定量化参数，评测集用于判断业务质量。两者不能完全相同。

建议校准集包含：

真实业务 prompt 的脱敏样本
短文本、长文本、多轮对话
代码、数学、表格、JSON 输出等高敏感任务
中英文混合输入
高风险边界样例

评测集则要覆盖准确性、格式稳定性、拒答边界、幻觉率、工具调用参数、结构化输出合法性等指标。

3. 先跑小模型或小流量灰度

不要直接把量化模型全量替换生产模型。更稳妥的方式是：

离线评测 → 影子流量 → 小比例灰度 → 分业务放量 → 全量切换

影子流量阶段不返回给用户，只记录量化模型和原模型的输出差异。小比例灰度阶段要实时监控投诉率、重试率、超时率、格式错误率和人工兜底比例。

4. 将量化模型当成一个独立模型版本管理

量化后的 checkpoint 不应只是原模型的附属文件。它应该有独立版本号、量化配置、校准数据摘要、评测报告和回滚策略。

建议记录的元信息示例：

base_model: Qwen/Qwen3-xxB
quant_method: AWQ
weight_dtype: int4
activation_dtype: fp16
kv_cache_dtype: fp8
calibration_dataset: business-sampled-2026-06
inference_engine: vLLM x.y.z
hardware: H100 / A100 / 4090 / Ascend 910B
quality_report: report-20260629.md
rollback_model: bf16-baseline

常见误区

误区一：模型越大，越适合极低 bit

不一定。较大模型有时对 4-bit 更鲁棒，但这不代表任何大模型都适合 2-bit 或 binary。最新 OpenPangu NPU 实证研究也显示，极低精度仍然困难，多数 2-bit 和二值化设置出现严重退化。

误区二：量化只影响准确率，不影响系统行为

错误。量化会影响延迟分布、吞吐、显存峰值、kernel 选择、batch 策略、长上下文稳定性和输出格式合法性。对于需要 JSON、工具调用或代码生成的系统，轻微数值扰动也可能放大成格式错误。

误区三：只要 benchmark 分数接近，就可以上线

通用 benchmark 只能说明一部分问题。真实业务更关心长尾输入、固定格式、召回事实、领域术语、拒答边界和上下文一致性。量化模型上线前必须通过业务回归。

误区四：预量化模型一定比自己量化更可靠

预量化模型节省时间，但你不知道它的校准数据和目标 workload 是否匹配。它适合快速试验，不代表可以跳过生产评测。

上线检查清单

质量检查

与 FP16/BF16 baseline 做逐项对比
检查业务核心问题准确率
检查代码、数学、表格、JSON 输出
检查多轮对话和长上下文
检查拒答、安全和合规边界

性能检查

首 token 延迟
平均每秒 token 数
P95/P99 延迟
单卡最大并发
显存峰值
不同 batch size 下的吞吐曲线

运行时检查

推理框架是否原生支持该格式
是否使用高性能 kernel，而不是 fallback
Tensor parallel / pipeline parallel 是否正常
LoRA、工具调用、结构化输出是否兼容
KV Cache 精度是否影响长上下文
是否支持快速回滚到 baseline

结论：量化是系统工程，不是压缩按钮

大模型量化的价值很明确：降低显存、提高吞吐、让更大模型进入更低成本的部署环境。但生产落地时，真正的问题不是”用不用量化”，而是量化什么、量化到什么精度、在哪个硬件上跑、由哪个推理框架执行、用什么业务数据验证。

一个稳健的实践原则是：先建立 FP16/BF16 基线，再从 FP8 或 INT8 这类保守方案开始，确认收益后再进入 INT4/AWQ/GPTQ；如果服务包含长上下文和高并发，再单独评估 KV Cache 量化。量化模型必须有独立版本、评测报告和回滚路径。只有这样，量化才是生产优化，而不是一次不可控的压缩实验。

大模型量化实战：FP8、INT4、AWQ 与生产推理的取舍

背景：量化解决的不是”模型变小”这么简单

核心概念：权重、激活和 KV Cache 是三类不同对象

权重量化：最直观的显存收益

激活量化：收益更大，风险也更高

KV Cache 量化：长上下文服务不能忽略

主流路线：FP8、INT4、AWQ、GPTQ 各自适合什么场景

FP8：面向数据中心 GPU 的稳健选择

INT4：显存压力大时的强压缩方案

AWQ：保护少数关键通道，而不是平均压缩所有权重

GPTQ：成熟，但要警惕校准集过拟合

各量化路线对比速览

一个可落地的选型框架

第一步：先确定瓶颈类型

第二步：先从保守方案开始

第三步：让推理框架决定可用格式

工程落地：一套可执行流程

1. 建立 FP16/BF16 基线

2. 准备校准集和评测集

3. 先跑小模型或小流量灰度

4. 将量化模型当成一个独立模型版本管理

常见误区

误区一：模型越大，越适合极低 bit

误区二：量化只影响准确率，不影响系统行为

误区三：只要 benchmark 分数接近，就可以上线

误区四：预量化模型一定比自己量化更可靠

上线检查清单

质量检查

性能检查

运行时检查

结论：量化是系统工程，不是压缩按钮

主要参考资料

常见问题