企业官网建设流程全解析

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(), lr=2e-5, # 微调场景一般给得比较小 betas=(0.9, 0.999), eps=1e-8, weight_decay=0.01 ) scheduler = CosineAnnealingLR( optimizer, T_max=num_epochs, eta_min=1e-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 之后的学习率衰减策略，我个人的对比经验如下：

如果你是做微调任务，我强烈建议用 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），它们分别解决显存效率和训练稳定性两个问题。

混合精度训练的基本原理是：在计算前向和反向传播时用 FP16（16 位浮点数）代替 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_norm=1.0 时，如果梯度范数是 5.0，梯度向量会被整体缩小到原值的 1/5，方向不变：

torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.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 如何选择

训练阶段的优化做得再好，推理引擎选错，一切都是白搭。推理引擎的作用是把训练框架里的模型，转换并优化成特定硬件上运行最充分的执行图——比如把多个算子融合、把临时变量分配得更合理、并利用硬件的特殊指令集。

常用的推理引擎各有侧重：

如果你在 NVIDIA GPU 上做推理，不考虑 TensorRT 基本等于把性能红利白白丢掉。TensorRT 的优化能力来源几点：一是算子融合，它能将常见的 Conv+BN+ReLU 等连续小算子融合成一个大的融合算子，减少内核启动开销；二是自动选择最优的 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 在 batch=1 时算力利用率极低，GPU 的 SIMT 架构特性决定了只要存在并行度，它能同时处理很多样本。一个合理做法是：请求先进入一个队列，凑到一定数量再一次性推理，提高 GPU 利用率，这个策略叫动态批处理。

Batch 大小不一定越大越好。过大的 batch 会把单次请求的延迟拉高，因为你需要等更多请求凑齐；而过小又浪费算力。我常用的策略是设一个最大 batch（比如 32）和一个最大等待时间（比如 20ms），两个条件任意一个满足都触发推理。这样短请求有低延迟保障，长请求也能通过等待拿到吞吐。

还有输入预处理。我在很多项目里发现，团队只优化推理模型本身，却忽略了 CPU 端的解码、缩放、归一化，这些操作往往是耗时大户。特别是做图片业务的，解码一张高分辨率图片的时间可能比跑一次推理还长。我的建议是把预处理尽量推到 GPU 上做，或者至少用多线程流水线把它和推理并发执行，别让 CPU 端的串行处理卡住整个流程。实战里我把预处理从 CPU 换成 GPU 后，端到端延迟降了差不多 30%，这种优化比你去抠算子的耗时管用得多。

4.3 端侧与边缘设备的专属考量

如果你的模型最终要跑在手机、嵌入式设备上，推理优化会更严苛。这些设备没有 GPU 级别的算力，内存也极其有限。这时不仅要量化到 INT8（很多端侧已经用 FP16/INT8/INT4 混合精度），还得考虑算子是否被端侧推理框架覆盖——比如安卓端的 NNAPI、TFLite、MNN，iOS 端的 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 用一张表理清优化手段的适用顺序

把前面讲的三种优化层级和多个手段放在一起，我习惯用一张决策表来确定"当前项目该做哪一步"。这个表是我反复踩坑后总结出来的，现在每次接手新项目都会先对照它做规划。

举个例子：如果你当前模型训练得不好，loss 一直下不来，就别上来急着做量化——那属于把房子盖歪了再想着刷墙。先回到训练阶段把优化器调对，学习率调稳，确保模型本身的收敛质量是能上线的，然后再去谈压缩和加速。我一个朋友的项目，前期模型精度卡了整整两周，最后发现是优化器选了普通 Adam 且学习率太高，换 AdamW 加 warmup 后一天就把指标刷上去了，这种基本功的价值比任何花活都大。

6.2 一次优化的完整工作流参考

结合前面的所有内容，我推荐一个标准工作流，可以直接套用到大多数 AI 项目上：

第一步，基线测量。先把原始模型在目标硬件上的延迟、显存、精度三个指标测出来，记录下来。没有基线就做优化，后面对比不出收益，等于白干。

第二步，做精度与速度问题归类。对照上面的决策表判断当前项目的瓶颈到底是什么类型。如果瓶颈是训练，调整优化器和学习率；如果瓶颈是部署，考虑量化、剪枝、蒸馏；如果瓶颈是并行度，调整 batch 策略。

第三步，逐步实施优化，每做一步重新测量三项指标。不要一次性做多种优化，否则出了问题你完全不知道怎么归因。顺序一般建议先把模型精度和结构调到合适状态，再做量化，最后调推理引擎和部署参数。

第四步，验证业务目标。最终优化是否成功的判断标准不是模型大小或者 FLOPs 降了多少，而是业务指标：比如线上推荐点击率是否保持、OCR 识别准确率是否达标、延迟是否满足 SLA。不要在指标好看但业务受损的优化方案上死磕。

7. 关于 Model-Optimizer 的几点个人体会

这篇文章的核心是我在几个大项目里反复折腾出来的真实经验，不是教科书式的理论堆砌。我现在接手新模型时，习惯带着一个问题去思考：这个项目到底卡在哪。是模型学不进去、还是结构太大装不进内存、还是跑得太慢满足不了并发？三个问题对应的优化策略完全不同，想清楚这一点，你就不会盲目地去调那些花哨的参数了。

写到最后分享一个小习惯：优化前后都要留好完整的日志。这里的日志不只是代码日志，而是训练曲线、显存占用记录、延迟测试报告、精度评估记录，全部归档。很多优化手段的收益不是立刻就能看出来的，可能过了两周、换了数据分布之后才显现出差异。有了完整记录，你就能分析出到底哪次改动带来了收益，哪次改动其实是有害的，然后逐步沉淀出你自己的优化方法论。这些经验比任何调参技巧都值钱。下次遇到模型上线前资源告急的情况，希望你能从容地梳理问题、分步优化，而不是一上来就陷入"多快好省"的焦虑里。