当时我在做一个自动驾驶（Self-Driving）场景下的Object Detection实验，内部项目编号叫proj5。模型的骨架是Faster R-CNN + ResNet50-FPN，在晴天白天的验证集上mAP能到45左右，自我感觉还不错。结果一上夜间小雨场景，AP直接掉了快一半。我的第一反应很朴素：上TTA（Test-Time Augmentation），测试时增强嘛，多跑几个变换，把预测平均一下，总能稳一点。结果打脸打得非常干脆。
翻转TTA掉了近2个点，多尺度TTA涨了但涨幅有限，所有变换全开又涨不动了。后来排查到Batch Normalization的统计量上，才明白问题不在“增强不够”，而在“归一化假设失效”。这篇文章就是把这次排查和改造过程完整记录下来，包括BN统计量重估的具体实现、我踩过的六个坑，以及最终在典型自动驾驶困难场景下的实测效果。如果你也在做检测模型的推理优化，或者你的模型同样存在“白天行、雨夜崩”的问题，这篇应该能帮你省不少时间。
1. BN 在检测模型里的位置，决定了它对场景漂移有多敏感
1.1 先盘一下 BN 层在典型检测骨架里的分布
很多人对BN的理解停留在“训练的时候归一化一下，加快收敛”。但到了推理阶段，BN的行为和训练阶段差别很大，而这个差别在自动驾驶这种分布剧烈变化的场景下会被放得非常大。
以我最常用的Faster R-CNN + ResNet50-FPN为例，BN层基本都堆在backbone里。ResNet50的stem部分（conv1 + bn1 + relu + maxpool）就有一个BN，后面的layer2到layer4每个BasicBlock里又有两个BN，一共几十个。FPN的1x1卷积通常不带BN，RPN和检测头也很少用BN。所以可以说，BN对最终预测的影响几乎全部来自backbone提取特征的过程。
正是因为BN分布在这么底层的位置，它一旦失准，后续的FPN、ROI pooling、检测头全部建立在错误特征分布上。这不像分类网络，最后一层线性层还能扛一扛。检测的回归框和分类分数对特征尺度极其敏感，特征分布一变，框的置信度、回归量都会跟着漂。
1.2 训练时用的 batch 统计量，推理时用的 running stats，二者不是一回事
训练阶段，BN层会对当前batch计算均值和方差，然后用这个batch统计量去做归一化。同时，它还会用滑动平均更新一组全局统计量（running_mean和running_var），PyTorch里的公式是：
running_stats = (1 - momentum) * running_stats + momentum * batch_stats注意PyTorch里momentum默认是0.1，也就是每次更新只吸收10%的当前batch信息，更新非常平滑。
推理阶段（model.eval()），BN不再计算batch统计量，而是直接用训练时累计下来的running_mean和running_var做归一化。这个设计在训练和测试数据同分布时没问题，一旦分布漂移，问题就来了。
我在排查proj5模型时做过一个很直观的检查：把一片雨夜图像的中间特征拎出来，统计每个通道的均值和方差，和模型里存着的running_mean、running_var做对比。结果多个通道的偏差超过3倍以上，有的通道均值方向直接相反。相当于你拿一个“晴天模型”的统计基准，去归一化雨夜的激活值，每个通道都在错误尺度上被拉伸或压缩。
1.3 自动驾驶场景下的分布漂移，最直接地体现在统计量层面
自动驾驶感知是典型的开放场景问题。训练集大多是晴朗白天，光照稳定、对比度正常。但到了部署环节，夜间、逆光、雨雾、雪天、隧道出入口，每个都是完全不同的成像分布。
这些差异不是简单的“亮度变暗”能概括的。雨滴会造成局部纹理扰动，夜间的低照度会让传感器噪声急剧放大，雾气会让高频细节损失、整体对比度下降。这些干扰在语义层面可能只是“图像变脏了”，但在channel-wise统计量层面，它是剧烈的分布偏移。
BN推理模式假设测试分布和训练分布一致，一旦这个假设被雨夜打破，归一化后的特征就会偏离模型预期的范围。再加上ReLU这种单侧抑制激活函数，负值被截断，特征被强行推向饱和区，检测性能的崩塌几乎是必然的。
所以，先别急着上各种复杂的域适应算法，第一步应该解决的是BN统计量和当前场景的匹配问题。
2. TTA 本身没有错，错在被 BN 的统计量拖了后腿
2.1 检测任务里常用的 TTA 和分类任务不太一样
TTA的核心思想很简单：对同一张输入做多个变换，比如水平翻转、多尺度缩放、色彩抖动，然后分别跑前向，再把结果聚合起来。
分类任务里TTA很容易做，直接把softmax概率平均就行。但检测任务里的“聚合”麻烦得多，因为每张图得到的是数量不定的一组框。最常见的做法是把所有TTA结果合并，然后做一次加权NMS（Weighted NMS）。基本逻辑是：如果多个变换都在同一位置预测出高置信度目标，说明这个目标很可靠；把重合框的位置和分数按置信度加权平均，得到一个更稳的框。
这个思路从理论上讲是对的，问题出在模型内部。
2.2 为什么 TTA 偶尔反而掉点：统计量失配下的均值没有意义
我一开始天真地以为，TTA是纯收益，最多算力贵一点。结果在proj5的夜间子集上跑了三组实验：
- 水平翻转TTA：AP反而从31.2掉到29.8
- 多尺度TTA（0.8x/1.0x/1.2x）：AP升到33.7
- 翻转+多尺度全开：AP只能到32.5左右，甚至不如单独多尺度
这个现象让我困惑了很久。后来把各层激活分布拉出来看，才意识到核心矛盾在哪儿。
TTA的每个变换都会产生一组新的特征分布。例如翻转TTA改变了特征的水平统计特性，多尺度TTA则改变了特征的空间尺寸和尺度响应。这些变换后的特征，经过BN层时，用的还是训练集那一套running_mean和running_var。
举个例子，你对输入做了1.2倍的放大，目标在特征图上的尺度发生了变化，某些通道的激活强度整体上升。BN层仍然用晴天训练时的均值/方差去归一化，结果这些通道的激活被压到了错误的响应区间。下一层ReLU可能让一部分信息直接消失，也可能让另一部分进入饱和区。这时候你再对多个变换结果做加权平均，等于把多个被系统性误差污染的结果强行平均在一起。
平均只能消除方差，不能消除偏差。
2.3 深层机制：TTA 扩大了特征分布与 BN 假设的偏差
我做过一个更细的对照实验。训练集用的是BDD100K的晴天子集，测试集是夜间雨雾子集。分别对一张雨夜图像做原始输入、水平翻转、1.25x缩放三种输入，分别提取backbone输出的特征统计量。
结果很有意思：三种输入的统计量之间差异不大，但它们和模型running_stats之间的偏差都很大。换句话说，TTA带来的统计量偏移，本身就隐含在BN假设失配的系统性偏差里。变换再多，平均水平还是落在错误基准附近。
这个结论让我意识到，TTA要真正稳下来，必须先让BN的统计量“落”到当前测试分布上。只要统计量还是旧的，TTA做得再精细，底层都是沙地上盖楼。
3. 核心改造：把 BN 统计量重估模块接进 TTA 流程
3.1 为什么只重估统计量，不动所有权重
这里有个很关键的设计决策。域自适应通常有两种思路：一是用测试数据微调模型权重，二是只调整BN统计量。
我选择只调统计量，基于三个现实原因：
- 微调权重没有标签，自监督信号容易引入噪声，而且一旦微调不恰当，会把模型在正常场景下的能力破坏掉。
- BN统计量重估几乎不涉及梯度回传，算力开销低，推理引擎里很容易集成。
- 从工程风险角度看，统计量只影响归一化的“位置”，改动范围面小，出问题的概率低，便于灰度验证和快速回滚。
实际效果也证明，对检测任务来说，统计量重估能解决的性能瓶颈占比非常大，不需要贸然动权重。
3.2 具体实现方案：eval 模式下用校准 batch 重算 running stats
我要分享的是一种在PyTorch里非常实用的实现路径。核心思路是：保持模型在eval模式，避免引入Dropout的随机性；把目标BN层的track_running_stats置为False，使其在eval下也使用当前batch的统计量做归一化；同时手动按EMA方式更新running_mean和running_var。
伪代码大概长这样：
def reestimate_bn_stats(model, calib_loader, momentum=0.6, target_prefixes=("layer3", "layer4")): """ 在不打开Dropout的前提下，用校准数据流式重估BN统计量。 momentum是PyTorch语义：新统计量占的权重。 """ model.eval() torch.set_grad_enabled(False) # 收集目标BN层 bn_layers = [] for name, module in model.named_modules(): if isinstance(module, torch.nn.BatchNorm2d) and any( prefix in name for prefix in target_prefixes ): bn_layers.append((name, module)) # 备份并切换BN模式 saved_flags = [] for _, module in bn_layers: saved_flags.append(module.track_running_stats) module.track_running_stats = False # 当前batch统计量参与归一化 # 注意：track_running_stats=False后，running_mean/var在前向里不会被更新 # 流式更新running stats for batch_idx, imgs in enumerate(calib_loader): model(imgs) # 前向，特征是batch统计量归一化 for _, module in bn_layers: # 此时module.running_mean/var保留的是旧值，需要手动更新 bn_mean = module.running_mean bn_var = module.running_var # 因为track_running_stats=False，running_*在forward后不会自动变。 # 最新的batch统计量需要从模块内部重新取。 # 这里简化描述，实际可用一个前向hook把batch的mean/var记录下来。 pass # 真正推荐的方式：用forward_hook在模块forward之后， # 计算batch_mean/batch_var，然后执行EMA更新： # module.running_mean = (1 - momentum) * module.running_mean + momentum * batch_mean # module.running_var = (1 - momentum) * module.running_var + momentum * batch_var # 恢复原始flag for module, flag in zip(bn_layers, saved_flags): module.track_running_stats = flag实际工程里，我不会在伪代码里把hook写得这么粗糙。更稳妥的做法是：写一个forward_hook，在BN层forward结束时拿到该层的batch均值/方差，然后手动更新running统计量。这个hook在调度上所有层都串行，不会互相干扰，也方便做“只重估指定层”的开关。
要注意的关键点：校准batch的构建决定了统计量重估的质量。我强烈建议不要用单帧的多变换图当校准数据。单帧信息量有限，统计量方差大，多个TTA变换之间的相关性也会让统计量偏斜。最好是攒一个20到50帧的滑窗视频序列，每帧加上各自的多变换结果，混合成这个校准batch。这样统计量能反映短时间内的真实场景分布，又不会因为单一帧的噪声而剧烈跳变。
3.3 选哪些层重估，以及重估频率怎么定
不是所有BN层都需要重估。我实测下来的结论是：靠近输入的低层BN（stem和layer2）对场景漂移不敏感，真正影响检测性能的是高层语义特征里的统计量偏差。
原因是低层BN主要在做像素级统计，比如亮度、对比度，它本身就有一定的尺度补偿能力。而高层BN对应的是语义特征分布，雨雾噪声在这些层会体现得更抽象，统计量失配造成的影响也更难通过后续层修正。
我习惯的做法是只重估layer3和layer4的BN，block2那组保留不动。这样能显著降低前向次数，而且在大部分雨、雾、夜场景下效果几乎无损。
重估频率上，我的经验是：连续视频流里每10帧做一次滑窗校准就够了。如果场景切换极其剧烈（比如隧道出入口），可以再加一个简单的触发机制：对比当前帧的统计量和running_stats之间的偏差，超过阈值就触发一次重估。
3.4 三种实现路径的对比，以及为什么我推荐开关式hook
技术社区里重估BN统计量的实现思路大概有三种：
| 实现路径 | 优点 | 缺点 |
|---|---|---|
| 直接model.train() | 实现最简单，BN会自动用batch统计量 | 会连带启用Dropout，推理结果带随机性；需额外遍历禁用Dropout |
| 把track_running_stats设False | BN在eval下也按batch统计量归一化，不带Dropout | running stats不自动更新，需要手动做EMA，逻辑稍微绕 |
| forward_hook手动更新 | 完全可控，可按层开启，不影响原模型结构 | 代码量最大，但最省算力 |
我最终选的是第三种，理由很简单：它能做到“精确控制”。比如我只想重估layer4、只校准20帧、只在夜间场景开启，这些需求在前两种路径里都会显得很别扭，但hook方案里就是几个配置项的事。
而且hook方案可以做成一个独立的运行时模块，推理引擎里加一个开关就能启用，回溯问题也方便。生产环境最怕的就是黑盒改动，hook方案把所有行为都暴露在代码里，出了问题能定位。
4. 复现过程中踩过的六个坑，按完整排查链路记录
4.1 坑一：直接调用 model.train() 导致的隐蔽方差
第一次做统计量重估时我偷了个懒，觉得“BN要batch统计量，那就把模型切成train模式呗”。看起来没问题，BN确实开始用batch统计量了，但我忽略了：train模式下Dropout也同时被打开了。
那段时间同一个输入跑两遍，输出框会不一样，尤其是小目标区域。一开始我还以为是NMS的随机性，后来发现是Dropout在作怪，因为每次前向随机关闭的神经元不同，检测头的输出自然不稳定。
排查思路是：对同一张图固定随机种子跑两次推理，比较输出的差异。然后把Dropout层全部手动切到eval模式，再跑两次，差异明显缩小。最后就不再依赖train模式，而是用hook方案，把Dropout完全隔离在改动之外。
4.2 坑二：多尺度TTA的缩放倍率，FPN比你想象中敏感
最初做多尺度TTA时，我习惯像图像分类一样把缩放倍率设成0.5x、1.0x、2.0x这种跨度。结果2.0x那一支严重拖后腿，全部融合后AP甚至不如单独1.0x。
后来发现原因出在FPN的结构上。FPN会把不同尺度的目标分配到不同层（P2到P5），放大输入会让目标在特征空间里被“变大”，从而被分配到语义粒度不同的层。放得太大，中远距离目标跑到更粗粒度的层，反而丢失了精细位置信息。而我用的检测头ROI Align对这种层分配又非常敏感，稍微偏一点，框回归就飘。
最终把缩放倍率收敛到0.8x、1.0x、1.25x这种温和区间，效果才稳定。如果你的骨架不是FPN而是单纯的连续下采样backbone，这个坑可能不明显，但如果用了FPN，一定要注意倍率跨度。
4.3 坑三：PyTorch 的 momentum 语义给更新强度带来的反直觉
这是我踩得最久的一个坑。我一开始重估BN统计量时，沿用训练时的默认momentum=0.1，结果跑了20个校准帧，running统计量几乎没动。后来才意识到，PyTorch里momentum=0.1的意思是每次更新只吸收10%的新信息，更新非常缓慢。而我需要的是快速把统计量“拖”到当前场景上，0.1这个值根本不够。
把momentum提到0.6以后，统计量大概十帧就能完成迁移，效果明显提升。但我也测了0.95，发现单帧噪声会让统计量跳变得太剧烈，尤其是雨雪天里偶尔一帧极亮或极暗的图，会把统计量瞬间带偏。最后把momentum稳定在0.4到0.7之间，配合20帧滑窗，效果最稳。
这里建议大家一定先确认自己用的框架里momentum到底是“旧值保留比例”还是“新值吸收比例”。不同框架的语义恰好相反，照着别人博客抄之前先翻一下源码。
4.4 坑四：多卡推理时，BN 统计量没有自动同步
我用四卡做并行推理时，一开始每张卡各自维护一套running stats，结果发现四张卡的结果不完全一致，平均之后性能反而有点毛刺。
排查后才意识到，PyTorch的BN统计量默认是per-device的。在DDP训练里分布式同步BN需要特意设置sync_bn，推理时更没人帮你同步。多卡TTA场景下，不同卡上校准batch不同，统计量自然不同。
解决方式有两种：要么只在一张卡上做统计量重估，然后把更新后的统计量broadcast到其他卡；要么在每步更新后做一次all_reduce。前者简单，但只适用于批量一致、负载均衡的场合。后者更通用，但要小心all_reduce操作本身带来的延迟。
4.5 坑五：校准 batch 的显存占用被严重低估
TTA本身就意味着每个前向要跑多个变换，统计量重估又要求一次forward里同时存在多个校准帧。两个叠加起来，显存压力翻了好几倍。
我第一次跑的时候，把50帧的滑窗全部塞到一个batch里，直接在3090上OOM。后来改成在每个校准step里做小批量循环，比如每次只放8帧，循环6次，累计更新统计量。这样显存峰值只取决于单次前向的batch大小，与总校准帧数无关。
这种“小步更新”方式虽然更新步数更多，但统计量收敛曲线更平滑，而且更接近在线推理的真实形态。所以最终线上方案也是按小batch流式更新来设计的。
4.6 坑六：预训练权重携带的统计量，本身可能就带偏
这个坑发生在从COCO预训练权重复制到BDD100K任务时。我直接加载了COCO的ResNet50权重，BN的running_mean和running_var全部还是COCO图像统计出来的。
虽然我对主干做了几个epoch的BDD100K微调，但当时batch设得比较小，统计量还没完全“漂移”到BDD100K上。后面测试时统计量重估一开始效果反而很差，就是因为旧的running stats和实际上该有的统计量差距太大，前几帧校准全在修正方向。
排查方法是：加载权重后先在验证集上随机抽几十帧做统计量“踩一踩”，看看统计量迁移幅度。如果迁移太大，就说明预训练权重的统计量和当前任务差距太远，需要多跑一些校准帧再谈TTA优化。
5. 实测效果：夜间和雨雾子集上的提升，以及开销评估
5.1 实验设置
模型用的是Faster R-CNN + ResNet50-FPN，检测头是标准的两阶段结构。训练数据来自BDD100K的晴天白天子集，测试集单独切分出夜间子集（约1500帧）和雨雾子集（约1200帧）。TTA的变换组合最终固定为水平翻转、缩放0.8x/1.0x/1.25x三档，合并策略用Weighted NMS。BN统计量重估开启layer3和layer4，momentum=0.6，滑窗20帧，每10帧做一次校准。
5.2 对比结果
以下是我在自己测试集上跑出来的典型数值（AP50，百分比）：
| 配置 | 夜间子集 AP50 | 雨雾子集 AP50 | 推理耗时（相对基线倍数） |
|---|---|---|---|
| 基线（无TTA、无重估） | 28.4 | 31.2 | 1.0x |
| 基线 + 水平翻转TTA | 27.9 | 29.8 | 1.1x |
| 基线 + 多尺度TTA | 31.1 | 33.7 | 1.7x |
| 基线 + BN统计量重估 | 30.2 | 33.4 | 1.15x |
| 基线 + BN重估 + 翻转TTA | 31.8 | 34.3 | 1.2x |
| 基线 + BN重估 + 多尺度TTA | 33.8 | 36.5 | 1.9x |
| 基线 + BN重估 + 全部TTA | 34.5 | 37.1 | 2.4x |
三组值得留意的结论：
第一，单独的翻转TTA在夜间子集上不仅没涨，反而掉点。这在统计量失配的场景下非常典型，也在前面的分析链条之内。
第二，只做BN统计量重估，什么都不加，夜间子集从28.4涨到30.2，雨雾子集从31.2涨到33.4。对于零额外损耗的改动来说，这个收益很值得做。
第三，BN重估和TTA的结合不是简单的加法。BN重估先把统计量基线修正了，TTA的增强变换才真正开始发挥作用。两者叠加后的增益明显大于各自单用的增益之和，这是我一开始没有预料到的。
5.3 定性观察：哪些漏检被真正解决了
定量结果之外，我挑了几类典型困难样本逐帧看效果。
夜间逆光场景，基线的典型问题是车灯区域对比度过高，检测头容易把车灯误判为一个高亮斑点，导致漏检。开启BN重估后，特征归一化尺度回正，车灯区域的激活不再饱和，漏检减少很明显。
雨丝干扰场景，基线的问题是小目标被雨线纹理淹没，置信度普遍偏低。多尺度TTA带来的增益主要是把这类目标的响应凑齐了，而BN重估让置信度整体抬升，漏检减少的同时误检也少了一些。
还有一个比较典型的场景是隧道入口，光线从极暗到极亮剧烈切换。这种情况下，固定running stats的模型会在出口那十几帧内产生大量误检，BN重估的滑窗机制能很快把统计量拉到当前亮度水平，误检潮被明显压制住。
5.4 推理开销怎么压到可接受范围
完整TTA加全部BN重估的耗时确实不低，2.4倍被认为是有点贵的。我在工程上做了两个优化。
第一个优化是重估频率降频。从每10帧校准一次降到每20帧校准一次，夜间子集AP只掉了0.3个点，但耗时下降了约15%。如果场景相对稳定，甚至可以只在前30帧做一次“热身校准”，后续不重估，效果也能保持大半。
第二个优化是选择性TTA。不是所有场景都值得开全部变换，我先用一个轻量统计量偏移检测器判断当前帧与running stats的偏差程度，偏差小就不开多尺度TTA，只保留翻转；偏差大再开完整TTA。这样一个夜间场景里大约只有30%的帧跑完整版本，平均耗时从2.4x降到1.6x左右。
6. 从实验到量产：哪些做法能真正落到车上
6.1 视频流推理不是单张图片，batch 约束要重新设计
很多实验里的“在线BN重估”都是按单张图片设计的，但自动驾驶是连续视频流，batch这个维度天然存在。车载推理通常batch=1，如果只拿当前帧的多个TTA变换来更新统计量，统计量方差特别大，容易受单帧噪声影响。
更好的做法是维护一个循环状态队列，保存最近若干帧的统计量摘要（均值、方差、计数），滑窗式更新。这样即使batch=1，统计量更新依然有足够多的样本支撑，不会被单帧极端亮度带偏。
6.2 场景切换检测器：让重估模块只在需要时启动
万物皆可开TTA会让算力爆炸，量产落地的核心是“条件触发”。我给重估模块加了一个前置判断：用当前帧的少量低层统计量特征与running stats的偏移量做阈值判断，超过阈值才触发完整重估。
这个机制在实际路测里效果很好。白天高速路段几乎不触发，夜晚城市道路和雨天会频繁触发，算力分配和性能收益的曲线非常平衡。类似的思路也可以用来做缓存管理，比如不同天气条件下分别缓存一套统计量，场景切换时直接加载预存统计量，进一步节省预热时间。
6.3 轻量模型同样适用，但收益幅度和层选择要重新调
有人可能会问：如果backbone换成MobileNetV3或EfficientNet-Lite，BN统计量重估还有用吗？
我试过MobileNetV3-Large为backbone的轻量检测模型，结论是有用，但收益比ResNet50小。原因在于轻量模型网络的深度浅，BN层数量少，统计量失配的影响范围窄。但胜在重估开销很低，几乎可以常开。
层选择上，轻量模型的“高层”BN可能只有最后两三层，重估全部BN层也不贵。侧重点变成了减少TTA变换数，因为轻量模型本身对变换的精度容错更低，变换太激进口会导致更大的误差。
6.4 我的建议：把统计量重估做成推理引擎里的标准开关
做了这么多实验之后，我的实际建议是：BN统计量重估这种模块，不应该以“论文实验代码”的形态存在，而应该做成推理引擎里的标准开关，默认开启，按场景触发。
它能解决的问题非常直接：不需要重新训练，不需要标签，不需要梯度和反向传播，几十行代码就能实现推理期域自适应。对比微调、对抗训练这些重方案，它带来的性能收益往往被严重低估。
在量产流程里，这个模块也不会干扰其他优化。它和TensorRT、量化可以共存，只要归一化统计量是显式传入的，量化的scale和zero point也能跟着更新，不会出现“重估后量化臂偏差”的问题。
6.5 后续可以继续扩展的方向
我目前还在尝试的一个方向是：不直接重估统计量，而是用卡尔曼滤波对BN统计量的变化进行平滑跟踪。这样在场景切换频繁的城市路段，统计量更新会更稳定，不会因为短时逆光或闪烁而反复抖动。
另一个更有意思的方向是：把“统计量偏移幅度”本身作为场景恶劣程度的可解释指标。比如统计量偏移超过某个阈值，就自动触发雨刮器或大灯这类车辆控制动作。这种感知结果向整车控制回传的思路，已经超出了纯检测模型的范畴，但很值得探索。
最后再分享一个小技巧：如果你暂时不想改代码，只想快速确认自己的模型是否也需要BN统计量重估，最简单的办法是拿一小段测试视频，把模型在eval模式下跑一遍，同时对每个BN层记录当前batch的均值和方差，和模型里的running stats算差。如果多个通道的偏差超过2倍，那么恭喜你，统计量重估大概率能给你带来至少两个点的提升。
