尧图网页设计 
1. 从模型能跑到模型跑得省Model-Optimizer 到底在解决什么做模型部署的人大概都有过这种体验训练阶段一切顺利指标也好看可一旦要把模型塞进实际业务环境问题就全冒出来了。推理延迟高得离谱、显存占用把显卡撑爆、批量请求一上来服务直接雪崩。这时候你会发现训练时那些能跑就行的宽松假设到了生产环境全都不成立。Model-Optimizer 这类工具出现的根本原因就是要把能跑的模型变成跑得省、跑得稳、跑得快的模型。我先把话说清楚Model-Optimizer 不是一个具体的库名而是一类面向模型推理优化的工具集合的统称。它覆盖的工作包括量化、剪枝、算子融合、图优化、内存复用、内核调优等等。你可以把它理解成模型上线前的体检加调理环节——模型本身没病但亚健康状态严重需要一套系统化的手段把它调整到最佳竞技状态。为什么这件事值得单独拿出来讲因为绝大多数团队在模型优化上的投入和收益是严重不成比例的。我见过太多项目训练阶段砸了几十张卡、调了几个月参结果部署时随手一个torch.save加torch.load就上线了推理性能全靠硬件硬扛。等到成本报表出来才发现推理成本是训练成本的十几倍甚至几十倍。模型优化不是锦上添花它是决定一个 AI 项目能不能长期活下去的关键环节。这篇文章适合三类人看一是刚接触模型部署、想知道优化到底在优化什么的工程师二是已经在做推理服务、但性能始终卡在瓶颈上的开发者三是需要为团队做技术选型、想搞清楚各类优化手段适用边界的负责人。我会尽量把原理讲透同时给出可以直接上手操作的步骤和参数让你看完就能在自己的项目里试。需要提前说明的是模型优化没有银弹。每一种手段都是在精度、速度、内存、开发成本之间做权衡。Model-Optimizer 的价值不在于某个单点技术多厉害而在于它提供了一套可组合、可度量、可回退的工程化流程。下面我会从优化前的诊断、核心手段的原理与实操、踩坑排查、到效果验证一层层拆开讲。2. 动手之前先做诊断搞清楚瓶颈到底在哪2.1 为什么不能上来就量化我见过最常见的错误就是一听说量化能提速二话不说先把模型转成 INT8结果精度掉了一大截回头再花大量时间做量化感知训练去补救。这个顺序是反的。正确的做法是先诊断搞清楚你的瓶颈是计算密集、内存带宽受限还是调度开销过大然后对症下药。诊断的核心是三个指标延迟Latency、吞吐Throughput、显存占用Memory Footprint。这三个指标之间往往互相牵制。比如你增大 batch size 能提升吞吐但延迟会上升、显存会吃紧。所以第一步不是优化而是明确你的业务到底更看重哪个。在线交互类服务通常卡延迟离线批处理类任务通常卡吞吐而边缘设备上显存和功耗才是硬约束。2.2 用 Profiler 定位真正的热点光看总延迟没用你得知道时间花在哪了。PyTorch 生态里我常用torch.profiler它能给出每个算子的耗时占比。下面是一段可以直接抄的代码import torch from torch.profiler import profile, ProfilerActivity model MyModel().eval().cuda() dummy_input torch.randn(1, 3, 224, 224).cuda() with profile(activities[ProfilerActivity.CPU, ProfilerActivity.CUDA], record_shapesTrue) as prof: with torch.no_grad(): for _ in range(10): model(dummy_input) print(prof.key_averages().table(sort_bycuda_time_total, row_limit20))跑完之后你会看到一张按 CUDA 耗时排序的算子表。经验上如果前五个算子的耗时加起来超过总时间的 70%那优化重点就非常明确了。常见的几个耗电大户是大矩阵乘法GEMM、卷积、LayerNorm、以及各种 element-wise 操作。element-wise 操作单个看着不起眼但数量一多内存带宽就被吃光了这时候算子融合的收益会非常明显。2.3 区分计算瓶颈和内存瓶颈这一步很多人会忽略但它直接决定你该用哪种优化手段。判断方法很简单看算子的算术强度Arithmetic Intensity也就是每读取一个字节能完成多少次浮点运算。算术强度高的算子比如大 GEMM是计算瓶颈优化方向是降低计算精度量化或换更快的计算内核。算术强度低的算子比如激活函数、逐元素加法是内存带宽瓶颈优化方向是算子融合把多次内存读写合并成一次。我自己的判断习惯是如果 profiler 显示大量时间花在elementwise、copy、contiguous这类操作上那基本可以确定是内存瓶颈优先考虑图优化和算子融合如果时间集中在gemm、conv、attention上那量化带来的收益会更直接。提示诊断阶段一定要用真实输入尺寸和真实 batch size。用torch.randn(1,3,224,224)测出来的结果和线上 batch32 的场景可能完全是两回事优化方向都可能相反。3. 量化收益最大但也最容易翻车的一环3.1 量化的本质是重新映射数值分布量化的核心思想是把原本用 32 位浮点表示的权重和激活值用更低的位宽通常是 INT8来表示。听起来简单但关键在于如何确定映射的缩放因子scale和零点zero point。浮点数能表示的范围很宽但实际模型里的数值往往集中在一个很窄的区间。如果你按理论最大范围去映射那大部分数值都会挤在很少的几个量化格子里精度损失巨大。所以量化的第一步永远是校准Calibration拿一批有代表性的真实数据跑一遍模型统计每一层激活值的实际分布范围据此确定 scale 和 zero point。校准数据的质量直接决定量化效果这一点后面踩坑部分我会详细讲。3.2 训练后量化与量化感知训练怎么选对比维度训练后量化PTQ量化感知训练QAT实现成本低几行代码高需要重新训练精度损失通常 0.5%~2%通常 0.1%~0.5%适用场景对精度不敏感的模型精度敏感、PTQ 掉点严重数据需求几百条校准样本完整训练集耗时分钟级小时到天级我的建议是先用 PTQ 试掉点可接受就直接上掉点严重再考虑 QAT。很多团队一上来就搞 QAT结果发现 PTQ 其实就够了白白浪费了大量算力。判断可接受的标准要结合业务分类任务掉 1% 准确率可能无所谓但检测任务掉 1% mAP 可能就影响召回了。3.3 一个可复现的 PTQ 实操流程以 PyTorch 的量化工具链为例静态量化Static Quantization的完整流程大致如下import torch import torch.quantization as tq # 1. 准备模型并设置为评估模式 model MyModel().eval() # 2. 指定量化配置 model.qconfig tq.get_default_qconfig(fbgemm) # x86 用 fbgemmARM 用 qnnpack # 3. 插入观察器准备量化 model_prepared tq.prepare(model, inplaceFalse) # 4. 用校准数据跑一遍收集激活分布 def calibrate(model, data_loader, num_batches10): with torch.no_grad(): for i, (inputs, _) in enumerate(data_loader): if i num_batches: break model(inputs) calibrate(model_prepared, calib_loader) # 5. 转换为量化模型 model_quantized tq.convert(model_prepared, inplaceFalse) # 6. 保存 torch.save(model_quantized.state_dict(), model_int8.pth)这段代码看着简单但每一步都有讲究。qconfig的选择要和目标硬件匹配选错了不仅没加速反而可能更慢。校准的 batch 数量也不是越多越好10 到 20 个 batch 通常足够关键是这些数据要覆盖真实场景的分布。3.4 逐通道量化为什么比逐张量量化好默认的逐张量量化Per-Tensor对整层用同一个 scale但卷积层的不同输出通道数值分布差异可能很大。逐通道量化Per-Channel给每个通道单独算 scale精度通常能提升不少代价是推理时多一点点开销。在卷积和线性层上我基本都会开逐通道量化实测精度损失能减少一半左右。配置方式是在 qconfig 里指定 observerfrom torch.ao.quantization.observer import MovingAveragePerChannelMinMaxObserver model.qconfig tq.QConfig( activationtq.get_default_qconfig(fbgemm).activation, weightMovingAveragePerChannelMinMaxObserver.with_args( qschemetorch.per_channel_symmetric ) )4. 剪枝与稀疏化把冗余参数真正删掉4.1 剪枝不等于加速这是最大的认知误区很多人以为把权重置零就是剪枝模型就变小变快了。实际上如果你只是把权重设成 0但张量形状没变那计算量一点没减少内存占用也没降。真正能带来加速的剪枝必须配合稀疏计算内核或者结构化剪枝。非结构化剪枝随机把某些权重置零在通用硬件上几乎拿不到加速因为 GPU 的并行计算模式不适合处理不规则稀疏。所以我的经验是要么做结构化剪枝整通道、整头剪掉要么确保你的推理框架支持稀疏张量加速。前者通用性好后者需要特定硬件和框架支持。4.2 结构化剪枝的完整思路结构化剪枝的核心是找到不重要的通道或注意力头然后整块删掉。判断重要性的常见指标有权重的 L1/L2 范数、激活值的统计量、以及基于梯度的敏感度分析。流程一般是训练一个基准模型记录精度对每一层计算通道重要性分数按比例剪掉分数最低的通道微调恢复精度重复 2-4 直到达到目标压缩率这里有个关键细节剪枝率不能一刀切。浅层特征提取层通常对剪枝更敏感深层冗余更多。我一般会给浅层设较低的剪枝率比如 10%深层设较高的比如 40%。一次性把所有层剪到同一个比例精度往往崩得很难看。4.3 剪枝后的微调策略剪枝完必须微调但微调也有讲究。学习率要设得比原始训练小一个数量级否则容易把好不容易保留的结构又破坏掉。另外微调时最好冻结浅层只训练被剪过的深层这样收敛更快也更稳。我实测下来一个 50% 结构化剪枝的模型用原始学习率的十分之一微调 10 个 epoch精度基本能恢复到剪枝前的 98% 以上。注意剪枝和量化可以叠加使用但顺序很重要。一般先剪枝再量化因为剪枝改变了权重分布量化校准需要基于剪枝后的模型来做。反过来先量化再剪枝量化模型的剪枝操作会非常麻烦。5. 算子融合与图优化不花训练成本的白捡收益5.1 算子融合为什么能提速前面诊断部分提到过很多模型的时间不是花在计算上而是花在内存读写上。一个典型的例子是Conv - BatchNorm - ReLU这个组合如果不融合中间结果要写回显存再读出来三次操作三次内存往返。融合之后计算在寄存器或共享内存里一次完成内存访问次数大幅减少。这就是为什么算子融合几乎是零成本、零精度损失的优化手段。5.2 常见的融合模式融合模式收益来源典型场景Conv BN ReLU减少内存往返CNN 主干网络Linear Add合并偏置计算Transformer FFNMatMul Softmax减少中间张量Attention 计算LayerNorm Residual合并归一化与残差Transformer Block这些融合大部分推理框架会自动做但前提是你的模型图能被正确识别。如果你用了大量动态控制流、或者自定义算子融合就可能失效。这时候手动改写模型结构把可融合的部分显式表达出来收益会很明显。5.3 用 TorchScript 和 ONNX 导出时的注意事项图优化的前提是模型能被正确导出成静态图。这里坑特别多。第一torch.jit.trace对控制流不友好如果你的模型里有if判断trace 只会记录实际走过的那条分支。第二ONNX 导出时算子版本要匹配opset 版本选低了某些算子不支持选高了目标推理引擎可能不认。第三导出后一定要用onnxruntime或onnxsim做一遍图简化把冗余的 Identity、Dropout 等节点清掉。import torch import onnx import onnxsim # 导出 ONNX torch.onnx.export( model, dummy_input, model.onnx, opset_version13, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}} ) # 图简化 model_onnx onnx.load(model.onnx) model_simplified, check onnxsim.simplify(model_onnx) onnx.save(model_simplified, model_simplified.onnx)我实测过一个未经简化的 ONNX 模型经过onnxsim处理后节点数能减少 20% 到 30%推理延迟相应下降。这一步几乎没有任何副作用属于必做项。6. 踩坑实录那些让我熬夜排查的优化问题6.1 量化后精度暴跌问题出在校准数据有一次我做一个图像分类模型的 INT8 量化PTQ 之后 top-1 准确率从 78% 掉到了 61%惨不忍睹。排查了半天最后发现是校准数据的问题——我随手用了训练集里随机抽的几百张图但训练集里某个类别的样本特别多导致校准时的激活分布严重偏斜。换成按类别均衡采样的校准集之后精度恢复到 76.5%只掉了 1.5 个点。这个坑的教训是校准数据必须代表真实推理时的输入分布。如果你的线上流量有特定的分布特征校准集就要反映这个特征。别偷懒用训练集随便抽那可能和线上分布差很远。6.2 算子融合失效罪魁祸首是自定义激活函数还有一次我发现模型推理速度比预期慢很多profiler 显示 Conv 和 ReLU 是分开执行的没有融合。查了半天原来是我用了一个自定义的激活函数框架不认识所以融合规则匹配不上。改成标准 ReLU 之后融合立刻生效延迟下降了 15%。这个坑提醒我优化阶段尽量用标准算子。自定义算子虽然灵活但会破坏框架的图优化能力。如果非用不可那就得手动实现融合版本或者接受这部分优化收益的损失。6.3 动态 shape 导致的性能抖动线上服务经常遇到变长输入比如不同长度的文本。如果模型导出时固定了 shape遇到不同长度就得重新编译或 padding前者慢后者浪费算力。我踩过的坑是ONNX 导出时没设dynamic_axes结果线上每条请求的 shape 不一样推理引擎每次都重新做图优化延迟忽高忽低。解决办法是在导出时显式声明动态维度让推理引擎提前做好适配。但要注意动态 shape 会牺牲一部分优化空间所以如果业务上 shape 相对固定还是固定 shape 性能更好。这是一个需要根据实际情况权衡的点。6.4 显存碎片化导致 OOM做批量推理时我遇到过明明显存总量够、但就是 OOM 的情况。原因是频繁申请释放不同大小的张量导致显存碎片化。解决办法有两个一是用内存池很多推理框架自带二是尽量让中间张量的 shape 保持一致减少碎片产生。PyTorch 里可以设置PYTORCH_CUDA_ALLOC_CONF环境变量来调整分配策略export PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128这个参数控制内存块的最大分割粒度设小一点能减少碎片但可能增加分配次数。具体数值要根据模型的实际张量大小来调没有万能值。7. 优化效果的度量与回退机制7.1 建立一套可对比的基准优化最怕的就是感觉快了。你必须有一套可复现的基准测试。我的做法是固定三样东西固定的测试数据集、固定的硬件环境、固定的预热轮数。预热特别重要第一次推理往往包含各种初始化开销不预热测出来的数据没有参考价值。一般预热 10 到 20 轮然后测 100 轮取平均和 P99。度量指标不能只看平均延迟P99 延迟往往才是用户体验的瓶颈。一个平均 50ms 但 P99 达到 500ms 的服务用户会明显感觉到卡顿。所以基准报告里我至少会记录平均延迟、P99 延迟、吞吐量、峰值显存。7.2 精度回归测试不能省每次优化之后必须跑一遍完整的精度评估。我习惯维护一个小型的黄金测试集覆盖各个类别的代表性样本优化前后都跑一遍对比输出差异。如果发现某些样本的输出变化特别大就要深入排查是哪个环节引入的误差。对于量化模型还可以逐层对比量化前后的输出差异定位是哪一层的量化误差最大。PyTorch 提供了逐层对比的工具也可以自己写钩子函数来采集每层输出。7.3 一定要有回退方案优化是有风险的线上出问题时必须能快速回退。我的做法是优化版本和原始版本同时部署通过配置开关切换。一旦监控发现精度或延迟异常立刻切回原始版本。这个机制看起来笨但在关键时刻能救命。我见过太多团队优化上线后出问题手忙脚乱重新部署故障时间被拉得很长。另外优化后的模型文件、配置文件、以及对应的优化脚本都要版本化管理。别出现这个量化模型是用哪个脚本生成的都说不清的情况。8. 不同硬件平台上的优化侧重点8.1 GPU 上的优化重点GPU 算力强但显存带宽是瓶颈所以优化重点是减少内存访问和提升计算密度。量化在 GPU 上的收益主要体现在显存占用下降速度提升要看具体内核支持。TensorRT 这类推理引擎会把融合、量化、内核选择都做掉用起来省心但调优空间也相对受限。我的经验是GPU 上优先用成熟的推理引擎自己手写优化的收益往往不如把引擎用好。8.2 CPU 上的优化重点CPU 上量化收益非常明显因为 INT8 指令如 AVX512-VNNI的吞吐远高于浮点。但 CPU 优化的坑在于不同代际的指令集支持不一样编译时要针对目标平台。另外 CPU 上的线程调度、内存对齐都会影响性能。我一般会用numactl绑定核心减少跨 NUMA 节点的内存访问。8.3 边缘设备上的优化重点边缘设备算力、内存、功耗三重受限优化要更激进。除了量化和剪枝还要考虑算子替换用轻量算子替代重算子、模型结构搜索NAS等。这个领域工具链碎片化严重不同芯片厂商都有自己的编译器和量化工具通用性差。我的建议是尽早确定目标硬件然后围绕它的工具链来做优化别等模型定型了再适配。9. 我个人的几条实操心得做了这么多模型优化项目有几条经验是我反复验证过的分享出来供参考。第一条优化要趁早介入。别等模型训练完了才想优化的事。训练阶段就可以考虑用对量化友好的结构比如用 ReLU 替代某些复杂激活用对剪枝友好的正则化。这些前期投入能让后期优化省很多事。第二条每次只改一个变量。优化手段叠加使用时一定要逐个引入、逐个度量。同时上量化和剪枝出了问题你根本不知道是谁的锅。我习惯的做法是维护一个优化日志记录每一步改了什么、指标变化多少。第三条别迷信论文里的压缩率。论文里说能压缩 10 倍精度不掉那是特定模型特定数据集上的结果。你的模型结构、数据分布、任务难度都不一样照搬参数大概率翻车。所有参数都要在自己的场景里重新验证。第四条优化到一定程度就该停。边际收益递减是必然的。当优化带来的收益已经小于维护成本时就该把精力放到别的地方去了。我见过团队为了再压 5% 的延迟投入几个月结果业务需求早就变了。技术优化要服务于业务目标别本末倒置。最后说一个具体的技巧做量化校准时我会额外保留一批困难样本——就是那些模型原本就预测得不太准的样本。这些样本对量化误差最敏感用它们来验证量化效果比用随机样本严格得多。如果量化后这些困难样本的表现没有明显恶化那整体精度基本就稳了。这个技巧帮我提前发现过好几次潜在的精度问题比上线后才发现要好得多。 模型推理优化实战：量化、剪枝与算子融合的工程化落地
1. 从模型能跑到模型跑得省Model-Optimizer 到底在解决什么做模型部署的人大概都有过这种体验训练阶段一切顺利指标也好看可一旦要把模型塞进实际业务环境问题就全冒出来了。推理延迟高得离谱、显存占用把显卡撑爆、批量请求一上来服务直接雪崩。这时候你会发现训练时那些能跑就行的宽松假设到了生产环境全都不成立。Model-Optimizer 这类工具出现的根本原因就是要把能跑的模型变成跑得省、跑得稳、跑得快的模型。我先把话说清楚Model-Optimizer 不是一个具体的库名而是一类面向模型推理优化的工具集合的统称。它覆盖的工作包括量化、剪枝、算子融合、图优化、内存复用、内核调优等等。你可以把它理解成模型上线前的体检加调理环节——模型本身没病但亚健康状态严重需要一套系统化的手段把它调整到最佳竞技状态。为什么这件事值得单独拿出来讲因为绝大多数团队在模型优化上的投入和收益是严重不成比例的。我见过太多项目训练阶段砸了几十张卡、调了几个月参结果部署时随手一个torch.save加torch.load就上线了推理性能全靠硬件硬扛。等到成本报表出来才发现推理成本是训练成本的十几倍甚至几十倍。模型优化不是锦上添花它是决定一个 AI 项目能不能长期活下去的关键环节。这篇文章适合三类人看一是刚接触模型部署、想知道优化到底在优化什么的工程师二是已经在做推理服务、但性能始终卡在瓶颈上的开发者三是需要为团队做技术选型、想搞清楚各类优化手段适用边界的负责人。我会尽量把原理讲透同时给出可以直接上手操作的步骤和参数让你看完就能在自己的项目里试。需要提前说明的是模型优化没有银弹。每一种手段都是在精度、速度、内存、开发成本之间做权衡。Model-Optimizer 的价值不在于某个单点技术多厉害而在于它提供了一套可组合、可度量、可回退的工程化流程。下面我会从优化前的诊断、核心手段的原理与实操、踩坑排查、到效果验证一层层拆开讲。2. 动手之前先做诊断搞清楚瓶颈到底在哪2.1 为什么不能上来就量化我见过最常见的错误就是一听说量化能提速二话不说先把模型转成 INT8结果精度掉了一大截回头再花大量时间做量化感知训练去补救。这个顺序是反的。正确的做法是先诊断搞清楚你的瓶颈是计算密集、内存带宽受限还是调度开销过大然后对症下药。诊断的核心是三个指标延迟Latency、吞吐Throughput、显存占用Memory Footprint。这三个指标之间往往互相牵制。比如你增大 batch size 能提升吞吐但延迟会上升、显存会吃紧。所以第一步不是优化而是明确你的业务到底更看重哪个。在线交互类服务通常卡延迟离线批处理类任务通常卡吞吐而边缘设备上显存和功耗才是硬约束。2.2 用 Profiler 定位真正的热点光看总延迟没用你得知道时间花在哪了。PyTorch 生态里我常用torch.profiler它能给出每个算子的耗时占比。下面是一段可以直接抄的代码import torch from torch.profiler import profile, ProfilerActivity model MyModel().eval().cuda() dummy_input torch.randn(1, 3, 224, 224).cuda() with profile(activities[ProfilerActivity.CPU, ProfilerActivity.CUDA], record_shapesTrue) as prof: with torch.no_grad(): for _ in range(10): model(dummy_input) print(prof.key_averages().table(sort_bycuda_time_total, row_limit20))跑完之后你会看到一张按 CUDA 耗时排序的算子表。经验上如果前五个算子的耗时加起来超过总时间的 70%那优化重点就非常明确了。常见的几个耗电大户是大矩阵乘法GEMM、卷积、LayerNorm、以及各种 element-wise 操作。element-wise 操作单个看着不起眼但数量一多内存带宽就被吃光了这时候算子融合的收益会非常明显。2.3 区分计算瓶颈和内存瓶颈这一步很多人会忽略但它直接决定你该用哪种优化手段。判断方法很简单看算子的算术强度Arithmetic Intensity也就是每读取一个字节能完成多少次浮点运算。算术强度高的算子比如大 GEMM是计算瓶颈优化方向是降低计算精度量化或换更快的计算内核。算术强度低的算子比如激活函数、逐元素加法是内存带宽瓶颈优化方向是算子融合把多次内存读写合并成一次。我自己的判断习惯是如果 profiler 显示大量时间花在elementwise、copy、contiguous这类操作上那基本可以确定是内存瓶颈优先考虑图优化和算子融合如果时间集中在gemm、conv、attention上那量化带来的收益会更直接。提示诊断阶段一定要用真实输入尺寸和真实 batch size。用torch.randn(1,3,224,224)测出来的结果和线上 batch32 的场景可能完全是两回事优化方向都可能相反。3. 量化收益最大但也最容易翻车的一环3.1 量化的本质是重新映射数值分布量化的核心思想是把原本用 32 位浮点表示的权重和激活值用更低的位宽通常是 INT8来表示。听起来简单但关键在于如何确定映射的缩放因子scale和零点zero point。浮点数能表示的范围很宽但实际模型里的数值往往集中在一个很窄的区间。如果你按理论最大范围去映射那大部分数值都会挤在很少的几个量化格子里精度损失巨大。所以量化的第一步永远是校准Calibration拿一批有代表性的真实数据跑一遍模型统计每一层激活值的实际分布范围据此确定 scale 和 zero point。校准数据的质量直接决定量化效果这一点后面踩坑部分我会详细讲。3.2 训练后量化与量化感知训练怎么选对比维度训练后量化PTQ量化感知训练QAT实现成本低几行代码高需要重新训练精度损失通常 0.5%~2%通常 0.1%~0.5%适用场景对精度不敏感的模型精度敏感、PTQ 掉点严重数据需求几百条校准样本完整训练集耗时分钟级小时到天级我的建议是先用 PTQ 试掉点可接受就直接上掉点严重再考虑 QAT。很多团队一上来就搞 QAT结果发现 PTQ 其实就够了白白浪费了大量算力。判断可接受的标准要结合业务分类任务掉 1% 准确率可能无所谓但检测任务掉 1% mAP 可能就影响召回了。3.3 一个可复现的 PTQ 实操流程以 PyTorch 的量化工具链为例静态量化Static Quantization的完整流程大致如下import torch import torch.quantization as tq # 1. 准备模型并设置为评估模式 model MyModel().eval() # 2. 指定量化配置 model.qconfig tq.get_default_qconfig(fbgemm) # x86 用 fbgemmARM 用 qnnpack # 3. 插入观察器准备量化 model_prepared tq.prepare(model, inplaceFalse) # 4. 用校准数据跑一遍收集激活分布 def calibrate(model, data_loader, num_batches10): with torch.no_grad(): for i, (inputs, _) in enumerate(data_loader): if i num_batches: break model(inputs) calibrate(model_prepared, calib_loader) # 5. 转换为量化模型 model_quantized tq.convert(model_prepared, inplaceFalse) # 6. 保存 torch.save(model_quantized.state_dict(), model_int8.pth)这段代码看着简单但每一步都有讲究。qconfig的选择要和目标硬件匹配选错了不仅没加速反而可能更慢。校准的 batch 数量也不是越多越好10 到 20 个 batch 通常足够关键是这些数据要覆盖真实场景的分布。3.4 逐通道量化为什么比逐张量量化好默认的逐张量量化Per-Tensor对整层用同一个 scale但卷积层的不同输出通道数值分布差异可能很大。逐通道量化Per-Channel给每个通道单独算 scale精度通常能提升不少代价是推理时多一点点开销。在卷积和线性层上我基本都会开逐通道量化实测精度损失能减少一半左右。配置方式是在 qconfig 里指定 observerfrom torch.ao.quantization.observer import MovingAveragePerChannelMinMaxObserver model.qconfig tq.QConfig( activationtq.get_default_qconfig(fbgemm).activation, weightMovingAveragePerChannelMinMaxObserver.with_args( qschemetorch.per_channel_symmetric ) )4. 剪枝与稀疏化把冗余参数真正删掉4.1 剪枝不等于加速这是最大的认知误区很多人以为把权重置零就是剪枝模型就变小变快了。实际上如果你只是把权重设成 0但张量形状没变那计算量一点没减少内存占用也没降。真正能带来加速的剪枝必须配合稀疏计算内核或者结构化剪枝。非结构化剪枝随机把某些权重置零在通用硬件上几乎拿不到加速因为 GPU 的并行计算模式不适合处理不规则稀疏。所以我的经验是要么做结构化剪枝整通道、整头剪掉要么确保你的推理框架支持稀疏张量加速。前者通用性好后者需要特定硬件和框架支持。4.2 结构化剪枝的完整思路结构化剪枝的核心是找到不重要的通道或注意力头然后整块删掉。判断重要性的常见指标有权重的 L1/L2 范数、激活值的统计量、以及基于梯度的敏感度分析。流程一般是训练一个基准模型记录精度对每一层计算通道重要性分数按比例剪掉分数最低的通道微调恢复精度重复 2-4 直到达到目标压缩率这里有个关键细节剪枝率不能一刀切。浅层特征提取层通常对剪枝更敏感深层冗余更多。我一般会给浅层设较低的剪枝率比如 10%深层设较高的比如 40%。一次性把所有层剪到同一个比例精度往往崩得很难看。4.3 剪枝后的微调策略剪枝完必须微调但微调也有讲究。学习率要设得比原始训练小一个数量级否则容易把好不容易保留的结构又破坏掉。另外微调时最好冻结浅层只训练被剪过的深层这样收敛更快也更稳。我实测下来一个 50% 结构化剪枝的模型用原始学习率的十分之一微调 10 个 epoch精度基本能恢复到剪枝前的 98% 以上。注意剪枝和量化可以叠加使用但顺序很重要。一般先剪枝再量化因为剪枝改变了权重分布量化校准需要基于剪枝后的模型来做。反过来先量化再剪枝量化模型的剪枝操作会非常麻烦。5. 算子融合与图优化不花训练成本的白捡收益5.1 算子融合为什么能提速前面诊断部分提到过很多模型的时间不是花在计算上而是花在内存读写上。一个典型的例子是Conv - BatchNorm - ReLU这个组合如果不融合中间结果要写回显存再读出来三次操作三次内存往返。融合之后计算在寄存器或共享内存里一次完成内存访问次数大幅减少。这就是为什么算子融合几乎是零成本、零精度损失的优化手段。5.2 常见的融合模式融合模式收益来源典型场景Conv BN ReLU减少内存往返CNN 主干网络Linear Add合并偏置计算Transformer FFNMatMul Softmax减少中间张量Attention 计算LayerNorm Residual合并归一化与残差Transformer Block这些融合大部分推理框架会自动做但前提是你的模型图能被正确识别。如果你用了大量动态控制流、或者自定义算子融合就可能失效。这时候手动改写模型结构把可融合的部分显式表达出来收益会很明显。5.3 用 TorchScript 和 ONNX 导出时的注意事项图优化的前提是模型能被正确导出成静态图。这里坑特别多。第一torch.jit.trace对控制流不友好如果你的模型里有if判断trace 只会记录实际走过的那条分支。第二ONNX 导出时算子版本要匹配opset 版本选低了某些算子不支持选高了目标推理引擎可能不认。第三导出后一定要用onnxruntime或onnxsim做一遍图简化把冗余的 Identity、Dropout 等节点清掉。import torch import onnx import onnxsim # 导出 ONNX torch.onnx.export( model, dummy_input, model.onnx, opset_version13, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}} ) # 图简化 model_onnx onnx.load(model.onnx) model_simplified, check onnxsim.simplify(model_onnx) onnx.save(model_simplified, model_simplified.onnx)我实测过一个未经简化的 ONNX 模型经过onnxsim处理后节点数能减少 20% 到 30%推理延迟相应下降。这一步几乎没有任何副作用属于必做项。6. 踩坑实录那些让我熬夜排查的优化问题6.1 量化后精度暴跌问题出在校准数据有一次我做一个图像分类模型的 INT8 量化PTQ 之后 top-1 准确率从 78% 掉到了 61%惨不忍睹。排查了半天最后发现是校准数据的问题——我随手用了训练集里随机抽的几百张图但训练集里某个类别的样本特别多导致校准时的激活分布严重偏斜。换成按类别均衡采样的校准集之后精度恢复到 76.5%只掉了 1.5 个点。这个坑的教训是校准数据必须代表真实推理时的输入分布。如果你的线上流量有特定的分布特征校准集就要反映这个特征。别偷懒用训练集随便抽那可能和线上分布差很远。6.2 算子融合失效罪魁祸首是自定义激活函数还有一次我发现模型推理速度比预期慢很多profiler 显示 Conv 和 ReLU 是分开执行的没有融合。查了半天原来是我用了一个自定义的激活函数框架不认识所以融合规则匹配不上。改成标准 ReLU 之后融合立刻生效延迟下降了 15%。这个坑提醒我优化阶段尽量用标准算子。自定义算子虽然灵活但会破坏框架的图优化能力。如果非用不可那就得手动实现融合版本或者接受这部分优化收益的损失。6.3 动态 shape 导致的性能抖动线上服务经常遇到变长输入比如不同长度的文本。如果模型导出时固定了 shape遇到不同长度就得重新编译或 padding前者慢后者浪费算力。我踩过的坑是ONNX 导出时没设dynamic_axes结果线上每条请求的 shape 不一样推理引擎每次都重新做图优化延迟忽高忽低。解决办法是在导出时显式声明动态维度让推理引擎提前做好适配。但要注意动态 shape 会牺牲一部分优化空间所以如果业务上 shape 相对固定还是固定 shape 性能更好。这是一个需要根据实际情况权衡的点。6.4 显存碎片化导致 OOM做批量推理时我遇到过明明显存总量够、但就是 OOM 的情况。原因是频繁申请释放不同大小的张量导致显存碎片化。解决办法有两个一是用内存池很多推理框架自带二是尽量让中间张量的 shape 保持一致减少碎片产生。PyTorch 里可以设置PYTORCH_CUDA_ALLOC_CONF环境变量来调整分配策略export PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128这个参数控制内存块的最大分割粒度设小一点能减少碎片但可能增加分配次数。具体数值要根据模型的实际张量大小来调没有万能值。7. 优化效果的度量与回退机制7.1 建立一套可对比的基准优化最怕的就是感觉快了。你必须有一套可复现的基准测试。我的做法是固定三样东西固定的测试数据集、固定的硬件环境、固定的预热轮数。预热特别重要第一次推理往往包含各种初始化开销不预热测出来的数据没有参考价值。一般预热 10 到 20 轮然后测 100 轮取平均和 P99。度量指标不能只看平均延迟P99 延迟往往才是用户体验的瓶颈。一个平均 50ms 但 P99 达到 500ms 的服务用户会明显感觉到卡顿。所以基准报告里我至少会记录平均延迟、P99 延迟、吞吐量、峰值显存。7.2 精度回归测试不能省每次优化之后必须跑一遍完整的精度评估。我习惯维护一个小型的黄金测试集覆盖各个类别的代表性样本优化前后都跑一遍对比输出差异。如果发现某些样本的输出变化特别大就要深入排查是哪个环节引入的误差。对于量化模型还可以逐层对比量化前后的输出差异定位是哪一层的量化误差最大。PyTorch 提供了逐层对比的工具也可以自己写钩子函数来采集每层输出。7.3 一定要有回退方案优化是有风险的线上出问题时必须能快速回退。我的做法是优化版本和原始版本同时部署通过配置开关切换。一旦监控发现精度或延迟异常立刻切回原始版本。这个机制看起来笨但在关键时刻能救命。我见过太多团队优化上线后出问题手忙脚乱重新部署故障时间被拉得很长。另外优化后的模型文件、配置文件、以及对应的优化脚本都要版本化管理。别出现这个量化模型是用哪个脚本生成的都说不清的情况。8. 不同硬件平台上的优化侧重点8.1 GPU 上的优化重点GPU 算力强但显存带宽是瓶颈所以优化重点是减少内存访问和提升计算密度。量化在 GPU 上的收益主要体现在显存占用下降速度提升要看具体内核支持。TensorRT 这类推理引擎会把融合、量化、内核选择都做掉用起来省心但调优空间也相对受限。我的经验是GPU 上优先用成熟的推理引擎自己手写优化的收益往往不如把引擎用好。8.2 CPU 上的优化重点CPU 上量化收益非常明显因为 INT8 指令如 AVX512-VNNI的吞吐远高于浮点。但 CPU 优化的坑在于不同代际的指令集支持不一样编译时要针对目标平台。另外 CPU 上的线程调度、内存对齐都会影响性能。我一般会用numactl绑定核心减少跨 NUMA 节点的内存访问。8.3 边缘设备上的优化重点边缘设备算力、内存、功耗三重受限优化要更激进。除了量化和剪枝还要考虑算子替换用轻量算子替代重算子、模型结构搜索NAS等。这个领域工具链碎片化严重不同芯片厂商都有自己的编译器和量化工具通用性差。我的建议是尽早确定目标硬件然后围绕它的工具链来做优化别等模型定型了再适配。9. 我个人的几条实操心得做了这么多模型优化项目有几条经验是我反复验证过的分享出来供参考。第一条优化要趁早介入。别等模型训练完了才想优化的事。训练阶段就可以考虑用对量化友好的结构比如用 ReLU 替代某些复杂激活用对剪枝友好的正则化。这些前期投入能让后期优化省很多事。第二条每次只改一个变量。优化手段叠加使用时一定要逐个引入、逐个度量。同时上量化和剪枝出了问题你根本不知道是谁的锅。我习惯的做法是维护一个优化日志记录每一步改了什么、指标变化多少。第三条别迷信论文里的压缩率。论文里说能压缩 10 倍精度不掉那是特定模型特定数据集上的结果。你的模型结构、数据分布、任务难度都不一样照搬参数大概率翻车。所有参数都要在自己的场景里重新验证。第四条优化到一定程度就该停。边际收益递减是必然的。当优化带来的收益已经小于维护成本时就该把精力放到别的地方去了。我见过团队为了再压 5% 的延迟投入几个月结果业务需求早就变了。技术优化要服务于业务目标别本末倒置。最后说一个具体的技巧做量化校准时我会额外保留一批困难样本——就是那些模型原本就预测得不太准的样本。这些样本对量化误差最敏感用它们来验证量化效果比用随机样本严格得多。如果量化后这些困难样本的表现没有明显恶化那整体精度基本就稳了。这个技巧帮我提前发现过好几次潜在的精度问题比上线后才发现要好得多。