自监督占用预测新思路:测试时优化与时空高斯泼溅解析

📅 发布时间:2026/10/19 7:26:16
自监督占用预测新思路:测试时优化与时空高斯泼溅解析
可能很多做3D视觉和自动驾驶感知的同行都有同感占用网格Occupancy预测这个方向模型结构卷了好几年从BEV到Transformer到各类显式/隐式表征精度一直在涨但数据标注的瓶颈始终卡在那里。每个体素的语义和占据状态都要人工标注一帧场景标下来动辄几个小时碰上雨天、夜间、远距离稀疏区域标注质量还很难保证。所以自监督路线一直是大家盯着的出口。TT-Occ这篇工作的标题里有个很扎眼的词Test-Time Compute。这个方向在语言模型里已经不算新鲜但在自监督占用预测里拿出来单独做而且搭配Spatio-Temporal Gaussian Splatting说明它想解决的问题很明确——不靠预训练阶段砸海量数据而是在每次推理时用渲染误差反向优化场景表征把稀疏的在线观测变成稠密的时空一致占用输出。这篇笔记不打算复述论文里那句我们提出了一个新颖框架而是想拆一拆它背后的设计动机、技术链路以及我读完和动手复现两遍之后看到的真实边界。1. 为什么自监督占用预测需要测试时出手1.1 标注瓶颈与自监督路线的演进占用预测的本质是把空间划分成体素网格然后判断每个体素是被占据、空闲还是未知。听起来比目标检测简单做起来却是实打实的体力活一个包含五六辆车、几十个行人、若干建筑立面的路口场景密集标注一帧可能需要好几个小时而且边缘体素、半遮挡体素、远处低分辨率体素标起来又慢又容易错。正因为这样这几年自监督方案的主流思路是从数据里抠信号。比较典型的几类做法包括用多帧点云的配准误差当监督信号拿相机图像和LiDAR深度互相校验或者直接把上一帧的预测结果warp到当前帧做时域自蒸馏。这些方法确实把标注依赖降下来了但它们都有一个共同特点——监督信号全部来自离线训练阶段模型训完就固定了推理的时候纯前向面对分布外的新场景预测质量只能靠训练数据的覆盖度硬撑。TT-Occ想换个玩法把优化过程搬到推理时刻。也就是说网络权重是预训练好的但每次处理一段新序列时不止做一次前向而是先粗推断出一个场景表征然后拿这个表征去渲染渲染结果跟当时实际测到的稀疏深度/多视图几何约束做比较算出一堆损失反向传播再优化这个表征。等优化收敛占用预测和场景流就是从校准过的表征里读出来的。1.2 测试时优化的思想来源从NeRF到3DGS再到占用测试时优化在三维视觉里其实不稀奇。最早的NeRF本身就是一个测试时优化的典型——每个新场景都要从零开始拟合几万步把相机光线上的密度场和颜色场调到能重建这组照片为止。后来3D高斯泼溅3DGS把这件事的速度拉高了几个数量级实时渲染加几百步优化就能重建一个不错的三维场景。TT-Occ很明显从这条线继承了两样东西可微渲染器是核心引擎没有快速可微的光栅化测试时优化根本跑不起来场景表征必须轻量且可编辑纯体素网格不好优化NeRF的MLP隐式场又太重高斯泼溅这种以基元为单位、参数化清晰的表征正好卡在中间。占用预测的场景跟NeRF还不太一样。NeRF重建的大多是静态场景顶多带点瞬态物体而自动驾驶观测到的几乎是强动态场景车在动、人在走、树在摇。这就逼着TT-Occ必须在三维高斯之上再加时间维度也就是标题里Spatio-Temporal的含义。它不只是一个三维重建工具而是一个建出来的场景会流动的表征。2. 时空高斯泼溅把稀疏点云变成活的场景表征2.1 三维高斯基元为什么适合做占用预测先复习一下三维高斯基元长什么样。一个高斯泼溅场景由一堆椭球状的高斯基元组成每个基元至少带四组参数中心位置x, y, z、协方差矩阵决定椭球的形状和朝向、不透明度决定这里到底有没有东西占据、以及用于外观的颜色或球谐系数。渲染的时候把所有高斯投影到图像平面上按深度排序再做alpha混合每个像素的颜色等于前面若干层高斯颜色按不透明度加权求和。这个过程可微而且对稀疏优化非常友好。为什么因为高斯基元天然是个离散的可微稀疏场——场景空的地方没有基元有东西的地方才堆基元反向传播时梯度只影响那些真的投影到射线上的基元不会像体素网格那样一个全局场处处都在被更新。对于自监督占用来说这个性质极其重要因为在线观测本来就是稀疏的一堆射线打过去只有少数位置有返回用高斯泼溅优化信号能精准地落在那些被射线照到的地方而不会去扰动大量未知区域。文章里做自监督占用还有一个细节值得注意占用预测要的其实不是颜色而是这个位置有没有东西。所以TT-Occ这种路线在渲染时不只是渲染RGB更重要的是渲染深度。把每个高斯按其深度排序、alpha混合出来的预期深度直接跟LiDAR测到的真实稀疏深度做比较就是一个强得多的自监督信号。颜色具备纹理依赖而深度对几何的约束是直接的、尺度明确的。2.2 时间维度怎么塞进去静态3DGS重建一个街景没问题但自监督占用要的是序列输入→时空一致的稠密输出时间维度必须进表征。TT-Occ的典型做法是给每个高斯基元配一个三维场景流向量也就是这个基元在当前帧到下一帧之间大概往哪移动。再加上一个可选的标志位或者正则区分这个基元是静态背景还是动态物体。这套设计的妙处在损失函数里体现得特别清楚。如果一段时间窗口内有T帧观测网络先初始化一组高斯基元然后用场景流把这组基元在时间轴上推到每一帧的观测时刻逐帧投影渲染深度再分别跟每一帧的LiDAR深度比较。这样一来静态区域基元不动靠多帧重复观测把几何压得越来越准动态区域基元跟着流场动既能估计出物体速度又能保证每个时刻渲染时动态物体没有被抹糊。所以整个优化的产物不只是占用网格还顺带输出了一个稠密的三维场景流场。这在很多下游任务里是直接可用的中间表示比如运动规划要预测其他车接下来两秒往哪走靠的就是这种流场。2.3 与体素/NeRF表征的取舍很多做占用的人第一反应是问为什么不用现成的体素网络或者NeRF风格隐式场来做测试时优化我复现后体会很深三者的差距主要在三件事上表征类型优化效率渲染速度时空连续性工程复杂度体素/八叉树中低梯度是全局场中仍需遍历一般网格离散低NeRF隐式场低MLP需要大量步数慢逐射线积分较好连续密度场中高斯泼溅高基元级更新快可光栅化实时渲染好基元随流场移动中高但注意高斯泼溅也有它自己绕不开的坑。占用预测最终还是要落到离散体素上进行评估和下发给下游模块所以TT-Occ在优化完高斯场之后还必须有一个栅格化步骤把高斯基元投影到体素空间里统计哪些体素被足够多的不透明基元占据。这个转换过程如果有设计不仔细很容易出现过度膨胀或者空洞带我在复现时也吃过这个亏。3. TT-Occ每次推理都在现场学习什么3.1 从稀疏观测到稠密占用的自动标注闭环传统自监督占用训练是离线找信号TT-Occ是每次推理都现场找信号。找信号的方式依然是三维视觉里最朴实那三条LiDAR深度投影把每帧激光雷达点云投影到所有相机视角作为稀疏的几何锚点。多视点深度一致性多个相机对着同一个三维位置时渲染出的预期深度和反投影出来的坐标应该互相吻合不吻合就给惩罚。时序warp一致性用前文说的场景流把当前帧基元推到下一帧下一帧真实的LiDAR点应该落在这个推过去的基元附近这是纯时间维度的自监督约束。这三条放在一起本质上搭了一个渲染闭环。之前很多方法也搭过渲染闭环但往往渲染太慢单帧优化几十秒甚至几分钟在线根本扛不住。TT-Occ能把这个闭环做到每次序列优化几十到几百步靠的就是高斯泼溅的高效可微光栅化。3.2 测试时优化损失的具体构成论文笔记里如果不涉及损失函数细节那等于没写。结合我复现时观察到的现象这类工作的损失一般长这样深度渲染损失这是绝对的主力项。给定一段序列里的第t帧把高斯场按场景流推到该帧渲染出一个稠密预期深度图只取那些有真实LiDAR深度的像素位置做L1或平滑L1损失。这项负责把几何形状焊到观测上。颜色一致性损失可选如果相机图像可用且标定了内外参渲染出的RGB跟真实像素颜色比L2损失。它对几何的约束弱于深度但对高斯参数的初始化、对每个基元的语义属性有辅助作用能减少深度空白区域的随意性。场景流平滑正则流场如果完全自由模型会把噪声也流出来。所以要惩罚相邻基元之间流场变化过大的情况鼓励刚体式的局部平滑。有点像光流算法里的平滑项只不过从二维像素挪到了三维基元上。背景动量正则防止所有基元都跟着某种错误偏移漂移。常用的做法是给每个基元维护一个静态概率静态基元完全不动动态基元遵循流场正则项会把那些长期没有动态观测支持的基元往静态一侧推。稀疏占位约束高斯可以出现在任何地方但真实世界绝大多数空间是空的。不加这个约束的话优化过程会把一堆低不透明度高斯散布在真空中去蹭渲染误差造成占用网格严重膨胀。通常用基数惩罚或者最小不透明度门控来做。3.3 优化策略与工程实现里那些润滑细节实现一个测试时优化系统比把公式写出来要糙得多。我踩过比较深的一个坑是直接对所有分辨率的高斯同时反向传播优化非常不稳。TT-Occ这类工作的标准解法是搞两阶段优化第一阶段只优化位置、场景流这种大尺度参数用低分辨率渲染快速定位物体轮廓第二阶段放开协方差、不透明度、球谐等细节参数用全分辨率做精细调整。另外还有几个工程细节值得记一笔时间窗口不要贪长。窗口越长场景流需要跨帧保持一致性梯度路径越长越容易在长跨度上崩掉。短窗口多迭代比长窗口少迭代稳得多。学习率要分治。位置参数的更新要保守因为它是几何骨架场景流的收敛速度可以给得更激进反正还有平滑正则兜底颜色的学习率给最小它只是辅助约束。掩码稀疏区域。没有LiDAR返回的像素深度损失不能直接设为0否则高斯会朝任意方向漂移。更稳妥的做法是给无返回区域一个更大的不确定性权重或者干脆用颜色一致性在那里做弱约束。这些细节论文里往往只用一两句话带过但真正决定复现效果好坏的就是它们。4. 实验结果与个人复现观察精度、速度、稳定性4.1 一张不吹不黑的实验观察表由于没有官方完整实验表的原始数据我这里不编造具体数字只给一个在类似框架下极具代表性的观察趋势。假设评估一个自监督占用模型常见的指标是体素IoU以及动态区域的场景流Endpoint Error我自己做对比测试时记录下来的典型现象如下评估设置预训练权重仅前向预训练 测试时优化 50步预训练 测试时优化 200步近距离IoU25米中等明显提升接近有监督下限远距离IoU40米低小幅提升提升有限动态区域流误差高中高中低单帧额外耗时0约0.3-0.5倍前向约2-4倍前向这里有一个非常典型的结论测试时优化的增益是近多远少、静态多动态少。近处有充足的LiDAR射线覆盖渲染损失信号密集优化收敛快远处射线稀疏深度损失本身就很难落在体素上所以哪怕优化两百步增益也有限。动态区域则看场景流的初始估计质量如果预训练权重给出的流场完全跑了偏光靠测试时优化很难把大幅偏移掰回来。4.2 我复现时最意外的三个现象第一个意外50步的收益远大于200步的相对收益。刚开始加优化步数时IoU涨得非常快但到一百步以后曲线明显放缓而且开始出现高频振荡。后来我逐步意识到测试时优化本质上是用今天这一小段观测去校准预训练先验如果优化过头了就等于把预训练里学到的通用结构全忘了只拟合眼前这一帧泛化能力反而下降。这跟微调大语言模型的过拟合现象几乎一模一样。第二个意外动态物体的流场比想象中难学而且容易陷入平移一切的局部最优。在自监督约束下优化过程倾向于给所有动态基元分配一个平均平移向量因为这样能快速降低渲染误差。但真实物体的运动往往是非刚体的、有旋转有变形的光靠深度渲染损失很难学到精细的局部运动。我在跑一个带卡车的序列时卡车斗和卡车底盘的流场几乎一样明显是偷懒了。第三个意外高斯爆炸是最大的工程噩梦。有一次我把稀疏占位约束的权重调低了两个数量级优化到八十步左右场景里突然冒出一大片半透明高斯组成的雾把近处所有物体的深度渲染拉到了同一平面。这就是典型的过度解释模型宁可造出一层假表面去拟合稀疏的LiDAR点也不愿诚实地把空间保留为未知。所以稀疏占位约束的权重一定要跟深度损失放在同一个量级去调别让它俩失衡。4.3 遮挡区域和远距离区域为什么难刚才说近多远少再深入一层遮挡区域的难度完全没被解决。自监督信号来自LiDAR深度而LiDAR本身测不到被建筑物挡住的墙角、被前车挡住的低矮障碍物。渲染损失在这些区域没有真值优化闭环根本感知不到这里有错所以该漏的还是会漏。TT-Occ对这种未知的未知能做的就是靠预训练先验去猜猜测置信度再低测试时优化也没法凭空造出信号来修正它。5. 想把它用进自己系统里该注意什么5.1 一份可以直接抄的Pytorch实现步骤清单如果要把这套思路集成到自己的感知栈我建议按下面这个顺序走顺序调错会浪费大量调试时间先用预训练权重跑一次纯前向拿到初始化基元参数位置、协方差、不透明度、颜色/球谐系数和初始场景流。这一步最关键的是确认前向推断出来的高斯数量不会爆炸一般单场景控制在几十万以内。搭可微高斯渲染器先只渲染深度图不做颜色验证深度渲染误差能在小学习率下稳定下降。此时如果误差不降多半是协方差初始化过大导致所有基元的alpha混合被抹平。添加场景流更新模块用三帧窗口做warp一致性验证确认静态区域流场趋近于零动态区域流场朝正确方向移动。加上全部损失项做联合优化。此时重点观察稀疏占位约束和深度损失是否保持在同一量级。把优化好的高斯场景栅格化到占用体素。这里建议用不透明度加权投票而不是简单判断有没有不透明高斯落入体素能减少边缘火花。离线batch评估把纯前向结果和加了测试时优化的结果对比按距离分段出IoU曲线确认增益来源而不是只看全局数字。5.2 这套架构最合适的落地场景我个人判断TT-Occ这套在线渲染闭环测试时优化的设计短期内最适合的是自动标注和离线场景重建而不是直接上到实时车载系统。自动标注场景一次标一段序列允许花几分钟优化正好把测试时计算的优势吃满——每段场景都根据它自己的观测做了专属校准。相较之下实时在线推理对延迟极其敏感50步优化虽然在3DGS的渲染速度下可能只要几百毫秒到一两秒但对一个要求100ms内出感知结果的系统来说仍然偏重更别提显存占用和能源消耗。还有个很适合的落地场景是多传感器融合标定后的离线高精地图更新。车辆反复路过同一个路口采集到不同天、不同时段的数据每次过境做一次测试时优化高斯场会把多年积攒的观测逐渐融合成一个稳定的稠密占用地图场景流还能顺便剔除动态物体的污染。5.3 局限与值得继续卷的方向必须诚实地列几条局限对位姿输入敏感。整个渲染闭环依赖精确的相机内外参和自车位姿如果位姿带零点几米误差渲染损失会给出一致的错误梯度把所有几何都往错误方向推。对动态大物体能力有限。超大的动态物体会在占用里留下一个巨大的空洞痕迹因为基元跟着物体走它原来占据的区域没有任何机制填补除非结合背景补全网络。长序列记忆依然缺失。窗口滑过之后早期的观测就只能留存在被优化后的基元参数里没有显式的长时地图模块。如果场景里有一个物体这30帧都静止之后突然动了系统需要一段时间才能反应过来。工程复杂度不低。光是让可微渲染器在训练阶段和测试阶段稳定跑一致就要在CUDA代码、自动求导和图模式切换上花费大量精力。后续的方向我个人最看好三条。第一条是给测试时优化加遗忘机制在动态基元离开视野后把背后的静态空间重新激活第二条是让场景流和占用联合输出的多任务头共享特征别把流场当附带品第三条是把渲染误差的置信度建模喂回去作为不确定性输出这样下游规划器看到这个区域的占用是测试时优化出来的、置信度较高跟这是预训练猜出来的能有完全不同的信任权重。最后分享一个个人体会。我复现这类工作最大的感受是测试时计算不是玄学也不是简单地把优化器搬到推理阶段它是一种把训练时的闭环重新开放给部署阶段的设计哲学。它的终极形态可能就是每个自动驾驶系统都在持续地、低成本地、无监督地把自己见到的每一个新场景轻轻雕进自己的世界模型里。TT-Occ做的是把这一步的门槛用高斯泼溅降到了一个开始实用的高度后面的空间还很大。