1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的项目里。当时线上推理服务用的是 BERT-base单次请求延迟在 180ms 左右QPS 一上去 GPU 显存就爆运维天天在群里艾特我。那会儿我的第一反应是加机器但算了一笔账单卡 T4 按量付费一个月下来成本接近四位数扩到四张卡就是四倍开销老板肯定不批。于是我开始认真研究模型优化这条路从量化、剪枝、蒸馏一路摸到算子融合和显存复用最后把延迟压到了 45ms显存占用降到原来的三分之一机器没加一台。Model-Optimizer 这个词说白了就是一整套让模型跑得更快、更小、更省资源的工具链和方法论。它不是某一个具体的库而是一个工程方向把训练好的模型通过一系列变换变成在目标硬件上推理效率更高的版本同时尽量不损失精度。它解决的问题非常具体——模型太大装不下、推理太慢扛不住并发、功耗太高边缘设备跑不动、成本太贵预算撑不住。适合看这篇内容的人我大致分三类。第一类是算法工程师模型训完了要交付发现部署环节一堆坑第二类是后端或推理服务开发接手别人的模型要做服务化被延迟和显存折磨第三类是边缘端开发者手机、嵌入式设备上跑模型资源和功耗卡得死死的。不管你是哪一类只要你的模型能跑但跑不好Model-Optimizer 这套东西就值得花时间啃。我下面会按照我自己踩坑的顺序把整个优化链路拆开讲先讲整体设计思路和方案选型再讲每个环节的核心细节和实操要点然后是完整的落地流程和参数计算最后是我遇到过的典型问题和排查方法。内容偏工程实战理论点到为止重点放在怎么做和为什么这么做。2. 整体优化思路与方案选型拆解2.1 优化的四个方向与优先级判断模型优化不是一上来就堆工具得先想清楚瓶颈在哪。我一般把优化方向分成四类按投入产出比排序量化把 FP32 权重和激活降到 FP16、INT8 甚至 INT4显存和带宽直接砍半甚至砍到四分之一速度提升最明显改动最小通常是我的第一选择。剪枝去掉冗余的权重或通道减少计算量。结构化剪枝对硬件友好非结构化剪枝理论收益高但实际加速有限。知识蒸馏用大模型教小模型换一个更小的架构。适合对延迟极度敏感、能接受重新训练的场景。图优化与算子融合把多个算子合并成一个减少 kernel launch 开销和中间张量的显存读写。这个往往和推理引擎绑定比如 TensorRT、ONNX Runtime 都自带。优先级怎么定我的经验是先量化再图优化然后剪枝最后才考虑蒸馏。原因是量化改动最小、见效最快图优化基本是白捡的收益剪枝需要重新微调蒸馏等于重训一遍成本最高。除非你的模型架构本身就不适合量化比如某些对数值精度极度敏感的检测头否则量化永远是第一步。2.2 为什么量化是性价比最高的起点量化的本质是用更低的数值精度表示原本的浮点数。FP32 是 32 位FP16 是 16 位INT8 是 8 位。位数越少显存占用越小内存带宽压力越小而现代 GPU 对低精度计算有专门的加速单元比如 Tensor Core 对 FP16 和 INT8 的吞吐远高于 FP32。我拿一个具体的例子算给你看。假设一个模型有 1.1 亿参数BERT-base 量级FP32 存储需要 1.1亿 × 4字节 ≈ 440MBFP16 只要 220MBINT8 只要 110MB。这还只是权重激活值、中间张量同样按比例缩减。显存占用降下来batch size 就能开大吞吐自然上去。但量化不是没有代价。FP16 基本无损精度掉个千分之一都算多的INT8 就需要校准calibration用一批代表性数据统计激活值的动态范围把浮点映射到整数区间。如果校准数据分布和线上真实分布差太多精度会明显下降。我见过最夸张的案例校准用了干净的文档数据线上是带大量噪声的用户输入INT8 之后准确率掉了 8 个点最后只能回退到 FP16。提示量化前一定要确认目标硬件支持哪些精度。老一些的 GPU 对 INT8 支持不完整强行上反而更慢。查清楚硬件的算力特性和推理引擎的支持矩阵再决定量化到什么精度。2.3 方案选型的三个约束条件选优化方案的时候我一般看三个约束精度容忍度、硬件能力、工程成本。精度容忍度取决于业务。搜索排序掉 0.5 个点可能无所谓医疗影像分割掉 0.5 个点可能就是事故。这个必须和业务方对齐不能自己拍脑袋。硬件能力决定了你能用什么手段。支持 Tensor Core 的卡FP16 和 INT8 都能吃到红利只有普通 CUDA 核心的卡量化收益就打折扣。边缘设备更复杂有些 NPU 只支持特定量化方案你得按它的要求来。工程成本包括改造成本和维护成本。引入 TensorRT 意味着多一套构建流程模型更新要重新编译 engine用 ONNX Runtime 相对轻量但某些自定义算子可能不支持。这些都要提前评估别做到一半发现走不通。3. 核心细节解析与实操要点3.1 量化实操从 FP32 到 INT8 的完整链路量化分两种训练后量化PTQ和量化感知训练QAT。PTQ 不需要重新训练拿训练好的模型直接转快但精度损失相对大QAT 在训练时模拟量化误差精度更好但需要重训。我的建议是先用 PTQ 试精度不达标再上 QAT。PTQ 的流程大致是这样准备校准数据集一般 100 到 500 个样本就够要覆盖线上真实分布。把模型转成支持量化的格式比如 ONNX。用校准数据跑一遍统计每层激活值的动态范围。生成量化模型验证精度。校准数据集的选择是重中之重。我一般从线上日志里采样确保覆盖各种输入长度、各种边界情况。如果线上有长尾分布校准集里也要有。曾经有个项目校准集全是短文本结果线上长文本一进来激活值超出量化范围输出直接乱掉。# 以 ONNX Runtime 的静态量化为例核心是配置校准数据读取器 from onnxruntime.quantization import quantize_static, CalibrationDataReader class MyCalibReader(CalibrationDataReader): def __init__(self, data): self.data iter(data) def get_next(self): return next(self.data, None) quantize_static( model_inputmodel.onnx, model_outputmodel_int8.onnx, calibration_data_readerMyCalibReader(calib_samples), quant_formatQuantFormat.QDQ, # QDQ 格式对多数推理引擎更友好 per_channelTrue, # 逐通道量化精度更好 activation_typeQuantType.QUInt8, weight_typeQuantType.QInt8, )per_channelTrue这个参数很关键。逐张量量化是整个权重矩阵共用一个缩放因子逐通道量化是每个输出通道一个后者精度明显更好代价是稍微多一点存储。实测下来逐通道量化通常能比逐张量多保住 1 到 2 个点的精度。3.2 剪枝的坑结构化与非结构化的取舍剪枝听起来很美去掉不重要的权重模型变小变快。但实际操作里非结构化剪枝随便挑权重置零在通用硬件上几乎不会加速因为 GPU 是按稠密矩阵算的你置零了它照样算只是结果乘了个零。真正能加速的是结构化剪枝整行整列或整个通道去掉矩阵维度真的变小。结构化剪枝的流程训练一个基准模型。评估每个通道的重要性常用 L1/L2 范数或者 BN 层的缩放因子。按重要性排序去掉最不重要的那部分通道。微调恢复精度。重复 2 到 4逐步剪到目标比例。这里有个经验一次别剪太狠。我试过一次剪掉 50% 的通道精度直接崩了微调也救不回来。后来改成每次剪 10% 到 20%剪完微调几个 epoch迭代几轮最终能剪到 40% 到 50% 还保持精度。渐进式剪枝比一次性剪枝稳得多。注意剪枝后一定要重新评估模型的实际推理速度不能只看参数量。有些剪枝方案参数量降了但因为破坏了内存对齐或者引入了不规则计算实际速度反而更慢。参数量不等于延迟这个坑我踩过不止一次。3.3 图优化与算子融合白捡的收益图优化是推理引擎自动做的你基本不用写代码但得知道它在干什么才能判断收益从哪来。常见的融合有几种Conv BN ReLU 融合把卷积、批归一化、激活合并成一个算子减少两次中间张量的读写。矩阵乘 加偏置融合GEMM 和 bias add 合并。多头注意力的 QKV 投影融合把三个线性层合并成一个大矩阵乘。这些融合减少的是 kernel launch 开销和显存带宽占用。在 GPU 上kernel launch 本身有固定开销算子越多开销越大中间张量写回显存再读出来带宽是瓶颈。融合之后数据在寄存器或共享内存里就完成了多步计算省下大量带宽。用 TensorRT 的话这些融合基本是自动的你只要把 ONNX 喂进去它自己会做。ONNX Runtime 也有图优化级别可以调ORT_ENABLE_ALL会开启所有优化。实测下来光图优化这一项在 Transformer 类模型上通常能带来 10% 到 30% 的加速而且精度零损失。3.4 显存优化的几个实用技巧除了量化显存还有几个优化点容易被忽略KV Cache 优化。自回归生成模型里KV Cache 占的显存随序列长度线性增长。可以用 PagedAttention 这类技术把 KV Cache 分页管理减少碎片提升显存利用率。梯度检查点。这个是训练时的技巧用计算换显存把中间激活值不存反向传播时重算。推理时用不上但如果你在做微调这个能让你在同样的卡上开更大的 batch。动态 batch 与序列长度分桶。把长度相近的请求分到一批减少 padding 浪费。这个在 NLP 服务里效果特别明显我做过一个项目分桶之后有效吞吐提升了 40%。4. 完整实操流程与参数计算4.1 一个真实项目的优化全流程我拿之前那个推荐系统的 BERT-base 项目举例把完整流程走一遍。第一步建立基准。优化前先测准基线不然你不知道优化有没有效果。测三个指标延迟P50、P99、吞吐QPS、显存占用。测试要用真实流量回放或者接近真实的压测数据别用几条样例糊弄。基线数据P50 延迟 180msP99 延迟 320msQPS 45显存占用 6.2GBbatch size 8。第二步FP16 量化。这一步最简单PyTorch 里model.half()就行或者导出 ONNX 时指定 FP16。精度基本无损显存直接减半。FP16 后P50 延迟 110msQPS 78显存 3.4GB。延迟降了 39%吞吐涨了 73%。第三步图优化。转成 TensorRT engine开启 FP16 和算子融合。TensorRT 后P50 延迟 72msQPS 120显存 3.1GB。又降了 35%。第四步INT8 量化。用校准数据做 PTQ逐通道量化。INT8 后P50 延迟 45msQPS 190显存 1.9GB。精度掉了 0.3 个点业务方接受。第五步动态 batch 与分桶。把请求按序列长度分桶减少 padding。最终P50 延迟 45msQPS 260显存 1.9GB。相比基线延迟降到四分之一吞吐涨了近 6 倍机器一台没加。4.2 量化参数的计算过程INT8 量化的核心是确定缩放因子scale和零点zero point。公式是real_value scale × (quantized_value - zero_point)对于对称量化zero_point 为 0scale max(abs(real_value)) / 127。对于非对称量化scale (max - min) / 255zero_point round(-min / scale)。假设某层激活值的范围是 [-2.5, 3.8]非对称量化scale (3.8 - (-2.5)) / 255 6.3 / 255 ≈ 0.0247zero_point round(-(-2.5) / 0.0247) round(101.2) 101这样 -2.5 映射到 03.8 映射到 255中间值线性映射。校准的过程就是统计每层的 min 和 max但直接用全局 min/max 容易被离群值带偏所以常用移动平均或者百分位裁剪比如取 99.9% 分位数来估计范围。我一般用百分位裁剪把极端离群值排除掉量化范围更紧凑精度更好。代价是超出范围的激活值会被截断但这种情况很少影响可控。4.3 精度验证的完整方法优化完不能只看速度精度必须验证。我的验证流程分三层第一层单元测试。拿一批固定输入对比优化前后输出的差异。用余弦相似度或者最大绝对误差衡量。一般 FP16 的余弦相似度在 0.9999 以上INT8 在 0.99 以上算正常。第二层离线评估。在完整的验证集上跑一遍看业务指标掉了多少。这一步要和业务方一起定阈值掉多少可以接受。第三层在线灰度。小流量上线对比优化前后的线上指标。这一步最关键因为离线数据和线上分布总有差异。灰度期间要盯紧一旦指标异常立刻回滚。提示三层验证缺一不可。我见过离线指标正常、线上一塌糊涂的案例就是因为线上有离线没覆盖的输入模式。灰度是最后一道防线千万别省。5. 常见问题与排查技巧实录5.1 量化后精度暴跌怎么排查精度暴跌是最常见的问题排查思路按这个顺序走排查项检查方法常见原因校准数据对比校准集与线上分布分布不匹配长尾未覆盖量化范围打印每层 min/max离群值拉大范围有效精度降低敏感层逐层回退到 FP16某些层对量化敏感算子支持检查是否有算子回退到 FP32混合精度导致精度异常我的经验是先查校准数据。八成的问题出在这里。校准集要覆盖线上各种输入长度、领域、噪声水平都要接近。如果线上有用户生成的乱码、超长文本校准集里也得有。如果校准数据没问题就查敏感层。Transformer 里LayerNorm 和 softmax 附近的层通常对量化敏感可以单独保留 FP16。这种混合精度方案能救回大部分精度。5.2 优化后速度没提升甚至变慢这种情况一般是几个原因算子回退。某些算子在目标推理引擎里没有低精度实现自动回退到 FP32导致混合精度反而更慢。用 profiling 工具看每个算子的实际精度和耗时找出回退的算子。内存对齐问题。剪枝或量化后张量维度不再是 8 或 16 的倍数GPU 的内存访问效率下降。解决办法是把维度 padding 到对齐的倍数。kernel launch 开销。模型被切得太碎算子数量多launch 开销占比高。这时候图优化的融合就很重要。数据传输瓶颈。如果模型在 GPU 上但数据在 CPUPCIe 传输成了瓶颈。用 pinned memory 和异步传输能缓解。我一般用 Nsight Systems 或者 PyTorch Profiler 做 profiling看时间花在哪。是计算、是内存、还是传输一目了然。5.3 显存碎片与 OOM 问题显存 OOM 不一定是显存不够可能是碎片。PyTorch 的缓存分配器会预留显存长时间运行后碎片化严重。解决办法设置PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True用可扩展段减少碎片。定期重启服务或者用显存池管理。推理时用torch.no_grad()避免保存计算图。还有一个容易忽略的点模型加载时的峰值显存。加载大模型时如果先加载到 CPU 再搬到 GPU峰值是两份。用device_map或者分片加载能降低峰值。5.4 独家避坑清单最后整理一份我踩过的坑都是文档里不会写的量化前先备份原始模型。量化不可逆出问题要能回退。校准数据要固定随机种子。不然每次校准结果不一样没法复现。TensorRT engine 和硬件绑定。换卡要重新编译别指望跨卡通用。INT8 不一定比 FP16 快。小模型上 INT8 的反量化开销可能抵消收益实测为准。剪枝后要重新测延迟。参数量降了不代表速度快了。灰度期间监控要加精度指标。光看延迟和 QPS 不够业务指标才是根本。优化是迭代的。一次优化到位很难多轮小步快跑比一次大改稳。我个人在实际操作中的体会是模型优化这件事七分靠测量三分靠技术。你得先知道瓶颈在哪再选对应的手段。盲目上工具往往是花了大力气收益却不成正比。每次优化前后都要有数据对比用数据说话别凭感觉。这套方法我在好几个项目里复用基本都能把推理成本压到原来的三分之一到五分之一效果稳定。
Model-Optimizer实战：量化剪枝与图优化加速推理
1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的项目里。当时线上推理服务用的是 BERT-base单次请求延迟在 180ms 左右QPS 一上去 GPU 显存就爆运维天天在群里艾特我。那会儿我的第一反应是加机器但算了一笔账单卡 T4 按量付费一个月下来成本接近四位数扩到四张卡就是四倍开销老板肯定不批。于是我开始认真研究模型优化这条路从量化、剪枝、蒸馏一路摸到算子融合和显存复用最后把延迟压到了 45ms显存占用降到原来的三分之一机器没加一台。Model-Optimizer 这个词说白了就是一整套让模型跑得更快、更小、更省资源的工具链和方法论。它不是某一个具体的库而是一个工程方向把训练好的模型通过一系列变换变成在目标硬件上推理效率更高的版本同时尽量不损失精度。它解决的问题非常具体——模型太大装不下、推理太慢扛不住并发、功耗太高边缘设备跑不动、成本太贵预算撑不住。适合看这篇内容的人我大致分三类。第一类是算法工程师模型训完了要交付发现部署环节一堆坑第二类是后端或推理服务开发接手别人的模型要做服务化被延迟和显存折磨第三类是边缘端开发者手机、嵌入式设备上跑模型资源和功耗卡得死死的。不管你是哪一类只要你的模型能跑但跑不好Model-Optimizer 这套东西就值得花时间啃。我下面会按照我自己踩坑的顺序把整个优化链路拆开讲先讲整体设计思路和方案选型再讲每个环节的核心细节和实操要点然后是完整的落地流程和参数计算最后是我遇到过的典型问题和排查方法。内容偏工程实战理论点到为止重点放在怎么做和为什么这么做。2. 整体优化思路与方案选型拆解2.1 优化的四个方向与优先级判断模型优化不是一上来就堆工具得先想清楚瓶颈在哪。我一般把优化方向分成四类按投入产出比排序量化把 FP32 权重和激活降到 FP16、INT8 甚至 INT4显存和带宽直接砍半甚至砍到四分之一速度提升最明显改动最小通常是我的第一选择。剪枝去掉冗余的权重或通道减少计算量。结构化剪枝对硬件友好非结构化剪枝理论收益高但实际加速有限。知识蒸馏用大模型教小模型换一个更小的架构。适合对延迟极度敏感、能接受重新训练的场景。图优化与算子融合把多个算子合并成一个减少 kernel launch 开销和中间张量的显存读写。这个往往和推理引擎绑定比如 TensorRT、ONNX Runtime 都自带。优先级怎么定我的经验是先量化再图优化然后剪枝最后才考虑蒸馏。原因是量化改动最小、见效最快图优化基本是白捡的收益剪枝需要重新微调蒸馏等于重训一遍成本最高。除非你的模型架构本身就不适合量化比如某些对数值精度极度敏感的检测头否则量化永远是第一步。2.2 为什么量化是性价比最高的起点量化的本质是用更低的数值精度表示原本的浮点数。FP32 是 32 位FP16 是 16 位INT8 是 8 位。位数越少显存占用越小内存带宽压力越小而现代 GPU 对低精度计算有专门的加速单元比如 Tensor Core 对 FP16 和 INT8 的吞吐远高于 FP32。我拿一个具体的例子算给你看。假设一个模型有 1.1 亿参数BERT-base 量级FP32 存储需要 1.1亿 × 4字节 ≈ 440MBFP16 只要 220MBINT8 只要 110MB。这还只是权重激活值、中间张量同样按比例缩减。显存占用降下来batch size 就能开大吞吐自然上去。但量化不是没有代价。FP16 基本无损精度掉个千分之一都算多的INT8 就需要校准calibration用一批代表性数据统计激活值的动态范围把浮点映射到整数区间。如果校准数据分布和线上真实分布差太多精度会明显下降。我见过最夸张的案例校准用了干净的文档数据线上是带大量噪声的用户输入INT8 之后准确率掉了 8 个点最后只能回退到 FP16。提示量化前一定要确认目标硬件支持哪些精度。老一些的 GPU 对 INT8 支持不完整强行上反而更慢。查清楚硬件的算力特性和推理引擎的支持矩阵再决定量化到什么精度。2.3 方案选型的三个约束条件选优化方案的时候我一般看三个约束精度容忍度、硬件能力、工程成本。精度容忍度取决于业务。搜索排序掉 0.5 个点可能无所谓医疗影像分割掉 0.5 个点可能就是事故。这个必须和业务方对齐不能自己拍脑袋。硬件能力决定了你能用什么手段。支持 Tensor Core 的卡FP16 和 INT8 都能吃到红利只有普通 CUDA 核心的卡量化收益就打折扣。边缘设备更复杂有些 NPU 只支持特定量化方案你得按它的要求来。工程成本包括改造成本和维护成本。引入 TensorRT 意味着多一套构建流程模型更新要重新编译 engine用 ONNX Runtime 相对轻量但某些自定义算子可能不支持。这些都要提前评估别做到一半发现走不通。3. 核心细节解析与实操要点3.1 量化实操从 FP32 到 INT8 的完整链路量化分两种训练后量化PTQ和量化感知训练QAT。PTQ 不需要重新训练拿训练好的模型直接转快但精度损失相对大QAT 在训练时模拟量化误差精度更好但需要重训。我的建议是先用 PTQ 试精度不达标再上 QAT。PTQ 的流程大致是这样准备校准数据集一般 100 到 500 个样本就够要覆盖线上真实分布。把模型转成支持量化的格式比如 ONNX。用校准数据跑一遍统计每层激活值的动态范围。生成量化模型验证精度。校准数据集的选择是重中之重。我一般从线上日志里采样确保覆盖各种输入长度、各种边界情况。如果线上有长尾分布校准集里也要有。曾经有个项目校准集全是短文本结果线上长文本一进来激活值超出量化范围输出直接乱掉。# 以 ONNX Runtime 的静态量化为例核心是配置校准数据读取器 from onnxruntime.quantization import quantize_static, CalibrationDataReader class MyCalibReader(CalibrationDataReader): def __init__(self, data): self.data iter(data) def get_next(self): return next(self.data, None) quantize_static( model_inputmodel.onnx, model_outputmodel_int8.onnx, calibration_data_readerMyCalibReader(calib_samples), quant_formatQuantFormat.QDQ, # QDQ 格式对多数推理引擎更友好 per_channelTrue, # 逐通道量化精度更好 activation_typeQuantType.QUInt8, weight_typeQuantType.QInt8, )per_channelTrue这个参数很关键。逐张量量化是整个权重矩阵共用一个缩放因子逐通道量化是每个输出通道一个后者精度明显更好代价是稍微多一点存储。实测下来逐通道量化通常能比逐张量多保住 1 到 2 个点的精度。3.2 剪枝的坑结构化与非结构化的取舍剪枝听起来很美去掉不重要的权重模型变小变快。但实际操作里非结构化剪枝随便挑权重置零在通用硬件上几乎不会加速因为 GPU 是按稠密矩阵算的你置零了它照样算只是结果乘了个零。真正能加速的是结构化剪枝整行整列或整个通道去掉矩阵维度真的变小。结构化剪枝的流程训练一个基准模型。评估每个通道的重要性常用 L1/L2 范数或者 BN 层的缩放因子。按重要性排序去掉最不重要的那部分通道。微调恢复精度。重复 2 到 4逐步剪到目标比例。这里有个经验一次别剪太狠。我试过一次剪掉 50% 的通道精度直接崩了微调也救不回来。后来改成每次剪 10% 到 20%剪完微调几个 epoch迭代几轮最终能剪到 40% 到 50% 还保持精度。渐进式剪枝比一次性剪枝稳得多。注意剪枝后一定要重新评估模型的实际推理速度不能只看参数量。有些剪枝方案参数量降了但因为破坏了内存对齐或者引入了不规则计算实际速度反而更慢。参数量不等于延迟这个坑我踩过不止一次。3.3 图优化与算子融合白捡的收益图优化是推理引擎自动做的你基本不用写代码但得知道它在干什么才能判断收益从哪来。常见的融合有几种Conv BN ReLU 融合把卷积、批归一化、激活合并成一个算子减少两次中间张量的读写。矩阵乘 加偏置融合GEMM 和 bias add 合并。多头注意力的 QKV 投影融合把三个线性层合并成一个大矩阵乘。这些融合减少的是 kernel launch 开销和显存带宽占用。在 GPU 上kernel launch 本身有固定开销算子越多开销越大中间张量写回显存再读出来带宽是瓶颈。融合之后数据在寄存器或共享内存里就完成了多步计算省下大量带宽。用 TensorRT 的话这些融合基本是自动的你只要把 ONNX 喂进去它自己会做。ONNX Runtime 也有图优化级别可以调ORT_ENABLE_ALL会开启所有优化。实测下来光图优化这一项在 Transformer 类模型上通常能带来 10% 到 30% 的加速而且精度零损失。3.4 显存优化的几个实用技巧除了量化显存还有几个优化点容易被忽略KV Cache 优化。自回归生成模型里KV Cache 占的显存随序列长度线性增长。可以用 PagedAttention 这类技术把 KV Cache 分页管理减少碎片提升显存利用率。梯度检查点。这个是训练时的技巧用计算换显存把中间激活值不存反向传播时重算。推理时用不上但如果你在做微调这个能让你在同样的卡上开更大的 batch。动态 batch 与序列长度分桶。把长度相近的请求分到一批减少 padding 浪费。这个在 NLP 服务里效果特别明显我做过一个项目分桶之后有效吞吐提升了 40%。4. 完整实操流程与参数计算4.1 一个真实项目的优化全流程我拿之前那个推荐系统的 BERT-base 项目举例把完整流程走一遍。第一步建立基准。优化前先测准基线不然你不知道优化有没有效果。测三个指标延迟P50、P99、吞吐QPS、显存占用。测试要用真实流量回放或者接近真实的压测数据别用几条样例糊弄。基线数据P50 延迟 180msP99 延迟 320msQPS 45显存占用 6.2GBbatch size 8。第二步FP16 量化。这一步最简单PyTorch 里model.half()就行或者导出 ONNX 时指定 FP16。精度基本无损显存直接减半。FP16 后P50 延迟 110msQPS 78显存 3.4GB。延迟降了 39%吞吐涨了 73%。第三步图优化。转成 TensorRT engine开启 FP16 和算子融合。TensorRT 后P50 延迟 72msQPS 120显存 3.1GB。又降了 35%。第四步INT8 量化。用校准数据做 PTQ逐通道量化。INT8 后P50 延迟 45msQPS 190显存 1.9GB。精度掉了 0.3 个点业务方接受。第五步动态 batch 与分桶。把请求按序列长度分桶减少 padding。最终P50 延迟 45msQPS 260显存 1.9GB。相比基线延迟降到四分之一吞吐涨了近 6 倍机器一台没加。4.2 量化参数的计算过程INT8 量化的核心是确定缩放因子scale和零点zero point。公式是real_value scale × (quantized_value - zero_point)对于对称量化zero_point 为 0scale max(abs(real_value)) / 127。对于非对称量化scale (max - min) / 255zero_point round(-min / scale)。假设某层激活值的范围是 [-2.5, 3.8]非对称量化scale (3.8 - (-2.5)) / 255 6.3 / 255 ≈ 0.0247zero_point round(-(-2.5) / 0.0247) round(101.2) 101这样 -2.5 映射到 03.8 映射到 255中间值线性映射。校准的过程就是统计每层的 min 和 max但直接用全局 min/max 容易被离群值带偏所以常用移动平均或者百分位裁剪比如取 99.9% 分位数来估计范围。我一般用百分位裁剪把极端离群值排除掉量化范围更紧凑精度更好。代价是超出范围的激活值会被截断但这种情况很少影响可控。4.3 精度验证的完整方法优化完不能只看速度精度必须验证。我的验证流程分三层第一层单元测试。拿一批固定输入对比优化前后输出的差异。用余弦相似度或者最大绝对误差衡量。一般 FP16 的余弦相似度在 0.9999 以上INT8 在 0.99 以上算正常。第二层离线评估。在完整的验证集上跑一遍看业务指标掉了多少。这一步要和业务方一起定阈值掉多少可以接受。第三层在线灰度。小流量上线对比优化前后的线上指标。这一步最关键因为离线数据和线上分布总有差异。灰度期间要盯紧一旦指标异常立刻回滚。提示三层验证缺一不可。我见过离线指标正常、线上一塌糊涂的案例就是因为线上有离线没覆盖的输入模式。灰度是最后一道防线千万别省。5. 常见问题与排查技巧实录5.1 量化后精度暴跌怎么排查精度暴跌是最常见的问题排查思路按这个顺序走排查项检查方法常见原因校准数据对比校准集与线上分布分布不匹配长尾未覆盖量化范围打印每层 min/max离群值拉大范围有效精度降低敏感层逐层回退到 FP16某些层对量化敏感算子支持检查是否有算子回退到 FP32混合精度导致精度异常我的经验是先查校准数据。八成的问题出在这里。校准集要覆盖线上各种输入长度、领域、噪声水平都要接近。如果线上有用户生成的乱码、超长文本校准集里也得有。如果校准数据没问题就查敏感层。Transformer 里LayerNorm 和 softmax 附近的层通常对量化敏感可以单独保留 FP16。这种混合精度方案能救回大部分精度。5.2 优化后速度没提升甚至变慢这种情况一般是几个原因算子回退。某些算子在目标推理引擎里没有低精度实现自动回退到 FP32导致混合精度反而更慢。用 profiling 工具看每个算子的实际精度和耗时找出回退的算子。内存对齐问题。剪枝或量化后张量维度不再是 8 或 16 的倍数GPU 的内存访问效率下降。解决办法是把维度 padding 到对齐的倍数。kernel launch 开销。模型被切得太碎算子数量多launch 开销占比高。这时候图优化的融合就很重要。数据传输瓶颈。如果模型在 GPU 上但数据在 CPUPCIe 传输成了瓶颈。用 pinned memory 和异步传输能缓解。我一般用 Nsight Systems 或者 PyTorch Profiler 做 profiling看时间花在哪。是计算、是内存、还是传输一目了然。5.3 显存碎片与 OOM 问题显存 OOM 不一定是显存不够可能是碎片。PyTorch 的缓存分配器会预留显存长时间运行后碎片化严重。解决办法设置PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True用可扩展段减少碎片。定期重启服务或者用显存池管理。推理时用torch.no_grad()避免保存计算图。还有一个容易忽略的点模型加载时的峰值显存。加载大模型时如果先加载到 CPU 再搬到 GPU峰值是两份。用device_map或者分片加载能降低峰值。5.4 独家避坑清单最后整理一份我踩过的坑都是文档里不会写的量化前先备份原始模型。量化不可逆出问题要能回退。校准数据要固定随机种子。不然每次校准结果不一样没法复现。TensorRT engine 和硬件绑定。换卡要重新编译别指望跨卡通用。INT8 不一定比 FP16 快。小模型上 INT8 的反量化开销可能抵消收益实测为准。剪枝后要重新测延迟。参数量降了不代表速度快了。灰度期间监控要加精度指标。光看延迟和 QPS 不够业务指标才是根本。优化是迭代的。一次优化到位很难多轮小步快跑比一次大改稳。我个人在实际操作中的体会是模型优化这件事七分靠测量三分靠技术。你得先知道瓶颈在哪再选对应的手段。盲目上工具往往是花了大力气收益却不成正比。每次优化前后都要有数据对比用数据说话别凭感觉。这套方法我在好几个项目里复用基本都能把推理成本压到原来的三分之一到五分之一效果稳定。
