1. 模型优化器到底在优化什么第一次看到 Model-Optimizer 这个词很多人会下意识地把它和“训练加速”“显存压缩”画等号。这个理解不算错但只对了一半。模型优化器真正处理的对象是模型从“能跑”到“跑得省、跑得快、跑得稳”之间那一整段工程鸿沟。它既可能是一个独立的工具库也可能是一套嵌入训练或推理流程的优化策略集合核心目标只有一个在不显著牺牲精度的前提下把模型的计算成本、存储成本和部署门槛压下来。我接触这类工具最早是在做端侧推理的时候。当时一个不到 200MB 的视觉模型在服务器上跑得好好的一放到资源受限的设备上就频繁超时。后来发现问题不在模型本身而在于权重精度、算子实现和内存布局都没有针对目标硬件做适配。Model-Optimizer 这类工具的价值就是把这些零散的优化动作系统化、自动化让开发者不用手工去抠每一个算子。它适合谁如果你正在做模型部署、推理服务搭建、边缘计算落地或者单纯觉得自己的模型“太胖了跑不动”那这类工具就是为你准备的。哪怕你只是想把一个开源模型塞进自己的小项目里了解模型优化的基本思路也能帮你省下不少算力账单。2. 核心优化手段与选型逻辑2.1 量化把浮点数换成整数到底损失了什么量化是模型优化里最常被提到的手段没有之一。它的基本逻辑是用低比特整数比如 INT8、INT4来近似表示原本的 FP32 或 FP16 权重和激活值。听起来很简单但实际操作中量化带来的精度损失往往不是线性的而是集中在某些敏感层上。我做过一组对比实验同一个 Transformer 模型分别做全量 INT8 量化和仅对线性层做 INT8 量化。全量量化后模型体积缩小到原来的四分之一推理速度提升约 2.3 倍但在长文本生成任务上出现了明显的重复和截断问题。而只量化线性层、保留注意力计算为 FP16 的方案体积缩小到约三分之一速度提升 1.8 倍生成质量几乎无损。这个差异说明量化策略的选择比量化本身更重要。常见的量化方式有三种训练后量化、量化感知训练和动态量化。训练后量化最省事拿一个训练好的模型直接转适合快速验证量化感知训练需要在训练阶段模拟量化误差精度保持最好但需要重新训练动态量化则是在推理时根据输入动态决定量化范围适合输入分布变化较大的场景。注意做训练后量化时一定要准备一个有代表性的校准数据集。我见过有人随手拿几十条数据去校准结果量化后的模型在真实业务数据上直接崩掉。校准集至少要覆盖你线上会遇到的主要输入类型数量建议在 500 到 1000 条之间。2.2 剪枝去掉冗余连接为什么不会让模型变傻剪枝的思路更直接神经网络里有很多权重其实贡献很小甚至接近零把它们去掉对最终输出影响微乎其微。结构化剪枝去掉整个通道或注意力头非结构化剪枝则细到单个权重。前者对硬件更友好后者压缩率更高但需要稀疏计算库支持。我在一个推荐模型上做过迭代式剪枝每剪掉 10% 的权重就做一轮微调最终在精度下降不到 0.5% 的情况下把参数量压到了原来的 40%。关键点在于“迭代”两个字一次性剪太多模型直接废掉慢慢剪、边剪边恢复才能保住精度。2.3 知识蒸馏让小模型学会大模型的“手感”知识蒸馏不是压缩原模型而是训练一个更小的学生模型去模仿大模型的输出分布。这里有个容易被忽略的细节学生模型学的不仅是硬标签更重要的是软标签里包含的类别间相似性信息。比如大模型在识别一只猫时会给“猫”很高的概率同时给“狗”一个不可忽略的概率这个信息比单纯的 one-hot 标签有用得多。温度参数 T 在这里起关键作用。T 越大软标签分布越平滑学生模型能学到的类间关系越丰富T 太小则退化成普通训练。我一般从 T4 开始试根据学生模型的表现上下调整。2.4 图优化与算子融合让计算图少绕路这一层优化往往被低估。计算图里很多相邻算子可以合并成一个比如卷积后面的批归一化在推理阶段可以直接折叠进卷积核里减少一次内存读写。算子融合、常量折叠、死代码消除这些编译层面的优化不需要改模型结构也不需要重新训练收益却相当可观。不同推理框架对图优化的支持程度不一样。有的框架自带图优化器有的需要你手动指定优化级别。我的经验是先开最高级别的图优化跑一遍如果精度有异常再逐级往下降定位是哪个优化动作引入了误差。3. 实操流程从原始模型到优化后部署3.1 环境准备与依赖确认动手之前先把环境理清楚。你需要确认三件事目标推理框架是什么、目标硬件支持哪些指令集、模型原始格式是什么。这三者决定了你能用哪些优化手段。以常见的 ONNX 模型为例如果目标是 CPU 推理优先考虑 ONNX Runtime 的量化工具如果目标是特定加速卡可能需要用厂商提供的转换工具。Python 环境建议用虚拟环境隔离避免依赖冲突。我一般会固定版本号因为优化工具链的版本兼容性有时候很微妙升级一个小版本就可能导致量化结果不一致。python -m venv optimize_env source optimize_env/bin/activate pip install onnx onnxruntime numpy3.2 基线测试先知道原来的模型有多“重”这一步很多人会跳过直接开始优化结果优化完了不知道到底提升了多少。基线测试要记录四个指标模型体积、推理延迟、内存占用和精度指标。延迟测试要注意预热前几次推理往往包含初始化开销不能算数。我通常跑 100 次推理去掉前 10 次取剩下 90 次的平均值和 P99 值。P99 比平均值更能反映线上体验因为用户感知到的卡顿往往来自长尾延迟。指标测试方法记录要点模型体积文件系统直接查看区分权重文件和结构文件推理延迟多次推理取统计值关注 P99 而非仅平均值内存占用推理时监控进程内存区分峰值和稳态精度指标标准测试集评估与原始模型对齐3.3 量化实操一步步把 FP32 变成 INT8以 ONNX Runtime 的静态量化为例完整流程分四步。第一步导出 FP32 模型并确认输入输出节点名称第二步准备校准数据做成 numpy 数组第三步配置量化参数指定哪些算子参与量化第四步执行量化并验证。from onnxruntime.quantization import quantize_static, CalibrationDataReader class DataReader(CalibrationDataReader): def __init__(self, data): self.data data self.index 0 def get_next(self): if self.index len(self.data): return None item {input: self.data[self.index]} self.index 1 return item quantize_static( model_inputmodel_fp32.onnx, model_outputmodel_int8.onnx, calibration_data_readerDataReader(calib_data), quant_formatQuantFormat.QDQ, per_channelTrue )per_channelTrue这个参数值得展开说。逐通道量化对每个输出通道单独计算量化参数比逐张量量化精度更好尤其适合卷积层。代价是量化参数存储稍微多一点但现代硬件基本可以忽略。量化完成后必须做精度对比。我一般会在验证集上跑一遍如果精度下降超过 1%就回去检查是不是某些层不该量化。常见做法是把第一层和最后一层排除在量化范围之外这两层对输入输出敏感度最高。3.4 剪枝实操迭代式剪枝的节奏把控剪枝的实操比量化更依赖经验。以 PyTorch 为例先用torch.nn.utils.prune对指定层做 L1 范数剪枝然后微调几个 epoch 恢复精度再重复这个过程。import torch.nn.utils.prune as prune for module in model.modules(): if isinstance(module, torch.nn.Linear): prune.l1_unstructured(module, nameweight, amount0.1) # 微调若干轮后永久移除被剪枝的权重 for module in model.modules(): if isinstance(module, torch.nn.Linear): prune.remove(module, weight)节奏怎么把握我的经验是每次剪枝比例不超过 15%微调学习率设为原始训练学习率的十分之一。如果微调后精度恢复不到剪枝前的 99%说明剪多了回退一步减小比例。提示剪枝后模型会变成稀疏结构但普通硬件不会自动加速稀疏计算。想要真正拿到速度收益需要配合支持稀疏运算的推理引擎否则只是体积变小了速度未必提升。3.5 优化后验证别只看精度一个指标优化完的模型要过三道验证。第一道是精度验证确保业务指标没有明显下滑第二道是性能验证确认延迟和吞吐达到预期第三道是稳定性验证长时间运行不出现内存泄漏或数值异常。我踩过一个坑量化后的模型在短输入上表现正常但输入长度超过某个阈值后输出全是乱码。后来定位到是激活值的动态范围超出了量化时校准的范围。解决办法是在校准数据里加入长样本或者对激活值采用动态量化。4. 常见问题与排查技巧实录4.1 量化后精度暴跌的排查顺序精度暴跌是最常见的问题排查要按顺序来。先看校准数据是否具有代表性这是最常见的原因再看是否有敏感层被量化尝试排除首尾层然后检查量化格式是否与推理引擎匹配QDQ 和 QOperator 格式在不同引擎上的表现可能不同最后看是否需要对特定算子禁用量化。我整理了一个速查表遇到问题按顺序过一遍基本能定位到原因。现象可能原因排查动作整体精度下降校准数据不具代表性扩充校准集覆盖主要输入类型特定类别精度差该类样本在校准集中缺失补充对应类别样本长输入输出异常激活值范围超出校准范围加入长样本或改动态量化推理报错量化格式与引擎不兼容切换 QDQ/QOperator 格式速度没提升硬件不支持低比特加速确认硬件指令集支持情况4.2 剪枝后模型无法收敛怎么办剪枝后微调不收敛通常是因为剪枝比例过大或者学习率设置不当。我的处理方式是先把学习率降到原始值的二十分之一用较小的学习率慢慢恢复。如果还是不收敛就回退到上一个剪枝检查点减小剪枝比例重新来。另一个容易被忽略的点是批归一化层的处理。剪枝后批归一化的统计量会发生变化需要在微调时重新估计。如果冻结了批归一化层模型很难恢复。4.3 优化工具链版本兼容性避坑优化工具链的版本问题非常隐蔽。我曾经遇到过一次ONNX Runtime 从 1.14 升级到 1.15 后同一个模型的量化结果精度下降了 3%。后来发现是新版本默认启用了某个新的量化策略。解决办法是在量化配置里显式指定策略不依赖默认值。建议在项目里锁定所有优化相关库的版本号并且在升级前做完整的回归测试。优化不是一劳永逸的事每次工具链变动都可能引入新的变量。4.4 多平台部署时的优化策略差异同一个模型要部署到不同平台优化策略不能一刀切。服务器端 CPU 可以接受 INT8 量化移动端可能还需要考虑 FP16 和 INT8 的混合方案而某些嵌入式设备只支持特定的算子集。我的做法是先确定一个“基准优化版本”然后在不同平台上做增量调整。基准版本保证精度增量调整针对平台特性做适配。这样既能保证一致性又能兼顾各平台的性能需求。5. 优化策略的组合与取舍5.1 量化加剪枝能不能一起用可以但顺序很重要。我的经验是先剪枝再量化。剪枝会改变权重分布如果先量化再剪枝量化后的离散权重被剪掉后剩下的权重分布可能变得很奇怪影响后续微调。先剪枝、微调恢复精度、再量化整个流程更可控。组合使用时的收益不是简单叠加的。剪枝压缩了参数量量化压缩了每个参数的比特数两者叠加后模型体积可以降到原来的十分之一左右。但速度提升受限于硬件对稀疏计算和低比特计算的支持程度不一定能达到同等比例。5.2 蒸馏和量化怎么选这两个手段解决的不是同一个问题。蒸馏解决的是“模型太大”的问题产出的是一个结构更小的新模型量化解决的是“每个参数占太多空间”的问题模型结构不变。如果你的目标是极致压缩可以先用蒸馏得到一个小子模型再对小子模型做量化。蒸馏的代价是需要重新训练时间成本高量化基本不需要训练工程成本低。如果时间紧优先做量化如果对模型体积有硬性要求蒸馏加量化的组合更合适。5.3 什么时候不该做优化不是所有场景都需要模型优化。如果模型只在服务器端跑算力充足延迟要求也不苛刻那优化带来的收益可能抵不上引入的复杂度和风险。我见过团队花了两周做量化结果线上精度掉了两个点最后又回滚到原始模型。判断标准很简单优化带来的收益是否明显大于维护成本。如果模型推理成本只占整体成本的一小部分或者精度对业务至关重要不容有失那保守一点未必是坏事。6. 我在实际操作中的几点体会做模型优化这些年最大的感受是优化不是单纯的工程问题而是精度、速度、成本三者之间的持续权衡。没有一套参数能适配所有场景每一次优化都需要针对具体模型、具体硬件、具体业务做调整。另一个体会是基线测试和回归验证的时间永远不能省。我早期为了赶进度跳过基线测试结果优化后无法量化收益汇报时拿不出有说服力的数据。后来养成了习惯任何优化动作之前先跑基线优化之后跑完整回归数据说话。最后分享一个小技巧做量化校准的时候除了用真实业务数据可以额外加入一些边界样本比如特别长、特别短、特别模糊的输入。这些样本能帮量化工具更好地确定激活值的动态范围减少线上出现异常输出的概率。这个做法在多个项目里都帮我避免了长尾问题。 
长河君 · 2026/10/2 19:09:43 · 阅读 1.2k 模型优化器实战：量化、剪枝与知识蒸馏的工程取舍
1. 模型优化器到底在优化什么第一次看到 Model-Optimizer 这个词很多人会下意识地把它和“训练加速”“显存压缩”画等号。这个理解不算错但只对了一半。模型优化器真正处理的对象是模型从“能跑”到“跑得省、跑得快、跑得稳”之间那一整段工程鸿沟。它既可能是一个独立的工具库也可能是一套嵌入训练或推理流程的优化策略集合核心目标只有一个在不显著牺牲精度的前提下把模型的计算成本、存储成本和部署门槛压下来。我接触这类工具最早是在做端侧推理的时候。当时一个不到 200MB 的视觉模型在服务器上跑得好好的一放到资源受限的设备上就频繁超时。后来发现问题不在模型本身而在于权重精度、算子实现和内存布局都没有针对目标硬件做适配。Model-Optimizer 这类工具的价值就是把这些零散的优化动作系统化、自动化让开发者不用手工去抠每一个算子。它适合谁如果你正在做模型部署、推理服务搭建、边缘计算落地或者单纯觉得自己的模型“太胖了跑不动”那这类工具就是为你准备的。哪怕你只是想把一个开源模型塞进自己的小项目里了解模型优化的基本思路也能帮你省下不少算力账单。2. 核心优化手段与选型逻辑2.1 量化把浮点数换成整数到底损失了什么量化是模型优化里最常被提到的手段没有之一。它的基本逻辑是用低比特整数比如 INT8、INT4来近似表示原本的 FP32 或 FP16 权重和激活值。听起来很简单但实际操作中量化带来的精度损失往往不是线性的而是集中在某些敏感层上。我做过一组对比实验同一个 Transformer 模型分别做全量 INT8 量化和仅对线性层做 INT8 量化。全量量化后模型体积缩小到原来的四分之一推理速度提升约 2.3 倍但在长文本生成任务上出现了明显的重复和截断问题。而只量化线性层、保留注意力计算为 FP16 的方案体积缩小到约三分之一速度提升 1.8 倍生成质量几乎无损。这个差异说明量化策略的选择比量化本身更重要。常见的量化方式有三种训练后量化、量化感知训练和动态量化。训练后量化最省事拿一个训练好的模型直接转适合快速验证量化感知训练需要在训练阶段模拟量化误差精度保持最好但需要重新训练动态量化则是在推理时根据输入动态决定量化范围适合输入分布变化较大的场景。注意做训练后量化时一定要准备一个有代表性的校准数据集。我见过有人随手拿几十条数据去校准结果量化后的模型在真实业务数据上直接崩掉。校准集至少要覆盖你线上会遇到的主要输入类型数量建议在 500 到 1000 条之间。2.2 剪枝去掉冗余连接为什么不会让模型变傻剪枝的思路更直接神经网络里有很多权重其实贡献很小甚至接近零把它们去掉对最终输出影响微乎其微。结构化剪枝去掉整个通道或注意力头非结构化剪枝则细到单个权重。前者对硬件更友好后者压缩率更高但需要稀疏计算库支持。我在一个推荐模型上做过迭代式剪枝每剪掉 10% 的权重就做一轮微调最终在精度下降不到 0.5% 的情况下把参数量压到了原来的 40%。关键点在于“迭代”两个字一次性剪太多模型直接废掉慢慢剪、边剪边恢复才能保住精度。2.3 知识蒸馏让小模型学会大模型的“手感”知识蒸馏不是压缩原模型而是训练一个更小的学生模型去模仿大模型的输出分布。这里有个容易被忽略的细节学生模型学的不仅是硬标签更重要的是软标签里包含的类别间相似性信息。比如大模型在识别一只猫时会给“猫”很高的概率同时给“狗”一个不可忽略的概率这个信息比单纯的 one-hot 标签有用得多。温度参数 T 在这里起关键作用。T 越大软标签分布越平滑学生模型能学到的类间关系越丰富T 太小则退化成普通训练。我一般从 T4 开始试根据学生模型的表现上下调整。2.4 图优化与算子融合让计算图少绕路这一层优化往往被低估。计算图里很多相邻算子可以合并成一个比如卷积后面的批归一化在推理阶段可以直接折叠进卷积核里减少一次内存读写。算子融合、常量折叠、死代码消除这些编译层面的优化不需要改模型结构也不需要重新训练收益却相当可观。不同推理框架对图优化的支持程度不一样。有的框架自带图优化器有的需要你手动指定优化级别。我的经验是先开最高级别的图优化跑一遍如果精度有异常再逐级往下降定位是哪个优化动作引入了误差。3. 实操流程从原始模型到优化后部署3.1 环境准备与依赖确认动手之前先把环境理清楚。你需要确认三件事目标推理框架是什么、目标硬件支持哪些指令集、模型原始格式是什么。这三者决定了你能用哪些优化手段。以常见的 ONNX 模型为例如果目标是 CPU 推理优先考虑 ONNX Runtime 的量化工具如果目标是特定加速卡可能需要用厂商提供的转换工具。Python 环境建议用虚拟环境隔离避免依赖冲突。我一般会固定版本号因为优化工具链的版本兼容性有时候很微妙升级一个小版本就可能导致量化结果不一致。python -m venv optimize_env source optimize_env/bin/activate pip install onnx onnxruntime numpy3.2 基线测试先知道原来的模型有多“重”这一步很多人会跳过直接开始优化结果优化完了不知道到底提升了多少。基线测试要记录四个指标模型体积、推理延迟、内存占用和精度指标。延迟测试要注意预热前几次推理往往包含初始化开销不能算数。我通常跑 100 次推理去掉前 10 次取剩下 90 次的平均值和 P99 值。P99 比平均值更能反映线上体验因为用户感知到的卡顿往往来自长尾延迟。指标测试方法记录要点模型体积文件系统直接查看区分权重文件和结构文件推理延迟多次推理取统计值关注 P99 而非仅平均值内存占用推理时监控进程内存区分峰值和稳态精度指标标准测试集评估与原始模型对齐3.3 量化实操一步步把 FP32 变成 INT8以 ONNX Runtime 的静态量化为例完整流程分四步。第一步导出 FP32 模型并确认输入输出节点名称第二步准备校准数据做成 numpy 数组第三步配置量化参数指定哪些算子参与量化第四步执行量化并验证。from onnxruntime.quantization import quantize_static, CalibrationDataReader class DataReader(CalibrationDataReader): def __init__(self, data): self.data data self.index 0 def get_next(self): if self.index len(self.data): return None item {input: self.data[self.index]} self.index 1 return item quantize_static( model_inputmodel_fp32.onnx, model_outputmodel_int8.onnx, calibration_data_readerDataReader(calib_data), quant_formatQuantFormat.QDQ, per_channelTrue )per_channelTrue这个参数值得展开说。逐通道量化对每个输出通道单独计算量化参数比逐张量量化精度更好尤其适合卷积层。代价是量化参数存储稍微多一点但现代硬件基本可以忽略。量化完成后必须做精度对比。我一般会在验证集上跑一遍如果精度下降超过 1%就回去检查是不是某些层不该量化。常见做法是把第一层和最后一层排除在量化范围之外这两层对输入输出敏感度最高。3.4 剪枝实操迭代式剪枝的节奏把控剪枝的实操比量化更依赖经验。以 PyTorch 为例先用torch.nn.utils.prune对指定层做 L1 范数剪枝然后微调几个 epoch 恢复精度再重复这个过程。import torch.nn.utils.prune as prune for module in model.modules(): if isinstance(module, torch.nn.Linear): prune.l1_unstructured(module, nameweight, amount0.1) # 微调若干轮后永久移除被剪枝的权重 for module in model.modules(): if isinstance(module, torch.nn.Linear): prune.remove(module, weight)节奏怎么把握我的经验是每次剪枝比例不超过 15%微调学习率设为原始训练学习率的十分之一。如果微调后精度恢复不到剪枝前的 99%说明剪多了回退一步减小比例。提示剪枝后模型会变成稀疏结构但普通硬件不会自动加速稀疏计算。想要真正拿到速度收益需要配合支持稀疏运算的推理引擎否则只是体积变小了速度未必提升。3.5 优化后验证别只看精度一个指标优化完的模型要过三道验证。第一道是精度验证确保业务指标没有明显下滑第二道是性能验证确认延迟和吞吐达到预期第三道是稳定性验证长时间运行不出现内存泄漏或数值异常。我踩过一个坑量化后的模型在短输入上表现正常但输入长度超过某个阈值后输出全是乱码。后来定位到是激活值的动态范围超出了量化时校准的范围。解决办法是在校准数据里加入长样本或者对激活值采用动态量化。4. 常见问题与排查技巧实录4.1 量化后精度暴跌的排查顺序精度暴跌是最常见的问题排查要按顺序来。先看校准数据是否具有代表性这是最常见的原因再看是否有敏感层被量化尝试排除首尾层然后检查量化格式是否与推理引擎匹配QDQ 和 QOperator 格式在不同引擎上的表现可能不同最后看是否需要对特定算子禁用量化。我整理了一个速查表遇到问题按顺序过一遍基本能定位到原因。现象可能原因排查动作整体精度下降校准数据不具代表性扩充校准集覆盖主要输入类型特定类别精度差该类样本在校准集中缺失补充对应类别样本长输入输出异常激活值范围超出校准范围加入长样本或改动态量化推理报错量化格式与引擎不兼容切换 QDQ/QOperator 格式速度没提升硬件不支持低比特加速确认硬件指令集支持情况4.2 剪枝后模型无法收敛怎么办剪枝后微调不收敛通常是因为剪枝比例过大或者学习率设置不当。我的处理方式是先把学习率降到原始值的二十分之一用较小的学习率慢慢恢复。如果还是不收敛就回退到上一个剪枝检查点减小剪枝比例重新来。另一个容易被忽略的点是批归一化层的处理。剪枝后批归一化的统计量会发生变化需要在微调时重新估计。如果冻结了批归一化层模型很难恢复。4.3 优化工具链版本兼容性避坑优化工具链的版本问题非常隐蔽。我曾经遇到过一次ONNX Runtime 从 1.14 升级到 1.15 后同一个模型的量化结果精度下降了 3%。后来发现是新版本默认启用了某个新的量化策略。解决办法是在量化配置里显式指定策略不依赖默认值。建议在项目里锁定所有优化相关库的版本号并且在升级前做完整的回归测试。优化不是一劳永逸的事每次工具链变动都可能引入新的变量。4.4 多平台部署时的优化策略差异同一个模型要部署到不同平台优化策略不能一刀切。服务器端 CPU 可以接受 INT8 量化移动端可能还需要考虑 FP16 和 INT8 的混合方案而某些嵌入式设备只支持特定的算子集。我的做法是先确定一个“基准优化版本”然后在不同平台上做增量调整。基准版本保证精度增量调整针对平台特性做适配。这样既能保证一致性又能兼顾各平台的性能需求。5. 优化策略的组合与取舍5.1 量化加剪枝能不能一起用可以但顺序很重要。我的经验是先剪枝再量化。剪枝会改变权重分布如果先量化再剪枝量化后的离散权重被剪掉后剩下的权重分布可能变得很奇怪影响后续微调。先剪枝、微调恢复精度、再量化整个流程更可控。组合使用时的收益不是简单叠加的。剪枝压缩了参数量量化压缩了每个参数的比特数两者叠加后模型体积可以降到原来的十分之一左右。但速度提升受限于硬件对稀疏计算和低比特计算的支持程度不一定能达到同等比例。5.2 蒸馏和量化怎么选这两个手段解决的不是同一个问题。蒸馏解决的是“模型太大”的问题产出的是一个结构更小的新模型量化解决的是“每个参数占太多空间”的问题模型结构不变。如果你的目标是极致压缩可以先用蒸馏得到一个小子模型再对小子模型做量化。蒸馏的代价是需要重新训练时间成本高量化基本不需要训练工程成本低。如果时间紧优先做量化如果对模型体积有硬性要求蒸馏加量化的组合更合适。5.3 什么时候不该做优化不是所有场景都需要模型优化。如果模型只在服务器端跑算力充足延迟要求也不苛刻那优化带来的收益可能抵不上引入的复杂度和风险。我见过团队花了两周做量化结果线上精度掉了两个点最后又回滚到原始模型。判断标准很简单优化带来的收益是否明显大于维护成本。如果模型推理成本只占整体成本的一小部分或者精度对业务至关重要不容有失那保守一点未必是坏事。6. 我在实际操作中的几点体会做模型优化这些年最大的感受是优化不是单纯的工程问题而是精度、速度、成本三者之间的持续权衡。没有一套参数能适配所有场景每一次优化都需要针对具体模型、具体硬件、具体业务做调整。另一个体会是基线测试和回归验证的时间永远不能省。我早期为了赶进度跳过基线测试结果优化后无法量化收益汇报时拿不出有说服力的数据。后来养成了习惯任何优化动作之前先跑基线优化之后跑完整回归数据说话。最后分享一个小技巧做量化校准的时候除了用真实业务数据可以额外加入一些边界样本比如特别长、特别短、特别模糊的输入。这些样本能帮量化工具更好地确定激活值的动态范围减少线上出现异常输出的概率。这个做法在多个项目里都帮我避免了长尾问题。