最近手里的显存又告急了。一个35B级别的MoE模型FP16权重文件就要70GB往上单卡放不下双卡又嫌推理太慢。后来把模型量化到INT4整体体积砍掉近70%在24GB的消费级显卡上也能跑得动生成速度还快了不少。说实话最初我对量化是有偏见的总觉得它会让模型变笨但真正吃透原理、选对策略之后才发现量化不是无奈之下的妥协而是部署大模型时性价比最高的一道工序。这篇文章把我在实操中积累的模型量化策略写出来适合正在做模型部署、本地推理、边缘端落地的同学参考。内容覆盖量化原理、档位选择、开源工具链、校准集处理、以及上线前容易踩的坑尽量用白话讲清楚并给出可以照着做的方案。1. 为什么没人在生产环境老老实实跑满精度先泼一盆冷水在真实的生产环境里绝大多数大模型都不是以FP16甚至FP32的原始精度运行的。不是大家不想保留精度而是物理条件不允许。1.1 FP16模型的显存账单拿一个35B参数量的模型举例。FP16精度下每个权重占2字节光权重文件就是70GB。跑推理的时候还不能只算权重KV Cache、激活值、中间结果都是一笔额外开销。实测下来一个35B模型的推理峰值显存往往要到110GB上下这已经超过了两张A100 80GB的显存总和。如果是部署在边缘设备或消费级显卡上这个数字几乎是致命的。我看过一组数据目前个人开发者手头最常用的显卡是RTX 3060 12GB和RTX 4090 24GB显存稍大一点的A100 80GB普通人根本摸不到。想在这些设备上跑大模型量化是唯一现实出路。1.2 量化真正的意义不是省内存而是提速度很多人以为量化只是为了把模型塞进更小的显存其实这个理解只对了一半。量化的核心收益在于降低内存带宽压力。推理过程中GPU每次生成一个token都需要把模型权重从显存搬到计算单元。搬运速度受限于显存带宽而计算单元大多数时候是在等数据。模型权重的比特数降下来搬运的数据量就减少生成速度自然就上去了。这就好比一个快递分拣员——假如每个包裹都用一个巨大的纸箱装着FP16搬运起来费时费力换成压缩过的轻便包装INT4同样时间能处理几倍的包裹。分拣台上的机械臂计算能力一直没有变但吞吐量翻番了。2. 从FP16到INT4数值映射的数学直觉与误差来源理解了量化是为了省钱省力接下来就得看懂量化到底对模型做了什么。这一步非常重要因为只有弄懂了底层原理后面做档位选择和工具选型时才不会两眼一抹黑。2.1 对称量化与非对称量化一张表看懂取舍量化的本质是把一个高精度数值范围压到一个低比特整数范围。最常见的做法是线性映射关键在于两个参数缩放因子scale和零点偏移zero point。对称量化把原始浮点张量的范围对称映射到整数范围的正负两侧zero point固定为0实现简单推理时计算量小。非对称量化则允许浮点分布不对称比如ReLU后的激活值全是正数用zero point把整数的0平移到浮点分布的中心这样能更充分地利用整数编码空间精度损失更小代价是实现复杂。拿一个小例子感受一下一个张量x [-2.5, 0.3, 1.7]如果要量化到INT8范围-128到127对称量化的scale就是2.5/128 ≈ 0.0195量化结果为[-128, 15, 87]。看起来很简单但注意0.3量化成了15反量化回去是0.2925误差不大可如果分布里有一个极端大的离群值把scale撑大了其他正常数值的精度就会集体下降。这个离群值拖累全局精度的现象是量化误差里最常见的一类问题后面讲校准数据集时还会碰到。2.2 三元量化为什么特殊最近注意到三元量化模型这个热词。它和常规的INT8/INT4不是一个维度的东西值得单独说。三元量化的思路来自BitNet系列工作核心是把权重约束到三个取值{-1, 0, 1}。这话听起来极端但效果出乎意料。因为当权重只有三个可能值时原本的浮点矩阵乘法就变成了纯粹的加减法——GPU上的计算开销被大幅压缩同时显存占用也降到极致。以1.58bit的BitNet b1.58为例它相当于每个权重用不到2比特表示比INT4还要激进。三元量化的问题也很明显表达能力有限。适合对精度要求不苛刻、但推理速度要求极高的场景比如边端设备上的实时响应模型。常规聊天、文档摘要这类任务想用三元量化达到生产可用标准至少目前还不太现实。它更适合作为研究方向和特定场景下的特种工具而不是通用方案。2.3 量化误差的三个来源不管用哪种量化方式误差总归来自三个方面舍入误差——把浮点数映射到整数时小数部分丢失。这是不可避免的只能通过调整scale和zero point来减小。裁剪误差——浮点分布中超出整数表示范围的极端值被截断。量化范围设窄了裁剪误差大设宽了舍入误差大。两者此消彼长需要找到一个平衡点。分布偏移——量化在降低数值精度的同时改变了模型内部激活值的分布形态。经过多层网络累积这个偏移会被放大最终体现为生成质量的下降。理解了这三个误差来源你就能理解为什么量化策略的关键不在于把数值压得多低而在于如何把误差控制在模型能力不受明显影响的范围之内。3. 档位怎么选INT8、INT4、三元量化的适用边界逛社区的时候经常看到开源模型量化档排名这种话题大家乐此不疲地对比各个档位跑出来的效果。我的结论是档位没有绝对的好坏只有适不适合你的硬件和任务。这里把主流档位放在一起对比一下。量化档位单权重体积推理速度精度损失适用场景FP16原始2字节基准无上游训练、评测INT81字节快约1.5-2倍极小服务端推理、批量任务INT40.5字节快约2-3倍较小消费级显卡本地部署三元/1.58bit约0.2字节极快明显边端设备、实时响应3.1 MoE模型的量化特殊性热搜词里出现了一个具体的模型名后缀很长但重点是前面的参数结构35B总参数、3B激活参数这是标准的MoE混合专家架构。这类模型的推理特点是虽然总权重有35B但每个token只激活其中一小部分专家计算量远低于同体量的稠密模型。MoE模型对量化格外友好。因为你量化的对象是全部权重文件而35B的MoE量化到INT4后只有18GB左右一张24GB的显卡能轻松装下。激活参数只有3B量化带来的计算精度下降对推理质量的影响也更可控。所以我现在遇到MoE模型第一反应就是先量化到INT4再说。3.2 不同档位对模型能力的实际影响从我实测过的多个开源模型Qwen系列、Llama系列等来看精度损失与任务类型高度相关。代码生成和数学推理这两个方向对量化最敏感INT4下偶尔会出现逻辑错误率上升代码里出现低级bug的概率也会增加。通用对话、文案写作、知识问答这类方向对量化非常宽容INT4和FP16的输出质量差距绝大多数用户分辨不出来。至于三元量化坦白讲目前还没有哪个开源模型的1.58bit版本敢说自己能完整保住对话能力。它更适合做垂直单任务场景比如分类、抽取、指令识别这类够用就行的活。这也是为什么我不建议一上来就追求最低比特——除非你非常清楚自己的任务对精度不敏感。4. 主流量化工具链GPTQ、AWQ、GGUF的选型逻辑选好了档位下一步就要决定用什么工具来干活。市面上主流的量化工具五花八门但绕不开三个名字GPTQ、AWQ和GGUF。这三者解决的问题不太一样选错工具会浪费大量时间。4.1 GPTQ与AWQ算法层面的差异GPTQ是经典方案核心思路是用逐层校准的方式把量化误差最小化。它和后面讲到的校准数据集绑定很深——需要提供一批代表真实分布的样本数据让算法在量化每一层时参考这些样本找出最优的scale。AWQ激活感知量化的思路更聪明它不去管权重本身而是观察激活值。如果一个通道的激活值总是出现较大的数值说明这个通道对整体输出更重要量化时会专门给它分配更高精度保留为FP16或者使用更小的scale。这样可以做到的量化效果普遍比GPTQ在低比特位下更稳。实操中我的感受是4bit以下比如INT3、INT2AWQ比GPTQ更能保住代码能力4bit以上两者差距不大。4.2 GGUF的k-quants分级GGUF是另一套生态它的量化重点不在算法而在跨平台兼容性。GGUF文件把权重和Tokenizer、配置打包在一起配合llama.cpp生态不管你是CPU、苹果M系列还是NVIDIA显卡都能跑起来。这也让它成为本地部署MacBook用户的首选。GGUF内部的量化方案有一串令人头疼的名字Q2_K、Q3_K、Q4_K_S、Q5_K_M、Q8_0这些就是k-quants分级的各个档位。命名规则里第一段是量化比特数第二段是分块等级。我的建议是显存紧张跑Q4_K_M这是性价比最高的档位也是社区常说的甜点档显存充裕跑Q5_K_M或Q6_K质量接近原版但体积更可控坚决不建议为了省几个GB去用Q2_K或Q3_K省下来的显存远远抵不上模型智力的断崖式下跌4.3 我的选型习惯实际项目里我一般按下面这套规则来服务端推理用AWQ配合vLLM或SGLang吞吐量高且稳定本地Mac或CPU用户用GGUF图个省事不用自己配置环境要做PTQ训练后量化对比实验时先用GPTQ快速验证可行性再做AWQ精调记住一个原则:工具选型一旦选定就不要频繁更换。因为不同工具的量化方案差异会导致最终效果的细微变化频繁切换很难确定模型质量波动到底来自模型本身还是量化工具。5. 校准数据集精度崩坏的头号原因如果说量化有什么地方最容易被新人翻车那我毫不犹豫地提名校准数据集。很多人跑量化脚本随便拿几十条样本喂进去出来的模型效果不好就怪量化本身太渣——其实锅在校准集上。5.1 校准集不是随便找点文本GPTQ这类基于校准的量化算法原理是拿着一批样本在推理时计算每层激活值的分布然后基于这个分布求最优缩放参数。校准集的质量直接决定了量化误差的大小。我见过最离谱的用法是拿训练集里的几百条数据来做校准结果模型上线后被用户抱怨说话像个复读机生成的内容大量重复。原因很简单校准样本太集中在一个狭窄的分布区间scale被这些样本带偏了模型在更广泛的输入分布下精度崩坏。实操中的建议校准集必须覆盖你实际使用时的输入分布。比如模型上线后主要做客服对话校准集就应该是客服对话样本而不是维基百科文本。样本条数不用贪多128条到256条就够关键是多样性。校准集和评测集必须分开。有过惨痛教训有人拿评测集去校准评测分数出奇地高上线效果一塌糊涂——这就是典型的数据泄漏。5.2 校准样本数量实验为了把这块讲透我做过一次完整实验。用同一个7B模型分别用16、64、256、1024条校准样本做INT4量化然后在同一个评测集上测精度。结果是16条样本时模型表现明显拉胯生成经常跑题64条样本时恢复到正常水平的九成256条和1024条几乎无差别时间上却相差近一倍。这说明校准数据的边际收益递减很厉害刻意堆样本数量没有任何意义。有一个容易被忽略的细节校准样本的长度也会影响量化效果。短文本样本几十个token会让激活分布的覆盖范围偏小建议校准集里混入一些中等长度512-1024 token的文本让分布更饱满。6. 部署避坑实录显存计算、算子兼容与采样质量的平衡量化的种种准备工作做完最后一步是上线部署。这一步的坑比前几步都深稍不留神就把之前省下的显存又赔进去或者让模型输出质量变得说不出的别扭。6.1 显存不能只看权重文件大小很多人算显存只算权重文件体积这是最典型的部署翻车点。INT4的35B模型权重是18GB听起来放24GB的卡绰绰有余但你还要算上KV Cache、激活值、框架运行时开销。拿一个实际经过来举例35B MoE模型INT4量化权重18GB上下文长度4096时KV Cache要额外占约8GB激活值和框架开销再加2-4GB实际占用已经到了28-30GB24GB的卡根本装不下。这就是为什么我建议部署计算时至少预留1.5倍权重文件大小的显存预算。如果实测发现放不下正确思路不是马上降到INT2而是优先考虑缩短上下文长度、限制并发数、或者改用量化后的KV Cache。这些手段加在一起效果比无脑降比特位靠谱得多。6.2 算子兼容性量化模型最隐蔽的坑量化模型不是随便一个推理框架都能完美跑起来的。有些算子比如某些注意力变体、特殊的激活函数在低精度下没有对应的kernel实现框架会退化到用FP16解量化算子运行——这个过程不仅慢还会稳不住显存占用。我遇到过最头痛的情况一个量化好的模型在A卡上完全正常换到另一家GPU上推理速度骤降百分之六十查了半天原因是有两个算子在目标设备上没有INT4的kernel退化成了FP16执行。降级执行不报错只有观察性能时才能发现异常。解决思路是上线前先小规模压测把吞吐量和延迟数据拉出来看一眼。如果发现某个模型在特定设备上的速度明显低于预期先怀疑算子兼容性而不是模型本身。6.3 量化后采样质量变钝量化模型生成的文本质量主观感受上往往会变钝——字面通顺但表现力不足。这里有个常被忽略的技术原因量化不仅压缩了权重还改变了采样时的softmax分布曲线。原版模型在softmax之前的logits数值分布跨度较大采样时容易产生明显的高概率token和低概率token分化量化后logits分布被压缩概率差异变小采样随机性增加结果就是文本变得平淡、缺乏突出的词语选择。处理办法是调整采样参数而不是怀疑量化坏了。经验值是量化模型比原版模型适当调低temperature比如从0.8降到0.65同时微调top_p能明显恢复生成文本的锐度。这个经验在很多社区帖里被反复验证过非常有效。6.4 混合精度量化留一手保护敏感层如果你想在INT4的基础上进一步压显存或者发现量化后某个具体能力比如代码缩进、长文本逻辑退化明显可以试试混合精度量化把关键的敏感层保留在INT8甚至FP16其余层降到INT4。哪些层是敏感层以我的经验看第一层和最后一层嵌入层最敏感attention层次之FFN层最不敏感。把embedding层保留FP16整个模型往往只需要多花几个GB的显存却能把量化损失降一个档次。GPTQ和AWQ都支持自定义层级精度这个方法在工程上很容易落地。上线前最重要的一个环节是准备一个能快速跑完的评测清单。我一般会测三件事一段代码补全评估逻辑能力、一段复杂指令遵循评估对齐能力、一段长文本摘要评估信息保持能力。三个任务跑完基本就能判断这个量化版本能不能撑住生产需求。最后分享一个小经验是我跑量化跑了很久才养成的习惯拿量化前后的模型做同样的10组推理对比输出结果的多样性。如果量化版本输出的10组结果差异明显小于原版说明采样分布被过度压缩了这时候调采样参数比调量化参数更优先。这个判断方法不需要跑评测集三分钟就能出结论在实际项目里救过我很多次。
最近手里的显存又告急了。一个35B级别的MoE模型FP16权重文件就要70GB往上单卡放不下双卡又嫌推理太慢。后来把模型量化到INT4整体体积砍掉近70%在24GB的消费级显卡上也能跑得动生成速度还快了不少。说实话最初我对量化是有偏见的总觉得它会让模型变笨但真正吃透原理、选对策略之后才发现量化不是无奈之下的妥协而是部署大模型时性价比最高的一道工序。这篇文章把我在实操中积累的模型量化策略写出来适合正在做模型部署、本地推理、边缘端落地的同学参考。内容覆盖量化原理、档位选择、开源工具链、校准集处理、以及上线前容易踩的坑尽量用白话讲清楚并给出可以照着做的方案。1. 为什么没人在生产环境老老实实跑满精度先泼一盆冷水在真实的生产环境里绝大多数大模型都不是以FP16甚至FP32的原始精度运行的。不是大家不想保留精度而是物理条件不允许。1.1 FP16模型的显存账单拿一个35B参数量的模型举例。FP16精度下每个权重占2字节光权重文件就是70GB。跑推理的时候还不能只算权重KV Cache、激活值、中间结果都是一笔额外开销。实测下来一个35B模型的推理峰值显存往往要到110GB上下这已经超过了两张A100 80GB的显存总和。如果是部署在边缘设备或消费级显卡上这个数字几乎是致命的。我看过一组数据目前个人开发者手头最常用的显卡是RTX 3060 12GB和RTX 4090 24GB显存稍大一点的A100 80GB普通人根本摸不到。想在这些设备上跑大模型量化是唯一现实出路。1.2 量化真正的意义不是省内存而是提速度很多人以为量化只是为了把模型塞进更小的显存其实这个理解只对了一半。量化的核心收益在于降低内存带宽压力。推理过程中GPU每次生成一个token都需要把模型权重从显存搬到计算单元。搬运速度受限于显存带宽而计算单元大多数时候是在等数据。模型权重的比特数降下来搬运的数据量就减少生成速度自然就上去了。这就好比一个快递分拣员——假如每个包裹都用一个巨大的纸箱装着FP16搬运起来费时费力换成压缩过的轻便包装INT4同样时间能处理几倍的包裹。分拣台上的机械臂计算能力一直没有变但吞吐量翻番了。2. 从FP16到INT4数值映射的数学直觉与误差来源理解了量化是为了省钱省力接下来就得看懂量化到底对模型做了什么。这一步非常重要因为只有弄懂了底层原理后面做档位选择和工具选型时才不会两眼一抹黑。2.1 对称量化与非对称量化一张表看懂取舍量化的本质是把一个高精度数值范围压到一个低比特整数范围。最常见的做法是线性映射关键在于两个参数缩放因子scale和零点偏移zero point。对称量化把原始浮点张量的范围对称映射到整数范围的正负两侧zero point固定为0实现简单推理时计算量小。非对称量化则允许浮点分布不对称比如ReLU后的激活值全是正数用zero point把整数的0平移到浮点分布的中心这样能更充分地利用整数编码空间精度损失更小代价是实现复杂。拿一个小例子感受一下一个张量x [-2.5, 0.3, 1.7]如果要量化到INT8范围-128到127对称量化的scale就是2.5/128 ≈ 0.0195量化结果为[-128, 15, 87]。看起来很简单但注意0.3量化成了15反量化回去是0.2925误差不大可如果分布里有一个极端大的离群值把scale撑大了其他正常数值的精度就会集体下降。这个离群值拖累全局精度的现象是量化误差里最常见的一类问题后面讲校准数据集时还会碰到。2.2 三元量化为什么特殊最近注意到三元量化模型这个热词。它和常规的INT8/INT4不是一个维度的东西值得单独说。三元量化的思路来自BitNet系列工作核心是把权重约束到三个取值{-1, 0, 1}。这话听起来极端但效果出乎意料。因为当权重只有三个可能值时原本的浮点矩阵乘法就变成了纯粹的加减法——GPU上的计算开销被大幅压缩同时显存占用也降到极致。以1.58bit的BitNet b1.58为例它相当于每个权重用不到2比特表示比INT4还要激进。三元量化的问题也很明显表达能力有限。适合对精度要求不苛刻、但推理速度要求极高的场景比如边端设备上的实时响应模型。常规聊天、文档摘要这类任务想用三元量化达到生产可用标准至少目前还不太现实。它更适合作为研究方向和特定场景下的特种工具而不是通用方案。2.3 量化误差的三个来源不管用哪种量化方式误差总归来自三个方面舍入误差——把浮点数映射到整数时小数部分丢失。这是不可避免的只能通过调整scale和zero point来减小。裁剪误差——浮点分布中超出整数表示范围的极端值被截断。量化范围设窄了裁剪误差大设宽了舍入误差大。两者此消彼长需要找到一个平衡点。分布偏移——量化在降低数值精度的同时改变了模型内部激活值的分布形态。经过多层网络累积这个偏移会被放大最终体现为生成质量的下降。理解了这三个误差来源你就能理解为什么量化策略的关键不在于把数值压得多低而在于如何把误差控制在模型能力不受明显影响的范围之内。3. 档位怎么选INT8、INT4、三元量化的适用边界逛社区的时候经常看到开源模型量化档排名这种话题大家乐此不疲地对比各个档位跑出来的效果。我的结论是档位没有绝对的好坏只有适不适合你的硬件和任务。这里把主流档位放在一起对比一下。量化档位单权重体积推理速度精度损失适用场景FP16原始2字节基准无上游训练、评测INT81字节快约1.5-2倍极小服务端推理、批量任务INT40.5字节快约2-3倍较小消费级显卡本地部署三元/1.58bit约0.2字节极快明显边端设备、实时响应3.1 MoE模型的量化特殊性热搜词里出现了一个具体的模型名后缀很长但重点是前面的参数结构35B总参数、3B激活参数这是标准的MoE混合专家架构。这类模型的推理特点是虽然总权重有35B但每个token只激活其中一小部分专家计算量远低于同体量的稠密模型。MoE模型对量化格外友好。因为你量化的对象是全部权重文件而35B的MoE量化到INT4后只有18GB左右一张24GB的显卡能轻松装下。激活参数只有3B量化带来的计算精度下降对推理质量的影响也更可控。所以我现在遇到MoE模型第一反应就是先量化到INT4再说。3.2 不同档位对模型能力的实际影响从我实测过的多个开源模型Qwen系列、Llama系列等来看精度损失与任务类型高度相关。代码生成和数学推理这两个方向对量化最敏感INT4下偶尔会出现逻辑错误率上升代码里出现低级bug的概率也会增加。通用对话、文案写作、知识问答这类方向对量化非常宽容INT4和FP16的输出质量差距绝大多数用户分辨不出来。至于三元量化坦白讲目前还没有哪个开源模型的1.58bit版本敢说自己能完整保住对话能力。它更适合做垂直单任务场景比如分类、抽取、指令识别这类够用就行的活。这也是为什么我不建议一上来就追求最低比特——除非你非常清楚自己的任务对精度不敏感。4. 主流量化工具链GPTQ、AWQ、GGUF的选型逻辑选好了档位下一步就要决定用什么工具来干活。市面上主流的量化工具五花八门但绕不开三个名字GPTQ、AWQ和GGUF。这三者解决的问题不太一样选错工具会浪费大量时间。4.1 GPTQ与AWQ算法层面的差异GPTQ是经典方案核心思路是用逐层校准的方式把量化误差最小化。它和后面讲到的校准数据集绑定很深——需要提供一批代表真实分布的样本数据让算法在量化每一层时参考这些样本找出最优的scale。AWQ激活感知量化的思路更聪明它不去管权重本身而是观察激活值。如果一个通道的激活值总是出现较大的数值说明这个通道对整体输出更重要量化时会专门给它分配更高精度保留为FP16或者使用更小的scale。这样可以做到的量化效果普遍比GPTQ在低比特位下更稳。实操中我的感受是4bit以下比如INT3、INT2AWQ比GPTQ更能保住代码能力4bit以上两者差距不大。4.2 GGUF的k-quants分级GGUF是另一套生态它的量化重点不在算法而在跨平台兼容性。GGUF文件把权重和Tokenizer、配置打包在一起配合llama.cpp生态不管你是CPU、苹果M系列还是NVIDIA显卡都能跑起来。这也让它成为本地部署MacBook用户的首选。GGUF内部的量化方案有一串令人头疼的名字Q2_K、Q3_K、Q4_K_S、Q5_K_M、Q8_0这些就是k-quants分级的各个档位。命名规则里第一段是量化比特数第二段是分块等级。我的建议是显存紧张跑Q4_K_M这是性价比最高的档位也是社区常说的甜点档显存充裕跑Q5_K_M或Q6_K质量接近原版但体积更可控坚决不建议为了省几个GB去用Q2_K或Q3_K省下来的显存远远抵不上模型智力的断崖式下跌4.3 我的选型习惯实际项目里我一般按下面这套规则来服务端推理用AWQ配合vLLM或SGLang吞吐量高且稳定本地Mac或CPU用户用GGUF图个省事不用自己配置环境要做PTQ训练后量化对比实验时先用GPTQ快速验证可行性再做AWQ精调记住一个原则:工具选型一旦选定就不要频繁更换。因为不同工具的量化方案差异会导致最终效果的细微变化频繁切换很难确定模型质量波动到底来自模型本身还是量化工具。5. 校准数据集精度崩坏的头号原因如果说量化有什么地方最容易被新人翻车那我毫不犹豫地提名校准数据集。很多人跑量化脚本随便拿几十条样本喂进去出来的模型效果不好就怪量化本身太渣——其实锅在校准集上。5.1 校准集不是随便找点文本GPTQ这类基于校准的量化算法原理是拿着一批样本在推理时计算每层激活值的分布然后基于这个分布求最优缩放参数。校准集的质量直接决定了量化误差的大小。我见过最离谱的用法是拿训练集里的几百条数据来做校准结果模型上线后被用户抱怨说话像个复读机生成的内容大量重复。原因很简单校准样本太集中在一个狭窄的分布区间scale被这些样本带偏了模型在更广泛的输入分布下精度崩坏。实操中的建议校准集必须覆盖你实际使用时的输入分布。比如模型上线后主要做客服对话校准集就应该是客服对话样本而不是维基百科文本。样本条数不用贪多128条到256条就够关键是多样性。校准集和评测集必须分开。有过惨痛教训有人拿评测集去校准评测分数出奇地高上线效果一塌糊涂——这就是典型的数据泄漏。5.2 校准样本数量实验为了把这块讲透我做过一次完整实验。用同一个7B模型分别用16、64、256、1024条校准样本做INT4量化然后在同一个评测集上测精度。结果是16条样本时模型表现明显拉胯生成经常跑题64条样本时恢复到正常水平的九成256条和1024条几乎无差别时间上却相差近一倍。这说明校准数据的边际收益递减很厉害刻意堆样本数量没有任何意义。有一个容易被忽略的细节校准样本的长度也会影响量化效果。短文本样本几十个token会让激活分布的覆盖范围偏小建议校准集里混入一些中等长度512-1024 token的文本让分布更饱满。6. 部署避坑实录显存计算、算子兼容与采样质量的平衡量化的种种准备工作做完最后一步是上线部署。这一步的坑比前几步都深稍不留神就把之前省下的显存又赔进去或者让模型输出质量变得说不出的别扭。6.1 显存不能只看权重文件大小很多人算显存只算权重文件体积这是最典型的部署翻车点。INT4的35B模型权重是18GB听起来放24GB的卡绰绰有余但你还要算上KV Cache、激活值、框架运行时开销。拿一个实际经过来举例35B MoE模型INT4量化权重18GB上下文长度4096时KV Cache要额外占约8GB激活值和框架开销再加2-4GB实际占用已经到了28-30GB24GB的卡根本装不下。这就是为什么我建议部署计算时至少预留1.5倍权重文件大小的显存预算。如果实测发现放不下正确思路不是马上降到INT2而是优先考虑缩短上下文长度、限制并发数、或者改用量化后的KV Cache。这些手段加在一起效果比无脑降比特位靠谱得多。6.2 算子兼容性量化模型最隐蔽的坑量化模型不是随便一个推理框架都能完美跑起来的。有些算子比如某些注意力变体、特殊的激活函数在低精度下没有对应的kernel实现框架会退化到用FP16解量化算子运行——这个过程不仅慢还会稳不住显存占用。我遇到过最头痛的情况一个量化好的模型在A卡上完全正常换到另一家GPU上推理速度骤降百分之六十查了半天原因是有两个算子在目标设备上没有INT4的kernel退化成了FP16执行。降级执行不报错只有观察性能时才能发现异常。解决思路是上线前先小规模压测把吞吐量和延迟数据拉出来看一眼。如果发现某个模型在特定设备上的速度明显低于预期先怀疑算子兼容性而不是模型本身。6.3 量化后采样质量变钝量化模型生成的文本质量主观感受上往往会变钝——字面通顺但表现力不足。这里有个常被忽略的技术原因量化不仅压缩了权重还改变了采样时的softmax分布曲线。原版模型在softmax之前的logits数值分布跨度较大采样时容易产生明显的高概率token和低概率token分化量化后logits分布被压缩概率差异变小采样随机性增加结果就是文本变得平淡、缺乏突出的词语选择。处理办法是调整采样参数而不是怀疑量化坏了。经验值是量化模型比原版模型适当调低temperature比如从0.8降到0.65同时微调top_p能明显恢复生成文本的锐度。这个经验在很多社区帖里被反复验证过非常有效。6.4 混合精度量化留一手保护敏感层如果你想在INT4的基础上进一步压显存或者发现量化后某个具体能力比如代码缩进、长文本逻辑退化明显可以试试混合精度量化把关键的敏感层保留在INT8甚至FP16其余层降到INT4。哪些层是敏感层以我的经验看第一层和最后一层嵌入层最敏感attention层次之FFN层最不敏感。把embedding层保留FP16整个模型往往只需要多花几个GB的显存却能把量化损失降一个档次。GPTQ和AWQ都支持自定义层级精度这个方法在工程上很容易落地。上线前最重要的一个环节是准备一个能快速跑完的评测清单。我一般会测三件事一段代码补全评估逻辑能力、一段复杂指令遵循评估对齐能力、一段长文本摘要评估信息保持能力。三个任务跑完基本就能判断这个量化版本能不能撑住生产需求。最后分享一个小经验是我跑量化跑了很久才养成的习惯拿量化前后的模型做同样的10组推理对比输出结果的多样性。如果量化版本输出的10组结果差异明显小于原版说明采样分布被过度压缩了这时候调采样参数比调量化参数更优先。这个判断方法不需要跑评测集三分钟就能出结论在实际项目里救过我很多次。
