1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的排序模型上。当时线上推理延迟死活压不下去单次请求要 180ms业务方要求砍到 80ms 以内。我一开始的想法很朴素——换更小的模型、砍特征、降 batch结果 AUC 掉了两个点业务方直接不干了。后来才意识到问题不在模型本身而在于我从来没认真对待过优化器这一层。这里说的 Model-Optimizer不是指 Adam、SGD 那种训练时的参数更新算法而是指一整套围绕模型推理与部署阶段的优化工具链和策略集合。它要干的事情很明确在不显著损失精度的前提下把模型跑得更快、更小、更省资源。解决的痛点也很直接——训练出来的模型往往又大又慢直接上线成本高得离谱。适合看这篇内容的人大概有三类一是做模型部署和推理服务的工程师天天被延迟和显存折磨二是算法同学模型训完了不知道怎么落地三是刚入行的同学想搞清楚模型优化这四个字背后到底有哪些具体手段。我会尽量把每个环节的为什么讲透而不是甩一堆名词。先说结论模型优化不是单一技术而是一条流水线。量化、剪枝、蒸馏、算子融合、图优化、KV Cache 管理、批处理调度这些手段各管一段组合起来才能把模型从能跑变成跑得好。下面我按实际项目里的推进顺序一层层拆开讲。2. 优化方案的整体设计与选型逻辑2.1 先搞清楚瓶颈在哪别上来就优化我踩过最大的坑就是一上来就想着量化。结果折腾了两周发现真正的瓶颈根本不在计算而在数据预处理和内存拷贝上。所以任何优化动作之前必须先做 profiling。常用的 profiling 手段有这么几类算子级耗时分析看每个算子的时间占比找出 top 10 的耗时算子。PyTorch 可以用torch.profilerTensorRT 有自带的 profiler。显存占用分析区分是权重占显存、激活值占显存还是 KV Cache 占显存。这三者的优化手段完全不同。端到端延迟分解把请求拆成预处理 → 推理 → 后处理三段看哪段是大头。很多线上服务其实是预处理拖后腿。我一般会先跑一个 baseline把这三类数据都记下来形成一张体检表。没有这张表后面所有优化都是盲人摸象。2.2 优化手段的优先级排序在拿到体检表之后我会按下面的优先级来排优先级手段适用场景典型收益P0算子融合 图优化几乎所有模型延迟降 20%~40%P0量化INT8/FP16计算密集型模型延迟降 30%~50%显存减半P1KV Cache 优化自回归生成类模型显存降 40%吞吐翻倍P1批处理与调度高并发在线服务吞吐提升 2~5 倍P2剪枝冗余参数多的模型参数量降 30%~70%P2蒸馏有充足训练资源小模型逼近大模型效果这个排序的逻辑是先做无损或低损的优化再做有损的优化。算子融合和图优化基本不损失精度量化在 INT8 下通常掉点可控剪枝和蒸馏则需要重新训练成本高、风险大放在后面。2.3 为什么不能只靠一种手段很多人以为量化是万能药其实不是。我做过一个实验一个 BERT-base 的文本分类模型单独做 INT8 量化延迟从 45ms 降到 28ms单独做算子融合从 45ms 降到 32ms两个一起做降到 19ms。收益不是简单相加而是有协同效应的——量化后的算子融合空间更大融合后的图又更容易做量化。反过来如果只做剪枝不做量化剪枝带来的稀疏性在很多硬件上根本吃不到加速因为通用 GPU 对稀疏矩阵的支持有限。所以优化手段要成组使用并且要考虑目标硬件的特性。3. 核心细节解析与实操要点3.1 量化从 FP32 到 INT8 的关键细节量化是模型优化里收益最直接的手段但也是最容易掉点的环节。核心原理是把 FP32 的权重和激活值映射到 INT8 的整数区间用整数运算替代浮点运算。量化的关键参数是scale缩放因子和 zero_point零点。公式很简单real_value (int8_value - zero_point) * scale但难点在于怎么确定 scale。业界主流有两种方案对称量化zero_point 固定为 0scale max(abs(min), abs(max)) / 127。适合权重分布对称的场景。非对称量化zero_point 可调scale (max - min) / 255。适合激活值分布偏斜的场景。我实测下来权重用对称量化激活值用非对称量化是掉点最少的组合。因为权重通常近似零均值分布而激活值经过 ReLU 之后全是非负的分布明显偏斜。还有一个坑是per-tensor 还是 per-channel。per-tensor 是整个张量共用一个 scaleper-channel 是每个通道一个 scale。per-channel 精度更高但计算开销略大。我的经验是权重量化用 per-channel激活量化用 per-tensor这是精度和性能的平衡点。注意量化校准集的选择非常关键。校准集必须能代表真实推理时的数据分布一般取 500~1000 个样本就够。我见过有人拿训练集的前 100 条做校准结果线上掉点严重因为训练集前 100 条往往是同一类样本分布严重偏斜。3.2 算子融合为什么能省时间算子融合的原理是把多个小算子合并成一个大算子减少 kernel launch 次数和中间结果的显存读写。举个最常见的例子Conv BatchNorm ReLU。在未融合的情况下这三个算子要启动三次 kernel中间结果要写回显存再读出来。融合之后一个 kernel 搞定中间结果留在寄存器里省了两次显存往返。我做过统计在一个 ResNet-50 上Conv-BN-ReLU 这种模式出现了 53 次。每次省两次显存往返按每次 0.1ms 算光这一项就能省 10ms 左右。常见的融合模式包括Conv BN ReLU/ReLU6Linear Bias ActivationAdd LayerNormTransformer 里高频出现MatMul Add残差连接实操上TensorRT 和 ONNX Runtime 都内置了融合规则你只要把模型导出成 ONNX它们会自动做。但要注意有些融合需要你手动调整图结构比如把 BN 的参数提前 fold 进 Conv 的权重里这样融合才能生效。3.3 KV Cache自回归模型的显存杀手做 LLM 推理的同学对 KV Cache 一定不陌生。自回归生成时每生成一个 token都要把之前所有 token 的 Key 和 Value 缓存下来避免重复计算。但缓存会随序列长度线性增长显存很快就爆了。以一个 7B 模型为例假设 32 层、32 个 head、head_dim 128、FP16 存储单个 token 的 KV Cache 大小是2 (K和V) * 32 (层) * 32 (head) * 128 (dim) * 2 (字节) 512 KB序列长度 2048 时单个请求的 KV Cache 就是 1GB。并发 10 个请求10GB 显存就没了。这就是为什么 LLM 服务的显存总是紧张。优化 KV Cache 的主流手段有MQA/GQA多个 head 共享同一份 K/V直接把 cache 缩小几倍。这是模型结构层面的改动需要重新训练。PagedAttention把 KV Cache 分页管理像操作系统管理内存一样减少碎片。vLLM 就是靠这个把吞吐提升了好几倍。KV Cache 量化把 FP16 的 cache 量化到 INT8显存直接减半掉点通常很小。滑动窗口 / 稀疏注意力只保留最近 N 个 token 的 cache适合长文本场景。我实测下来PagedAttention KV Cache INT8 量化是性价比最高的组合显存能降到原来的 1/3 左右精度几乎无损。3.4 批处理与调度吞吐的放大器在线服务里单请求延迟和整体吞吐往往是一对矛盾。批处理能提升吞吐但会增加单请求延迟。怎么平衡是调度策略的核心。常见的调度策略静态批处理攒够 N 个请求一起推理。实现简单但延迟不可控。动态批处理设定一个时间窗口比如 10ms窗口内的请求一起处理。延迟可控吞吐也不错。连续批处理请求不等整批完成谁先完成谁先走新请求随时插入。这是 vLLM、TensorRT-LLM 的核心能力吞吐最高。我做过对比测试在同样的硬件上静态批处理吞吐是 100 req/s动态批处理能到 250 req/s连续批处理能到 600 req/s。差距非常明显。但连续批处理的实现复杂度也最高需要管理每个请求的 KV Cache 生命周期、处理请求的插入和退出。如果团队没有足够的工程能力建议先用动态批处理稳定之后再上连续批处理。4. 完整实操流程与关键环节实现4.1 环境准备与工具链搭建我一般用这套工具链# 基础环境 pip install torch2.1.0 onnx1.15.0 onnxruntime-gpu1.17.0 pip install tensorrt8.6.1 pip install transformers4.36.0 pip install vllm0.2.7 # 用于 LLM 推理工具选型的逻辑ONNX作为中间格式几乎所有框架都支持导出通用性最好。ONNX Runtime用于快速验证量化效果它的量化工具链最成熟。TensorRT用于最终部署性能最好但只支持 NVIDIA 硬件。vLLM专门做 LLM 推理连续批处理和 PagedAttention 开箱即用。提示TensorRT 的版本和 CUDA 版本强绑定装之前一定要查兼容性表。我踩过 CUDA 12.1 配 TensorRT 8.5 的坑编译直接报错折腾了一下午。4.2 模型导出与图优化以 PyTorch 模型为例导出 ONNX 的标准流程import torch import torch.onnx model.eval() dummy_input torch.randn(1, 3, 224, 224).cuda() torch.onnx.export( model, dummy_input, model.onnx, opset_version13, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}, output: {0: batch_size}} )几个关键点opset_version 选 13 或更高低版本不支持一些新算子。dynamic_axes 一定要设否则 batch size 被写死线上没法动态批处理。导出前必须 model.eval()否则 BN 和 Dropout 的行为不对。导出之后用 ONNX Runtime 的图优化工具做一轮优化from onnxruntime.transformers import optimizer optimized_model optimizer.optimize_model( model.onnx, model_typebert, num_heads12, hidden_size768 ) optimized_model.save_model_to_file(model_optimized.onnx)这一步会自动做算子融合、常量折叠、冗余节点消除。实测下来光这一步就能降 15%~25% 的延迟。4.3 量化实操从校准到部署ONNX Runtime 的量化流程分三步from onnxruntime.quantization import quantize_dynamic, QuantType # 动态量化最简单不需要校准集 quantize_dynamic( model_optimized.onnx, model_int8.onnx, weight_typeQuantType.QInt8 )动态量化只量化权重激活值在推理时动态量化精度损失小但加速有限。如果要榨干性能得用静态量化from onnxruntime.quantization import quantize_static, CalibrationDataReader class MyCalibrationReader(CalibrationDataReader): def __init__(self, calibration_data): self.data calibration_data self.index 0 def get_next(self): if self.index len(self.data): return None batch self.data[self.index] self.index 1 return {input: batch} quantize_static( model_optimized.onnx, model_int8_static.onnx, CalibrationDataReader(calibration_data), quant_formatQuantFormat.QDQ, per_channelTrue, activation_typeQuantType.QUInt8, weight_typeQuantType.QInt8 )参数选择的理由QuantFormat.QDQQuantize-Dequantize 格式兼容性最好几乎所有推理引擎都支持。per_channelTrue权重量化用 per-channel精度更高。activation_typeQUInt8激活值用无符号 INT8因为 ReLU 之后都是非负的。weight_typeQInt8权重用有符号 INT8因为权重有正有负。量化完之后一定要做精度对比。我一般会跑一个验证集对比量化前后的指标。如果掉点超过 1%就要考虑混合精度量化——把敏感层保留 FP16其他层用 INT8。4.4 部署与性能验证最后一步是部署到 TensorRT 或者 vLLM。以 TensorRT 为例trtexec --onnxmodel_int8_static.onnx \ --saveEnginemodel.engine \ --int8 \ --fp16 \ --workspace4096 \ --minShapesinput:1x3x224x224 \ --optShapesinput:8x3x224x224 \ --maxShapesinput:32x3x224x224关键参数--int8 --fp16同时开启TensorRT 会自动选择最优精度。--workspace4096给 4GB 显存做优化空间太小会导致某些优化策略无法启用。min/opt/maxShapes定义动态 shape 的范围optShapes 是最常见的 batch sizeTensorRT 会针对它做重点优化。编译完之后用 trtexec 做性能测试trtexec --loadEnginemodel.engine --shapesinput:8x3x224x224 --iterations1000看三个指标吞吐throughput、延迟latency、显存占用。和 baseline 对比确认优化效果。5. 常见问题与排查技巧实录5.1 量化后精度掉得厉害怎么办这是最高频的问题。排查思路按下面的顺序来现象可能原因排查方法解决方案整体掉点校准集分布不对对比校准集和验证集的分布重新选校准集覆盖各类样本某类样本掉点严重该类样本激活值范围异常单独统计该类样本的激活分布对该类层用混合精度首层或末层掉点输入输出对精度敏感逐层对比量化前后输出首末层保留 FP16掉点随机量化误差累积逐层量化定位敏感层敏感层用 FP16我的经验是90% 的量化掉点问题都出在校准集上。校准集一定要覆盖真实场景的各种输入不能只用一类样本。5.2 优化后延迟没降反升这种情况通常是优化手段和目标硬件不匹配。比如在 CPU 上做 INT8 量化很多 CPU 对 INT8 的支持并不好反而因为量化/反量化的开销导致变慢。小模型做算子融合小模型本身 kernel launch 开销占比就低融合收益有限反而可能因为融合规则不优导致变慢。batch size 太小做连续批处理连续批处理的调度开销在低并发下反而拖后腿。排查方法很简单逐个手段单独测试确认每个手段都有正收益再组合。不要一次性全上出了问题根本定位不到。5.3 显存不够用怎么排查显存问题要分清楚是哪个部分占的import torch # 查看当前显存占用 print(torch.cuda.memory_allocated() / 1024**3, GB) print(torch.cuda.memory_reserved() / 1024**3, GB) # 查看显存快照 torch.cuda.memory._dump_snapshot(memory_snapshot.pickle)memory_allocated是实际使用的显存memory_reserved是 PyTorch 向系统申请的显存。如果两者差距大说明有显存碎片可以用torch.cuda.empty_cache()释放。如果是 KV Cache 占太多就上 PagedAttention 或者 KV Cache 量化。如果是激活值占太多就减小 batch size 或者用梯度检查点推理时一般用不到。如果是权重占太多就量化或者剪枝。5.4 实操避坑清单最后整理一份我踩过的坑供参考导出 ONNX 时忘记设 dynamic_axes导致线上只能固定 batch size白白浪费批处理能力。量化校准集用了训练集的前 N 条分布严重偏斜线上掉点 3 个点。TensorRT 的 workspace 设太小某些优化策略静默失效性能没达到预期。连续批处理没做请求超时控制长请求把短请求堵死P99 延迟爆炸。KV Cache 没做上限控制单个超长请求把显存吃光整个服务 OOM。优化后没做回归测试某个边缘 case 精度崩了上线后才发现。注意任何优化上线前必须做完整的回归测试包括精度对比、延迟对比、显存对比、异常 case 测试。优化带来的性能收益不能以牺牲稳定性为代价。6. 不同场景下的优化策略组合6.1 CV 模型量化 算子融合是主力CV 模型ResNet、YOLO 这类结构规整算子类型集中量化收益非常明显。我的标准组合是导出 ONNX做图优化静态量化到 INT8per-channel 权重TensorRT 编译开启 INT8 FP16动态 batchoptShapes 设成线上最常见的 batch size这套组合下来ResNet-50 在 T4 上能从 45ms 降到 8ms 左右吞吐提升 5 倍以上。6.2 NLP 模型KV Cache 连续批处理是关键NLP 模型BERT、LLM的瓶颈往往在显存和调度上。我的组合是导出 ONNX做图优化量化到 INT8注意 attention 层可能敏感LLM 场景用 vLLM开启 PagedAttention 和连续批处理KV Cache 量化到 INT8这套组合下来7B 模型在 A100 上能支持 50 并发吞吐比朴素实现高 10 倍以上。6.3 推荐模型特征工程和预处理优化不能忽视推荐模型的瓶颈经常不在模型本身而在特征预处理和 embedding 查表上。我的经验是先做端到端 profiling确认瓶颈段特征预处理用 GPU 加速避免 CPU-GPU 频繁拷贝Embedding 表用 FP16 存储显存减半模型部分做量化和算子融合推荐模型的优化预处理优化往往比模型优化收益更大。我见过一个案例光把特征预处理从 CPU 挪到 GPU端到端延迟就降了 40%。7. 我个人的一些实操体会做模型优化这几年最大的体会是优化不是一锤子买卖而是持续迭代的过程。模型在变、数据在变、硬件在变优化策略也要跟着变。另一个体会是不要迷信工具要理解原理。TensorRT、ONNX Runtime 这些工具确实强大但它们只是把优化规则固化了。当遇到工具覆盖不到的场景时只有理解原理才能自己动手改。最后分享一个小技巧建立自己的优化 checklist 和 benchmark 集。每次优化都按 checklist 走一遍用 benchmark 集验证效果。这样既能保证不遗漏环节又能积累数据形成自己的经验库。我现在这个 checklist 已经积累了 30 多条每次新项目都能省不少时间。模型优化这条路坑多但收益也大。希望这些经验能帮你少走点弯路。