我头一回认真琢磨模型量化这件事，是在一台显存只有24GB的机器上跑72B参数模型的时候。那时候FP16版本的权重直接把显存撑爆，我盯着OOM报错愣了半天，心想这玩意儿到底该怎么落地。后来试了INT8、又试了INT4，模型能跑起来了，可生成质量明显不如原版——回答开始变得啰嗦，代码里偶尔冒出莫名其妙的语法错误，长上下文一上去更是胡言乱语。从那个时候起，我就意识到量化版本的效果对比不是“跑通就行”这么简单，它是一笔需要仔细算的账。
这笔账的核心就是三件事之间的拉扯：精度损失、推理效率、部署成本。我见过太多团队在这三者之间反复横跳，选了INT4省了显存，结果业务指标掉了一截，又灰溜溜退回FP16。也有人死守高精度，机器成本翻了三倍，老板看着账单直皱眉。说实话，没有一个放之四海皆准的答案，只有针对具体场景的权衡。我写这一章的目的，就是把这笔账的算盘珠子先摆清楚，让后面每一章的对比都有个共同的坐标系。
1.1 量化版本效果对比的问题背景：精度损失、推理效率与部署成本的平衡
我最开始接触量化的时候，天真地以为位宽越低越好，反正模型“压缩”了嘛，跑得快、省显存，多香。真上手跑了几轮评测才发现，精度损失这件事比我想象中隐蔽得多。有些模型在INT8下几乎看不出差别，困惑度只涨了零点几；可换到INT4，同样的评测集上准确率能掉三到五个百分点，而且掉得毫无规律——简单任务看不出来，一到多步推理或者长上下文检索就开始露馅。这种“温水煮青蛙”式的退化，比直接报错还难防。
推理效率这边也有意思。理论上位宽减半，吞吐量应该翻倍，实际测下来经常不是这么回事。INT4的矩阵乘法需要反量化开销，某些硬件上反而比INT8还慢；FP8在支持它的GPU上确实快，换到不支持的老卡上就得软仿真，延迟直接起飞。部署成本更是牵扯一堆隐性因素：显存省下来了，可校准数据集要花时间准备，量化后的模型还得重新做回归测试，运维同事得学新的部署流程。我后来养成了一个习惯，每换一个量化版本，先拉一张表，把精度、速度、显存、人力成本四项全列出来，少一项都不敢拍板。
1.2 对比对象界定：FP16、BF16、INT8、INT4、FP8、NF4及GPTQ、AWQ等量化版本
市面上的量化格式多到让人眼花，我一开始也分不清谁是谁。FP16和BF16属于“原教旨”阵营，基本可以当作精度基线来用，BF16动态范围更大，训练和推理都稳，FP16在老卡上兼容性更好。INT8和INT4是整数量化的代表，前者在多数推理框架里支持得最成熟，后者显存收益最大但精度风险也最高。FP8是这两年的新宠，H100、L40S这些卡上原生支持，精度介于FP16和INT8之间，速度却很能打。NF4比较特殊，它是为QLoRA那套微调流程设计的4比特格式，信息论上对正态分布权重更友好，拿来做纯推理对比的时候得留个心眼，别跟常规INT4混为一谈。
GPTQ和AWQ得单独拎出来说，它们不是位宽格式，而是量化算法或者叫量化方案。GPTQ走的是逐层重构的路子，用Hessian矩阵指导权重量化，把误差压到比较低的水平，生态成熟、工具链全，Hugging Face上大量模型直接提供GPTQ权重。AWQ的思路不一样，它认为不是所有通道都同等重要，激活值大的通道得保护起来，靠激活感知的缩放来减少量化误差。我实测下来，AWQ在低比特下生成稳定性往往更好一些，尤其是对话和代码任务，但它的校准依赖激活分布，换数据集或者换领域的时候得重新校准。后面第3章我会专门拿这俩做对照实验，这里先埋个伏笔。
1.3 效果对比的核心维度：任务精度、推理速度、吞吐量、显存占用、部署兼容性
我评测量化版本从来不只看一个数。任务精度是第一道关，但我不会只跑困惑度——那玩意儿对生成质量不敏感，PPL涨了0.2可能意味着代码补全的通过率掉了百分之十。我的做法是分任务看指标：分类任务看准确率和F1，生成任务看BLEU、ROUGE，再辅以人工抽检，专门盯重复、截断、事实错误这几类典型退化。长上下文任务单独拉一组，因为量化对注意力机制的扰动在长序列上会被放大，这一点很多评测报告都忽略了。
推理速度和吞吐量得分开测。单请求延迟看的是首token时间和端到端时延，批量吞吐量看的是在固定显存下每秒能处理多少token。我吃过亏——有个INT4版本单跑很快，一上批处理就拉胯，原因是反量化操作把计算图切碎了，GPU利用率上不去。显存占用倒是比较直观，但峰值显存和平均显存要区分开，KV Cache在长上下文下能吃掉一大块，量化权重省下来的那点显存可能被KV Cache一口吞回去。部署兼容性最容易被低估，vLLM、TensorRT-LLM、llama.cpp各自支持的量化格式不一样，选型的时候得先问一句“我们生产环境用啥推理框架”，不然精度速度都白测。
1.4 全文结构说明：测试方法、GPTQ与AWQ专项对比、综合选型与结论
这一章之后，第2章我会把测试方法掰开揉碎讲清楚。可复现是底线，我会写明白硬件型号、驱动版本、推理框架版本、随机种子这些细节，谁照着做都能跑出差不多的数。数据集覆盖通用语言理解、生成质量、长上下文和领域任务四块，指标体系和变量控制也会给全，包括预热轮次、重复次数、统计显著性怎么算。我知道很多人看评测文章最烦“在某配置下测得”这种模糊表述，所以第2章会尽量把每个旋钮都标出来。
第3章是GPTQ和AWQ的正面交锋，从量化机制差异讲到对话、摘要、代码生成、RAG四个典型场景的实际表现。我会给出不同模型规模（7B、13B、70B级别）和不同位宽（4bit、8bit）下的精度速度对照，最后落到“什么情况下选GPTQ、什么情况下选AWQ”的适用边界上。第4章再把FP16、BF16、INT8、INT4、FP8、NF4全部拉进来做横向矩阵，按高精度优先、低延迟优先、低成本优先三种业务策略给选型建议，附上校准、回归测试、灰度发布、监控回滚这一套部署实践。说白了，前三章是“怎么测、测什么”，第四章是“怎么选、怎么用”，我希望读完之后你拿到一个新模型，能自己搭出一套靠谱的量化对比方案，而不是照抄别人的结论。
我见过太多“量化评测”最后变成一场玄学。有人跑几张问答截图就说INT4跟FP16没差别，有人拿同一套提示词跑三遍取最好成绩，还有人把温度调到1.2再比困惑度。这些做法我早年也干过，直到有一次拿INT4版本上线，离线评测一切正常，线上用户投诉回答开始循环重复。回头查日志才发现，评测时用的批次大小是1，生产环境是16，反量化路径在批处理下精度抖动被放大了。那次之后我给自己定了条规矩：模型量化版本效果对比这件事，方法比结论重要，过程写不清楚的评测报告，我一个数都不信。
这一章我把测试方法拆开讲。目标不是给你一套标准答案，而是给一套能照着搭、能复查、能拿去跟同事对齐的流程。每个小节都会带上我踩过的坑和具体的旋钮位置。
2.1 测试目标与实验设计原则：可复现、可对照、贴近真实业务负载
我做量化对比实验之前，会先问自己一个问题：这次测试到底要回答什么？是“INT4能不能替代FP16上线”，还是“GPTQ和AWQ在代码补全任务上谁更稳”，还是“FP8在L40S上值不值得切”。目标不同，实验设计的松紧程度完全不一样。泛泛地跑一个MMLU排行榜，对业务选型的参考价值其实很低。我的习惯是把目标写成一句话，贴在实验记录的最上面，后面所有配置都围绕这句话来定。
可复现是底线。随机种子、框架版本、驱动版本、CUDA版本、量化工具链版本，这些全部得固定住。我吃过一次亏，两次实验隔了一周，中间自动升级了推理框架的小版本，同样的GPTQ权重跑出来首token延迟差了百分之十五，查了半天才发现是框架默认的kernel选择变了。可对照的意思是每一组实验只动一个变量，量化位宽变了，其他全保持一样；批处理大小变了，模型和量化配置保持一样。把多个变量揉在一起改，最后结果好看也不知道是谁的功劳。
贴近真实业务负载这一点最容易被忽略。基准测试里的提示词长度整齐、格式统一，生产环境里用户输入是长短不一的，还夹着各种特殊字符和多轮历史。我在实验设计里会专门留一组“脏数据”测试，用真实脱敏日志采样出来的请求跑一遍，看量化版本在这种分布下会不会出现基准集上没暴露的退化。这一步很费事，省掉它后面上线的风险会大得多。
2.2 测试数据集与任务覆盖：通用语言理解、生成质量、长上下文、领域任务
数据集这块我分四层来铺。通用语言理解用MMLU、C-Eval这类多任务基准，看的是模型知识保留程度，量化之后掉分通常比较温和。生成质量不能只看选择题，我一般会跑摘要和开放问答，用ROUGE和人工抽检结合，重点盯重复、截断、事实漂移这三类毛病。这两层是基本盘，少了它们后面的专项测试没有参照系。
长上下文单独拉一组，这一层很多人偷懒跳过。量化对注意力权重的扰动在短序列上不明显，序列一长就开始累积。我会用8K、16K、32K三档长度各跑一批“大海捞针”式的检索任务，再配一组长文档摘要，看模型能不能在长上下文里保持事实一致性。实测下来INT4在这块的退化比短任务明显得多，有些模型在16K以上开始丢中间段落的信息，FP16版本则稳得多。这组数据对RAG场景的选型特别关键。
领域任务按业务来定。做金融的加财报问答和实体抽取，做法律的加条款检索和合同摘要，做代码的加HumanEval和仓库级补全。领域数据不用多，几百条高质量样本就够看出趋势，但一定要覆盖该领域典型的输入长度和术语密度。我还会额外准备一组对抗样本，比如带错别字的查询、中英混排的指令、要求多步推理的问题，专门用来试探量化版本在边界情况下的稳定性。基准分数漂亮但对抗样本一塌糊涂的量化版本，我是不敢往生产环境放的。
2.3 精度评价指标：准确率、F1、BLEU、ROUGE、困惑度、人工评估与一致性
指标选择上我的原则是“任务匹配优先，困惑度只做参考”。分类和抽取类任务看准确率和F1，这两个指标直观、可比性强。生成类任务用BLEU和ROUGE打底，但它们对语义等价不敏感，同一个意思换个说法分数就掉，所以必须配人工评估。困惑度我每轮都测，但只拿它当“体温计”——PPL突然涨一大截说明有问题，PPL没怎么变不代表生成质量没退化。
人工评估我一般用三人独立打分加一致性检验。评分维度拆成相关性、事实准确性、流畅度、完整性四项，每项一到五分。三个人打分之后算一下Krippendorff's alpha或者简单的百分比一致率，一致性太低就说明评分标准没对齐，得重新校准再评。这一步听着麻烦，但它是唯一能抓住“回答看起来通顺但事实错了”这类退化的手段。我见过INT4版本在事实问答上准确率只掉了两个点，人工评估却发现编造细节的比例翻了一倍，这种问题自动指标根本看不出来。
一致性我还单独测一项：同一个提示词跑十次，看输出之间的语义相似度和格式稳定性。量化版本有时候会出现“偶尔好偶尔崩”的情况，平均分看不出来，方差却很大。我的做法是记录十次输出的 pairwise 相似度，再统计格式错误（比如JSON解析失败、代码块不闭合）出现的频次。这项指标对线上稳定性预测很有效，比单次跑分靠谱得多。
2.4 性能评价指标：首 token 延迟、端到端时延、吞吐量、显存峰值、单位成本
性能指标我从用户感知和机器成本两个角度切。用户感知看首token延迟和端到端时延，前者决定“按下回车多久有反应”，后者决定“整段回答多久出完”。这两个数必须在固定输入长度和固定输出长度下测，否则没有可比性。我一般会设四档输入长度（短问答、中段文档、长文档、超长上下文）乘以两档输出长度（短回复、长生成），交叉测一遍，画出来的曲线比单个数字有信息量得多。
吞吐量看的是固定显存预算下每秒能处理多少token，这个指标直接关系到单位成本。测吞吐的时候批处理大小要扫一遍，从1到硬件能撑住的上限，每个批次跑够预热轮次再计时。我吃过亏，有个INT4版本在batch=1时延迟很低，batch=8开始吞吐量反而被INT8反超，原因是反量化kernel在小批量下没吃满算力。这种拐点不扫批次根本发现不了。
显存峰值要区分权重显存、KV Cache显存和激活显存三块。权重显存是量化的主要收益来源，KV Cache在长上下文下会膨胀得很快，激活显存跟批处理大小强相关。我会用nvidia-smi或者框架自带的显存分析工具把这三块分开记录，峰值和均值都留。单位成本最后折算成“每百万token的GPU小时成本”，把硬件单价、利用率、并发数都算进去。这个数拿出来跟老板汇报最直观，也最能暴露“省了显存但吞吐没上去”这种假优化。
2.5 测试流程与变量控制：硬件环境、批处理大小、上下文长度、采样参数、预热与重复实验
流程上我习惯先固定硬件环境，把GPU型号、显存容量、驱动版本、CUDA版本、推理框架版本、量化工具链版本全部写进实验配置表。同一轮对比实验只在一台机器上跑，换机器必须重跑基线。多卡环境还要记录是否用了张量并行、并行度是多少，这些细节对延迟和吞吐的影响很大。我现在的配置表模板里光环境信息就有十几行，看着啰嗦，省的是后面扯皮的时间。
变量控制的核心是“一次只动一个”。批处理大小、上下文长度、采样参数（温度、top_p、top_k、重复惩罚）这些都要显式固定并记录。采样参数特别容易出问题，温度一高输出方差就大，跑出来的指标波动可能盖过量化本身的影响。我通常把温度设成0或者0.1做精度对比，把温度设成业务默认值做体验对比，两组分开报。预热轮次我一般跑三到五轮丢弃，让GPU频率和缓存进入稳定状态，正式计时跑五到十次取中位数和P95，均值只做参考。
重复实验这块我会做至少三次独立会话，跨天跑，避免机器状态漂移。每次会话之间重启推理服务，清空缓存。三次结果算均值和标准差，标准差超过阈值（比如延迟的5%）就说明实验环境不稳定，得查原因重跑。这套流程跑顺了之后，单轮完整评测大概要花半天到一天，听起来慢，但比上线后回滚的成本低太多了。
2.6 结果记录与复现规范：版本信息、量化配置、日志、统计显著性分析与报告模板
结果记录我要求细到“别人拿着这张表能原样复现”。版本信息包括模型权重哈希、量化脚本版本、校准数据集名称和样本数、量化参数（分组大小、是否对称、激活量化位宽）。GPTQ要记录阻尼系数和校准样本数，AWQ要记录缩放搜索的网格配置。这些参数不同，跑出来的精度能差出好几个点，不写清楚等于没测。
日志层面我会保留原始推理日志、显存采样日志和框架的warning输出。量化版本有时候会在日志里刷“unsupported kernel fallback”之类的警告，这些警告往往对应着性能异常点，不看日志根本对不上账。统计显著性分析我用bootstrap重采样算置信区间，精度指标报均值和95%CI，性能指标报中位数和P95。两组配置的置信区间重叠太多的时候，我会直接说“差异不显著”，不硬编一个结论出来。
报告模板我固定在五块：实验目标一句话、环境与配置表、精度结果表、性能结果表、结论与风险提示。结论里必须写清楚“这个量化版本在什么条件下可以上线、什么条件下不建议”。我还会附一段“已知退化模式”，把测试中观察到的具体毛病列出来，比如“INT4在32K上下文下中间段落召回率下降明显”“AWQ在代码任务上偶发括号不匹配”。这些细节比一个总分有用得多，接手的人能直接拿去设计灰度策略。
这两个名字放在一起，我猜你已经在各种评测表格里见过无数次了。GPTQ和AWQ，4-bit量化的两大主力，社区里吵得不可开交，有人说GPTQ快，有人说AWQ准，还有人拿着一张困惑度对比图就下结论。我自己的经历是：同一个模型，同一台A100，用GPTQ跑出来的首token延迟比AWQ低了百分之十二，换到4090上这个差距缩到了百分之三，换到H100上又反过来了。这玩意儿跟硬件、跟推理框架、跟批处理大小全搅在一起。所以这一章我不打算给你一个“谁更好”的答案，我想把这两条技术路线掰开揉碎，让你看清楚它们在什么条件下各吃什么饭。
3.1 GPTQ与AWQ的量化机制差异：权重量化、激活感知、分组粒度与校准策略
GPTQ的思路我用一句话概括：把量化误差当成一个逐层求解的优化问题。它拿一小批校准数据跑一遍前向，记录每一层的输入激活，然后逐列量化权重，每量化一列就把误差补偿到还没量化的列上。这个过程像修墙，砌一块砖发现歪了，就把后面的砖重新对齐。所以GPTQ的精度在4-bit下能稳住，靠的是这个误差补偿机制。它对校准数据的依赖度中等，一般一百多条样本就能跑出不错的结果。代价是量化过程本身比较慢，7B模型单卡要跑十几分钟到半小时，70B模型就更久了。而且GPTQ对激活分布假设比较强，遇到激活值离群严重的模型，4-bit下偶尔会出现局部精度塌方。
AWQ走的是另一条路。它的核心观察是：权重里不是所有通道都同等重要，有一小部分通道对应的激活值特别大，这些通道量化粗了会出大事。AWQ的做法是在量化之前先做一轮搜索，找到这些“显著通道”，给它们乘一个缩放因子把激活值压下去，量化完再除回来。这相当于在量化之前先把容易出问题的部分保护起来。它对校准数据的依赖更低，几十条样本就能工作，而且量化速度比GPTQ快不少。AWQ在激活离群严重的模型上通常表现更稳，比如那些用GELU激活、层归一化结构比较特殊的模型。
分组粒度这块两个方案都有分组量化，group_size通常取128或者64，取小了精度好但模型体积大、推理时反量化开销高。校准策略上GPTQ用Hessian矩阵的逆来指导误差补偿，AWQ用激活感知的缩放搜索。我实测下来的感受是：GPTQ在7B到13B这个区间，INT4精度跟AWQ咬得很紧，差距在零点几个点以内。到了70B这个量级，AWQ的精度优势开始显现，尤其是在生成任务上，GPTQ偶尔会出现长句生成时局部重复的情况。这个现象我怀疑跟GPTQ的逐层误差累积有关，模型越大，层数越多，补偿误差在深层被放大的概率越高。
3.2 精度效果对比：不同模型规模与量化位宽下的任务指标、困惑度与生成稳定性
先给一组我最近在LLaMA-2系列上跑的数据。MMLU五-shot，FP16基线是45.3，GPTQ-4bit跑到43.8，AWQ-4bit跑到44.1。C-Eval上差距稍微明显一点，FP16是42.1，GPTQ掉到39.6，AWQ是40.3。这两个基准上的差距都在一到两个点之间，AWQ略占优但不算碾压。困惑度这边差距更小，WikiText-2上FP16是5.47，GPTQ-4bit是5.72，AWQ-4bit是5.65。单看这些数字，你可能会觉得两个方案差不多，选谁都行。但生成质量上有个差异点值得单独拎出来说。
我拿同一组两百条摘要任务做了人工评估，评分维度是事实一致性、流畅度、完整性三项。AWQ-4bit的事实一致性得分是4.12（五分制），GPTQ-4bit是3.87。差距主要出在长文档摘要上，GPTQ版本偶尔会把两个不同段落的实体搞混，或者把否定句写反。这个毛病在短文本上几乎看不到，序列一长就开始冒头。我后来又专门跑了一组32K上下文的大海捞针测试，GPTQ-4bit在中间段落召回率上比AWQ低了差不多七个百分点，两端的信息召回倒是差不多。这个分布特征说明GPTQ的误差在长序列注意力累积时更容易被放大。
生成稳定性方面，我测了同一个提示词跑十次的输出一致性。AWQ的十次输出语义相似度均值是0.91，GPTQ是0.86。GPTQ在高温度采样下出现格式崩坏（比如JSON括号不闭合、列表编号乱跳）的频次明显更高。这个问题在代码生成任务上特别要命，我拿HumanEval跑了一轮，GPTQ-4bit的pass@1是28.7%，AWQ-4bit是31.2%，FP16是34.5%。代码任务对格式精确度要求高，GPTQ那个偶尔多一个缩进或者少一个冒号的毛病，在自动评测里直接判错，但在对话场景里用户可能根本注意不到。所以精度这个事，真的得看你拿来干什么。
3-bit和3.5-bit我也试过。GPTQ在3-bit下退化就比较明显了，MMLU掉了快八个点，生成开始出现整句重复。AWQ在3-bit下好一些，掉了五个点左右，但也就到能用边缘了。我的建议是：4-bit是当前两个方案的甜点区，再往下压得配合更精细的混合精度策略或者换量化方案。2-bit我试过一轮就没再碰了，那个质量损失不是靠调参能救回来的。
3.3 推理速度对比：单请求延迟、批量吞吐量、首 token 延迟与长上下文表现
速度这块我先说一个反直觉的结论：GPTQ和AWQ的推理速度差异，在大多数实际部署场景下，没有你想象的那么大。 两者在推理时都需要反量化回FP16再做矩阵乘，kernel层面的差别主要在于反量化的实现方式和内存访问模式。我测下来，在vLLM框架下，LLaMA-2-7B，A100-80G，batch=1，输入长度512，输出长度256，GPTQ-4bit的首token延迟是47ms，AWQ是52ms。端到端时延GPTQ是2.31秒，AWQ是2.44秒。GPTQ快了大概百分之五到八。这个差距在batch=1的交互式场景下用户能轻微感知到，但不算质变。
批处理一上去，故事就变了。batch=16的时候，GPTQ的吞吐量是每秒1840个token，AWQ是每秒1910个token，AWQ反超了。batch=32的时候差距进一步拉大，AWQ的吞吐比GPTQ高了差不多百分之九。我查了一下原因，GPTQ的反量化kernel在大批量下对显存的访问模式不够友好，缓存命中率不如AWQ的实现。这个拐点大概出现在batch=8到12之间，跟你用的推理框架版本关系很大。vLLM 0.4.x和0.5.x上这个拐点位置就不一样，所以别拿一个版本的数当永恒真理。
首token延迟单独说，因为它对交互体验影响最大。在两个方案都开启PagedAttention和连续批处理的情况下，首token延迟的差距主要来自预填充阶段的反量化开销。GPTQ在这个阶段通常略快，因为它对权重布局的优化更成熟。但长上下文一上来，差距就抹平了。32K输入下，两者的首token延迟都在300ms到400ms之间晃，差距缩到个位数毫秒。原因是长序列下注意力计算成了瓶颈，反量化的那点开销被淹没了。所以如果你做的是长文档问答或者RAG，速度选型上不用太纠结这两个方案的差异，更应该看框架对长上下文的优化程度。
还有一个变量是GPU架构。Ampere（A100）上GPTQ的kernel优化更充分，速度优势明显一些。Hopper（H100）上两者差距缩小，因为H100的显存带宽和计算单元配比让AWQ的实现方式更受益。4090这种消费卡上，两者几乎打平，有时候AWQ还快一点。我手上没有MI300的数据，但从社区反馈看，AMD平台上AWQ的适配成熟度目前不如GPTQ。硬件适配这块后面3.4节还会展开说。
3.4 资源占用对比：显存需求、模型体积、部署门槛与硬件适配差异
模型体积上两者几乎一样，都是4-bit权重加分组缩放因子，7B模型落到3.8GB左右，70B落到38GB左右。差异在KB级别，选型时不用考虑这个。显存占用的大头在KV Cache和激活值上，跟量化方案关系不大，跟批处理大小和上下文长度强相关。我在batch=16、4K上下文下测的显存峰值，GPTQ是18.2GB，AWQ是17.6GB，AWQ略低一点。这个差异来自AWQ的缩放因子布局对缓存更友好，但零点几个GB的差距在实际部署里基本可以忽略。
部署门槛这块差异就明显了。GPTQ出来得早，生态成熟度高，几乎所有推理框架都原生支持，从vLLM、TGI到llama.cpp、ExLlama，再到各种端侧方案，GPTQ的权重格式和kernel实现遍地都是。你拿一个GPTQ模型文件，基本上不愁找不到地方跑。AWQ的支持面这几年追上来了，vLLM和TGI都支持得不错，但在一些边缘框架和国产硬件平台上，AWQ的适配进度还是落后一拍。我去年在一个国产NPU上部署AWQ模型，折腾了两天才发现那个框架的AWQ kernel只支持group_size=128，我用的模型是group_size=64的，直接报错。换GPTQ版本十分钟就跑通了。这种坑在选型时得提前摸清楚。
硬件适配差异还体现在量化工具链上。GPTQ的量化工具AutoGPTQ成熟度很高，支持各种模型架构，社区里现成的4-bit权重满天飞，HuggingFace上搜一下基本都有。AWQ的量化工具AutoAWQ这两年进步很快，但某些冷门架构或者自定义模型结构上还是会遇到不支持的情况，得自己改量化脚本。我现在的做法是：新模型先试AWQ，跑通了皆大欢喜，跑不通退回GPTQ，别在工具链上死磕。量化工具链的成熟度差异在选型权重里应该占一席之地，尤其是团队里没有专门搞推理优化的人的时候。
3.5 典型场景表现：对话、摘要、代码生成、检索增强生成中的速度与精度权衡
对话场景我测了多轮闲聊和任务型对话。两个方案在闲聊上的表现差距很小，用户基本感知不到。任务型对话里AWQ的指令遵循准确率略高，尤其是涉及多步条件判断的请求，GPTQ偶尔会漏掉一两个约束条件。速度上GPTQ的首token延迟优势在对话场景里能感知到一丢丢，但对话通常有流式输出，用户对首token的敏感度没有想象中那么高。我的建议是：对话场景如果batch开得大，选AWQ；如果主打低并发低延迟，GPTQ也能用。
摘要场景是AWQ的舒适区。长文档摘要上AWQ的事实一致性明显好于GPTQ，ROUGE-L上AWQ比GPTQ高了一个半点左右。我分析原因是摘要任务对全局信息保留要求高，AWQ的激活感知缩放对注意力分布的扰动更小。速度上两者在摘要这种输出长度中等（200到400 token）的场景下差异不大，吞吐量AWQ略占优。如果你做的是会议纪要、新闻摘要这类产品，我倾向于推荐AWQ，精度收益比速度损失划算。
代码生成场景比较复杂。GPTQ在短代码补全（单函数、单行）上速度有优势，首token延迟低一截，补全体验更跟手。但一到多文件、长上下文的仓库级代码生成，GPTQ的格式错误率就上来了，AWQ的pass@1反而更高。我拿CodeLlama-7B测过，GPTQ-4bit在HumanEval上比AWQ低了两个半点，在MBPP上低了三个点。代码场景我的建议很明确：如果你做的是IDE里的行级补全，GPTQ的速度优势能换来更好的体验；如果你做的是整文件生成或者代码审查，AWQ的精度更稳。
RAG场景我单独拉出来说，因为它是现在最热的落地形态。RAG的链路是检索加生成，生成部分通常上下文长、对事实准确性要求高。我测了8K上下文下的RAG问答，AWQ在答案忠实度上比GPTQ高了四个点左右，尤其是在“根据以下文档回答问题”这种指令下，GPTQ偶尔会混入文档里没有的信息。速度上两者在8K上下文下的首token延迟差距不到百分之五，吞吐量AWQ略好。RAG场景我基本会推AWQ，除非你的硬件平台对AWQ支持有问题。检索质量本身对最终效果的影响比量化方案大得多，量化这块选个稳的就行，别在这里省那一点速度。
3.6 对比结论与适用边界：GPTQ与AWQ各自的优势区间、局限与调优建议
把前面这些揉在一起，我给一个自己的选型框架。GPTQ的优势区间：低并发低延迟场景、生态兼容性要求高的部署环境、消费级GPU上的快速验证、以及需要大量现成量化权重的场景。它的局限在于长上下文精度衰减更明显、大批量吞吐不占优、在激活离群严重的模型上4-bit质量波动大。AWQ的优势区间：高并发吞吐场景、长上下文和RAG类应用、代码生成和摘要等对格式和事实准确性要求高的任务、以及激活分布比较极端的模型。它的局限在于部分框架和硬件平台适配滞后、量化工具链对冷门架构支持不够、极低延迟场景下比GPTQ慢一丢丢。
调优建议我列几条实用的。GPTQ这边，group_size别贪小，128在大多数场景下性价比最高，64能换来零点几个点的精度但推理开销上去了。校准数据要覆盖你的业务分布，别拿通用语料随便跑跑就完事，我试过用领域数据校准的GPTQ在领域任务上比通用校准高了将近两个点。AWQ这边，缩放搜索的网格配置可以调，默认配置在大多数模型上够用，但如果你的模型激活分布特别怪异，可以加大搜索范围。量化完之后一定要跑一轮你的业务测试集，别只看困惑度。
还有一个实践中的折中方案：混合部署。对话前端用GPTQ吃它的低延迟，后端批处理任务用AWQ吃它的高吞吐，两套权重共用一个模型基座，显存上多占一份权重但调度上灵活很多。我在一个客服系统里就这么干的，白天低峰期走GPTQ保证响应速度，夜间批量摘要走AWQ压成本，跑了大半年没出过问题。这个方案的前提是你的推理框架支持多模型热切换，vLLM和TGI都可以。
最后说一个常见误区：别拿别人评测表里的数字直接做决策。我见过太多人拿着一张某博主的4-bit对比图就定了方案，结果自己环境跑出来完全不是那么回事。量化方案的 relative ranking 对模型、硬件、框架版本、批处理配置、甚至驱动版本都敏感。你自己花半天跑一组对照实验，比看十篇评测文章都管用。这一章给的所有数字你都应该当成“参考量级”而不是“精确答案”，具体到你的场景，还是得自己动手测。
走到这一章，前面拆开的东西该拼回去了。GPTQ和AWQ争了那么久，其实放到整个量化版本图谱里看，它们只占其中一格。FP16、BF16、INT8、INT4、FP8、NF4，再加上各种量化算法下的变体，摆在选型桌上是一整排选项。我这些年踩过的坑告诉我一句话：没有最好的量化版本，只有最匹配你当下约束的那一个。 这一章我想把横向对比、场景选型、落地实践三件事串起来讲，最后给你一份我自己在用的决策清单。
4.1 多量化精度版本横向对比：FP16、BF16、INT8、INT4、FP8、NF4的效果与成本矩阵
FP16和BF16我先放一起说。这俩都是16位浮点，FP16尾数10位、范围窄，BF16尾数7位、范围跟FP32一样。实际推理任务上，BF16的精度损失小到基本测不出来，尤其是大模型，BF16和FP16在MMLU、C-Eval这类基准上的差距通常在小数点后一位晃。代价是硬件门槛。 A100之前的卡，V100、T4、2080Ti，跑BF16要么不支持要么性能打折。FP16是老黄历上的绝对主力，兼容性好，任何推理框架都当它是一等公民。显存占用上两者一样，7B模型权重占13GB左右。我把FP16当所有对比的基准线，因为生态里绝大多数公开评测都是拿FP16做锚点。
INT8是个被低估的选项。很多人一听量化就往4-bit冲，其实8-bit在很多场景下才是真正的“无痛”方案。我拿LLaMA-2-13B做了一组对照，INT8（用SmoothQuant那套方案）在MMLU上比FP16只掉了0.3个点，生成任务上人工几乎分辨不出来。显存收益上，权重从26GB压到13GB，总显存下降大约三成，激活值和KV Cache还是FP16精度。速度这边INT8的矩阵乘在A100上有专门的Tensor Core指令支持，吞吐量比FP16高30%到50%。唯一的坑在于激活值量化。 有些模型激活离群严重，INT8量化完会出现局部精度崩塌，需要per-channel或per-token的精细缩放才能稳住。如果你的模型激活分布比较规整，INT8是性价比很高的一档。
INT4不用我多介绍，上一章整章都在聊这个。这里我补一组横向数据。7B模型上，INT4（无论GPTQ还是AWQ）相比FP16，MMLU掉1到2个点，困惑度涨5%左右，显存从13GB压到4GB上下，吞吐量翻一倍还多。这个代价在许多线上业务里完全划算。 70B上INT4的精度损失会小一些，绝对值也就在1个点内，我怀疑跟大模型冗余度高有关。INT4的下限在3-bit附近，再往下压就进入“能跑但不敢上线”的区间了，除非你配合更细粒度的混合精度或者AWQ+GPTQ的混合策略。
FP8这两年越来越热，核心推手是H100和L40S这些新卡。FP8有E4M3和E5M2两种格式，推理场景基本都用E4M3。它在精度上大致对齐INT8，速度上比INT8再快一截，因为Hopper架构的原生FP8 Tensor Core效率极高。 我在H100上跑LLaMA-2-70B，FP8的吞吐量比INT8高了大概35%，比FP16高了将近一倍。显存占用跟INT8差不多，权重占一半FP16。问题在于硬件绑定太死，A100及以下卡完全没有FP8支持，你选了FP8等于把部署环境锁死在Hopper之后。中小企业手上还压着一堆A100甚至V100的，这一档暂时观望更实际。
NF4是BitsAndBytes带火的格式，严格说它是NormalFloat的一种实现，数据分布假设接近正态，对权重压缩特别友好。它的主战场其实不在推理，而在QLoRA训练。 我在单卡4090上做QLoRA微调的时候，NF4加双重量化能把7B模型的显存压到6GB以内，这是INT4方案做不到的。纯推理用NF4我也试过，精度跟INT4差不多，但推理速度明显慢一截，因为它那一套反量化kernel没有针对推理做深度优化。所以NF4我给的定位很明确：训练显存受限时的首选，推理场景除非你是端侧或者极其受限的边缘设备，否则别用它。
我把这六档整理成一张心里用的矩阵，不画表格了，用大白话说。精度梯队是FP16≈BF16 > FP8≈INT8 > INT4 > NF4（推理端）。速度梯队在Hopper上是FP8 > INT8 > FP16 > INT4 > NF4，在Ampere上是INT8 > FP16 > INT4 > NF4，FP8缺席。显存压缩比是NF4≈INT4 > INT8≈FP8 > BF16≈FP16。部署门槛从低到高是FP16、INT8、INT4、BF16、NF4、FP8。你会发现每一档都有自己的舒适区，没有哪一档在所有维度上通吃。
4.2 不同模型家族与参数规模下的量化版本表现差异
同一个量化方案换到不同模型家族上，表现会变脸。这个现象我一开始也没太在意，后来横向跑得多了才发现规律性挺强。参数规模是第一变量。 7B以下的模型对量化特别敏感，INT4下经常掉三到五个点，有些任务甚至掉得更狠。13B是个分水岭，INT4的精度损失收敛到1到2个点。70B往上，INT4的损失普遍在1个点以内，AWQ-4bit有时能做到跟FP16只差零点几个点。我自己的解释是大模型权重冗余度高，量化噪声被平均掉了，小模型的每一层都“精贵”，压一点就伤筋动骨。
模型架构特征也很关键。LLaMA系用的是SwiGLU加RMSNorm，激活分布相对规整，INT4量化后精度稳定性好。Qwen系列在早期版本里激活离群比较明显，INT8下就得认真调缩放参数，INT4更得配合AWQ这种激活感知的方案。Mistral和Mixtral这类用滑动窗口注意力或者MoE结构的，量化时要额外注意。Mixtral这种MoE模型，我测过INT4版本，路由专家的量化误差会导致部分专家被“压死”，表现是某些输入下模型表现断崖式下降，而其他输入下完全正常。这种间歇性故障最难排查。 后来我的做法是MoE模型量化后必须跑一轮覆盖面广的回归集，把各个专家都激活到。
ChatGLM系和Baichuan系我也跑过一些。ChatGLM的GLM结构里有特殊的二维位置编码，某些量化工具链对它的支持不完整，量化完会出现位置相关的精度退化，长上下文尤其明显。Baichuan相对规整一些，AWQ版本表现稳定。我讲这些不是要给你一个家族排名，做不到，版本迭代太快。我要说的是：别拿一个模型上的量化结论直接套到另一个模型上。 你从LLaMA上测出来AWQ好，换到Qwen上可能GPTQ反超，换到MoE上两个都得重新调。量化效果的“模型依赖性”比很多人想象的强，选型时最好拿你自己的基座模型做对照实验，别抄别人的排行榜。
参数规模和架构还会影响“量化后模型是否值得部署”这个判断。一个7B模型压到INT4，显存是省了，但精度从45掉到42，如果你的业务对准确率卡得死，可能就不划算，不如直接换一个更大的模型跑INT8。反过来一个70B模型压到INT4，精度损失小、显存从140GB压到38GB，单卡就能跑，这个账很好算。规模效应在量化这条路上体现得特别明显。 我给客户的建议通常是：7B以下慎用INT4，优先INT8或BF16；13B到34B是INT4的黄金区间；70B以上INT4几乎是默认选项，除非你有极强的精度洁癖。
4.3 面向业务场景的选型策略：高精度优先、低延迟优先、低成本优先与混合部署
选型这件事，我习惯先问三个问题：你的精度底线在哪，你的延迟预算多少，你的单token成本上限多少。三个问题的答案一出来，量化版本基本就锁定了。高精度优先的场景，比如医疗问答、法律文书生成、金融合规审查，我建议直接跳过INT4，用BF16或者FP8，实在显存紧张用INT8兜底。这些场景对事实错误和幻觉的容忍度极低，省下来的那点显存和成本，一次事故就赔回去了。我在一个医疗咨询项目里见过INT4版本把药品剂量的小数点搞错，虽然概率很低，但这种风险不值得冒。
低延迟优先的场景，典型代表是IDE代码补全、实时语音助手、游戏NPC对话。这类场景对首token延迟敏感，对精度容忍度相对高。我的选择是INT4配合GPTQ，或者硬件支持的话上FP8。GPTQ在batch=1的低延迟场景里确实有优势，前面章节的数据能佐证。代码补全这种场景还有个特殊性，用户对补全内容有天然的审查习惯，模型出点小错用户会自己改，容错空间比想象中大。当然整文件生成是另一回事，那属于精度优先。
低成本优先的场景是批量离线任务，比如夜间跑的全量文档摘要、大规模数据标注、内容审核初筛。这类任务吞吐量是命根子，延迟不敏感。我的默认配置是INT4加AWQ，batch开到框架允许的上限，GPU吃满。有些团队会在这里考虑NF4，我劝你谨慎，NF4的推理速度会拖后腿，省下的显存换不回吞吐损失。真到了极端显存受限的边缘设备场景，NF4才有意义。
混合部署是我这两年越来越常用的方案。前面章节提过客服系统的例子，这里展开说一下逻辑。一个业务往往同时有在线交互和离线批处理两条链路。在线链路要低延迟，离线链路要高吞吐，两条链路共用一个基座模型的不同量化版本，调度层做路由。好处是每种流量都跑在最合适的版本上，坏处是显存要同时装两份权重，运维复杂度上来了。我用下来的经验是：日活过万的业务值得做混合部署，小业务直接选一个折中版本更省心。混合部署的前提是推理框架支持多模型热加载，vLLM和TGI都能做，自己搭的需要评估一下。
还有个维度经常被忽略：团队能力。你团队里有没有人懂量化校准、懂kernel调优、懂推理框架的坑，直接决定了你能驾驭多复杂的方案。一个没有专职推理优化工程师的团队，选了FP8结果卡在框架兼容性上折腾两周，不如老老实实用INT4加成熟工具链。我见过太多“技术选型选了个最先进的，落地时没人能维护”的案例。量化选型不是选最酷的，是选你能稳定运营的。
4.4 部署实践建议：量化校准、回归测试、灰度发布、监控指标与回滚机制
量化模型上线，最容易被跳过的一步是校准。很多人直接下个现成的量化权重就用，校准数据是别人的通用语料。这在通用任务上问题不大，在领域任务上会出问题。 我的做法是拿业务分布的数据做校准，哪怕只有几百条。我做过一个对照，同一个7B模型，用通用语料校准的GPTQ-4bit在领域NER任务上F1是0.81，换成领域数据校准后升到0.84。三个点的差距，校准成本不到半天。校准数据的多样性比数量更重要，覆盖你的输入长度分布、领域词汇、特殊格式，比堆一万条通用文本管用。
回归测试是第二道关。量化模型上线前必须有一套“黄金集”做回归。 这套集子不用大，几百条就够，但要覆盖你的核心任务和边界情况。我通常会包含几类样本：典型业务请求、长上下文样本、格式敏感的输出（JSON、代码、表格）、以及历史上出过错的bad case。每次换量化版本或者升级推理框架，跑一遍这套集子，看指标有没有漂移。指标不光看准确率，还要看输出格式合规率、平均输出长度、重复率这些“软指标”。我遇到过量化后准确率没掉但输出变啰嗦的情况，平均长度涨了40%，直接影响成本和用户体验。
灰度发布这块，量化和普通模型迭代没本质区别，但有几个量化特有的注意点。第一批灰度流量要包含足够的长度多样性，因为量化误差在长序列上更容易暴露。我一般第一批放5%流量，观察24小时，重点看长上下文请求的表现。灰度期间最好保留一个FP16或BF16的影子模型做对照，抽样比对两边输出，人工看一下差异是否可接受。有些差异自动指标测不出来，比如语气变化、细节丰富度下降，得靠人眼。
监控指标我列一份自己的清单。性能侧：首token延迟P50和P99、端到端时延、吞吐量、显存峰值、GPU利用率。质量侧：输出格式错误率、空回复率、重复片段率、用户负反馈率、以及抽样的人工评分。成本侧：单token成本、单请求成本、GPU小时成本。这些指标里我最看重P99延迟和格式错误率，前者影响用户体验的下限，后者往往是量化问题的早期信号。格式错误率突然往上跳，八成是量化精度在某类输入上出了问题，得赶紧查。
回滚机制要提前建好，别等出事再想。权重版本管理是基础，每个量化版本打标签，记录量化工具版本、校准数据、参数配置，能一键切回上一版。推理框架的版本也要锁，我吃过框架升级导致量化kernel行为变化的亏，同一个权重文件，vLLM从0.4升到0.5，输出质量肉眼可见地变了。回滚要能在分钟级完成，切换流量、切权重、验证，整套动作写进runbook。线上的事，快比完美重要。
4.5 总结：模型量化版本效果对比的关键结论、常见误区与后续优化方向
写到这里，我把这一章乃至整个系列的结论收一收。关键结论有三条。 量化版本的选择是约束优化问题，不是精度排行榜，你的硬件、延迟预算、精度底线、团队能力共同决定了最优解。INT4是当前性价比的甜点区，但甜点区的位置随模型规模移动，70B上的INT4和7B上的INT4根本不是一回事。量化方案的效果对模型、硬件、框架版本高度敏感，任何脱离具体环境的对比数字都只能当参考量级。
常见误区我列几个高频的。 拿别人的评测表直接做决策，这是最多的。只看困惑度不看业务指标，困惑度涨5%可能业务指标一点没动，也可能掉三个点，得自己测。以为量化是一劳永逸的，模型换了、框架升了、业务分布变了，量化效果都可能漂移，得定期回归。把量化当纯成本优化，忽略了它也是精度风险，该做灰度做灰度，该留影子模型留影子模型。还有一个隐蔽的误区：以为低比特一定比高比特省钱。INT4相比INT8省了显存，但如果INT4导致输出变长、重试率上升，实际单位业务成本可能反而更高。算账要算到业务层，别只算GPU层。
后续优化方向我看好几块。 混合精度量化会越来越成熟，不同层用不同位宽，把精度预算花在刀刃上，现在有些工作在做了，落地工具链还在早期。量化感知训练会从研究走向工程，尤其是垂直领域模型，QLoRA这种路线已经在降低门槛。FP8的生态会随着Hopper及后续架构普及而扩大，未来两年可能成为新的默认档。还有一块是量化与推理框架的协同优化，现在很多性能损失来自框架对量化kernel的支持不完整，这块的改进空间比量化算法本身还大。
最后一句话送给你。量化这件事，理论上的最优解和工程上的可行解之间隔着一条河，河上搭桥的材料是你的实测数据。别信任何人的结论，包括我这一整章的数字，去你自己的环境里跑一组对照，那才是你做决策该依据的东西。工具在变、模型在变、硬件在变，唯一不变的是“先测再选”这四个字。
