1. 从两个缩写说起BEV和OCC到底在解决什么问题如果你最近一年翻过任何一篇关于自动驾驶感知的论文或者量产方案介绍BEV和OCC这两个词几乎不可能绕开。BEV是Birds Eye View的缩写中文一般叫鸟瞰视角OCC是Occupancy的缩写通常翻译成占用栅格或者占用网络。这两个概念经常被放在一起讨论甚至有人直接问“为什么BEV和OCC是通用的”这个问题的潜台词其实是它们是不是已经成了自动驾驶感知模块的标准答案换哪家来做都绕不开先把结论摆在前面。BEV解决的是“把多个视角的传感器信息统一到一个平面上”的问题OCC解决的是“在这个平面上哪些空间被物体占据了”的问题。前者是坐标系和表征方式的统一后者是几何和语义的统一。它们之所以显得“通用”不是因为有什么强制标准而是因为下游的规划控制模块需要一个统一、稠密、带语义的三维空间描述而目前能同时满足精度、实时性和成本约束的方案BEV加OCC是最顺手的那条路。我拿一个生活化的类比来解释。想象你在一个漆黑的停车场里找车位你手里有四个手电筒分别照向前后左右每个手电筒看到的东西都是局部的、有透视变形的。BEV做的事情相当于把你四个手电筒看到的内容拼成一张从天花板往下看的平面图OCC做的事情相当于在这张平面图上标注出哪些格子被车、柱子、行人占住了哪些格子是空的。规划模块拿到这张带占用的平面图才能决定往哪打方向盘。这个类比能帮你理解为什么两者是配套的。只有BEV没有OCC你得到一张好看的俯视图但不知道哪里能走只有OCC没有BEV你连统一的俯视坐标系都没有占用栅格往哪放都是问题。所以业内把它们放在一起讲是有内在逻辑的。适合读这篇内容的人我大致分三类第一类是刚进入自动驾驶感知方向的工程师想搞清楚BEV和OCC在整个链路里的位置第二类是做模型部署或者数据闭环的同行关心这两个模块落地时的工程约束第三类是对自动驾驶技术路线感兴趣的产品或项目管理者需要判断当前方案的成熟度。不管你是哪一类我都会尽量把原理讲透同时把落地时踩过的坑说清楚。2. BEV和OCC为什么会被认为“通用”2.1 通用性来自下游需求不是来自技术垄断很多人误以为BEV和OCC通用是因为某几家头部公司做得好形成了事实标准。这个理解只对了一半。真正的原因在于自动驾驶的规划控制模块对输入有一个硬性要求它需要一个在自车坐标系下、时间上连续、空间上稠密、带语义标签的三维描述。这个需求不是某家公司发明的而是运动规划算法本身决定的。你想想规划模块要算一条从A到B的轨迹它必须知道每个候选位置在未来几秒内是否安全。如果感知只给你一堆离散的检测框规划就得自己去猜框与框之间的空隙能不能过。检测框的漏检和抖动会直接导致规划犹豫甚至误刹。BEV把多相机、多雷达的信息融合到一个统一网格里OCC进一步把每个网格的占用概率和语义类别给出来规划拿到的就是一张相对完整的“可通行性地图”。这是需求倒逼出来的通用性。2.2 BEV的核心价值把透视视角拍扁成俯视视角BEV最直观的价值是视角统一。前视相机看到的是透视图像近处大远处小同一个物体在不同相机里的尺度完全不一样。如果直接把多个相机的检测结果往自车坐标系里投影会出现严重的对齐误差。BEV通过显式的视角变换把图像特征或者检测结果映射到俯视平面让不同传感器、不同视角的信息在同一个坐标系下对齐。这里有个关键的技术分水岭早期BEV靠逆透视变换IPM做假设地面是平的把图像像素直接映射到地面网格。这个方法在高速场景勉强能用一旦遇到坡道、颠簸或者立体物体就崩了。后来基于Transformer的BEV方案比如BEVFormer这类思路通过可学习的查询和注意力机制让网络自己学会从图像特征里采样并投影到BEV网格不再依赖平地假设。这是BEV真正走向通用的技术转折点。2.3 OCC的核心价值从“检测框”升级到“体素占用”OCC要解决的问题更底层。传统检测输出的是框框是稀疏的、有类别先验的。但现实世界里大量物体是检测器训练集里没有的类别比如掉落的货物、异形路障、施工围挡。你不可能为每一种可能出现的物体都准备标注数据。OCC换了个思路不关心你是什么只关心你有没有占据这个空间。每个体素输出一个占用概率可选地再输出语义类别。这样即使遇到没见过的物体只要它占据了空间规划就能知道那里不能走。这个思路的通用性非常强因为它把“识别”问题降级成了“几何占位”问题。几何占位对类别先验的依赖小得多泛化能力自然更好。这也是为什么很多方案把OCC当作安全兜底模块和检测模块并行运行。2.4 两者结合形成的表征闭环把BEV和OCC放在一起看它们形成了一个完整的表征闭环BEV提供统一的俯视坐标系和特征空间OCC在这个空间里做稠密的占用预测。上游的传感器融合、时序对齐、特征提取都往BEV空间里灌下游的规划控制从OCC栅格里读可通行性。中间这个闭环一旦建立整个感知链路的接口就稳定了不同模块可以独立迭代。我用一个表格把两者的分工和通用性来源列清楚维度BEVOCC核心作用统一视角与坐标系稠密占用与语义预测输入多相机图像、雷达点云BEV特征、点云特征输出俯视特征图或检测结果三维体素占用栅格通用性来源下游需要统一坐标系下游需要稠密可通行性描述主要挑战视角变换精度、时序融合标注成本、算力开销典型落地形态BEV检测、BEV分割占用预测网络、安全兜底这张表不是让你背而是帮你建立判断力。以后看到任何新的感知方案你都可以问它有没有解决坐标系统一有没有给出稠密占用如果两个都没有那它大概率还得再补这两个模块。3. 落地情况从demo到量产的真实距离3.1 乘用车量产BEV已经铺开OCC还在爬坡BEV在乘用车量产上的落地相对成熟。国内几家头部新势力和部分传统车企的高阶智驾方案基本都把BEV作为感知主干。原因很实际BEV检测能直接替代原来分散的前视、侧视、后视检测减少后处理融合的复杂度同时提升跨相机目标的一致性。你在高速领航和城市领航功能里看到的稳定跟车、变道决策背后很多都是BEV在支撑。OCC的落地节奏慢一些主要卡在三个地方。第一是标注成本三维体素级别的标注比二维框标注贵一个数量级而且标注一致性很难保证。第二是算力稠密体素预测对显存和算力的消耗远高于二维检测。第三是评价体系占用预测的评测指标不像检测的mAP那么成熟导致不同方案之间很难直接比较。目前的折中做法是BEV检测作为主感知输出OCC作为安全兜底或者特定场景的补充。比如在低速泊车、窄路通行、施工区域这些检测容易失效的场景OCC的价值更明显。我了解到的一些量产方案里OCC并不是全场景常开而是根据场景和算力预算动态调度。3.2 数据生成与仿真BEV和OCC的另一个战场热搜词里出现了自动驾驶数据集和仿真相关的内容这其实点到了BEV和OCC落地的另一个关键环节数据。BEV和OCC模型对数据的需求和传统检测模型完全不同。传统检测要的是二维框标注BEV要的是多相机联合标定和时序对齐OCC要的是三维占用标注。这三类数据的采集和生成难度是递增的。仿真在这里扮演了重要角色。像CarSim、PreScan、VTD这类仿真工具可以生成带真值的三维场景理论上能直接产出OCC标注。但仿真数据和真实数据之间存在域差异仿真里生成的占用栅格直接拿来训练在真实场景里往往掉点。常见的做法是用仿真做预训练或者做特定场景的补充真实数据做微调和验证。我自己的经验是OCC的数据闭环比BEV更难建。BEV至少还能靠多相机联合标注和自动标注工具来提效OCC的自动标注目前还没有特别成熟的方案。有些团队尝试用激光雷达点云做半自动占用标注但点云的稀疏性和遮挡问题会导致标注不完整。这块的工程投入比很多人预想的要大。3.3 模型部署从服务器到车端的现实约束热搜词里大量出现模型部署相关的内容说明很多同行正卡在从训练到上车的这一步。BEV和OCC的部署有几个特殊约束和普通二维检测模型不一样。第一是输入分辨率高。BEV通常需要多路高分辨率图像输入OCC还需要体素级别的输出这对内存带宽和算力都是考验。第二是时序依赖。BEV方案很多都带时序融合意味着推理时不能只处理单帧要维护历史特征缓存这对部署框架的状态管理提出了要求。第三是算子支持。BEV里的可变形注意力、OCC里的三维卷积和稀疏卷积在车端芯片上的支持程度参差不齐经常需要做算子替换或者重写。我见过不少团队在服务器上跑通了模型一上车就发现延迟翻倍、精度掉点。原因往往不是模型本身而是部署时的量化策略、算子实现和内存管理没有针对车端做优化。这块后面我会单独展开讲。4. 核心技术点拆解BEV和OCC各自的关键环节4.1 BEV视角变换的三种主流路线BEV的视角变换是整个模块的地基路线选错了后面怎么调都别扭。目前主流的有三条路线我按落地成熟度从高到低说。第一条是基于几何的逆透视变换。它假设地面平坦用相机内外参直接把图像像素映射到地面网格。优点是计算量极小几乎不占算力适合对实时性要求极高的场景。缺点是只在地面平坦且物体贴地时有效遇到立体物体和坡道就失效。我早期做泊车项目时用过这条路线车位线检测还行一旦有立柱或者悬空物体就完全没法处理。第二条是基于深度估计的投影。先用一个深度网络估计每个像素的深度再结合相机参数把像素投影到三维空间最后拍扁到BEV平面。这条路线比IPM灵活能处理一定程度的立体物体但深度估计的误差会直接传递到BEV空间远处物体的投影误差可能很大。而且深度网络本身也要消耗算力。第三条是基于Transformer的查询式变换。在BEV平面上初始化一组查询每个查询通过注意力机制从图像特征里采样并聚合信息。这条路线不依赖显式深度网络自己学习如何投影。优点是精度高、对遮挡有一定鲁棒性缺点是算力开销大、训练需要更多数据。目前量产方案里这条路线占比在上升但部署优化是难点。选择哪条路线核心看你的场景和算力预算。高速场景地面相对平坦IPM加后处理可能就够了城市复杂场景立体物体多查询式变换更稳。不要盲目追新先想清楚你的失效场景在哪里。4.2 OCC的体素化粒度与类别设计OCC的体素粒度直接决定了精度和算力的平衡。体素太小比如5厘米精度高但显存爆炸体素太大比如50厘米算力省但小物体直接消失。目前常见的粒度在10厘米到20厘米之间具体选多少要看你的最小关注物体尺寸和芯片算力。我做过一个粗略的估算。假设BEV感知范围是前后各50米、左右各25米、高度方向4米体素粒度取10厘米那么体素总数是1000乘500乘40也就是两千万个体素。每个体素如果输出一个占用概率和一个类别用float16存储光输出张量就接近80MB。这对车端芯片的带宽是很大的压力。所以实际方案里通常会做范围裁剪、稀疏化或者多分辨率设计。类别设计也有讲究。OCC的类别不需要像检测那么细通常只分几大类可通行、不可通行、动态物体、静态物体。有些方案甚至只输出占用概率不输出类别把语义交给BEV检测去做。这样能大幅降低标注和训练难度。我的建议是如果你的BEV检测已经比较成熟OCC可以先做纯几何占用等数据闭环跑通了再逐步加语义。4.3 时序融合BEV和OCC都绕不开的工程难题时序融合是BEV和OCC提升稳定性的关键手段但也是部署时最容易出问题的地方。单帧感知在遮挡、运动模糊、远处稀疏点云的情况下很容易抖动时序融合能把历史帧的信息累积起来让输出更平滑。BEV的时序融合通常有两种做法。一种是在BEV特征层面做对齐和融合把历史BEV特征根据自车运动变换到当前坐标系然后和当前特征拼接或加权。另一种是在查询层面做时序注意力让当前查询去历史特征里检索信息。前者实现简单但依赖自车运动估计的精度后者效果更好但算力开销大。OCC的时序融合更麻烦因为体素空间的数据量本来就大再维护历史体素缓存对内存是很大考验。常见的做法是只对关键区域做时序融合或者用循环网络在特征层面做压缩。我踩过的一个坑是时序融合模块在训练时用了完整的序列部署时为了省内存只缓存了部分帧导致精度明显下降。后来把训练时的序列长度和部署时的缓存策略对齐问题才解决。提示时序融合的训练和部署配置必须严格对齐包括序列长度、坐标系变换方式、缓存更新策略。任何一处不一致都可能导致精度掉点而且这种掉点很难通过调参找回来。5. 实操过程从数据到部署的完整链路5.1 数据准备与标注策略BEV和OCC的数据准备是整个链路里最耗时的环节。我按数据类型分开说。BEV检测的数据相对成熟多相机图像加联合标定标注二维框后通过标定参数投影到BEV平面。这里的关键是标定精度。我见过很多团队在标定上偷懒结果BEV投影出来的框和实际位置差半米下游规划直接没法用。标定要做在线校验不能只靠出厂标定。OCC的数据是难点。三维占用标注目前没有特别高效的方案主流做法有三种。第一种是激光雷达点云累积把多帧点云拼在一起用占据栅格滤波生成占用标签。优点是自动化程度高缺点是点云稀疏区域标注不完整动态物体处理麻烦。第二种是人工标注在三维可视化工具里逐帧标注占用体素。精度高但成本极高只适合小规模验证。第三种是仿真生成用仿真引擎直接输出真值。成本低但域差异大。我的建议是混合使用。用点云累积做基础标注人工修正关键场景仿真数据做补充和预训练。不要指望单一来源能解决所有问题。5.2 模型训练的关键参数与技巧BEV和OCC的训练有一些共通的技巧也有一些各自特有的坑。学习率调度上BEV和OCC模型通常比普通检测模型更敏感。因为视角变换和体素预测的梯度传播路径更长学习率太大会导致训练不稳定。我一般用warmup加余弦退火warmup阶段占总步数的5%到10%初始学习率比检测模型低一个数量级。损失函数设计上OCC的类别不平衡问题比检测严重得多。因为大部分体素是空的占用体素占比可能不到5%。直接用交叉熵会导致模型倾向于全预测为空。常见的做法是用focal loss或者带权重的交叉熵对占用体素给更高的权重。另外可以加一个几何一致性损失约束相邻体素的占用预测不要跳变。数据增强上BEV模型对图像增强比较敏感颜色抖动和裁剪要谨慎使用因为会破坏相机之间的几何一致性。OCC模型可以做体素级的旋转和翻转但要注意保持自车坐标系的一致性。5.3 部署优化量化、算子与内存管理部署是BEV和OCC落地最容易被低估的环节。我按优化顺序说。第一步是量化。BEV和OCC模型通常用FP16或者INT8量化。FP16比较稳精度损失小但算力收益有限。INT8能大幅提升算力利用率但对量化敏感层要特别处理。我的经验是BEV的注意力层和OCC的三维卷积层对量化最敏感这两部分建议保留FP16其余层做INT8。量化校准集要覆盖各种场景不能只用晴天高速数据。第二步是算子优化。BEV里的可变形注意力和OCC里的稀疏卷积在车端芯片上往往没有原生支持。需要根据芯片的指令集做算子重写或者用厂商提供的加速库。这块工作量很大但收益也最明显。我见过一个方案光是重写可变形注意力算子推理延迟就降了40%。第三步是内存管理。BEV和OCC的中间特征张量很大如果部署框架不做内存复用很容易爆显存。常见的做法是分析计算图找出生命周期不重叠的张量让它们共享内存。另外时序融合的历史缓存要设上限不能无限增长。优化阶段主要手段预期收益注意事项量化FP16/INT8混合量化算力提升30%到100%敏感层保留FP16算子重写可变形注意力、稀疏卷积延迟降低20%到40%依赖芯片指令集内存张量复用、缓存上限显存降低30%到50%注意时序一致性调度动态分辨率、场景裁剪平均算力降低20%避免关键场景掉点5.4 实车验证与问题定位模型上车之后真正的挑战才开始。我分享几个实车验证时的经验。第一建立分层验证体系。先在服务器上用回放数据验证再在车机上用离线数据验证最后才上路实测。每一层的通过标准要明确不要跳步。我见过团队直接上路测结果一个标定问题查了两周。第二关注长尾场景。BEV和OCC在常规场景下表现都不错差距体现在长尾场景。比如隧道出入口的光照突变、大雨天的相机遮挡、施工区域的异形障碍物。这些场景要专门建测试集定期回归。第三做好数据回传和闭环。实车发现的问题要能快速回传到数据平台标注后加入训练集。这个闭环的速度决定了你迭代的效率。我建议把回传、标注、训练、验证的周期压缩到两周以内再慢就跟不上场景变化了。6. 常见问题与排查技巧实录6.1 BEV投影错位怎么查BEV投影错位是最常见的问题表现是BEV图上的目标和实际位置对不上。排查顺序我一般这样走。先查标定。把标定参数拿出来用已知位置的标定板做验证。如果标定板在BEV图上的位置和实际位置差超过10厘米标定就有问题。注意标定要分温度做车规级相机在不同温度下内参会漂移。再查时间同步。多相机图像如果时间戳没对齐运动物体在BEV图上会出现拖影或者错位。检查相机触发信号和图像时间戳的偏差一般要求控制在5毫秒以内。最后查坐标系变换。自车运动估计的误差会累积到BEV投影上。检查IMU和轮速计的融合精度特别是在低速和转弯场景下。6.2 OCC占用预测抖动怎么解OCC抖动表现为相邻帧的占用栅格跳变规划模块会因此犹豫。原因通常有三个。一是单帧噪声。OCC模型对输入噪声敏感特别是点云稀疏区域。解决办法是加时序融合用历史帧平滑当前输出。二是体素化粒度太细。粒度过细时物体边缘的体素占用概率在阈值附近波动导致二值化后跳变。可以适当增大粒度或者在二值化前做空间平滑。三是训练数据不足。OCC模型在训练集没覆盖的场景下预测不稳定。需要补充对应场景的数据特别是动态物体和遮挡场景。6.3 部署后精度掉点怎么定位部署后精度掉点是另一个高频问题。我整理了一个排查表现象可能原因排查方法整体精度下降量化误差逐层对比量化前后输出特定类别掉点算子实现差异对比服务器和车端算子输出远处精度差分辨率裁剪检查部署时的输入分辨率时序场景掉点缓存策略不一致对齐训练和部署的序列配置偶发严重错误内存越界开启内存检查工具排查的核心思路是逐层对比。把服务器上的中间层输出保存下来和车端对应层的输出做数值对比找到偏差最大的层再针对性优化。6.4 实操心得几个容易忽略的细节最后分享几个我在实际项目里踩过的坑。第一个是标定文件的版本管理。标定参数会随车辆状态变化如果部署时用了旧版本标定文件BEV投影会系统性偏移。建议把标定文件和模型版本绑定每次更新模型时校验标定。第二个是OCC的评估指标选择。不要只看IoUIoU对空体素不敏感。要关注占用体素的召回率和精确率特别是小物体的召回。我见过IoU很高但小物体全漏的方案规划根本没法用。第三个是仿真数据的域差异。仿真数据训练的OCC模型在真实场景下地面和天空的占用预测往往偏差很大。建议在仿真预训练后用真实数据做充分的微调并且监控真实场景的验证指标。第四个是算力预算的动态分配。BEV和OCC不必全场景全分辨率运行。高速场景可以降分辨率泊车场景可以缩小感知范围。动态调度能省下可观的算力但调度策略要经过充分验证避免在关键场景降级。7. 我对BEV和OCC落地节奏的判断回到最初的问题BEV和OCC为什么通用以及落地情况怎么样。我的判断是BEV的通用性已经基本确立量产方案里很难找到完全不用BEV的高阶智驾。OCC的通用性在技术逻辑上成立但落地节奏取决于数据闭环和算力成本这两个变量。数据闭环这块谁能把OCC的标注成本降下来谁就能更快迭代。目前看点云半自动标注加仿真补充是相对可行的路线但离全自动还有距离。算力成本这块随着车端芯片算力提升和部署优化手段成熟OCC的常开运行会越来越现实。我在实际项目里的体会是不要为了追热点硬上OCC。先想清楚你的失效场景在哪里如果BEV检测加规则后处理能覆盖就不必急着上OCC。OCC的价值在长尾场景和安全兜底如果你的产品定位对这两点要求不高投入产出比可能不划算。反过来如果你做的是城市复杂场景的高阶智驾OCC迟早要补上早做数据和技术储备比晚做好。最后分享一个实用建议BEV和OCC的迭代要绑定在一起做。单独优化BEV检测可能会让OCC的输入分布变化导致占用预测掉点。反过来OCC的反馈也能指导BEV的特征提取往哪些区域加强。把两者当成一个联合优化问题比分开调更有效率。