Sparse4D实战：用稀疏查询告别BEV，打造高效多模态3D检测

前两年做自动驾驶3D感知，绕不开BEV这个词。不管你是纯视觉路线还是激光雷达路线，最后都习惯把多路传感器的特征投到鸟瞰图上去，再用一个2D检测头输出目标框。BEV好用，但真的很“重”——你得维护一张几百乘几百的栅格特征图，感知范围一大、分辨率一高，计算量就成倍往上翻。Sparse4D走的是另一条路：不建BEV，直接用一组稀疏的可学习query，在多视角图像特征上做可变形注意力采样，再把历史帧信息通过时序anchor和时序注意力融合进来。我第一次把这个项目跑通的时候，最大的感受是：原来稀疏表征也能把多视角和时序融合做得这么干净，而且在nuScenes这种需要从历史帧预测物体速度的数据集上，指标还能做到很靠前的位置。

这篇文章我想从项目实战的角度，把Sparse4D的核心设计、为什么值得用它做多模态融合、具体怎么把LiDAR点云接进来、以及训练和部署中绕不开的那些坑，一次讲明白。适合正在做自动驾驶感知、想做多模态融合但被BEV庞大的特征图成本劝退的同学参考。如果你已经有视觉3D检测的基础，看起来会更快。

1. 先搞明白Sparse4D为什么值钱：它绕开了BEV这座大山

1.1 BEV方案的账：好用，但很贵

在Sparse4D之前，主流的多视角3D检测方案基本都围绕着BEV展开。思路也很好理解：每路相机都能看到一部分三维空间，把图像特征通过深度分布预测投影到统一的俯视图网格上，网格叠加起来就有了一个“从天上往下看”的特征平面。后续的检测、跟踪、规划模块直接在这个平面上工作，逻辑清晰，而且对传感器数量不敏感，多加一路相机，只要外参标定没问题，投到网格里就行。

但BEV方案有一个让人头疼的问题：计算量随感知范围平方增长。假设你在做60米乘60米的区域，栅格分辨率是0.5米，那就有120乘120共14400个网格位置。如果分辨率提高到0.25米，网格数就变成57600个。每个网格都需要查询图像特征、在深度维度上做体素投影，这个开销在训练和部署时都相当可观。我之前在实车上跑过一版BEV方案，GPU占用率常年顶在90%以上，边缘设备根本没机会部署，这就是现实。

另一个不舒服的点是量化误差。无论你网格画得多细，物体的边界都不可能完全落在网格线上。小目标、远距离目标在BEV特征图上往往只有几个像素点，检测头找回它们非常吃力。而BEV网格一旦确定，后续感知范围想要扩大，整个backbone和特征图尺寸又得重新设计，扩展性不算友好。

1.2 Sparse4D的破局点：把3D检测当成一个“稀疏查询”问题

Sparse4D的思路和BEV完全不一样。它的出发点，是把每个待检测目标看作一个可学习的稀疏query。这些query一开始只是一组随机初始化的embedding，在decoder里不断从图像特征中采样关键信息、更新自己的表示，最后直接回归出目标的3D位置、尺寸、朝向和类别。过程中不需要生成任何稠密BEV特征图，也没有网格化和量化。

这个思路其实和DETR把2D目标检测变成集合预测问题的思路一脉相承——既然目标在真实世界里是稀疏分布的，为什么特征表示也要用稠密网格？每个query携带一个3D anchor信息，代表它正在负责空间中的某个位置。通过稀疏可变形注意力，query能够自己决定去哪些视角、哪些图像层级上采样特征，这就把“全图稠密扫描”变成了“按需精准查询”。

我实际跑下来的体感是，Sparse4D的显存占用和推理延迟相比同规模的BEV方法要友好很多。尤其当你需要扩大感知范围时，只需要增加少量query，而不是把整张特征图重新算一遍。稀疏表征在这种场景下的扩展性优势非常明显。

2. 多模态融合需求：纯视觉方案的天花板在哪

2.1 纯视觉感知的“虚报”与“漏报”

纯视觉3D检测已经在很多场景下做得不错了，白天、道路结构清晰、标注规范的数据集上，指标甚至可以超过一些早期激光雷达方案。但一上真实道路，问题就浮现了。最典型的是夜间和逆光场景，图像里的目标对比度很低，车辆轮廓和背景混在一起，模型很容易漏检。还有就是雨雾天气，镜头上的水渍和雾化效果会让深度估计变得不稳定，远处的车可能直接“消失”在画面里。

