测试时优化+时空高斯泼溅：让占据网格预测在线自监督精修

1. 这项研究到底在解决什么问题先说个背景。占据网格预测在自动驾驶感知里基本已经成了标配它比传统的3D目标检测更细能把任意形状的障碍物、路面、施工区域都用体素级别的占用概率表达出来。但问题在于主流方案几乎都依赖大量标注好的占据栅格真值或者依赖多帧点云拼接出来的稠密监督。前者贵得离谱后者在动态场景里其实有大量噪声。TT-Occ这篇工作的核心主张非常直接把“优化”从训练阶段搬到测试阶段。换句话说模型在推理时不是一次性前向出结果而是用当前帧和时序上下文之间的自监督约束在测试时继续迭代优化占据表示。这个思路以前在NeRF相关的测试时优化里出现过但落在占据网格这个任务上还结合了时空高斯泼溅Spatio-Temporal Gaussian Splatting是我近期看到的比较有意思的视角。如果一个词的概括太抽象我换个说法。传统监督学习是“教一次考一次”考试时不能翻书。TT-Occ则是“教过一次考试时可以现场翻资料、打草稿”而且翻资料的过程不需要标准答案只靠题目本身的逻辑自洽来校验。这就是“Test-Time Compute”的核心含义推理阶段可计算、可迭代、可自我修正。读这篇论文时我一直在想一个问题为什么自监督占据预测这么难做非得绕这么大一圈后来发现答案是精度和泛化之间的老矛盾。自监督方法往往依赖时域融合或者点云反投影但普通模型只能拿到当前帧的信息一旦物体被遮挡、激光雷达稀疏或者相机视野受限占据预测的质量就崩。TT-Occ的做法是引入可微的时空高斯泼溅作为场景表达让测试时优化可以借助“多帧一致性”这个天然信号来修正当前的占据预测而不是依赖任何外部标注。这篇文章我读下来最值得参考的并不是某个单一模块有多精巧而是整套“训练粗模型测试时精修”的范式迁移到了占据预测任务上。下面把所有细节拆开说一遍包括核心结构、自监督损失怎么设计、高斯泼溅为什么能支撑起测试时优化以及我在复现和思考过程中踩到的一些概念上的坑。2. 核心思路拆解从“一次前向”变成“迭代求解”2.1 测试时计算到底改变了什么常规的占据预测网络长这样输入多视角相机图像经过一个基于Transformer或者卷积的编码器输出一个稠密的占据场比如128×128×128或者类似分辨率的概率体素。整个过程是pure feed-forward训练好之后推理一次就能拿结果。这个范式的隐含假设是训练数据的分布能够完全覆盖测试时遇到的所有场景分布。但自动驾驶场景中这个假设经常不成立——新城市、新天气、新传感器配置、新的遮挡模式全都可能让模型表现大幅下降。TT-Occ采用了一个不同的策略把测试时的输入也当成一个可优化的场景表达。它使用时空高斯泼溅来显式建模占据场这个表达本身是可微的因此可以定义自监督损失用连续帧之间的双向光度一致性来优化场景几何和占据概率。测试时计算量的增加换来了输出质量的显著提升尤其是在物体边缘和动态区域。这里的关键直觉是单帧信息不足时多帧的信息可以补。而多帧之间的一致性不需要标注真值只需要可微渲染和光度误差。这是最宝贵的自监督信号。2.2 为什么选择时空高斯泼溅作为场景表达3D高斯泼溅是近年来场景重建和渲染领域的热门表达它把连续场景表示为一系列各向异性的三维高斯分布每个高斯带不透明度、颜色、尺度、旋转等参数。相比NeRF逐点查询高斯泼溅的优势是渲染速度快、显式性好、便于优化。TT-Occ没有止步于静态高斯泼溅而是直接构造了一个时空版本把时间维度并进场景表达里。每个高斯不仅描述“哪里有什么”还描述“它从哪来、到哪去”也就是说每个高斯可以同时建模占据概率、运动方向、以及与时间相关的动态变化。这样一来同一个场景表达既能用于当前帧占据预测又能用来渲染相邻帧从而构造时空一致性约束。有人会问为什么不用BEV特征加光流来建模时序我的理解是光流是二维层面的运动估计在遮挡和边缘处不可靠BEV特征时序融合则缺少显式的三维几何约束。高斯泼溅直接在三维空间建模运动让多帧无线索可以在三维域对齐避免了二维域信息损失。另外还有一层实际考虑高斯泼溅的头是轻量化的不像NeRF那样要在线反复查询网络几百次测试时优化的负担可控。从论文报告的运行开销来看迭代优化的时间代价在可接受范围内部分关键场景只增加数十毫秒级别的计算。2.3 测试时优化的自监督信号从哪来这是整套方案最核心的问题。没有标注真值你拿什么当监督信号答案是多帧光度一致性。具体做法是先根据当前帧图像得到一组初始的高斯泼溅表达然后用时空高斯泼溅去渲染相邻帧视角下的图像。如果场景表达是准确的那么渲染出来的相邻帧图像应该和真实采集的相邻帧图像高度一致。如果存在误差那么将光度残差反传回归就能更新高斯参数进而更新占据预测。这个思想本身不新奇多视角立体视觉、神经辐射场都做过。但TT-Occ把它用在时序数据上且以占据网格为最终输出这就有意思了它相当于在动态驾驶场景中把自监督三维重建当成占据预测的代理任务并且两者共享同一个场景表达。不过光度一致性也有失效场景比如车辆前方大面积的纯色墙壁、无纹理路面、强反光区域。针对这些问题论文里额外加入了几何一致性约束利用深度估计结果或者点云边缘对齐来弥补光度信号不足的问题。这种多信号融合的思路我觉得比单一约束更稳。3. 整体Pipeline剖析粗预测、场景表达、时序精修3.1 训练阶段的“粗模型”如何构建和约束TT-Occ的训练阶段并没有完全丢弃监督信息只是把监督从稠密占据栅格换成了更便宜、更易获得的信号。我个人阅读判断它更多采用了一种预训练加自适应的组合策略先用已有的开放在线数据或者自监督预训练任务把粗模型练起来让模型具备一个合理的初始化能力然后在测试时去精修。粗模型输出的不是最终占据场而是一组初始的高斯参数。这个设计很关键——它让模型输出的结果天然是渲染友好的而不是一个必须后处理才能用的体素概率图。原始输入经过图像编码器得到BEV特征再经过一个轻量的高斯参数预测头输出初始的位置、尺度、旋转、不透明度、颜色等属性。在训练粗模型时需要用可微渲染把高斯泼溅渲染回图像平面并与原始输入图像计算重建损失。这里虽然也不需要稠密占据真值但重建损失本身是一个Weak Supervision——它训练模型在高斯表达空间内做合理的预测确保测试时起点不能太差。如果粗模型完全瞎初始化测试时优化大概率收敛到局部极小值所以预训练过程的信号质量决定了测试时优化的上限。3.2 测试时的在线优化如何循环迭代测试时优化不是一个模糊的过程论文里给的循环大致如下第一步拿着当前帧图像过一遍粗模型得到初始高斯集合。第二步把高斯集合沿时间轴扩展每个高斯关联运动向量可以推导到前后帧的坐标。第三步用当前帧的时空高斯泼溅渲染相邻视角图像构建光度残差。第四步将光度残差继续反传用梯度下降方式更新高斯参数。第五步用更新后的高斯参数重新渲染当前帧视角提取占据概率。这个循环会做多轮直到收敛或者达到预设迭代次数。整个过程就是典型的“分析-合成“闭环分析当前帧得到场景表达合成相邻帧进行校验再用误差修正表达。相比训练时固定权重的模型测试时的这个闭环相当于针对当前场景做了现场适配把场景特定的细节比如某个路口的特殊形状、某个特定车辆的精确轮廓全部拟合进去了。3.3 占据概率如何从高斯泼溅中提取高斯泼溅是连续的场景表达但自动驾驶下游任务需要的是离散占据网格。所以最后一步必须有一个从连续高斯集合到体素占用概率的映射。这个映射可以有很多种实现方式。最直接的就是在每个体素中心周围查询所有高斯的累积不透明度然后转换成占据概率。但直接这么做有个问题——多个高斯的贡献可能会相互重叠导致某些区域过饱和。论文里的方案我没有读得很细但基于我做类似工作的经验通常会加一个截断阈值和一阶近似让占据概率平滑过渡到0和1之间。另外值得一提的是空间中的高斯参数在和占据网格相互转换时需要保持梯度通路否则测试时优化的梯度无法回传到占有率上。这也是时空高斯泼溅能端到端工作的核心前提之一。4. 关键技术细节与实验设定4.1 损失函数拆解占据网格测试时自监督优化的核心挑战在于单纯的图像重建损失往往会被纹理和光照偏差干扰特别是相机曝光差异、移动物体阴影、动态光源变化等场景中光度损失会产生反效果。因此TT-Occ不是单一Loss走到底我理解至少包含以下几个组成第一项是相邻帧之间的重建损失用鲁棒损失函数消除遮挡和离群点的影响。第二项是深度一致性约束把预测深度和激光雷达投影深度或者和视觉深度估计结果对比用于在弱纹理区域稳定几何。第三项是时空平滑正则约束相邻体素之间的占据概率不出现突跳尤其对地面和静态背景区域有显著效果。这种组合方式非常值得借鉴因为它体现了工程化的思维单一信号容易骗到模型多个信号互相兜底才能保证自监督优化稳定收敛。4.2 粗模型的设计选择从架构上看粗模型可以采用轻量的单目图像编码器也可以接入多视角特征。训练粗模型的损失函数比较灵活既能用无监督重建也能用路边已有的自监督深度估计预训练权重做初始化。论文最巧妙的地方在于让粗模型输出一个渲染友好的表达而不是直接输出占据体素这给了测试时优化极大的灵活性。我用一个类比来说这跟Inverse Rendering的思路高度类似。渲染友好的场景表达可以被任意的图像残差反推修正而占据体素本身很难直接和图像观测建立联系。这是一步关键的设计决策。4.3 动态目标和静态背景怎么差异化处理在自动驾驶时序数据中大量的光度变化其实来自动态目标——其他车辆、行人、非机动车。如果把动态目标带来的光度和几何变化一股脑算进自监督损失里优化过程很容易被带偏。TT-Occ在处理这个问题时利用了时空高斯泼溅的运动建模能力。动态高斯和静态高斯被区分对待静态高斯只允许在空间位置上做小幅度修正动态高斯则额外拥有速度向量和运动轨迹的自由度。这样优化器就明确知道“哪些误差应该归因于几何不准”而“哪些误差应该归因于物体在移动”。这个设计在工程上非常实用。否则你很难分清一个像素残差究竟是因为物体在移动还是因为你的占据预测位置不对。有了双域自由度梯度信号天然被解耦收敛稳定性和速度都会好很多。5. 实验效果最值得关注的结果集中在哪5.1 在Open Occupancy基准上的表现论文的实验主要在几个主流的自监督和半监督占据网格基准上展开。从我读到的数据看TT-Occ相比基线的提升主要集中在IoU指标和高分辨率体素下的边缘精度上。特别值得注意的是在动态物体区域IoU_dynamic和远距离区域IoU_beyond提升幅度比静态近处区域更明显。这其实很好解释近处静态背景是传统自监督方法已经能解决得很好的部分而远处和动态区域恰恰是单帧信息最不充分、最依赖时序上下文精修的部分。TT-Occ的测试时计算恰好补上了这个短板。5.2 推理代价的权衡测试时优化最让人担心的就是实时性问题。论文提到TT-Occ的测试时优化在单个场景上需要多帧影像的迭代优化整体运行时间比纯前向模型高。但如果用高并行GPU并将迭代步数控制在30步以内推理帧率依然能维持在接近实时的水平。这个做法的意义在于提供了一个额外的旋钮如果算力富余就多迭代几步拿更高精度如果算力紧张就少迭代几步保帧率。这种“按需精度”的模式在落地时非常有用因为不同车型的域控制器算力差异巨大同一个模型可以在不同平台上做不同档位的推理。5.3 泛化性的实际意义我判断这篇论文更大的价值在泛化性提升。自监督占据预测如果不加测试时优化基本只能在自己训练的数据分布里工作换城市、换季节、换相机布局都可能崩。而有了测试时优化每到新场景都能在线自适应用新场景的多帧图像自己去拟合几何细节相当于每次部署都在做一次轻量迁移学习。从实际落地角度看这个思路比深度学习训练阶段堆数据要更高效因为你无法保证训练数据永远覆盖所有边缘案例但测试时优化可以针对当前实际看到的场景做定制化调整。6. 实操视角如果我要用这套思路该注意什么6.1 光学校准和帧间质量直接影响优化上限第一个要强调的点测试时自监督优化的上限取决于相邻帧之间的图像质量和相对位姿精度。如果相机的内外参标定有毫米级的误差或者帧间IMU插值有明显漂移那么多帧一致性约束本身就存在系统性偏差你再怎么迭代优化也救不回来。实际部署时建议在特征提取前先对图像做运动补偿并且在构建相邻帧约束时优先选择时间间隔较短、视角变化较小的帧对避免大基线导致的遮挡区域过多。不要为了帧数而盲目增加时间跨度时间跨度过大导致遮挡比例升高自监督信号的信噪比反而会下降。6.2 高斯数量不是越多越好时空高斯泼溅的表达容量由高斯数量直接决定。高斯太少表达不出复杂场景细节边缘和薄壁结构会糊高斯太多内存开销增大且优化容易陷入局部震荡。根据我的实践对于一个前向100米、横向40米范围的驾驶场景初始高斯在十万级别是合理区间更精细场景可以到几十万。同时要注意高斯的初始化位置。如果在粗模型预测阶段能够结合深度先验初始化高斯中心会显著加速收敛。这一点非常建议在复现时采用能减少一半以上的迭代步数。6.3 把正则项当成稳定器而不是主力在自监督优化中正则项的作用常常被低估。尤其是占据网格任务表面上光度损失是主力但实际优化时空间分布很容易扭曲——某些地方为了最小化像素误差而让高斯堆积其他区域则被清空。这时时空平滑正则就很重要。从经验来看正则权重要设成光度的0.10.3倍不可太高也不可太低。太高会限制自由度导致结果偏模糊太低则会产生碎片化的孤立体素。每次场景切换后建议先小范围测试三到五个权重组合再去批量跑。6.4 动态目标占比高的场景要多留迭代裕量城市道路中动态目标比例高尤其是在十字路口和交叉口。动态目标多了之后光度残差会被更大的运动噪声主导优化的收敛速度会慢。我建议在这种场景下至少留出50%的额外迭代裕量或者干脆把动态目标运动向量作为网络输出让网络显式估计每个动态高斯的速度而不是单纯依靠残差迭代去隐式拟合。7. 常见问题与复现排坑7.1 光度损失震荡怎么办这是我在复现类似测试时自优化框架时踩过最多的坑。症状表现为前几轮迭代loss下降很快随后开始震荡甚至反弹。通常原因有两种一种是鲁棒损失设置不对没有过滤掉遮挡像素导致被大残差干扰另一种是学习率过大在收敛附近来回穿越。建议把学习率设置为分阶段衰减前面二十步用较大学习率做全局调整后面三十步用较低学习率做精修。这样可以同时保证收敛速度和稳定性。对于遮挡像素建议用相邻帧光流做mask在mask区域直接关闭光度约束。7.2 弱纹理区域有漂浮物无纹理墙面、纯色地面、大面积天空等区域光度梯度几乎为零高斯优化没有着力点。常见结果是这些区域的高斯参数乱飞甚至产生漂浮的伪体素。解决办法是在损失函数中加入深度先验约束用稀疏激光雷达或者单目深度估计网络提供的锚点来稳住这些区域的几何。另一种思路是为这些高斯开启更大的空间平滑权重让它们跟着周围有明显信号的高斯一起运动。7.3 远处区域精度不佳远处的物体在图像平面上占的像素少光度梯度弱导致占据预测质量低。我的经验是给多帧图像构建一个多尺度金字塔损失低分辨率主导全局结构高分辨率精修近处细节可以有效提升远处区域优化效果。代价是多了一部分显存开销但对远端IoU的收益非常明显。7.4 显存不够怎么办测试时优化最实际的瓶颈就是显存。时空高斯泼溅本身就比纯光栅化占显存再加上迭代优化需要保存计算图很容易把消费级显卡直接跑满。建议做法是缩小相邻帧的数量、降低渲染分辨率、以及去掉不需要的梯度保存层。精度会略降但实用性大幅提升。8. 这套思路还能往哪个方向延伸TT-Occ这种想法并不局限于占据预测它实际上揭示了一个通用的路径任何显式几何表达只要是可微的就有可能利用时序观测来实现测试时自监督优化。顺着这个思路我能想到几个明确的扩展方向第一个是统一动态物体跟踪和占据预测。既然时空高斯已经在建模运动向量了那为什么不直接输出实例级别的运动轨迹如果高斯参数中加上语义标签占据网格和3D跟踪就能共享同一套场景表达下游规控模块也可以拿到更丰富的结构化信息。第二个是把测试时优化的梯度信号扩展到毫米波雷达或者超声波传感器。现在的方案主要依赖视觉光度一致性但毫米波雷达对速度敏感、对遮挡鲁棒恰好可以弥补光度信号在雨雾场景的不足。多传感器一致性的自监督信号理论上可迁移。第三个是轻量化迭代器。当前的测试时优化需要跑多轮梯度下降如果专门训练一个小型网络来预测“残差到参数更新量”的映射类似Learned Optimizer就能把迭代步数压到个位甚至一次到位。当然这会重新引入对训练数据的依赖如何平衡要具体场景评估。9. 写在最后的一点个人感受我自己做了几年三维感知相关的工作明显感受到行业在从“大力出奇迹的堆数据”转向“结构化表达加运行时优化”的方向。标注数据贵、长尾场景多、传感器配置杂这些问题用堆训练数据很难根治。而测试时计算提供了一条几乎不需要额外标注就能持续提升精度的路径。TT-Occ最大的启发不是时空高斯泼溅本身有多酷而是它演示了一个非常务实的工程组合可微的场景表达是地基时序自监督是信号来源测试时优化是执行机制三个东西单独看都不算完全全新但拼在一起就解决了一个十分现实的系统级问题——部署后的在线自适应能力。如果你正在做占据网格预测或者类似的自动驾驶三维感知任务强烈建议找一个夜间或者雨天场景跑一遍不加测试时优化的基线再对比一下加了TT-Occ思路之后的结果。你会发现最大的差异往往不是整体数字而是那些之前完全崩掉的corner case变得可用了。这种“测试时开始变聪明”的感觉是这套方法最打动我的地方。