导读：
10月18日，最新一期地平线「你好，开发者」自动驾驶技术专场在智猩猩顺利完结直播。专场由地平线感知算法工程师林天威主讲，主题为《面向端到端自动驾驶的稀疏感知通用架构探索》。
本文是此次专场主讲环节的实录整理。如果对直播回放以及Q&A有需求，可以点击
大家晚上好，我是今天的主讲人林天威，是地平线的感知算法工程师，非常感谢大家能够来参加本期专场。今天我讲解的主题是《面向端到端自动驾驶的稀疏感知通用架构探索》，会主要介绍我们在稀疏感知算法方面的一些探索工作和思考。
今天的介绍内容主要分为四个部分，分别是研究背景与现状，长时序稀疏化3D检测算法Sparse4D的V1 & V2版本，稀疏通用感知架构设计的想法，以及我们认为在稀疏感知的范式下未来值得探索的方向。
01 3D感知研究背景与现状
首先从端到端自动驾驶说起。端到端自动驾驶是目前自动驾驶领域最受关注的方向之一。如图所示的就是今年CVPR Best Paper 的工作UniAD。
传统的自动驾驶系统通常会采用级联式的架构，在模块与模块之间通常传递的是结构化信息，同时在系统内存在着海量人工设计的复杂规则。这使得整体的自动驾驶系统复杂性高、难以联合优化以及迭代周期比较长。
而端到端的设计思路则带来了全新的可能性。在端到端架构中，首先各个主要的模块都是基于神经网络的形式设计；其次模块间也不再只是传递结构化信息，而是同时传递稀疏实例特征表示，这使得从感知到规控的整体系统可以进行联合优化；最终的planner模块也能从更加靠前的阶段获得更丰富的信息。
但这里会带来一个问题，就是在端到端自动驾驶系统中，我们是否需要显式的去做感知的模块？目前也存在着一些方法是不产生中间结果，可以直接通过图像输入，直接输出控制信号的彻底端到端技术路线。这种技术路线会存在彻底黑盒、解释性差的问题。而从自动驾驶产品安全性的角度来看，把每个模块都网络化并串联在一起的技术路线，会更加可靠可行，也就是UniAD技术路线。因此，还是非常有必要去做显式的感知结果的输出。
在这样的架构设计下，主要讨论的问题是：对于一个面向落地的端到端纯视觉驾驶系统，我们需要怎么样的通用的感知后端呢？我个人认为主要包括这四个方面：
1、需要具备强大的感知性能，能够输出高质量的实例化特征；
2、需要高效的融合多视角+时序的视觉信息，速度快，且对于板端芯片比较友好；
3、感知的范围方面能够具备All in One的能力，不需要多个模型去补充不同范围的视野；
4、需要有可靠多任务能力，能够适配并良好的支持动态、静态，像HDMap的高精地图重建等各种任务。
在更早期的阶段，自动驾驶系统中通常会采用后融合感知系统，如这张图所示。对于不同视角图像，我们会分别检测里面的物体。这样显而易见会带来两个问题：一个是摄像头之间有重叠的区域，一个目标可能会被检测到两次；第二就是有一些很大的目标，比如大卡车，它会跨多摄像头，使得每个视角中都没有办法完整的检测到整体的检测框。为了解决这两个问题，这类方法就需要有一个目标级的多传感器融合、目标级的时序融合和滤波模块，这样就构成了我们常说的后融合感知系统。
后融合感知系统会有几个明显的不足：
1、融合模块，仅仅收到了结构化的感知结果，信息不够充足；
2、需要有一些前提假设，比如说感知误差分布、目标运动模型，需要很多超参数进行调优，一定程度上限制了整个感知系统的上限；
3、需要维护一套独立于模型以外的融合模块，这使得系统的复杂度偏高。
因此，这两年业界更多地在推行的是中融合方案，即先对不同视角的图像提取特征，然后在一个统一的特征空间下融合这些特征，最后再产出感知结果。这个坐标系，一般指自车的VCS 3D坐标系。
这张图演示的是相关方法的演进。
其中大部分都是基于BEV的方法，用某种方式将图像视角特征转到BEV特征空间，也就是一个高度方向拍扁的自车3D坐标系空间下，再用一个检测的Head实现目标检测。BEV这张图的尺寸通常比较大，比如一般常见的论文里面会用128×128 size，但在实际中，我们甚至会用两倍大小的BEV特征图。从图像特征空间向BEV层空间转换过程，是一个非常密集的计算过程。有很多的方法也是在优化这部分的速度，比如说Fast-BEV 、BEVPoolv2 等。
而另外一类方法没有提取显式的BEV特征，比如 PETR 系列工作和我们的Sparse4D 系列工作。它的关键思想就是构造3D空间下Query，用3D空间的Query去获取不同视角的特征，去聚合不同视角的特征，再传出检测的结果。
下面我先介绍一下比较有代表性的BEV和稀疏的方法。
首先是BEV方法中的2D到3D的技术路线。这也是我自己的叫法，指的是BEV特征的生成过程中，将2D 图像上的特征向3D 空间投影。最早的工作是Lift，Splat，Shoot。它的核心思想，是将图像上的每个点看作是一条射线。这条射线在3D空间中具体位置可以根据相机内外参获得，在这条射线上会去采样很多点，对于每个点去估计一个深度的置信度（即这个深度位置有物体的概率）。射线整体上的深度置信度，通过softmax可以规划为1。我们将图像上这个点的特征乘上射线上每个点的置信度，就可以获得射线上每个点的特征。基于这个思想，BEVDet 进一步实现了BEVPool算子，能够比较高效地实现升维后的视锥多视角图像特征向BEV 特征的快速转换，获得了很好的效果。
在BEVDet基础上进一步发展的BEVDet4D算法，引入了时序能力。具体做法比较简单，就是把上一帧的图像特征和单点帧图像特征拼接在一起，再过一个卷积进行融合，这就是我们称之为一种两帧短时序的时序融合方式。它能够比较简单地去获得视频时序流动的运动信息。
通过刚才的介绍可以知道，BEVDet 特征投影方式效果是十分依赖于视锥深度估计的效果，那么如何去提升这个特征点投影效果呢？我们就需要获得更精准的深度估计。
一个比较直观的做法就是给深度估计加显式的监督，也就是BEVDepth的做法。BEVDepth的监督是来自于稀疏Lidar 点云。那么再进一步如何再去提升深度估计效果呢？BEVStereo这个方法，就是将时序上的前后帧看作是一组双目图像，引入了双目深度估计中的思想去进一步提升深度估计的效果。
后续的像SOLOFusion工作，就更进一步将多视角的几何的深度估计和长时序的策略融合结合在一起。它核心就包括两个模块，一个是高分辨率短时序模块，主要是基于前后帧的多视角几何的思想，去获得更加精确的深度估计，并初步获得BEV特征；再用BEV空间下的低分辨率长时序模块去融合，最多达到16帧的较长时序的BEV特征，这样它就获得了一个很好的效果。
但随着帧数越来越多，时序方法也出现了低效率问题。以SOLOFusion为例子，在每帧的前向过程中都需要融合过去16帧的特征。这样做的问题是：一方面整体网络中存在着很多的冗余计算，另一方面系统中需要缓存非常多的历史BEV特征。又因为BEV特征图通常比较大，这样的做法在系统带宽比较低的车端，自动驾驶系统是很难使用的。
今年，VideoBEV提出了一种更加简单的Recurrent时序工作方式。
简单来说就是将当前帧提取的BEV特征和上一帧融合后的BEV特征进行融合，再将融合后的BEV特征传递到下一帧。这种有点类似于RNN的形式，可以让帧间传递的融合BEV特征，理论上能够保留较长时序的特征信息。当然这种循环神经结构也会存在着很强的遗忘特性，因此实际上传递的长时序信息是比较有限的。VideoBEV这种形式对于实际车端使用是比较友好的，因为它的计算量始终是恒定的，指标提升也非常明显。
这张实验对比图是来自于VideoBEV。
这张图片展示了基于Lift-Splat 2D到3D的BEV生成方式的技术发展路线。从多视角的特征融合，到时序的短时序融合，再到点云深度监督，再到多视角几何的估计，再到SOLOFusion长时序，再到VideoBEV Recurrent时序的形式，一步步的把这个方法框架的效果提升，使它更加适合真实场景的使用。
另外一条与2D到3D路线相对的，我叫做3D到2D的特征投影技术路线。
这类方法中，我们先会设定3D空间中的一系列点。比如，将BEV空间中地面的某个点，根据相机内外参投影到多视角图像上，再去采样对应的特征作为3D空间点的特征表示。这类方法里面最有代表性的方法是基于IPM的BEV方法 。IPM，我个人认为是一个最简单快速的BEV算法。它的做法是将每个BEV Grid看作所有物体在地面上，把BEV Grid的地面道路上的点投影到图像上去，获得BEV Grid的特征。可以看出，IPM依赖的一个前提是所有物体都在地面高度上，但实际场景中的高于地面的物体其实是不符合假设的，会存在很多的特征畸变。如果大家开车的时候会看360影像，会对这一点非常熟悉。因为360影像其实就是比较小范围的基于IPM的BEV。
那么如何去优化IPM的效果，有很多改进方法。像去年非常有影响力的工作BEVFormer，我认为在某种程度上可以看作是一种IPM的改进。
BEVFormer方案主要包括两个主要的模块：一个Spatial Attention，另一个是Temporal Attention。我们先看Spatial Attention。它的做法是对于BEV Grid上的每个点视为Query，每个Query会在对应的grid的高度方向上划分多个voxel，每个voxel里面去用Deformable Attention采样多点，然后全部融合在一起去作为Query也就是 BEV Grid的特征。如果说刚刚的IPM是一个BEV Grid采样一个点，BEVFormer就是一个Grid采样了非常多的点。远远更加充分的点采样和特征融合，使得BEVFormer获得了比IPM好很多的效果。时序方面，BEVFormer用的也是一个两帧的短时序融合方式，采用的也是Deformable Attention的形式进行融合。
BEV类的方法可以算是当前多视角3D感知的一个主流路线，但是在实践中BEV方法也存在很多的问题。
我觉得各类问题的根源在于，需要感知的目标在三维空间中通常是十分稀疏的，存在着非常多的无效区域。而从图像空间到BEV空间转换，是一个稠密特征到稠密特征的重新排列组合。它计算量非常大，而且计算量与图像尺寸以及BEV的图像尺寸是成正相关的，这使得BEV模型的感知范围、感知精度以及计算效率其实是非常难平衡的。
在我们常用的nuScenes数据集中，一般感知范围会设置为长宽 [-50m, +50m] 的方形区域，但在实际场景中，我们通常会需要达到单向100米，甚至200米的感知距离。如果说我们想要保持BEV Grid的分辨率不变，那么就需要去增加BEV特征图的尺寸，这会使得端上的计算负担和带宽负担都非常重。如果要保持BEV特征图的尺寸不变，就需要更加粗粒度的BEV Grid，那么它的感知精度就会下降。因此在车端有限的算力以及带宽条件下，BEV方案的一个常见难点是比较难以实现远距离感知与高分辨率感知的平衡。
这个问题怎么解决？业界一个比较常见的做法是补充一个或者若干个前视或者前视窄角模型，比如2D模型，专门去做特别远距离的感知。但是这又带来一个问题，如果有好几个3D检测的感知来源，就还得再去做后融合，这使得模型又变得复杂起来了，没有真正消除掉后融合，也很难真正去做到端到端。
另外一个问题是BEV空间是一个压缩高度信息的三维空间，这使得它对于一些高度方向上敏感的任务比较难完成。一类任务是标志牌、红绿灯检测。好在标志灯、标志牌、红绿灯检测可以通过2D任务来解决。另外一类，比如异形车，它不同高度，形状不一样，用拍扁的方式，很多时候不一定能够很好地解决。
那么，与这种生成密集特征相对应的就是我们称之为稀疏感知方法，比较早的有代表性的就是DETR3D。
它的稀疏体现在，并没有像BEV一样对BEV 3D空间中所有点都去转换特征，而是只对我们感兴趣的目标进行了3D特征的转换和融合，主要流程包括以下几步：
·和大部分方法一样，也是提取多视角的特征；
·初始化Query，用特征编码方式初始化若干的Object Queries；
·将Query特征通过MLP映射到3D空间的参考点坐标，将这个点通过相机内外参投影到图像平面上，并去采样多尺度特征，融合后采样特征来作为Query的特征更新；
·通过更新后的特征，迭代式地去更新Query的信息，并去预测目标框信息；最后用二分匹配方式去跟真值进行关联，再进行训练。
另外一个比较有代表性的方法是PETR系列。
PETR系列方法与DETR3D的一个最大区别在于：PETR里面Query特征是通过Cross Attention直接和所有的图像特征进行交互，而非类似Deformable Attention这种基于采样的方式与图像中的特征进行稀疏性的交互。在PETR这种形式下，关键的问题在于：如何将图像特征跟3D的信息关联上？PETR的方法是将相机的视锥射线基于内外参投影到3D的自车坐标系下，基于这些点的坐标进行编码，得到3D的位置编码，然后加到图像特征上去做。
在此基础上，PETR-V2进一步引入了两帧形式的时序融合，和一个更加优秀的3D的位置编码策略。
更进一步，近期StreamPETR方法，类似于VideoBEV引入了Recurrent的时序融合策略。
但不同的点是采用Recurrent时序融合策略是实例级别的融合。具体做法是把t-1帧获得的检测结果作为Query，通过一定的隐式的运动变换后，把它推到第t帧作为一部分的输入Query。来自上一帧的Query和这一帧新初始化的Query，一起进入Decoder 模型，得到新一帧的感知结果。我们的Sparse4D-V2版本方法，也采用了一个类似的实例级别的Recurrent时序融合策略，后面我会介绍两者之间的设计上的差异。
在上面的几个方法中， DETR3D是稀疏Query加上稀疏的特征交互；PETR则是稀疏的Query加上密集的特征交互；PETR-V2 和StreamPETR 则分别引入了两帧的时序和Recurrent的时序形式。
PETR系列方法效果非常好，但可能存在一个问题是稠密的特征交互，特别是在板端算力有限的情况下，对于比较高分辨率的图像特征输入不够友好，耗时会随着输入图像分辨率的增加而非常快地增长。
我们这一系列研究出发点是，希望实现一个高性能、高效率的长时序纯稀疏融合感知算法。这条技术路线比较代表性的方法是刚刚提到DETR3D算法。但是，从开源数据及指标来看，DETR3D的性能距离其他稠密类型的算法有比较大的差距。
为了让纯稀疏感知或者DETR3D感知再次把性能达到这种算法水平，我们这两年相继提出了Sparse4D以及它的改进版本Sparse4D-V2，从Query的构建方式、特征采样方式、特征融合方式以及时序融合方式等多方面提升了模型效果。当前 Sparse4D-V2 在nuScenes Detection 3D的榜单上也达到了比较SOTA的效果，超越了像SOLOFusion、BEVFormer-V2和StreamPETR在内的一些方法，而且在推理效率上也有明显的优势。
接下来我主要会介绍Sparse4D和Sparse4D-V2方案的一些细节的实践。
02 长时序稀疏化3D检测算法Sparse4D
首先，我们再去回顾一下DETR3D上面存在的问题。
作为一个比较早期的算法，DETR3D的设计比较简单，存在几个问题。
第一点是它的每个Query只对应一个3D参考点，不能够非常有效的去采样目标特征，特别是对于比较大的目标以及一些跨视角目标，可能就投到一个点，但不能把这个目标都覆盖到；
第二点是Query解码到3D参考点的形式，并不能非常有效地定位ROI区域，会存在退化解，多模式的问题。这个问题其实在2D的DETR改进方法里面有很多讨论，类似于DAB-DETR也讨论了Query到参考点解码形式的存在问题；
第三点是DETR3D里面没有引入时序信息融合。在Sparse4D的第一版本中，我们主要通过Instance的构建方式，特征采用、特征融合和时序融合等方面去对DETR3D进行了改进。
我们在改进过程中学习了非常多2D检测领域DETR改进的经验。
首先，最大区别是我们重新引入了Anchor的使用。对于待感知的目标我们定义为Instance，每个Instance会由两个部分构成：第一部分是Instance的 Feature。它在Decoder中会不断由来自于图像特征的采样特征所更新；第二个部分3D Anchor 是目标结构化的状态信息，我们会显式地把Anchor的参数作为Anchor的信息，它会包括很多具体的值，包括目标框的位置、长宽高、yaw角、速度信息，我们都会作为Anchor的一部分。在Sparse4D-V1里面，Anchor本身我们通过K-Means算法来进行初始化的，同时在网络中基于一个 MLP网络来对Anchor的结构化信息进行高维空间映射，得到Anchor Embed的概念，并与前面说到可学习的Instance feature相加得到更加综合的特征表示。
基于以上定义，我们可以初始化一系列的Instance，经过每一层Decoder都会对Instance进行调整，包括Instance特征的更新和Anchor box的refine，对于每层预测的bounding box中，Sparse4D同样会通过二分匹配的方式与真值进行匹配，并计算损失函数。
在Sparse4D中，最重要的一个模块是Deformable 4D Aggregation可并行的4D特征聚合模块。这个模块主要负责Instance和时序图像特征之间交互。
如图所示，主要包括三个步骤：
第一点是4D关键点生成。基于每个实例的3D Anchor信息，首先可以生成一系列的3D关键点，分为固定的关键点和可学习的关键点。将固定的关键点设置为Anchor box的每个面的中心点，以及其立体的中心点；可学习的关键点，通过实例的特征接入一层全链接的MLP网络来得到。在 Sparse4D-V1的版本中，我们采用了7个固定关键点 + 6个可学习关键点的配置，一共13个关键点。然后，我们会结合每个实例自身的速度信息，以及自车的速度信息，对这些3D关键点的位置进行时序的运动补偿，获得它们在每一个历史帧中的位置，相当于把当前帧的一系列关键点投影到了每一个历史帧上。那么，结合当前帧和历史帧的3D关键点，就获得了每个实例的4D的关键点。
下一步是4D特征采样。在获得每个Instance的当前帧和历史帧这个关键点之后，我们会根据内外参将这些点投影到对应的多视角图像上去，进行双线性的插值采样，从而得到多关键点、多时间戳、多尺度和多视角的特征表示。这其实是一个比较大的特征表示。
得到多层级特征表示之后，做层次化的特征融合，我们分为了三层：
首先，对每个关键点去融合在不同特征尺度和视角上投影特征，采用了加权求和的形式。权重系数是通过将实例特征输入到全连接网络中去预测到的，是一种动态加权的方式；
第二点是做时序特征的融合，我们采用的是一个简单的，类似于RNN的网络来做融合；
最后一点我们会用求和的方式将一个实例不同关键点特征加在一起，作为一个融合。
这页展示的是 Sparse4D中的Ablation Study。
左上角是我们在刚刚的4D关键点中做运动补偿的必要性，对自车运动以及目标实例的运动做运动补偿，对于网络的效果都是有明显提升，特别是对于速度估计的提升是非常的巨大的。其次，我们的融合策略比起直接简单的去加权多尺度的多级别特征，效果要好一些。在Sparse4D中的时序方面，我们发现跟SOLOFusion类似的结论，时序增加的越多，效果就越好，但后面的提升可能会逐步收敛。
效率方面，Sparse4D单帧的版本的速度是略慢于DETR3D，这是一个预期内的情况，因为采样点变得更多了，而且有很多融合的模块。
但在多帧的情况下，Sparse4D的速度下降了很多，主要是因为多帧推理的时候，在Sparse4D框架里面类似于SOLOFusion，对每一个历史帧的特征都要进行一次采样融合。在Deformable 4D Aggregation这个模块中，由于要采用多视角、多尺度、多关键点，再按多帧特征去融合，中间有很多的读写操作，效率也不是很理想。
此外，Sparse4D帧间传递的是比较重的多视角的图像特征，缺乏实例间的帧间传递。这些点就使得Sparse4D特别是在多帧的情况下， FPS下降比较明显。比起一些对比的方法，它在速度和显式量上其实并没有很大的优势，并没有很好体现出稀疏框架的优点。同时Sparse4D时序采样的一个问题是：它的速度采用的是实例在当前时间节点估计的速度，而且我们用了常速度的运动假设，对于变速度的目标历史帧投影很可能是不准的。
那么，针对Sparse4D-V1里面存在的这些问题，我们做了很多改进。
总体来说，可以归为两方面：第一点是我们引入了Recurrent的实例级别的时序方案；第二点是我们对网络中的非常多的模块进行了速度和效率地优化，使得整体的FPS和显式占用都得到了极大优化。具体而言，如上面这张图所示，我们会把上一帧的Instance传到下一帧作为Query的输入。
接下来介绍一下具体的框架。
这张图展示了Sparse4D-V2的整体框架图，Encoder部分与V1版本一致，这边就不展开。Decoder 部分分为了非时序层和时序层。其中非时序层有1层，时序层有5层。非时序层全部是新初始化的Instance作为输入，输出一部分高置信度的Instance到时序层。时序层的Instance除了来自于单帧层的输出以外，大部分来自于历史帧，也就是上一帧。我们的做法是将历史帧的Instance投影到当前帧，在这个过程中保持实例的特征是不变的，但Anchor box会通过自车运动和目标速度投影到当前帧，Anchor embed通过对投影后的Anchor box进行编码得到。可以看出非时序帧的作用主要是先简单检测一下场景中的目标，去做一个比较好的新出现的目标的初始化。
其实，大家如果熟悉MOTR以及MUTR3D ，会觉得这个框架跟MOTR有点相似，都有历史帧的实例进入当前这一帧，也有当前帧新的实例一起进行检测。主要区别在于，Sparse4D-V2中，目前在真值关联部分没有区分历史帧和新Instance的匹配。因为在MOTR里面，是有一套比较独特的匹配策略，它的历史帧已经贯穿目标，会继续跟历史帧关联。我们这边没有做针对tracking的关联策略的调整，还是全部放在一起进行一个关联形式。
Sparse4D-V2和StreamPETR都采用了实例级别的Query的时序框架，两者之间有什么差别？主要有几点：
第一点，是Instance表示方式。在PETR里面Query Instance 采用的是将均匀分布在3D 空间中的可学习 Anchor point，用MLP编码成Query特征。Sparse4D中则是更加显式的做法，会把Instance分离成Feature和3D Anchor，PETR的Instance的形式就更加隐式一些了。我们的观点是特征跟Anchor box的分离的表示方式，在稀疏3D检测任务中可能是更加有效、简洁的方式，也更加易于训练更新检测结果。
第二点，我们将历史帧投影到当前帧这个时序转换的方式，其实是跟前面刚刚说到的Instance的表示方式相对应的。在StreamPETR中，采用了隐式的Query时序特征表示，既把目标的速度、自车的速度、时间戳都编码成特征，然后再和每个Query的特征做adaptive的normalization来进行隐式的更新。
Sparse4D-V2 如刚刚说的是一种非常显式的时序转换方式，直接把Instance基于运动信息的Anchor box投影到当前帧，特征是保持不变的，因为希望这个特征更多的保留它的一些语义信息。
第三点，StreamPETR和Sparse4D-V2中历史帧的数量不同，从PETR里面会保留多帧的信息，再去那一帧做Attention。Sparse4D-V2只cache了一帧，StreamPETR也可以只cache一帧，但是效果会略有下降。在实际的业务实践中，比较少的cache历史帧有助于减少端上的带宽占用，进一步提升系统整体的性能。
此外，在Sparse4D-V2中一个比较大的改进是，我们还对Deformable Aggregation模块进行了底层的分析和优化，让其并行计算效率显著提升，显存占用大幅降低。
左上图展示的是Deformable Attention基本的计算流程，在原始的流程中我们会先采样得到多关键点、多视角、多尺度的中间特征，把这个特征和group weight进行融合，得到融合后的特征。在这个过程中，需要对显存进行很多次的访问和读写操作，降低了推理速度，而且中间的特征尺度比较大，有好几个维度，使得显存占用量会显著增加，且使得反向传播过程中的显存消耗比较明显的提升。
那么，为了提升op的计算效率，降低显式占用，我们将上述实现中的双线性特征插值采样和加权求和融合，合并在一起做了一个算子。就像右边这张图所示，我们称之为Efficient Deformable Aggregation(EDA)模块。这个模块关键在于将采样所有特征再融合的形式，变成了并行地边采样边融合的形式，它能够在关键点k的维度和特征的c维度上实现比较完全地并行化。每个线程或者每个cuda线程的计算复杂度仅与这个相机数量n和特征尺度s有关。
此外，在大多数情况下，特别是在自动驾驶的多视角图像的情况下，3D空间中的一个点，一般最多就被投影到两个视图上，这使得我们可以进一步将计算的复杂度降低为2×s。EDA作为一种比较基础性的算子操作，可以适用于需要多图像和多尺度融合的各种应用。目前这个算子的实现，也已经在我们的官方代码库上开源了。
我们在3090上对EDA模块进行了性能测试，可以看出来EDA对显存占用和推理速度都有一个比较明显的优化。在加入EDA模块之前，在这个配置下，它的推理FPS只能达到13.7FPS，但加入EDA之后就可以有50%的提升，到20FPS。而且整体的训练速度也降低了非常多。此外，我们还提了一个Ablation Study，在Sparse4D-V2上再次去检验了动态特征加权的有效性，可以看出它能够带来三个点的MVP的提升，还是比较有效的一种做法。
这页展示了更多的关键设计的Ablation Study。
我们对比实验1和实验5可以看出，采用Recurrent Instance的形式来实现长时序融合，相比单帧的提升非常大，有将近10个点提升。
对比实验4、实验5可以看出，在Sparse4D-V2中深度监督模块比较重要，能够比较明显降低Sparse4D-V2的收敛难度。如果去掉这个模块， V2版本的模型可能会出现一定的梯度崩溃的情况，使其指标有一定的降低。可能很多时候，在业务场景不具备深度监督条件，这时候也可以用一些其他的 head去辅助，比如FCOS Head、YoloX等去做辅助监督，都能够有效改善训练情况。
实验2和实验3去做对比，可以看出我们刚刚提到的单帧层 + 时序层的组合，先用单帧层去初始化一些检测的Instance，它会比全部用未初始化的 Instance+时序Instance方式的效果好很多。
实验3、实验5对比是展示了我们的另外一个小的改动，在特征聚合的模块里面加了相机参数编码，它也有比较可观的提升。
此外就是实验1单帧模型，它在3090上推理速度是21FPS，实验5的推理速度是20.3FPS，基本上是保持一致的，它时序的速度稳定性还是非常好的。
另外，我们也在nuScenes validation上面去更新一些参考方法，和一些比较SOTA的新的3D感知方法做了对比。
可以看出，无论在低分辨率+ResNet50或者是高分率+ResNet101的配置下，Sparse4D-V2都获得一个比较好的效果，超过了像SOLOFusion、VideoBEV、StreamPETR等算法，当然也比较明显的超过了Sparse4D-V1版本，不过这个表格里面没有写V1的效果。
Sparse4D-V2在256×704的低分率下，速度要比StreamPETR慢，但是会快于LSS-Based，类似于BEVPoolv2。但当图像分辨率提升到512之后，Sparse4D-V2反而会快一些。这主要是因为在低分辨率下直接做Global Attention的代价会比较低，但随着特征图尺寸的上升，它的效率会比较明显下降。Sparse4D head部分的理论计算量和特征图尺寸是无关的，都是通过grid sample去实现特征采样，这也展示了稀疏算法的优势。实际设定中当图像分辨率从256×704提升到512×1408的时候，Sparse4D-V2 Decoder部分的耗时只会增加15%左右，但这是因为从一个比较高分辨率图像的特征上去采样特征，虽然说计算量是一样，但它会比低分辨率图像上的测量会慢一点，这跟特征的访问效率有关。
另外，我们也在测试集上面去做了对比，由图可见，也获得了比较好的效果。
总的来说，对于Sparse4D-V2，我们的结论包括三方面：
第一点是显式的稀疏实例的表示方式。把Instance表示为3D Anchor和特征结合，并不断地进行迭代更新，是一种比较简洁有效的方式。同时这种方式在时序框架里面，也很容易去做时序运动补偿。
第二点是对于稀疏架构，它的特征采样和聚合的算子效率是非常重要的，如果是一个直接基于PyTorch实现算子，它的效率可能并没有那么高，并没有理论计算量那么高效。因此，我们就提出了针对多视角、多视图像的层级化的采样策略，也提出了一个非常高效率的算子。
第三点是Recurrent的时序稀疏融合框架。它使得时序模型基本具备了与单帧模型相同的推理速度，且帧间占用的带宽非常少。这样轻量且有效的时序方案，是非常适合在一个真实的车端场景去处理多摄视频流的数据。
这里还有没有写的一个结论是：Sparse4D-V2的时序框架，是非常容易去做端到端的跟踪。我们后面做了一个实验，发现将检测结果直接根据帧间的Instance对应关系，加上track id，不额外去添加一个tracker，比如一些移植的tracker，就能够得到非常好的跟踪效果。由此可以看出， Sparse4D-V2去做端到端跟踪的潜力是非常大的。
这页还进一步展示了我们最新的一个实验的结果Sparse4D-V3，目前代码和报告还没有release。
在Sparse4D-V3中，我们进一步加入了一些新的特性，比如更大的backbone以及更优秀的训练策略，我们也实现了刚刚说的端到端的跟踪能力，获得了比较好的效果。这是前几天的一个比较新的实验结果。Offline版本的Sparse4D-V3到了0.719的NDS。Offline的版本是指在这个实验中用到的未来帧信息。
正好聊一下这个问题，对于这种比较大Backbone的多视角感知模型，它的业务价值到底在什么地方？因为实际上在端上可以跑的模型，一般跑不了很大的Demo，比如说像刷榜大家会问到VIT-Large这种级别的Demo，它在业务场景下很难使用。因为端上的算力可能有限，可能只能用到ResNet34或者ResNet50这种小模型。
那么，我们认为这种大模型的最大价值就是尽可能地追求它的指标上限，拿来作为云端真值系统的预刷模型，产生4D的真值。这些真值再拿去作为车端模型的训练。这种离线的真值系统里面一个比较重要的策略是我们要用到未来帧的图像，或者在后处理跟踪过程中，用未来帧信息去优化跟踪结果，目标是尽可能提升它的感应效果，以找到比较好的真值，作为真值系统的输入。
03 稀疏通用感知架构
前面讲了很多Sparse4D的细节，接下来讲一些相对更加发散、更大一点的topic。如何在端到端自动驾驶系统中构建一个可靠可用的稀疏的通用感知后端？这是我们认为未来非常有价值的技术方向。
因为只是把检测这个事情做稀疏化，其实并不够。一个真实的系统中，不止检测，还有Online Mapping、障碍物感知，还有freespace等各种各样的任务。我们想要彻底去做稀疏化，就需要把各个任务都做优化改进。
这张图是最近我画的，分为5个部分，是一个我对于稀疏通用感知架构设想的框架。
第一个部分是图像特征的提取。我在左上角写了Foundation Model ，后续可以和Foundation Model的预训练的方式相结合，在图像特征提取上面得到更加强大的特征表示。
第二部分是PV-based 感知。在图像上去做检测任务，或者一些深度估计任务的时候有很多作用。第一点是PV检测的结果，可以作为后续3D感知Query的初始化，这一点在BEVFormer-V2等几个最近的工作中都有采用。Sparse4D目前还没有用上这个策略，应该也会是一个比较有效的策略。第二点是PV的一些任务，包括深度的任务或检测任务，它也有助于图像特征的收敛，使得网络整体上训练得更好一些。第三点是我们认为基于图像PV特征的一些检测深度，乃至于分割结果，有助于挖掘一些场景中存在的通用障碍物。
第三部分是3D感知部分，包括动态感知（也就是检测）、道路元素感知（也就是HD map的在线预测）以及通用障碍物感知。
我还画了一个BEV的模块，这是因为可能有些任务需要在一个相对可能比较小的发展范围内去输出密集的结果。比如freespace就是要道路面上的密集的结果，它是没办法去做Instance表示的形式。所以，在这种框架里面还是不可避免的要加上一个BEV模块。但这里的BEV模块可以使用一个较小的size，更加轻量的设计。最右的两个模块指的是时序融合模块和实例语义关系模块。
总的来说，在架构设计中我们的出发点包括四个部分：
·尽可能会去除后处理和规则融合模块，使得网络整体是端到端完全可微；
·尽可能将大部分的任务稀疏实例化，实现更加高效的时序融合和存储；
·整体架构是一个层次化的架构。从2D的检测结果级别，到3D的级别，到时序的级别，到语义关系的级别，整体有一个比较好的自洽性；
·这个框架进一步加入预测模块和规控模块，就能够实现完整的端到端自动驾驶能力。
在这个框架里面，很多也是比较初步的设想，有很多地方都不太成熟，值得我们未来去探索。
比如第一点，在稀疏范式下的视觉跟Lidar的中融合的结合。虽然我这张图片没有画Lidar，但是后面在类似Sparse4D的框架下做和Lidar的融合，也是一个很好的话题。因为Lidar的稀疏化是一个更加自然的事情。
第二点和第三点是如何去做完全稀疏化的道路元素感知和通用障碍物感知，这两点我接下来会展开讲一下。
第四点是实例化的语义逻辑建模，就是对Topology的建模。这个方向研究工作也比较多，像Tesla也在Workshop上面也展示过一些相关效果。
最后一点也是最重要的一点，就是要做好稀疏感知架构在芯片端的效率优化。因为所有的模块都要建立在一个良好的芯片端的效率上，才能够成立。
04 稀疏感知新范式的未来探索方向
对于具体的三个方向，首先想讨论一下稀疏高精地图建模。
早期的方法，比如HDMapNet，可以认为是模型和后处理相结合的多阶段方法。一般会先获得BEV特征，在BEV特征上做语义感知类任务，在后处理阶段对BEV特征做聚类等的一些后处理，得到结构化车道线。
后续的MapTR V1&V2等方法就实现了端到端的HD map网络。它的特点是基于BEV特征直接预测结构化车道线，省去了后处理步骤，通常是会构造稀疏车道线实例的Query，以及一些车道线中关键控制点的Query，去和BEV层做Attention交互，去迭代修正车道线的结果。
那么，进一步的形势可能是怎么样的呢？
刚刚我们提到了MapTR是用稀疏的Query和BEV特征去交互，BEV特征又是来自于图像特征。理论上可以移除掉BEV这个特征的中间商，直接从图像特征出发，预测结构化车道线，我们认为这是一条完全可行的技术路线。
另外一个方向是关于通用障碍物感知，这个问题可能就更加开放性一些。
通用障碍物的感知是自动驾驶感知系统里面比较重要的一个问题。传统方法一般就是不断地扩充白名单，也就是需要增加感知的目标种类。当遇到一类新的corner case，就可能需要去标很多数据，扩充相关的系统。但这样的做法比较缺乏泛化能力，成本也比较高。
去年Tesla AI DAY之后，Occupancy又成为了解决这类方法的一种可能性。通过识别空间中的通用的障碍物情况，来定位到一些此前没见过的障碍物在3D空间中的占用。但Occupancy在实际系统中存在一些问题，比如计算效率比较低，因为3D Occupancy的输出空间很大，有效的点也很稀疏，这使得下游的模块想去解析并使用Occupancy的时候，是非常困难的一件事情，要真正用起来并不是一件很容易的事情。
那么，是否有一种可行的路线呢？我也不是很确定，是否能去做稀疏的Occupancy是一种我们的预期想法。即只对感兴趣的目标或区域去做Occupancy，而不把所有地方都给估计出来。因为在一个整体的驾驶场景中，很多区域的Occupancy并不太重要，比如左图所示，一些距离道路可能20米之外的树木的Occupancy，估计出来对于系统来说并没什么意义。如果只挖掘对自车驾驶重要的区域，就可以避免算力的浪费。
最近有一篇非常相关的工作叫Occupancy DETR，我觉得就有点这个意思，就是把前景物体跟背景的Occupancy分开估计，前景是用一种类似于DETR的方式去做估计，对于前景物体Occupancy估计效果会提升非常多。我觉得这个方法是一个挺有趣的工作。对于通用障碍物感知的事情而言，另外一个可能比较困难或者说比较重要的事情是：如何从图像视角去挖掘出有可能是一个障碍物的 Queries，再用DETR去做估计。
总的来说，前面介绍了很多端到端自动驾驶的想法，以及稀疏感知的一些内容。
第一点，以端到端自动驾驶为目标，稀疏感知范式在稀疏实例化表示、计算效率、模型带宽和感知范围等方面，都存在优势，有比较大的潜力。
第二点，对于稀疏感知，虽然我前面对比很多稀疏感知和BEV的形式，但其实它跟BEV并不是互斥的形式，在整体的模型框架中还需要根据具体的子任务目标和感知范围去合理地选择，至少可以共享图像特征提取器。
第三点，是在稀疏感知的范式下，有很多任务和难题还有待解决。在未来的一两年里面，我们认为很多任务都可能成为研究的热点。
最后一点，对稀疏感知模型关键算子支持，对于后续的自动驾驶芯片来说也很重要，这不仅是对于其他公司芯片，对我们自己地平线芯片来说也是一个很重要的方向。