另一个问题是视觉深度估计的固有歧义。单张图像里一辆小货车和一辆大客车，如果成像尺寸相同，模型其实很难判断谁离得更近。虽然通过多视角几何约束可以缓解，但在缺乏纹理的墙面、空旷道路、隧道场景下，深度分支依然会给出“看似合理其实错了”的值。这一点在紧急制动场景里特别致命——视觉估计前面障碍物还有25米，实际上可能只有18米，哪怕只有一个帧周期的误差，也直接影响决策。

激光雷达天然提供精确的深度，但它在某些场景下也不完美。远距离点云稀疏，反射率低的黑色车辆在点云里往往只有零星几个点；雨雪天气点云中还会出现大量噪声点。所以视觉和点云并不是“谁替代谁”的关系，而是互补大于竞争。这也是为什么行业里越来越强调多模态融合。

2.2 视觉和点云的互补，到底补的是什么

多模态融合的核心价值，是让两种传感器在各自“擅长”和“不擅长”的区域形成交叉验证。图像特征能提供丰富的语义信息，帮模型认清“这是一辆车”还是“这是一个广告牌”，而且视觉在远距离上的角分辨率通常优于激光雷达。点云则提供精确的几何位置和尺寸，让模型不需要从图像中勉强估算深度，尤其在车辆进入近场时，点云对横向位置的刻画非常准。

对3D检测来说，最理想的情况是：用图像特征做分类和语义判断，用点云特征做位置回归，再用历史帧信息来平滑时序变化。Sparse4D以稀疏query为核心的设计，天然适合这种分工。query本身代表一个3D位置假设，它可以自主地决定去图像特征上采样语义信息，去点云特征上采样几何信息，两个信息来源在同一个query内部完成融合。

我见过不少多模态方案是拿两个独立的网络分别提取视觉和点云特征，然后在最后输出层做加权平均。这种后融合方式实现简单，但两个模态在特征层面完全没有交互，检测头如果对其中一个模态置信度较高，另一个模态的信息几乎就被忽略了。稀疏query架构里，每个query在各层decoder中都会反复和不同模态的特征交互，融合发生的层次更深，信息互补得更充分。

2.3 为什么Sparse4D这类稀疏架构特别适合做多模态融合

如果我一开始就走BEV路线做视觉和点云融合，面临的第一个问题就是特征对齐。视觉投影到BEV需要预测深度分布，点云投到BEV只需要简单按坐标栅格化，两个特征图的生成方式和误差分布完全不同，对齐起来很别扭。你要么花大力气设计矫正模块，要么干脆只保留一个粗粒度的BEV特征做融合，分辨率上不去，精度自然受限。

Sparse4D这类稀疏架构不存在这个问题。每个query代表的是三维空间中的一个具体位置，它投影到图像上是像素坐标，落到点云里是体素坐标，投影关系由标定参数严格决定，不需要额外学习对齐。模型要做的只是让query从两种特征中采样，然后用注意力机制决定采什么、采多少。这样就把多模态融合问题，从“特征图怎么对齐”简化成了“特征怎么采样和加权”，难度一下子小了很多。

另外从工程角度看，稀疏query的融合计算量只和query数量相关。如果这个区域没有目标，模型不会在那附近浪费计算资源。这和“全场景稠密融合”的策略相比，部署在嵌入式平台上的压力小不少。

3. Sparse4D核心组件与多模态改造实操

3.1 四个核心组件拆解

要把Sparse4D改造到自己的项目里，首先得把它的核心组件吃透。我个人习惯把整个网络拆成四块来看：图像骨干网络与多尺度特征、3D anchor定义与初始化、稀疏可变形注意力、时序融合模块。

图像骨干网络负责从多视角图像中提取特征，一般用ResNet、Swin Transformer这类通用结构加上FPN，输出多尺度特征图。多尺度很关键，因为不同大小的目标需要在不同分辨率的特征层上去找。小目标要高层级的高分辨率特征，大目标和远距离目标则依赖语义更强的低分辨率特征。我在项目里测试过只用单尺度特征的效果，小目标召回率掉了差不多8个百分点，所以FPN这一层结构不能省。

3D anchor的定义是整个网络的“空间骨架”。每个query对应的anchor包含中心点三维坐标、长宽高尺寸、朝向角这几个量。初始化时可以让anchor均匀分布在自车周围的感知范围内，也可以结合路网先验做非均匀分布，比如车道区域多一些点。anchor初始化分布如果和数据集目标分布差别太大，训练初期loss会很难收敛，这一点后面细说。

