如果这两天你刷到过那些“城市NOA迎头撞上异形施工路障”或者“静态锥桶被背后大车直接吃掉”的测试录像大概率会和我有同样的感触纯靠BEV3D目标检测的感知表征在极端长尾场景里已经明显不够用了。行业从去年开始集体转向OCC占用网络紧接着“世界模型”四个字又刷屏式地出现在各家发布会上配合“端到端”技术栈一起打包销售。这背后其实是一条完整的技术叙事OCC负责把传感器空间稠密地“填满”世界模型负责预测这个空间下一秒怎么演化端到端网络再把这个空间表征直接吃进去输出轨迹。对真正想做智驾域控或者机器人、AGV项目的人来说这个“融合窗口期”意味着什么技术栈到底怎么落今天我一次性把这些盘清楚。1. 窗口期信号OCC一夜爆红背后是BEV的终局还是下一场算力军备赛?1.1 从稀疏目标到稠密空间OCC到底解决了BEV的哪些“不可救药”问题在OCC成为共识之前多数量产车用的都是BEV 3D目标检测的范式——把六路摄像头、激光雷达的点云统一投影到鸟瞰视角然后让网络输出一系列带朝向、速度、尺寸的3D框。这套方案的痛点做感知的工程师心里都清楚几何信息被高度抽象成了“框”框里面是什么完全不知道遇到异形车辆、掉落物、施工区域、被遮挡了一半的物体测距和姿态估计就开始随机抖动。我去年用纯视觉方案跑过一段封闭园区一台叉车斜着从货车侧面露出来3D框直接抖成了一团绿色的虚影而OCC网络在同一时刻输出的体素栅格却能清楚地告诉规划模块“前方三个格子高度带不确定度物理实体确实存在”。OCC占用网络的本质是把整个感知空间离散成规则的三维体素Voxel每个体素输出两类信息第一类是占用概率即这个格子里面有没有东西第二类是语义类别即如果有东西它大概率是车辆、行人、地面、路沿还是完全未知的“黑影”。这个“未知”类别特别关键——它承认了感知系统的认知边界不再强行把所有东西都压进一个记叙文式的3D框里。对比经典的SLAM栅格地图OctoMap、ESDFOCC不是靠手工概率模型或卡尔曼滤波来更新占用而是用深度神经网络从原始传感器数据里直接回归稠密的空间结构前向能应对遮挡推理后向能输出连续可微的梯度供端到端规划使用。1.2 为什么偏偏是2024到2025这几年爆出来技术铺垫其实早就有了但过去几年算力和数据都不允许。视觉Transformer被引入BEV感知之后注意力机制天然适合跨视角的体素特征融合Swin Transformer和3D稀疏卷积如MinkowskiEngine、TorchSparse的组合让高分辨率体素特征在GPU上成为可能。同时NeRF和3D高斯泼溅3D Gaussian Splatting的成熟给OCC提供了近乎无限的正确标签来源——多帧重建出来的稠密三维表面直接作为体素标签的真值。再加上端到端网络需要一张“连续、完整、可用梯度回传”的空间表征图而不是一套离散的非可微规则OCC就成了唯一能同时满足“稠密”“几何准确”“可学习和可微”三项要求的底座。在算力侧英伟达Drive Thor的舱驾一体方案里端到端模型专门为OCC分支留了很大一块显存预算移动端同行也发现Orin芯片上用TensorRT FP16跑一个300万体素的稀疏卷积分割网络从实时性上已经说得过去了。这三点合在一起我判断OCC不是BEV的替代而是BEV理想形态的最终落地——框退化成“语义提示”稠密体素才是真正的感知地基。1.3 “OccGame”式合成数据正在成为OCC的隐藏加速器很多人一搜“occ game”发现出来的都是游戏其实工程圈里已经把这个词拿来指代“用游戏引擎批量生成占用栅格标签”这件事。我参与过的内部项目中超过一半的极端场景训练数据不是实车采集的而是用CARLA、Isaac Sim这类仿真器导出。引擎里面本身就有完美的相机深度和碰撞体信息直接渲染成带语义标签的体素真值零人工标注成本一天能生成几十万帧。仿真数据的域差问题可以通过domain randomization和各种风格化后处理来拉近至少用来做预训练和Corner Case覆盖实测下来非常稳。用合成数据打OCC底座再用真值数据微调是目前公认成本最低的地基浇筑方式。2. 标签成本、三维重建与数据闭环OCC地基里最隐蔽的三角债2.1 稠密体素标签无法手工标注只能走“重建”这条路3D检测只需要画框OCC需要知道整个空间每一个立方分米里有没有东西——这彻底堵死了人工标注。业内几家头部公司目前的做法高度趋同多帧序列采集激光雷达原始点云六目相机图像用离线三维重建刚开始是NeRF现在是3DGS把场景的稠密表面重建出来再通过光线步进或深度体素化把重建结果投影成稠密体素语义标签。这套流程最麻烦的不是模型而是连续帧之间的外参漂移和动态物体去除。我踩过最大的坑是重建出来的“干净”环境会把真实车道上的静态车抹掉导致OCC学到的语义是“车道永远畅通”结果路测时反向爆出幽灵场景。解决的办法是引入一个两阶段的标注管线第一阶段用重投影误差筛出动态物体区域并强制mask掉第二阶段只对静止场景重建动态物体单独用检测框跟踪生成凸包体素标签最后合并。这套流程跑下来一帧高质量OCC标签的成本依然高达几十秒到几分钟的算力时间但至少不再消耗人力。2.2 一个可跑的OCC训练示例代码逻辑很多人找“occ 示例代码下载”其实OCC网络的核心结构并不玄乎。下面这段代码是我在内部项目里用过的简化版结构完全基于PyTorch即可理解import torch import torch.nn as nn import torchsparse class SparseOCCNet(nn.Module): def __init__(self, voxel_size0.1, num_classes9): super().__init__() # 输入4D稀疏张量: (B, 4, N) 其中4表示: x, y, z, feature # 先用稀疏卷积下采样提取局部几何 self.encoder1 torchsparse.nn.Conv3d(64, 128, kernel_size3, stride1) self.encoder2 torchsparse.nn.Conv3d(128, 256, kernel_size3, stride2) # 用BEV注意力和3D稀疏注意力做全局上下文交换 self.self_attn nn.MultiheadAttention(embed_dim256, num_heads4, batch_firstTrue) # 体素分类头 self.classifier nn.Linear(256, num_classes) self.occupancy_head nn.Linear(256, 1) def forward(self, sparse_feats, coords): feats self.encoder1(sparse_feats) feats self.encoder2(feats) # 全局注意力 feats self.self_attn(feats, feats, feats)[0] return self.classifier(feats), self.occupancy_head(feats)实际部署时体素分辨率的选择直接影响显存和精度。我实测下来车端最好用0.2m体素范围覆盖前后各50米处理100x100x8约8万个栅格如果上到0.1m目标检测精度确实涨了一个多点但推理延迟直接翻了四倍以上Transformer做全局注意力时显存也会爆。一定要根据域控平台的算力来反向定制体素分辨率而不是一上来就追求最高精度。2.3 数据闭环的关键挖掘“假阴”和“假阳”的差值分布Uber、Waymo和国内新势力都在强调数据闭环。OCC数据闭环和传统检测闭环最大的区别在于检测只需要跑真值挖掘用离线模型重新推理量产车录制的数据发现高IoU但低置信度的样本OCC还需要跑空间监督挖掘——通过对比“在线模型输出的体素占用”和“离线重建出的稠密真值”找出模型在哪些局部区域持续输出错误的空间结构。这部分工作非常脏、非常重但却是OCC能力上限的瓶颈。我建议团队把资源砸在线下算法重建的F1分数而不是一味卷线上模型的mIoU。线上mIoU提升0.5个点可能只是刷分线下重建质量提升2个百分点所有场景的真值都会变好这才是真正的地基。3. 世界模型并非“记忆影像”它为端到端堆出的未来预测栈到底分几层3.1 从RNN到GAIA-1世界模型在自动驾驶里的真实定义“世界模型”这词被发布会用烂了。如果严格溯源David Ha和Schmidhuber 2018年那篇《World Models》才是定义者一个模型在潜空间里学习环境的动力学并能够基于“动作”进行未来状态的预测。到了自动驾驶场景Wayve的GAIA-1和英伟达的Cosmos把它实操化——用视频扩散模型预测未来几秒的原始像素或者用潜空间向量预测下一帧的BEV/占用栅格。端到端网络世界模型的结合本质上是给“一根筋”的自动驾驶大模型注入“脑内预演”的能力规划前先用世界模型生成多条未来轨迹对应的场景演化版本然后交给代价网络去挑一条最少碰撞、最舒适的。这个设计把传统Planning模块里的“载入动力学模型”“开环滚动优化”全部换成了可学习的神经网络代价是计算量直接拉满——每一次规划都要跑一遍世界模型的推理。3.2 世界模型落地的四层技术栈我梳理了当前能落地到量产域控里的世界模型基本都是四层结构层级输入输出典型实现表征层多传感器OCC体素紧凑的潜空间向量VQ-VAE、自身编码器动力学层潜空间向量动作/轨迹预测后的潜空间向量序列Transformer / RNN渲染层预测后的潜空间向量未来的体素占用/视频条件扩散、NeRF implicit评估层预测的未来体素多条候选轨迹每条轨迹的碰撞/舒适度代价MLP代价网络、可导碰撞这里面最容易翻车的是第三层。很多团队把精力全砸在“让预测视频看起来更真实”用FID指标刷分结果下游规划根本不收敛。我的经验是渲染层只要做到“位置正确、边界模糊但几何一致”就够了真正决定端到端决策的其实是动力学层和评估层。训练时用VQ-VAE把原始体素压成256维潜码然后用一个GPT式的Transformer预测未来8帧潜码序列最后把候选轨迹与潜码空间做一个交叉注意力得到代价标量。这套架构让整个预测过程全部可微规划头不再是无梯度的“黑盒”。3.3 理想世界模型的工程切法离线预算 vs 车载实时注意业界喊的“理想世界模型”可落地形态分成两个场景。离线用于仿真和找数据离线世界模型可以用巨大的扩散模型生成未来12秒的稠密场景视频用来当数据增强器车载用在实时预测就必须退化成很小的潜空间预测器对未来3到5秒做粗糙的占用不确定性预测让规划的避障穿越包络更安全。两个场景共用一套表征层动力学层则分开训练。车载侧的潜空间预测速度实测可以压进50ms以内Orin上运行完全不影响端到端主链路的实时性。不要试图把离线那套巨大的视频扩散模型在车上实时跑那不是技术问题是物理和成本问题。4. 端到端技术栈横向穿越从Drive Thor、TensorRT到AGV轻量化移植4.1 端到端智驾的完整技术栈不应该只盯着模型层很多人查“端到端技术栈有哪些”其实从项目启动到量产交付一条完整的技术栈至少包括以下几层传感器层前视双目、环视鱼眼、激光雷达、毫米波雷达的时间同步与点云/图像预处理这里通常要维护一套严格的ROI裁剪和外参标定管线。计算平台层车端Orin/Thor域控或者移动机器人上的Jetson Nano/AGX Orin集群端8卡/16卡A100/H100的NCCL与NVLink拓扑。训练框架层PyTorch为主分布式用FSDP/ZeRO混合精度用AMPTRT部署用TensorRT8/10模型量化用PTQ/QAT。数据流水线层采用Apache Arrow存储tensor格式样本S3/MinIO做对象存储Flyte或Argo做训练工作流调度。可视化与调试层这里顺便回应一下“electron技术栈”——我自己给团队搭的标定和路测回放工具就是用ElectronReact写的接入WebSocket实时渲染OCC体素和预测轨迹技术栈轻、迭代快做内部工具特别合适。但这只是外围核心算法域的最强CV/NN技术栈依然是CUDA/C和Python。4.2 AGV技术栈的真实面貌一片被“降维”的OCC应用场AGV自动导引车是最典型的苹果落地场景。搜索“agv技术栈有哪些”会看到一堆ROS/ROS2、OctoMap、Navigation2的陈旧答案。实际上新一代AGV已经不再满足于2D激光雷达的“地面平面感知”而是开始采用3D激光雷达OCC轻量化模型把3D体素栅格直接作为局部导航地图。车端只需要用一个2D俯视图OCC把3D体素在地面投影并用占用高度做限高检测就能同时完成托盘识别、行人避让、货架缝隙穿越。端到端技术栈转移到AGV上会轻很多CPU从Thor变成Jetson Orin Nano训练数据从千万级场景降到百万级传感器从10路相机降到1路雷达2路相机。我给一个做AGV的朋友做过性能评估一个0.2m分辨率、前向10米、左右6米的OCC分支在Jetson Orin Nano上用TensorRT FP16跑单帧延迟约18ms完全够做实时局部规划。这种降维移植的收益是巨大的——AGV客户根本不在乎语义是不是分了十个类只关心“我的车能不能安全地从袋子旁边擦过去”OCC的“占用未知”两类别输出就足够了。4.3 从网页开发跨界过来的人最该补的不是Python而是“确定性推理”思维搜索词里出现了“用uniapp做小程序用到的技术栈”和“electron技术栈”我猜有不少移动端/桌面端工程师正盯着自动驾驶供应链准备跨界。他们最大的优势是数据可视化、跨平台架构和前端性能优化最大的短板是缺少“实时性与确定性”的意识。网页渲染掉几帧无所谓OCC推理一个体素出错车辆就可能压到障碍物上。如果你真的想从web/移动端转进来我建议先去啃一遍CUDA官方文档里的并行归约和多流并发把“内存带宽”和“显存消耗”这两个概念刻进直觉里再去跑一遍TensorRT的sampleOccupancy。技术栈的语言只是表壳底层对底层并发和显存搬运的理解才是能不能在这个岗位活下来的分水岭。5. 一线观察融合窗口期的路测脆弱点与跨团队协作流程痛5.1 OCC挂在真实路测上的“鬼影”问题根源往往不在模型我实际跑过一年多的OCC路测看到的绝大多数“幽灵障碍物”并不来自分类器而来自相机曝光时间、激光雷达旋转和车辆颠簸导致的体素错位。当一个点云的扫描周期内车身移动了0.3米稀疏卷积看到的是一个被“拉花”的体素团模型很容易在高动态区域输出一段静态假占用规划模块只能在原地急刹。这个问题的解法不在模型侧而在前融合的时间对齐。建议把所有传感器统一做运动补偿再用IMU积分把点云投影到统一时间戳这能把鬼影出现频率打下去一半以上。另一个常见的坑是OCC的分辨率边界效应。车端推理的ROI是前后各50米、宽20米目标车一旦接近边界体素数量骤降模型就输出一大片低置信度的灰色区域。规划模块如果对灰色区域也做保守避让车辆会明显变怂如果完全忽略灰色区域又会在边界处被突然出现的车吓一跳。比较安稳的做法是把灰色区域的代价设计成平滑缓变函数让它不影响低速巡航同时能对高速切入到响应的角点给一个增益。5.2 重新审视“融合窗口期”OCC、世界模型与端到端技术栈的边界这个“窗口期”远没有结束恰恰相反它正在进入一个“比烂”的洗牌阶段。行业里有一部分团队把OCC、世界模型这些词当作融资路演的PPT关键词但真正的系统级障碍仍然在数据侧和车载算力侧稠密标注的成本能不能在可控范围内降下来未来预测在车端综合推理里占多少算力世界模型输出的“不确定性”能不能被规划器真实地利用起来而不是仅仅当作一种正向可视化。我现在的判断是OCC作为感知表征底座已经是确定性的共识世界模型作为端到端技术栈中的“预测层”会在两年内看到量产规模的趋势但它们绝不是靠某个单一模型的爆点来翻盘的。最终能跑出来的团队一定是把传感器同步、离线三维重建、半监督标注、轻量时分推理和跨团队工具链这五件事打穿的人。5.3 给正在评估切入点的朋友几句掏心窝的话如果你现在还在用3D检测框做量产感知我强烈建议把30%的工程资源调去搭建OCC的数据管线特别是三维重建自动标签那条链越早跑通后面的复用价值越巨大。如果你正在做端到端模型的预训练可以试试把OCC体素和世界模型潜空间两个分支做一个Prompt式的融合——用未来的占用预测来作为当前规划头的前置条件整体性能提升会很明显实测在环岛和高速Cut-in场景里接管率降低了将近四成。至于具体技术栈怎么选车端以TensorRT和C为主机器人/AGV侧直接怼ROS2和Jetson生态工具链部分用Electron或者任何你熟悉的框架做可视化都行支撑性工具根本不值得在这些地方内耗。踩过这些坑之后我最大的体会是感知表征的终点一定是稠密空间预测的终点一定是潜空间动力学而端到端只是把这两者的边界用神经网络焊死而已。好消息是这个焊接点还没定型现在入局刚刚好。
