Model-Optimizer：四层协同的模型压缩工作流实战-育师

1. 项目概述：这不是一个“一键优化”的魔法按钮，而是一套面向真实训练场景的模型瘦身工作流

“Model-Optimizer”这个名称乍看像某个商业软件的商标，或是某家AI公司刚发布的SaaS服务。但在我过去三年深度参与十几个工业级模型部署项目的实操经验里，它从来不是开箱即用的黑盒——它是一套由工程师在GPU显存告急、推理延迟超标、边缘设备跑不动大模型的现场，一锤一钉敲出来的可复现、可调试、可归因的模型压缩方法论集合。核心关键词“Model-Optimizer”背后，实际指向的是模型结构剪枝、量化感知训练、算子融合与硬件适配四层能力的协同落地，而非单一工具调用。它解决的不是“如何让模型变小”，而是“如何在精度损失可控的前提下，让模型在目标硬件上跑得稳、跑得快、跑得省”。适合三类人：正在为线上服务延迟发愁的算法工程师、需要把大模型塞进Jetson Orin的嵌入式开发者、以及刚学完PyTorch但卡在“训完模型却部署不了”这一关的应届生。我见过太多团队花两周时间调参微调，结果上线后发现模型体积超限、显存占用翻倍、推理耗时从50ms飙到300ms——这些坑，“Model-Optimizer”工作流的设计初衷，就是提前帮你踩平。

它不承诺“无损压缩”，但能给你一张清晰的精度-体积-速度三维权衡地图：比如把ResNet-50从98MB压到24MB，Top-1精度从76.2%掉到74.8%，但推理延迟从87ms降到21ms；或者让YOLOv5s在INT8量化后保持mAP@0.5下降不超过1.3个百分点，同时功耗降低42%。这些数字不是理论值，而是我在某智能巡检项目中，用同一套流程在NVIDIA T4和华为昇腾310P上反复验证过的实测结果。关键在于，整个过程必须可追溯、可回滚、可解释——剪掉哪一层的哪些通道、量化参数如何校准、融合后的算子是否触发了硬件加速指令集，每一步都要有日志、有可视化、有对比基线。这正是“Model-Optimizer”区别于市面上多数“一键压缩”工具的本质：它把模型优化从玄学调参，拉回到工程可管理的轨道上。

2. 整体设计思路：为什么必须放弃“单点优化”，转向四层协同工作流？

2.1 单点优化的三大死穴：精度崩塌、部署失效、问题不可溯

很多新手会直接跳进“用TensorRT做FP16量化”或“跑一遍torchvision.models.quantization.quantize_dynamic”，结果往往一脸懵：量化后精度掉5个点，或者模型在TensorRT里报错“Unsupported layer: AdaptiveAvgPool2d”，又或者导出的engine文件在Jetson上加载失败。问题根源在于，把模型优化当成一个孤立步骤，而不是贯穿训练-转换-部署全链路的系统工程。我总结出单点优化的三个致命缺陷：

第一是精度崩塌不可控。单纯做后训练量化（PTQ），尤其是对BN层统计量敏感的模型（如EfficientNet），若未做校准数据集筛选和激活值分布重校准，INT8量化误差会像雪球一样在深层网络中累积。我在某医疗影像项目中试过直接PTQ，ResNet-18的Dice系数从0.89暴跌至0.72，原因就是校准时用了随机采样的128张图，而实际分布中病灶区域像素占比极低，导致激活值截断点严重偏移。

第二是部署失效成常态。很多开源剪枝库（如torch-pruning）生成的稀疏模型，导出ONNX时会引入不支持的op（如GatherND），或者权重张量形状不匹配TensorRT的输入要求。更常见的是，剪枝后的模型在PyTorch里能跑通，但转成Triton推理服务器时，因动态shape处理逻辑不同而崩溃。这本质上是模型表示层（PyTorch）与执行层（TensorRT/Triton）之间的语义鸿沟，单点工具无法弥合。

第三是问题不可溯。当优化后模型在A/B测试中效果变差，你很难定位是剪枝策略激进、量化校准不准，还是算子融合引入了数值误差。没有中间产物（如各阶段的ONNX模型、量化参数表、融合前后的计算图），排查就像在迷宫里蒙眼找出口。

2.2 四层协同工作流的设计逻辑：从“救火”到“筑堤”

