我手头正好有一个做端侧推理的项目模型在服务器上精度不错但一放到真实设备上就暴露了体积和速度的问题。折腾了一圈之后我把自己的一套优化流程沉淀成了一个叫Model-Optimizer的小工具箱专门用来处理推理阶段的模型瘦身和加速。今天就把这套流程和里面的关键细节从头到尾拆开讲一遍内容围绕量化、结构化剪枝、知识蒸馏这套组合拳展开目标是让你拿到一个已经训练好的模型后能系统地把它压到适合部署的体量同时尽量保住精度。无论你是刚接触模型压缩还是已经尝试过某种单一手段但效果不理想这篇文章都能给你一个可以直接照做的完整路线。如果你只是听说过“模型优化”这个词但不知道它到底在优化什么我的理解很简单我们手上有一个已经训练好的模型它的精度是达标的但部署环境不喜欢它。要么是安装包体积超了要么是推理延迟太高要么是内存吃不消。Model-Optimizer 干的事情就是在尽量不伤害精度的前提下把这个模型变得又小又快又省资源。这是一套工程化的实践不是某篇论文里的一两个公式。1. 项目定位一个能落地的端侧模型优化方案1.1 为什么需要一套完整的优化工具链很多人觉得模型优化就是调用一下量化接口把 FP32 换成 INT8完事。实际上单一手段的收益非常有限。我之前接过一个分类模型的优化需求原始模型 22MB跑一次推理大约 38ms放到某颗中端芯片上勉强能用但客户希望把安装包压到 10MB 以内延迟压到 15ms 以下。这个目标用单靠量化做不到因为量化只是把每个权重从 32 位变成 8 位理想情况下体积能缩小到原来的四分之一也就是 5.5MB 左右。但延迟方面量化对 CPU 的加速往往取决于算子是否对 INT8 做了底层优化实测下来可能只快 20% 到 30%离 15ms 的目标还有距离。这时候就需要动结构了。把通道剪掉一部分再把剩下的权重重新蒸馏训练一遍让模型整体更紧凑同时把量化的精度损失补回来。这就是为什么我最终把这几个手段组合到了一起而不是挑其中一个用到头。这套工具箱的适用对象很明确一是已经在跑 CV 或 NLP 模型需要部署到手机、嵌入式设备、边缘盒子上的开发者二是有一个训练好的大模型但推理资源吃紧的后端团队。这套流程对任务类型没有太多限制分类、检测、分割、文本匹配都适用核心思路是一致的。1.2 技术选型思路为什么是量化加剪枝加蒸馏我选了这三样组合而不是用更复杂的神经架构搜索或者权重矩阵低秩分解原因很简单工程可控。量化和结构化剪枝的收益是可预测的知识蒸馏则负责回收精度损失。这三者放在一起能形成一个稳定的“压缩—训练—再压缩”循环。用一个生活化的类比来解释假设你有一个塞满东西的行李箱量化是把你行李里的液体都换成小瓶子装体积缩小但容量不变剪枝是扔掉那些你根本用不上的纪念品蒸馏则是你在扔掉东西之后重新整理了一遍行李确保剩下的东西摆得更合理、更紧凑。三者做的事情不冲突而且顺序还有讲究。实际项目中我的执行顺序是先做剪枝骨架再做量化压缩最后用蒸馏去微调。先剪枝的好处是它相当于改变网络结构后续的量化步可以更加激进。如果反过来先量化再剪枝剪枝造成的精度损失会钉在已经压缩过的数值范围之上后面回收精度的难度会大很多。1.3 优化效果的度量口径要先统一在做任何优化之前必须把度量口径定清楚不然你根本不知道自己的优化到底有没有效果。体积这个指标至少要有两种口径磁盘体积和内存中的参数体积。磁盘体积看的是保存后的模型文件大小内存中的参数体积则需要看反序列化之后占用的空间两者可能因为序列化格式的不同而出现显著差异。延迟的度量更要谨慎。同一个模型在不同线程数、不同绑核策略下推理时间可以差出两倍以上。我踩过这个坑一开始测基线时没有固定线程数量化后的模型换了个环境跑测出来的延迟比优化前还高吓出一身冷汗。后来我把所有延迟测试都统一成同一份评测脚本固定线程数、固定绑核策略、固定输入张量尺寸多次运行取中位数数据才变得可信。精度指标也要统一。必须在优化前就把测试集固定下来最好是评估集和训练集完全隔离。如果测试集和训练集有重合量化后的模型可能在评测指标上看起来“涨点”但真实场景的表现反而变差。这类假象在模型压缩领域特别常见后面我会详细展开。2. 动手前必须做好的环境准备与基线搭建2.1 项目结构与工具链选型Model-Optimizer 的项目结构我不能说多么标准但经过几次项目验证后形成了一套比较顺手的组织方式。整体分成四个目录baseline 存放原始模型和原始评估脚本optimize 存放优化脚本和中间产物evaluate 存放统一的评测工具export 存放最终导出给部署端使用的模型。这么做的好处是所有过程都留痕不会出现“改了一版代码后不知道之前是怎么导出这个模型”的情况。model-optimizer/ ├── baseline/ # 原始模型、原始评估脚本 ├── optimize/ # 剪枝、量化、蒸馏的训练脚本 ├── evaluate/ # 统一评测工具固定线程、固定输入 └── export/ # 最终导出的部署模型工具链方面我习惯以 PyTorch 为主做优化实验因为它的动态图和丰富的钩子机制方便中途插入剪枝、蒸馏等操作。量化导出阶段会用到 ONNX Runtime 做 PTQ或者用 PyTorch 自带的量化感知训练接口做 QAT。这套组合基本能覆盖主流的部署后端。2.2 基线模型的确定与评估脚本固定我见过的很多优化项目最大的问题不是优化手段不够好而是基线本身就不干净。比如有人在优化前用的评估脚本和部署后的推理脚本走了完全不同的预处理逻辑导致量化后“精度暴跌”实际上是颜色通道顺序搞错了。在启动 Model-Optimizer 任何一项优化之前先把基线脚本冻结。具体做法是写一个独立的评估脚本输入是模型路径和测试数据路径输出是这份模型在这份数据上的全部指标。这个脚本在优化前后都不允许改动最多只能是“加载模型的方式”发生变化。优化前先跑一遍基线把指标记录下来之后每做一步优化都跑同一份脚本只允许模型文件发生变化。固定随机种子也很关键。模型优化涉及到大量随机过程比如校准集的采样、剪枝后的权重重排、蒸馏训练中的 dropout如果不固定种子两次实验之间的差异可能被误判为优化带来的收益或损失。我用了一个土办法在做任何实验前对比两次跑相同脚本的指标方差如果方差已经大过预期的优化收益那就先别急着优化先把评测稳定性搞定。2.3 校准集和验证集的隔离策略量化、剪枝、蒸馏都需要数据。量化需要校准集来确定每个 tensor 的数值范围剪枝如果需要敏感度分析也需要数据蒸馏则需要无标签数据或者原始训练集来让教师模型输出软标签。这三者千万不要混用。我的经验是严格要求三个集合互不重叠校准集用于确定量化参数验证集只用来评估最终精度蒸馏训练集或者无标签样本集用于训练阶段。如果校准集和验证集重叠量化后的模型在评测时相当于“开卷考试”INT8 的范围是专门针对这些样本调的看起来精度很高一到真实场景就露馅。有人会问如果数据集本身不大强行分三份会不会导致每一份都太少这个问题很实际。通常校准集需要 500 到 1000 张具有代表性的样本即可不需要太多。验证集建议至少 2000 张以上否则指标波动太大无法区分优化带来的真实变化。蒸馏训练集当然越多越好但如果数据有限可以利用教师模型在无标签数据上生成软标签来扩充。3. 量化实操收益最直接的第一步3.1 量化原理与 INT8 的收益计算量化简而言之就是用更少的数据位来表示权重和激活值。FP32 有 32 位INT8 只有 8 位所以模型的体积理论上可以减少到原来的四分之一。但这里有个误区很多人以为量化后模型一定会小到四分之一。实际上绝大部分模型里还有 BN 层、一些零散的标量参数这些参数可能依然以 FP32 存储。再加上序列化格式的额外开销实测体积缩小比例通常在 3.2 到 3.8 倍之间。量化的核心是找到一个映射把 FP32 的数值范围映射到 INT8 的 [-128, 127]。最常见的对称量化公式是q round(r / scale)其中 scale max_abs / 127r 是原始浮点数值q 是量化后的整数。反量化时 r_hat q * scale。举个例子某层权重最大绝对值是 2.0那 scale 就是 2.0 / 127 0.01575。原始权重 0.5 会映射为 round(0.5 / 0.01575) round(31.75) 32量化误差只有 0.0078 左右。但如果这一层有一个权重值是 20.0而其他值都在 0.1 以内那 scale 就会被这个异常值撑大大部分权重实际映射到 0 和 1 附近精度严重受损。这就是为什么量化需要校准数据目的就是为了统计出每一层激活值真实的数值范围尽量排除异常离群值的影响。3.2 校准数据的构建与 PTQ 操作步骤PTQ训练后量化是最省事的量化方式不需要重新训练模型只需要一小部分校准数据跑一遍前向统计每层激活值的分布再确定量化参数。实操步骤大致如下准备一份校准集建议 500 到 1000 张尽可能覆盖真实场景中的各种亮度、角度、遮挡情况。将校准数据按照部署时的预处理流程处理保持数据口径一致。在模型中插入量化观察点记录每层激活值的 min、max 或直方图分布。依据分布选择合适的量化参数常见策略包括 MinMax、Percentile、MSE 等。导出量化后的模型跑统一评估脚本。以 PyTorch 的 ONNX 导出配合 ONNX Runtime 量化举例典型的 PTQ 脚本长这样import onnxruntime as ort from onnxruntime.quantization import quantize_static, CalibrationDataReader, QuantType calib_loader build_calibration_loader(calib_dir, batch_size32) class CalibReader(CalibrationDataReader): def get_next(self): data calib_loader.next_batch() if data is None: return None return {input:0: data} quantize_static( model_inputbaseline.onnx, model_outputmodel_int8.onnx, calibration_data_readerCalibReader(), quant_formatQuantType.QOperator, per_channelTrue, activation_typeQuantType.QInt8, weight_typeQuantType.QInt8, )这里有两个参数值得展开说。per_channel 设置为 True会让量化更精细每个输出通道都有自己独立的 scale这对卷积网络特别重要。如果设置成 False整层共享一个 scale遇到权重分布不均匀的层精度损失会明显增大。activation_type 和 weight_type 我这里都选择了 QInt8因为许多推理引擎对 INT8 的优化最成熟而且对大部分任务来说INT8 的动态范围已经足够。3.3 QAT 量化感知训练与什么场景下才值得做PTQ 虽然方便但在一些敏感模型上精度损失可能超过 3%这个时候就需要引入 QAT量化感知训练。QAT 的思路很简单在训练过程中就把量化的效果模拟出来让模型的前向过程“提前适应”低比特带来的误差。PyTorch 的 torch.ao.quantization 提供了现成的假量化模块即 FakeQuantize它在前向传播时假装做了量化但反向传播时却使用直通估计器让梯度能正常回传。FakeQuantize 的前向数学表述是 q clip(round(x / scale), -128, 127) * scale注意这个公式里虽然数值被量化到整数再乘回 scale看起来是全精度操作但其实际效果是模拟了量化误差。模型在训练中就能感知到这种误差并尽量去适应。做 QAT 前先冷静评估一下你是否有足够的时间和算力QAT 通常需要微调 3 到 10 个 epoch数据量和训练资源都不能太少。如果 PTQ 精度只掉 0.5%不会影响业务指标那就不要 QAT如果精度掉了 2% 且这个损失无法接受QAT 就是值得的。我常用的经验参数是学习率设置为基础学习率的十分之一优化器用 Adambatch size 尽量和原始训练的 batch size 保持一致训练完后再冻结 BN 层跑一轮量化参数重统计这样能额外挽回 0.1% 到 0.3% 的精度。3.4 敏感层排查哪些层应该豁免量化量化实践中最容易被忽略的是敏感层问题。同一个模型里不同层对量化的耐受度差别非常大。有些卷积层即使使用 3 bit 量化精度都能保持而某些特殊的层比如带残差连接的相加层、带有大数值范围的 embedding 层一旦被量化精度直接崩掉。我常用的排查方法是通道敏感度分析把模型逐层设置为“不量化”其他层仍然量化然后跑一遍验证集记录每一层单独不量化时对整体精度的影响。如果某一层单独豁免后精度能提升 0.5% 以上说明这一层是敏感层在最终量化时应该跳过或者调整为更高精度如 INT16。这个操作的成本很低只需要在量化配置中设置 excluded_nodes 列表即可。比如 ONNX Runtime 的 quantize_static 支持一个 excluded_nodes 参数你可以把排查出来的敏感层名字填进去。实践中我见过最极端的模型有 5 个敏感层全部豁免后最终模型体积仍缩小了 30%但精度保持率从 85% 提升到了 99.7%。这告诉我们不要执着于“全网 INT8”适度的混合精度才是实战里的最佳解。4. 结构化剪枝真正甩掉多余的参数4.1 为什么选择结构化剪枝而不是非结构化剪枝剪枝大体分两类。非结构化剪枝是把权重矩阵中绝对值很小的单个元素直接置为零这样做可以达到很高的稀疏度但问题在于稀疏是“不规则”的。也就是说一个矩阵里哪些位置是零完全随机这导致绝大多数推理引擎底层存储数据时平移访问不连续无法有效加速。除非你跑在特定支持稀疏张量的硬件上否则非结构化剪枝只会给你带来理论参数量的下降实际推理速度反而更慢。结构化剪枝则是在整个通道或整个 Filter 的粒度上做取舍剪完之后网络每一层的形状都发生了变化宽度变窄了。这带来两个好处一是经过剪枝后的卷积计算在常规 CPU 和 GPU 上都能直接获得加速二是模型体积也会因为参数数量减少而下降。代价是精度损失通常比非结构化剪枝大一些因此剪枝后的微调就格外重要。你可以把这两者的区别理解成收拾书架非结构化剪枝是把每本书里抽掉几页剩下的书摆回去虽然纸张少了但每本书的厚度基本没变结构化剪枝是把一整本没什么价值的书直接抽出来扔掉书架上空出来一大片位置。4.2 基于 BN 层 Gamma 系数的剪枝方案通道剪枝有很多种实现方式比如基于权重范数、基于激活统计的泰勒展开等。在 Model-Optimizer 中我长期使用的是一种效果稳定且开销极低的方法基于 BN 层 gamma 系数的剪枝也叫 Slimming 方法。BN 层是网络中的归一化层它会对上一层输出做标准化再缩放缩放因子就叫 gamma。如果某个通道的 gamma 值非常接近 0说明这个通道经过标准化和缩放后输出的贡献趋近于 0也就是这个通道本身就是“可有可无”的。于是我们可以在训练时对 gamma 施加 L1 稀疏正则化逼迫更多 gamma 走向 0然后根据最终需要保留的比例剪掉 gamma 最小的那部分通道。训练期间的 loss 构造是关键def loss_with_slimming(original_loss, gamma, alpha): l1_reg torch.norm(gamma, 1) return original_loss alpha * l1_reg这里 alpha 是稀疏系数经验上初始可以取 1e-4 到 1e-3需要根据模型大小微调。alpha 太小gamma 稀疏化效果不明显剪枝后浪费通道alpha 太大模型精度在剪枝前就会被正则项压垮。我的经验是先跑一个 3 epoch 的小实验观察 gamma 直方图如果 gamma 分布大部分集中在 0 附近或者绝对值小于 1e-3说明 alpha 取大了如果 gamma 分布几乎都在 0.5 以上就说明正则强度不够。4.3 剪枝操作与微调重训练的具体流程当拿到稀疏化训练后的模型剪枝本身是“外科手术”式的。对每一层我根据 gamma 系数排序把占比最小的通道对应的卷积核从权重矩阵中移除同时相应调整下一层的输入通道数。具体操作可以分为以下几步冻结 BN 层参数记录每层 gamma 的绝对值排序。确定每层的剪枝比例。可以统一也可以按敏感度逐层设置但工程上统一比例更省事比如全局剪掉 30% 的通道。保存被剪通道的索引用 mask 标记哪些通道保留。重新构建一个更窄的模型结构将保留的权重拷贝过去。用低学习率对剪枝后的窄模型进行微调恢复精度。重训练阶段我习惯把学习率设置为基础学习率的 1/10使用余弦退火调度。微调 epoch 数不必太多对通用分类任务 15 到 20 个 epoch 足够检测模型因为任务复杂度高可能需要 30 个以上。我实验里最常见的现象是剪枝后模型精度会先掉一截大概 3 到 5 个点随后在微调过程中逐步恢复最终逼近未剪枝模型的精度但参数量减少了 30%。需要注意不要剪完一层就直接去搜索下一层的全局最优剪枝比例这会让切面变得极其复杂且难以维护。工程上全局统一比例剪枝配合敏感层保护即忽略敏感层的剪枝或给予最低剪枝比例已经能带来接近完美剪枝方案的表现。5. 知识蒸馏给小模型装上大模型的经验5.1 蒸馏在优化流程中的真实作用在整套 Model-Optimizer 流程中知识蒸馏不是必须的一步但往往是决定最终精度上限的一步。剪枝和量化都会让模型“瘦身”但模型的表示能力也会随之下降。直接微调可以恢复部分精度可是如果训练数据有限光靠微调很难让轻量化模型学到原始大模型的全部知识。知识蒸馏的核心思想是让轻薄模型学生模型同时向两个目标学习一是真实标签二是教师模型通常是原始未压缩的大模型输出的软标签。软标签里有真实标签没有的信息。比如分类任务里一张猫的照片真实标签是“猫”但教师模型可能会输出“猫 0.7老虎 0.2狗 0.1”。这个分布信息告诉学生模型猫和老虎在特征空间里有相似性。学生模型学到这份相似性泛化能力会比只学硬标签更强。这么说吧直接训练一个小模型就好比让新人只看标准答案来学习解题而有教师模型的软标签引导相当于让新人不仅知道正确答案还知道出题人是怎么倾向其他相近选项的。后者的理解深度完全不同。5.2 教师模型选择与温度参数调优教师模型的选择看似简单实则讲究。很多文章会说“用更大的模型做教师”但实际操作中我倾向于用“当前精度最高的模型”做教师而不是“参数量最大的模型”。这两个属性经常重合但不总是一样。比如在处理某项任务时我手上有一个 ResNet 系列的大模型还有一个经过大量数据增强的小模型后者精度更高。此时用小模型做教师反而合适因为它的输出分布和目标任务更匹配。温度参数 T 是蒸馏训练中为数不多的人为引入超参数它控制着软标签的分布“平滑度”。在分类任务中蒸馏 loss 通常基于 KL 散度计算公式为L_distill KL(softmax(teacher_logits / T) || softmax(student_logits / T))当 T 趋近于 1 时软标签退化为硬标签蒸馏失去意义当 T 过大比如 15 以上各类别的概率分布会被抹平软标签里的有效信息被稀释学生模型反而学不到关键区别。我通常在分类任务中把 T 设置在 4 到 8 之间物体检测因为输出结构更复杂T 的取值需要更稳健一些。我常用的蒸馏 loss 是硬标签监督和软标签监督的加权组合total_loss alpha * student_ce_loss (1 - alpha) * T * T * distill_kd_loss其中 alpha 通常在 0.3 到 0.7 之间系数 T * T 用于抵消梯度缩放影响因为软标签经过了温度缩放后梯度会变小若不放大回来蒸馏对更新贡献就会过弱。5.3 联合蒸馏、剪枝与量化的训练策略这一节可能是整套流程里最有价值的部分。很多人把剪枝、量化和蒸馏当成三段独立的流水线依次执行中间没有任何交互。但实战下来我更强调整合起来做。推荐的做法是在微调过程里同时做三件事。首先对教师模型输出软标签其次将学生模型的 forward 中插入伪量化模块让模型在训练时感知量化误差最后对 BN 层的 gamma 加上稀疏正则以便后续再剪一轮。三个目标可以被计入一个统一 losstotal_loss ce_hard lambda_1 * kd_soft lambda_2 * fake_quant_loss lambda_3 * l1_gamma注意fake_quant_loss 通常不需要显式计算因为量化误差是通过前向传播中模拟的量化操作自然影响梯度的。你只需要把量化的模拟假性量化算子插到正确的位置上然后正常反传就行。这样做的好处是模型在紧凑的结构变化中同时优化参数取值范围、空间结构和语义能力避免了踏入“先剪枝损伤精度—微调恢复—再量化又损伤精度—再微调”的无底洞。我的实验结果显示一体化的联合训练比三段式流程的最终精度高出 0.8 到 1.5 个点尤其是在剪枝比例和量化压缩同时较大的场景下更加明显。6. 回归验证与常见问题排查实录6.1 优化前后的性能与精度对照清单经过上述一系列操作后最忌讳的就是只把模型导出来就完事然后到部署环境去“裸奔”。任何一个环节出现问题都要能够逐层排查。我给 Model-Optimizer 定制了一份固定的回归验证清单每次优化完都会照着跑一遍。评估时固定采样以下纬度模型体积、参数内存、单次推理延迟、峰值内存、精度指标。延迟测试强调的是多次运行取中位数而不是取一次最好成绩内存测量需要在推理库启动后单独测量模型加载和运行时增长量避免和系统占用混在一起。这里分享一张最近一次项目的实际对照表数据已脱敏指标基线 FP32量化 INT8量化 剪枝 30%最终含蒸馏微调模型体积22.0 MB5.8 MB3.9 MB3.8 MB推理延迟38.0 ms31.5 ms22.0 ms21.8 ms是否超过预期延迟阈值 20ms是是否否Top-1 精度92.1%91.2%89.5%90.8%这个表能直观反映出每一步的收益与代价。单看量化精度只掉了 0.9%延迟降低不明显单看剪枝延迟降低明显但精度损失很大最终融合蒸馏后延迟达标精度也被拉回了一个能接受的水平。6.2 高频问题排查速查表为了减少反复试错我把自己踩过的高频问题整理成了一份速查表。这里的每一条都对应着真实损耗过的时间和精力。问题现象可能原因排查路径PTQ 后某一类精度剧烈下降该类样本在校准集中覆盖不足检查校准集类别分布补充该类样本后重新校准量化后模型的延迟不降反升算子部署到不被优化的 INT8 实现用性能剖析工具检查算子的实际执行后端对不支持 INT8 的算子豁免剪枝后参数量减少但推理变慢结构化剪枝后通道数变成非对齐状态检查通道数是否为 4 或 8 的倍数调整剪枝比例让其对齐蒸馏微调 loss 一直不降T 值过大导致软标签过于平滑降低温度参数或者增大硬标签 loss 的权重量化后的模型体积没有缩小到预期部分层被排除量化或者是混合精度所致导出去重分析核对各层数据类型占比有一个隐藏很深的坑必须提一下剪枝后的模型如果没有对 BN 层重新统计均值与方差而是直接复制了原模型的 BN 统计量那么即使精度恢复到位放到部署端也可能出现严重的数值抖动。解决方法是剪枝后跑一遍前向用当前模型的实际统计量对 BN 层做重初始化或者直接在微调阶段打开 BN 的 track_running_stats完事后再冻结。6.3 从回归结果逆向定位优化方向如果最后的回归结果仍不满足预期怎么继续往下走很多人第一反应是提高剪枝比例或者加大蒸馏权重实际上这是最不推荐的“瞎猫碰死耗子”式调参。正确做法是分析瓶颈在哪。如果延迟达标但体积超标可以直接把注意力转向量化混合精度或者检查模型里有没有一些无效的辅助层可以被简化。如果精度不达标而体积和延迟都正常则问题多半出在模型容量或蒸馏训练策略上此时应该减少剪枝比例、提高蒸馏 loss 的权重或者增加训练数据。如果精度和体积都不达标就要问问是不是模型原始结构本身过于冗余。这个场景下我会单独跑一次完整流程但做两个 A/B 实验一个是只剪枝不量化另一个是只量化不剪枝。通过比较这两个方向的收益能够快速定位出哪一个手段在当前模型上“性价比”更高然后重点优化该手段。写在最后的几点经验真正在项目中把 Model-Optimizer 用起来之后有几件事给我的印象最深。首先是“能不动就不动”量化能解决的地方绝不上剪枝因为剪枝改变网络结构会带来连锁调试成本。其次是“数据大于算法”校准集的覆盖度、验证集的可靠性环比任何优化技巧对最终结果的影响都更大。最后是“灰度上线前三思”优化后的模型即使离线数据全部达标也要安排一部分真实流量做灰度观察尤其是用户场景和训练分布不一致时离线指标再漂亮也可能在线上被打脸。我的一位 colleague 曾遇到量化模型在同分布测试集上精度只掉 0.3%但放到新收集的难例数据上直接掉了 2%后来排查发现难例都集中在夜间低光照场景而当初的校准集里几乎没有夜间样本。如果你要做模型优化请尽早把这类真实场景的样本纳入校准集和验证集这才是项目顺利落地的安全网。