1. 先把概念说透模型优化到底在优化什么1.1 三种完全不同却常被混为一谈的优化我在跟同行聊天时经常发现一个问题大家嘴里说的模型优化往往根本不是同一件事。有人指的是训练阶段的优化比如调优化器、改学习率、加速收敛有人指的是模型结构上的压缩比如把 70 亿参数的模型砍到 20 亿还保持效果还有人指的是线上部署层面的加速比如把 FP32 的权重转成 INT8、用推理引擎把延迟从 50ms 打到 15ms。这三件事在工作流里全都被叫做模型优化但它们的工具链、评估指标、甚至团队人员组成都完全不同。训练优化侧重的是收敛得更快更稳你关心的曲线是 loss 和验证集指标结构压缩侧重的是参数更少但能力保住你盯的是压缩率和精度差部署优化侧重的是在特定硬件上跑得更快更省你测量的是延迟、吞吐和显存峰值。这三者当然有交集但如果你一开始没想清楚自己到底在做哪一层后面很容易做出看起来很辛苦却没有收益的调整。我做过的很多失败案例根源都是没区分清楚我到底在优化什么。1.2 为什么优化越来越绕不开部署场景前几年大家提模型优化第一反应是调参炼丹谁 loss 曲线漂亮谁厉害。但现在风向已经彻底变了。大规模模型动不动几十上百 GB训练出来只是第一步真正要落地到业务里还得过推理这一关。我见过不少团队模型在 PyTorch 环境里跑得好好的往生产环境一放遇到显存不够、并发上不去、延迟超时一堆问题这才回头来研究优化——其实这一步应该在模型还没定型的时候就开始做。所以我对模型优化的理解是以最终业务指标为目标在不明显损伤准确率的前提下把模型变得更快、更小、更容易部署。这可能涉及训练策略的调整也可能涉及模型结构的改造还可能涉及推理框架的选择。一个成熟的优化工程师三块多少都要懂一点。本文就把这三块放一起来聊按实际工作流顺序走一遍该避的坑也一并说出来。1.3 谁适合看这份内容如果你手头正在做一个深度学习项目模型已经训练得差不多但部署时遇到资源瓶颈或者你刚入门机器学习想厘清优化器选了又换到底在折腾什么又或者你在做模型服务化想知道量化和剪枝究竟是走流程还是真有收益——这篇文章大概率能帮到你。我会尽量避免空谈理论讲到的每个方案都有对应的实操场景和参数说明你可以直接拿去对照自己的项目做调整。2. 训练阶段优化先把模型养好后面才谈压缩和加速2.1 优化器选型背后的逻辑与默认参数陷阱训练阶段的优化很多人第一个想到的就是换个优化器。确实优化器选型是影响收敛速度最直接的因素之一。现在主流的选择基本就是 SGD、Adam、AdamW 这三类其中 AdamW 几乎成了 PyTorch 预训练模型和微调任务的事实标准。先说原因Adam 系优化器最大的优势是自适应学习率。它对每个参数单独计算梯度的动量一阶矩和二动量二阶矩天然能应付梯度尺度差异巨大的场景——这在 Transformer 结构里尤其明显。我给过一个非常直观的类比SGD 就像一个不看路况、只按固定步幅走路的人路平的时候走得还行遇到陡坡就一脚踏空Adam 则像一个边走边调整步幅的人地形陡峭、梯度大的地方自动放小步幅地形平坦、梯度小的地方自动加大步幅。Transformer 每个 block 里不同参数对应的梯度差异可能相差十几个数量级用 SGD 你必须小心翼翼找到一个照顾所有参数的学习率而 Adam 几乎不需要这种精细的手工调参。但 Adam 也有它的毛病权重衰减的处理方式不严谨。传统的 Adam 实现会在梯度更新之后再额外把权重乘以一个 (1 - weight_decay * lr) 的系数。这个做法的问题在于权重衰减项和动量项耦合在一起梯度大时动量也大再叠加衰减容易让模型正则化失控最终导致泛化性能下降。AdamW 把 weight_decay 从梯度更新逻辑里剥离出来单独对参数做衰减就像把油和水在程序上分开处理一样实验效果普遍优于 Adam这也是 Hugging Face、PyTorch 官方微调脚本里默认用 AdamW 的原因。下面给一个我常用的 PyTorch 微调配置import torch from torch.optim import AdamW from torch.optim.lr_scheduler import CosineAnnealingLR optimizer AdamW( model.parameters(), lr2e-5, # 微调场景一般给得比较小 betas(0.9, 0.999), eps1e-8, weight_decay0.01 ) scheduler CosineAnnealingLR( optimizer, T_maxnum_epochs, eta_min1e-6 )注意这里 lr 给的是 2e-5而不是论文里常见的 3e-4。很多同学从预训练任务转微调时忘了把学习率调小结果一跑起来 loss 直接起飞。微调的核心逻辑是在已有能力基础上小幅修正而不是从零开始学学习率必须低一个到两个数量级。这里有个很常被忽视的点betas和eps在大多数情况下不需要动但如果你训练的不稳定性特别高可以尝试把betas(0.9, 0.999)改成(0.95, 0.999)。增大一阶动量系数相当于给梯度更新加了一层更重的惯性滤波器能压掉高频噪声代价是收敛速度变慢。我在训练小 batch 的密集模型时用过这个改动稳定性确实有明显提升。至于eps默认的 1e-8 偏小如果训练中频繁出现数值异常可以调到 1e-6 甚至 1e-5让分母更大一些避免除以接近零的数导致梯度爆炸。2.2 学习率调度Warmup 与衰减策略的微观考量学习率调度是整个训练优化里最容易被低估的部分。很多人调了好几版 loss 曲线都压不下来最后发现是学习率衰减节奏不对。先讲 Warmup。它的逻辑很简单训练刚开始时模型参数处于随机状态梯度方向非常不稳定这时候不应该直接用大学习率暴冲。正确的做法是把学习率从接近 0 缓慢线性上升到目标值这个过程白皮书上叫 warmup steps。为什么要缓慢上升而不是一步到位我自己的理解是训练初期的 loss landscape 像一个剧烈震荡的水面你不知道哪个方向是真正下坡的方向。学习率如果一开始就很大相当于每次都在乱冲容易把参数冲进一个不好的局部洼地后面再训练也拉不回来。做过 NLP 任务的都知道不加 warmup 的 Transformer 微调几乎必然出现 loss 前期剧烈波动甚至 NaN。Warmup 之后的学习率衰减策略我个人的对比经验如下策略适用场景优点缺点Step Decay长时间训练简单直观方便对照实验衰减点附近精度波动明显Cosine Annealing中短时间训练10-50 epoch变化平滑收敛稳定超长训练时收益不明显Linear Decay预训练风格与 warmup 搭配自然后期学习率过低收敛偏慢OneCycle小数据集快速迭代前期快后期慢收敛速度快参数敏感需仔细调 max_lr如果你是做微调任务我强烈建议用 Warmup Linear Decay 的组合这个方案在 Hugging Face 的 Trainer 里也是默认实现。它之所以稳定是因为微调任务训练数据量通常不会非常大而线性衰减能在训练进入尾声时把学习率压得很低让模型在极小步长下慢慢打磨权重往往能挤出最后几个点的精度提升。我做过对比同一个模型Warmup Cosine 比直接固定学习率最终精度能高 0.5 到 1 个点这个差距在榜单竞争上的分量你懂的。还有一个很多人踩过的坑scheduler 的调用时机。如果用了 PyTorch 的CosineAnnealingLR必须等每个 epoch 结束再调用scheduler.step()。如果写反了在每步 batch 迭代里调用学习率会衰减得过快等于在训练中途就进入停滞状态。我早期经常在这个细节上翻车训练出来的模型明显欠拟合检查了半天才发现是 scheduler 和 optimizer 的 step 顺序搞反了。排错方法是用一个小脚本在训练前打印前 20 个 step 的学习率肉眼看一下数值变化是否符合预期。2.3 混合精度和梯度裁剪上手就能见效的两个技巧除了优化器和学习率调度训练阶段还有两个高频操作混合精度训练AMP和梯度裁剪Gradient Clipping它们分别解决显存效率和训练稳定性两个问题。混合精度训练的基本原理是在计算前向和反向传播时用 FP1616 位浮点数代替 FP32这样显存占用直接减半同时因为 GPU 的 Tensor Core 对 FP16 有专门优化计算速度也能提升。但 FP16 的动态范围比 FP32 小很多容易出现数值溢出的情况。主流做法是梯度累积补偿用 FP16 做前向反向但把梯度累积到 FP32 的 master 副本上更新权重时用 FP32 执行。这也是 PyTorch 的torch.cuda.amp工具在内部做的事scaler torch.cuda.amp.GradScaler() for batch in train_loader: with torch.cuda.amp.autocast(): loss model(batch) loss loss_fn(loss, targets) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update() optimizer.zero_grad()代码里那个 GradScaler 承担的是动态缩放工作——它会监测梯度数值太小时放大、太大时缩小防止 FP16 下梯度下溢。我的经验是如果你用了混合精度却不加 GradScaler小梯度全部被权重中的尘埃吃掉训练几乎不收敛这是新手最容易犯的错误。另外注意scaler.scale(loss).backward()的反向传播是经过缩放后的梯度所以clip_grad_norm_也要在缩放后的梯度上做否则梯度裁剪的阈值设置会失去意义。梯度裁剪则是把反向传播得到的梯度范数限制在一个上限之内。它针对的问题是当 batch 中某个样本产生异常大的梯度时权重会被冲得很远造成 loss 陡增甚至 NaN。梯度裁剪会把整个梯度向量的 L2 范数限制在 max_norm 之内给定 max_norm1.0 时如果梯度范数是 5.0梯度向量会被整体缩小到原值的 1/5方向不变torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0)这个技巧对 RNN 和 Transformer 这类深度结构尤其有效。我推荐在训练初期就把裁剪加上不会带来明显副作用。阈值设在 0.1 到 1.0 之间都算常见怎么选一个经验法则是看训练前几个 batch 的梯度范数统计量把 max_norm 设在梯度范数分布的中位数附近就可以在压掉极端值和保留正常更新力度之间取得平衡。3. 结构压缩三件套剪枝、蒸馏、量化3.1 剪枝权重稀疏化与通道裁剪的实际操作模型训练到后期大量参数实际上处于冗余状态。剪枝的基本思路就是评估每个参数或每个通道对最终输出的贡献度把贡献度低的参数置零或删除然后对模型进行微调恢复精度。参数级剪枝的优点是不改变结构、实现简单坏处是它产生的是稀疏矩阵如果硬件和推理框架不针对稀疏结构做优化实际加速效果非常有限。在工程场景里我更推荐做结构化剪枝也就是把整个 channel 直接剪掉。比如一个卷积层原本输出 64 个 channel剪枝后只剩 32 个 channel这样前后两层的连接数直接减半内存和计算量都实打实降下来和硬件配合良好——因为 GPU 的矩阵运算本质上是稠密乘法通道数减了乘法的外沿就小了。剪枝最关键的环节是评估通道的重要性。简单方案是直接用权重绝对值之和作为重要性指标取低者剪掉。更稳一点的做法是统计通道输出对后续 loss 的影响比如通过梯度计算得到敏感度但计算量大、工程代价高。我实际工作中经常用偏经验的方式先用权重 L1 范数做一轮粗剪剪完微调观察 test accuracy 的下降幅度如果下降超过硬线比如 1 个点就减少剪枝比例。在 ResNet 这类模型上保留 50% 到 70% 的通道往往就能保持原模型 95% 以上的精度剩下就是微调力量的展示。剪枝里面最典型的误操作是一次性剪到底。因为剪枝率越高模型越小但精度下降越快。一个合适的做法是多轮迭代剪枝比如先剪掉 20% 通道微调恢复精度再在剩余结构上继续评估重要性再剪 20%微调重复直到精度掉到阈值边缘。这和渐进式学习有点像每一步只做小幅手术模型有机会自我修复损伤。3.2 知识蒸馏让小模型吸收大模型的判断力如果剪枝是从结构上删减那蒸馏就是从输出上迁移。知识蒸馏的核心思路训练一个小模型student让它去拟合一个大模型teacher的输出。大模型经过大量数据学习后它的输出往往包含着类别之间的微妙关系这种信息比原始标签更富。蒸馏的关键在于软标签。原始训练数据的标签是 one-hot比如猫、狗、车的概率是 1、0、0。但大模型输出的概率分布往往是 (0.6, 0.3, 0.1) 这种形式其中的 0.3 表达了这个东西跟狗有那么点像。对训练小模型来说这种软性信息比 one-hot 标签包含更多学习信号。就像你教小孩认动物你告诉他这是猫不是狗效果远不如带他去观察猫和狗在体型、叫声、习性上的差异。实现蒸馏要做两件事第一用大模型跑一遍训练集保存它的 logits第二让小模型的训练 loss 同时包含对 one-hot 标签的损失和对老师 logits 的损失其中后者乘以一个温度参数 T 和权重 λ。温度的作用是让概率分布更平滑或更尖锐——T 越大分布越平滑学生学到的是类别间的相似性而非绝对差异。我最常用的公式loss (1 - λ) * CE(student_logits, hard_label) λ * T² * KL_div(softmax(student_logits / T), softmax(teacher_logits / T))这里乘了一个 T²是因为 softmax 的梯度会被缩放 1/T乘回去是为了保持梯度量级正常。这个细节很多论文里写得隐晦我自己第一次实现时因为漏掉了 T²蒸馏 loss 被压得几乎不起作用差点以为方法本身有问题。蒸馏在工程里往往是最后一根救命稻草。我在不少上线项目里用蒸馏把小模型提升了 2-3 个点成本几乎可以忽略因为训练逻辑上只是在原来 loss 函数上多加一项。有一种更进阶的做法是自蒸馏先训练一个大模型用它的输出去蒸馏一个相同或更小的模型这个流程在不少知识蒸馏框架里被封装成了现成的类但你最好理解内部机制再动手。3.3 量化把连续精度砍成离散精度从 FP32 到 INT8量化和剪枝、蒸馏走的是完全不同的路它不动结构而是把参数原有的取值范围映射到更小的取值空间。最常见的做法是从 FP32 量化到 INT8即每个参数只保留 256 个可能的取值。参数少了自然显存占用少、计算速度快因为 INT8 运算在 GPU 和 CPU 上都有专门的加速硬件Tensor Core、AVX512 等。量化方法分两类训练后量化PTQ和量化感知训练QAT。PTQ 最省事——模型训练完用少量校准数据集跑前向统计每一层激活值的分布确定缩放比例和零点然后直接把权重从 FP32 转成 INT8。这个方法几乎不改训练代码特别适合快速上线。缺点是如果激活值分布极不均匀量化误差会被放大精度损失明显。QAT 则是在训练过程中模拟量化过程——前向传播时把权重假装量化成 INT8反向传播时仍然用 FP32 更新权重。这样模型在训练过程中就学会适应量化误差最终精度一般比 PTQ 高出不少。代价是要改训练代码训练时间也长一些。实际工作中的经验是先做 PTQ如果精度损失在 1 个点以内就直接上线如果超了再上 QAT。很多团队一上来就上 QAT分析下来发现其实根本没必要白白浪费了几天训练时间。只有当模型部署到强算力受限的边缘设备上、比如手机或嵌入式板子QAT 的精度收益才显得非常重要。另外要注意量化的目标不只是权重激活值的量化往往更关键因为激活值在不同输入下分布差异大校准数据集的选择对 PTQ 效果影响极大我建议校准数据一定要覆盖真实业务场景的分布。4. 推理层面的优化才是真正跑在钱上的环节4.1 推理引擎选型ONNX Runtime、TensorRT 与 OpenVINO 如何选择训练阶段的优化做得再好推理引擎选错一切都是白搭。推理引擎的作用是把训练框架里的模型转换并优化成特定硬件上运行最充分的执行图——比如把多个算子融合、把临时变量分配得更合理、并利用硬件的特殊指令集。常用的推理引擎各有侧重引擎适配硬件优点缺点适用场景ONNX RuntimeCPU/GPU生态成熟、算子覆盖广、转换简单性能上限中等快速落地、跨平台TensorRTNVIDIA GPU性能顶尖、量化支持好转换流程繁琐、动态 shape 支持差GPU 高吞吐线上服务OpenVINOIntel CPU/GPUIntel 硬件优化深入非 Intel 平台支持弱Intel 服务器部署TFLite/CoreML移动端适配手机 NPU/GPU算子覆盖受限端侧推理如果你在 NVIDIA GPU 上做推理不考虑 TensorRT 基本等于把性能红利白白丢掉。TensorRT 的优化能力来源几点一是算子融合它能将常见的 ConvBNReLU 等连续小算子融合成一个大的融合算子减少内核启动开销二是自动选择最优的 kernel 实现三是支持 INT8 量化和层间融合。我现在团队里部署 GPU 服务TensorRT 引擎相比 ONNX Runtime 默认能快 30% 到 50%这个差距在高并发场景下就是实打实的服务器成本差异。以 TensorRT 为例一个最简单的流程import tensorrt as trt # 简化流程实际还需要处理 dynamic shape、calibration 等细节 TRT_LOGGER trt.Logger(trt.Logger.INFO) builder trt.Builder(TRT_LOGGER) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, TRT_LOGGER) with open(model.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) # 1GB workspace plan builder.build_serialized_network(network, config)这里的 workspace 大小限制对显存和速度影响很大。工作区限制小了算子融合空间不足性能上不去工作区限制大了构建时显存爆掉。我的方法是从 512MB 开始往上试每次构建后用benchmark脚本测延迟找到速度和显存的平衡点。此外 TensorRT 对动态 shape 支持不够友好如果你的服务输入尺寸不固定建议在构建引擎时把 min/max/optimize 三个 profile 配好否则运行时会反复 re-build 引擎那个耗时是灾难级别的。4.2 动态 Batch 与预处理流水线被低估的延迟热点推理阶段还有一个容易被忽略的细节动态 Batch。在很多线上服务里请求是一次一个进来的每次只跑一个 batch 的推理。但绝大多数 GPU 在 batch1 时算力利用率极低GPU 的 SIMT 架构特性决定了只要存在并行度它能同时处理很多样本。一个合理做法是请求先进入一个队列凑到一定数量再一次性推理提高 GPU 利用率这个策略叫动态批处理。Batch 大小不一定越大越好。过大的 batch 会把单次请求的延迟拉高因为你需要等更多请求凑齐而过小又浪费算力。我常用的策略是设一个最大 batch比如 32和一个最大等待时间比如 20ms两个条件任意一个满足都触发推理。这样短请求有低延迟保障长请求也能通过等待拿到吞吐。还有输入预处理。我在很多项目里发现团队只优化推理模型本身却忽略了 CPU 端的解码、缩放、归一化这些操作往往是耗时大户。特别是做图片业务的解码一张高分辨率图片的时间可能比跑一次推理还长。我的建议是把预处理尽量推到 GPU 上做或者至少用多线程流水线把它和推理并发执行别让 CPU 端的串行处理卡住整个流程。实战里我把预处理从 CPU 换成 GPU 后端到端延迟降了差不多 30%这种优化比你去抠算子的耗时管用得多。4.3 端侧与边缘设备的专属考量如果你的模型最终要跑在手机、嵌入式设备上推理优化会更严苛。这些设备没有 GPU 级别的算力内存也极其有限。这时不仅要量化到 INT8很多端侧已经用 FP16/INT8/INT4 混合精度还得考虑算子是否被端侧推理框架覆盖——比如安卓端的 NNAPI、TFLite、MNNiOS 端的 CoreML。一个重要但容易被忽略的点是端侧模型不一定要完整部署。很多时候可以采取端侧小模型 云端大模型的混合策略简单样本端侧直接出结果复杂样本上传云端让大模型处理。这样既节省了端侧的内存和功耗又能保证整体效果不差。我在图片分类的项目里这么做了之后端侧推理频率降了一大半因为简单类别根本不需要消耗大模型用户体验也更好。做这个方案的关键是设计一个置信度阈值策略比如端侧对每个样本输出一个置信度分分高直接返回分低再上传云端。这个阈值设计需要反复测试目标是让端侧承担 70% 的流量云端只处理最难的 30%。5. 高频踩坑与排查案例实录5.1 优化后精度骤降先别急着归咎于量化损失我遇到好几次用户跑来说量化后精度崩了结果一查根本不是量化的问题而是推理引擎里的算子行为和训练框架不一致。特别是 LayerNorm、Attention 这些算子在 CPU 和 GPU 上处理极小数值时方式可能不一样。视觉模型还好NLP 模型对这种极小的数值差异非常敏感因为句子的语义边界往往就落在 logits 的微小差异里。排查思路分几步第一步做一致性测试用同一个输入分别喂给原始 PyTorch 模型和优化后的模型比对输出 logits 的差异。如果差异在 1e-3 级别那是正常的数值误差如果差异到了 1e-1 级别就得看是不是某些算子被错误替换或者量化比例设置不对。第二步做分层比对把网络分成多个段逐段输出中间结果对比原始模型和优化模型的差异出现在哪一层基本就定位到问题层了。很多工具链提供 per-layer 的 dump 功能别嫌麻烦这个步骤在有数值问题时几乎是唯一高效的定位方式。5.2 显存占用一直降不下来可能是静态分配惹的祸有个案例我印象特别深模型剪枝后参数减少了一半结果显存占用却几乎没变化。客户百思不得其解怀疑剪枝是不是没生效。实际原因是推理框架尤其是 CUDA 相关的推理框架在初始化时会一次性分配一块很大的静态内存池之后推理仅仅在这个池里复用内存。所以看显存占用看到的是峰值需求而不是平均需求。当模型变小只要输入 shape 不变峰值需求可能没降多少。想真正降低显存占用可以从三件事里选一件做减少最大 batch size、降低输入分辨率、或者改用更紧凑的模型结构。如果只想精确看模型本身的显存消耗可以用torch.cuda.max_memory_allocated()这类 API逐步测量各阶段的内存峰值找出真正的隐形炸弹到底在哪一层。很多时候显存大头不在模型权重而在中间激活值特别是超长序列的 NLP 模型内存消耗曲线几乎跟序列长度线性相关那这种场景你需要考虑的是输入截断和梯度检查点而不是模型结构剪枝。5.3 优化目标错位别让 FLOPs 骗了你最后说一个比较容易被忽视也很重要的点FLOPs 只是理论计算量不代表实际速度。模型 A 的 FLOPs 比模型 B 小一半但在你的具体硬件上A 的速度反而更慢这种情况经常发生。原因很复杂算子的并行度、内存带宽、缓存命中率、是否使用了硬件加速指令都会影响真实推理时间。我经历过一个典型的案例把 ResNet50 换成 MobileNet 结构FLOPs 降了将近 4 倍但在老旧的 GPU 上反而更慢。原因在于 MobileNet 大量使用了 depthwise 卷积这种算子并行度远低于普通卷积在部分硬件上没有得到专门优化执行效率反而更低。在 GPU 上算得快慢不仅仅取决于计算量还取决于内存访问模式和指令流水线利用率。所以我的建议是做了任何模型结构或推理方案优化后必须在目标硬件上做 A/B 测试测真实延迟和吞吐而不是只盯着 FLOPs 或者论文里给的数据。本地快不算快部署环境里快才算数。6. 一个完整的 Model-Optimizer 决策框架6.1 用一张表理清优化手段的适用顺序把前面讲的三种优化层级和多个手段放在一起我习惯用一张决策表来确定当前项目该做哪一步。这个表是我反复踩坑后总结出来的现在每次接手新项目都会先对照它做规划。项目状态第一优先级第二优先级第三优先级训练收敛慢优化器选型 学习率调度梯度裁剪混合精度显存不够训练混合精度梯度检查点减少 batch size模型太大无法部署量化PTQ优先剪枝蒸馏推理延迟高分析预处理耗时推理引擎切换动态 Batch端侧资源紧张结构调整QAT 量化端云协同举个例子如果你当前模型训练得不好loss 一直下不来就别上来急着做量化——那属于把房子盖歪了再想着刷墙。先回到训练阶段把优化器调对学习率调稳确保模型本身的收敛质量是能上线的然后再去谈压缩和加速。我一个朋友的项目前期模型精度卡了整整两周最后发现是优化器选了普通 Adam 且学习率太高换 AdamW 加 warmup 后一天就把指标刷上去了这种基本功的价值比任何花活都大。6.2 一次优化的完整工作流参考结合前面的所有内容我推荐一个标准工作流可以直接套用到大多数 AI 项目上第一步基线测量。先把原始模型在目标硬件上的延迟、显存、精度三个指标测出来记录下来。没有基线就做优化后面对比不出收益等于白干。第二步做精度与速度问题归类。对照上面的决策表判断当前项目的瓶颈到底是什么类型。如果瓶颈是训练调整优化器和学习率如果瓶颈是部署考虑量化、剪枝、蒸馏如果瓶颈是并行度调整 batch 策略。第三步逐步实施优化每做一步重新测量三项指标。不要一次性做多种优化否则出了问题你完全不知道怎么归因。顺序一般建议先把模型精度和结构调到合适状态再做量化最后调推理引擎和部署参数。第四步验证业务目标。最终优化是否成功的判断标准不是模型大小或者 FLOPs 降了多少而是业务指标比如线上推荐点击率是否保持、OCR 识别准确率是否达标、延迟是否满足 SLA。不要在指标好看但业务受损的优化方案上死磕。7. 关于 Model-Optimizer 的几点个人体会这篇文章的核心是我在几个大项目里反复折腾出来的真实经验不是教科书式的理论堆砌。我现在接手新模型时习惯带着一个问题去思考这个项目到底卡在哪。是模型学不进去、还是结构太大装不进内存、还是跑得太慢满足不了并发三个问题对应的优化策略完全不同想清楚这一点你就不会盲目地去调那些花哨的参数了。写到最后分享一个小习惯优化前后都要留好完整的日志。这里的日志不只是代码日志而是训练曲线、显存占用记录、延迟测试报告、精度评估记录全部归档。很多优化手段的收益不是立刻就能看出来的可能过了两周、换了数据分布之后才显现出差异。有了完整记录你就能分析出到底哪次改动带来了收益哪次改动其实是有害的然后逐步沉淀出你自己的优化方法论。这些经验比任何调参技巧都值钱。下次遇到模型上线前资源告急的情况希望你能从容地梳理问题、分步优化而不是一上来就陷入多快好省的焦虑里。
