如果你最近在尝试把大模型塞进一块消费级显卡或者开发板大概率对“量化”这两个字是又爱又恨。爱的是INT4一套下来模型体积只剩四分之一显存一下子宽裕了恨的是压完之后生成质量经常悄悄滑坡更麻烦的是有些方案要求你拿一大包数据重新训一遍——训完还可能比原来更笨。直到AWQActivation-aware Weight Quantization激活感知权重量化出现局面才真正松动。它不重训、不过拟合、只保护约1%的关键权重通道却能把显存占用砍掉六成、推理速度拉到接近3倍把边缘端跑大模型从一个实验玩具变成了可以认真对待的工程方案。这篇文章我把自己在部署过程中对AWQ的理解、拆解和踩坑记录整理出来适合想上手INT4部署、又不想被PTQ精度波动折磨的读者。1. 为什么量化的第一步就踩在“过拟合”与“延迟”的双坑里1.1 FP16到INT4四倍缩水的诱惑与代价先从最朴素的账算起。一个7B参数规模的模型FP16权重占约14GB。换成INT4后权重只有约3.5GB。对现代消费级16GB显卡来说这几乎是“能不能跑”的分界线。推理时Decoder每生成一个token都要把全部权重从内存搬到计算单元这部分消耗占大头。按这个逻辑INT4权重让每次读取的数据量变成原来的四分之一理论上生成速度也应该最多快四倍。但很多人实现下来并没有四倍。原因不复杂其一权重读取确实少了可激活值、KV cache和中间状态仍以FP16读写它们也在竞争带宽其二INT4矩阵乘法在多数框架里要先反量化成FP16再计算反量化本身要消耗时间其三模型内部还有大量Norm层和加性残差它们是计算开销却不是权重带宽。真正到手的通常是一两倍运气好加工程优化才接近三倍。这还只是延迟的坑。更难受的是精度。INT4总共只有16个取值区间可LLM的权重分布并不均匀。少量权重会非常大它们像房间里的大象把整个量化区间撑得很宽剩下99%的普通权重只能挤在一起量化误差就被放大。换句话说INT4的精度损失主要不是平均损失而是个别离群值拖垮全盘。1.2 QAT的重训成本精度没保住过拟合先来了既然直接压精度容易崩传统补救方案就是QAT量化感知训练让模型带着“伪量化”误差做增量训练重新把权重学成对低精度更鲁棒的形态。听起来合理落地却有一道墙。第一道墙是算力。7B模型哪怕只训练几个epoch也要多卡GPU跑上几天而且校准数据清洗、训练配置、收敛判断这些工程细节随随便便占人一两周。第二道墙是过拟合。QAT本质上是在“校准集”上做有监督更新如果校准集和真实线上分布不一致模型会把这些新分布的模式学进去结果量化精度在benchmark上很漂亮上线却出现风格漂移、格式崩坏。我在实际项目中见过最典型的情况用一堆百科语料做QAT后模型在任务对话里回答变得越来越“百科腔”连简洁指令都听不懂。这就是重训练带来的过拟合后遗症。第三道墙是迭代成本。QAT每次改数据、改bit位宽都要重新训练试错成本极高PTQ则是几分钟出结果可以快速迭代。于是业界真正需要的是一个“不重训还尽量不掉点”的方案。AWQ就是在这条主线上撕开的口子。2. AWQ的破局点激活值暴露了权重的真实地位2.1 一个反直觉的实验观察做量化的人一开始都盯着权重本身看觉得绝对值大的权重就是重点保护对象。AWQ的研究者在实验里做了个对照把权重里绝对值最大的1%通道保持FP16结果精度并没有明显挽回转而把输入激活值最大的1%通道保持FP16精度反而几乎完全保住了。这个现象初看违背直觉细想很有道理。一个权重通道虽然数值大但如果它对应的前面通道的输入激活值常年很小它对下一层输出的实际贡献就有限。相反如果某通道的输入激活值经常很大权重再小乘积也会主导输出。所以判断权重量化该不该精细保护不能光看权重矩阵自己要看它在真实前向传播中被“用得多重”。这就是“激活感知”四个字的由来。用一个生活类比好理解一个员工A底薪很高但不干活另一个员工B底薪一般但每天经手大项目。公司裁员时直觉上该保A实际上保B才不伤筋动骨。权重的方式也一样数值大小不等于实际贡献大小激活频率才是。2.2 1%显著通道的标准怎么定具体操作里激活统计做起来并不玄。取几百条文本样本拼成batch在FP16模型上前向一遍在每一个Linear层入口处把输入激活张量记录成统计量。之后对每个通道把激活值的绝对值或平方在样本和序列长度维度上平均得到一个通道重要性向量。按重要性排序后AWQ取的是最靠前的约1%通道当作显著通道。实验证明把这一小撮通道在量化中单独保护效果远好于随机保护1%或者按权重范数保护1%。这里有个很容易做错的细节梯度级的“重要性”可以用二阶信息Hessian来估计但AWQ直接用激活幅值背后逻辑是激活幅值大意味着量化误差经由它缩放后对输出的扰动被放大。不需要求逆矩阵不需要多轮迭代这是它轻量的关键。当然1%不是铁律。不同模型、不同层最优保护比例会波动。对于某些结构简单的大模型严格只保1%已经够用对于敏感的头尾层工程上常放宽到2%~5%。这属于使用AWQ时的微调空间后面再展开。2.3 不保存混合精度缩放变换才是精髓读到这里的读者可能会想既然要保护1%的通道那就把它们直接存成FP16其他存INT4不就行了技术上可行但这给硬件出了个大难题。你想想一个矩阵乘法同时混着FP16和INT4两种数据格式显存排列是碎片的访存效率下降你为了“保护1%通道”反而拖慢了99%通道的带宽优势得不偿失。AWQ真正厉害的地方是它做到了“行为上像保护了1%存储上却完全统一INT4”。它靠的是缩放等价变换对一个权重矩阵W假设有一列通道需要重点保护引入一个缩放因子s把该列权重变成W*s同时把对应输入激活变成X/s矩阵乘法的结果理论上完全不变。但做完这步之后再去量化显著通道的权重值被放大了量化步长相对缩小误差异常变小而不显著通道被缩小到更容易被量化的区域。当然实际缩放因子不是人为指定而是按最小化加权量化误差的目标搜索出来的。s一般都取在0到1之间。取太小虽然显著通道精度更稳但普通通道会变成一个巨大负向误差取太大普通通道保住了显著通道又容易崩。这个“度”就是AWQ大部分论文细节在讨论的东西。这段逻辑讲清楚之后“仅保护1%显存开销还能锐降60%”就好理解了因为它并没有真的在显存里留出一块FP16区域只是用了一组几乎不占空间的缩放系数就把1%通道的精度给“保住”了。显存节省来自99%通道的INT4化精度保全来自那组精心挑选的缩放因子。3. AWQ量化流程逐段拆解3.1 激活统计阶段校准数据与工作负载AWQ的整个流程可以分成三个阶段。第一阶段是收集激活统计量。你需要一小批代表真实使用场景的文本通常几百条就够每条截断到几百个token。把它们按batch送进FP16模型跑一遍前向逐层保存Linear层输入激活。等所有batch跑完对每个通道做平均得到激活重要性向量。这一阶段实操时最容易翻车的是数据选择。我踩过的坑是直接用通用语料库随便截了200条就上结果模型在代码生成场景下量化后崩得很厉害。后来我给校准集里混了30%的代码类文本同样规模就稳多了。校准数据规模不必大但领域分布一定要贴合实际用途。另外绝不能拿评测集当校准集否则指标会虚高属于变相泄漏。还有一点激活统计建议在FP16基准模型上前向获得不要先量化再统计。因为你要的是“原始模型”的激活分布一旦先量化激活本身已经包含了量化扰动通道排名会被误差带偏。3.2 缩放因子搜索为什么是网格搜索拿到激活重要性后第二阶段就是对每个权重矩阵搜索缩放因子。目标是搜到一组s让量化后权重和原始权重的加权误差最小。加权误差中每个通道的权重就是这个通道的激活重要性激活越大的通道它的量化误差在loss里占比越高。目标函数可以写成这样一个示意形式实际AWQ代码的核心也是这个意思# 示意代码网格搜索单层缩放因子 def awq_scale_search(weight, act_activation, bits4, n_grid20): act_mean act_activation.abs().mean(dim(0, 1)) # 每个输入通道的平均激活幅度 best_scale 1.0 best_error float(inf) for s in torch.linspace(0.1, 1.0, n_grid): w_scaled weight * s q_w fake_quantize(w_scaled, bits) / s # 量化后反缩放 error ((weight - q_w) ** 2 * act_mean).mean() # 激活加权量化误差 if error best_error: best_error error best_scale s return best_scale为什么用网格搜索而不是梯度下降因为量化函数里有round它是阶梯状的梯度几乎处处为0反向传播求不出有效方向。网格搜索虽然看着笨但搜索空间只有一维候选s也就十几个每一层的计算量可以接受结果稳定可复现。论文里还会做一个跨通道的协同优化每次先固定别的通道只调整当前通道的scale迭代几次避免一起变动时通道间的误差互相干扰。这个细节决定了最终精度的天花板。搜索顺序上常规做法是从浅层到深层逐层处理。每一层量化完下一层看到的输入已经带上了量化误差但AWQ对这一点的容忍度很好。实操中可以每层独立搜索不必反复回环。3.3 量化后的模型推理落地操作与注意点第三阶段是把带缩放系数的权重真正打包成INT4并替换推理框架里的计算图。这里要留意三件事。第一embedding词表层和最终输出头通常保持FP16。词表动辄几万到十几万embedding矩阵虽然也是权重但对少样本任务的边际影响非常敏感压成INT4几乎一定会掉点而且它只占模型很小一部分显存不值得冒险。第二线性层本身在计算时有两种路线。路线A是“加载INT4权重→反量化成FP16→用FP16 GEMM计算”路线B是“加载INT4权重→直接用INT4/INT8混合精度kernel做GEMM最后再反量化输出”。路线B才是AWQ加速的主要来源。如果你部署完发现速度没有任何提升先检查是不是还在路线A上。注意很多框架默认情况下不支持INT4 kernel会在加载模型时悄悄回退到反量化FP16计算。一定要用profiler确认权重加载的实际格式再判断延迟数据是否有效。第三LayerNorm/RMSNorm这些归一化层的输入输出仍然是FP16它们不需要量化但它们的权重非常少且极度敏感千万别手滑也压成INT8。一个推荐的验证方法是量化完先跑几十条校准集外的样本对比FP16和量化模型输出的logits差异差异过大就检查是不是某个特殊算子不支持INT4而走了降级路径。4. 实测数据与坐实结论的复盘4.1 显存占用与体积7B级别模型的账本先把显存账算清楚。以7B模型为例FP16权重约14GBINT4权重约3.5GB。实际推理时还要算上KV cache取决于上下文长度、激活中间缓存和框架运行时开销。一个短上下文场景下FP16推理最低大约需要16GB勉强能跑INT4后大约5到6GB。从这个角度看总显存占用下降约60%是一个相当真实的结果而不是标题党的夸张。注意权重从FP16到INT4本身是75%的缩减为什么总显存只降60%因为embedding我通常还是FP16KV cache又是独立开销。所以如果你看到某个框架广告说“模型体积降75%”它说的是权重文件不是真实部署时的总显存。“锐降60%”谈的是部署侧实际收益两者口径不同。更大的模型更明显。一个70B量级的FP16权重有140GB需要多卡或高内存服务器INT4之后约35GB一张高端消费级显卡就能扛住。这种“让大模型从机房走进单卡”的变化才是AWQ对边缘端最有价值的部分。4.2 解码速度从“带宽瓶颈”到“翻倍收益”大模型文本生成是典型的带宽受限任务。生成阶段batch size通常只有1GPU计算单元吃不饱绝大多数时间都在等权重从显存搬过来。权重从14GB缩到3.5GB意味着同样带宽下读权重的耗时降为原来的四分之一还没算KV cache读取。所以条件满足时生成速度提升两倍到三倍是真实的。我在一个7B模型上看到的具体数字是FP16约4 token/sAWQ INT4约10到11 token/s提升约2.7倍。如果把上下文压短、batch固定为1、再用优化的反量化kernel突破3倍也不奇怪。但注意prefill阶段对长prompt一次性计算首token是计算密集与带宽混合的加速比通常只有1.3到1.8倍。端到端总时延是否3倍取决于你的应用里首token时延占比多少。如果是长文档、长prompt场景别指望那个“3倍”。4.3 精度损失困惑度、下游任务与幻觉精度方面典型的AWQ INT4结果会比FP16的困惑度上升约0.1到0.5明显小于朴素RTN那种动辄几个点的崩坏也通常优于依赖重训练的早期方案。下游任务指标视任务敏感度不同逻辑推理和代码类任务通常掉1到3个点情感分类这类简单任务几乎不掉开放式问答里的格式畸变可能变多。这里我想特别提醒不要在量化完只测一下困惑度就上线。困惑度是全体token的平均损失会掩盖个别层的严重退化。在项目中我习惯额外准备一组“压力测试”包括超长instruction、多轮对话、格式严格要求的输出JSON/表格逐个对比FP16和量化模型的输出。AWQ整体稳健但遇到一些极端长尾分布时量化模型偶尔会输出奇怪的重复或中文标点错乱这种问题要提前筛出来。建议上线前准备一组对抗性prompt专门测试格式、语气、长上下文记忆。量化的风险往往不在平均指标上而在长尾分布上。4.4 那些“标题党时刻”为什么不是所有场景都3倍速把标题拆开看AWQ、1%保护、显存砍60%、速度3倍、边缘端奠基——几乎每个数字都有它成立的前提。1%保护是“默认模型的普遍情况”不是每个层都严格1%显存60%是“包含embedding和KV cache的真实部署”不是权重文件对比速度3倍是“短上下文、小batch、有INT4内核优化”的理想条件。所以我建议读标题时保留一分冷静AWQ把“基础条件”做对了但把“收益取满”仍然需要工程配合。最典型的反例就是长上下文。上下文越长KV cache占显存和带宽的比例越高。当KV cache本身就占了物理内存一半时权重INT4省下来的带宽只是总带宽的一部分加速比会被稀释。这也是为什么AWQ适合对话场景、端侧小batch而不太适合超长文档离线分析。5. AWQ、GPTQ与QAT一张表看完PTQ家族的选型逻辑5.1 三者的本质区别与适用场景刚上手量化的同事经常问AWQ和GPTQ不是同一个东西吗其实它们是同一类问题训练后量化的两条不同路线和QAT则是完全不同的方法论。用一张表把差异理清方法是否需要重训核心机制校准数据需求典型部署场景AWQ否激活统计识别关键通道缩放等效保护几百条文本即可边缘端、快速PTQ、精度与速度平衡要求高GPTQ否用Hessian矩阵做逐层误差补偿需要较多样本来估计二阶统计服务器端PTQ成熟框架支持广QAT是训练中模拟量化让权重适应低精度大训练集加GPU算力对精度要求极高且有重训预算QAT理论上精度上限最高因为它让模型从头学习鲁棒量化表示。但它的成本不是普通人愿意承担的而且重训练过拟合的风险让它在模型快速迭代时代显得笨重。GPTQ的强项是数学完备逐层误差补偿更系统但对校准集的规模和分布更敏感。AWQ的聪明在于把问题简化为“谁重要就保护谁”用缩放系数把重要性编码进量化尺度天然更适合快速、低资源、边缘端这个目标。5.2 实践中混合使用的策略实际工程没有非此即彼。常见套路是先用AWQ快速出一版INT4跑一下业务指标如果可接受就直接上不行再叠加两个手段改善一是对敏感层比如输出头附近的FFN层提高到5比特或6比特代价是体积增加一点点二是对KV cache做增量量化从FP16降到INT8进一步省显存。另一个思路是“PTQ打底后续微调修复”。在AWQ量化后的模型上用少量领域数据做一个低秩适配微调可以针对性修复量化带来的领域偏斜。注意这时的微调要锁住量化权重只更新适配器避免把好不容易压下去的显存又练回去。选择方法论时我个人的判断标准是如果目标是快速部署、经常换模型优先AWQ如果项目预算充足、模型固定不变、精度是生死线可以认真做QAT如果已有框架只支持GPTQ导出而你不打算改推理栈那就用GPTQ起步并做好校准集控制。方法论只是工具业务指标才是最终裁判。6. 边缘端部署随笔AWQ帮你解决的第一千米与剩下的九千米6.1 设备端推理的硬件现实边缘端的魅力在于不需要机房不需要高速网络在手机、开发板、嵌入式盒子上本地跑模型。AWQ让1到2GB的INT4 7B模型成为现实但跑不跑得动还要看设备的具体条件。首先是带宽。很多边缘设备用的是统一内存架构CPU和GPU共享内存带宽往往远低于服务器显卡。可正因为带宽低INT4省带宽的优势反而更突出。同样带宽下FP16读一次权重的时间足够INT4读四次。我在开发板上实测FP16 7B的解码几乎是不可用的每秒1个tokenINT4后能到每秒3到4个token虽然还是慢但已经可以支撑语音助手这类非实时交互。其次是算子。边缘CPU通常没有专门的INT4 GEMM指令许多框架会先反量化成FP16再算普通乘法加速比打折扣。如果你所在平台还没有成熟的INT4 kernelAWQ的收益可能只体现在显存和内存占用上速度收益会小很多。计划做端侧部署前先查清目标推理引擎对per-channel scale和INT4 packing的支持情况不要等量化完了才发现导不进去。6.2 模型体积缩小之外的隐形成本AWQ把权重压缩了但边缘端的其他成本不会自动消失。词表embedding在低内存设备上可能成为瓶颈——一个几十万词表的中文模型embedding表就有几百MB这部分如果用FP16存甚至可能比INT4的Transformer主体还大。实际部署时也要算进去。另外端侧内存带宽与模型体积还可能受制于进程内其他应用或系统组件。我踩过的坑是模型本身只有2GB设备却预留了3GB内存结果系统后台一开相机内存溢出直接被杀死。所以边缘端部署必须把内存预算做硬约束而不是只看模型文件大小。还有一个隐性成本是发热。INT4虽然省带宽和功耗但矩阵乘法一旦被反复调用设备温度会上升触发降频后速度反而比FP16更差。长会话场景下有必要做温度监控和降级策略。6.3 多模态与更大量级的扩展方向AWQ的思想并没有被锁死在纯文本模型里。视觉语言模型的视觉编码器、投影层和跨模态注意力中大量线性层同样适用激活统计加缩放保护的思路。把图像、音频样本混入校准集做一次统计就可以把整个多模态模型压到INT4。虽然不同模态层的最优保护通道可能不同但流程完全一致。更大的模型也一样。一个400B级别的稀疏或稠密模型权重从FP8压到INT4后体积大幅缩小单台高内存工作站已经能跑再配合多卡分片就能做成服务。这里AWQ解决的是“权重装得下”剩下的还有通信、分片和推理引擎调度问题需要工程团队继续填坑。我自己目前的判断是AWQ已经把“训练后量化”这条路的门槛拉到了极低低到普通开发者也能用一把螺丝刀完成从前需要机修车间干一天的活。但它只是第一千米——算子库适配、内存预算、温度控制、业务侧评估每一千米都要自己拿脚量。先把一个7B模型用AWQ完整跑通再谈超大模型这个顺序我建议所有初学者照着走一遍。 
长河君 · 2026/10/10 18:49:11 · 阅读 1.2k AWQ量化：1%权重保护，让大模型在消费级显卡上高效运行
如果你最近在尝试把大模型塞进一块消费级显卡或者开发板大概率对“量化”这两个字是又爱又恨。爱的是INT4一套下来模型体积只剩四分之一显存一下子宽裕了恨的是压完之后生成质量经常悄悄滑坡更麻烦的是有些方案要求你拿一大包数据重新训一遍——训完还可能比原来更笨。直到AWQActivation-aware Weight Quantization激活感知权重量化出现局面才真正松动。它不重训、不过拟合、只保护约1%的关键权重通道却能把显存占用砍掉六成、推理速度拉到接近3倍把边缘端跑大模型从一个实验玩具变成了可以认真对待的工程方案。这篇文章我把自己在部署过程中对AWQ的理解、拆解和踩坑记录整理出来适合想上手INT4部署、又不想被PTQ精度波动折磨的读者。1. 为什么量化的第一步就踩在“过拟合”与“延迟”的双坑里1.1 FP16到INT4四倍缩水的诱惑与代价先从最朴素的账算起。一个7B参数规模的模型FP16权重占约14GB。换成INT4后权重只有约3.5GB。对现代消费级16GB显卡来说这几乎是“能不能跑”的分界线。推理时Decoder每生成一个token都要把全部权重从内存搬到计算单元这部分消耗占大头。按这个逻辑INT4权重让每次读取的数据量变成原来的四分之一理论上生成速度也应该最多快四倍。但很多人实现下来并没有四倍。原因不复杂其一权重读取确实少了可激活值、KV cache和中间状态仍以FP16读写它们也在竞争带宽其二INT4矩阵乘法在多数框架里要先反量化成FP16再计算反量化本身要消耗时间其三模型内部还有大量Norm层和加性残差它们是计算开销却不是权重带宽。真正到手的通常是一两倍运气好加工程优化才接近三倍。这还只是延迟的坑。更难受的是精度。INT4总共只有16个取值区间可LLM的权重分布并不均匀。少量权重会非常大它们像房间里的大象把整个量化区间撑得很宽剩下99%的普通权重只能挤在一起量化误差就被放大。换句话说INT4的精度损失主要不是平均损失而是个别离群值拖垮全盘。1.2 QAT的重训成本精度没保住过拟合先来了既然直接压精度容易崩传统补救方案就是QAT量化感知训练让模型带着“伪量化”误差做增量训练重新把权重学成对低精度更鲁棒的形态。听起来合理落地却有一道墙。第一道墙是算力。7B模型哪怕只训练几个epoch也要多卡GPU跑上几天而且校准数据清洗、训练配置、收敛判断这些工程细节随随便便占人一两周。第二道墙是过拟合。QAT本质上是在“校准集”上做有监督更新如果校准集和真实线上分布不一致模型会把这些新分布的模式学进去结果量化精度在benchmark上很漂亮上线却出现风格漂移、格式崩坏。我在实际项目中见过最典型的情况用一堆百科语料做QAT后模型在任务对话里回答变得越来越“百科腔”连简洁指令都听不懂。这就是重训练带来的过拟合后遗症。第三道墙是迭代成本。QAT每次改数据、改bit位宽都要重新训练试错成本极高PTQ则是几分钟出结果可以快速迭代。于是业界真正需要的是一个“不重训还尽量不掉点”的方案。AWQ就是在这条主线上撕开的口子。2. AWQ的破局点激活值暴露了权重的真实地位2.1 一个反直觉的实验观察做量化的人一开始都盯着权重本身看觉得绝对值大的权重就是重点保护对象。AWQ的研究者在实验里做了个对照把权重里绝对值最大的1%通道保持FP16结果精度并没有明显挽回转而把输入激活值最大的1%通道保持FP16精度反而几乎完全保住了。这个现象初看违背直觉细想很有道理。一个权重通道虽然数值大但如果它对应的前面通道的输入激活值常年很小它对下一层输出的实际贡献就有限。相反如果某通道的输入激活值经常很大权重再小乘积也会主导输出。所以判断权重量化该不该精细保护不能光看权重矩阵自己要看它在真实前向传播中被“用得多重”。这就是“激活感知”四个字的由来。用一个生活类比好理解一个员工A底薪很高但不干活另一个员工B底薪一般但每天经手大项目。公司裁员时直觉上该保A实际上保B才不伤筋动骨。权重的方式也一样数值大小不等于实际贡献大小激活频率才是。2.2 1%显著通道的标准怎么定具体操作里激活统计做起来并不玄。取几百条文本样本拼成batch在FP16模型上前向一遍在每一个Linear层入口处把输入激活张量记录成统计量。之后对每个通道把激活值的绝对值或平方在样本和序列长度维度上平均得到一个通道重要性向量。按重要性排序后AWQ取的是最靠前的约1%通道当作显著通道。实验证明把这一小撮通道在量化中单独保护效果远好于随机保护1%或者按权重范数保护1%。这里有个很容易做错的细节梯度级的“重要性”可以用二阶信息Hessian来估计但AWQ直接用激活幅值背后逻辑是激活幅值大意味着量化误差经由它缩放后对输出的扰动被放大。不需要求逆矩阵不需要多轮迭代这是它轻量的关键。当然1%不是铁律。不同模型、不同层最优保护比例会波动。对于某些结构简单的大模型严格只保1%已经够用对于敏感的头尾层工程上常放宽到2%~5%。这属于使用AWQ时的微调空间后面再展开。2.3 不保存混合精度缩放变换才是精髓读到这里的读者可能会想既然要保护1%的通道那就把它们直接存成FP16其他存INT4不就行了技术上可行但这给硬件出了个大难题。你想想一个矩阵乘法同时混着FP16和INT4两种数据格式显存排列是碎片的访存效率下降你为了“保护1%通道”反而拖慢了99%通道的带宽优势得不偿失。AWQ真正厉害的地方是它做到了“行为上像保护了1%存储上却完全统一INT4”。它靠的是缩放等价变换对一个权重矩阵W假设有一列通道需要重点保护引入一个缩放因子s把该列权重变成W*s同时把对应输入激活变成X/s矩阵乘法的结果理论上完全不变。但做完这步之后再去量化显著通道的权重值被放大了量化步长相对缩小误差异常变小而不显著通道被缩小到更容易被量化的区域。当然实际缩放因子不是人为指定而是按最小化加权量化误差的目标搜索出来的。s一般都取在0到1之间。取太小虽然显著通道精度更稳但普通通道会变成一个巨大负向误差取太大普通通道保住了显著通道又容易崩。这个“度”就是AWQ大部分论文细节在讨论的东西。这段逻辑讲清楚之后“仅保护1%显存开销还能锐降60%”就好理解了因为它并没有真的在显存里留出一块FP16区域只是用了一组几乎不占空间的缩放系数就把1%通道的精度给“保住”了。显存节省来自99%通道的INT4化精度保全来自那组精心挑选的缩放因子。3. AWQ量化流程逐段拆解3.1 激活统计阶段校准数据与工作负载AWQ的整个流程可以分成三个阶段。第一阶段是收集激活统计量。你需要一小批代表真实使用场景的文本通常几百条就够每条截断到几百个token。把它们按batch送进FP16模型跑一遍前向逐层保存Linear层输入激活。等所有batch跑完对每个通道做平均得到激活重要性向量。这一阶段实操时最容易翻车的是数据选择。我踩过的坑是直接用通用语料库随便截了200条就上结果模型在代码生成场景下量化后崩得很厉害。后来我给校准集里混了30%的代码类文本同样规模就稳多了。校准数据规模不必大但领域分布一定要贴合实际用途。另外绝不能拿评测集当校准集否则指标会虚高属于变相泄漏。还有一点激活统计建议在FP16基准模型上前向获得不要先量化再统计。因为你要的是“原始模型”的激活分布一旦先量化激活本身已经包含了量化扰动通道排名会被误差带偏。3.2 缩放因子搜索为什么是网格搜索拿到激活重要性后第二阶段就是对每个权重矩阵搜索缩放因子。目标是搜到一组s让量化后权重和原始权重的加权误差最小。加权误差中每个通道的权重就是这个通道的激活重要性激活越大的通道它的量化误差在loss里占比越高。目标函数可以写成这样一个示意形式实际AWQ代码的核心也是这个意思# 示意代码网格搜索单层缩放因子 def awq_scale_search(weight, act_activation, bits4, n_grid20): act_mean act_activation.abs().mean(dim(0, 1)) # 每个输入通道的平均激活幅度 best_scale 1.0 best_error float(inf) for s in torch.linspace(0.1, 1.0, n_grid): w_scaled weight * s q_w fake_quantize(w_scaled, bits) / s # 量化后反缩放 error ((weight - q_w) ** 2 * act_mean).mean() # 激活加权量化误差 if error best_error: best_error error best_scale s return best_scale为什么用网格搜索而不是梯度下降因为量化函数里有round它是阶梯状的梯度几乎处处为0反向传播求不出有效方向。网格搜索虽然看着笨但搜索空间只有一维候选s也就十几个每一层的计算量可以接受结果稳定可复现。论文里还会做一个跨通道的协同优化每次先固定别的通道只调整当前通道的scale迭代几次避免一起变动时通道间的误差互相干扰。这个细节决定了最终精度的天花板。搜索顺序上常规做法是从浅层到深层逐层处理。每一层量化完下一层看到的输入已经带上了量化误差但AWQ对这一点的容忍度很好。实操中可以每层独立搜索不必反复回环。3.3 量化后的模型推理落地操作与注意点第三阶段是把带缩放系数的权重真正打包成INT4并替换推理框架里的计算图。这里要留意三件事。第一embedding词表层和最终输出头通常保持FP16。词表动辄几万到十几万embedding矩阵虽然也是权重但对少样本任务的边际影响非常敏感压成INT4几乎一定会掉点而且它只占模型很小一部分显存不值得冒险。第二线性层本身在计算时有两种路线。路线A是“加载INT4权重→反量化成FP16→用FP16 GEMM计算”路线B是“加载INT4权重→直接用INT4/INT8混合精度kernel做GEMM最后再反量化输出”。路线B才是AWQ加速的主要来源。如果你部署完发现速度没有任何提升先检查是不是还在路线A上。注意很多框架默认情况下不支持INT4 kernel会在加载模型时悄悄回退到反量化FP16计算。一定要用profiler确认权重加载的实际格式再判断延迟数据是否有效。第三LayerNorm/RMSNorm这些归一化层的输入输出仍然是FP16它们不需要量化但它们的权重非常少且极度敏感千万别手滑也压成INT8。一个推荐的验证方法是量化完先跑几十条校准集外的样本对比FP16和量化模型输出的logits差异差异过大就检查是不是某个特殊算子不支持INT4而走了降级路径。4. 实测数据与坐实结论的复盘4.1 显存占用与体积7B级别模型的账本先把显存账算清楚。以7B模型为例FP16权重约14GBINT4权重约3.5GB。实际推理时还要算上KV cache取决于上下文长度、激活中间缓存和框架运行时开销。一个短上下文场景下FP16推理最低大约需要16GB勉强能跑INT4后大约5到6GB。从这个角度看总显存占用下降约60%是一个相当真实的结果而不是标题党的夸张。注意权重从FP16到INT4本身是75%的缩减为什么总显存只降60%因为embedding我通常还是FP16KV cache又是独立开销。所以如果你看到某个框架广告说“模型体积降75%”它说的是权重文件不是真实部署时的总显存。“锐降60%”谈的是部署侧实际收益两者口径不同。更大的模型更明显。一个70B量级的FP16权重有140GB需要多卡或高内存服务器INT4之后约35GB一张高端消费级显卡就能扛住。这种“让大模型从机房走进单卡”的变化才是AWQ对边缘端最有价值的部分。4.2 解码速度从“带宽瓶颈”到“翻倍收益”大模型文本生成是典型的带宽受限任务。生成阶段batch size通常只有1GPU计算单元吃不饱绝大多数时间都在等权重从显存搬过来。权重从14GB缩到3.5GB意味着同样带宽下读权重的耗时降为原来的四分之一还没算KV cache读取。所以条件满足时生成速度提升两倍到三倍是真实的。我在一个7B模型上看到的具体数字是FP16约4 token/sAWQ INT4约10到11 token/s提升约2.7倍。如果把上下文压短、batch固定为1、再用优化的反量化kernel突破3倍也不奇怪。但注意prefill阶段对长prompt一次性计算首token是计算密集与带宽混合的加速比通常只有1.3到1.8倍。端到端总时延是否3倍取决于你的应用里首token时延占比多少。如果是长文档、长prompt场景别指望那个“3倍”。4.3 精度损失困惑度、下游任务与幻觉精度方面典型的AWQ INT4结果会比FP16的困惑度上升约0.1到0.5明显小于朴素RTN那种动辄几个点的崩坏也通常优于依赖重训练的早期方案。下游任务指标视任务敏感度不同逻辑推理和代码类任务通常掉1到3个点情感分类这类简单任务几乎不掉开放式问答里的格式畸变可能变多。这里我想特别提醒不要在量化完只测一下困惑度就上线。困惑度是全体token的平均损失会掩盖个别层的严重退化。在项目中我习惯额外准备一组“压力测试”包括超长instruction、多轮对话、格式严格要求的输出JSON/表格逐个对比FP16和量化模型的输出。AWQ整体稳健但遇到一些极端长尾分布时量化模型偶尔会输出奇怪的重复或中文标点错乱这种问题要提前筛出来。建议上线前准备一组对抗性prompt专门测试格式、语气、长上下文记忆。量化的风险往往不在平均指标上而在长尾分布上。4.4 那些“标题党时刻”为什么不是所有场景都3倍速把标题拆开看AWQ、1%保护、显存砍60%、速度3倍、边缘端奠基——几乎每个数字都有它成立的前提。1%保护是“默认模型的普遍情况”不是每个层都严格1%显存60%是“包含embedding和KV cache的真实部署”不是权重文件对比速度3倍是“短上下文、小batch、有INT4内核优化”的理想条件。所以我建议读标题时保留一分冷静AWQ把“基础条件”做对了但把“收益取满”仍然需要工程配合。最典型的反例就是长上下文。上下文越长KV cache占显存和带宽的比例越高。当KV cache本身就占了物理内存一半时权重INT4省下来的带宽只是总带宽的一部分加速比会被稀释。这也是为什么AWQ适合对话场景、端侧小batch而不太适合超长文档离线分析。5. AWQ、GPTQ与QAT一张表看完PTQ家族的选型逻辑5.1 三者的本质区别与适用场景刚上手量化的同事经常问AWQ和GPTQ不是同一个东西吗其实它们是同一类问题训练后量化的两条不同路线和QAT则是完全不同的方法论。用一张表把差异理清方法是否需要重训核心机制校准数据需求典型部署场景AWQ否激活统计识别关键通道缩放等效保护几百条文本即可边缘端、快速PTQ、精度与速度平衡要求高GPTQ否用Hessian矩阵做逐层误差补偿需要较多样本来估计二阶统计服务器端PTQ成熟框架支持广QAT是训练中模拟量化让权重适应低精度大训练集加GPU算力对精度要求极高且有重训预算QAT理论上精度上限最高因为它让模型从头学习鲁棒量化表示。但它的成本不是普通人愿意承担的而且重训练过拟合的风险让它在模型快速迭代时代显得笨重。GPTQ的强项是数学完备逐层误差补偿更系统但对校准集的规模和分布更敏感。AWQ的聪明在于把问题简化为“谁重要就保护谁”用缩放系数把重要性编码进量化尺度天然更适合快速、低资源、边缘端这个目标。5.2 实践中混合使用的策略实际工程没有非此即彼。常见套路是先用AWQ快速出一版INT4跑一下业务指标如果可接受就直接上不行再叠加两个手段改善一是对敏感层比如输出头附近的FFN层提高到5比特或6比特代价是体积增加一点点二是对KV cache做增量量化从FP16降到INT8进一步省显存。另一个思路是“PTQ打底后续微调修复”。在AWQ量化后的模型上用少量领域数据做一个低秩适配微调可以针对性修复量化带来的领域偏斜。注意这时的微调要锁住量化权重只更新适配器避免把好不容易压下去的显存又练回去。选择方法论时我个人的判断标准是如果目标是快速部署、经常换模型优先AWQ如果项目预算充足、模型固定不变、精度是生死线可以认真做QAT如果已有框架只支持GPTQ导出而你不打算改推理栈那就用GPTQ起步并做好校准集控制。方法论只是工具业务指标才是最终裁判。6. 边缘端部署随笔AWQ帮你解决的第一千米与剩下的九千米6.1 设备端推理的硬件现实边缘端的魅力在于不需要机房不需要高速网络在手机、开发板、嵌入式盒子上本地跑模型。AWQ让1到2GB的INT4 7B模型成为现实但跑不跑得动还要看设备的具体条件。首先是带宽。很多边缘设备用的是统一内存架构CPU和GPU共享内存带宽往往远低于服务器显卡。可正因为带宽低INT4省带宽的优势反而更突出。同样带宽下FP16读一次权重的时间足够INT4读四次。我在开发板上实测FP16 7B的解码几乎是不可用的每秒1个tokenINT4后能到每秒3到4个token虽然还是慢但已经可以支撑语音助手这类非实时交互。其次是算子。边缘CPU通常没有专门的INT4 GEMM指令许多框架会先反量化成FP16再算普通乘法加速比打折扣。如果你所在平台还没有成熟的INT4 kernelAWQ的收益可能只体现在显存和内存占用上速度收益会小很多。计划做端侧部署前先查清目标推理引擎对per-channel scale和INT4 packing的支持情况不要等量化完了才发现导不进去。6.2 模型体积缩小之外的隐形成本AWQ把权重压缩了但边缘端的其他成本不会自动消失。词表embedding在低内存设备上可能成为瓶颈——一个几十万词表的中文模型embedding表就有几百MB这部分如果用FP16存甚至可能比INT4的Transformer主体还大。实际部署时也要算进去。另外端侧内存带宽与模型体积还可能受制于进程内其他应用或系统组件。我踩过的坑是模型本身只有2GB设备却预留了3GB内存结果系统后台一开相机内存溢出直接被杀死。所以边缘端部署必须把内存预算做硬约束而不是只看模型文件大小。还有一个隐性成本是发热。INT4虽然省带宽和功耗但矩阵乘法一旦被反复调用设备温度会上升触发降频后速度反而比FP16更差。长会话场景下有必要做温度监控和降级策略。6.3 多模态与更大量级的扩展方向AWQ的思想并没有被锁死在纯文本模型里。视觉语言模型的视觉编码器、投影层和跨模态注意力中大量线性层同样适用激活统计加缩放保护的思路。把图像、音频样本混入校准集做一次统计就可以把整个多模态模型压到INT4。虽然不同模态层的最优保护通道可能不同但流程完全一致。更大的模型也一样。一个400B级别的稀疏或稠密模型权重从FP8压到INT4后体积大幅缩小单台高内存工作站已经能跑再配合多卡分片就能做成服务。这里AWQ解决的是“权重装得下”剩下的还有通信、分片和推理引擎调度问题需要工程团队继续填坑。我自己目前的判断是AWQ已经把“训练后量化”这条路的门槛拉到了极低低到普通开发者也能用一把螺丝刀完成从前需要机修车间干一天的活。但它只是第一千米——算子库适配、内存预算、温度控制、业务侧评估每一千米都要自己拿脚量。先把一个7B模型用AWQ完整跑通再谈超大模型这个顺序我建议所有初学者照着走一遍。