跑通MIT-BEVFusion的推理demo之后我原以为最难啃的骨头是那些视觉特征提取和点云体素化的部分。结果真正花掉我最多时间的是这篇标题里的两个模块fuser特征融合和decoder解码特征。你猜怎么着——fuser整个实现下来核心代码量还不到一百行但它是BEVFusion整个多模态对齐思路的浓缩而decoder看起来就是标准的DETR3D式Transformer实际读进去之后才发现有不少细节会直接影响训练收敛和最终mAP。这篇文章是系列第四篇前几篇我们陆续梳理了数据预处理、图像分支的视觉encoder、点云分支的体素化和BEV encoder。这篇我们聚焦到融合之后的事情图像特征怎么被搬到BEV空间、两个模态的特征用什么方式合成一个、以及最后那个Transformer decoder是怎么把BEV特征图“翻译”成一个个3D检测框的。适合已经把前面几篇消化得差不多、正准备啃bevfusion.py和bevfusion_head.py的读者。1. 先回到整体pipelinefuser和decoder在整条链路上的位置1.1 detector主流程里的一次数据接力要理解fuser和decoder先得打开mmdet3d/models/detectors/bevfusion.py看看BEVFusion这个detector在forward的时候到底是怎么串起两个模态的。核心入口就是extract_featdef extract_feat(self, points, img, img_metas): Extract features from images and points. img_feats, pts_feats self.extract_feat_twomodality(img, points) ... x self.fuse_features(img_feats, pts_feats, img_metas) ... return x这里img_feats是图像分支输出的多尺度2D特征pts_feats是点云分支输出的BEV特征。注意一个细节extract_feat_twomodality里两个分支是并行跑的互不干扰直到进入fuse_features才真正汇合。而fuse_features内部又分两步——图像特征先经过img_view_transformer也就是LSS那套视角变换从2D图像坐标系搬到BEV坐标系然后才交给self.fuser做真正的特征级融合。decoder则位于detector的更下游。extract_feat返回融合后的BEV特征x之后接的是pts_bbox_head也就是BEVFusionHead的forwarddef forward_pts_train(self, pts_feats, img_feats, img_metas): ... outs self.pts_bbox_head(pts_feats, img_feats, img_metas) ...这里传入的pts_feats其实已经是fuser输出的融合特征了。所以整条链路可以概括为图像2D特征 → 视角变换 → BEV特征与点云BEV特征 → 融合 → 融合BEV特征 → Transformer decoder → 一组3D检测框。1.2 为什么这两个模块值得单独拆开讲从代码量上看conv_fuser.py不到一百行bevfusion_head.py相比之前的SECOND检测头也算不上长但它们分别代表了BEVFusion的两个核心设计决策。fuser层面的决策是多模态融合到底应该做得多复杂在BEVFusion之前不少工作倾向于在特征提取阶段就引入跨模态交互或者使用基于attention的融合模块。但BEVFusion的答案是把两个模态各自在BEV空间对齐之后一个简单的concat 1×1卷积就足够了。这个看似“过于简单”的设计恰恰是全文的核心卖点之一。decoder层面的决策是检测头还要不要继续用anchor-based或者center-based那套BEVFusion选了DETR3D式Transformer解码器用一组可学习的object query去BEV特征图上“查询”目标。这个设计的直接好处是省掉了NMS后处理同时天然支持多类别的端到端检测。所以这两个模块一个做减法一个做加法合在一起才构成完整的BEVFusion检测头部。下面我们分别展开。2. ConvFuser看起来只是concat实际藏着三层设计考量2.1 图像分支走到这里之前发生了什么先说清楚一个前提fuser拿到的那份图像BEV特征到底是怎么来的。如果不理解这一步后面cat的语义就是不完整的。图像分支的输出是来自视觉backbone通常是Swin-T或ResNet系列的多尺度2D特征图每层特征图上的每个位置只对应图像上的一小片区域没有深度信息。要把它变成BEV特征就必须走LSS那套lift-splat流程先对每个像素预测一个深度分布然后把2D特征“抬升”到3D视锥空间最后通过外参和内参把3D点投影到BEV网格上做池化。在bevfusion.py里这部分实现在img_view_transformer中配置里对应的类型通常是LiftSplatShoot。它的输出fused_img_feats是一个(B, C, H_bev, W_bev)的BEV特征图空间分辨率和点云分支的BEV特征完全一致。这个一致性是融合的前提——两个特征图只有尺度和坐标系对齐了融合才有意义。这里有一个很多人容易忽略的参数LiftSplatShoot里的图像特征范围img_feat_height、img_feat_width和BEV网格的尺寸grid_size之间的对应关系。如果配置不当图像BEV特征里某个位置代表的空间范围会跟点云BEV特征对不上后续融合出来的特征就是错位的。我们在后面第五节会专门讲这个坑。2.2 融合运算内部做了什么concat 1x1卷积背后的设计取舍现在看mmdet3d/models/fusion_layers/conv_fuser.py这个文件的核心就一个ConvFuser类。我把关键代码抽出来class ConvFuser(BaseModule): def __init__(self, in_channels[80, 80], out_channels80): super().__init__() self.conv ConvModule( sum(in_channels), out_channels, kernel_size1, conv_cfgdict(typeConv2d), norm_cfgdict(typeBN2d, eps0.001, momentum0.01), act_cfgdict(typeReLU, inplaceTrue) ) def forward(self, inputs): inputs [self._network_input_transform(input) for input in inputs] return self.conv(torch.cat(inputs, dim1))forward就做两件事先把输入在通道维度上拼接再过一个1×1卷积。卷积核后面带BN和ReLU。先说为什么是concat而不是加权求和。如果两个模态的特征已经是BEV空间对齐的那么concat保留了两种特征的全部信息后续1×1卷积可以通过学习通道权重来自动决定哪些通道应该被信任、哪些通道是冗余的。相比之下加权求和要求网络在融合前就必须决定两个模态的贡献比例而这个比例往往是空间变化的——不同位置两个模态的可信度不同比如远处相机特征可能更可靠被遮挡区域点云特征更可靠concat给了网络逐通道逐位置调整的空间。再说为什么是1×1卷积而不是3×3。融合阶段的核心任务是通道间的重标定而不是空间信息传播。空间结构在图像分支的视角变换和点云分支的BEV encoder阶段都已经形成此时如果再引入3×3卷积扩大感受野反而会把两个模态在空间上的误差进一步放大。1×1卷积不会跨像素混合信息融合出来的BEV特征在空间分辨率上严格等于输入这对后续Transformer decoder的reference point采样是一个友好的性质。关于这里的BN参数eps0.001, momentum0.01也是一个细节。跨模态融合后的特征统计量波动比单模态大BN如果更新太快momentum太大容易导致训练不稳定。0.01的momentum让running mean和running variance的更新更平滑这是从实际训练稳定性角度做的取舍。2.3 为什么作者说“不用attention是故意的”在首次读到论文时我在“为什么不用attention做融合”这个问题上纠结了很久。作者在论文里给了一段很关键的话不同传感器对精确的BEV定位同等重要因此无法依赖一个固定的先验来决定哪个模态应该被强调。这句话值得展开。基于attention的融合模块比如经典的CrossAttention本质上是让网络根据当前输入的内容动态决定token之间的交互权重。这看起来很灵活但也引入了一个风险网络可能会偷懒学到“某个模态整体更可靠”的固定偏好从而在训练中逐渐忽略另一个模态。一旦遇到部署环境中相机过曝或者LiDAR被遮挡的情况模型性能就会断崖式下跌。BEVFusion选择concat 1×1 conv实际上是一招以退为进不做模态间的动态交互只做通道级的静态重标定反而更容易保持两个模态的独立性。从鲁棒性的角度说这种“简单融合”在模态缺失时表现得更好——因为特征通道里依然保留了两个模态各自的原始信息下游检测头可以在线调整对它们的依赖。这给我们的工程启示是在做一个多模态项目时不要一上来就上复杂融合模块。先在BEV空间把两种模态的特征对齐然后用最简单的方式融合起来跑通全流程之后再根据可视化结果决定是否有必要引入更复杂的交互机制。BEVFusion能在nuScenes上拿到SOTA很大程度上就是因为他们把精力花在了“让两个模态都把自己的活干好”上而不是花在融合模块本身。3. Decoderobject query如何从BEV图里“捞”出3D框3.1 BEVFusionHead的整体职责划分打开mmdet3d/models/dense_heads/bevfusion_head.py这个head的设计思路和传统的anchor-based检测头完全不一样。它不是在前景背景分类的基础上回归anchor偏移而是直接学习一组object query到检测框的映射。BEVFusionHead的__init__会接收一大票参数其中包括num_classes目标类别数nuScenes下通常是10类num_queryobject query的数量默认300num_reg_fcs回归分支全连接层的层数transformer配置好的解码器bbox_coder预测结果到3D框的转换器loss_cls、loss_bbox、loss_speed各类损失forward的入口大致是def forward(self, x, pts_feats, img_feats, img_metas): bs x.size(0) query_embeddings self.query_embedding.weight # (num_query, embed_dims*2) ... hs, init_reference, inter_references self.transformer( x, query_embeddings, ...) ... outs self._decode_head_forward(hs, ...) return outsx就是上一步fuser输出的融合BEV特征。hs是Transformer decoder每一层的输出shape通常是(num_decoder_layers, bs, num_query, embed_dims)init_reference是每个query初始预测的空间参考点inter_references是每一层预测的参考点配合iterative refinement。后面会把hs分别送入分类分支和回归分支得到每个query的分类logits和回归值再用bbox_coder解码成真正的3D框。3.2 object query到底查的是什么这是整个decoder里最核心的概念。query_embedding是一个nn.Embedding(num_query, embed_dims * 2)在代码里它被拆成两半一半当作内容查询content query另一半当作位置查询positional query。这两半在Transformer的每个解码层里都会被用到前者负责“我到底要检测什么”后者负责“我要去BEV图的哪个位置找”。你可能要问既然有两个模态的特征都融合在x里了为什么还要用一组固定的可学习query而不是直接对BEV特征做像素级分类这就要回到DETR系列的设计初衷目标检测的天然输出是一个集合一组框而不是一张逐像素的mask。用固定数量的query去预测固定数量的候选框让网络自己学习“哪个query负责哪个目标”就省掉了传统检测里最麻烦的NMS后处理。但是固定query有一个隐患如果两个query同时“看中”了同一个目标怎么办答案在后面的self-attention里。3.3 decoder layer里的self-attention和cross-attention各自作用BEVFusion的decoder层结构沿用了DETR3D的设计每个decoder layer大致包含以下几个子层self-attention所有object query之间做交互让query之间互相“打招呼”避免重复检测同一个目标。这相当于在集合层面做了一次隐式的去重。cross-attention每个query根据自己当前预测的reference point到BEV特征图上采样对应位置的特征然后和query内容做注意力交互。这是query真正从BEV特征里“读取信息”的环节。FFN对query特征做非线性变换增强特征表达。其中cross-attention的实现细节值得多看两眼。它并不是对整个BEV特征图做full attention那样计算量太大而是借鉴了DETR3D的思路每个query先用一个小MLP从自身预测出一个2D参考点在BEV特征图上的归一化坐标然后用这个参考点对BEV特征做双线性采样。这样每个query只和BEV特征图上的一个位置交互计算量小很多而且可解释性更强——你能直观看到每个query在“看”BEV空间的哪个位置。在代码实现里query预测reference point用的是self.reference_points这个MLP输出后经过sigmoid保证坐标落在[0,1]之间然后映射到BEV特征图的坐标范围。采样使用grid_sample或者手写的双线性插值。每次decoder layer都会重新预测新的reference point实现逐层refine前几层可能只能框出目标的粗略位置后面几层的参考点会越来越准。整个decoder默认是6层每一层的输出都会送到检测分支做一次预测训练时每一层都会计算lossauxiliary loss推理时默认只用最后一层的输出。3.4 从解码结果到3D框bbox_coder与损失函数decoder的最终输出hs经过分类和回归分支后得到两类结果。分类分支输出的是(bs, num_query, num_classes)的logits回归分支输出的是(bs, num_query, 10)的原始回归值10维分别对应中心坐标(x, y, z)、尺寸(w, l, h)、朝向角yaw、速度(vx, vy)。注意这里回归的是相对reference point的残差而不是绝对坐标。bbox_coder负责把这些残差还原成最终的3D框bboxes self.bbox_coder.decode( preds, reference_points, img_metasimg_metas)decode过程做的事情可以简单理解为pred_center reference_point delta_centerpred_size exp(delta_size) * anchor_sizeanchor_size是一组可学习的先验尺寸pred_yaw delta_yaw reference_yaw这样的逆变换。至于损失BEVFusion用的还是DETR3D那套。分类用Focal Loss因为query预测的目标类别分布严重不平衡大部分query对应的都是背景回归用L1 Loss在center、size、yaw、velocity上都算然后按一定的权重加总。target assigner用的是Hungarian算法在预测框和GT框之间计算一个综合cost分类cost 回归cost然后做二分图匹配确定每个GT框对应哪个query去负责预测。关于权重配置我在配置文件里常用的一组是损失项类型权重loss_clsFocalLoss2.0loss_bboxL1Loss0.25loss_speedSmoothL1Loss0.25loss_bbox权重给得比loss_cls低是一个常见经验回归任务在训练初期变化大权重太高容易干扰分类分支的正常收敛。先让网络学会“哪里有目标”再慢慢把框的位置调准这个顺序在实战中屡试不爽。4. 配置文件里的关键参数读代码必须结合config看4.1 transformer配置和head配置的对应关系很多人在读bevfusion_head.py的时候会忽略head初始化时的transformer参数其实是一个完整的配置对象。在bevfusion_lidar-cam_voxel0075_second_secfpn_8xb4-256e_nus-3d.py里head部分的配置大致长这样pts_bbox_headdict( typeBEVFusionHead, num_classes10, in_channels512, num_query300, num_reg_fcs2, transformerdict( typeBEVFormerTransformer, num_feature_levels4, encoderdict(...), decoderdict( typeDetectionTransformerDecoder, num_layers6, return_intermediateTrue, transformerlayersdict( typeDetrTransformerDecoderLayer, attn_cfgs[ dict(typeMultiheadAttention, embed_dims256, num_heads8, dropout0.1), dict(typeDetr3DCrossAtten, embed_dims256, num_heads8, dropout0.1) ], feedforward_channels512, ffn_dropout0.1, operation_order(self_attn, norm, cross_attn, norm, ffn, norm) ) ) ), bbox_coderdict( typeNMSFreeCoder, post_center_range[-61.2, -61.2, -10.0, 61.2, 61.2, 10.0], max_num300, score_threshold0.1, num_classes10 ), ... )这个配置里有两个关键数字值得展开。第一个是num_query300。它的含义是无论当前场景里实际有几个目标网络都固定预测300个候选框然后通过评分筛选出最终结果。300这个数字不是拍脑袋定的它需要覆盖nuScenes单帧里的最大目标数同时又要兼顾显存开销。你把它改成200或500试试就知道改小会导致某些拥挤场景漏检改大则明显增加训练显存和训练时间。第二个是num_feature_levels4。这是说decoder可以从4个不同分辨率的特征层上采样reference point对应的特征。BEVFusion的backbone不同stage输出的特征分辨率不同多尺度特征能让decoder同时关注到大目标的整体结构和小目标的细节。但注意配置里的num_feature_levels必须和视觉backbone实际输出的特征层数一致否则level_start_index会越界直接报错。4.2 loss权重和target assigner的匹配逻辑head的loss_cls、loss_bbox参数和train_cfg里的assigner是配套使用的。NMSFreeCoder和Hungarian assigner的精妙之处在于它让检测变成了一次“二分图最优匹配”而不是传统的“每个anchor独立预测”。在配置中你会看到train_cfgdict( assignerdict( typeHungarianAssigner3D, cls_costdict(typeFocalLossCost, weight2.0), reg_costdict(typeBBox3DL1Cost, weight0.25) ) )这里的weight必须和loss里的权重保持一致因为assigner计算匹配cost的时候也是用分类cost加回归cost。如果两边权重不一致可能会出现“训练时更看重分类匹配时却更看重回归”的割裂情况导致训练不收敛。我一开始没注意这个匹配结果训练到一半发现loss在下降但可视化检测框始终是乱的。后来排查发现就是assigner的weight配错了。这个坑值得记录一下。5. 实操中遇到的几个真坑和排查思路5.1 显存爆炸num_query和decoder层数的影响我第一次在8卡机器上尝试跑BEVFusion训练开到一半就OOM了。仔细排查后发现问题出在num_query300和decoder层数6的组合在梯度反传的时候会保留每一层decoder的中间变量显存占用比想象中大得多。如果你也遇到OOM可以按下面的顺序排查先把num_query降到200看显存是否明显下降。如果降了说明query相关的attention是显存大头。如果num_query已经很小还是炸考虑把decoder的num_layers从6降到4或者把feedforward_channels从512降到256。注意这会影响精度只能作为临时方案。检查img_view_transformer里的depth维度这个维度如果配得过大会在lift阶段生成巨大的中间张量也是显存大户。5.2 融合前归一化两个模态特征的量纲问题fuser的concat操作要求两个输入在数值范围上不能差太多。点云BEV特征经过SECONDFPN后特征数值通常集中在0附近而图像BEV特征经过LiftSplatShoot后由于经过了深度分布的加权求和数值范围可能明显偏大。如果直接concat1×1卷积的初始loss会很大训练前期不稳定。我的做法是在进入ConvFuser之前对图像BEV特征做一次LayerNorm或者简单的除以标准差。但注意BEVFusion原始代码里没有这个操作所以如果你加了需要同步调整BN的momentum否则BN统计量会被打破。如果你不想改代码也可以用更保守的方案把图像分支的损失权重调低一点让网络前期主要靠点云分支学后期再让图像分支跟上。5.3 可视化debug怎么确认fuser输出真的“融合”了训练过程中怎么判断fuser的输出不是某一模态单独在起作用我最常用的手段是直接把融合后的BEV特征做空间维度的平均池化得到(B, C)的向量然后做PCA降到3维映射到RGB空间可视化。如果图像分支单独工作可视化结果会是沿图像视角方向有清晰的纹理边界如果点云分支单独工作边界会是点云稀疏度决定的。两者都出现说明融合基本健康。另一个更直观的方法是分别把图像BEV特征和点云BEV特征单独送入decoder比较各自的检测结果。如果图像单独跑出来的框和融合后跑出来的框在重叠区域分布一致说明融合没有引入空间错位如果差别很大优先检查LiftSplatShoot的坐标变换参数。5.4 推理时BEV特征范围配置最后一个容易被忽略的配置是post_center_range。这个参数在bbox_coder里定义了最终检测框中心点的合法范围在nuScenes的BEV坐标系下通常是[-61.2, -61.2, -10.0, 61.2, 61.2, 10.0]。它必须和训练时BEV特征图对应的空间范围一致。如果训练时BEV网格覆盖的是前后左右各51.2米推理时却设成61.2米decoder输出的reference point映射关系就会错乱导致大量检测框堆在边缘。我在一个自定义数据集上犯过这个错数据集中目标基本都在近处于是我把BEV范围缩小了但忘了同步post_center_range结果一到推理阶段就开始疯狂在远处产生假阳性框。排查到最后才想起来改回一致后就正常了。这属于“配置对不上”的经典案例。说实话fuser和decoder这两个模块花了我不少时间但啃完之后再回头看整个BEVFusion会觉得整个框架的逻辑意外地清爽前面所有复杂的backbone和encoder最终都只是为了在BEV空间交出两张对齐好的特征图之后fuser用一次简单的concat加1×1卷积完成模态融合decoder用一组可学习的query把融合特征变成检测框。两个模块都算不上“炫技”但组合在一起却取得了非常扎实的效果。如果你也在读这份代码建议把conv_fuser.py和bevfusion_head.py放一起反复对照尤其注意配置文件里那些看似不起眼的参数——很多时候代码逻辑本身不难难的是把代码和配置对应起来。