★ FEATURED ARTICLE Hey各位折腾大模型部署的朋友们好久不见。这次继续聊模型量化而且是专门针对大语言模型LLM的那套玩法。如果说量化基础篇讲的是通用方法论那到了LLM这里画风就完全不一样了。你有没发现用PyTorch自带的torch.quantization去量化一个70亿参数的模型结果往往惨不忍睹要么推理速度没提升多少要么回答质量断崖式下跌。原因很简单LLM的输出分布和CNN完全不是一个套路。卷积网络的激活值相对规整而LLM的激活值里藏着大量极端离群点用经典的minmax或percentile策略一刀切误差全砸在这些关键点上。今天这篇“下篇”咱们就把LLM圈子里那五个最出名的专用方案全部扒一遍LLM.int8、GPTQ、AWQ、SmoothQuant、NF4。我会把它当成一次选型复盘来写每个方案的核心思路、数学原理尽量用人话讲、实操参数、踩坑记录一股脑倒出来。你可以直接对照自己的业务场景抄作业。1. 为什么通用量化在LLM上失灵离群点才是罪魁祸首得先把这个根子上的问题说清楚。刚才提到离群点具体长什么样你在HuggingFace上随便拉一个7B模型跑一下前向把某一层的激活值打印出来会发现99.9%的数值都趴在-1到1这个区间里但总有那么几个值能飙到20、50甚至上百。这串数字看起来有点疯狂但确实是LLM的常态。这种分布对量化是致命的。因为INT8的范围只有[-128, 127]你要把FP16的激活值映射过去缩放因子scale就得根据绝对值最大的那个离群值来定。假设最大激活值是80那scale就是80/127≈0.63结果那些占比99.9%的正常小值被压缩到只有几个量化步长去表示信息几乎全部丢失。这就是为什么通用量化方案在LLM上“翻车”频率特别高。更麻烦的是离群点不是随机分布的它高度集中在特定的特征通道channel和特定的token位置上。有研究者发现这些离群值往往出现在句子开头、标点符号附近而且某些维度上几乎每一个token都会激活。这就没法靠简单的“裁剪”来清理你剪掉它模型能力直接受损你不剪它量化误差大到离谱。所以LLM专用量化方案的核心命题就变成了如何在保留离群点信息的前提下尽可能把大部分计算用低位宽完成。围绕这个命题演化出了几条完全不同的技术路线有把离群点单独拎出来用高精度算的LLM.int8、有靠二阶信息逐层补偿误差的GPTQ、有主动把量化难度从激活转移到权重上的SmoothQuant、还有从数据格式层面做文章的NF4。下面一个一个说。2. LLM.int8()离群点特殊对待的混合精度分解这个方案是HuggingFace和论文《LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale》带火的也是最早一批让人真正敢在超大模型上跑量化的方法。它的核心思路特别直白既然离群点是少数那就把它们单独提出来用FP16算剩下的绝大多数正常值用INT8矩阵乘法算最后把两部分结果拼回去。2.1 核心原理拆解向量级量化与混合精度分解LLM.int8()其实包含了两层设计。第一层叫向量级量化Vector-wise Quantization。普通量化是给整张权重矩阵算一个scaleLLM.int8()改成给矩阵的每一列单独算一个scale。为什么要这么做因为权重矩阵的每一列对应一个输出特征列之间的数值范围差异极大统一用一个scale会委屈那些数值范围小的列。逐列独立缩放以后每列的信噪比都能保证这是它对精度友好的第一步。第二层才是真正的重点叫混合精度分解Mixed-precision Decomposition。流程是这样的前向计算时先看当前这个样本或者这个token的激活值找出哪些特征维度上存在离群点阈值通常设为6.0也就是绝对值超过6就认为离群。然后把这部分离群列对应的权重子矩阵和激活子矩阵分别抠出来用FP16精度做矩阵乘剩余那些没有离群点的正常列就用INT8精度做矩阵乘。两个结果最后在FP16域里相加得到完整的输出。这块的实现细节有个坑离群特征虽然只占很小比例但你不能简单把它丢掉或者粗暴量化必须保持它在FP16域的精确计算否则模型会直接开始胡言乱语。2.2 八位量化实测与避坑指南实操中用LLM.int8()非常简单在Transformers库的from_pretrained里加一个load_in_8bitTrue就行。但我强烈建议你配合device_mapauto使用因为8bit加载模型时bitsandbytes库会自动做设备分配。我来说说实测数据。拿一个13B模型FP16大概要26GB显存8bit加载后能压到13GB左右显存占用减半。推理速度方面在A100 80G上13B模型用8bitLLM.int8的生成速度大约是FP16的1.05到1.1倍。注意这个加速幅度比理想中低多了原因就是混合精度分解本身有开销每次矩阵乘都要判断离群列、做矩阵切片、把结果拼接回去这些操作的额外耗时抵消了一部分INT8矩阵乘的加速收益。而且越是小模型越体现不出优势。7B以下模型LLM.int8()的速度甚至可能比FP16还慢因为模型本身计算量不大切片拼接的CPU/GPU通信开销反而占了主导。所以我的建议是用这个方案的人要么模型特别大重点解决显存放不下的问题要么机器显存刚好卡在临界点上否则性价比不高。避坑提示几个不要和torch.compile一起用。torch.compile的图优化和bitsandbytes库的8bit线性层有一定兼容性问题实测经常会报奇怪的算子错误或者直接变慢。切换模型到GPU后再用8bit。如果模型原本在CPU上bitsandbytes会强制要求重新加载到GPU而且可能触发精度对齐问题。最新版bitsandbytes对多卡环境友好多了但还是建议你先用单卡跑通再上多卡排查问题时能节省大量时间。2.3 这个方案适合谁用总结一下LLM.int8()适合“你有一块24G卡想跑一个原本26G的模型又不愿意做GPTQ量化重新生成4bit checkpoint”的过渡场景。好处是无感、无需校准数据集、开箱即用坏处是加速有限、显存节省没到极致。3. GPTQ基于二阶信息的逐层量化补偿如果说LLM.int8()是在“运行时”做文章那GPTQ就是在“离线”阶段就把量化误差压到最低。它属于**训练后量化PTQ**路线核心思路来源于一篇更早的论文——OBSOptimal Brain Surgeon最优脑外科手术。那篇论文本来讲的是剪枝它的思想是当你移除神经网络里某个权重时其他权重会产生连锁误差影响如果知道损失函数的二阶导信息Hessian矩阵就能在移除一个权重的同时对其他权重做补偿把总误差降到最低。GPTQ把同样的思想移植到了量化上量化一个权重不是孤立操作我可以根据Hessian矩阵算出这个量化操作对其他权重的影响然后同步更新剩余权重让整体误差最小化。3.1 量化补偿的数学逻辑具体来说GPTQ是对模型逐层layer-by-layer量化的。每一层内部它按列处理权重矩阵先量化某一列然后计算这个量化误差对后面所有未量化列的影响并给这些未量化列加上一个修正量。这里涉及两个关键概念Hessian矩阵衡量权重变化对输出误差影响的二阶信息用校准集calibration set里几百条样本的激活值算出来通常是个几百乘几百的矩阵。它能精确告诉我们“如果把某个权重动一下其他权重该往哪个方向补”。逐层重建GPTQ不需要反向传播也不需要梯度更新它就是在做“最小化当前层输出误差”的优化。这个优化不带标签、不涉及训练所以速度极快一个13B模型在单张A100上半小时到一个小时就能完成全部量化。实际操作中还有一个提升稳定性的技巧叫阻尼dampening。计算Hessian矩阵逆的时候为了防止列不满秩导致数值爆炸GPTQ给Hessian对角线加了一个很小的常数percdamp常见取0.01。这个参数看着不起眼但它对量化后模型最终困惑度的影响非常显著不建议直接改成0。3.2 实操参数与量化流程记录用AutoGPTQ库做GPTQ量化的完整流程我跑过很多次和你分享一下关键步骤。首先准备环境pip install auto-gptq optimum然后加载模型和校准数据。校准数据的质量是整个量化成败的关键千万不要随便找一段文本就去校准。我常用的做法是从模型的原始训练数据分布里采样或者至少用和下游任务同领域的、几百条覆盖多样性的文本。接下来是几组关键参数bits4是主流也有用3的但要接受明显的精度下降2基本不建议尝试崩得很快。group_size指权重矩阵分组量化的粒度。常见选择128和32。组越小量化越精细精度越好但显存占用和计算开销也随之上升。实测下来group_size128是效果和性能之间最稳的平衡点绝大多数开源量化模型比如那些跑的很多的4bit量化版模型都用这个值。desc_act激活顺序字面意思是“激活顺序”实际指是否在量化时考虑激活值的真实数值范围来决定量化顺序。开启后精度确实更高但代价是推理时需要先对权重矩阵做重排加载和首次推理明显变慢。我的经验是如果你只是日常聊天测试开着问题不大如果要做高并发推理desc_actFalse或者选一个不增加额外IO开销的配置可能更合适。跑量化的时候用类似下面这段代码from transformers import AutoTokenizer from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig tokenizer AutoTokenizer.from_pretrained(你的基础模型路径) calibration_loader ... # 准备好校准数据 quantize_config BaseQuantizeConfig( bits4, group_size128, desc_actTrue, damp_percent0.01, ) model AutoGPTQForCausalLM.from_pretrained( 你的基础模型路径, quantize_configquantize_config, ) model.quantize(calibration_loader) model.save_quantized(量化后的输出目录, use_safetensorsTrue)3.3 两个容易踩的坑第一个坑是关于首次加载慢。量化后的模型文件确实小了但加载到GPU上做from_pretrained的时候需要把4bit的权重反量化dequantize到FP16再进行计算。这个反量化过程如果没用预编译的优化内核可能非常慢第一次加载十几二十分钟都正常。这个问题在AutoGPTQ和ExLlama的实现里都有一定程度的优化但如果你用得很早或者在某些框架里一定要有这个心理预期。第二个坑是关于校准集偏差。GPTQ的校准集如果和上线后的实际输入分布差异过大量化误差会被成倍放大。具体症状就是模型平时看着正常一遇到特定格式的输入就开始胡言乱语、答非所问。解决办法是准备一份足够贴近真实业务场景的校准集不要偷懒从网上随便拉几百段新闻混过去。4. AWQ激活感知的权重量化AWQ的全称是Activation-aware Weight Quantization意思是“激活感知的权重量化”。它和GPTQ在哲学上有一个重要差异GPTQ觉得量化误差是均匀分布在所有权重上的我要做的是在量化过程中动态补偿AWQ则认为不同权重对最终输出的重要性是不一样的有些权重通道天然更重要量化时得“偏心”对待它们。4.1 如何识别并保护重要权重通道AWQ最聪明的地方在于它找到了一个指标来识别哪些权重通道更重要激活值的大小。如果某个输入特征通道上的激活值普遍很大那对应的权重通道对输出影响就更大量化误差在这个通道上会被放大。这个思路直觉上很成立而且实现成本极低——你只需要跑一遍校准集统计每个通道激活值的平均值就够了不需要任何反向传播和微调。那怎么“偏心”呢光靠直觉说“这个通道少量化几个bit”是不行的AWQ的实际做法是给重要通道的权重乘一个缩放系数同时给激活值除以同一个系数数学上整个矩阵乘的结果完全不变但量化误差的分布被改变了。具体过程是这样假设原始计算是WX我找到缩放向量s把它变成(W·s)(X/s)。直观理解就是重要通道的权重被放大以后量化时相对误差占比变小精度自然更高虽然激活被缩小了会略微损失一点点激活精度但只要s选得合理收益远大于损失。这里s的选择不是手调的AWQ用了一个简单的网格搜索或者梯度搜索目标函数是量化前后输出的均方误差最小。整个搜索过程非常快13B模型几分钟就能完成。4.2 与GPTQ的横向对比与选型建议AWQ和GPTQ是目前最主流的两个4bit W4A16量化方案我实际对比过很多次直接说结论推理速度两者在成熟推理框架下如vLLM、TensorRT-LLM、llama.cpp差距不大但AWQ在部分硬件上有更高效的kernel支持因为它的权重量化不需要反向传播和动态补偿矩阵生成速度有时能比GPTQ快5%到8%。量化速度和成本AWQ只需要校准集的“前向统计缩放搜索”不需要GPTQ那样逐层做Hessian矩阵求逆和补偿更新所以量化过程快得多对算力紧张的团队更友好。精度表现整体在同一水平线但AWQ对校准数据集的依赖略低一些因为它用的是“统计值”而不是“全局二阶优化”理论上更鲁棒。不过在实际体验中两者在复杂推理任务上差距很小都属于4bit quantization的一线水平。我的选型建议很简单如果你的部署框架已经明确支持某种格式就优先用那个框架对应的量化方案。举例来说TensorRT-LLM对AWQ的支持非常完善那你在NVIDIA显卡上部署就用AWQ如果团队已经用AutoGPTQ跑通了一套流水线也没必要为了那点速度差去折腾新格式。4.3 AWQ实操中的几个细节用AutoAWQ库做量化的流程大概是from awq import AutoAWQForCausalLM model AutoAWQForCausalLM.from_pretrained(你的基础模型路径) tokenizer AutoTokenizer.from_pretrained(你的基础模型路径) quant_config {zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM} model.quantize(tokenizer, quant_configquant_config) model.save_quantized(量化后的输出目录, safetensorsTrue)这里的q_group_size同样是128zero_pointTrue表示使用对称量化加零点偏移version选GEMM还是GEMV取决于你的推理场景。GEMM适合批量推理、吞吐优先的场景比如服务端的连续多请求。GEMV适合单请求、低延迟场景比如在线实时聊天。如果你搞混了这个配置最常见的问题是模型在并发请求下吞吐上不去或者单次响应延迟莫名其妙高。排查了半天才发现是量化版本的kernel选错了。AWQ还有一个好处是模型量化后不用像GPTQ那样每次加载都做全局反量化很多推理框架可以直接操作4bit权重矩阵显存占用和加载速度都更好。5. SmoothQuant把量化难题从激活转移给权重刚才几个方案都是W4A16权重4bit、激活16bit核心原因是激活值太“刺头”离群点太多很难压到8bit以下。但问题来了如果我只量化权重、不量化激活矩阵乘法时权重是低精度、激活是FP16那计算时还是要把权重反量化回FP16再做FP16乘加根本发挥不出低精度矩阵乘法的硬件加速能力。想要真正利用INT8的Tensor Core加速必须做到W8A8权重8bit、激活8bit。而卡住W8A8的瓶颈就在激活值本身。SmoothQuant就是为了解决这个卡点而生的。5.1 数学迁移的核心思想SmoothQuant的核心思想用一句话概括就是把激活值上的量化难度通过数学上等价的变换迁移一部分到权重侧。具体推导非常漂亮设激活为x权重为W。我们可以构造一个对角缩放矩阵diag(s)然后把计算写成Wx (W · diag(s)^{-1}) · (diag(s) · x)这个式子两边严格相等不引入任何近似。也就是说我对激活做的任何缩放都可以在权重上做相反的缩放来完全抵消。既然激活里有几个通道的离群值特别大那我就把这些通道的激活缩小对应地把权重中相同通道放大。这样激活的整体数值范围被压平了INT8量化变得可行而权重虽然数值范围变大了但权重量化本身比激活量化宽容得多损失可控。这里有一个超参数alpha控制缩放迁移的力度migration strength。alpha0表示完全不迁移等于没做alpha1表示把激活的数值范围完全压到和权重一致。最佳值通常在0.5左右太大太小都会导致一侧的量化误差失控。SmoothQuant厉害在它是一个数学等价的迁移不需要重新训练只需要校准集统计迁移强度而且迁移后的权重计算不需要任何额外运行时开销——因为所有缩放都可以预先融合进权重里推理时正常做W8A8矩阵乘即可。5.2 实际收益与部署经验SmoothQuant的收益最直观地体现在吞吐上真正跑INT8矩阵乘比FP16矩阵乘能快1.5到2倍甚至更多在TensorRT-LLM、vLLM这些框架里都有现成的支持。部署时我建议你用Text Generation InferenceTGI或者TensorRT-LLM它们对SmoothQuant的集成最完善基本只需指定quantizesmoothquant相关的参数。如果你用自己写的推理代码那得注意几个核心步骤准备校准集统计每个激活通道的绝对值最大值算出迁移强度alpha。用alpha生成平滑缩放因子s对模型的权重矩阵和激活分别做缩放。将缩放后的权重直接转成INT8格式保存推理时加载INT8权重并按INT8 GEMM的方式计算。实测下来SmoothQuant在13B以上模型上的精度损失是非常低的困惑度perplexity通常只增加零点几。它适合的场景是你需要低延迟高吞吐的在线服务并且GPU支持高效的INT8计算。如果你的推理框架不支持INT8 GEMM优化SmoothQuant的收益会大打折扣。5.3 SmoothQuant的三个判断条件这里说点实在的SmoothQuant不是谁想用就能用好的你得先满足三个条件你的推理后端必须真正使用INT8 GEMM而不是INT8权重FP16计算。你手头有足够的校准数据来统计激活分布数据质量直接影响平滑效果。你对上线的精度要求足够宽能接受微小的质量波动。如果你做的任务对输出质量极其敏感比如医疗问答、代码生成W8A8方案的精度损失还是要比4bit方案小得多但依然要谨慎测试。6. NF4从数据格式层面逼近理论最优最后这个方案和前面四个画风不太一样。前面的方案都是“量化算法”NF4更多是一种“数据格式”——它定义了一种4bit的数值表示方法专门用来提升LLM量化后的信息保留能力。它最出名的应用场景就是QLoRA。6.1 分位数格式的设计逻辑为什么需要一种新的4bit格式传统FP4浮点4bit只有3个有效数字位数值范围不小但精度分布不均匀INT4虽然步长均匀但对LLM这种长尾分布来说大量小值会被粗暴归零。NF4NormalFloat4的思路是去拟合LLM权重真实分布——近似正态分布。NF4的设计原理是分位数量化Quantile Quantization既然权重大致服从标准正态分布那我就在[0, 1]区间上均匀地取16个分位点然后映射到正态分布对应的数值上。这样可以保证数值落在每个分位区间内的概率相等量化误差被最小化。这和我们前面讲过的minmax策略完全不同minmax关心的是“绝对值范围”NF4关心的是“概率密度匹配”。这正好符合LLM权重的分布特性——绝大多数权重挤在0附近极小部分拖在尾部。NF4用自己的分位点把0附近的小值分隔得特别细精度极高而尾部大值虽然有粗粒度但影响相对小。6.2 QLoRA训练中的实际应用QLoRAQuantized LLM with Low-Rank Adaptation就是建立在NF4之上的。它的核心组合是NF4量化底模把预训练模型比如13B甚至70B用NF4格式加载到GPU上冻结权重显存占用直接缩小4倍。70B模型原本要140GB显存NF4后只需要35GB左右一张48G的卡或两张24G卡就能跑起来。Double Quantization对量化过程中产生的缩放因子scale再做一次量化省掉那部分显存开销。这个操作看着微不足道但实际能省出几百MB到1GB对极限显存场景很关键。分页优化器Paged Optimizer借鉴操作系统虚拟内存的分页思想当显存不足时把优化器状态暂时挪到CPU内存需要时再自动拉回GPU避免训练中途OOM崩溃。实操中用QLoRA微调大模型只要改几行参数from transformers import BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, # nf4 or fp4 bnb_4bit_use_double_quantTrue, # 开启二次量化 bnb_4bit_compute_dtypetorch.bfloat16, # 计算时反量化到bf16 ) model AutoModelForCausalLM.from_pretrained( 你的基础模型路径, quantization_configbnb_config, device_mapauto, )这里有几个坑我必须强调bnb_4bit_compute_dtype建议用bfloat16而不是float16。实测在推理和训练中bf16的动态范围更大避免了fp16在某些数值区间上溢出导致loss变成NaN。load_in_4bitTrue后不要直接对底模做任何参数更新要做微调必须挂LoRA适配器PeftModel训练时只有适配器参数参与梯度更新底模权重始终是冻结的NF4状态。4bit加载并不意味着所有算子都变成INT4矩阵乘NF4推理时通常还是要反量化到compute_dtype比如bf16再做矩阵乘。它真正带来的是显存的大幅度节省而非计算加速。想明白这一点你就不会对QLoRA的推理速度抱有不切实际的期望。6.3 NF4和FP4的实际选择bitsandbytes库提供了NF4和FP4两种4bit格式实测下来NF4的精度更好这也是为什么QLoRA论文把NF4作为默认选择。FP4的优势在于实现简单、和硬件对齐更直接有些GPU硬件原生支持FP4但精度损失略大。如果你拿不定主意无脑选NF4就好。有一个细节值得留意NF4的量化是**分块block-wise**的默认块大小是64也就是说每64个权重共享一个缩放因子。块大小越小精度越高但显存开销越大如果你追求极致显存可以把bnb_4bit_block_size调大但不要超过默认太多否则精度损失会迅速累积。7. 五个方案对比与选型决策参考花了大篇幅把五种方案逐个讲透现在该回归到最现实的问题我到底该用哪一个我把它们放在一张表里快速对比方案位宽激活策略校准数据是否需要微调核心优势最适合场景LLM.int8W8A8混合精度分解不需要否开箱即用临时跑大模型、显存卡点GPTQW4A16FP16激活需要几百条否离线精度补偿4bit部署、离线量化生态成熟AWQW4A16FP16激活需要几百条否量化速度快、kernel支持好高并发在线服务SmoothQuantW8A8平滑后INT8需要几百条否真正INT8加速、精度损失小高吞吐在线服务、低延迟场景NF4W4A16FP16激活不需要配合QLoRA显存极致压缩单卡训练/微调大模型从大方向上看各方案的适用边界非常清晰追求极致推理速度 GPU支持INT8加速选SmoothQuantW8A8才是硬件加速的主力形态。追求显存省到极致 推理速度次要选AWQ或GPTQ它们都能实现4bit权重加载而且部署生态相对成熟。既要省显存又要做微调选NF4QLoRA这是目前唯一能把训练级显存占用降下来的方案。不想动量化流程、追求无感使用选LLM.int8()虽然加速有限但胜在省心。如果你觉得方案太多不知道怎么选有一个更粗暴的经验法则部署场景选AWQ没有明确部署框架就选GPTQ训练微调选NF4对延迟有强要求且GPU型号较新选SmoothQuant。8. 高频问题排查清单最后这部分全是实际操作中碰过的坑按方案分类记录下来省得你到时候一个个去搜问题。LLM.int8 相关模型加载时报CUDA out of memory先确认device_mapauto是否生效再看有没有在模型加载前不小心把其他tensor占用了显存。如果显存确实小建议直接转4bit方案。load_in_8bitTrue以后模型推理还是占用很多显存检查一下加载后是否触发了模型的反量化比如调用了.half()或.float()有些操作会不经意间把8bit权重解包回FP16显存瞬间爆炸。GPTQ 相关模型量化后输出明显变差检查group_size是不是被设成了32甚至更小检查校准数据是否足够多样必要时把damp_percent从0.01往0.05方向微调。加载4bit模型速度极慢这是反量化开销导致的优先考虑用ExLlamaV2或者AutoGPTQ的最新kernel能优化不少。如果首次加载实在不能忍试试转成AWQ格式通常加载会快一些。AWQ 相关量化时提示显存不足AWQ量化过程需要跑校准集的前向传播建议把校准集分批次加载避免一次性把几千条样本全塞进显存。量化后的模型在CPU上无法推理AWQ的kernel依赖GPUCPU上跑需要额外的反量化支持很多推理框架没做这个适配。如果你有CPU推理需求用GGUF或者GPTQ的CPU方案更现实。SmoothQuant 相关推理速度和FP16相比没有明显提升确认你的推理后端真的在做INT8 GEMM很多框架虽然支持SmoothQuant加载但默认计算路径还是FP16。查一下kernel有没有落到INT8分支。alpha调高到0.7后精度急剧下降这通常说明当前模型对权重范围很敏感迁移过度了。回退到0.5或者把校准集换得更好一些再试。NF4 相关QLoRA训练时loss震荡或出现NaN优先检查bnb_4bit_compute_dtype是否为bfloat16再检查学习率是否偏高。QLoRA微调一般用2e-4左右比全参数微调低一个量级。4bit加载后生成结果糟糕不是所有模型都适合直接4bit加载有些模型在权重量化后误差传播特别明显。这种时候先试bnb_4bit_quant_typefp4如果还不行就退回8bit或换NF4分块大小更大的配置。通用问题模型输出有时胡言乱语、有时正常大概率是量化误差在某些输入上集中爆发这通常与校准集和真实输入的分布偏差有关核心解决思路是重新校准或换量化方案不存在一步到位的银弹。不管用哪个方案记得重复一遍量化不是免费午餐每一步都是精度与资源的权衡。上线之前一定找一批有代表性的测试用例对比量化前后的输出质量而不是只看显存占用和跑分数据。结尾这套五个方案用下来我自己的体会是方案本身没有绝对优劣最重要的是想清楚你的瓶颈在哪。如果模型跑不动是因为显存不够NF4和4bit方案就是解药如果是因为推理速度不够SmoothQuant的W8A8才是真正该投入的方向如果你只是想快速验证一个想法LLM.int8()最省事。最后再分享一个小技巧不管用哪个方案都把量化前后的模型输出日志留一份跑线上之前用几十条真实业务case做一次盲测对比把质量损失控制在一个可接受范围以后再上线。我见过太多因为量化之后没做质量回归测试上线就被用户反馈“变笨了”的翻车案例。量化这个领域水很深但把它当成一套工具箱而不是一道单向门你会用得更从容。
阅读完成 · 觉得有帮助？