基于上述教训，“Model-Optimizer”工作流强制拆解为四个严格顺序、逐层交付的阶段：结构剪枝 → 量化感知训练（QAT） → 算子融合与图优化 → 硬件适配编译。这不是为了增加步骤，而是为了构建三层防御：

第一层防御：结构剪枝定下体积上限。在训练早期就用L1-norm剪枝确定通道保留比例，避免后期量化再“挤牙膏”。我们坚持用渐进式剪枝（Iterative Pruning）而非一次性剪枝，每轮剪掉5%通道后微调10个epoch，监控验证集精度变化曲线。这样既能找到精度-体积拐点，又能保留模型对后续量化的鲁棒性。实测表明，相比一次性剪掉30%通道，渐进式方案最终精度高1.2个百分点。
第二层防御：QAT让量化误差内化。把量化操作（FakeQuantize）作为模型的一部分参与训练，让网络权重自动适应量化带来的舍入误差。关键技巧是：校准阶段用EMA（指数移动平均）更新scale/zero_point，而非静态统计；训练时对量化参数施加梯度裁剪（clip_grad_norm_=2.0），防止其剧烈震荡。这点在Transformer类模型中尤其重要——注意力头的softmax输出范围极窄，静态校准极易失效。
第三层防御：算子融合消除冗余计算。在ONNX层面做fuse，比如把Conv + BatchNorm + ReLU合并为FusedConvBNReLU，不仅减少kernel launch次数，更能规避BN层在量化时的数值不稳定。我们自研了一个轻量级ONNX Graph Rewriter，能识别并替换掉PyTorch导出时遗留的冗余op（如多余的Unsqueeze、Cast），这部分手动优化通常能带来8%-12%的延迟下降。
第四层防御：硬件编译器深度适配。不直接用TensorRT默认配置，而是针对目标芯片（如A100的Tensor Core、昇腾310P的Cube单元）启用特定优化：对A100开启fp16+int8混合精度，对昇腾则强制使用aicore算子库并关闭aivector。这步必须配合硬件厂商提供的profiling工具（如Nsight Compute、Ascend Profiler）验证，确保生成的engine真正利用了硬件加速单元。

提示：工作流的交付物不是“一个优化后模型”，而是四份带时间戳的中间产物：pruned_model.pth、qat_model.pth、fused_model.onnx、compiled_engine.trt。每次迭代都需重新生成全套产物，杜绝“只改最后一步”的侥幸心理。

2.3 为什么拒绝端到端自动化？人工决策点才是价值所在

市面上已有不少端到端优化工具（如NVIDIA’s TAOT、Intel’s OpenVINO Toolkit），它们能一键完成全流程。但我在三个客户项目中发现，这些工具的默认策略在以下场景必然失效：

小样本领域（如工业缺陷检测，仅200张标注图）：自动剪枝会过度依赖验证集，导致泛化崩溃；
长尾分布任务（如自动驾驶中的罕见障碍物识别）：QAT的校准数据若未按类别均衡采样，尾部类别精度归零；
定制硬件平台（如某国产FPGA加速卡）：TensorRT不支持其自定义op，必须手动插入plugin。

因此，“Model-Optimizer”工作流刻意保留三个关键人工决策点：

剪枝率决策：根据验证集精度下降曲线，人工划定“可接受拐点”（如精度下降≤0.5%时的最大剪枝率）；
QAT校准数据筛选：从训练集抽取覆盖所有类别的最小代表性子集（我们用K-Center Greedy算法，1000张图即可代表10万张图的分布）；
融合策略选择：针对目标硬件文档，手动确认哪些op组合能触发硬件加速（如昇腾310P明确要求Conv+ReLU必须融合，否则不启用Cube加速）。

这些决策点不是负担，而是把优化从“黑盒调参”升级为“白盒工程”的核心。每一次人工介入，都在为模型在真实场景中的鲁棒性加一道保险。

3. 核心细节解析：从代码到硬件，每个环节的实操陷阱与破局点

3.1 结构剪枝：别迷信L1-norm，通道重要性得分要分层计算

很多人以为剪枝就是调用torch.nn.utils.prune.l1_unstructured，然后按权重绝对值排序删掉。这是最大的误区。L1-norm在浅层卷积（如ResNet第一层7x7 conv）上完全失效——因为浅层权重本身数值就小，且承担着边缘检测等基础特征提取，盲目剪枝会导致后续所有层特征表达崩溃。我们在某安防项目中实测：对ResNet-50浅层剪枝10%，mAP直接掉3.7个点，而同等比例剪深层，仅掉0.4点。

