做 4D 占用世界模型的人几乎都绕不开密集体素网格这道坎。空间被切成几百万个格子每个都要算一遍可真正有东西的格子连百分之一都不到。第一次看到 SparseWorld 这个思路时我印象最深的并不是它用了什么花哨网络而是它把问题换了一种问法既然整张网格大多是空的为什么还要让模型在空白上浪费那么多算力SparseWorld 的做法很直接——扔掉密集体素网格只放一千多个会跑的查询点让它们自己去找场景里值得关心的位置。这篇文章不打算复述复杂公式主要想从思路拆解、模块设计到踩坑记录聊聊这套替代方案到底怎么落地适合正在做占用预测、端到端感知或者世界模型的朋友参考。1. 为什么密集体素网格会成为 4D 占用建模的瓶颈1.1 先算一笔体素账密集体素网格的问题从来不是概念不好懂而是账面数字太吓人。假设自车前方 70 米、左右各 35 米、高度范围从 -2 米到 4 米分辨率取 0.2 米那么体素数就是 350 × 350 × 30约 367 万个。这还只是三维空间的一帧占用。如果换成 0.1 米分辨率体素数量会直接乘以 8变成近三千万个。很多团队一开始觉得 3D 卷积能扛但实际跑起来才发现分辨率一旦上去显存和算力几乎是指数级增长。尤其做 4D 占用世界模型时要把时间维度也纳进来每一帧关键帧都对应一整套三维体素特征多帧累积之后特征图数量成倍增加。更麻烦的是3D 卷积的感受野是固定的哪怕某个格子的周围全是空白卷积核也必须在那个位置做完整的乘加运算。换句话说大量算力被消耗在“查无此物”的区域上。体素账真正可怕的地方在于你为整个空间预分配了完整的内存和计算资源但实际用到的只有其中极少一部分。这叫结构性浪费换再好的卷积网络也救不回来。1.2 真实道路场景里的占用率低得离谱城市道路场景虽然看着繁忙可把三维空间量化成体素之后真正被车、树、行人、护栏占据的格子通常只有几个百分点。大部分区域要么是自由空间要么是长期不变的背景。做一个简单类比密集体素网格就像是一个安保系统对着整栋大楼的每一个房间都装监控不管有没有人而稀疏查询点方案则是在有人活动的地方才调度摄像头资源。这个差异在训练阶段尤其明显。网格模型的监督信号天然偏向空区域因为空体素数量压倒性地多。网络学来学去大量容量都在拟合“这里没东西”而不是去分辨“这里有车”和“这里有行人”的边界。所以不少做占用预测的团队会观察到分辨率调到一定程度后IoU 指标反而上不去甚至开始掉。这不是网络能力不够而是优化目标被空白区域稀释了。SparseWorld 的核心动机就是把这个比例倒过来不再假设空间处处需要建模而是默认空间大部分是空的只在可能发生占用变化的位置投入计算资源。这个前提一旦成立后边的结构设计就顺理成章了。1.3 网格在时间维度上的额外成本4D 占用世界模型真正区别于静态占用预测的点在于它必须感知“空间在时间里的变化”。固定网格做法为了建模动态场景通常要维护过去 N 帧的体素特征做对齐、累积、融合。每多存一帧历史内存就多一份体素量级的开销。自车还在持续运动还得处理 ego-motion 补偿否则同一个格子的内容会在不同帧之间漂移。网格方案的时间维灵活性也比较差分辨率是固定的一秒钟 60 帧不可能对每一帧、每一个位置都做精细的时序建模。你只能在分辨率、历史长度、算力之间妥协。SparseWorld 换成查询点之后情况完全不一样。点作为一个实体可以从上一帧继承状态在时间上做平滑的更新。你不需要把整个空间的历史都存下来只需要保存每个查询点的位置和历史特征。计算量跟随“场景里关心对象数量”增长而不是“空间格子数量”增长。这个差异在长时序预测里会越拉越大。2. SparseWorld 的核心策略一千多个查询点怎么干活2.1 查询点不是普通采样点而是有状态的软体素很多人第一次听说查询点会把它理解成“在空间里随机撒一堆点然后取特征”。这是常见的误解。SparseWorld 里的查询点是带状态的实体一般包含三样东西空间坐标、特征向量、局部感知范围。坐标决定了这个点当前关心哪里特征向量编码了这个位置周围应该有什么感知范围则决定了它能代表多大一块局部区域。可以把它理解成一个“软体素”。普通体素是固定坐标、固定大小的硬格子查询点则可以在连续空间里自由分布。靠近物体边界时可以更密远离物体时可以更疏。它不需要对齐到任何固定分辨率从根本上绕开了“分辨率该设多少”这个纠缠不清的问题。这里也能看到与 BEV 感知里 object query 的区别。DETR 一类方法里的 object query 最终目的是出检测框或分割掩码SparseWorld 的查询点则是为了回答“我所在的这个位置以及我周围的这一小块空间在未来是否被占据”。它更像是一个智能探针而不是一个输出头。维度密集体素网格SparseWorld 稀疏查询点空间覆盖方式固定间隔铺满整个区域动态分布在非空区域附近内存开销随分辨率三次方增长随查询点数量线性增长时间建模需要维护多帧历史体素点继承状态自然做时序更新动态目标跟踪靠重新预测容易跳变点可以跟着目标移动输出连续下游产物规则体素直接可查解码成局部体素后拼接成规则网格主要风险分辨率与算力难以兼顾点分布质量决定成败拿这张对比表来说网格方案胜在结构简单、下游友好查询点方案胜在把计算资源花在刀刃上但代价是新增了一套“点怎么放、怎么跑、怎么拼”的机制。2.2 “会跑”的本质从欧拉视角切到拉格朗日视角流体力学里有两个经典视角欧拉视角是固定坐标系看流体怎么流过每一个格点拉格朗日视角是跟着一个流体微团走看它在不同时刻到了哪里。密集体素网格在空间上就是典型的欧拉视角——坐标永远不变网络要自己感知内容的变化。SparseWorld 则更像拉格朗日视角——点本身是运动实体跟着场景里值得关注的结构走。所谓“会跑的查询点”本质上就是让点具备自己决定“下一帧去哪”的能力。如果某个点发现自己周围出现了一个正在移动的物体它应该跟着那个物体走如果它发现自己长期处在空地它应该往更有信息量的方向漂移。一千多个点组合起来就像一群浮标始终大致覆盖在场景中最值得关注的位置上。具体实现中位置更新通常不会一步到位。常见做法是预测一个三维位移向量然后限制单步位移幅度在同一帧内迭代数次让点逐步逼近最优位置。这也是为什么有些实现看起来很像“用 GRU 做位置迭代更新”的原因。限制步长非常关键否则点可能在两帧之间直接跳到一个完全不相关的区域导致时间上的抖动。2.3 局部感知场点与点怎么合作覆盖空间每个查询点只负责自己周围一个局部区域相当于一个探照灯。解码时把这个局部区域再划分成一个小网格比如 5×5×5 或 7×7×7查询点的特征通过 MLP 解码出这个小网格里每个体素的占用概率。一千多个点的小局部网格合起来就能覆盖整个场景里真正有东西的地方大片空白区域完全不参与计算。有人会问这样拼接出来的占用场会不会在点与点之间留下缝隙会但这正是一个需要靠设计解决的问题。局部感知半径要和查询点密度匹配半径太小容易漏检半径太大会让边界糊成一片。一个比较实用的做法是让相邻查询点的局部感受野有一定重叠重叠区域用最大池化或加权平均来融合这样既能覆盖连续空间又不会产生双倍计算。这个设计还有一个额外好处输出仍然是规则小体素格式只要把每个点解码出来的局部体素按坐标写回全局体素数组下游规划器依然可以按传统方式查询占用状态不需要改动太多对接逻辑。3. SparseWorld 关键模块拆解与实现要点3.1 查询点数量和感知范围怎么配为什么标题里说“一千多个”而不是几万个常见实现里 1024 或 2048 是典型配置这个数量级不是凭空拍出来的。查询点的数量下限取决于感知范围、目标物体最小尺寸和局部解码网格大小。思路其实很朴素把感知范围按最小识别物体的尺寸切分数一数“大约会落在非空区域内的格子数量”把它当作查询点数量的参考基线。举个例子如果局部解码网格是 5×5×5每个查询点大约覆盖边长 0.5 米的区域那么覆盖几十米范围内所有动态物体和关键静态障碍物1024 个点通常是够用的。设成 4096 个点覆盖率会更充分小物体会更容易召回但位置更新和解码的耗时也会成倍上升训练时点聚团的概率更大。我的经验是 256 到 1024 个点的收益提升最明显之后再往上加边际收益会快速递减。另外查询点初始化的分布方式比数量更影响最终效果。全范围均匀撒点虽然实现最简单但相当一部分点会落在远处的空地白白浪费。更好的做法是按先验布置自车前方密度高一点远处稀疏一点道路边界和车道中心附近多放一点绝对空地上少放一点。初始分布合理后续位置更新模块的压力也会小很多。3.2 特征从哪里来多模态输入如何注入查询点查询点不能只靠自己身上的那组随机初始化特征它必须理解当前场景。常见做法是让查询点在相机特征和激光雷达特征里做采样。激光雷达这边点云通常先经过 3D 稀疏卷积提取成稀疏体素特征然后以查询点坐标为中心做三线性插值或邻域聚合。相机这边把查询点坐标投影到图像平面做双线性采样多个相机的特征会汇总成一个向量。整个采样逻辑和 BEV 方法里的可微采样很像只是采样位置从固定网格变成了动态查询点。实操里有个容易踩的坑雷达点云在近处密度高在远处稀疏。如果每个查询点只用固定半径内的点云特征远距离查询点往往会采不到有效信息导致远处目标漏检。解决办法是给查询点配多尺度采样先用小半径提取局部细节再用大半径提取上下文或者在设计特征注入时根据雷达点的距离和密度做一个权重调整。只靠加大半径硬采反而会把近处目标的噪声带进来。3.3 位置更新模块让点“跑”起来的具体做法位置更新是整个 SparseWorld 方案里最核心的模块。它的输入是当前查询点的位置和特征输出是新位置或者位移向量。我见过的实现里比较顺手的结构是轻量级 GRU 加一个 MLP 回归头把上一帧的状态作为记忆让点具备短时运动惯性。这里给一段简化伪代码方便理解循环结构# 伪代码SparseWorld 风格的查询点循环更新简化 queries init_queries(centerego, bboxregion, num1024) # [1024, 3] states init_states(num1024) # [1024, D] for t in range(seq_len): feats gather_features(queries, img_feats, lidar_feats) # [1024, C] state, delta position_update(feats, states, queries) # 预测位移 queries queries delta.clamp(max_step0.3) # 限制单步位移 occ decode_local(queries, state) # 局部占用解码 record(occ, queries)注意两个细节第一位置更新做了 clamp 限幅不让点一步跑太远第二同一次推理里可以迭代 2 到 4 次让点逐渐逼近真实占用区域。这个“小步多走”的策略比直接回归大位移要稳定得多。时间维度上用上一帧的查询点状态来初始化当前帧就形成了隐式的时序记忆。代价是如果运动模块预测错了错误会被平滑带到下一帧所以初始化和前两帧的收敛质量特别重要。3.4 训练目标占用精度和位置引导要一起盯占用预测主损失没有太多花头最常见的是 BCE 或者 Focal Loss。由于局部小网格里正负样本比例依然可能失衡Focal Loss 会比普通 BCE 稳一些。真正容易翻车的是缺少“位置监督”。如果只让网络预测占用它很容易偷懒把所有查询点全部挤到最大的那个物体上因为这样占用损失很小但其他区域全丢了。SparseWorld 里一般会额外设计一个“查询点应覆盖非空区域”的损失。常见做法是对每个查询点找最近的真实占用点算 Chamfer 距离鼓励点和真实占用边界贴合或者把预测的非空期望当作软标签反过来引导位置更新头。时间一致性方面也有一个经典问题训练时开着 teacher forcing 很稳测试时一旦完全自回归预测就会开始漂移。常见解法是在训练过程中逐步提高自回归输入的比例让模型慢慢接管自己的预测再加一个帧间特征变化的正则项约束点的移动轨迹保持光滑。这两个 trick 对于 4D 占用建模来说属于性价比非常高的投入。4. 实际工程中的表现与调参现象记录4.1 最直观的收益占用分支变轻了在同样的场景和骨干网络下把固定体素占用分支换成稀疏查询点之后最直观的变化是显存占用和帧率。我没有严谨的 benchmark 数字因为各家平台、传感器、骨干网络差太多了单就个人经验来说占用解码分支的负担明显降了一个量级小批次训练也能塞进原来的显卡了。但要泼一盆冷水特征提取网络尤其是图像骨干和雷达稀疏卷积往往才是整体算力的大头。如果把骨干网络原封不动只换占用分支整体端到端速度的提升并不会像想象中那么夸张。SparseWorld 真正省下的是“把所有空间都当潜在占用”的冗余计算它不等同于把整个感知管线都变快。想拿到完整的性能收益通常还得在特征提取侧做配合比如降低 BEV 特征分辨率或减少骨干层数。4.2 查询点数从 256 涨到 4096 会发生什么这个部分我在项目里专门调过一串实验。256 个点时覆盖密度明显不足小目标经常漏检升到 1024 个点覆盖率接近可用状态大多数障碍物都能正确出现在局部占用场里再往上涨到 4096 个点召回率还会继续改善但位置更新模块和解码头的时间开销也随之翻倍。更有意思的问题是“维度灾难”会转移到点分布上点越多越容易扎堆训练时如果不加位置均匀性约束点可能密密麻麻全堆在几个大车身上。为了压住这种倾向往往还得给损失函数加额外的惩罚项。结果就是堆点数不如改善位移更新策略把 1024 个点管好比粗暴地加 4096 个点更有实际价值。4.3 动态场景的连续性点真的会跟着物体走做 4D 占用最终看的是时序上的稳定输出。网格方案在每一帧独立做预测连续帧之间容易出现跳变今天识别成车、明天识别成树的状况时有发生。查询点方案因为有历史状态下一帧预测是在上一帧的基础上做的输出天然更平滑。我在可视化里看到过很有意思的现象当一个查询点锁定了一辆正在变道的车它的坐标会持续跟着那辆车移动而不是停在后方的固定网格里。这就是拉格朗日视角带来的优势。不过这也意味着如果运动预测模块判断错了点可能会从一辆车“串”到另一辆车上去导致特征状态被带偏。所以动态场景下的序列启动阶段尤其关键经常需要在前几帧加较大的 dropout 或噪声让模型学会纠正错误跟随。5. 常见问题与避坑清单5.1 查询点聚成一个团怎么处理现象所有点都堆在某个大目标附近远处小目标完全没点。原因通常是位置监督被大目标主导点被大量拉到占用重心附近。排查时先把可视化打开看点的分布是否均匀。解决思路有两个方向。一是初始化时把查询点分成两拨一拨做均匀覆盖负责背景和静态障碍物一拨做动态跟随负责预测运动。二是加均匀性正则直接约束每个局部区域内能容纳的点数上限。我试过几轮两个方向配合使用最稳定单靠哪一个都容易复发现。5.2 远处目标漏检怎么处理现象近处车辆都出来了远处几十米外的行人和车辆经常丢失。原因大概率是雷达点云远距稀疏、特征采样不足或者查询点初始化时远处分布太少。排查时先检查查询点初始化分布远处的点是否太少再检查特征注入半径远处查询点是否能采到有效的上下文。一个实用组合是远处多分配一点初始化点同时给采样模块加多尺度特征让远距离点能够借用更大范围的上下文。还有一个小技巧给点云距离加权重让远距离点的重要性不至于被近处高密度点掩盖。5.3 拼接出来的占用图有空洞和毛刺现象物体中间出现莫名其妙的空腔或者边界像锯齿。原因多数是查询点覆盖密度不足解码半径设置偏小。排查时把当前帧所有查询点的覆盖范围可视化和真实占用标注做对比统计一下“被查询点覆盖到的非空区域”占全部非空区域的比例。如果低于 90%就需要增加点数或加大解码半径。毛刺则往往来自重叠区域融合方式点与点的局部体素重叠后取 max 容易保留噪声取平均容易模糊边界。可视化对比几种融合策略比盲调损失更快。5.4 训练时模型输出全是 free现象:训练到一半网络学会了把所有查询点都预测成“无占用”整体占用图一片空白。原因通常是空区域缺少负样本网络发现输出 free 的损失更低就选择保守策略。解决办法是在训练时除了让查询点覆盖非空区域还特意在随机空区域采样一批负样本查询点给它们 free 监督。这样网络才会被迫区分“这是真空地”和“这里有物体”。这个坑非常容易踩尤其是当位置引导损失设置太弱的时候。5.5 给规划模块交付什么格式现象模型训练没问题但规划模块说拿不到可以用的话题。原因是对接层没处理好。SparseWorld 内部是稀疏查询点但规划模块通常只认规则体素数组。处理方法是把每个查询点解码出来的局部小体素通过它们携带的坐标索引写回全局体素数组重叠位置按 max 或加权平均合并。输出给下游的就是标准的 3D 占用地图。如果规划模块也支持稀疏查询那就更好办直接把查询点和占用置信度打包成稀疏张量流即可。工程上我一般会保留两种输出接口方便不同下游模块使用。我自己做下来最深的体会是SparseWorld 这类方案最有趣的地方并不是“省显存”这个结果而是它逼着设计者重新回答了一个问题一个感知模型到底应该把算力花在空间里的哪个坐标上一千多个查询点更像一团有判断力的浮标而不是一张铺满全场的固定渔网。如果你也想在自己的项目里尝试替换密集体素网格我建议从小场景开始先把查询点可视化打开观察它在每一帧是怎么移动的。这个直观规律比任何网络结构参数都值得先看清楚等看懂了点的移动逻辑再去调数量、调步长、调损失整个系统会顺很多。
做 4D 占用世界模型的人几乎都绕不开密集体素网格这道坎。空间被切成几百万个格子每个都要算一遍可真正有东西的格子连百分之一都不到。第一次看到 SparseWorld 这个思路时我印象最深的并不是它用了什么花哨网络而是它把问题换了一种问法既然整张网格大多是空的为什么还要让模型在空白上浪费那么多算力SparseWorld 的做法很直接——扔掉密集体素网格只放一千多个会跑的查询点让它们自己去找场景里值得关心的位置。这篇文章不打算复述复杂公式主要想从思路拆解、模块设计到踩坑记录聊聊这套替代方案到底怎么落地适合正在做占用预测、端到端感知或者世界模型的朋友参考。1. 为什么密集体素网格会成为 4D 占用建模的瓶颈1.1 先算一笔体素账密集体素网格的问题从来不是概念不好懂而是账面数字太吓人。假设自车前方 70 米、左右各 35 米、高度范围从 -2 米到 4 米分辨率取 0.2 米那么体素数就是 350 × 350 × 30约 367 万个。这还只是三维空间的一帧占用。如果换成 0.1 米分辨率体素数量会直接乘以 8变成近三千万个。很多团队一开始觉得 3D 卷积能扛但实际跑起来才发现分辨率一旦上去显存和算力几乎是指数级增长。尤其做 4D 占用世界模型时要把时间维度也纳进来每一帧关键帧都对应一整套三维体素特征多帧累积之后特征图数量成倍增加。更麻烦的是3D 卷积的感受野是固定的哪怕某个格子的周围全是空白卷积核也必须在那个位置做完整的乘加运算。换句话说大量算力被消耗在“查无此物”的区域上。体素账真正可怕的地方在于你为整个空间预分配了完整的内存和计算资源但实际用到的只有其中极少一部分。这叫结构性浪费换再好的卷积网络也救不回来。1.2 真实道路场景里的占用率低得离谱城市道路场景虽然看着繁忙可把三维空间量化成体素之后真正被车、树、行人、护栏占据的格子通常只有几个百分点。大部分区域要么是自由空间要么是长期不变的背景。做一个简单类比密集体素网格就像是一个安保系统对着整栋大楼的每一个房间都装监控不管有没有人而稀疏查询点方案则是在有人活动的地方才调度摄像头资源。这个差异在训练阶段尤其明显。网格模型的监督信号天然偏向空区域因为空体素数量压倒性地多。网络学来学去大量容量都在拟合“这里没东西”而不是去分辨“这里有车”和“这里有行人”的边界。所以不少做占用预测的团队会观察到分辨率调到一定程度后IoU 指标反而上不去甚至开始掉。这不是网络能力不够而是优化目标被空白区域稀释了。SparseWorld 的核心动机就是把这个比例倒过来不再假设空间处处需要建模而是默认空间大部分是空的只在可能发生占用变化的位置投入计算资源。这个前提一旦成立后边的结构设计就顺理成章了。1.3 网格在时间维度上的额外成本4D 占用世界模型真正区别于静态占用预测的点在于它必须感知“空间在时间里的变化”。固定网格做法为了建模动态场景通常要维护过去 N 帧的体素特征做对齐、累积、融合。每多存一帧历史内存就多一份体素量级的开销。自车还在持续运动还得处理 ego-motion 补偿否则同一个格子的内容会在不同帧之间漂移。网格方案的时间维灵活性也比较差分辨率是固定的一秒钟 60 帧不可能对每一帧、每一个位置都做精细的时序建模。你只能在分辨率、历史长度、算力之间妥协。SparseWorld 换成查询点之后情况完全不一样。点作为一个实体可以从上一帧继承状态在时间上做平滑的更新。你不需要把整个空间的历史都存下来只需要保存每个查询点的位置和历史特征。计算量跟随“场景里关心对象数量”增长而不是“空间格子数量”增长。这个差异在长时序预测里会越拉越大。2. SparseWorld 的核心策略一千多个查询点怎么干活2.1 查询点不是普通采样点而是有状态的软体素很多人第一次听说查询点会把它理解成“在空间里随机撒一堆点然后取特征”。这是常见的误解。SparseWorld 里的查询点是带状态的实体一般包含三样东西空间坐标、特征向量、局部感知范围。坐标决定了这个点当前关心哪里特征向量编码了这个位置周围应该有什么感知范围则决定了它能代表多大一块局部区域。可以把它理解成一个“软体素”。普通体素是固定坐标、固定大小的硬格子查询点则可以在连续空间里自由分布。靠近物体边界时可以更密远离物体时可以更疏。它不需要对齐到任何固定分辨率从根本上绕开了“分辨率该设多少”这个纠缠不清的问题。这里也能看到与 BEV 感知里 object query 的区别。DETR 一类方法里的 object query 最终目的是出检测框或分割掩码SparseWorld 的查询点则是为了回答“我所在的这个位置以及我周围的这一小块空间在未来是否被占据”。它更像是一个智能探针而不是一个输出头。维度密集体素网格SparseWorld 稀疏查询点空间覆盖方式固定间隔铺满整个区域动态分布在非空区域附近内存开销随分辨率三次方增长随查询点数量线性增长时间建模需要维护多帧历史体素点继承状态自然做时序更新动态目标跟踪靠重新预测容易跳变点可以跟着目标移动输出连续下游产物规则体素直接可查解码成局部体素后拼接成规则网格主要风险分辨率与算力难以兼顾点分布质量决定成败拿这张对比表来说网格方案胜在结构简单、下游友好查询点方案胜在把计算资源花在刀刃上但代价是新增了一套“点怎么放、怎么跑、怎么拼”的机制。2.2 “会跑”的本质从欧拉视角切到拉格朗日视角流体力学里有两个经典视角欧拉视角是固定坐标系看流体怎么流过每一个格点拉格朗日视角是跟着一个流体微团走看它在不同时刻到了哪里。密集体素网格在空间上就是典型的欧拉视角——坐标永远不变网络要自己感知内容的变化。SparseWorld 则更像拉格朗日视角——点本身是运动实体跟着场景里值得关注的结构走。所谓“会跑的查询点”本质上就是让点具备自己决定“下一帧去哪”的能力。如果某个点发现自己周围出现了一个正在移动的物体它应该跟着那个物体走如果它发现自己长期处在空地它应该往更有信息量的方向漂移。一千多个点组合起来就像一群浮标始终大致覆盖在场景中最值得关注的位置上。具体实现中位置更新通常不会一步到位。常见做法是预测一个三维位移向量然后限制单步位移幅度在同一帧内迭代数次让点逐步逼近最优位置。这也是为什么有些实现看起来很像“用 GRU 做位置迭代更新”的原因。限制步长非常关键否则点可能在两帧之间直接跳到一个完全不相关的区域导致时间上的抖动。2.3 局部感知场点与点怎么合作覆盖空间每个查询点只负责自己周围一个局部区域相当于一个探照灯。解码时把这个局部区域再划分成一个小网格比如 5×5×5 或 7×7×7查询点的特征通过 MLP 解码出这个小网格里每个体素的占用概率。一千多个点的小局部网格合起来就能覆盖整个场景里真正有东西的地方大片空白区域完全不参与计算。有人会问这样拼接出来的占用场会不会在点与点之间留下缝隙会但这正是一个需要靠设计解决的问题。局部感知半径要和查询点密度匹配半径太小容易漏检半径太大会让边界糊成一片。一个比较实用的做法是让相邻查询点的局部感受野有一定重叠重叠区域用最大池化或加权平均来融合这样既能覆盖连续空间又不会产生双倍计算。这个设计还有一个额外好处输出仍然是规则小体素格式只要把每个点解码出来的局部体素按坐标写回全局体素数组下游规划器依然可以按传统方式查询占用状态不需要改动太多对接逻辑。3. SparseWorld 关键模块拆解与实现要点3.1 查询点数量和感知范围怎么配为什么标题里说“一千多个”而不是几万个常见实现里 1024 或 2048 是典型配置这个数量级不是凭空拍出来的。查询点的数量下限取决于感知范围、目标物体最小尺寸和局部解码网格大小。思路其实很朴素把感知范围按最小识别物体的尺寸切分数一数“大约会落在非空区域内的格子数量”把它当作查询点数量的参考基线。举个例子如果局部解码网格是 5×5×5每个查询点大约覆盖边长 0.5 米的区域那么覆盖几十米范围内所有动态物体和关键静态障碍物1024 个点通常是够用的。设成 4096 个点覆盖率会更充分小物体会更容易召回但位置更新和解码的耗时也会成倍上升训练时点聚团的概率更大。我的经验是 256 到 1024 个点的收益提升最明显之后再往上加边际收益会快速递减。另外查询点初始化的分布方式比数量更影响最终效果。全范围均匀撒点虽然实现最简单但相当一部分点会落在远处的空地白白浪费。更好的做法是按先验布置自车前方密度高一点远处稀疏一点道路边界和车道中心附近多放一点绝对空地上少放一点。初始分布合理后续位置更新模块的压力也会小很多。3.2 特征从哪里来多模态输入如何注入查询点查询点不能只靠自己身上的那组随机初始化特征它必须理解当前场景。常见做法是让查询点在相机特征和激光雷达特征里做采样。激光雷达这边点云通常先经过 3D 稀疏卷积提取成稀疏体素特征然后以查询点坐标为中心做三线性插值或邻域聚合。相机这边把查询点坐标投影到图像平面做双线性采样多个相机的特征会汇总成一个向量。整个采样逻辑和 BEV 方法里的可微采样很像只是采样位置从固定网格变成了动态查询点。实操里有个容易踩的坑雷达点云在近处密度高在远处稀疏。如果每个查询点只用固定半径内的点云特征远距离查询点往往会采不到有效信息导致远处目标漏检。解决办法是给查询点配多尺度采样先用小半径提取局部细节再用大半径提取上下文或者在设计特征注入时根据雷达点的距离和密度做一个权重调整。只靠加大半径硬采反而会把近处目标的噪声带进来。3.3 位置更新模块让点“跑”起来的具体做法位置更新是整个 SparseWorld 方案里最核心的模块。它的输入是当前查询点的位置和特征输出是新位置或者位移向量。我见过的实现里比较顺手的结构是轻量级 GRU 加一个 MLP 回归头把上一帧的状态作为记忆让点具备短时运动惯性。这里给一段简化伪代码方便理解循环结构# 伪代码SparseWorld 风格的查询点循环更新简化 queries init_queries(centerego, bboxregion, num1024) # [1024, 3] states init_states(num1024) # [1024, D] for t in range(seq_len): feats gather_features(queries, img_feats, lidar_feats) # [1024, C] state, delta position_update(feats, states, queries) # 预测位移 queries queries delta.clamp(max_step0.3) # 限制单步位移 occ decode_local(queries, state) # 局部占用解码 record(occ, queries)注意两个细节第一位置更新做了 clamp 限幅不让点一步跑太远第二同一次推理里可以迭代 2 到 4 次让点逐渐逼近真实占用区域。这个“小步多走”的策略比直接回归大位移要稳定得多。时间维度上用上一帧的查询点状态来初始化当前帧就形成了隐式的时序记忆。代价是如果运动模块预测错了错误会被平滑带到下一帧所以初始化和前两帧的收敛质量特别重要。3.4 训练目标占用精度和位置引导要一起盯占用预测主损失没有太多花头最常见的是 BCE 或者 Focal Loss。由于局部小网格里正负样本比例依然可能失衡Focal Loss 会比普通 BCE 稳一些。真正容易翻车的是缺少“位置监督”。如果只让网络预测占用它很容易偷懒把所有查询点全部挤到最大的那个物体上因为这样占用损失很小但其他区域全丢了。SparseWorld 里一般会额外设计一个“查询点应覆盖非空区域”的损失。常见做法是对每个查询点找最近的真实占用点算 Chamfer 距离鼓励点和真实占用边界贴合或者把预测的非空期望当作软标签反过来引导位置更新头。时间一致性方面也有一个经典问题训练时开着 teacher forcing 很稳测试时一旦完全自回归预测就会开始漂移。常见解法是在训练过程中逐步提高自回归输入的比例让模型慢慢接管自己的预测再加一个帧间特征变化的正则项约束点的移动轨迹保持光滑。这两个 trick 对于 4D 占用建模来说属于性价比非常高的投入。4. 实际工程中的表现与调参现象记录4.1 最直观的收益占用分支变轻了在同样的场景和骨干网络下把固定体素占用分支换成稀疏查询点之后最直观的变化是显存占用和帧率。我没有严谨的 benchmark 数字因为各家平台、传感器、骨干网络差太多了单就个人经验来说占用解码分支的负担明显降了一个量级小批次训练也能塞进原来的显卡了。但要泼一盆冷水特征提取网络尤其是图像骨干和雷达稀疏卷积往往才是整体算力的大头。如果把骨干网络原封不动只换占用分支整体端到端速度的提升并不会像想象中那么夸张。SparseWorld 真正省下的是“把所有空间都当潜在占用”的冗余计算它不等同于把整个感知管线都变快。想拿到完整的性能收益通常还得在特征提取侧做配合比如降低 BEV 特征分辨率或减少骨干层数。4.2 查询点数从 256 涨到 4096 会发生什么这个部分我在项目里专门调过一串实验。256 个点时覆盖密度明显不足小目标经常漏检升到 1024 个点覆盖率接近可用状态大多数障碍物都能正确出现在局部占用场里再往上涨到 4096 个点召回率还会继续改善但位置更新模块和解码头的时间开销也随之翻倍。更有意思的问题是“维度灾难”会转移到点分布上点越多越容易扎堆训练时如果不加位置均匀性约束点可能密密麻麻全堆在几个大车身上。为了压住这种倾向往往还得给损失函数加额外的惩罚项。结果就是堆点数不如改善位移更新策略把 1024 个点管好比粗暴地加 4096 个点更有实际价值。4.3 动态场景的连续性点真的会跟着物体走做 4D 占用最终看的是时序上的稳定输出。网格方案在每一帧独立做预测连续帧之间容易出现跳变今天识别成车、明天识别成树的状况时有发生。查询点方案因为有历史状态下一帧预测是在上一帧的基础上做的输出天然更平滑。我在可视化里看到过很有意思的现象当一个查询点锁定了一辆正在变道的车它的坐标会持续跟着那辆车移动而不是停在后方的固定网格里。这就是拉格朗日视角带来的优势。不过这也意味着如果运动预测模块判断错了点可能会从一辆车“串”到另一辆车上去导致特征状态被带偏。所以动态场景下的序列启动阶段尤其关键经常需要在前几帧加较大的 dropout 或噪声让模型学会纠正错误跟随。5. 常见问题与避坑清单5.1 查询点聚成一个团怎么处理现象所有点都堆在某个大目标附近远处小目标完全没点。原因通常是位置监督被大目标主导点被大量拉到占用重心附近。排查时先把可视化打开看点的分布是否均匀。解决思路有两个方向。一是初始化时把查询点分成两拨一拨做均匀覆盖负责背景和静态障碍物一拨做动态跟随负责预测运动。二是加均匀性正则直接约束每个局部区域内能容纳的点数上限。我试过几轮两个方向配合使用最稳定单靠哪一个都容易复发现。5.2 远处目标漏检怎么处理现象近处车辆都出来了远处几十米外的行人和车辆经常丢失。原因大概率是雷达点云远距稀疏、特征采样不足或者查询点初始化时远处分布太少。排查时先检查查询点初始化分布远处的点是否太少再检查特征注入半径远处查询点是否能采到有效的上下文。一个实用组合是远处多分配一点初始化点同时给采样模块加多尺度特征让远距离点能够借用更大范围的上下文。还有一个小技巧给点云距离加权重让远距离点的重要性不至于被近处高密度点掩盖。5.3 拼接出来的占用图有空洞和毛刺现象物体中间出现莫名其妙的空腔或者边界像锯齿。原因多数是查询点覆盖密度不足解码半径设置偏小。排查时把当前帧所有查询点的覆盖范围可视化和真实占用标注做对比统计一下“被查询点覆盖到的非空区域”占全部非空区域的比例。如果低于 90%就需要增加点数或加大解码半径。毛刺则往往来自重叠区域融合方式点与点的局部体素重叠后取 max 容易保留噪声取平均容易模糊边界。可视化对比几种融合策略比盲调损失更快。5.4 训练时模型输出全是 free现象:训练到一半网络学会了把所有查询点都预测成“无占用”整体占用图一片空白。原因通常是空区域缺少负样本网络发现输出 free 的损失更低就选择保守策略。解决办法是在训练时除了让查询点覆盖非空区域还特意在随机空区域采样一批负样本查询点给它们 free 监督。这样网络才会被迫区分“这是真空地”和“这里有物体”。这个坑非常容易踩尤其是当位置引导损失设置太弱的时候。5.5 给规划模块交付什么格式现象模型训练没问题但规划模块说拿不到可以用的话题。原因是对接层没处理好。SparseWorld 内部是稀疏查询点但规划模块通常只认规则体素数组。处理方法是把每个查询点解码出来的局部小体素通过它们携带的坐标索引写回全局体素数组重叠位置按 max 或加权平均合并。输出给下游的就是标准的 3D 占用地图。如果规划模块也支持稀疏查询那就更好办直接把查询点和占用置信度打包成稀疏张量流即可。工程上我一般会保留两种输出接口方便不同下游模块使用。我自己做下来最深的体会是SparseWorld 这类方案最有趣的地方并不是“省显存”这个结果而是它逼着设计者重新回答了一个问题一个感知模型到底应该把算力花在空间里的哪个坐标上一千多个查询点更像一团有判断力的浮标而不是一张铺满全场的固定渔网。如果你也想在自己的项目里尝试替换密集体素网格我建议从小场景开始先把查询点可视化打开观察它在每一帧是怎么移动的。这个直观规律比任何网络结构参数都值得先看清楚等看懂了点的移动逻辑再去调数量、调步长、调损失整个系统会顺很多。
