1. 大模型量化困局与AWQ的破局思路1.1 为什么量化总是“翻车”从显存焦虑说起但凡在本地跑过大模型的人都经历过那种“显存就差一点点”的绝望。你手里可能是一张16G显存的卡想跑一个70亿参数的模型FP16精度下光权重就要吃掉14G再加上KV Cache、激活值、框架开销分分钟爆显存。于是大家自然而然想到量化——把FP16的权重压到INT4理论上显存直接砍到四分之一多出来的空间还能把上下文拉长一点。但现实往往很骨感。你兴冲冲地拿一个INT4量化模型跑起来发现输出质量断崖式下跌原本能答对的问题开始胡言乱语代码生成缺胳膊少腿数学推理直接摆烂。更气人的是有时候量化后的模型推理速度并没有提升多少延迟反而因为反量化操作变高了。这就是标题里说的“过拟合与高延迟诅咒”——量化不是简单的数值压缩它是一场在精度和效率之间的走钢丝。我踩过最典型的坑是用某套常规的权重量化方案把一个中文对话模型压到INT4结果模型在通用benchmark上看着还行但一到实际对话就露馅尤其是涉及长尾知识或者需要精细推理的场景表现惨不忍睹。后来才明白问题出在量化粒度上——粗粒度的per-tensor或者per-channel量化对所有权重一视同仁但大模型里不同通道的重要性差异极大有些通道承载了关键语义信息你把它压狠了模型就“失忆”了。1.2 AWQ的核心洞察不是所有权重都生而平等AWQ全称Activation-aware Weight Quantization翻译过来就是“激活感知的权重量化”。它的核心洞察非常朴素但极其深刻权重的的重要性不是由权重本身决定的而是由它对应的激活值决定的。打个比方一个团队里每个人都很重要但真正决定项目成败的往往是那几个关键角色。你裁员的时候不能按人头平均砍得看谁在关键任务上出力最多。AWQ就是干这个的——它通过分析校准数据在模型前向传播过程中的激活分布找出那些对输出影响最大的权重通道然后对这些通道进行保护让它们在量化时保留更高的精度。这里的关键在于“激活感知”四个字。传统的量化方法要么只看权重数值分布比如GPTQ要么用简单的统计量做缩放但AWQ发现真正需要保护的是那些对应大激活值的权重通道。因为在大模型里激活值往往呈现极端的离群点分布——少数通道的激活值可能是其他通道的几十倍甚至上百倍。这些离群通道如果被粗暴量化误差会被放大最终导致模型输出崩坏。AWQ的做法是对每个权重通道根据其对应激活值的幅度计算一个缩放因子。激活值大的通道缩放因子就大量化时保留更多有效位激活值小的通道可以压得更狠。这样一来量化误差被智能地分配到了不重要的通道上重要通道的精度得到了保护。1.3 仅保护1%显存开销背后的数学逻辑标题里说“仅保护1%显存开销”这个数字不是拍脑袋来的。AWQ在实现时并不是把重要通道单独拎出来用FP16存储——那样显存开销就大了。它的做法是在量化过程中引入一个缩放因子s对权重进行等价变换W W * s然后对W做量化推理时再除以s还原。这个缩放因子是per-channel的只需要存储一个向量相对于整个权重矩阵来说额外开销几乎可以忽略不计。具体来说假设权重矩阵是N×K量化后每个权重占4bit那么总显存是NK0.5字节。缩放因子向量长度是K如果用FP16存储额外开销是K*2字节。当N远大于1时大模型的权重矩阵N通常是几千到几万额外开销占比不到0.1%。即使加上一些实现上的对齐和元数据整体额外开销控制在1%以内是完全合理的。这个设计的精妙之处在于它没有改变量化的基本框架只是在量化前做了一次聪明的等价变换。你可以把它理解成“给重要通道戴上了一层保护罩”但这层保护罩本身几乎不占空间。相比之下有些混合精度方案会把重要通道单独用INT8或FP16存储显存开销直接翻倍部署时非常尴尬。1.4 推理暴增3倍的工程实现路径量化带来的推理加速理论上来自两个方面一是显存带宽压力降低因为权重从FP16变成INT4读取同样数量的权重只需要四分之一的带宽二是计算密度提升INT4的矩阵乘法在支持低精度计算的硬件上吞吐更高。但理论归理论实际能不能跑到3倍加速取决于推理框架的优化程度。AWQ的加速效果之所以显著是因为它和主流的推理引擎做了深度集成。比如在TensorRT-LLM里AWQ量化后的模型可以直接走INT4的GEMM kernel反量化操作被融合进了矩阵乘法内部不会产生额外的内存往返。在vLLM里AWQ也有专门的CUDA kernel支持能够实现高效的paged attention和量化推理。我实测下来在同样的硬件上一个7B模型用FP16跑大概是每秒30个token换成AWQ INT4之后能到每秒90个token左右差不多就是3倍。这个提升在长文本生成场景下感知特别明显——以前等一段500字的回复要十几秒现在五六秒就出来了。当然加速比和模型大小、batch size、硬件都有关系不是所有场景都能精确到3倍但方向是确定的。2. 核心细节解析与实操要点2.1 校准数据的选取决定量化成败的隐形之手AWQ的量化过程需要一小批校准数据来统计激活分布这批数据的选择直接决定了量化后模型的表现。很多人随便拿几百条通用文本就开跑结果量化出来的模型在特定任务上表现很差还以为是算法不行其实是校准数据没选对。校准数据的核心原则是分布要覆盖你实际推理时可能遇到的输入类型。如果你量化的是一个代码模型校准数据里就应该有足够多的代码片段如果你量化的是中文对话模型校准数据就应该包含多样化的中文对话场景。我一般会准备512到1024条校准样本长度控制在模型最大上下文的一半左右这样既能覆盖足够的激活模式又不会让校准过程太慢。还有一个细节是校准数据的顺序。AWQ在统计激活值时会逐层前向传播前面的层会影响后面的层。如果校准数据里全是短文本那么长文本场景下的激活分布就没被覆盖到量化后模型处理长文本时可能出问题。我的做法是混合不同长度的样本短句、段落、长文都放一些让激活统计更全面。注意校准数据不要用训练集里的数据否则量化后的评估结果会偏乐观。最好是从真实业务场景里采样或者用公开的评测集但只取输入部分不要用标签。2.2 缩放因子的搜索空间网格搜索与梯度优化的权衡AWQ在计算缩放因子时并不是直接解析求解而是在一个搜索空间里找最优值。具体来说它把缩放因子限制在一个合理的范围内然后通过网格搜索或者梯度优化的方式找到让量化误差最小的那个值。网格搜索的优点是稳定、可复现缺点是计算量大。如果每个通道都要搜几十个候选值整个量化过程可能要跑几个小时。梯度优化的优点是快但容易陷入局部最优而且对超参数敏感。AWQ的论文里提到他们用了一种基于激活感知的搜索策略实际上是在两者之间做了折中——先用激活统计量缩小搜索范围再在缩小的范围里做精细搜索。实操中如果你用的是现成的AWQ工具链比如AutoAWQ这些细节已经被封装好了你只需要指定校准数据集和量化配置就行。但如果你想自己调优可以关注两个参数一个是搜索的粒度粒度越细量化误差越小但耗时越长另一个是保护比例也就是有多大比例的通道被视为“重要通道”需要保护。保护比例太高显存开销上去了保护比例太低精度保不住。一般建议从1%开始试根据评估结果微调。2.3 量化粒度选择per-tensor、per-channel还是per-group量化粒度是影响精度和效率的关键参数。per-tensor是整个权重矩阵共用一个缩放因子实现最简单但精度最差per-channel是每个输出通道一个缩放因子精度好一些但存储开销增加per-group是把通道分成若干组每组一个缩放因子在精度和开销之间取得平衡。AWQ默认用的是per-group量化group size通常设为128。这个选择是有讲究的group size太小缩放因子太多存储开销和反量化开销都上去了group size太大组内通道的重要性差异被忽略精度下降。128是一个经验值在大多数模型上表现均衡。我试过把group size调到64精度确实有提升但推理速度掉了大概10%因为反量化时需要读取更多的缩放因子。调到256的话速度上去了但在一些对精度敏感的任務上比如数学推理会出现明显的质量下降。所以除非你有特殊需求否则128是一个比较稳妥的默认值。量化粒度精度表现显存开销推理速度适用场景per-tensor较差最低最快对精度要求极低的场景per-channel中等较低较快通用场景per-group (128)良好适中适中大多数大模型部署per-group (64)优秀较高较慢精度敏感任务2.4 与GPTQ的对比为什么AWQ更适合边缘端GPTQ和AWQ是当前最主流的两种训练后量化方案很多人纠结选哪个。我的经验是如果你追求极致的压缩率GPTQ可以做到3bit甚至2bit如果你追求精度和速度的平衡尤其是边缘端部署AWQ更合适。GPTQ的核心是逐层做二阶误差补偿量化过程比较慢而且对校准数据更敏感。AWQ的核心是激活感知的缩放量化过程相对快鲁棒性更好。在边缘端场景下硬件资源有限推理框架对量化格式的支持程度不一AWQ因为和TensorRT-LLM、vLLM等框架集成得更好部署起来更省心。还有一个实际因素是AWQ量化后的模型在低精度下的“崩溃点”更靠后。什么意思呢就是当你把量化位宽继续往下压的时候GPTQ可能在某個位宽突然精度暴跌而AWQ的下降曲线更平滑。这对于需要在不同硬件上灵活调整位宽的场景很重要。3. 实操过程与核心环节实现3.1 环境准备与工具链选型要跑通AWQ量化你需要准备三样东西一个支持CUDA的GPU环境、一套AWQ量化工具、一个待量化的模型。工具链方面目前最成熟的是AutoAWQ它封装了量化、校准、导出等全流程支持Hugging Face上的大多数模型架构。安装AutoAWQ很简单一条pip命令就行pip install autoawq但要注意版本兼容性。AutoAWQ对transformers、torch、CUDA版本都有要求版本不匹配会出现各种奇怪的错误。我建议用conda创建一个干净的环境然后按照官方文档的版本矩阵来装。比如transformers 4.40以上、torch 2.1以上、CUDA 11.8或12.1这些组合经过验证比较稳定。硬件方面量化一个7B模型大概需要16G显存13B模型需要24G到32G70B模型建议用多卡或者80G显存的卡。如果显存不够可以开启CPU offload但量化速度会慢很多。我试过用一张16G的卡量化13B模型开启offload后跑了将近两个小时而用32G的卡只要二十分钟。3.2 量化脚本编写与参数配置AutoAWQ的量化接口设计得很直观核心就是几行代码from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path your-model-path quant_path your-quantized-model-path quant_config { zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM } model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) model.quantize(tokenizer, quant_configquant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)这里有几个参数需要解释一下。zero_point设为True表示使用非对称量化对于激活值分布偏斜的情况更友好q_group_size就是前面说的分组大小w_bit是量化位宽4bit是当前最常用的version指定量化算法版本GEMM是通用矩阵乘法版本兼容性最好。校准数据通过model.quantize的calib_data参数传入如果不传AutoAWQ会用默认的校准集通常是pile数据集的子集。但我强烈建议自己传校准数据尤其是中文模型默认的英文校准集效果会打折扣。calib_data [你的校准文本1, 你的校准文本2, ...] model.quantize(tokenizer, quant_configquant_config, calib_datacalib_data)校准文本不需要太长每条几十到几百个token就行但数量要够一般512条起步。我通常会准备1000条左右覆盖不同的主题和长度。3.3 量化过程监控与显存占用分析量化过程中最需要关注的是显存占用和耗时。AutoAWQ在量化时会逐层处理每层的激活统计和缩放因子搜索都会消耗显存。如果你发现显存快爆了可以调小校准数据的batch size或者减少校准样本数量。我实测过一个7B模型的量化过程校准数据1000条每条平均128个token量化耗时大约15分钟峰值显存占用约14G。其中大部分显存被模型权重和激活值占用缩放因子搜索的额外开销不到1G。这也印证了标题里说的“仅保护1%显存开销”——量化过程本身的额外开销确实很小。量化完成后导出的模型大小值得关注。一个7B模型FP16大概是14GAWQ INT4量化后大约是3.5G到4G压缩比接近4倍。但实际部署时你还需要加上KV Cache和框架开销所以总显存占用不会是简单的四分之一。以16G卡为例FP16下7B模型只能跑很短的上下文AWQ INT4下可以跑到8K甚至16K上下文这就是量化带来的实际收益。3.4 推理部署与性能实测量化完的模型可以用多种框架部署。最简单的是用AutoAWQ自带的推理接口from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model AutoAWQForCausalLM.from_quantized(quant_path) tokenizer AutoTokenizer.from_pretrained(quant_path) inputs tokenizer(你的问题, return_tensorspt).to(cuda) outputs model.generate(**inputs, max_new_tokens256) print(tokenizer.decode(outputs[0]))但如果你追求极致性能建议用vLLM或TensorRT-LLM。vLLM对AWQ的支持很好启动命令大概是python -m vllm.entrypoints.openai.api_server \ --model your-quantized-model-path \ --quantization awq \ --dtype float16 \ --max-model-len 8192TensorRT-LLM的部署流程复杂一些需要先把AWQ模型转换成TensorRT引擎但转换后的推理速度是最快的。我在一张消费级显卡上对比过AutoAWQ原生推理每秒约45个tokenvLLM约75个tokenTensorRT-LLM约90个token。当然这个数字和具体模型、batch size、生成长度都有关系但趋势是明确的——框架优化对AWQ的加速效果影响很大。提示部署时注意max-model-len的设置它决定了KV Cache的预分配大小。设得太大浪费显存设得太小长文本会被截断。一般根据你的实际业务需求来定8K是一个比较通用的值。4. 常见问题与排查技巧实录4.1 量化后模型输出乱码或重复这是最常见的问题通常有几个原因。第一是校准数据质量太差比如全是乱码或者格式混乱的文本导致激活统计失真。解决办法是换一批干净的、多样化的校准数据。第二是量化位宽太低比如用了3bit甚至2bit模型容量不够了。可以尝试回到4bit或者增加保护比例。第三是模型架构不兼容有些自定义模型层没有被AWQ正确识别量化时被跳过了导致混合精度推理时出错。这种情况需要检查AutoAWQ的版本是否支持你的模型架构。我遇到过一次比较隐蔽的情况量化后的模型在短文本上正常但一超过512个token就开始重复输出。排查后发现是校准数据里没有长文本样本导致长序列下的激活分布没被覆盖。后来在校准集里加入了20%的长文本问题就解决了。4.2 推理速度不升反降理论上量化应该加速但有时候反而变慢了。原因通常是反量化开销太大或者推理框架没有针对INT4做优化。如果你用的是原生PyTorch推理没有专门的量化kernel那么反量化操作会引入额外的计算和内存访问速度可能还不如FP16。解决办法是换用支持AWQ的推理框架比如vLLM、TensorRT-LLM、llama.cpp等。这些框架都有专门的量化kernel能把反量化融合进矩阵乘法避免额外的内存往返。另外检查一下你的GPU是否支持INT4的硬件加速。较新的架构对低精度计算有专门优化老架构可能只能靠软件模拟加速效果有限。还有一个容易被忽略的点是batch size。量化模型在小batch下加速明显但在大batch下可能因为计算密度已经很高加速比反而下降。如果你的场景是离线批量推理建议实测一下不同batch size下的吞吐找到最优值。4.3 显存占用没有明显下降量化后显存没降多少通常是因为KV Cache和激活值占了大头。权重从FP16压到INT4确实省了四分之三的权重显存但如果你的上下文很长KV Cache可能比权重还大。这时候需要配合KV Cache量化或者paged attention来进一步压缩。另外检查一下推理框架是否真的加载了量化权重。有些框架在加载AWQ模型时如果配置不对会先把权重反量化成FP16再推理这样显存占用和FP16一样但速度还更慢。确保你的启动参数里正确指定了量化方式比如vLLM里的--quantization awq。还有一个细节是模型并行。如果你用多卡部署每张卡上的权重是分片的单卡显存占用会下降但卡间通信开销会增加。对于边缘端单卡场景这个不是问题对于多卡服务器场景需要权衡。4.4 常见问题速查表问题现象可能原因排查方法解决方案输出乱码/重复校准数据差、位宽过低、架构不兼容换校准集、升位宽、查版本用干净多样校准数据4bit起步推理变慢无反量化优化、GPU不支持INT4换框架、查GPU架构用vLLM/TensorRT-LLM部署显存没降KV Cache大、权重被反量化查框架配置、看上下文长度开KV Cache量化确认量化加载精度暴跌保护比例低、group size大调保护比例、调group size保护比例升到1%group size降到64量化过程OOM校准数据太多、batch size大减样本、减batch分批次校准开CPU offload4.5 独家避坑经验量化不是一劳永逸最后分享几个我踩坑总结出来的经验。第一量化后的模型一定要做全面评估不能只看loss或者perplexity。我习惯用一套覆盖问答、推理、代码、翻译的评测集来测每个任务至少100条样本这样才能发现潜在的问题。第二不同批次的校准数据会导致量化结果有细微差异如果你对复现性要求高建议固定随机种子和校准集。第三AWQ量化后的模型可以继续做微调但需要特殊的训练框架支持普通LoRA微调可能会破坏量化结构导致精度下降。还有一个实际部署中的小技巧如果你的显存实在紧张可以尝试AWQ量化加KV Cache量化的组合。KV Cache量化能把缓存从FP16压到INT8甚至INT4对于长上下文场景能省下大量显存。不过KV Cache量化对精度的影响比权重量化更敏感建议先在小范围测试再全量上线。我在实际使用中发现AWQ最适合的场景是边缘端单卡部署尤其是那些显存有限但又需要跑较大模型的场景。它用极小的额外开销换来了显著的精度保护和速度提升这个 trade-off 在当前的技术条件下是非常划算的。当然如果你的场景对精度要求极高或者硬件不支持低精度计算那可能还需要考虑其他方案。但就大多数本地部署和边缘推理的需求而言AWQ确实是当前最值得尝试的量化方案之一。 
长河君 · 2026/10/10 7:25:33 · 阅读 1.2k AWQ量化实战：仅1%显存开销实现3倍推理加速
1. 大模型量化困局与AWQ的破局思路1.1 为什么量化总是“翻车”从显存焦虑说起但凡在本地跑过大模型的人都经历过那种“显存就差一点点”的绝望。你手里可能是一张16G显存的卡想跑一个70亿参数的模型FP16精度下光权重就要吃掉14G再加上KV Cache、激活值、框架开销分分钟爆显存。于是大家自然而然想到量化——把FP16的权重压到INT4理论上显存直接砍到四分之一多出来的空间还能把上下文拉长一点。但现实往往很骨感。你兴冲冲地拿一个INT4量化模型跑起来发现输出质量断崖式下跌原本能答对的问题开始胡言乱语代码生成缺胳膊少腿数学推理直接摆烂。更气人的是有时候量化后的模型推理速度并没有提升多少延迟反而因为反量化操作变高了。这就是标题里说的“过拟合与高延迟诅咒”——量化不是简单的数值压缩它是一场在精度和效率之间的走钢丝。我踩过最典型的坑是用某套常规的权重量化方案把一个中文对话模型压到INT4结果模型在通用benchmark上看着还行但一到实际对话就露馅尤其是涉及长尾知识或者需要精细推理的场景表现惨不忍睹。后来才明白问题出在量化粒度上——粗粒度的per-tensor或者per-channel量化对所有权重一视同仁但大模型里不同通道的重要性差异极大有些通道承载了关键语义信息你把它压狠了模型就“失忆”了。1.2 AWQ的核心洞察不是所有权重都生而平等AWQ全称Activation-aware Weight Quantization翻译过来就是“激活感知的权重量化”。它的核心洞察非常朴素但极其深刻权重的的重要性不是由权重本身决定的而是由它对应的激活值决定的。打个比方一个团队里每个人都很重要但真正决定项目成败的往往是那几个关键角色。你裁员的时候不能按人头平均砍得看谁在关键任务上出力最多。AWQ就是干这个的——它通过分析校准数据在模型前向传播过程中的激活分布找出那些对输出影响最大的权重通道然后对这些通道进行保护让它们在量化时保留更高的精度。这里的关键在于“激活感知”四个字。传统的量化方法要么只看权重数值分布比如GPTQ要么用简单的统计量做缩放但AWQ发现真正需要保护的是那些对应大激活值的权重通道。因为在大模型里激活值往往呈现极端的离群点分布——少数通道的激活值可能是其他通道的几十倍甚至上百倍。这些离群通道如果被粗暴量化误差会被放大最终导致模型输出崩坏。AWQ的做法是对每个权重通道根据其对应激活值的幅度计算一个缩放因子。激活值大的通道缩放因子就大量化时保留更多有效位激活值小的通道可以压得更狠。这样一来量化误差被智能地分配到了不重要的通道上重要通道的精度得到了保护。1.3 仅保护1%显存开销背后的数学逻辑标题里说“仅保护1%显存开销”这个数字不是拍脑袋来的。AWQ在实现时并不是把重要通道单独拎出来用FP16存储——那样显存开销就大了。它的做法是在量化过程中引入一个缩放因子s对权重进行等价变换W W * s然后对W做量化推理时再除以s还原。这个缩放因子是per-channel的只需要存储一个向量相对于整个权重矩阵来说额外开销几乎可以忽略不计。具体来说假设权重矩阵是N×K量化后每个权重占4bit那么总显存是NK0.5字节。缩放因子向量长度是K如果用FP16存储额外开销是K*2字节。当N远大于1时大模型的权重矩阵N通常是几千到几万额外开销占比不到0.1%。即使加上一些实现上的对齐和元数据整体额外开销控制在1%以内是完全合理的。这个设计的精妙之处在于它没有改变量化的基本框架只是在量化前做了一次聪明的等价变换。你可以把它理解成“给重要通道戴上了一层保护罩”但这层保护罩本身几乎不占空间。相比之下有些混合精度方案会把重要通道单独用INT8或FP16存储显存开销直接翻倍部署时非常尴尬。1.4 推理暴增3倍的工程实现路径量化带来的推理加速理论上来自两个方面一是显存带宽压力降低因为权重从FP16变成INT4读取同样数量的权重只需要四分之一的带宽二是计算密度提升INT4的矩阵乘法在支持低精度计算的硬件上吞吐更高。但理论归理论实际能不能跑到3倍加速取决于推理框架的优化程度。AWQ的加速效果之所以显著是因为它和主流的推理引擎做了深度集成。比如在TensorRT-LLM里AWQ量化后的模型可以直接走INT4的GEMM kernel反量化操作被融合进了矩阵乘法内部不会产生额外的内存往返。在vLLM里AWQ也有专门的CUDA kernel支持能够实现高效的paged attention和量化推理。我实测下来在同样的硬件上一个7B模型用FP16跑大概是每秒30个token换成AWQ INT4之后能到每秒90个token左右差不多就是3倍。这个提升在长文本生成场景下感知特别明显——以前等一段500字的回复要十几秒现在五六秒就出来了。当然加速比和模型大小、batch size、硬件都有关系不是所有场景都能精确到3倍但方向是确定的。2. 核心细节解析与实操要点2.1 校准数据的选取决定量化成败的隐形之手AWQ的量化过程需要一小批校准数据来统计激活分布这批数据的选择直接决定了量化后模型的表现。很多人随便拿几百条通用文本就开跑结果量化出来的模型在特定任务上表现很差还以为是算法不行其实是校准数据没选对。校准数据的核心原则是分布要覆盖你实际推理时可能遇到的输入类型。如果你量化的是一个代码模型校准数据里就应该有足够多的代码片段如果你量化的是中文对话模型校准数据就应该包含多样化的中文对话场景。我一般会准备512到1024条校准样本长度控制在模型最大上下文的一半左右这样既能覆盖足够的激活模式又不会让校准过程太慢。还有一个细节是校准数据的顺序。AWQ在统计激活值时会逐层前向传播前面的层会影响后面的层。如果校准数据里全是短文本那么长文本场景下的激活分布就没被覆盖到量化后模型处理长文本时可能出问题。我的做法是混合不同长度的样本短句、段落、长文都放一些让激活统计更全面。注意校准数据不要用训练集里的数据否则量化后的评估结果会偏乐观。最好是从真实业务场景里采样或者用公开的评测集但只取输入部分不要用标签。2.2 缩放因子的搜索空间网格搜索与梯度优化的权衡AWQ在计算缩放因子时并不是直接解析求解而是在一个搜索空间里找最优值。具体来说它把缩放因子限制在一个合理的范围内然后通过网格搜索或者梯度优化的方式找到让量化误差最小的那个值。网格搜索的优点是稳定、可复现缺点是计算量大。如果每个通道都要搜几十个候选值整个量化过程可能要跑几个小时。梯度优化的优点是快但容易陷入局部最优而且对超参数敏感。AWQ的论文里提到他们用了一种基于激活感知的搜索策略实际上是在两者之间做了折中——先用激活统计量缩小搜索范围再在缩小的范围里做精细搜索。实操中如果你用的是现成的AWQ工具链比如AutoAWQ这些细节已经被封装好了你只需要指定校准数据集和量化配置就行。但如果你想自己调优可以关注两个参数一个是搜索的粒度粒度越细量化误差越小但耗时越长另一个是保护比例也就是有多大比例的通道被视为“重要通道”需要保护。保护比例太高显存开销上去了保护比例太低精度保不住。一般建议从1%开始试根据评估结果微调。2.3 量化粒度选择per-tensor、per-channel还是per-group量化粒度是影响精度和效率的关键参数。per-tensor是整个权重矩阵共用一个缩放因子实现最简单但精度最差per-channel是每个输出通道一个缩放因子精度好一些但存储开销增加per-group是把通道分成若干组每组一个缩放因子在精度和开销之间取得平衡。AWQ默认用的是per-group量化group size通常设为128。这个选择是有讲究的group size太小缩放因子太多存储开销和反量化开销都上去了group size太大组内通道的重要性差异被忽略精度下降。128是一个经验值在大多数模型上表现均衡。我试过把group size调到64精度确实有提升但推理速度掉了大概10%因为反量化时需要读取更多的缩放因子。调到256的话速度上去了但在一些对精度敏感的任務上比如数学推理会出现明显的质量下降。所以除非你有特殊需求否则128是一个比较稳妥的默认值。量化粒度精度表现显存开销推理速度适用场景per-tensor较差最低最快对精度要求极低的场景per-channel中等较低较快通用场景per-group (128)良好适中适中大多数大模型部署per-group (64)优秀较高较慢精度敏感任务2.4 与GPTQ的对比为什么AWQ更适合边缘端GPTQ和AWQ是当前最主流的两种训练后量化方案很多人纠结选哪个。我的经验是如果你追求极致的压缩率GPTQ可以做到3bit甚至2bit如果你追求精度和速度的平衡尤其是边缘端部署AWQ更合适。GPTQ的核心是逐层做二阶误差补偿量化过程比较慢而且对校准数据更敏感。AWQ的核心是激活感知的缩放量化过程相对快鲁棒性更好。在边缘端场景下硬件资源有限推理框架对量化格式的支持程度不一AWQ因为和TensorRT-LLM、vLLM等框架集成得更好部署起来更省心。还有一个实际因素是AWQ量化后的模型在低精度下的“崩溃点”更靠后。什么意思呢就是当你把量化位宽继续往下压的时候GPTQ可能在某個位宽突然精度暴跌而AWQ的下降曲线更平滑。这对于需要在不同硬件上灵活调整位宽的场景很重要。3. 实操过程与核心环节实现3.1 环境准备与工具链选型要跑通AWQ量化你需要准备三样东西一个支持CUDA的GPU环境、一套AWQ量化工具、一个待量化的模型。工具链方面目前最成熟的是AutoAWQ它封装了量化、校准、导出等全流程支持Hugging Face上的大多数模型架构。安装AutoAWQ很简单一条pip命令就行pip install autoawq但要注意版本兼容性。AutoAWQ对transformers、torch、CUDA版本都有要求版本不匹配会出现各种奇怪的错误。我建议用conda创建一个干净的环境然后按照官方文档的版本矩阵来装。比如transformers 4.40以上、torch 2.1以上、CUDA 11.8或12.1这些组合经过验证比较稳定。硬件方面量化一个7B模型大概需要16G显存13B模型需要24G到32G70B模型建议用多卡或者80G显存的卡。如果显存不够可以开启CPU offload但量化速度会慢很多。我试过用一张16G的卡量化13B模型开启offload后跑了将近两个小时而用32G的卡只要二十分钟。3.2 量化脚本编写与参数配置AutoAWQ的量化接口设计得很直观核心就是几行代码from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path your-model-path quant_path your-quantized-model-path quant_config { zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM } model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) model.quantize(tokenizer, quant_configquant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)这里有几个参数需要解释一下。zero_point设为True表示使用非对称量化对于激活值分布偏斜的情况更友好q_group_size就是前面说的分组大小w_bit是量化位宽4bit是当前最常用的version指定量化算法版本GEMM是通用矩阵乘法版本兼容性最好。校准数据通过model.quantize的calib_data参数传入如果不传AutoAWQ会用默认的校准集通常是pile数据集的子集。但我强烈建议自己传校准数据尤其是中文模型默认的英文校准集效果会打折扣。calib_data [你的校准文本1, 你的校准文本2, ...] model.quantize(tokenizer, quant_configquant_config, calib_datacalib_data)校准文本不需要太长每条几十到几百个token就行但数量要够一般512条起步。我通常会准备1000条左右覆盖不同的主题和长度。3.3 量化过程监控与显存占用分析量化过程中最需要关注的是显存占用和耗时。AutoAWQ在量化时会逐层处理每层的激活统计和缩放因子搜索都会消耗显存。如果你发现显存快爆了可以调小校准数据的batch size或者减少校准样本数量。我实测过一个7B模型的量化过程校准数据1000条每条平均128个token量化耗时大约15分钟峰值显存占用约14G。其中大部分显存被模型权重和激活值占用缩放因子搜索的额外开销不到1G。这也印证了标题里说的“仅保护1%显存开销”——量化过程本身的额外开销确实很小。量化完成后导出的模型大小值得关注。一个7B模型FP16大概是14GAWQ INT4量化后大约是3.5G到4G压缩比接近4倍。但实际部署时你还需要加上KV Cache和框架开销所以总显存占用不会是简单的四分之一。以16G卡为例FP16下7B模型只能跑很短的上下文AWQ INT4下可以跑到8K甚至16K上下文这就是量化带来的实际收益。3.4 推理部署与性能实测量化完的模型可以用多种框架部署。最简单的是用AutoAWQ自带的推理接口from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model AutoAWQForCausalLM.from_quantized(quant_path) tokenizer AutoTokenizer.from_pretrained(quant_path) inputs tokenizer(你的问题, return_tensorspt).to(cuda) outputs model.generate(**inputs, max_new_tokens256) print(tokenizer.decode(outputs[0]))但如果你追求极致性能建议用vLLM或TensorRT-LLM。vLLM对AWQ的支持很好启动命令大概是python -m vllm.entrypoints.openai.api_server \ --model your-quantized-model-path \ --quantization awq \ --dtype float16 \ --max-model-len 8192TensorRT-LLM的部署流程复杂一些需要先把AWQ模型转换成TensorRT引擎但转换后的推理速度是最快的。我在一张消费级显卡上对比过AutoAWQ原生推理每秒约45个tokenvLLM约75个tokenTensorRT-LLM约90个token。当然这个数字和具体模型、batch size、生成长度都有关系但趋势是明确的——框架优化对AWQ的加速效果影响很大。提示部署时注意max-model-len的设置它决定了KV Cache的预分配大小。设得太大浪费显存设得太小长文本会被截断。一般根据你的实际业务需求来定8K是一个比较通用的值。4. 常见问题与排查技巧实录4.1 量化后模型输出乱码或重复这是最常见的问题通常有几个原因。第一是校准数据质量太差比如全是乱码或者格式混乱的文本导致激活统计失真。解决办法是换一批干净的、多样化的校准数据。第二是量化位宽太低比如用了3bit甚至2bit模型容量不够了。可以尝试回到4bit或者增加保护比例。第三是模型架构不兼容有些自定义模型层没有被AWQ正确识别量化时被跳过了导致混合精度推理时出错。这种情况需要检查AutoAWQ的版本是否支持你的模型架构。我遇到过一次比较隐蔽的情况量化后的模型在短文本上正常但一超过512个token就开始重复输出。排查后发现是校准数据里没有长文本样本导致长序列下的激活分布没被覆盖。后来在校准集里加入了20%的长文本问题就解决了。4.2 推理速度不升反降理论上量化应该加速但有时候反而变慢了。原因通常是反量化开销太大或者推理框架没有针对INT4做优化。如果你用的是原生PyTorch推理没有专门的量化kernel那么反量化操作会引入额外的计算和内存访问速度可能还不如FP16。解决办法是换用支持AWQ的推理框架比如vLLM、TensorRT-LLM、llama.cpp等。这些框架都有专门的量化kernel能把反量化融合进矩阵乘法避免额外的内存往返。另外检查一下你的GPU是否支持INT4的硬件加速。较新的架构对低精度计算有专门优化老架构可能只能靠软件模拟加速效果有限。还有一个容易被忽略的点是batch size。量化模型在小batch下加速明显但在大batch下可能因为计算密度已经很高加速比反而下降。如果你的场景是离线批量推理建议实测一下不同batch size下的吞吐找到最优值。4.3 显存占用没有明显下降量化后显存没降多少通常是因为KV Cache和激活值占了大头。权重从FP16压到INT4确实省了四分之三的权重显存但如果你的上下文很长KV Cache可能比权重还大。这时候需要配合KV Cache量化或者paged attention来进一步压缩。另外检查一下推理框架是否真的加载了量化权重。有些框架在加载AWQ模型时如果配置不对会先把权重反量化成FP16再推理这样显存占用和FP16一样但速度还更慢。确保你的启动参数里正确指定了量化方式比如vLLM里的--quantization awq。还有一个细节是模型并行。如果你用多卡部署每张卡上的权重是分片的单卡显存占用会下降但卡间通信开销会增加。对于边缘端单卡场景这个不是问题对于多卡服务器场景需要权衡。4.4 常见问题速查表问题现象可能原因排查方法解决方案输出乱码/重复校准数据差、位宽过低、架构不兼容换校准集、升位宽、查版本用干净多样校准数据4bit起步推理变慢无反量化优化、GPU不支持INT4换框架、查GPU架构用vLLM/TensorRT-LLM部署显存没降KV Cache大、权重被反量化查框架配置、看上下文长度开KV Cache量化确认量化加载精度暴跌保护比例低、group size大调保护比例、调group size保护比例升到1%group size降到64量化过程OOM校准数据太多、batch size大减样本、减batch分批次校准开CPU offload4.5 独家避坑经验量化不是一劳永逸最后分享几个我踩坑总结出来的经验。第一量化后的模型一定要做全面评估不能只看loss或者perplexity。我习惯用一套覆盖问答、推理、代码、翻译的评测集来测每个任务至少100条样本这样才能发现潜在的问题。第二不同批次的校准数据会导致量化结果有细微差异如果你对复现性要求高建议固定随机种子和校准集。第三AWQ量化后的模型可以继续做微调但需要特殊的训练框架支持普通LoRA微调可能会破坏量化结构导致精度下降。还有一个实际部署中的小技巧如果你的显存实在紧张可以尝试AWQ量化加KV Cache量化的组合。KV Cache量化能把缓存从FP16压到INT8甚至INT4对于长上下文场景能省下大量显存。不过KV Cache量化对精度的影响比权重量化更敏感建议先在小范围测试再全量上线。我在实际使用中发现AWQ最适合的场景是边缘端单卡部署尤其是那些显存有限但又需要跑较大模型的场景。它用极小的额外开销换来了显著的精度保护和速度提升这个 trade-off 在当前的技术条件下是非常划算的。当然如果你的场景对精度要求极高或者硬件不支持低精度计算那可能还需要考虑其他方案。但就大多数本地部署和边缘推理的需求而言AWQ确实是当前最值得尝试的量化方案之一。