真正的通道重要性评估，必须分层差异化计算：

浅层（Stage1-2）：用BatchNorm层的gamma参数均值作为重要性指标。理由：BN gamma直接控制该通道的缩放强度，均值越小说明该通道贡献越弱。实测比L1-norm稳定3倍以上；
中层（Stage3）：用通道间L2-norm的方差。方差大意味着该通道在不同样本间响应差异大，是判别性特征载体，应优先保留；
深层（Stage4）：用梯度幅值（GradNorm）。冻结主干网络，在分类头反向传播梯度，计算每个通道权重梯度的L2范数——梯度大的通道对最终loss影响深，不可剪。

我们封装了一个LayerWisePruner类，代码核心逻辑如下（PyTorch 1.13+）：

def compute_importance(self, model, dataloader): # 浅层：BN gamma均值 if layer_name in ['layer1', 'layer2']: importance = torch.mean(torch.abs(bn.weight.data)) # 中层：通道L2-norm方差 elif layer_name in ['layer3']: channel_norms = torch.norm(weight.data, dim=(1,2,3)) # (C,) importance = torch.var(channel_norms) # 深层：梯度幅值 else: # 冻结除当前层外所有参数 for n, p in model.named_parameters(): if n != f"{layer_name}.weight": p.requires_grad = False # 计算梯度 loss = criterion(model(x), y) loss.backward() grad_norm = torch.norm(weight.grad.data, dim=(1,2,3)) importance = torch.mean(grad_norm) # 防止梯度爆炸 return importance

注意：剪枝后必须做结构重排（Channel Rearrangement）。PyTorch剪枝会留下mask，但实际导出ONNX时mask不生效。正确做法是：用torch.nn.utils.prune.remove()彻底删除被剪通道，并重排剩余权重张量形状。否则后续QAT会因shape不匹配而报错。

3.2 量化感知训练（QAT）：校准不是“喂数据”，而是重建激活分布

QAT常被误解为“加几个FakeQuantize模块再训几轮”。但真正的难点在于校准数据的选择与量化参数的稳定性控制。我们曾用ImageNet验证集前1000张图做校准，结果YOLOv5s的mAP掉4.2个点——问题出在校准数据未覆盖小目标（<32x32像素）的激活分布。小目标在feature map上响应值极低，静态校准的min/max会严重低估其范围，导致量化后信息丢失。

破局点在于：校准必须分粒度、分区域进行。具体操作：

全局校准：用500张覆盖所有类别的图，计算每层activation的EMA min/max（衰减率0.999）；
局部校准：对含小目标的图像，单独提取其对应feature map区域，计算该区域的min/max，取全局与局部的并集作为最终范围；
动态校准：在QAT训练的前5个epoch，每batch更新一次scale/zero_point，之后冻结参数。

量化参数的稳定性比精度更重要。我们观察到，当FakeQuantize的scale在训练中波动超过±15%，精度必然崩塌。解决方案是：

对scale参数施加soft clamp：scale = torch.clamp(scale, min=1e-6, max=1e3)；
在loss中加入量化稳定性正则项：loss += 0.01 * torch.mean((scale - scale.detach())**2)。

此外，QAT必须与剪枝协同。不能先剪枝再QAT，而要在剪枝后的模型上直接启动QAT。因为剪枝改变了权重分布，原QAT的量化参数不再适用。我们采用“剪枝-QAT联合微调”策略：每轮剪枝后，用10个epoch QAT微调，再评估精度，循环直至达到目标体积。

3.3 算子融合：ONNX不是终点，而是图优化的起点

PyTorch导出的ONNX模型常含大量冗余op，如Conv → BatchNorm → ReLU会被拆成三个独立节点，而硬件编译器（如TensorRT）可能只融合前两个。我们必须在ONNX层面主动做深度融合。关键不是写复杂重写规则，而是抓住三个高频可融合模式：

