1. 先厘清 FastOcc 到底在解决什么问题三年前我第一次把占用栅格预测的网络跑通盯着 200×200×16 的体素网格里慢慢浮出车道、路沿还有远处那堵墙那感觉像把一台老收音机调到正确频率——噪声里突然冒出一段清晰的信号。兴奋没撑过一周实测帧率只有个位数车端那点算力根本吃不下。后来我盯上 FastOcc 这类方案原因很朴素它不是再刷一个精度点的模型而是围绕“让占用预测真正落进车端时间预算”重新做取舍的一整套工程打法。这里说的占用栅格预测行业里习惯简称 Occ做的事是把自车周围的空间切成一格一格的立方体判断每一格里有没有东西、是什么东西。它跟传统 3D 检测最大的区别在于检测是“找出若干个体每个体给个框和类别”Occ 是“把整个空间填满每格都要有结论”。好处是形状不规则的东西、被遮挡的东西、从没见过的东西都能以“被占用”的形式表达出来代价是计算量大得离谱因为你要处理的不是一个稀疏的点集而是一整个三维空间。FastOcc 瞄准的就是这个矛盾在保持可用的几何精度前提下把单帧推理压进几十毫秒量级同时让模型能真正部署到车端芯片或受限 GPU 上。适合读这篇的人分三类正在做车端感知部署、被 Occ 模型拖到掉帧的工程师刚入门 BEV 与占用预测、想搞清楚“为什么慢、慢在哪”的同学以及手上只有中低算力平台、需要在精度和速度之间找平衡点的项目负责人。需要说明下面涉及的架构细节与参数一部分来自公开方案的通用做法一部分是我在实际项目中反复试出来的经验值凡是补全的部分我都会点明是“常见实践”不代表某个特定产品的实现。1.1 从“看得见”到“测得准”占用预测的定位在哪先说清楚 Occ 在整个感知栈里的位置不然后面所有的优化都缺少参照。相机图像进来经过主干网络提特征再做视角变换把 2D 特征投到 3D 空间然后要么用稠密 3D 卷积、要么用稀疏卷积在体素上做特征聚合最后每个体素接一个分类头空/占用和一个语义头车、人、路面、植被等。激光雷达点云则可以直接体素化后作为监督信号或输入分支。这个链路里有两个天然的瓶颈。第一个是视角变换把图像特征“抬”到三维本质上是一个没有唯一解的病态问题一个像素对应一条射线上的无数个点模型只能靠深度分布去猜。第二个是三维卷积本身体素网格的规模随分辨率呈三次方增长你把边长精度从 0.5 米提到 0.4 米体素数量直接涨到原来的近两倍。这两处一叠加帧率就崩了。我的判断是视角变换决定了精度的天花板三维特征处理决定了速度的地板。FastOcc 这类方案的重心明显压在后半段——它承认深度估计不可能完美转而把工程力气花在“如何用更少的有效计算把体素填对”上。这个选型思路我认为是对的因为深度估计的精度靠的是数据和训练策略短期很难有量级突破而稀疏化和算子优化是能实打实换来几倍加速的。1.2 算力账本摊开算慢到底慢在哪很多人调优是凭感觉的看到掉帧就去砍分辨率结果精度崩了还没提速多少。我习惯先把账算明白。假设感知范围前后左右各 50 米高度从地面下 5 米到地面上 3 米体素边长 0.5 米那么网格尺寸是横向100 m / 0.5 m 200 格纵向100 m / 0.5 m 200 格高度8 m / 0.5 m 16 格总体素数 200 × 200 × 16 640,000。若特征通道是 32单精度浮点存储一个特征张量就是 640000 × 32 × 4 字节 ≈ 81.9 MB。听着还行但训练时反向传播要缓存每一层的激活值一个十几层的 3D 主干下来光激活就能吃掉好几 GB 显存。推理时虽然不存梯度但每一层的读写带宽同样是负担。更关键的是这 64 万个体素里真正有东西的通常只占 3% 到 8%。也就是说九成以上的计算是在一堆空的空气格子上做卷积。这就是为什么稀疏化是绕不过去的路。但稀疏化不是免费的午餐它带来的是索引管理开销、算子碎片化、以及部署阶段的一堆麻烦后文会详细说。还有一个常被忽略的点时序融合。单帧 Occ 对遮挡区域基本靠猜加了历史帧之后精度能提好几个点但代价是要缓存并对齐多帧体素特征显存和带宽翻倍。FastOcc 在这块的思路是“只融合有用的部分”具体做法我在第 2 章展开。1.3 FastOcc 的三条主线速度、精度、可部署性我把这类方案的优化拆成三条并行推进的主线理解了这个框架你看任何一篇 Occ 加速工作都能快速归类。第一条是空间稀疏化。核心是把稠密体素换成稀疏张量只在非空位置做计算。这条线能带来数倍加速但需要自定义算子和部署侧的配合。第二条是特征维度压缩与多尺度设计。高分辨率只在浅层用深层快速下采样用一个“粗到细”的结构把感受野撑开而不用付三次方的代价。这条线对精度影响可控属于性价比很高的优化。第三条是部署友好性。包括算子是否能在目标推理引擎里找到对应实现、能否量化、有没有动态 shape、内存访问是否连续。很多实验室里跑得飞快的模型一上板子就废掉问题全出在这条线上。三条线之间存在明显张力越稀疏部署越难越激进降采样小目标召回越差。FastOcc 的价值就在于它给出了一个明确的三线平衡点而不是单点突破。2. 整体架构设计为什么这么选聊完问题进入设计层面。我先把一个常见误区摆出来不少人以为 Occ 加速的关键是换个更轻的主干网络。实测下来主干换小带来的收益有限因为图像主干的耗时在整体链路里可能只占三成大头在三维部分和视角变换。所以真正有效的做法是把三维部分的结构重做而不是把二维主干砍掉。2.1 主干与视角变换的取舍逻辑图像主干这块我倾向选一个“深度可分离 通道可裁剪”的结构宽度系数按目标平台算力定不追求 SOTA。原因是 Occ 任务对纹理细节的敏感度不如分类任务它更依赖几何结构所以主干的通道冗余度可以压得比较狠。实测把宽度系数从 1.0 降到 0.5mIoU 掉大约 1.5 个点但主干耗时能砍一半以上这笔交易划算。视角变换这里有两个主流方向差别很大我列个表对比。方案类型核心机制优点代价适用场景深度分布抬升每个像素预测深度分布按权重把特征撒到体素结构简单易并行深度估计误差直接传导远处精度差中低算力平台追求实时查询式变换用一组 3D 查询去图像特征里采样几何一致性更好采样算子重训练慢高算力平台追求精度射线采样沿相机射线在体素里均匀取点再聚合显存友好可控制点数点密度需要调参折中方案工程上常用我在实际项目里多数时候选第一种或第三种。理由很直接查询式变换的采样算子在部署时经常找不到高效实现最后不得不退回稠密版本前面的优化白做。而深度分布抬升虽然精度略低但整个流程都是常规算子量化、导出、加速都顺。注意选深度分布方案时深度监督信号的构造方式会极大影响远处精度。别只用稀疏的激光点做监督那样近处准远处糊一定要补上基于邻域稠密化的伪监督否则你会误以为是网络容量不够。2.2 稀疏化怎么落地别一上来就全稀疏稀疏化这件事我踩过的最大坑是“一刀切”。一开始我把整个三维主干全换成稀疏卷积训练能跑但收敛特别慢而且小目标召回掉了不少。后来才想明白浅层特征密度高稀疏化的收益小、索引开销反而大深层特征稀疏度高收益才明显。所以比较稳的做法是分层混合前一到两级用稠密卷积因为此时分辨率最高但通道最少计算量还在可控范围从第三级开始转稀疏此时空间已经下采样过非空比例降低稀疏卷积的索引开销摊薄了。这个切换点不是拍脑袋定的要看你的实际占用比例一般建议在非空率降到 15% 以下时切换。稀疏张量的组织方式也有讲究。常见的是坐标加特征的组合坐标用一个形状为 (N, 4) 的整型张量存批次索引和 xyz特征用 (N, C) 存。这种格式灵活但每次卷积都要做坐标映射开销不小。另一种是规则化的稀疏块格式把 8×8×8 的邻域压成固定长度的向量牺牲一点灵活性换取访存连续。我实测后者在车端平台上快 20% 到 30%代价是边界处理麻烦。2.3 时序融合的轻量化处理时序融合是精度提升性价比最高的一招但也是最容易把速度拖垮的一招。朴素做法是缓存过去若干帧的体素特征按自车位姿变换到当前坐标系然后拼起来或者做注意力融合。问题在于自车一动历史特征要做重采样重采样是个逐体素的插值操作非常吃带宽。我的处理思路是“只对齐、不插值”。具体说位姿变换只做整数格点的平移旋转不做三线性插值误差靠后续卷积层自己学回来。这么做精度会掉一点点但耗时能降一大截。另一个技巧是历史帧降采样后再融合比如当前帧用 0.5 米分辨率历史帧用 1.0 米分辨率融合时上采样对齐。因为历史信息本来就是补充遮挡区域用的不需要那么高的空间精度。还有一个隐性成本是缓存管理。多帧特征常驻显存帧数一多就爆。我一般把历史帧限制在 2 到 4 帧并且用环形缓冲区加固定地址分配避免训练时反复申请释放造成碎片。2.4 监督信号怎么配别只盯着一个损失Occ 的监督比检测复杂得多。我的配置通常是三项加权体素级的二分类损失有没有东西、语义分类损失是什么、以及几何一致性损失相邻体素的预测要平滑。这里有个经验二分类损失用 focal 变体语义损失用类别平衡的交叉熵权重比大概 1 : 1。为什么因为空体素占了九成以上不加 focal 的话网络会倾向于全预测为空训练前期 loss 降得飞快但 mIoU 一直是零。而语义损失只在非空体素上算本身就不存在极端不均衡问题用普通交叉熵加类别权重就够了。还有一项容易被忽略的是射线方向的深度监督。如果你用深度分布抬升做视角变换一定要给深度头单独的监督并且这个损失的权重要在训练中期衰减不然后期会压制几何精度的进一步提升。我一般用 0.5 起步到总 epoch 的 60% 时线性降到 0.1。3. 核心细节与实操要点参数怎么定这一章是干货密集区我把几个反复调过的参数拿出来讲清楚推导过程你可以直接照着改。3.1 体素分辨率与感受野的参数计算分辨率选择是整个方案的锚点它决定了后面所有参数。我给一个从需求倒推的方法。先定感知距离。城市工况下自车要提前 2 秒做决策按 60 km/h 算就是 33 米加上制动余量前方 50 米是底线。侧向因为要处理加塞和路口一般取 30 到 40 米。这样一来网格尺寸就定死在 100×100 到 100×80 米的范围内。再定精度需求。要区分行人和非机动车体素边长不能大于 0.5 米要区分路沿和车道线0.3 到 0.4 米比较合适。但前面算过边长缩小 20%体素数量涨 46%。我的经验值是城区用 0.4 米高速用 0.5 米分开训练两套权重别指望一套通吃。高度方向的网格数也要克制。地面以下 2 米到地上 3 米5 米高度、0.5 米边长是 10 格取 16 格是 2 的幂次方便对齐和后续的池化操作多出来的空间当作安全余量。感受野的算法很简单堆 k 层 3×3×3 卷积感受野是 2k1 个体素。要在最深层覆盖 40 米以上的上下文按 0.4 米体素算需要 100 格那就要堆到 50 层显然不现实。所以必须靠下采样每次空间尺寸减半感受野翻倍。四层下采样之后同样的卷积层数能覆盖的范围扩大 16 倍这才是撑开感受野的正确方式。下面这张表是我实测的不同配置对比硬件是一块中端车载 GPU输入 6 路环视分辨率 800×448。体素边长网格尺寸非空率显存占用单帧耗时mIoU 参考0.5 m200×200×165.2%3.1 GB42 ms基准0.4 m250×250×164.1%4.6 GB63 ms1.80.4 m 稀疏主干250×250×164.1%2.4 GB38 ms1.60.3 m 稀疏主干334×334×203.3%3.8 GB高速档不可用2.9可以看到单纯提分辨率会同时吃显存和时间稀疏化之后才能把两头都压下来。0.3 米那一档在部分平台上根本跑不动属于“实验室可用、量产不可用”的范畴。3.2 稀疏卷积的通道配置与显存预算通道配置是最容易拍脑袋的地方。我的做法是按“空间尺寸的平方根”来分配让各层的计算量尽量均衡。具体说第一级空间尺寸最大通道给 16 或 24第二级空间减半通道翻到 32第三级再减半通道 64第四级 96 或 128。这个梯度比常见的 32/64/128/256 要窄原因是三维卷积的计算量是通道数的平方乘以空间大小通道堆太猛计算量涨得比二维更厉害。显存预算我一般按“特征图 索引 激活缓存”三块估。特征图按前面的公式算索引大约是特征图大小的 1/4因为它存的是整型坐标激活缓存只在训练时有大概是特征图总量的 2 到 3 倍取决于是否用梯度检查点。开启梯度检查点能省掉一大半激活显存代价是训练时间增加约 20%长训任务我会默认开。提示稀疏张量的批次拼接是显存杀手。多帧融合时如果每帧独立存一份坐标索引内存会翻倍。做法是用一个共享的坐标表加偏移量把多帧压进同一个稀疏张量里处理实测能省 30% 左右的索引开销。3.3 数据增强与类别不均衡处理三维场景的数据增强跟二维图像完全不同别直接套图像那套。我做过的有效增强有这几样全局旋转绕竖直轴随机旋转 ±15 度模拟路口不同朝向。注意旋转后要同步变换监督标签和位姿很多人只转了输入忘了标签。局部抠除随机挖掉一个立方体区域模拟遮挡。这个对提升鲁棒性效果明显但挖的区域别太大边长控制在 4 到 8 米。尺度抖动整体缩放 ±5%这个要谨慎会影响深度估计的绝对尺度。稀有类别过采样行人、非机动车在体素里占比可能不到 1%我把包含这些类别的场景帧采样权重提到 3 倍。类别不均衡还有个处理是损失加权但我不建议直接按频率倒数加权那样会把稀有类别权重抬到几百倍训练直接发散。稳妥做法是 cap 在 10 倍以内剩下的靠采样解决。3.4 训练策略里几个必须调对的参数学习率用 2e-4 起步配合余弦退火和 500 步线性 warmup。为什么不用常见的 1e-3因为稀疏卷积的梯度尺度比稠密卷积大学习率过高前几百步容易炸。批大小受显存限制我用 2 到 4。批太小会导致批归一化统计不稳所以要么改用组归一化要么在稀疏层里干脆不用归一化。我的选择是图像主干用批归一化三维部分用组归一化实测下来收敛曲线比较平顺。EMA 权重要开衰减率 0.999。稀疏模型的参数更新噪声大EMA 能明显稳住验证集指标。梯度裁剪设 10这个是防止个别帧的极端场景导致梯度爆掉。我遇到过一帧数据标错了高度范围不裁的话整个训练直接崩。训练轮次 24 到 36 之间看数据规模。太短欠拟合太长开始过拟合验证集 mIoU 会先涨后跌拐点一般在 20 轮以后。4. 从训练到部署工程落地全流程实验室跑通和车端跑通是两码事这一章按顺序把流程走一遍。4.1 环境与依赖准备基础环境用 PyTorch稀疏部分依赖稀疏卷积库这些在开源生态里都有现成实现不建议自己从零写。要注意的是版本对齐稀疏卷积库对 PyTorch 版本和 GPU 计算能力有要求装错版本会在编译阶段直接失败。一个能跑通的配置组合大概是python 3.9 torch 2.1 spconv 2.3.6 onnx 1.15 onnxsim 0.4.36装稀疏卷积库时如果编译报错通常是 CUDA 版本和 PyTorch 编译版本不匹配。先跑一行python -c import torch; print(torch.version.cuda)看清版本再决定装哪个预编译包。自己编译的话记得把CUDA_HOME指对并且编译并行度别开太高容易内存溢出。数据加载这块三维数据的读取是隐藏的性能瓶颈。一张点云加六路图像磁盘 IO 能占到整个训练步的 30%。我的做法是预处理时把数据转成内存映射格式配合多进程预取把num_workers设到 8 以上prefetch_factor设 4。4.2 训练脚本的关键配置配置文件我习惯用 yaml把结构参数和数据参数分开方便做消融。核心片段大概长这样model: backbone_width: 0.5 voxel_size: [0.4, 0.4, 0.5] grid_size: [250, 250, 16] use_sparse: true sparse_start_stage: 2 channels: [24, 32, 64, 96] temporal_frames: 3 depth_supervision: true train: batch_size: 4 lr: 2.0e-4 weight_decay: 0.01 warmup_steps: 500 epochs: 30 ema_decay: 0.999 grad_clip: 10.0 focal_alpha: 0.25 focal_gamma: 2.0 depth_loss_weight_init: 0.5 depth_loss_weight_final: 0.1sparse_start_stage: 2就是从第二级开始转稀疏这个参数我建议单独做消融不同平台的收益拐点不一样。损失函数这部分我把 focal 和语义损失的实现写一下很多人卡在 mask 处理上def occ_loss(pred_cls, pred_sem, gt_occ, gt_sem, cls_weight1.0, sem_weight1.0): # pred_cls: (N, 1) logits, pred_sem: (N, C) logits # gt_occ: (N,) 0/1, gt_sem: (N,) 0..C-1 cls_loss sigmoid_focal_loss(pred_cls.squeeze(-1), gt_occ.float(), alpha0.25, gamma2.0, reductionmean) non_empty gt_occ 0.5 if non_empty.sum() 0: sem_logits pred_sem[non_empty] sem_target gt_sem[non_empty] sem_loss F.cross_entropy(sem_logits, sem_target, weightclass_weights, label_smoothing0.05) else: sem_loss torch.zeros((), devicepred_cls.device) return cls_weight * cls_loss sem_weight * sem_loss这段里有三个细节值得说。第一语义损失只在非空体素上算别在全体素上算否则空体素会把语义头的梯度稀释掉。第二标签平滑给 0.05能缓解相邻类别比如路面和人行道的过拟合。第三if分支是为了防止某些批全是空体素导致除零这个在实际训练里真的会碰上。4.3 导出与推理加速的处理方式导出是整个流程里最容易翻车的一环。稀疏算子在标准的 ONNX 算子集里没有对应实现直接导出会失败或者导出成一大堆不支持的自定义节点。我的做法是准备双路径训练和验证用稀疏路径导出时切到稠密回退路径。稠密路径不是简单的全稠密而是用一个固定的掩码把计算限制在可能非空的区域比如以自车为中心的柱状区域把无意义的天空和远处体积排除掉。这个做法的精度损失通常在 0.5 个点以内但换来了完全的部署兼容性。具体流程是训练完成后用一批校准数据统计各层的实际非空位置分布得到一个保守的空间掩码。修改模型的前向逻辑让三维主干在这个掩码内计算。导出 ONNX用简化工具去掉冗余节点特别关注那些因为动态 shape 产生的If和Loop节点尽量把它们静态化。在推理引擎里做算子融合把卷积、归一化、激活合成一个节点。开 INT8 量化用校准集跑 200 到 500 个样本注意校准集要覆盖雨雾、夜间这些极端场景否则量化后这些场景掉点严重。量化的坑我单独说一下。三维卷积的激活值动态范围比二维大逐张量量化会掉点必须用逐通道量化。另外第一层和最后一层不要量化保留浮点这两层对精度影响最敏感。4.4 精度对齐与性能基线部署完之后必须做精度对齐。我的做法是分三层对第一层对数值随机取 100 个输入比对浮点推理和训练框架输出的最大绝对误差控制在 1e-4 以内算通过。第二层对指标在验证集上跑 mIoU跟训练框架的结果比掉点不超过 1.0 个点可接受。第三层对场景按距离分段统计0-20 米、20-40 米、40-60 米按类别统计找出掉点集中的地方。我遇到过一次整体只掉 0.6 个点但远处行人这一类掉了 8 个点原因就是量化校准集里远处样本太少。性能基线要测三个数纯模型推理耗时、端到端耗时含前后处理、以及峰值内存。端到端里前后处理经常被低估体素化和坐标变换加起来可能跟模型本身一样久。我这边的实测数据是模型 38 ms前后处理 11 ms端到端 49 ms一开始只测前者上车之后发现整体 60 ms 打不住就是漏算了后处理。5. 常见问题与排查技巧实录这一章是我这几年踩坑攒下来的按症状归类你可以当速查表用。5.1 训练不收敛的六种典型症状症状一loss 降得很快但 mIoU 一直是零。这是空体素太多导致的坍缩。检查 focal 的 alpha 是不是设错了方向二分类里正样本是“占用”如果 alpha 给了空类网络会拼命学空。另外确认一下正样本比例低于 3% 的话要配合过采样。症状二loss 震荡剧烈。学习率太高或者批太小。先用 5e-5 跑 200 步看曲线平不平平了再往上加。如果批大小只有 2把组归一化的组数调小。症状三前几轮正常第 8 轮突然 NaN。大概率是梯度爆炸或者除零。开梯度裁剪检查损失函数里有没有对零元素求对数的地方。我遇到过一次是深度损失里预测值取对数时没加 epsilon。症状四训练集好验证集差。过拟合但也可能是数据泄漏。检查一下时序融合的缓存有没有跨样本污染这个 bug 特别隐蔽表现就是验证集指标虚高或者忽高忽低。症状五某些类别召回一直是零。类别权重没设或者设得太保守。先看这个类别在训练集里的总样本数少于 10 万个体素的话靠权重救不回来必须采样。症状六稀疏层梯度为 NaN 但稠密层正常。稀疏卷积的索引里出现了越界坐标。检查体素化时有没有对边界做过 clamp点云坐标超出网格范围就会产生非法索引。5.2 部署后速度不达预期的定位方法速度不达预期是最高频的问题我用一套固定的排查顺序能覆盖八成情况。第一步看是不是被数据搬运拖住了。用性能分析工具看各阶段耗时占比如果预处理阶段占比超过 25%优化重心就该放在体素化和坐标变换上而不是模型本身。优化手段包括把坐标计算搬到 GPU、用定点数代替浮点、以及把重复的坐标变换合并。第二步看算子有没有回退。推理引擎遇到不支持的算子会回退到通用实现速度可能差十倍。导出后一定要看引擎的日志把所有回退算子列出来逐个替换或者融合。第三步看内存访问是否连续。三维张量的内存布局对性能影响很大通道优先和空间优先差很多。我的经验是在推理路径上用通道优先布局卷积前后不需要转置。第四步看批大小和并发的匹配。车端往往只跑单帧但有些引擎在批大小为 1 时效率很低要开特定的优化档位。这个细节不同引擎不一样得实测。第五步看热节流。车载环境温度高连续跑几分钟后频率会掉实测耗时可能比冷启动高 20%。做性能基线一定要跑够 10 分钟再看稳定值。5.3 常见问题速查表现象可能原因排查动作处理方式导出 ONNX 失败稀疏算子无对应实现看报错节点名切稠密回退路径量化后远处掉点严重校准集分布偏差按距离分段统计补远处与极端场景样本帧率波动大动态 shape 导致重编译打印每帧输入形状固定 shape 或预分配缓存显存缓慢增长缓存未释放或碎片监控显存曲线用固定地址环形缓冲边缘区域预测空洞网格边界无上下文看边界体素的感受野扩大网格或补零填充时序融合后精度反降位姿对齐误差累积关掉时序做对照缩短历史帧数或降采样融合小目标召回低深层特征分辨率不足分类别统计召回加浅层特征直连或提高输入分辨率提示表格里“时序融合后精度反降”这条我单独强调一下。很多人默认加时序一定涨点其实位姿标定有微小误差时历史特征会“糊”到错误位置反而干扰当前帧。判断方法是把历史帧数从 3 减到 1如果精度回升问题就在对齐上。另外分享一个排查小技巧把模型某一层的输出可视化出来用简单的俯视图投影到 BEV 平面看。很多时候指标看不出问题但图上一眼就能看出特征图整体偏移了半个体素——这种系统性偏移往往是坐标系的定义不一致导致的比如体素中心用格点索引还是用格点加半格训练和部署两边不一致就会整体错位。6. 我在这套方案上的一些实际体会最后说几个不太好归类的经验都是踩过才明白的。关于精度和速度的取舍我现在的判断是优先保几何精度语义精度可以妥协。原因是下游规划控制真正依赖的是“那里有没有障碍物、离我多远”而不是“那到底是轿车还是 SUV”。所以我在调参时会把二分类的指标看得比语义 mIoU 更重资源紧张时先砍语义头的通道数。这个取舍跟很多论文的优化目标不一致但更贴近实际使用。关于体素化这一步别小看它。我见过一个项目模型优化了三个月提升 15% 的速度结果换个更高效的体素化实现直接又省了 8 ms。体素化的核心是把连续坐标映射到整数格点用查表代替除法和取整能快不少另外把点云按坐标排序后做前缀和也能避免哈希冲突。关于数据标注Occ 的标注成本是检测的好几倍。我们后来的做法是用模型预标注加人工修正先跑一遍高精度的离线大模型生成稠密占用人工只修正错误区域。这个方法把标注效率提了三四倍但要注意预标注模型的系统性偏差会传导到训练数据里得定期用纯人工标注的小集做校验。关于验证策略我强烈建议按场景切片做验证而不是只看一个总体指标。雨天、夜间、隧道、地库这四类场景单独看往往会发现某一类掉得很厉害。我遇到过整体 mIoU 62但地库场景只有 41 的情况原因是训练集里地库数据不到 2%。这种问题不切片根本发现不了。还有一个想说的点别过早优化。我一开始就上稀疏卷积结果调试了两周才发现真正的瓶颈在数据加载。正确的顺序是先建一个能跑通的稠密基线用性能分析工具找出真实瓶颈再决定往哪个方向优化。基线跑通可能只要三天但它给你的信息量比盲目优化一个月还多。这套方案后续还能往几个方向延展一是把占用预测和端到端规划联合训练让感知直接对齐下游目标二是用蒸馏把大模型的知识压到小模型上这在车端算力受限时很实用三是把时序融合从特征级下沉到体素级减少重复计算。这几个方向我都在试有确定的结论再拿出来聊。