稀疏可变形注意力是query更新信息的核心机制。每个query先通过一个小网络预测一组3D参考点，通常取3到6个，落在目标中心附近以及可能被遮挡的关键位置。这些3D参考点通过相机内外参投影到每一路图像平面上，得到对应的2D采样点，然后在相应层级的特征图上做双线性插值，最后用注意力权重把各视角特征加权聚合回query。整个过程不需要让query去看完整图像，看它关心的几个位置就够了。

时序融合模块承担了“记忆”功能。由于单帧检测看不出物体的运动方向和速度，Sparse4D会缓存上一帧所有query的anchor和特征。这一帧的query在更新时，可以把上一帧的anchor通过自车运动位姿变换到当前帧坐标系，然后让当前帧query与历史query做匹配和特征交互。这样模型就能从历史帧中推断目标的速度和运动趋势。

3.2 如何把LiDAR接进来：两种可落地的融合路径

在Sparse4D骨架上做多模态融合，我实践下来有两条比较稳的路径。第一条是把点云编码成3D体素特征，让query直接在体素特征上采样；第二条是保留点云原始坐标，用类似deformable attention的思路在稀疏点云中找邻域特征。

先说第一条。点云输入先经过体素化，体素尺寸我常用0.1到0.15米，然后用3D稀疏卷积（比如Spconv的SECOND结构）提取特征。Sparse4D的每个query有3D参考点坐标，直接根据这个坐标在体素特征上做三线性插值，就能拿到当前位置的点云特征。这个特征可以拼接进query的content embedding，也可以通过一个简单的注意力模块和视觉特征做融合。这条路径实现起来不复杂，效果也稳定，适合第一次做多模态改造的人。代价是引入了稀疏卷积算子，部署时需要确认推理框架支持。

第二条路径更“稀疏到底”。点云不体素化，而是保留原始点坐标。对每个query，在点云中搜索其参考点附近的K个最近邻点，用点与query参考点的相对位置计算注意力权重，聚合邻域特征。好处是范围远、稀疏的区域不会因为体素化而丢细节；坏处是K近邻搜索在训练时比较耗时，需要自己优化索引策略。我在小规模数据集上对比过，两条路径指标非常接近，但第二条部署时更灵活，不需要依赖稀疏卷积加速库。

无论选哪条，有几个细节都得处理干净。第一，相机和LiDAR的时间戳通常不是完全同步的，车辆在动，10毫秒的偏差在高速行驶时就意味着厘米级的空间误差。第二，外参标定的精度直接决定融合效果，如果相机和LiDAR外参有0.2度的偏差，在50米外就会造成约0.4米的投影误差，这个误差对3D框的影响非常显著。第三，两种传感器对同一目标的观测视角不同，同一个点在图像上可见但在点云中被遮挡，或者反过来。这些都要靠attention机制让模型自己学会在不同模态之间取舍。

4. 训练配置、评估指标与部署要点

4.1 损失函数和匹配策略

Sparse4D的检测头输出目标类别、3D框参数和速度。训练时用focal loss做分类损失，用L1损失做框回归。最关键的设计是目标分配方式。这里采用集合匹配的思路：把网络预测的所有query和真实3D框做匈牙利匹配，计算每个预测和真值之间的匹配代价，代价既包括位置和尺寸差异，也包括分类置信度，最终为每个真值框分配一个最合适的预测query来监督。

我踩过的坑是，如果query数量太小，一个真值框可能匹配不到query，导致该目标直接变成漏检。最初我用600个query，在小目标密集的场景里损失函数一直降不下去，后来把query加到1200个，问题立刻缓解了。但query也不是越多越好，数量翻倍训练显存和耗时都会显著增加。建议先通过可视化推理结果观察哪些区域有query覆盖，再决定增减。

训练策略方面，我建议使用至少2个epoch的warmup。Sparse4D这类稀疏注意力结构在训练初期非常不稳定，直接上大学习率容易让注意力权重发散。优化器用AdamW，权重衰减设到0.01左右，学习率峰值按batch size做线性缩放。时序融合模块的训练依赖历史帧缓存，如果显存紧张，可以先冻结时序部分训练基础检测能力，再放开时序模块联合微调。

4.2 评估指标怎么看：NDS和mAP谁更重要

nuScenes数据集提供了两个最常用的指标：mAP和NDS。mAP就是经典的平均精度，计算的是3D检测框匹配上的比例。NDS则是nuScenes的综合指标，它不仅看3D框准不准，还看速度、朝向、属性等预测是否准确。同样是50米的距离，你框的位置对了但速度估计偏了5米每秒，mAP可能不受影响，NDS会扣掉一截。

