“第五代”像一把清楚的尺子，放到自动驾驶里却不太好用。BEV是鸟瞰视角下的空间表达，BEVFormer是具体的感知模型；端到端讨论感知、规划、控制怎么衔接，VLA又属于另一类建模方法。地平线开发者社区的架构梳理指出，市面上绝大多数量产L2+~L3仍采用“感知—规划—控制”的解耦设计。拿这些词排辈，比较的往往不是同一件事。
热度当然存在。界面新闻的行业观察在回顾蔚来、小鹏、理想和比亚迪推进城市NOA时提到，BEV+Transformer与OCC占用网络一度成为行业高频词。热词能说明车企在投入，给不出车端能否稳定运行的答案。
先把BEVFormer说准
BEVFormer的重要变化，是在统一的BEV空间里组织多摄像头特征，并把历史帧信息带入当前计算。北京智源社区收录的代季峰、张祥雨对话提到，该模型融合时空信息、采用稀疏注意力，可用于分割和检测等任务。BEVFormer技术笔记则将其概括为基于Deformable Attention的多视角空间与时序特征融合框架。
稀疏采样常被讲得过于直白。它不会先把天空、路面判成“无用区域”再全部跳过，更接近围绕BEV查询对应的参考位置，有选择地抽取有限特征。它避开了全量密集注意力，但这份纸面收益能否兑现，还要看车端怎么执行这些采样和索引操作。
参数量只是账面第一行
压缩参数可能减轻存储和计算压力，实测延迟还会受到特征图大小、内存访问、算子实现和数据搬运影响。两个参数量接近的模型，放到同一颗芯片上，运行表现也可能差很多。
关键在算子。采样、索引或融合操作如果无法直接落到NPU，编译器可能把它们拆成多段，甚至交给CPU执行。NPU与CPU来回切换，又会带来数据搬运和调度开销。参数表很好看，路上仍可能卡顿。
所以，一份轻量化结果不能只报参数量和理论计算量。目标芯片、工具链、输入配置、算子落点、内存占用和完整链路延迟，都该写清楚。模型能够导出，只算过了入口。
历史BEV先对时间，再谈复用
BEVFormer使用历史BEV特征辅助当前帧，首先是为了利用时序信息。能否借此少算一部分，取决于具体的缓存和复用方式。
车辆一直在运动，上一时刻的BEV特征需要与当前坐标和时间对齐。时间戳漂移、相机触发不同步或数据丢失，未必会立即触发程序错误，却可能让历史特征落到错误位置。
传感器越多，这件事越难绕开。上述北京智源社区对话以硬件变化为例：2014年的特斯拉Hardware 1.0只有一个前向摄像头，蔚来ET7、ET5则包含摄像头、LiDAR、Radar等数十个传感器。纯视觉方案要处理多摄像头之间的时间一致性，加入LiDAR或Radar后，还要面对跨传感器的数据对齐。
融合方案最终要过工具链
BEVFormer原始设计主要面向多摄像头输入。接入LiDAR点云，需要增加新的融合模块，把图像与点云特征放进统一BEV空间。融合方式一变，计算图和算子需求也会跟着变。
成熟的通用算子通常更容易获得芯片优化，自定义采样、交叉注意力和时序融合的支持程度则取决于编译器与算子库。云端GPU能运行，只能证明算法路径可行；到了目标车规芯片，还得查看编译日志：哪些算子留在NPU，哪些被拆解，哪些回退到CPU，中间发生了多少次数据格式转换。
这一关常被低估。很多所谓模型轻量化，只轻了模型文件，没有轻掉整条执行链。
平均延迟好看，还要盯住偶发尖峰
平均值只能说明通常有多快。量产系统更怕偶发超时，因为感知结果需要按节奏交给后续规划和控制模块。
还有一个容易混淆的问题：车流更密，不必然让固定计算图的模型主体成倍增加计算。输入尺寸、采样点和图结构保持不变时，主体推理量通常较为稳定；后处理、数据到达、内存争用、驱动调度和算子回退，仍可能制造延迟波动。把尖峰一律归因于场景复杂度，很容易找错瓶颈。
一份能用的车端测试记录，至少要写明：
- 使用哪颗芯片和哪套工具链，算子分别运行在NPU还是CPU；
- 摄像头及其他传感器如何同步，丢帧和时间戳漂移怎样处理；
- 延迟从哪里开始计时，是否包含预处理、后处理与数据搬运；
- 除平均延迟外，长尾与最大延迟表现如何；
- 持续运行时，内存和功耗是否出现明显波动。
汽车之家对BEV技术的介绍将其概括为从预研走向量产的技术路线。具体到某个BEVFormer变体，仍要回到指定芯片、传感器配置和完整推理链路逐项测试。
代际标签可以留在发布会，部署记录才该进评审会。