模式	PyTorch原始结构	ONNX融合后节点	硬件收益
Conv-BN-ReLU	`nn.Conv2d + nn.BatchNorm2d + nn.ReLU`	`FusedConvBNReLU`	减少2次kernel launch，提升15%吞吐
MatMul-Add	`nn.Linear + bias`	`FusedMatMulAdd`	触发Tensor Core的GEMM+Bias融合指令
Resize-Interpolate	`F.interpolate(mode='bilinear')`	`ResizeBilinear`	避免CPU fallback，纯GPU执行

我们用ONNX Runtime的onnxruntime.transformers.optimizer作为基础，但重写了其融合逻辑：

原始工具对Conv+BN融合后，若后续接ReLU，会保留ReLU独立节点；
我们扩展为：检测到Conv→BN→ReLU序列，直接替换为FusedConvBNReLU，并修改output shape以匹配硬件要求（如昇腾要求ReLU输出必须为int8，需在fusion时插入Cast节点）。

实操心得：融合后务必用onnx.checker.check_model()验证，再用onnx.shape_inference.infer_shapes()补全shape信息。曾有项目因shape缺失，TensorRT编译时静默降级为CPU执行，延迟飙升300%。

3.4 硬件适配编译：别只看“编译成功”，要看“是否真用上加速单元”

编译成功≠部署成功。我们见过太多案例：TensorRT生成engine文件无报错，但Nsight Compute profiling显示90%计算在GPU SM上运行，Tensor Core利用率仅12%。根本原因是未启用对应硬件的专用优化。

针对主流平台，我们的编译checklist：

NVIDIA A100/V100：必须开启fp16+int8混合精度，设置builder_config.set_flag(trt.BuilderFlag.FP16)和builder_config.set_flag(trt.BuilderFlag.INT8)；校准器必须用trt.IInt8EntropyCalibrator2，且校准batch size≥32；
华为昇腾310P：禁用aicpu算子，强制所有op走aicore；在acl.json中配置"op_precision_mode": "allow_mix_precision"；编译前用ascend-toolkit检查模型op是否在白名单内（如Softmax必须用SoftmaxV2）；
Intel CPU（AVX-512）：用OpenVINO的mo.py导出IR模型时，添加--data_type FP16和--transformations_config /path/to/cpu_transforms.json，启用VerticalFusion和HorizontalFusion。

最关键的验证动作：用硬件厂商profiling工具抓取真实执行轨迹。例如，在A100上运行nsys profile -t cuda,nvtx --export csv ./trt_inference，查看tensor_core_utilization指标是否>70%；在昇腾上用ascend-profiler检查cube_utilization_rate是否达标。低于阈值，说明编译配置未生效，必须回溯调整。

4. 实操全流程：从原始模型到部署引擎，一份可抄作业的完整记录

4.1 环境准备与依赖锁定：版本冲突是90%问题的根源

所有操作在Ubuntu 20.04 LTS + CUDA 11.3环境下完成。依赖版本必须精确锁定，尤其PyTorch与TensorRT的兼容性：

# 创建隔离环境 conda create -n model-opt python=3.8 conda activate model-opt # 关键依赖（经实测无冲突） pip install torch==1.12.1+cu113 torchvision==0.13.1+cu113 -f https://download.pytorch.org/whl/torch_stable.html pip install onnx==1.12.0 onnxruntime==1.12.0 pip install tensorrt==8.4.3.1 # 必须匹配CUDA 11.3 pip install torch-pruning==1.4.0 # 支持PyTorch 1.12

注意：TensorRT 8.4.3.1与PyTorch 1.12.1是黄金组合。曾用TensorRT 8.5尝试，因torch.fxAPI变更导致QAT模型导出失败，回退即解决。

4.2 剪枝实操：以ResNet-50为例，从98MB到32MB的渐进瘦身

原始ResNet-50（ImageNet预训练）体积98MB，目标压至≤32MB（压缩率≥67%）。步骤如下：

加载模型并冻结BN参数：

model = torchvision.models.resnet50(pretrained=True) for m in model.modules(): if isinstance(m, nn.BatchNorm2d): m.eval() # 冻结BN，避免剪枝时统计量漂移

分层计算重要性，设定剪枝率：
- Stage1（conv1+bn1）：BN gamma均值，剪枝率0%（保底）；
- Stage2（layer1）：剪枝率15%；
- Stage3（layer2）：剪枝率25%；
- Stage4（layer3+layer4）：剪枝率35%；
  总剪枝率理论值≈28%，实测体积降至32.1MB。

执行渐进式剪枝：