对自动驾驶来说，NDS更贴近真实需求，因为决策模块不仅需要知道目标在哪，还要知道它怎么动。Sparse4D在nuScenes val上的NDS表现相当好。纯视觉配置下，我记得官方release的checkpoint大约在0.43到0.55这个区间，具体要看backbone和训练轮数。加了LiDAR多模态分支后，mAP的提升通常非常明显，尤其在夜间和远距离场景，视觉深度估计一旦不可靠，点云特征就把精度托住了。

评估还有一个容易被忽视的维度：鲁棒性。你们如果看过一些质量评估相关的技术规范，会注意到里面强调多模态数据融合要兼顾不同场景下的稳定性，而不能只看一个平均指标。我在实车测试中会把数据集按白天、夜间、雨天、隧道分别切开来算指标，经常发现平均值差不多，但夜间类别的AP差了20个百分点以上。这种差异在标定数据集中看不出来，一定要单独跑一遍。

4.3 部署中绕不开的几个优化点

模型能跑到不错的效果只是第一步，真正难的是部署到车机平台上。Sparse4D里的稀疏可变形注意力包含大量gather和scatter操作，这些操作在GPU上表现不错，但在嵌入式设备上如果没优化好，反而比稠密卷积更慢。我建议先用TensorRT或ONNX Runtime的profiling工具看算子的耗时分布，重点优化采样索引生成和特征聚合部分。

多模态融合后，点云预处理经常成为新的性能瓶颈。体素化和稀疏卷积如果放在CPU上跑，一帧点云可能要额外花20到30毫秒，整体延迟就上去了。最好把点云预处理也搬到GPU上，或者用自定义CUDA算子一次性完成体素化和特征抽取。另外，如果融合分支只需要在query参考点周围取特征，可以只处理query附近的小范围点云，不必全场景体素化，能省下不少算力。

延时和帧率在工程上是硬指标。一般L2级别辅助驾驶要求感知链路端到端延迟在100毫秒以内，留给3D检测的预算大概在30到50毫秒。所以多模态改造不是简单把两个网络的特征拼起来，而是要精细地控制每一步的耗时。我的习惯是先用TensorRT fp16精度做一遍基准测试，再考虑有没有必要剪枝或蒸馏。

5. 常见问题与排查技巧实录

5.1 问题速查与定位思路

我把实际项目中遇到最多的几类问题整理成了一张速查表。这些问题如果只靠调参死磕，效率很低，正确的做法是先定位问题到底出在数据、模型、还是工程模块上。

这类问题有个共同特点：它们在指标曲线上暴露得比较晚，要尽早通过可视化和profiling去发现，不要等模型训完再回头查。

5.2 关于模态对齐，踩过的坑最值得说

模态对齐这个问题，我只用一句话总结：多模态融合里80%的异常，都是由于“两个传感器看到的不是同一个物理位置”造成的。项目初期我用了一套标定不够精细的外参，相机和LiDAR在近距离看起来基本吻合，但30米外就开始出现明显偏移。结果融合后的模型近距离检测精度很高，远距离目标的位置回归却会系统性偏向一侧，像有“惯性”一样。

排查方法其实不复杂：取一帧图像，把LiDAR点云按外参投影到图像上，看看点云轮廓是否和图像边缘贴合。如果边缘有系统性偏移，就说明外参还有残余误差；如果只在某些区域偏移，可能是传感器安装松动或标定实车状态和测试状态不一致。另外要把每一路相机的时间戳和LiDAR时间戳都打印出来，算一下平均延迟，不同的传感器时钟同步方案会导致几个毫秒到几十毫秒的差异，这个误差在车辆转弯时尤其明显，会让融合的特征整体“拖影”。

还有一个常被忽略的点：做多模态融合时，两种模态应该在数据增强阶段就打乱组合，而不是在模型中固定权重。我在训练时对图像做随机亮度扰动，同时对点云做随机丢弃部分点，通过这种方式让模型不能只依赖某一个模态，学出来的特征更鲁棒。实验对比下来，加了模态级dropout之后，夜间场景的mAP提升了大概3个百分点，效果相当明显。

最后再说一点关于query数量的朴素经验。很多刚接触Sparse4D的同学喜欢把查询数量调到四五千，觉得指标会一直涨。实际情况是，当query数量超过一定阈值后，很多query会退化成重复的“备胎”，不仅不贡献信息，还增加了匹配和采样的耗时。我在1280到2560的区间里调过几轮，最终选了一个中间值，效果和性能平衡得最好。如果想让模型处理更多目标，不妨先在同一query数量下把训练数据、增强和损失函数优化到位，比单纯加query更有效。多模态融合也一样，两个模态的信息利用率合理了，再谈加容量才有意义。