1. 为什么大模型量化不是“压缩一下”那么简单很多人第一次接触大模型量化脑子里浮现的画面是把一个几十GB的模型文件“压一压”像给照片降画质那样体积小了、精度掉一点完事。真上手之后才发现事情远没有这么线性。量化的本质是在数值表示精度和计算资源开销之间做一场精细的博弈而这场博弈的胜负直接决定了模型能不能在消费级显卡、边缘设备甚至手机端跑起来。我最初做量化实验时用的是最朴素的思路把FP16权重直接四舍五入到INT8。结果模型输出开始胡言乱语困惑度perplexity从个位数飙到几十。后来才明白大模型权重分布极不均匀少数通道的极值会“吃掉”大部分量化区间导致大量正常权重被压成同一个值。这就是量化领域最核心的矛盾离群值outlier与均匀量化区间的冲突。量化技术要解决的核心问题可以拆成三层。第一层是表示层用多少比特、什么数据类型来存权重和激活值。第二层是算法层怎么在量化过程中最小化信息损失是逐层校准还是全局优化。第三层是工程层量化后的模型怎么在真实硬件上高效推理kernel怎么适配显存怎么调度。这三层任何一层没处理好量化就只是“看起来很美”。适合读这篇内容的人我大致分三类。第一类是刚入门大模型部署的工程师想知道量化到底有哪些主流方案、各自适合什么场景。第二类是做模型压缩研究的学生或研究员需要一份能快速建立全局认知的路线图。第三类是在实际业务中面临显存瓶颈的开发者比如想把7B模型塞进单张消费卡或者想在端侧跑一个能用的对话模型。不管你是哪一类接下来的内容都会从原理到实操把量化这件事拆开揉碎讲清楚。提示量化不是万能药。如果你的任务对数值精度极度敏感比如某些科学计算或高精度回归量化带来的收益可能抵不过精度损失。先明确你的精度容忍度再决定要不要量化。2. 从FP32到INT4数值表示背后的取舍逻辑2.1 浮点数、定点数与量化区间的数学直觉要理解量化先得理解计算机怎么存数。FP32用1位符号、8位指数、23位尾数表示一个实数动态范围极大能表示从1e-38到1e38的数。FP16把指数缩到5位、尾数缩到10位范围小了很多但精度对大多数深度学习任务够用。而INT8是定点数8个比特全用来表示整数范围固定在-128到127之间。量化的核心操作就是一个仿射变换real_value scale * (quantized_value - zero_point)。这里的scale是缩放因子zero_point是零点偏移。对于对称量化zero_point为0scale等于权重绝对值的最大值除以127。对于非对称量化zero_point不为0能更好地利用量化区间。问题出在离群值上。大模型权重里某些通道的值可能是其他通道的几十倍甚至上百倍。如果按全局最大值定scale那绝大多数权重会被压缩到很窄的区间里量化误差巨大。我做过一个统计在LLaMA-7B的某一层里99%的权重落在[-0.1, 0.1]区间但最大值能到3.5。用全局scale的话0.1对应的量化步长是3.5/127≈0.0276意味着0.1以内的精细差异全被抹平了。2.2 对称量化与非对称量化的选择依据对称量化的公式简单scale max(abs(weight)) / 127推理时只需要一个乘法。非对称量化多一个zero_pointscale (max - min) / 255zero_point round(-min / scale)能更精确地表示非对称分布的数据。那什么时候用哪个我的经验是权重量化优先用对称量化因为权重通常近似零均值分布对称量化够用且计算简单。激活值量化优先用非对称量化因为激活值经过ReLU或GELU后往往是非负的分布不对称非对称量化能减少信息损失。但这里有个坑非对称量化在推理时需要额外处理zero_point某些硬件比如老款GPU的Tensor Core对非对称量化的支持不如对称量化好。如果你追求极致推理速度对称量化往往是更稳妥的选择。2.3 逐张量、逐通道与逐组量化的粒度权衡量化粒度决定了scale和zero_point的共享范围。逐张量量化per-tensor是整个张量共用一个scale最省存储但精度最差。逐通道量化per-channel是每个输出通道一个scale精度提升明显存储开销增加有限。逐组量化per-group是把通道再分成若干组每组一个scale精度最高但元数据最多。以INT4量化为例逐张量量化在7B模型上通常会导致困惑度翻倍逐通道量化能把损失压到10%以内逐组量化group size128基本能恢复到接近FP16的水平。但逐组量化的元数据开销不可忽视每个group需要一个FP16的scalegroup size128时每128个权重多2字节相当于每个权重多0.0156字节对INT4来说相当于增加了约4%的存储。实际选型时我通常这样决策如果目标是显存极度受限比如端侧部署用逐组量化group size取128或64。如果目标是推理速度优先比如服务端批量推理用逐通道量化kernel优化更成熟。如果只是快速验证逐张量量化先跑通再说。3. GPTQ、AWQ与GGUF三条主流技术路线的分野3.1 GPTQ的逐层校准与误差补偿机制GPTQGenerative Pre-trained Transformer Quantization的核心思想是逐层量化用Hessian矩阵指导权重更新。它不是简单地把权重四舍五入而是在量化每一层时用校准数据计算该层输入的Hessian矩阵然后按列量化权重每量化一列就用剩余未量化的权重去补偿误差。具体来说GPTQ把量化问题转化为一个最小二乘问题给定输入X和原始权重W找到量化后的权重Q使得||XW - XQ||^2最小。Hessian矩阵H 2XX^T刻画了每个权重对输出的影响程度。量化时优先处理影响小的权重把误差分摊到还没量化的权重上。这个方法的精妙之处在于误差补偿。假设你要量化权重矩阵的第j列量化完第j列后用第j列的量化误差去更新后面所有列的权重让它们“吸收”这个误差。这样逐列推进最终整体输出误差被压得很低。GPTQ的实操参数里group_size和damp_percent最关键。group_size越小精度越高但速度越慢通常取128。damp_percent是Hessian矩阵对角线上的阻尼系数防止数值不稳定一般取0.01。我试过damp_percent0.1时某些层的量化误差反而变大因为阻尼太强导致Hessian信息被过度平滑。注意GPTQ校准需要一定量的数据通常128到1024条样本就够。但校准数据的分布要和实际推理数据接近否则Hessian矩阵估计不准量化后模型在真实场景下可能表现更差。3.2 AWQ的激活感知权重量化思路AWQActivation-aware Weight Quantization走了一条不同的路。它的核心观察是不是所有权重都同等重要那些对应大激活值的权重通道才是关键。量化时应该保护这些重要通道而不是一视同仁。AWQ的做法是先用校准数据跑一遍统计每个通道的激活值幅度。然后对权重进行缩放让重要通道的权重在量化时占据更大的动态范围。具体来说它引入一个缩放因子s对权重做W W * s对激活做X X / s保持WX WX不变。通过优化s让重要通道的量化误差最小。这个思路的巧妙之处在于不需要反向传播计算量比GPTQ小很多。而且AWQ对校准数据的依赖相对较低泛化性更好。我在实际对比中发现AWQ在INT4量化下困惑度通常比GPTQ低0.1到0.3推理速度也略快因为它的缩放操作可以融合到前一层。但AWQ也有短板它对激活值分布变化剧烈的任务比如长上下文推理可能不如GPTQ稳定。因为AWQ的缩放因子是在校准数据上优化的如果实际推理时激活分布偏移很大保护策略可能失效。3.3 GGUF格式与llama.cpp的端侧落地实践GGUFGPT-Generated Unified Format是llama.cpp社区推出的模型格式专门为端侧推理设计。它支持多种量化类型从Q2_K到Q8_0还有混合量化方案比如Q4_K_M对重要层用更高精度。GGUF的量化策略和GPTQ/AWQ有本质区别它更注重推理时的内存布局和计算效率。GGUF把模型权重分块存储每块可以有不同的量化类型。比如Q4_K_M对注意力层的权重用Q6_K对FFN层用Q4_K在精度和体积之间取得平衡。我在安卓设备上跑GGUF模型的体验是Q4_K_M的7B模型大约4GB在骁龙8 Gen 2上能跑到5-8 tokens/s基本可用。Q5_K_M精度更好但体积到5GB速度降到4-6 tokens/s。如果设备内存紧张Q3_K_S能把体积压到3GB以内但输出质量下降明显适合对精度要求不高的场景。GGUF的另一个优势是工具链成熟。llama.cpp提供了quantize工具一行命令就能完成转换。而且GGUF支持CPU和GPU混合推理能把部分层卸载到GPU在显存不足时特别有用。量化方案核心思想精度INT4推理速度适用场景GPTQHessian引导的逐层误差补偿高中服务端GPU推理AWQ激活感知的权重缩放高快服务端/边缘GPUGGUF分块混合量化内存优化中高中端侧CPU/混合推理4. 量化实操中的参数调优与踩坑记录4.1 校准集的选择比你想的更重要很多人做量化时随便找几百条数据当校准集结果量化后模型在特定任务上表现崩盘。我踩过最惨的一次坑用英文通用语料校准一个中文对话模型量化后模型的中文输出开始夹杂英文而且逻辑连贯性明显下降。校准集的选择要遵循两个原则。第一分布匹配校准数据的领域、语言、长度分布要和实际推理场景一致。做中文对话就用人中文对话数据做代码生成就用代码数据。第二多样性校准集要覆盖模型可能遇到的各种输入模式不能全是短句或全是长文本。我通常用512条样本长度从16到512 tokens均匀采样。还有一个细节校准集的顺序会影响GPTQ的Hessian估计。因为GPTQ是逐层处理的如果校准数据按某种规律排序比如按长度递增Hessian矩阵可能偏向某种模式。我的做法是随机打乱校准集并且用固定的随机种子保证结果可复现。4.2 group_size与bit宽度的组合实验group_size和bit宽度是量化中最重要的两个超参数。我做过一组对比实验在LLaMA-7B上测试不同组合的困惑度和显存占用。bit宽度group_size困惑度WikiText-2显存占用推理速度FP16-5.6813.5GB1.0xINT81285.707.2GB1.8xINT41285.854.1GB2.3xINT4645.794.3GB2.1xINT4325.744.6GB1.9xINT31286.523.2GB2.5x从数据看INT4 group_size128是性价比拐点。再往下压到INT3困惑度跳升明显除非显存极度受限否则不建议。group_size从128降到64困惑度改善0.06但显存增加0.2GB推理速度降8%收益递减明显。还有一个反直觉的发现不是所有层都适合相同bit宽度。第一层和最后一层对精度更敏感中间层可以压得更狠。混合量化比如首尾层用INT8中间层用INT4能在几乎不增加体积的情况下把困惑度再降0.05到0.1。4.3 量化后模型“变傻”的排查链路量化后模型表现下降排查思路要系统化。我通常按以下链路走第一步确认是量化问题还是推理框架问题。把量化模型和原始FP16模型在相同输入下对比输出。如果FP16正常、量化异常问题在量化。如果两者都异常问题在推理框架或prompt格式。第二步定位是哪些层出了问题。逐层替换把量化模型的某一层换回FP16看输出是否恢复。如果换回某层后明显改善说明该层量化误差过大。通常注意力层的QKV投影和FFN的down_proj最容易出问题。第三步检查校准集和量化参数。校准集是否匹配group_size是否太小damp_percent是否合适我遇到过一次damp_percent0.01时某层Hessian矩阵接近奇异量化后该层输出全是NaN。把damp_percent调到0.05后问题消失。第四步考虑混合精度方案。如果某些层实在敏感就保留FP16或INT8。llama.cpp的Q4_K_M就是这种思路对关键层用更高精度。提示量化后的模型一定要做端到端评测不能只看困惑度。困惑度低不代表生成质量好。我习惯用一组固定prompt做人工评估覆盖问答、摘要、代码生成等任务对比量化前后的输出差异。5. 量化技术的边界与未来演进方向5.1 当前量化方案的精度天花板在哪里INT4量化在7B到70B模型上已经能做到几乎无损但再往下压就遇到瓶颈。INT3量化在7B模型上困惑度通常上升10%到20%INT2更是直接崩盘。根本原因是大模型的权重分布存在长尾极少数离群值携带了大量信息低bit量化无法保留这些信息。另一个边界是激活值量化。权重量化相对成熟但激活值量化尤其是KV Cache量化难度大得多。KV Cache的激活值动态范围随输入长度变化长上下文时离群值更严重。目前KV Cache量化通常用INT8INT4还在研究中精度损失明显。还有一个容易被忽视的边界量化对推理任务的影响不均匀。分类、检索这类任务对量化不敏感INT4几乎无损。但生成任务、数学推理、代码生成对量化更敏感INT4可能带来可感知的质量下降。如果你的业务是代码助手量化前一定要做充分的A/B测试。5.2 量化与微调、蒸馏的组合拳量化不是孤立的优化手段它和微调、蒸馏可以组合使用。QATQuantization-Aware Training是在训练时模拟量化误差让模型学会适应低精度表示。QAT通常比PTQPost-Training Quantization精度高但需要训练资源和数据。量化蒸馏是另一个思路用FP16的大模型当教师量化后的小模型当学生通过蒸馏让量化模型逼近教师输出。我在一个内部项目里试过INT4蒸馏后的模型比直接INT4量化的困惑度低0.3左右但训练成本增加明显。量化LoRA是当前最实用的组合。先量化基座模型再用LoRA做轻量微调。LoRA的权重保持FP16不参与量化这样既能享受量化的显存收益又能保持微调后的任务性能。我在一个客服对话场景里用这个方案INT4基座LoRA显存从24GB降到8GB任务指标只降了1.2%。5.3 硬件适配从GPU到NPU的量化部署差异不同硬件对量化的支持差异很大。NVIDIA GPU对INT8和INT4的支持最好Tensor Core有专门的量化指令kernel优化成熟。AMD GPU的量化生态还在追赶ROCm对GPTQ的支持不如CUDA完善。Apple Silicon通过Metal和Core ML支持量化但工具链和社区资源相对少。NPU和端侧芯片是量化的主战场。高通Hexagon、联发科APU、华为昇腾都对INT8有良好支持INT4支持参差不齐。部署到端侧时量化方案要跟着硬件走如果NPU只支持逐通道对称量化那就别用逐组非对称量化否则推理时要做额外转换速度反而更慢。我在RK3568上部署YOLOv5量化模型时踩过一个坑ONNX导出的INT8模型在PC上推理正常但转到RKNN后精度暴跌。原因是RKNN对量化参数的解析和ONNX Runtime不一致zero_point的处理有差异。后来用RKNN自带的量化工具重新校准问题才解决。端侧部署一定要用厂商提供的量化工具链不要直接拿通用工具导出的模型硬上。6. 我在量化项目里攒下的几条实战心得第一条心得量化前先做显存 profiling。很多人一上来就量化结果发现瓶颈不在权重而在KV Cache或激活值。用torch.cuda.memory_summary()看清楚显存到底花在哪再决定量化策略。如果KV Cache占大头优先做KV Cache量化而不是权重量化。第二条心得保留原始FP16模型作为回退。量化模型上线后如果发现某些输入下表现异常能快速切回FP16。我通常用AB测试框架把量化模型和FP16模型同时部署按流量比例分流监控输出质量指标。第三条心得量化不是一次性的要持续迭代。模型更新、数据分布变化、硬件升级都可能让之前的量化方案失效。我习惯每季度重新跑一次量化校准用最新的业务数据做校准集确保量化模型和实际场景不脱节。第四条心得别迷信论文里的最优参数。论文里的group_size128、damp_percent0.01是在特定模型和数据集上调出来的换到你的场景可能不是最优。我通常用网格搜索在小规模上快速筛选再在完整模型上验证。搜索空间不用太大group_size试[32, 64, 128, 256]bit宽度试[3, 4, 8]基本能覆盖大多数场景。第五条心得量化模型的评测要包含“边界输入”。常规评测集往往覆盖不到极端情况比如超长输入、特殊字符、多语言混合。我专门构造了一组边界测试用例包括空输入、超长输入、纯符号输入、中英混合输入每次量化后都跑一遍确保模型不会在这些情况下崩溃。最后分享一个实用技巧如果你用GPTQ量化可以在量化脚本里加一个--true-sequential参数让量化按层顺序执行而不是并行。这样显存占用更低但速度慢一些。在显存紧张的机器上这个参数能帮你省下不少显存。另外量化后的模型保存时用safetensors格式加载更快也更安全避免pickle的反序列化风险。