pruner = LayerWisePruner(model) for epoch in range(5): # 5轮迭代 pruner.prune_by_rate(target_rate=0.05) # 每轮剪5% # 微调10个epoch train(model, train_loader, epochs=10, lr=1e-4) # 评估精度 acc = validate(model, val_loader) print(f"Epoch {epoch}: Acc={acc:.3f}, Size={get_model_size(model):.1f}MB")

导出剪枝后模型：

# 移除mask，重排权重 for name, module in model.named_modules(): if hasattr(module, 'weight_mask'): torch.nn.utils.prune.remove(module, 'weight') torch.save(model.state_dict(), 'resnet50_pruned.pth')

实测结果：剪枝后Top-1精度75.8%（原76.2%），体积32.1MB，为后续QAT留出足够空间。

4.3 QAT实操：用校准数据重建激活分布

构造校准数据集：从ImageNet训练集抽取1000张图，确保每类至少5张，小目标类别（如“bicycle”）额外增加20张含小目标的图。

插入FakeQuantize模块：

from torch.quantization import QuantStub, DeQuantStub class QATResNet50(nn.Module): def __init__(self, model): super().__init__() self.model = model self.quant = QuantStub() self.dequant = DeQuantStub() def forward(self, x): x = self.quant(x) x = self.model(x) x = self.dequant(x) return x qat_model = QATResNet50(pruned_model) # 为每层Conv/Linear插入FakeQuantize qat_model.qconfig = torch.quantization.get_default_qat_qconfig('fbgemm') torch.quantization.prepare_qat(qat_model, inplace=True)

QAT训练（15个epoch）：
- 学习率：1e-4（原训练的1/10）；
- 损失函数：CrossEntropyLoss + 量化稳定性正则项；
- 校准：前5个epoch每batch更新scale，后10个epoch冻结。

导出QAT模型：

qat_model.eval() torch.quantization.convert(qat_model, inplace=True) # 转为量化模型 torch.save(qat_model.state_dict(), 'resnet50_qat.pth')

实测结果：QAT后精度74.9%，体积28.3MB（INT8权重），推理延迟在T4上降至23ms（原87ms）。

4.4 ONNX导出与融合：手写Graph Rewriter的必要性

导出ONNX（关键参数）：

dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( qat_model, dummy_input, "resnet50_qat.onnx", opset_version=13, # 必须≥12，支持QAT op do_constant_folding=True, input_names=['input'], output_names=['output'], dynamic_axes={'input': {0: 'batch'}, 'output': {0: 'batch'}} )

执行融合：运行自研onnx_fuser.py，识别并替换Conv→BN→ReLU为FusedConvBNReLU，同时修正output type为int8。

验证融合效果：

# 查看节点数变化 python -c "import onnx; m=onnx.load('resnet50_fused.onnx'); print(len(m.graph.node))" # 原始ONNX：217 nodes → 融合后：183 nodes

4.5 TensorRT编译：用Nsight Compute验证是否真加速

构建engine：

import tensorrt as trt logger = trt.Logger(trt.Logger.SEVERITY.INFO) builder = trt.Builder(logger) network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser = trt.OnnxParser(network, logger) with open("resnet50_fused.onnx", "rb") as f: parser.parse(f.read()) config = builder.create_builder_config() config.set_flag(trt.BuilderFlag.FP16) config.set_flag(trt.BuilderFlag.INT8) config.max_workspace_size = 1 << 30 # 1GB # 设置INT8校准器 calibrator = trt.IInt8EntropyCalibrator2() calibrator.set_batch_size(32) config.int8_calibrator = calibrator engine = builder.build_engine(network, config)

性能验证：

# 抓取profile nsys profile -t cuda,nvtx --export csv ./trt_inference # 查看csv中tensor_core_utilization列，实测值82.3%

最终交付物：resnet50_optimized.engine，体积24.7MB，T4上推理延迟21.4ms，精度74.8%，满足所有约束。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 精度骤降排查：从“哪里错了”到“为什么错”

现象	可能原因	排查步骤	解决方案
QAT后精度掉>3%	校准数据未覆盖长尾类别	用`torchvision.datasets.ImageFolder`统计校准集各类别数量，对比训练集分布	用K-Center Greedy重采样，确保尾部类别占比≥5%
TensorRT engine加载失败	ONNX中存在不支持op（如`GatherND`）	`onnx.checker.check_model()`报错定位op名；`netron`可视化查看	用`onnx-simplifier`简化模型，或手动替换为支持op
编译后延迟不降反升	Tensor Core未启用	Nsight Compute中`tensor_core_utilization`<30%	检查`builder_config.set_flag(trt.BuilderFlag.FP16)`是否生效；确认输入tensor dtype为`torch.float16`

实操心得：精度问题90%源于数据，而非模型。每次精度崩塌，第一反应不是调模型，而是检查校准数据集——用matplotlib画出校准集与训练集的类别分布直方图，差异超过20%必修。

5.2 工具链兼容性雷区：版本错配的典型症状

PyTorch 1.13 + TensorRT 8.4：torch.fxtracer会因API变更报错AttributeError: 'module' object has no attribute 'fx'。解法：降级PyTorch至1.12.1。
ONNX 1.13 + TensorRT 8.4：导出时opset_version=14导致TensorRT解析失败。解法：强制opset_version=13。
torch-pruning 1.5 + PyTorch 1.12：prune.global_unstructured报错TypeError: 'NoneType' object is not callable。解法：锁定torch-pruning==1.4.0。

提示：建立自己的requirements.lock文件，记录每个项目使用的精确版本。我们团队用pip freeze > requirements.lock，每次新环境都pip install -r requirements.lock，杜绝“在我机器上好使”的扯皮。

5.3 硬件特异性陷阱：同一份代码，在不同卡上表现天壤之别

A100 vs V100：A100的Tensor Core支持fp16+int8混合精度，V100仅支持fp16。若在V100上启用INT8flag，TensorRT静默降级为fp16，但日志无提示。解法：用nvidia-smi -q -d POWER确认GPU型号，编写脚本自动选择flag。
昇腾310P vs 昇腾910：310P的Cube单元对Softmax输入shape有硬限制（必须为[N,C]），而910无此限制。若模型含Softmax且输入为[N,C,H,W]，310P编译失败。解法：在ONNX中插入Reshapeop，将[N,C,H,W]→[N*C,H*W]，Softmax后再Reshape回原shape。

5.4 最后一道防线：部署前的“三连测”

任何优化后的模型，上线前必须通过：

精度回归测试：用100张验证图，对比原始模型与优化模型输出logits的MSE，阈值<1e-3；
延迟压力测试：用locust模拟100并发请求，监控P99延迟是否稳定在标称值±10%内；
显存泄漏测试：连续运行24小时，用nvidia-smi每5分钟记录显存占用，波动>5%即判定泄漏。

我在某金融风控项目中，就因漏做第三步，上线后第3天显存缓慢增长至98%，服务OOM。根因是TensorRT engine未正确释放context，修复方案：在推理函数末尾显式调用context.destroy()。

6. 经验沉淀：从“做完项目”到“沉淀方法论”的关键跃迁

这个“Model-Optimizer”工作流，不是我闭门造车想出来的，而是踩着三个项目的坑垒起来的。第一个项目，我们用商业工具一键压缩，上线后发现小目标漏检率飙升，回溯发现校准数据全是大图；第二个项目，为赶工期跳过QAT直接PTQ，结果医院CT影像分割Dice系数掉0.15，客户拒付尾款；第三个项目，终于建起这套四层工作流，不仅按时交付，还帮客户把边缘设备推理功耗从12W压到7W，多卖了2000台终端。

所以我想说，模型优化真正的价值，不在于“把模型变小”，而在于把不确定性转化为确定性。当你能清晰说出“剪掉这32个通道是因为BN gamma均值<0.012”，“QAT校准用了这500张图因为覆盖了所有病灶尺寸”，“TensorRT启用了FP16+INT8是因为Nsight显示Tensor Core利用率82%”，你就已经超越了90%的同行。这套工作流的文档，我们内部叫《Optimization Playbook》，每一页都写着“谁在什么场景下，因为什么错误，怎么修正的”。它不追求炫技，只解决一个问题：让模型优化这件事，变得像拧螺丝一样可靠。

最后分享一个小技巧：每次优化后，用git tag打一个带精度/体积/延迟的tag，如v1.2.0-acc74.8-vol24.7mb-lat21.4ms。三年后再看，哪个tag对应哪个客户项目，一目了然。技术债可以欠，但知识债必须清零。