1. 模型优化器到底在优化什么第一次看到 Model-Optimizer 这个词很多人会下意识以为它又是一个“调参神器”或者“自动炼丹炉”。我刚开始接触的时候也这么想后来踩了几次坑才明白它本质上是一套围绕模型推理与训练效率做系统性压缩和加速的工具链思路。你可以把它理解成给模型做“瘦身提速”的整套方案而不是单一某个函数。模型优化器要解决的核心问题很朴素模型太大、跑得太慢、显存吃得太狠。一个在实验室里跑得好好的模型一旦要部署到实际业务里马上就会遇到延迟高、成本高、并发上不去的问题。Model-Optimizer 这类工具的价值就是把这些“落地最后一公里”的问题系统化地处理掉。它适合谁如果你是把模型从 notebook 推向生产环境的工程师或者是需要在有限硬件上跑更大模型的开发者再或者你只是想让自己的推理服务响应更快一点那这套东西都值得花时间研究。哪怕你只是做实验理解优化器的原理也能帮你少走很多弯路。我个人的判断是模型优化不是“锦上添花”而是“雪中送炭”。当你的服务 QPS 上不去、GPU 利用率只有 30% 的时候优化带来的收益往往比换更贵的卡更直接。下面我就按自己的实操经验把 Model-Optimizer 这套东西拆开讲清楚。2. 模型优化的整体思路与方案选型2.1 为什么优化要从“量化”和“剪枝”两条主线入手模型优化的手段很多但真正在生产里被反复验证、性价比最高的主要就是两条主线量化Quantization和剪枝Pruning再加上一个经常被忽略但极其关键的算子融合Operator Fusion。量化是把模型权重和激活值从高精度比如 FP32降到低精度比如 FP16、INT8 甚至 INT4。它的逻辑很直接模型里大量参数其实不需要那么高的精度用低精度表示几乎不影响效果但显存占用和计算量能大幅下降。我实测过一个 7B 级别的模型从 FP16 量化到 INT8显存占用直接砍掉接近一半推理速度提升 30% 以上而效果下降在可接受范围内。剪枝则是把模型里“贡献很小”的权重或结构去掉。它比量化更激进因为一旦剪错模型可能直接“变傻”。所以剪枝通常需要配合微调fine-tuning来恢复精度。我一般建议新手先从量化入手剪枝放到后面再碰。算子融合是很多人忽略的一环。它不改变模型结构而是把多个连续的小算子合并成一个减少 kernel 启动开销和内存读写。这个优化在推理框架里通常是自动做的但你需要知道它的存在才能理解为什么同样的模型在不同框架下速度差那么多。2.2 方案选型的三个关键判断维度选优化方案不能拍脑袋我一般看三个维度精度容忍度、硬件支持、工程成本。精度容忍度决定了你能压到多低。如果你的业务对输出质量极其敏感比如医疗、金融场景那 INT8 可能就是底线INT4 要非常谨慎。如果只是做内容生成、推荐排序那 INT4 甚至更激进的方案都可以试。硬件支持是硬约束。不是所有显卡都支持 INT8 或 INT4 的加速指令。比如一些老卡对低精度支持很差你量化了反而更慢。所以动手前一定要查清楚目标硬件的算力特性。工程成本包括改造成本和维护成本。有些优化方案需要你改推理代码、重新导出模型、甚至重写部分算子。如果团队人手有限优先选那些“改一行配置就能生效”的方案。提示不要一上来就追求极致压缩。先跑通一个 baseline再逐步加优化每次只改一个变量这样出问题才知道是哪一步导致的。2.3 优化顺序的实操建议我踩过的最大坑就是“一次性全上”。量化、剪枝、融合一起搞结果精度崩了根本不知道是谁的锅。后来我固定了一套顺序先做算子融合通常无损再做量化FP16 → INT8 逐步来最后才考虑剪枝。每一步都做精度对比和性能测试确认没问题再进下一步。这个顺序的好处是风险可控。算子融合基本无损量化损失可量化剪枝风险最高放最后。这样即使剪枝出问题前面的收益也已经拿到了。3. 量化实操从 FP16 到 INT8 的完整流程3.1 量化前的准备工作动手量化之前有几件事必须先做。第一是确定评估指标。不能只看 loss要看业务相关的指标比如生成任务的 BLEU、分类任务的准确率、排序任务的 AUC。我一般会准备一个固定的小测试集每次优化后都跑一遍确保对比公平。第二是备份原始模型。量化过程可能不可逆尤其是动态量化一旦转换失败或者效果崩了你得能回到原点。我习惯把原始权重、配置文件、导出脚本全部打包存档。第三是确认推理框架。不同框架对量化的支持差异很大。有的框架只支持静态量化有的支持动态量化有的对某些算子根本不支持低精度。你需要提前查文档避免做到一半发现走不通。3.2 静态量化与动态量化的选择静态量化和动态量化的区别简单说就是“提前算好缩放因子”还是“运行时算”。静态量化需要在校准集上跑一遍统计激活值的分布提前确定量化参数。它的优点是推理时速度快因为缩放因子是固定的。缺点是校准集选不好会影响精度而且对输入分布变化敏感。动态量化则是运行时根据实际输入计算缩放因子。它更灵活对输入变化鲁棒但推理时多了一步计算速度略慢。我一般建议如果输入分布稳定比如固定格式的文本分类用静态量化如果输入变化大比如开放域对话用动态量化更稳。# 静态量化的大致流程示意 # 1. 准备校准数据 calibration_data load_calibration_dataset() # 2. 配置量化方案 quant_config { weight_dtype: int8, activation_dtype: int8, calibration_samples: 128 } # 3. 执行量化 quantized_model quantize_model( original_model, configquant_config, calibration_datacalibration_data ) # 4. 评估精度 evaluate(quantized_model, test_dataset)3.3 量化精度的评估与调优量化后精度下降是常态关键是把下降控制在可接受范围。我一般会看三个指标绝对精度下降、相对精度下降、以及最差样本的表现。绝对精度下降是看整体指标掉了多少比如准确率从 95% 掉到 93%那就是掉了 2 个点。相对精度下降是看掉了百分之多少2/95 大概是 2.1%。最差样本的表现最容易被忽略但很重要——有时候整体指标没怎么掉但某些特定输入的结果完全崩了这种问题在实际业务里是致命的。如果精度下降太多可以尝试几个调优手段。一是混合精度对敏感层保留高精度其他层用低精度。二是调整校准集让校准数据更贴近真实分布。三是量化感知训练QAT在训练阶段就模拟量化误差让模型提前适应。注意混合精度虽然能救精度但会削弱加速效果。我一般只在关键层用比如 attention 的输出层其他层还是保持低精度。3.4 量化后的性能实测量化完一定要实测性能不能只看理论收益。我实测过一个模型理论上 INT8 应该比 FP16 快一倍但实际只快了 40%。原因是某些算子没有低精度加速支持反而走了 fallback 路径。实测时我一般关注三个数据首 token 延迟、吞吐量tokens/s、显存峰值。首 token 延迟影响用户体验吞吐量影响成本显存峰值决定你能跑多大 batch。这三个数据要一起看不能只盯一个。精度显存峰值吞吐量首 token 延迟FP3224GB120 tokens/s350msFP1613GB210 tokens/s220msINT87GB290 tokens/s180msINT44GB340 tokens/s165ms上面这组数据是我在某次实测中记录的可以看到 INT4 的收益已经明显递减了但显存占用还在降。所以如果你的瓶颈是显存INT4 值得试如果瓶颈是速度INT8 性价比最高。4. 剪枝与算子融合的实操细节4.1 结构化剪枝与非结构化剪枝的区别剪枝分两种结构化剪枝和非结构化剪枝。非结构化剪枝是把单个权重置零模型结构不变但权重矩阵变得稀疏。它的优点是精度损失小缺点是通用硬件对稀疏矩阵的加速支持有限实际提速可能不明显。结构化剪枝是直接去掉整个通道、整个头或者整个层。它的优点是模型结构真的变小了推理速度提升明显。缺点是精度损失大通常需要微调恢复。我一般建议如果目标硬件支持稀疏加速比如某些专用芯片可以试非结构化剪枝如果是通用 GPU优先结构化剪枝因为提速更实在。4.2 剪枝比例怎么定剪枝比例是最难调的参数。剪太少没效果剪太多模型崩。我的经验是从小比例开始比如先剪 10%评估精度再逐步加到 20%、30%。每次加完都重新评估找到精度开始明显下降的临界点然后回退一档。还有一个技巧是分层剪枝。不同层对剪枝的敏感度不一样通常 attention 层比 FFN 层更敏感浅层比深层更敏感。所以可以对敏感层少剪对不敏感层多剪。这个需要做一些实验来确定每层的敏感度。# 分层剪枝比例配置示意 pruning_config { layer_0_attention: 0.05, # 浅层 attention 少剪 layer_0_ffn: 0.15, layer_1_attention: 0.08, layer_1_ffn: 0.20, layer_2_attention: 0.10, layer_2_ffn: 0.25, # 深层可以剪得更激进 }4.3 算子融合的实际效果算子融合通常由推理框架自动完成但你需要知道它做了什么才能判断性能瓶颈在哪。常见的融合包括ConvBNReLU 融合成一个算子、LayerNorm 融合、以及 attention 里的 QKV 计算融合。我实测过光是 attention 里的算子融合就能带来 15% 到 25% 的提速。这个收益是“白捡”的因为不损失精度。所以选推理框架时一定要看它的融合能力。提示如果你的框架不支持自动融合可以手动用图优化工具做。但手动融合容易出错建议先用小模型验证确认输出一致再上大模型。4.4 剪枝后的微调策略剪枝后微调是恢复精度的关键。我一般用较小的学习率比如原始学习率的 1/10跑 1 到 3 个 epoch。数据用原始训练集的子集就行不需要全量。微调时要注意冻结策略。我通常冻结没被剪的层只训练被剪的层和最后的输出层。这样收敛快也不容易破坏原有能力。如果精度恢复不理想再逐步解冻更多层。还有一个坑是过拟合。剪枝后模型容量变小如果微调数据太少或者跑太多 epoch很容易过拟合。我一般会在验证集上监控一旦指标不再提升就停。5. 常见问题与排查技巧实录5.1 量化后精度暴跌怎么办精度暴跌是最常见的问题。排查思路我一般按这个顺序走第一检查校准集。校准集和真实数据分布差异太大是最常见的原因。我遇到过用英文校准集去量化中文模型结果中文任务精度直接崩了。校准集一定要贴近实际输入。第二检查敏感层。有些层对量化特别敏感比如第一层和最后一层。可以对这些层保留高精度做混合精度量化。第三检查量化配置。有些框架默认对某些算子不做量化如果你强行量化可能出问题。查文档确认哪些算子支持低精度。第四考虑 QAT。如果 PTQ训练后量化怎么调都不行就上 QAT。虽然麻烦但效果通常最好。5.2 推理速度没提升甚至变慢量化了但速度没变快甚至更慢这个坑我也踩过。原因通常有几个一是硬件不支持低精度加速。老卡跑 INT8 可能走的是模拟路径反而更慢。查清楚硬件的算力特性。二是算子 fallback。某些算子没有低精度实现框架自动回退到高精度导致混合执行反而增加开销。用 profiling 工具看哪些算子走了 fallback。三是 batch size 太小。低精度的优势在大 batch 下更明显如果 batch size 是 1可能看不出差别。适当增大 batch size 再测。四是内存带宽瓶颈。如果模型本身是 memory-bound量化减少的内存访问可能被其他开销抵消。这种情况要结合算子融合一起优化。5.3 剪枝后模型输出异常剪枝后输出异常通常是剪太狠了。排查步骤先看剪枝比例是不是超过了临界点。回退到上一个安全的比例确认模型正常。再看是不是某些关键层被剪了。比如 attention 的 output projection 层剪了很容易崩。检查剪枝配置对关键层跳过。最后看微调是否充分。剪枝后没微调或者微调不够模型可能处于“半残”状态。增加微调 epoch 或者调整学习率再试。5.4 常见问题速查表问题现象可能原因排查方向解决手段量化后精度暴跌校准集不匹配对比校准集与真实数据分布更换校准集量化后精度暴跌敏感层被量化逐层评估敏感度混合精度速度没提升硬件不支持查硬件算力特性换精度或换硬件速度没提升算子 fallbackprofiling 看算子执行排除不支持算子剪枝后输出异常剪枝过度回退剪枝比例降低剪枝率剪枝后输出异常关键层被剪检查剪枝配置跳过关键层微调不收敛学习率太大监控 loss 曲线降低学习率微调过拟合数据太少看验证集指标增加数据或早停5.5 几个容易被忽略的实操心得第一个心得是优化前先做 profiling。很多人一上来就量化结果发现瓶颈根本不在计算而在数据加载或者后处理。先 profiling找到真正的瓶颈再针对性优化。第二个心得是保留完整的实验记录。每次优化的配置、精度、性能数据都记下来。我吃过亏调了一个参数效果很好但忘了记后来怎么都复现不出来。第三个心得是不要迷信理论收益。理论上的加速比和实际差距可能很大一切以实测为准。我见过理论 4 倍加速实际只有 1.2 倍的案例。第四个心得是优化是迭代过程。不要指望一次搞定通常是量化→评估→调优→再评估反复几轮才能达到理想效果。耐心很重要。6. 优化效果的持续监控与迭代模型优化不是一次性的工作。上线之后随着数据分布变化、业务需求调整原本的优化配置可能不再最优。我一般会建立一套监控机制持续跟踪几个关键指标推理延迟的 P99、显存占用、以及业务指标的变化。如果发现延迟上升或者精度下降就要考虑重新优化。重新优化时之前的实验记录就派上用场了可以快速定位到哪个环节需要调整。另外硬件升级或者框架版本更新后也建议重新评估优化配置。新硬件可能支持更激进的量化新框架可能提供了更好的融合策略。我遇到过框架升级后同样的 INT8 配置速度提升了 20% 的情况。提示优化配置最好做成可切换的比如通过配置文件控制精度和剪枝比例。这样出问题时可以快速回退不用重新部署。最后分享一个小技巧如果你的团队有多个人在做优化建议统一评估流程和测试集。否则每个人的数据不可比讨论起来就是鸡同鸭讲。我们后来固定了一套评估脚本任何人优化完都跑同一套测试数据直接进表格对比效率高很多。这个方向后续还可以往自动化调优走比如用搜索算法自动找最优的量化配置和剪枝比例。不过这需要一定的工程投入小团队可以先从手动迭代开始等流程跑顺了再考虑自动化。
模型优化器实战：量化与剪枝加速推理部署
1. 模型优化器到底在优化什么第一次看到 Model-Optimizer 这个词很多人会下意识以为它又是一个“调参神器”或者“自动炼丹炉”。我刚开始接触的时候也这么想后来踩了几次坑才明白它本质上是一套围绕模型推理与训练效率做系统性压缩和加速的工具链思路。你可以把它理解成给模型做“瘦身提速”的整套方案而不是单一某个函数。模型优化器要解决的核心问题很朴素模型太大、跑得太慢、显存吃得太狠。一个在实验室里跑得好好的模型一旦要部署到实际业务里马上就会遇到延迟高、成本高、并发上不去的问题。Model-Optimizer 这类工具的价值就是把这些“落地最后一公里”的问题系统化地处理掉。它适合谁如果你是把模型从 notebook 推向生产环境的工程师或者是需要在有限硬件上跑更大模型的开发者再或者你只是想让自己的推理服务响应更快一点那这套东西都值得花时间研究。哪怕你只是做实验理解优化器的原理也能帮你少走很多弯路。我个人的判断是模型优化不是“锦上添花”而是“雪中送炭”。当你的服务 QPS 上不去、GPU 利用率只有 30% 的时候优化带来的收益往往比换更贵的卡更直接。下面我就按自己的实操经验把 Model-Optimizer 这套东西拆开讲清楚。2. 模型优化的整体思路与方案选型2.1 为什么优化要从“量化”和“剪枝”两条主线入手模型优化的手段很多但真正在生产里被反复验证、性价比最高的主要就是两条主线量化Quantization和剪枝Pruning再加上一个经常被忽略但极其关键的算子融合Operator Fusion。量化是把模型权重和激活值从高精度比如 FP32降到低精度比如 FP16、INT8 甚至 INT4。它的逻辑很直接模型里大量参数其实不需要那么高的精度用低精度表示几乎不影响效果但显存占用和计算量能大幅下降。我实测过一个 7B 级别的模型从 FP16 量化到 INT8显存占用直接砍掉接近一半推理速度提升 30% 以上而效果下降在可接受范围内。剪枝则是把模型里“贡献很小”的权重或结构去掉。它比量化更激进因为一旦剪错模型可能直接“变傻”。所以剪枝通常需要配合微调fine-tuning来恢复精度。我一般建议新手先从量化入手剪枝放到后面再碰。算子融合是很多人忽略的一环。它不改变模型结构而是把多个连续的小算子合并成一个减少 kernel 启动开销和内存读写。这个优化在推理框架里通常是自动做的但你需要知道它的存在才能理解为什么同样的模型在不同框架下速度差那么多。2.2 方案选型的三个关键判断维度选优化方案不能拍脑袋我一般看三个维度精度容忍度、硬件支持、工程成本。精度容忍度决定了你能压到多低。如果你的业务对输出质量极其敏感比如医疗、金融场景那 INT8 可能就是底线INT4 要非常谨慎。如果只是做内容生成、推荐排序那 INT4 甚至更激进的方案都可以试。硬件支持是硬约束。不是所有显卡都支持 INT8 或 INT4 的加速指令。比如一些老卡对低精度支持很差你量化了反而更慢。所以动手前一定要查清楚目标硬件的算力特性。工程成本包括改造成本和维护成本。有些优化方案需要你改推理代码、重新导出模型、甚至重写部分算子。如果团队人手有限优先选那些“改一行配置就能生效”的方案。提示不要一上来就追求极致压缩。先跑通一个 baseline再逐步加优化每次只改一个变量这样出问题才知道是哪一步导致的。2.3 优化顺序的实操建议我踩过的最大坑就是“一次性全上”。量化、剪枝、融合一起搞结果精度崩了根本不知道是谁的锅。后来我固定了一套顺序先做算子融合通常无损再做量化FP16 → INT8 逐步来最后才考虑剪枝。每一步都做精度对比和性能测试确认没问题再进下一步。这个顺序的好处是风险可控。算子融合基本无损量化损失可量化剪枝风险最高放最后。这样即使剪枝出问题前面的收益也已经拿到了。3. 量化实操从 FP16 到 INT8 的完整流程3.1 量化前的准备工作动手量化之前有几件事必须先做。第一是确定评估指标。不能只看 loss要看业务相关的指标比如生成任务的 BLEU、分类任务的准确率、排序任务的 AUC。我一般会准备一个固定的小测试集每次优化后都跑一遍确保对比公平。第二是备份原始模型。量化过程可能不可逆尤其是动态量化一旦转换失败或者效果崩了你得能回到原点。我习惯把原始权重、配置文件、导出脚本全部打包存档。第三是确认推理框架。不同框架对量化的支持差异很大。有的框架只支持静态量化有的支持动态量化有的对某些算子根本不支持低精度。你需要提前查文档避免做到一半发现走不通。3.2 静态量化与动态量化的选择静态量化和动态量化的区别简单说就是“提前算好缩放因子”还是“运行时算”。静态量化需要在校准集上跑一遍统计激活值的分布提前确定量化参数。它的优点是推理时速度快因为缩放因子是固定的。缺点是校准集选不好会影响精度而且对输入分布变化敏感。动态量化则是运行时根据实际输入计算缩放因子。它更灵活对输入变化鲁棒但推理时多了一步计算速度略慢。我一般建议如果输入分布稳定比如固定格式的文本分类用静态量化如果输入变化大比如开放域对话用动态量化更稳。# 静态量化的大致流程示意 # 1. 准备校准数据 calibration_data load_calibration_dataset() # 2. 配置量化方案 quant_config { weight_dtype: int8, activation_dtype: int8, calibration_samples: 128 } # 3. 执行量化 quantized_model quantize_model( original_model, configquant_config, calibration_datacalibration_data ) # 4. 评估精度 evaluate(quantized_model, test_dataset)3.3 量化精度的评估与调优量化后精度下降是常态关键是把下降控制在可接受范围。我一般会看三个指标绝对精度下降、相对精度下降、以及最差样本的表现。绝对精度下降是看整体指标掉了多少比如准确率从 95% 掉到 93%那就是掉了 2 个点。相对精度下降是看掉了百分之多少2/95 大概是 2.1%。最差样本的表现最容易被忽略但很重要——有时候整体指标没怎么掉但某些特定输入的结果完全崩了这种问题在实际业务里是致命的。如果精度下降太多可以尝试几个调优手段。一是混合精度对敏感层保留高精度其他层用低精度。二是调整校准集让校准数据更贴近真实分布。三是量化感知训练QAT在训练阶段就模拟量化误差让模型提前适应。注意混合精度虽然能救精度但会削弱加速效果。我一般只在关键层用比如 attention 的输出层其他层还是保持低精度。3.4 量化后的性能实测量化完一定要实测性能不能只看理论收益。我实测过一个模型理论上 INT8 应该比 FP16 快一倍但实际只快了 40%。原因是某些算子没有低精度加速支持反而走了 fallback 路径。实测时我一般关注三个数据首 token 延迟、吞吐量tokens/s、显存峰值。首 token 延迟影响用户体验吞吐量影响成本显存峰值决定你能跑多大 batch。这三个数据要一起看不能只盯一个。精度显存峰值吞吐量首 token 延迟FP3224GB120 tokens/s350msFP1613GB210 tokens/s220msINT87GB290 tokens/s180msINT44GB340 tokens/s165ms上面这组数据是我在某次实测中记录的可以看到 INT4 的收益已经明显递减了但显存占用还在降。所以如果你的瓶颈是显存INT4 值得试如果瓶颈是速度INT8 性价比最高。4. 剪枝与算子融合的实操细节4.1 结构化剪枝与非结构化剪枝的区别剪枝分两种结构化剪枝和非结构化剪枝。非结构化剪枝是把单个权重置零模型结构不变但权重矩阵变得稀疏。它的优点是精度损失小缺点是通用硬件对稀疏矩阵的加速支持有限实际提速可能不明显。结构化剪枝是直接去掉整个通道、整个头或者整个层。它的优点是模型结构真的变小了推理速度提升明显。缺点是精度损失大通常需要微调恢复。我一般建议如果目标硬件支持稀疏加速比如某些专用芯片可以试非结构化剪枝如果是通用 GPU优先结构化剪枝因为提速更实在。4.2 剪枝比例怎么定剪枝比例是最难调的参数。剪太少没效果剪太多模型崩。我的经验是从小比例开始比如先剪 10%评估精度再逐步加到 20%、30%。每次加完都重新评估找到精度开始明显下降的临界点然后回退一档。还有一个技巧是分层剪枝。不同层对剪枝的敏感度不一样通常 attention 层比 FFN 层更敏感浅层比深层更敏感。所以可以对敏感层少剪对不敏感层多剪。这个需要做一些实验来确定每层的敏感度。# 分层剪枝比例配置示意 pruning_config { layer_0_attention: 0.05, # 浅层 attention 少剪 layer_0_ffn: 0.15, layer_1_attention: 0.08, layer_1_ffn: 0.20, layer_2_attention: 0.10, layer_2_ffn: 0.25, # 深层可以剪得更激进 }4.3 算子融合的实际效果算子融合通常由推理框架自动完成但你需要知道它做了什么才能判断性能瓶颈在哪。常见的融合包括ConvBNReLU 融合成一个算子、LayerNorm 融合、以及 attention 里的 QKV 计算融合。我实测过光是 attention 里的算子融合就能带来 15% 到 25% 的提速。这个收益是“白捡”的因为不损失精度。所以选推理框架时一定要看它的融合能力。提示如果你的框架不支持自动融合可以手动用图优化工具做。但手动融合容易出错建议先用小模型验证确认输出一致再上大模型。4.4 剪枝后的微调策略剪枝后微调是恢复精度的关键。我一般用较小的学习率比如原始学习率的 1/10跑 1 到 3 个 epoch。数据用原始训练集的子集就行不需要全量。微调时要注意冻结策略。我通常冻结没被剪的层只训练被剪的层和最后的输出层。这样收敛快也不容易破坏原有能力。如果精度恢复不理想再逐步解冻更多层。还有一个坑是过拟合。剪枝后模型容量变小如果微调数据太少或者跑太多 epoch很容易过拟合。我一般会在验证集上监控一旦指标不再提升就停。5. 常见问题与排查技巧实录5.1 量化后精度暴跌怎么办精度暴跌是最常见的问题。排查思路我一般按这个顺序走第一检查校准集。校准集和真实数据分布差异太大是最常见的原因。我遇到过用英文校准集去量化中文模型结果中文任务精度直接崩了。校准集一定要贴近实际输入。第二检查敏感层。有些层对量化特别敏感比如第一层和最后一层。可以对这些层保留高精度做混合精度量化。第三检查量化配置。有些框架默认对某些算子不做量化如果你强行量化可能出问题。查文档确认哪些算子支持低精度。第四考虑 QAT。如果 PTQ训练后量化怎么调都不行就上 QAT。虽然麻烦但效果通常最好。5.2 推理速度没提升甚至变慢量化了但速度没变快甚至更慢这个坑我也踩过。原因通常有几个一是硬件不支持低精度加速。老卡跑 INT8 可能走的是模拟路径反而更慢。查清楚硬件的算力特性。二是算子 fallback。某些算子没有低精度实现框架自动回退到高精度导致混合执行反而增加开销。用 profiling 工具看哪些算子走了 fallback。三是 batch size 太小。低精度的优势在大 batch 下更明显如果 batch size 是 1可能看不出差别。适当增大 batch size 再测。四是内存带宽瓶颈。如果模型本身是 memory-bound量化减少的内存访问可能被其他开销抵消。这种情况要结合算子融合一起优化。5.3 剪枝后模型输出异常剪枝后输出异常通常是剪太狠了。排查步骤先看剪枝比例是不是超过了临界点。回退到上一个安全的比例确认模型正常。再看是不是某些关键层被剪了。比如 attention 的 output projection 层剪了很容易崩。检查剪枝配置对关键层跳过。最后看微调是否充分。剪枝后没微调或者微调不够模型可能处于“半残”状态。增加微调 epoch 或者调整学习率再试。5.4 常见问题速查表问题现象可能原因排查方向解决手段量化后精度暴跌校准集不匹配对比校准集与真实数据分布更换校准集量化后精度暴跌敏感层被量化逐层评估敏感度混合精度速度没提升硬件不支持查硬件算力特性换精度或换硬件速度没提升算子 fallbackprofiling 看算子执行排除不支持算子剪枝后输出异常剪枝过度回退剪枝比例降低剪枝率剪枝后输出异常关键层被剪检查剪枝配置跳过关键层微调不收敛学习率太大监控 loss 曲线降低学习率微调过拟合数据太少看验证集指标增加数据或早停5.5 几个容易被忽略的实操心得第一个心得是优化前先做 profiling。很多人一上来就量化结果发现瓶颈根本不在计算而在数据加载或者后处理。先 profiling找到真正的瓶颈再针对性优化。第二个心得是保留完整的实验记录。每次优化的配置、精度、性能数据都记下来。我吃过亏调了一个参数效果很好但忘了记后来怎么都复现不出来。第三个心得是不要迷信理论收益。理论上的加速比和实际差距可能很大一切以实测为准。我见过理论 4 倍加速实际只有 1.2 倍的案例。第四个心得是优化是迭代过程。不要指望一次搞定通常是量化→评估→调优→再评估反复几轮才能达到理想效果。耐心很重要。6. 优化效果的持续监控与迭代模型优化不是一次性的工作。上线之后随着数据分布变化、业务需求调整原本的优化配置可能不再最优。我一般会建立一套监控机制持续跟踪几个关键指标推理延迟的 P99、显存占用、以及业务指标的变化。如果发现延迟上升或者精度下降就要考虑重新优化。重新优化时之前的实验记录就派上用场了可以快速定位到哪个环节需要调整。另外硬件升级或者框架版本更新后也建议重新评估优化配置。新硬件可能支持更激进的量化新框架可能提供了更好的融合策略。我遇到过框架升级后同样的 INT8 配置速度提升了 20% 的情况。提示优化配置最好做成可切换的比如通过配置文件控制精度和剪枝比例。这样出问题时可以快速回退不用重新部署。最后分享一个小技巧如果你的团队有多个人在做优化建议统一评估流程和测试集。否则每个人的数据不可比讨论起来就是鸡同鸭讲。我们后来固定了一套评估脚本任何人优化完都跑同一套测试数据直接进表格对比效率高很多。这个方向后续还可以往自动化调优走比如用搜索算法自动找最优的量化配置和剪枝比例。不过这需要一定的工程投入小团队可以先从手动迭代开始等流程跑顺了再考虑自动化。
