1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的排序模型上。当时线上推理延迟卡在 120ms 下不去GPU 利用率却只有 30% 出头团队里有人提议加机器有人提议换更小的模型。折腾了两周才发现真正的问题出在模型本身的结构冗余和算子实现上——把几个连续的全连接层做融合、把部分权重做量化、把推理图重新调度一遍延迟直接掉到 45ms精度损失不到 0.3%。这就是模型优化器存在的意义它不改变你要解决的任务而是让同一个模型在同样的硬件上跑得更快、更省、更稳。Model-Optimizer 这个词从字面上看是“模型优化器”但它不是一个单一工具而是一整套围绕模型生命周期做性能压榨的方法论和工具链的集合。它覆盖的范围很广训练阶段的梯度优化、显存优化、分布式通信优化推理阶段的图优化、算子融合、量化、剪枝、蒸馏以及部署阶段的编译、调度、内存复用。你可以把它理解成模型从“能跑”到“跑得好”之间的那一段工程化工作。适合看这篇内容的人我大致分三类。第一类是做算法落地但被性能卡住的工程师模型精度达标了但延迟、吞吐、显存总有一项不达标第二类是做推理服务或边缘部署的开发者需要在有限算力上塞进更大的模型第三类是想系统了解模型优化全貌的技术负责人需要判断在哪个环节投入产出比最高。不管你是哪一类接下来的内容都会从思路、细节、实操到踩坑一层层拆开讲。2. 整体设计思路与方案选型逻辑2.1 为什么优化要从“瓶颈定位”开始而不是直接上工具很多人一提到模型优化第一反应是去找量化工具、剪枝库、编译框架然后挨个试。这个顺序其实是反的。模型优化本质上是一个资源再分配的过程你得先知道资源被谁吃掉了才能决定从哪里下手。我见过太多团队上来就做 INT8 量化结果发现瓶颈根本不在计算而在数据搬运或者 kernel launch 开销上量化完延迟几乎没变精度还掉了。正确的做法是先做 profiling。训练阶段看的是每层的前向反向耗时、显存占用峰值、通信占比推理阶段看的是算子级耗时、内存带宽利用率、CPU-GPU 同步次数。只有拿到这些数据你才能判断当前模型是 compute-bound 还是 memory-bound。这两个结论对应的优化路径完全不同compute-bound 优先考虑算子融合和低精度计算memory-bound 优先考虑权重重排、内存复用和减少中间张量。提示profiling 工具的选择要和你的框架匹配。PyTorch 生态下 torch.profiler 能给出算子级时间线和显存快照TensorRT 有自带的 layer profilerONNX Runtime 也有 profiling 开关。不要用“感觉慢”来做优化决策。2.2 训练优化与推理优化的分界线在哪里训练和推理的优化目标不一样手段也不一样混在一起谈容易乱。训练阶段的核心矛盾是显存和通信大模型训练时显存往往先于算力成为瓶颈所以混合精度、梯度检查点、ZeRO 系列的分片策略、梯度累积这些手段本质上都是在用时间换空间或者用通信换空间。推理阶段的核心矛盾是延迟和吞吐这时候显存通常够用但每个请求都要走一遍完整前向所以图优化、算子融合、量化、KV Cache 管理才是重点。分界线在于训练优化关注的是“能不能训得动、训得快”推理优化关注的是“能不能响应快、扛得住并发”。一个典型的误区是把训练阶段的优化手段直接搬到推理上比如在推理时还用梯度检查点那就是白白增加计算量。反过来把推理量化直接用在训练上梯度精度不够会导致训练不收敛。2.3 优化手段的优先级排序从低成本高收益开始模型优化手段很多但投入产出比差异巨大。我一般按下面的顺序推进每一步确认收益后再进入下一步优先级优化手段典型收益实施成本精度影响1算子融合与图优化延迟降 20%-40%低无2混合精度推理延迟降 30%-50%低极小3内存复用与 KV Cache 优化显存降 30%-60%中无4训练后量化PTQ延迟降 40%-70%中小到中5结构化剪枝参数量降 30%-50%中高中6量化感知训练QAT延迟降 50%-70%高极小7知识蒸馏模型缩小 2-10 倍高可控这个排序的逻辑是先做那些不损失精度、实施成本低的手段把“免费”的收益拿到手再考虑需要重训练或者精度妥协的方案。很多项目做到第三步就已经能满足性能要求了根本不需要走到量化和蒸馏。3. 核心细节解析与实操要点3.1 算子融合为什么把 ConvBNReLU 合成一个算子能提速算子融合是推理优化里性价比最高的一招。以最常见的 ConvBNReLU 为例在未融合的情况下数据要经历三次 kernel 调用卷积算完写回显存BN 读出来算完再写回ReLU 再读再写。每次读写都是一次显存往返而显存带宽往往是推理的瓶颈。融合之后这三个操作在一个 kernel 里完成中间结果留在寄存器或共享内存里显存往返从三次降到一次。具体到数学上BN 在推理阶段是一个线性变换y gamma * (x - mean) / sqrt(var eps) beta。这个变换可以完全折叠进卷积的权重和偏置里。假设卷积权重为 W、偏置为 b融合后的权重 W W * gamma / sqrt(var eps)偏置 b (b - mean) * gamma / sqrt(var eps) beta。这样 BN 就消失了Conv 和 ReLU 再融合成一个算子整个模块只剩一次计算。实操上PyTorch 可以用 torch.fx 做图级别的融合TensorRT 和 ONNX Runtime 在构建引擎时会自动做这类融合。但要注意融合的前提是 BN 处于推理模式eval如果 BN 还在训练模式统计量还在更新融合会导致结果错误。注意动态图框架下融合效果依赖导出时的图结构。如果你在 forward 里写了条件分支或者动态 shape融合可能会失败。导出 ONNX 时尽量用固定 shape 或者明确标注动态维度。3.2 量化从 FP32 到 INT8 的精度损失到底出在哪里量化是把浮点权重和激活值映射到低比特整数的过程。以 INT8 为例一个 FP32 张量被映射到 [-128, 127] 的整数区间映射公式是 x_int round(x / scale) zero_point。scale 是缩放因子zero_point 是零点偏移。推理时用整数运算最后再反量化回浮点。精度损失主要来自三个地方。第一是截断误差如果某个层的激活值动态范围很大scale 会被拉大小数值就被量化得很粗。第二是离群值少数极大的激活值会把整个分布的 scale 撑大导致大部分正常值精度不足。第三是累积误差多层量化误差逐层累积到后面就放大了。解决思路对应也有三种。针对截断误差可以用 per-channel 量化代替 per-tensor 量化每个通道独立的 scale精度明显更好。针对离群值可以用 KL 散度校准或者 percentile 校准把极端值裁掉。针对累积误差可以在关键层保留 FP16只对不敏感的层做 INT8这种混合精度量化往往能在精度和速度之间取得很好的平衡。量化方案精度保持速度提升适用场景per-tensor INT8一般高对精度不敏感的 CV 模型per-channel INT8好高大多数 CNN混合 INT8/FP16很好中高Transformer、检测模型INT4 权重量化中很高大语言模型推理3.3 剪枝结构化剪枝和非结构化剪枝的取舍剪枝的思路是把模型中不重要的权重或结构去掉。非结构化剪枝是把单个权重置零理论上能获得很高的稀疏度但实际推理时除非硬件支持稀疏计算否则零权重还是要参与计算速度提升有限。结构化剪枝是直接去掉整个通道、整个头或者整个层剪完之后模型结构真的变小了推理速度能实打实提升。结构化剪枝的关键是判断哪些结构“不重要”。常用的重要性指标有 L1/L2 范数、BN 的 gamma 系数、梯度幅值、Taylor 展开的贡献度。实践中 BN 的 gamma 系数是很好用的指标因为 BN 后面通常接 ReLUgamma 接近零的通道输出也接近零去掉影响很小。剪枝的流程一般是先训一个稠密模型评估各结构的重要性按比例剪掉最不重要的部分然后 fine-tune 恢复精度。剪枝比例不能一次剪太多通常每次剪 10%-20%fine-tune 后再评估迭代几轮。一次性剪 50% 以上基本都会导致精度崩掉。提示剪枝后一定要重新做 profiling。有时候剪了参数但推理速度没变是因为剩下的结构变成了 memory-bound计算量减少但访存没减少。这种情况下要配合算子融合一起做。3.4 知识蒸馏用大模型教小模型的实操细节知识蒸馏是让一个小模型学生去模仿一个大模型教师的输出分布。和直接用硬标签训练相比软标签包含了类间相似性信息学生模型能学到更丰富的知识。蒸馏的损失函数通常是软标签 KL 散度和硬标签交叉熵的加权和L alpha * KL(student_soft || teacher_soft) (1 - alpha) * CE(student, label)。温度参数 T 是蒸馏里的关键。T 越大软标签分布越平滑类间关系信息越丰富但太大会让分布接近均匀失去区分度。实践中 T 取 2 到 10 之间比较常见alpha 取 0.5 到 0.9。教师模型的精度上限决定了学生模型的上限所以教师一定要训到足够好。蒸馏的另一个细节是中间层特征对齐。除了输出层蒸馏还可以让学生模型的中间特征去逼近教师模型的中间特征这叫 hint learning。对 Transformer 类模型注意力矩阵的蒸馏也很有效。这些额外约束能显著提升小模型的最终精度。4. 完整实操流程与关键环节实现4.1 环境准备与基线测量动手之前先把环境和基线固定下来。我一般会准备一个干净的 conda 环境装好 PyTorch、ONNX、ONNX Runtime、TensorRT如果做 GPU 部署以及对应的 profiling 工具。版本一定要锁死模型优化对版本非常敏感ONNX opset 差一个版本可能就导致某个算子不支持。基线测量要记录四组数据延迟P50 和 P99、吞吐QPS、显存峰值、精度指标。延迟要在固定 batch size 和固定输入 shape 下测否则数据没有可比性。测的时候先 warmup 至少 50 次把 GPU 频率和缓存都预热到位再跑 200 次取统计值。import torch import time def measure_latency(model, input_tensor, warmup50, iters200): model.eval() with torch.no_grad(): for _ in range(warmup): model(input_tensor) torch.cuda.synchronize() start time.perf_counter() for _ in range(iters): model(input_tensor) torch.cuda.synchronize() end time.perf_counter() return (end - start) / iters * 1000 # ms这段代码里 torch.cuda.synchronize() 很关键。GPU 是异步执行的不加同步的话计时只测到了 kernel launch 的时间不是真实执行时间。很多人第一次测出来延迟特别低就是因为漏了同步。4.2 图导出与算子融合实操以 PyTorch 导出 ONNX 为例导出时要明确指定 opset 版本和动态维度。动态维度用 dynamic_axes 参数标注比如 batch 维和序列长度维。导出后可以用 onnxsim 做一次图简化它会自动做常量折叠、冗余算子消除和部分融合。import torch.onnx torch.onnx.export( model, dummy_input, model.onnx, opset_version13, input_names[input], output_names[output], dynamic_axes{input: {0: batch, 1: seq_len}, output: {0: batch}} )导出后一定要验证数值一致性。用同一组输入分别跑 PyTorch 和 ONNX Runtime对比输出差异。如果 max diff 超过 1e-3说明导出过程中有算子行为不一致需要排查。常见原因是某些算子在 ONNX 里的实现和 PyTorch 有细微差别比如 interpolate 的 align_corners 参数。4.3 量化校准与精度验证训练后量化PTQ的流程分三步准备校准数据集、跑校准收集激活值分布、生成量化模型。校准数据集不需要标签但要从真实训练数据里采样数量一般 100 到 500 个 batch 就够。校准数据分布要和实际推理分布一致否则 scale 会偏。from onnxruntime.quantization import quantize_static, CalibrationDataReader class DataReader(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_readerDataReader(calib_data), quant_formatQDQ, per_channelTrue )量化完必须做精度验证。在验证集上跑一遍对比量化前后的指标。如果掉点超过可接受范围先尝试 per-channel 量化再尝试混合精度最后才考虑量化感知训练。我个人的经验是CNN 类模型 PTQ 掉点通常在 0.5% 以内Transformer 类模型掉点会大一些可能需要 QAT。4.4 推理引擎构建与性能调优如果目标是 GPU 部署TensorRT 通常是首选。构建引擎时几个参数很关键max_batch_size 决定最大并发workspace size 决定编译时可用的显存precision 决定是否启用 FP16/INT8。workspace 给太小会导致某些优化策略无法启用给太大又浪费显存一般给 1GB 到 4GB 之间。trtexec --onnxmodel.onnx \ --saveEnginemodel.engine \ --fp16 \ --workspace2048 \ --minShapesinput:1x128 \ --optShapesinput:8x128 \ --maxShapesinput:32x128minShapes、optShapes、maxShapes 这三个 shape 配置决定了引擎的优化 profile。optShapes 是你最常跑的 shape引擎会针对它做最优优化。如果实际请求的 shape 分布和 optShapes 差很远性能会下降。所以要根据线上真实流量分布来设置。5. 常见问题与排查技巧实录5.1 量化后精度暴跌的排查顺序量化掉点是最常见的问题。排查顺序我一般是这样先看是哪一层掉点最严重逐层做敏感度分析再看校准数据是否具有代表性然后检查是否有层不适合量化比如第一层和最后一层通常对精度敏感可以保留 FP32最后考虑换量化方案或者上 QAT。逐层敏感度分析的做法是每次只量化一层其他层保持 FP32看精度变化。掉点最大的那几层就是敏感层。这个分析比较耗时但能精准定位问题。实践中发现检测模型的回归头和分类模型的最后一层全连接通常最敏感。5.2 融合失败导致性能不升反降有时候做了算子融合延迟反而变高了。原因通常是融合后的算子实现不够高效或者融合破坏了原本的并行度。比如把两个小算子融合成一个大算子但大算子的实现没有针对硬件优化反而比两个小算子串行还慢。排查方法是看融合前后的算子级 profiling。如果融合后某个算子耗时异常高可以尝试禁用这个融合规则。TensorRT 和 ONNX Runtime 都支持通过配置禁用特定融合。另外融合后的算子如果寄存器压力太大导致 occupancy 下降也会变慢这种情况需要调整 tile size 或者换实现。5.3 动态 shape 下的性能抖动动态 shape 是推理服务里很头疼的问题。同一个引擎batch1 和 batch32 的延迟可能差 10 倍以上而且 P99 延迟往往出现在某些特定 shape 上。解决办法是设置合理的 shape profile把常见 shape 都覆盖到或者对不同的 shape 区间构建多个引擎做路由。另一个技巧是 padding。如果实际 shape 变化范围不大可以把输入 padding 到固定 shape用固定 shape 引擎推理最后再把 padding 部分裁掉。这样能避免动态 shape 带来的性能抖动代价是少量无效计算。对延迟敏感的场景这个 trade-off 通常是值得的。问题现象可能原因排查手段解决方向量化后掉点大敏感层被量化逐层敏感度分析敏感层保留 FP32融合后变慢融合算子实现低效算子级 profiling禁用该融合规则动态 shape 抖动shape profile 不合理分 shape 测延迟多引擎路由或 padding显存峰值高中间张量未复用显存快照分析内存复用或梯度检查点吞吐上不去请求调度不合理看 GPU 利用率动态 batching5.4 训练侧显存优化的几个实用手段训练大模型时显存不够是常态。除了买更大的卡工程上能做的有混合精度训练AMP能省约 40% 显存梯度检查点能省 50%-70% 激活显存但增加约 30% 计算时间ZeRO 系列把优化器状态和梯度分片到多卡能线性扩展显存容量。这几个手段可以叠加使用。我个人的经验是先开 AMP这是最省事收益最大的。如果还不够再上梯度检查点但要注意检查点的粒度太细会增加重计算开销太粗省不了多少显存。ZeRO 适合多卡场景单卡用不上。另外及时释放不再需要的中间变量、避免在计算图里保留不必要的引用这些编码习惯也能省不少显存。6. 优化效果评估与持续迭代6.1 怎么判断优化已经到位了优化做到什么程度算够这个问题没有标准答案但有几个信号可以参考。第一profiling 显示 GPU 利用率稳定在 70% 以上说明计算资源被充分利用了。第二延迟的 P99 和 P50 差距在 2 倍以内说明没有明显的长尾抖动。第三继续做优化手段的边际收益已经很小比如再量化一层只能降 2% 延迟但精度要掉 0.5%那就不值得了。另一个判断维度是看瓶颈是否转移。如果一开始是 compute-bound优化后变成了 memory-bound说明计算侧的优化已经到位接下来要解决访存问题。如果优化后瓶颈变成了 CPU 侧的预处理或者后处理那模型本身的优化空间就不大了该去优化数据管道了。6.2 建立回归测试防止优化引入退化模型优化不是一次性的工作每次模型更新、每次引擎重建都可能引入性能或精度退化。所以一定要建立回归测试。精度回归用固定的验证集每次优化后跑一遍指标掉超过阈值就报警。性能回归用固定的 benchmark 脚本记录延迟和吞吐同样设阈值。回归测试的频率取决于迭代速度。模型每周更新的话回归测试至少每周跑一次。引擎重建后必须跑。我见过因为换了 ONNX Runtime 版本导致某个算子实现变化延迟悄悄涨了 15% 都没人发现直到线上告警才排查出来。这种问题只有靠回归测试才能提前发现。6.3 优化手段的组合与冲突不同优化手段之间可能冲突。比如量化后再剪枝剪枝的重要性评估会受量化误差影响可能剪错结构。再比如蒸馏和量化同时做学生模型本身已经很小了再量化可能精度崩掉。所以优化手段要串行推进每步验证后再做下一步不要一次性全上。组合的顺序一般是先做图优化和算子融合再做量化然后剪枝最后蒸馏。蒸馏通常放在最后因为它是用大模型教小模型小模型的结构应该已经确定下来了。如果先蒸馏再剪枝剪枝可能破坏蒸馏学到的知识需要重新蒸馏。提示每次只改一个变量这是做优化的铁律。同时改多个参数出了问题根本不知道是哪个引起的。我吃过这个亏一次同时开了量化和融合结果精度掉了排查了一天才发现是量化校准数据的问题融合是无辜的。7. 一些个人体会做模型优化这些年最大的感受是优化不是炫技而是权衡。每一个手段都有代价要么是精度要么是工程复杂度要么是维护成本。真正难的从来不是“能不能优化”而是“值不值得优化”。一个延迟从 50ms 降到 40ms 的优化如果带来的是每周都要重新校准的维护负担那可能不如加一台机器划算。另一个体会是profiling 永远比直觉可靠。我见过太多人凭感觉猜瓶颈猜错的概率超过一半。花半个小时做一次 profiling比花两天试各种工具有效得多。数据不会骗人GPU 利用率、显存带宽、算子耗时这些指标摆在那里瓶颈一目了然。最后模型优化是一个持续的过程不是一锤子买卖。模型在变数据在变硬件在变优化策略也要跟着变。建立一套可复现的评估流程和回归测试比掌握任何一个具体优化技巧都重要。这套流程能让你在每次变化时快速定位问题而不是每次都从头再来一遍。 
长河君 · 2026/9/29 19:29:15 · 阅读 1.2k 模型优化器实战：从算子融合到量化剪枝的推理加速指南
1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的排序模型上。当时线上推理延迟卡在 120ms 下不去GPU 利用率却只有 30% 出头团队里有人提议加机器有人提议换更小的模型。折腾了两周才发现真正的问题出在模型本身的结构冗余和算子实现上——把几个连续的全连接层做融合、把部分权重做量化、把推理图重新调度一遍延迟直接掉到 45ms精度损失不到 0.3%。这就是模型优化器存在的意义它不改变你要解决的任务而是让同一个模型在同样的硬件上跑得更快、更省、更稳。Model-Optimizer 这个词从字面上看是“模型优化器”但它不是一个单一工具而是一整套围绕模型生命周期做性能压榨的方法论和工具链的集合。它覆盖的范围很广训练阶段的梯度优化、显存优化、分布式通信优化推理阶段的图优化、算子融合、量化、剪枝、蒸馏以及部署阶段的编译、调度、内存复用。你可以把它理解成模型从“能跑”到“跑得好”之间的那一段工程化工作。适合看这篇内容的人我大致分三类。第一类是做算法落地但被性能卡住的工程师模型精度达标了但延迟、吞吐、显存总有一项不达标第二类是做推理服务或边缘部署的开发者需要在有限算力上塞进更大的模型第三类是想系统了解模型优化全貌的技术负责人需要判断在哪个环节投入产出比最高。不管你是哪一类接下来的内容都会从思路、细节、实操到踩坑一层层拆开讲。2. 整体设计思路与方案选型逻辑2.1 为什么优化要从“瓶颈定位”开始而不是直接上工具很多人一提到模型优化第一反应是去找量化工具、剪枝库、编译框架然后挨个试。这个顺序其实是反的。模型优化本质上是一个资源再分配的过程你得先知道资源被谁吃掉了才能决定从哪里下手。我见过太多团队上来就做 INT8 量化结果发现瓶颈根本不在计算而在数据搬运或者 kernel launch 开销上量化完延迟几乎没变精度还掉了。正确的做法是先做 profiling。训练阶段看的是每层的前向反向耗时、显存占用峰值、通信占比推理阶段看的是算子级耗时、内存带宽利用率、CPU-GPU 同步次数。只有拿到这些数据你才能判断当前模型是 compute-bound 还是 memory-bound。这两个结论对应的优化路径完全不同compute-bound 优先考虑算子融合和低精度计算memory-bound 优先考虑权重重排、内存复用和减少中间张量。提示profiling 工具的选择要和你的框架匹配。PyTorch 生态下 torch.profiler 能给出算子级时间线和显存快照TensorRT 有自带的 layer profilerONNX Runtime 也有 profiling 开关。不要用“感觉慢”来做优化决策。2.2 训练优化与推理优化的分界线在哪里训练和推理的优化目标不一样手段也不一样混在一起谈容易乱。训练阶段的核心矛盾是显存和通信大模型训练时显存往往先于算力成为瓶颈所以混合精度、梯度检查点、ZeRO 系列的分片策略、梯度累积这些手段本质上都是在用时间换空间或者用通信换空间。推理阶段的核心矛盾是延迟和吞吐这时候显存通常够用但每个请求都要走一遍完整前向所以图优化、算子融合、量化、KV Cache 管理才是重点。分界线在于训练优化关注的是“能不能训得动、训得快”推理优化关注的是“能不能响应快、扛得住并发”。一个典型的误区是把训练阶段的优化手段直接搬到推理上比如在推理时还用梯度检查点那就是白白增加计算量。反过来把推理量化直接用在训练上梯度精度不够会导致训练不收敛。2.3 优化手段的优先级排序从低成本高收益开始模型优化手段很多但投入产出比差异巨大。我一般按下面的顺序推进每一步确认收益后再进入下一步优先级优化手段典型收益实施成本精度影响1算子融合与图优化延迟降 20%-40%低无2混合精度推理延迟降 30%-50%低极小3内存复用与 KV Cache 优化显存降 30%-60%中无4训练后量化PTQ延迟降 40%-70%中小到中5结构化剪枝参数量降 30%-50%中高中6量化感知训练QAT延迟降 50%-70%高极小7知识蒸馏模型缩小 2-10 倍高可控这个排序的逻辑是先做那些不损失精度、实施成本低的手段把“免费”的收益拿到手再考虑需要重训练或者精度妥协的方案。很多项目做到第三步就已经能满足性能要求了根本不需要走到量化和蒸馏。3. 核心细节解析与实操要点3.1 算子融合为什么把 ConvBNReLU 合成一个算子能提速算子融合是推理优化里性价比最高的一招。以最常见的 ConvBNReLU 为例在未融合的情况下数据要经历三次 kernel 调用卷积算完写回显存BN 读出来算完再写回ReLU 再读再写。每次读写都是一次显存往返而显存带宽往往是推理的瓶颈。融合之后这三个操作在一个 kernel 里完成中间结果留在寄存器或共享内存里显存往返从三次降到一次。具体到数学上BN 在推理阶段是一个线性变换y gamma * (x - mean) / sqrt(var eps) beta。这个变换可以完全折叠进卷积的权重和偏置里。假设卷积权重为 W、偏置为 b融合后的权重 W W * gamma / sqrt(var eps)偏置 b (b - mean) * gamma / sqrt(var eps) beta。这样 BN 就消失了Conv 和 ReLU 再融合成一个算子整个模块只剩一次计算。实操上PyTorch 可以用 torch.fx 做图级别的融合TensorRT 和 ONNX Runtime 在构建引擎时会自动做这类融合。但要注意融合的前提是 BN 处于推理模式eval如果 BN 还在训练模式统计量还在更新融合会导致结果错误。注意动态图框架下融合效果依赖导出时的图结构。如果你在 forward 里写了条件分支或者动态 shape融合可能会失败。导出 ONNX 时尽量用固定 shape 或者明确标注动态维度。3.2 量化从 FP32 到 INT8 的精度损失到底出在哪里量化是把浮点权重和激活值映射到低比特整数的过程。以 INT8 为例一个 FP32 张量被映射到 [-128, 127] 的整数区间映射公式是 x_int round(x / scale) zero_point。scale 是缩放因子zero_point 是零点偏移。推理时用整数运算最后再反量化回浮点。精度损失主要来自三个地方。第一是截断误差如果某个层的激活值动态范围很大scale 会被拉大小数值就被量化得很粗。第二是离群值少数极大的激活值会把整个分布的 scale 撑大导致大部分正常值精度不足。第三是累积误差多层量化误差逐层累积到后面就放大了。解决思路对应也有三种。针对截断误差可以用 per-channel 量化代替 per-tensor 量化每个通道独立的 scale精度明显更好。针对离群值可以用 KL 散度校准或者 percentile 校准把极端值裁掉。针对累积误差可以在关键层保留 FP16只对不敏感的层做 INT8这种混合精度量化往往能在精度和速度之间取得很好的平衡。量化方案精度保持速度提升适用场景per-tensor INT8一般高对精度不敏感的 CV 模型per-channel INT8好高大多数 CNN混合 INT8/FP16很好中高Transformer、检测模型INT4 权重量化中很高大语言模型推理3.3 剪枝结构化剪枝和非结构化剪枝的取舍剪枝的思路是把模型中不重要的权重或结构去掉。非结构化剪枝是把单个权重置零理论上能获得很高的稀疏度但实际推理时除非硬件支持稀疏计算否则零权重还是要参与计算速度提升有限。结构化剪枝是直接去掉整个通道、整个头或者整个层剪完之后模型结构真的变小了推理速度能实打实提升。结构化剪枝的关键是判断哪些结构“不重要”。常用的重要性指标有 L1/L2 范数、BN 的 gamma 系数、梯度幅值、Taylor 展开的贡献度。实践中 BN 的 gamma 系数是很好用的指标因为 BN 后面通常接 ReLUgamma 接近零的通道输出也接近零去掉影响很小。剪枝的流程一般是先训一个稠密模型评估各结构的重要性按比例剪掉最不重要的部分然后 fine-tune 恢复精度。剪枝比例不能一次剪太多通常每次剪 10%-20%fine-tune 后再评估迭代几轮。一次性剪 50% 以上基本都会导致精度崩掉。提示剪枝后一定要重新做 profiling。有时候剪了参数但推理速度没变是因为剩下的结构变成了 memory-bound计算量减少但访存没减少。这种情况下要配合算子融合一起做。3.4 知识蒸馏用大模型教小模型的实操细节知识蒸馏是让一个小模型学生去模仿一个大模型教师的输出分布。和直接用硬标签训练相比软标签包含了类间相似性信息学生模型能学到更丰富的知识。蒸馏的损失函数通常是软标签 KL 散度和硬标签交叉熵的加权和L alpha * KL(student_soft || teacher_soft) (1 - alpha) * CE(student, label)。温度参数 T 是蒸馏里的关键。T 越大软标签分布越平滑类间关系信息越丰富但太大会让分布接近均匀失去区分度。实践中 T 取 2 到 10 之间比较常见alpha 取 0.5 到 0.9。教师模型的精度上限决定了学生模型的上限所以教师一定要训到足够好。蒸馏的另一个细节是中间层特征对齐。除了输出层蒸馏还可以让学生模型的中间特征去逼近教师模型的中间特征这叫 hint learning。对 Transformer 类模型注意力矩阵的蒸馏也很有效。这些额外约束能显著提升小模型的最终精度。4. 完整实操流程与关键环节实现4.1 环境准备与基线测量动手之前先把环境和基线固定下来。我一般会准备一个干净的 conda 环境装好 PyTorch、ONNX、ONNX Runtime、TensorRT如果做 GPU 部署以及对应的 profiling 工具。版本一定要锁死模型优化对版本非常敏感ONNX opset 差一个版本可能就导致某个算子不支持。基线测量要记录四组数据延迟P50 和 P99、吞吐QPS、显存峰值、精度指标。延迟要在固定 batch size 和固定输入 shape 下测否则数据没有可比性。测的时候先 warmup 至少 50 次把 GPU 频率和缓存都预热到位再跑 200 次取统计值。import torch import time def measure_latency(model, input_tensor, warmup50, iters200): model.eval() with torch.no_grad(): for _ in range(warmup): model(input_tensor) torch.cuda.synchronize() start time.perf_counter() for _ in range(iters): model(input_tensor) torch.cuda.synchronize() end time.perf_counter() return (end - start) / iters * 1000 # ms这段代码里 torch.cuda.synchronize() 很关键。GPU 是异步执行的不加同步的话计时只测到了 kernel launch 的时间不是真实执行时间。很多人第一次测出来延迟特别低就是因为漏了同步。4.2 图导出与算子融合实操以 PyTorch 导出 ONNX 为例导出时要明确指定 opset 版本和动态维度。动态维度用 dynamic_axes 参数标注比如 batch 维和序列长度维。导出后可以用 onnxsim 做一次图简化它会自动做常量折叠、冗余算子消除和部分融合。import torch.onnx torch.onnx.export( model, dummy_input, model.onnx, opset_version13, input_names[input], output_names[output], dynamic_axes{input: {0: batch, 1: seq_len}, output: {0: batch}} )导出后一定要验证数值一致性。用同一组输入分别跑 PyTorch 和 ONNX Runtime对比输出差异。如果 max diff 超过 1e-3说明导出过程中有算子行为不一致需要排查。常见原因是某些算子在 ONNX 里的实现和 PyTorch 有细微差别比如 interpolate 的 align_corners 参数。4.3 量化校准与精度验证训练后量化PTQ的流程分三步准备校准数据集、跑校准收集激活值分布、生成量化模型。校准数据集不需要标签但要从真实训练数据里采样数量一般 100 到 500 个 batch 就够。校准数据分布要和实际推理分布一致否则 scale 会偏。from onnxruntime.quantization import quantize_static, CalibrationDataReader class DataReader(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_readerDataReader(calib_data), quant_formatQDQ, per_channelTrue )量化完必须做精度验证。在验证集上跑一遍对比量化前后的指标。如果掉点超过可接受范围先尝试 per-channel 量化再尝试混合精度最后才考虑量化感知训练。我个人的经验是CNN 类模型 PTQ 掉点通常在 0.5% 以内Transformer 类模型掉点会大一些可能需要 QAT。4.4 推理引擎构建与性能调优如果目标是 GPU 部署TensorRT 通常是首选。构建引擎时几个参数很关键max_batch_size 决定最大并发workspace size 决定编译时可用的显存precision 决定是否启用 FP16/INT8。workspace 给太小会导致某些优化策略无法启用给太大又浪费显存一般给 1GB 到 4GB 之间。trtexec --onnxmodel.onnx \ --saveEnginemodel.engine \ --fp16 \ --workspace2048 \ --minShapesinput:1x128 \ --optShapesinput:8x128 \ --maxShapesinput:32x128minShapes、optShapes、maxShapes 这三个 shape 配置决定了引擎的优化 profile。optShapes 是你最常跑的 shape引擎会针对它做最优优化。如果实际请求的 shape 分布和 optShapes 差很远性能会下降。所以要根据线上真实流量分布来设置。5. 常见问题与排查技巧实录5.1 量化后精度暴跌的排查顺序量化掉点是最常见的问题。排查顺序我一般是这样先看是哪一层掉点最严重逐层做敏感度分析再看校准数据是否具有代表性然后检查是否有层不适合量化比如第一层和最后一层通常对精度敏感可以保留 FP32最后考虑换量化方案或者上 QAT。逐层敏感度分析的做法是每次只量化一层其他层保持 FP32看精度变化。掉点最大的那几层就是敏感层。这个分析比较耗时但能精准定位问题。实践中发现检测模型的回归头和分类模型的最后一层全连接通常最敏感。5.2 融合失败导致性能不升反降有时候做了算子融合延迟反而变高了。原因通常是融合后的算子实现不够高效或者融合破坏了原本的并行度。比如把两个小算子融合成一个大算子但大算子的实现没有针对硬件优化反而比两个小算子串行还慢。排查方法是看融合前后的算子级 profiling。如果融合后某个算子耗时异常高可以尝试禁用这个融合规则。TensorRT 和 ONNX Runtime 都支持通过配置禁用特定融合。另外融合后的算子如果寄存器压力太大导致 occupancy 下降也会变慢这种情况需要调整 tile size 或者换实现。5.3 动态 shape 下的性能抖动动态 shape 是推理服务里很头疼的问题。同一个引擎batch1 和 batch32 的延迟可能差 10 倍以上而且 P99 延迟往往出现在某些特定 shape 上。解决办法是设置合理的 shape profile把常见 shape 都覆盖到或者对不同的 shape 区间构建多个引擎做路由。另一个技巧是 padding。如果实际 shape 变化范围不大可以把输入 padding 到固定 shape用固定 shape 引擎推理最后再把 padding 部分裁掉。这样能避免动态 shape 带来的性能抖动代价是少量无效计算。对延迟敏感的场景这个 trade-off 通常是值得的。问题现象可能原因排查手段解决方向量化后掉点大敏感层被量化逐层敏感度分析敏感层保留 FP32融合后变慢融合算子实现低效算子级 profiling禁用该融合规则动态 shape 抖动shape profile 不合理分 shape 测延迟多引擎路由或 padding显存峰值高中间张量未复用显存快照分析内存复用或梯度检查点吞吐上不去请求调度不合理看 GPU 利用率动态 batching5.4 训练侧显存优化的几个实用手段训练大模型时显存不够是常态。除了买更大的卡工程上能做的有混合精度训练AMP能省约 40% 显存梯度检查点能省 50%-70% 激活显存但增加约 30% 计算时间ZeRO 系列把优化器状态和梯度分片到多卡能线性扩展显存容量。这几个手段可以叠加使用。我个人的经验是先开 AMP这是最省事收益最大的。如果还不够再上梯度检查点但要注意检查点的粒度太细会增加重计算开销太粗省不了多少显存。ZeRO 适合多卡场景单卡用不上。另外及时释放不再需要的中间变量、避免在计算图里保留不必要的引用这些编码习惯也能省不少显存。6. 优化效果评估与持续迭代6.1 怎么判断优化已经到位了优化做到什么程度算够这个问题没有标准答案但有几个信号可以参考。第一profiling 显示 GPU 利用率稳定在 70% 以上说明计算资源被充分利用了。第二延迟的 P99 和 P50 差距在 2 倍以内说明没有明显的长尾抖动。第三继续做优化手段的边际收益已经很小比如再量化一层只能降 2% 延迟但精度要掉 0.5%那就不值得了。另一个判断维度是看瓶颈是否转移。如果一开始是 compute-bound优化后变成了 memory-bound说明计算侧的优化已经到位接下来要解决访存问题。如果优化后瓶颈变成了 CPU 侧的预处理或者后处理那模型本身的优化空间就不大了该去优化数据管道了。6.2 建立回归测试防止优化引入退化模型优化不是一次性的工作每次模型更新、每次引擎重建都可能引入性能或精度退化。所以一定要建立回归测试。精度回归用固定的验证集每次优化后跑一遍指标掉超过阈值就报警。性能回归用固定的 benchmark 脚本记录延迟和吞吐同样设阈值。回归测试的频率取决于迭代速度。模型每周更新的话回归测试至少每周跑一次。引擎重建后必须跑。我见过因为换了 ONNX Runtime 版本导致某个算子实现变化延迟悄悄涨了 15% 都没人发现直到线上告警才排查出来。这种问题只有靠回归测试才能提前发现。6.3 优化手段的组合与冲突不同优化手段之间可能冲突。比如量化后再剪枝剪枝的重要性评估会受量化误差影响可能剪错结构。再比如蒸馏和量化同时做学生模型本身已经很小了再量化可能精度崩掉。所以优化手段要串行推进每步验证后再做下一步不要一次性全上。组合的顺序一般是先做图优化和算子融合再做量化然后剪枝最后蒸馏。蒸馏通常放在最后因为它是用大模型教小模型小模型的结构应该已经确定下来了。如果先蒸馏再剪枝剪枝可能破坏蒸馏学到的知识需要重新蒸馏。提示每次只改一个变量这是做优化的铁律。同时改多个参数出了问题根本不知道是哪个引起的。我吃过这个亏一次同时开了量化和融合结果精度掉了排查了一天才发现是量化校准数据的问题融合是无辜的。7. 一些个人体会做模型优化这些年最大的感受是优化不是炫技而是权衡。每一个手段都有代价要么是精度要么是工程复杂度要么是维护成本。真正难的从来不是“能不能优化”而是“值不值得优化”。一个延迟从 50ms 降到 40ms 的优化如果带来的是每周都要重新校准的维护负担那可能不如加一台机器划算。另一个体会是profiling 永远比直觉可靠。我见过太多人凭感觉猜瓶颈猜错的概率超过一半。花半个小时做一次 profiling比花两天试各种工具有效得多。数据不会骗人GPU 利用率、显存带宽、算子耗时这些指标摆在那里瓶颈一目了然。最后模型优化是一个持续的过程不是一锤子买卖。模型在变数据在变硬件在变优化策略也要跟着变。建立一套可复现的评估流程和回归测试比掌握任何一个具体优化技巧都重要。这套流程能让你在每次变化时快速定位问题而不是每次都从头再来一遍。