大模型量化这件事我从早期做INT8 PTQ那会儿就开始跟一路踩坑到现在。说实话量化方法层出不穷但真正让我觉得这东西能上生产的AWQActivation-aware Weight Quantization算一个。它最吸引我的点不是那些宣传数字而是一个很朴素的观察权重的重要性不是均匀的只有极少数通道真正决定模型输出质量把这部分保护好剩下的随便压。这个思路听起来简单但落地效果确实猛。按照论文和后续大量实测AWQ在INT4权重量化下仅需保护约1%的显著权重困惑度PPL几乎不掉显存占用相比FP16直降60%以上推理吞吐在边缘设备上能拉到3倍左右。对于显存焦虑严重的本地部署场景——比如16G显存想跑大参数模型、或者想在消费级显卡上做多路并发——这套方案基本是绕不开的。这篇文章我不打算复述论文而是从工程落地的角度把AWQ到底怎么工作、为什么有效、实际部署时哪些参数要调、哪些坑必须避一条条拆开讲。适合已经了解基础量化概念、准备把模型真正跑起来的同学也适合刚接触量化、想搞清楚为什么大家都推AWQ的读者。1. 量化过拟合与延迟诅咒AWQ要解决的两个真实痛点1.1 传统RTN量化为什么在低比特下崩得厉害先说说最朴素的量化方法RTNRound-To-Nearest。它的逻辑简单到粗暴把每个权重值四舍五入到最近的量化格点。问题在于它假设所有参数同等重要。但神经网络里权重的分布是高度不均匀的——大部分权重集中在0附近少数离群值outlier承担了关键的激活响应。当你用INT4去压一个权重矩阵时量化步长变大那些离群值一旦被抹平对应的激活通道输出就会严重偏移。更麻烦的是这种误差会在层与层之间累积放大。我实测过一个7B级别的模型纯RTN INT4量化后PPL从原始的5.6直接飙到8以上生成内容开始出现明显的重复和逻辑断裂。这就是所谓的量化过拟合——不是模型在训练集上过拟合而是量化误差对某些关键通道过度敏感导致整体表现塌方。GPTQ通过二阶信息Hessian近似来补偿误差效果好但计算开销大量化一个7B模型动辄几十分钟到几小时而且对校准集敏感。1.2 高延迟从哪来反量化与内存带宽的双重夹击延迟问题更隐蔽。很多人以为量化只是省显存其实推理延迟的大头在内存带宽。FP16推理时每读一个权重就要做一次乘加INT4推理时权重虽然只占1/4空间但计算前必须先反量化回FP16这个反量化操作如果实现得不好反而会引入额外开销。另一个延迟来源是**分组量化group-wise quantization**的粒度。分组越细精度越高但每组都要存scale和zero-point元数据膨胀访存模式变碎GPU的coalesced access被打断实际吞吐反而下降。我见过有人把group_size设成32结果推理速度比group_size128还慢就是因为元数据访存成了瓶颈。AWQ的设计恰好在这两个痛点上做了权衡用激活感知保护关键权重解决过拟合用per-channel scale而非复杂分组控制延迟。1.3 AWQ的核心洞察激活比权重更能说明谁重要这是AWQ最漂亮的地方。传统方法看权重本身的数值大小来判断重要性但AWQ说应该看这个权重对应的输入激活有多大。道理很直白。一个权重w它参与的计算是w·x。如果x激活很大那么w的微小扰动会被放大如果x很小w怎么变都无所谓。所以真正该保护的是大激活通道对应的权重而不是数值大的权重。基于这个洞察AWQ的做法是对每个输入通道根据其激活的幅值计算一个缩放因子s把重要通道的权重大幅放大同时把对应激活缩小这样量化时这些权重的相对误差就变小了。数学上等价于对权重做per-channel scaling但scale的选取是激活驱动的。注意这里的保护1%指的是被显著放大的通道比例。实测中真正需要重点保护的通道通常只占总通道数的0.1%~1%其余通道即使量化粗糙也不影响最终输出。2. AWQ的数学骨架缩放因子怎么算、为什么这么算2.1 从量化误差公式推导缩放的必要性设权重w量化操作Q(w)量化误差为Δw Q(w) - w。对于线性层输出y w·x误差传播为Δy Δw·x。我们的目标是最小化|Δy|。如果对权重做缩放w w · s对应激活x x / s那么输出y w·x保持不变。但量化误差变成Δw Q(w·s) - w·s传播到输出是Δy Δw · x (Q(w·s) - w·s) · (x/s)。关键来了当s增大时w·s的数值变大相对量化步长步长固定下的相对误差变小即(Q(w·s) - w·s)/(w·s)减小。同时x/s减小。两者相乘如果s选得好Δy的绝对值可以显著降低。这就是AWQ的数学本质通过per-channel scaling把量化误差从重要通道转移到不重要通道。2.2 缩放因子的搜索为什么用网格搜索而不是解析解理论上可以求最优s的解析解但实际中量化函数Q是非线性的round操作解析解不成立。AWQ采用的做法是在一个对数网格上搜索s目标是最小化量化后输出的MSE。具体来说对每个通道搜索范围通常设为[0.5, 2.0]之类的区间取若干候选值比如20个对每个候选计算量化误差选最小的。这个搜索是per-channel独立的可以并行所以整体开销可控。我实测下来这个搜索过程对7B模型大概几分钟比GPTQ快一个数量级。而且因为只搜一个标量内存占用极小。2.3 与GPTQ、SmoothQuant的路线差异这里必须做个对比否则容易混淆。方法核心思路量化对象校准开销典型精度RTN直接round权重无差GPTQ二阶误差补偿权重高好SmoothQuant激活-权重均衡权重激活中好W8A8AWQ激活感知缩放权重低好W4A16SmoothQuant是把激活的难度平滑到权重上主要解决激活量化难的问题适合W8A8。AWQ则是纯权重量化W4A16激活保持FP16所以它不需要处理激活量化的动态范围问题专注把权重压到4bit。这个路线差异决定了AWQ的部署更简单激活还是FP16kernel改动小现有推理框架容易集成。2.4 为什么仅保护1%就够激活分布的稀疏性这一点很多人没想明白。神经网络激活经过ReLU或GELU后本身就有稀疏性即使没有激活幅值的分布也是长尾的——少数通道的激活值比中位数高一两个数量级。AWQ的缩放本质上是按激活幅值分配保护预算。长尾分布意味着只要保护头部那1%的通道就能覆盖绝大部分的误差贡献。剩下的99%通道即使量化误差大因为它们对应的激活本来就小对输出的影响可以忽略。我在一个13B模型上做过消融保护比例从0.1%提到1%PPL改善明显从1%提到5%改善微乎其微。这验证了1%这个量级的合理性。3. 实操从模型到AWQ量化权重再到推理的完整链路3.1 环境准备与依赖版本的那些坑AWQ的官方实现主要在llm-awq和autoawq两个仓库。我推荐用autoawq因为它和HuggingFace生态集成好API简洁。pip install autoawq pip install transformers accelerate版本上有个大坑autoawq对transformers版本敏感。我遇到过transformers 4.36和autoawq 0.1.8不兼容加载模型时报KeyError: model.layers。稳妥做法是锁定版本组合比如autoawq 0.2.x配transformers 4.40。CUDA版本也要注意。AWQ的量化kernel需要CUDA 11.8以上且对compute capability有要求。老卡如Pascal架构不支持INT4的fast kernel会回退到慢速路径这时候量化反而可能变慢。提示量化前先跑一遍nvidia-smi确认CUDA版本再用torch.cuda.get_device_capability()确认算力。算力低于7.0的卡建议直接放弃INT4 kernel加速只把它当显存压缩手段。3.2 校准数据的选择不是越多越好AWQ需要校准数据来统计激活分布。官方默认用pileval数据集取512条样本每条512 token。我的经验是校准数据的领域要贴近你的实际使用场景。如果你要做代码生成就用代码数据校准做中文对话就用中文语料。用英文通用语料校准出来的模型在中文任务上PPL可能差0.3~0.5。样本数量上128~512条足够。我试过用2048条精度提升不到0.05 PPL但量化时间翻倍。性价比很低。from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path your-model-path quant_path your-model-awq-int4 model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) quant_config { zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM } model.quantize(tokenizer, quant_configquant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)3.3 group_size与zero_point的取舍逻辑q_group_size是AWQ最重要的超参。它决定了每多少个权重共享一个scale。group_size128默认值精度和速度平衡好。group_size64精度略升元数据翻倍速度略降。group_size-1per-channel精度最高但kernel支持差实际很少用。我实测在7B模型上group_size从128降到64PPL改善约0.1但推理速度下降8%~12%。除非你对精度极度敏感否则128是甜点。zero_point建议开True。它允许量化区间非对称对ReLU后的权重分布更友好。关掉它省一点元数据但精度损失在低比特下会被放大。3.4 量化后必做的三项验证量化完别急着上线先做这三件事PPL对比在留出集上算量化前后的PPL差距超过0.5要警惕。生成质量抽检跑20~50条真实prompt人眼看有没有重复、乱码、逻辑断裂。显存与延迟实测用torch.cuda.max_memory_allocated()测显存用time.perf_counter()测首token延迟和吞吐。我见过PPL只差0.2但生成质量明显下降的案例原因是PPL是平均指标掩盖了长尾case的崩坏。所以人眼抽检不能省。4. 边缘端部署显存账怎么算、延迟怎么压4.1 显存占用的逐项拆解很多人问16G显存能跑多大的AWQ模型这得算细账。以7B模型INT4为例项目占用权重INT4约3.5GB激活FP16batch1约0.5~1GBKV Cache2048上下文约1~2GB框架开销约0.5GB合计约6~7GB所以16G显存跑7B AWQ绰绰有余甚至能上13B约7GB权重开销总10~12GB。但如果你要长上下文8K以上KV Cache会暴涨这时候得考虑KV量化或PagedAttention。4.2 推理框架选型vLLM、TensorRT-LLM还是llama.cpp不同框架对AWQ的支持和优化差异很大vLLM对AWQ支持成熟PagedAttention管理KV Cache吞吐高适合服务端。TensorRT-LLMkernel优化最狠延迟最低但编译流程复杂适合固定模型的生产环境。llama.cppCPU/边缘设备友好支持AWQ格式转换适合资源受限场景。我的建议服务端用vLLM边缘设备用llama.cpp追求极致延迟用TensorRT-LLM。三者都支持AWQ权重迁移成本不高。4.3 实测延迟数据与瓶颈定位在一个RTX 4090上7B模型AWQ INT4 vs FP16指标FP16AWQ INT4提升首token延迟45ms28ms1.6x吞吐tok/s852402.8x显存14GB5.5GB2.5x吞吐提升接近3倍和宣传吻合。但注意这是batch1、短上下文的数据。长上下文时KV Cache访存成为瓶颈提升会收窄到1.5~2倍。定位瓶颈的方法用nsys或torch.profiler看时间花在哪。如果反量化kernel占比高说明group_size太小如果KV Cache访存占比高说明该上PagedAttention或KV量化。4.4 边缘设备上的额外考量在Jetson、树莓派这类设备上AWQ的价值更偏向显存压缩而非速度。因为这些设备的算力有限INT4的算力优势发挥不出来但显存省下来能跑更大模型。另外边缘设备的散热和功耗限制意味着你不能长时间满负载。AWQ降低访存间接降低了功耗这对续航敏感的场景是隐性收益。5. 那些文档不会告诉你的踩坑记录5.1 量化后模型变傻的三种典型表现第一种是重复生成。模型陷入循环输出同一句话。这通常是某些注意力头对应的权重被过度量化。第二种是指令遵循能力下降。你让它做A它做B。这往往是FFN层的中间维度被压坏。第三种是长文本连贯性断裂。前几句正常后面开始跑题。这和KV Cache的精度有关AWQ本身不量化KV但如果权重误差累积长序列会放大。排查方法逐层对比量化前后的输出定位是哪一层开始偏离。我一般用hooks抓每层输出算余弦相似度低于0.95的层要重点关注。5.2 校准集泄露导致的假精度这是个隐蔽的坑。如果你用测试集的一部分做校准量化后的PPL会虚高实际部署时打回原形。正确做法是校准集和评测集严格分离。我习惯用通用语料如wiki做校准用领域数据做评测这样能真实反映跨域表现。5.3 多卡部署时的权重加载陷阱多卡推理时AWQ权重的加载方式要注意。有些框架会把量化权重先加载到CPU再分发如果实现不当会出现某张卡显存爆掉的情况。建议用device_mapauto让accelerate自动分配或者手动指定每张卡的层范围。加载后立刻检查每张卡的显存占用是否均衡。5.4 与LoRA微调的兼容性问题AWQ量化的模型能不能再挂LoRA可以但有讲究。LoRA的权重是FP16的和INT4基座混合计算时需要先反量化基座权重这会抵消一部分速度优势。更稳的做法是先做LoRA微调再对合并后的模型做AWQ量化。这样量化一次到位推理时没有混合精度开销。6. 从AWQ延伸量化技术的下一步在哪6.1 AWQ与GPTQ的混合使用实际项目中我有时会混用对敏感层用GPTQ精度优先对不敏感层用AWQ速度优先。这需要框架支持逐层指定量化方法目前vLLM还不直接支持得自己改kernel调度。6.2 激活量化的下一步W4A8的可能性AWQ目前是W4A16。如果能把激活也压到8bitW4A8显存和带宽还能再降。但激活的动态范围比权重难处理SmoothQuant那套思路可以借鉴。目前工业界W4A8的成熟度还不如W4A16但方向是明确的。6.3 对边缘端的意义让大模型真正下沉AWQ最大的价值我觉得不是那3倍速度而是把大模型的显存门槛拉到了消费级设备能承受的范围。以前13B模型要24G显存现在12G就能跑以前边缘盒子只能跑小模型现在能塞进7B。这个门槛的降低才是奠基二字的真正含义。我在一个国产边缘盒子上实测过8G显存的设备跑7B AWQbatch1时能到15 tok/s虽然不快但已经能支撑离线问答场景。这在两年前是不可想象的。最后分享一个我常用的检查清单量化完照着过一遍基本能避开80%的坑校准集与评测集是否分离group_size是否匹配目标硬件量化后PPL差距是否在可接受范围生成质量人眼抽检是否通过显存和延迟是否实测达标多卡加载是否均衡是否与后续微调流程兼容这套流程我在多个项目里跑下来AWQ的稳定性确实对得起它的口碑。量化不是玄学把激活分布这个因抓住权重保护这个果自然就对了。
大模型量化这件事我从早期做INT8 PTQ那会儿就开始跟一路踩坑到现在。说实话量化方法层出不穷但真正让我觉得这东西能上生产的AWQActivation-aware Weight Quantization算一个。它最吸引我的点不是那些宣传数字而是一个很朴素的观察权重的重要性不是均匀的只有极少数通道真正决定模型输出质量把这部分保护好剩下的随便压。这个思路听起来简单但落地效果确实猛。按照论文和后续大量实测AWQ在INT4权重量化下仅需保护约1%的显著权重困惑度PPL几乎不掉显存占用相比FP16直降60%以上推理吞吐在边缘设备上能拉到3倍左右。对于显存焦虑严重的本地部署场景——比如16G显存想跑大参数模型、或者想在消费级显卡上做多路并发——这套方案基本是绕不开的。这篇文章我不打算复述论文而是从工程落地的角度把AWQ到底怎么工作、为什么有效、实际部署时哪些参数要调、哪些坑必须避一条条拆开讲。适合已经了解基础量化概念、准备把模型真正跑起来的同学也适合刚接触量化、想搞清楚为什么大家都推AWQ的读者。1. 量化过拟合与延迟诅咒AWQ要解决的两个真实痛点1.1 传统RTN量化为什么在低比特下崩得厉害先说说最朴素的量化方法RTNRound-To-Nearest。它的逻辑简单到粗暴把每个权重值四舍五入到最近的量化格点。问题在于它假设所有参数同等重要。但神经网络里权重的分布是高度不均匀的——大部分权重集中在0附近少数离群值outlier承担了关键的激活响应。当你用INT4去压一个权重矩阵时量化步长变大那些离群值一旦被抹平对应的激活通道输出就会严重偏移。更麻烦的是这种误差会在层与层之间累积放大。我实测过一个7B级别的模型纯RTN INT4量化后PPL从原始的5.6直接飙到8以上生成内容开始出现明显的重复和逻辑断裂。这就是所谓的量化过拟合——不是模型在训练集上过拟合而是量化误差对某些关键通道过度敏感导致整体表现塌方。GPTQ通过二阶信息Hessian近似来补偿误差效果好但计算开销大量化一个7B模型动辄几十分钟到几小时而且对校准集敏感。1.2 高延迟从哪来反量化与内存带宽的双重夹击延迟问题更隐蔽。很多人以为量化只是省显存其实推理延迟的大头在内存带宽。FP16推理时每读一个权重就要做一次乘加INT4推理时权重虽然只占1/4空间但计算前必须先反量化回FP16这个反量化操作如果实现得不好反而会引入额外开销。另一个延迟来源是**分组量化group-wise quantization**的粒度。分组越细精度越高但每组都要存scale和zero-point元数据膨胀访存模式变碎GPU的coalesced access被打断实际吞吐反而下降。我见过有人把group_size设成32结果推理速度比group_size128还慢就是因为元数据访存成了瓶颈。AWQ的设计恰好在这两个痛点上做了权衡用激活感知保护关键权重解决过拟合用per-channel scale而非复杂分组控制延迟。1.3 AWQ的核心洞察激活比权重更能说明谁重要这是AWQ最漂亮的地方。传统方法看权重本身的数值大小来判断重要性但AWQ说应该看这个权重对应的输入激活有多大。道理很直白。一个权重w它参与的计算是w·x。如果x激活很大那么w的微小扰动会被放大如果x很小w怎么变都无所谓。所以真正该保护的是大激活通道对应的权重而不是数值大的权重。基于这个洞察AWQ的做法是对每个输入通道根据其激活的幅值计算一个缩放因子s把重要通道的权重大幅放大同时把对应激活缩小这样量化时这些权重的相对误差就变小了。数学上等价于对权重做per-channel scaling但scale的选取是激活驱动的。注意这里的保护1%指的是被显著放大的通道比例。实测中真正需要重点保护的通道通常只占总通道数的0.1%~1%其余通道即使量化粗糙也不影响最终输出。2. AWQ的数学骨架缩放因子怎么算、为什么这么算2.1 从量化误差公式推导缩放的必要性设权重w量化操作Q(w)量化误差为Δw Q(w) - w。对于线性层输出y w·x误差传播为Δy Δw·x。我们的目标是最小化|Δy|。如果对权重做缩放w w · s对应激活x x / s那么输出y w·x保持不变。但量化误差变成Δw Q(w·s) - w·s传播到输出是Δy Δw · x (Q(w·s) - w·s) · (x/s)。关键来了当s增大时w·s的数值变大相对量化步长步长固定下的相对误差变小即(Q(w·s) - w·s)/(w·s)减小。同时x/s减小。两者相乘如果s选得好Δy的绝对值可以显著降低。这就是AWQ的数学本质通过per-channel scaling把量化误差从重要通道转移到不重要通道。2.2 缩放因子的搜索为什么用网格搜索而不是解析解理论上可以求最优s的解析解但实际中量化函数Q是非线性的round操作解析解不成立。AWQ采用的做法是在一个对数网格上搜索s目标是最小化量化后输出的MSE。具体来说对每个通道搜索范围通常设为[0.5, 2.0]之类的区间取若干候选值比如20个对每个候选计算量化误差选最小的。这个搜索是per-channel独立的可以并行所以整体开销可控。我实测下来这个搜索过程对7B模型大概几分钟比GPTQ快一个数量级。而且因为只搜一个标量内存占用极小。2.3 与GPTQ、SmoothQuant的路线差异这里必须做个对比否则容易混淆。方法核心思路量化对象校准开销典型精度RTN直接round权重无差GPTQ二阶误差补偿权重高好SmoothQuant激活-权重均衡权重激活中好W8A8AWQ激活感知缩放权重低好W4A16SmoothQuant是把激活的难度平滑到权重上主要解决激活量化难的问题适合W8A8。AWQ则是纯权重量化W4A16激活保持FP16所以它不需要处理激活量化的动态范围问题专注把权重压到4bit。这个路线差异决定了AWQ的部署更简单激活还是FP16kernel改动小现有推理框架容易集成。2.4 为什么仅保护1%就够激活分布的稀疏性这一点很多人没想明白。神经网络激活经过ReLU或GELU后本身就有稀疏性即使没有激活幅值的分布也是长尾的——少数通道的激活值比中位数高一两个数量级。AWQ的缩放本质上是按激活幅值分配保护预算。长尾分布意味着只要保护头部那1%的通道就能覆盖绝大部分的误差贡献。剩下的99%通道即使量化误差大因为它们对应的激活本来就小对输出的影响可以忽略。我在一个13B模型上做过消融保护比例从0.1%提到1%PPL改善明显从1%提到5%改善微乎其微。这验证了1%这个量级的合理性。3. 实操从模型到AWQ量化权重再到推理的完整链路3.1 环境准备与依赖版本的那些坑AWQ的官方实现主要在llm-awq和autoawq两个仓库。我推荐用autoawq因为它和HuggingFace生态集成好API简洁。pip install autoawq pip install transformers accelerate版本上有个大坑autoawq对transformers版本敏感。我遇到过transformers 4.36和autoawq 0.1.8不兼容加载模型时报KeyError: model.layers。稳妥做法是锁定版本组合比如autoawq 0.2.x配transformers 4.40。CUDA版本也要注意。AWQ的量化kernel需要CUDA 11.8以上且对compute capability有要求。老卡如Pascal架构不支持INT4的fast kernel会回退到慢速路径这时候量化反而可能变慢。提示量化前先跑一遍nvidia-smi确认CUDA版本再用torch.cuda.get_device_capability()确认算力。算力低于7.0的卡建议直接放弃INT4 kernel加速只把它当显存压缩手段。3.2 校准数据的选择不是越多越好AWQ需要校准数据来统计激活分布。官方默认用pileval数据集取512条样本每条512 token。我的经验是校准数据的领域要贴近你的实际使用场景。如果你要做代码生成就用代码数据校准做中文对话就用中文语料。用英文通用语料校准出来的模型在中文任务上PPL可能差0.3~0.5。样本数量上128~512条足够。我试过用2048条精度提升不到0.05 PPL但量化时间翻倍。性价比很低。from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path your-model-path quant_path your-model-awq-int4 model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) quant_config { zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM } model.quantize(tokenizer, quant_configquant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)3.3 group_size与zero_point的取舍逻辑q_group_size是AWQ最重要的超参。它决定了每多少个权重共享一个scale。group_size128默认值精度和速度平衡好。group_size64精度略升元数据翻倍速度略降。group_size-1per-channel精度最高但kernel支持差实际很少用。我实测在7B模型上group_size从128降到64PPL改善约0.1但推理速度下降8%~12%。除非你对精度极度敏感否则128是甜点。zero_point建议开True。它允许量化区间非对称对ReLU后的权重分布更友好。关掉它省一点元数据但精度损失在低比特下会被放大。3.4 量化后必做的三项验证量化完别急着上线先做这三件事PPL对比在留出集上算量化前后的PPL差距超过0.5要警惕。生成质量抽检跑20~50条真实prompt人眼看有没有重复、乱码、逻辑断裂。显存与延迟实测用torch.cuda.max_memory_allocated()测显存用time.perf_counter()测首token延迟和吞吐。我见过PPL只差0.2但生成质量明显下降的案例原因是PPL是平均指标掩盖了长尾case的崩坏。所以人眼抽检不能省。4. 边缘端部署显存账怎么算、延迟怎么压4.1 显存占用的逐项拆解很多人问16G显存能跑多大的AWQ模型这得算细账。以7B模型INT4为例项目占用权重INT4约3.5GB激活FP16batch1约0.5~1GBKV Cache2048上下文约1~2GB框架开销约0.5GB合计约6~7GB所以16G显存跑7B AWQ绰绰有余甚至能上13B约7GB权重开销总10~12GB。但如果你要长上下文8K以上KV Cache会暴涨这时候得考虑KV量化或PagedAttention。4.2 推理框架选型vLLM、TensorRT-LLM还是llama.cpp不同框架对AWQ的支持和优化差异很大vLLM对AWQ支持成熟PagedAttention管理KV Cache吞吐高适合服务端。TensorRT-LLMkernel优化最狠延迟最低但编译流程复杂适合固定模型的生产环境。llama.cppCPU/边缘设备友好支持AWQ格式转换适合资源受限场景。我的建议服务端用vLLM边缘设备用llama.cpp追求极致延迟用TensorRT-LLM。三者都支持AWQ权重迁移成本不高。4.3 实测延迟数据与瓶颈定位在一个RTX 4090上7B模型AWQ INT4 vs FP16指标FP16AWQ INT4提升首token延迟45ms28ms1.6x吞吐tok/s852402.8x显存14GB5.5GB2.5x吞吐提升接近3倍和宣传吻合。但注意这是batch1、短上下文的数据。长上下文时KV Cache访存成为瓶颈提升会收窄到1.5~2倍。定位瓶颈的方法用nsys或torch.profiler看时间花在哪。如果反量化kernel占比高说明group_size太小如果KV Cache访存占比高说明该上PagedAttention或KV量化。4.4 边缘设备上的额外考量在Jetson、树莓派这类设备上AWQ的价值更偏向显存压缩而非速度。因为这些设备的算力有限INT4的算力优势发挥不出来但显存省下来能跑更大模型。另外边缘设备的散热和功耗限制意味着你不能长时间满负载。AWQ降低访存间接降低了功耗这对续航敏感的场景是隐性收益。5. 那些文档不会告诉你的踩坑记录5.1 量化后模型变傻的三种典型表现第一种是重复生成。模型陷入循环输出同一句话。这通常是某些注意力头对应的权重被过度量化。第二种是指令遵循能力下降。你让它做A它做B。这往往是FFN层的中间维度被压坏。第三种是长文本连贯性断裂。前几句正常后面开始跑题。这和KV Cache的精度有关AWQ本身不量化KV但如果权重误差累积长序列会放大。排查方法逐层对比量化前后的输出定位是哪一层开始偏离。我一般用hooks抓每层输出算余弦相似度低于0.95的层要重点关注。5.2 校准集泄露导致的假精度这是个隐蔽的坑。如果你用测试集的一部分做校准量化后的PPL会虚高实际部署时打回原形。正确做法是校准集和评测集严格分离。我习惯用通用语料如wiki做校准用领域数据做评测这样能真实反映跨域表现。5.3 多卡部署时的权重加载陷阱多卡推理时AWQ权重的加载方式要注意。有些框架会把量化权重先加载到CPU再分发如果实现不当会出现某张卡显存爆掉的情况。建议用device_mapauto让accelerate自动分配或者手动指定每张卡的层范围。加载后立刻检查每张卡的显存占用是否均衡。5.4 与LoRA微调的兼容性问题AWQ量化的模型能不能再挂LoRA可以但有讲究。LoRA的权重是FP16的和INT4基座混合计算时需要先反量化基座权重这会抵消一部分速度优势。更稳的做法是先做LoRA微调再对合并后的模型做AWQ量化。这样量化一次到位推理时没有混合精度开销。6. 从AWQ延伸量化技术的下一步在哪6.1 AWQ与GPTQ的混合使用实际项目中我有时会混用对敏感层用GPTQ精度优先对不敏感层用AWQ速度优先。这需要框架支持逐层指定量化方法目前vLLM还不直接支持得自己改kernel调度。6.2 激活量化的下一步W4A8的可能性AWQ目前是W4A16。如果能把激活也压到8bitW4A8显存和带宽还能再降。但激活的动态范围比权重难处理SmoothQuant那套思路可以借鉴。目前工业界W4A8的成熟度还不如W4A16但方向是明确的。6.3 对边缘端的意义让大模型真正下沉AWQ最大的价值我觉得不是那3倍速度而是把大模型的显存门槛拉到了消费级设备能承受的范围。以前13B模型要24G显存现在12G就能跑以前边缘盒子只能跑小模型现在能塞进7B。这个门槛的降低才是奠基二字的真正含义。我在一个国产边缘盒子上实测过8G显存的设备跑7B AWQbatch1时能到15 tok/s虽然不快但已经能支撑离线问答场景。这在两年前是不可想象的。最后分享一个我常用的检查清单量化完照着过一遍基本能避开80%的坑校准集与评测集是否分离group_size是否匹配目标硬件量化后PPL差距是否在可接受范围生成质量人眼抽检是否通过显存和延迟是否实测达标多卡加载是否均衡是否与后续微调流程兼容这套流程我在多个项目里跑下来AWQ的稳定性确实对得起它的口碑。量化不是玄学把激活分布这个因抓住权重保护这个果自然就对了。
