企业官网建设流程全解析

我今年一直在跟自动驾驶量产的几个项目，所以盖世汽车2023中国汽车人工智能大会这个级别的行业会议，我几乎是带着一肚子问题去看的。整场听下来，脑海里最挥之不去的两个词就是Transformer和量产行泊一体。这个话题圈内人已经聊了两年多，但2023年这个时间节点上，它们不再是论文里的概念，而是真刀真枪跑在量产产线上的系统架构。这篇文章就从我自己的视角，把这两个热词以及Nullmax这类公司的落地路径拆开聊聊，给正在做ADAS、智能驾驶或者准备入行的人一份偏实操的参考。特别是对那些想搞清楚“Transformer到底怎么上车”“行泊一体是不是伪需求”的朋友，这篇应该能帮你在工程和产品之间搭一座桥。

1. 从行业会议看风向：Transformer与行泊一体为何同时被反复提及

1.1 会议上的高频信号是什么

盖世汽车的中国汽车人工智能大会，算是国内汽车智能化赛道比较有风向标意义的场合。2023年这一届，几乎所有演讲嘉宾的PPT里都绕不开三个东西：Transformer、量产、行泊一体。如果说前两年大家还在争论“激光雷达路线和纯视觉路线谁才是终局”，2023年的共识已经悄悄转向了“无论用什么传感器，算法架构必须往Transformer上迁移，而且必须能在量产芯片上跑起来”。

这个转变背后的逻辑并不复杂。自动驾驶的感知任务以前基本是CNN的地盘，但CNN在处理复杂交通场景时有两个硬伤：一是感受野有限，一个遮挡的物体会因为局部特征缺失而丢失；二是对时序信息的利用很浅，很难把多帧图像里同一个目标的位置变化稳定地关联起来。Transformer用自注意力机制天然解决了这两个问题，所以从2021年开始，BEVFormer、DETR3D这一系列基于Transformer的工作几乎横扫了自动驾驶感知的榜单。到了2023年，已经没有任何一家想做量产的公司敢说自己还在用纯CNN做主流感知了。

不过会上反复强调“量产”这个词，说明这个行业已经从“比谁论文刷得高”进入“比谁能在有限算力上把算法打磨到可交付”的阶段。Transformer确实强，但它吃显存、吃算力、延迟不好控，往车端SoC上落地有一堆麻烦事。所以你看会上聊得最细的，往往是那些已经量产交付的公司——他们讲怎么剪枝、怎么量化、怎么调度，而不是又跑了多少个SOTA。

1.2 行泊一体到底解决什么问题

行泊一体这个概念，说穿了就是用一套硬件和一套软件系统，同时覆盖行车场景（高速、城市快速路）和泊车场景（地下车库、狭窄车位）。以前车企的做法是分开的：行车用一套域控制器和感知方案，泊车再单独挂一套APA/AVP系统。两套系统各有各的摄像头和ECU，各有各的开发团队，成本翻倍不说，用户体验还是割裂的——车道保持开得好好的，到了停车场突然“降级”成另一套系统的生硬逻辑，乘客能明显感觉出两个系统的存在。

行泊一体的核心价值，第一是成本。用一个域控SoC加一套传感器（通常是5-11个摄像头，按配置选装毫米波或超声波）覆盖两个场景，物料成本和线束成本都降一个量级。第二是体验，同一个感知模型和同一个规控框架可以做到场景无缝切换，从地库坡道驶出直接进入主干道，系统不用换脑子。第三是架构，一只栈维护起来远比两套栈省心，OTA也能统一推送。

但真正做起来并不容易。行车在乎的是远距离感知和纵向控制，泊车在乎的是近距离全周无死角，传感器的布置需求是有冲突的。行车主要靠前视摄像头看远，泊车就必须靠环视鱼眼摄像头看近，而且鱼眼畸变和Transformer的BEV空间怎么融合，是需要花大量精力去调试的。这些东西，光开会听是听不出来的，得在实际项目里反复磨。

2. Transformer上车：核心原理与量产落地的技术逻辑

2.1 为什么CNN在自动驾驶感知里逐渐不够用了

要理解Transformer为什么能成为自动驾驶感知的主流，得先搞清楚CNN的局限。CNN靠卷积核在图像上滑动提取特征，每个卷积核的视野是有限的，虽然可以通过堆叠层数扩大感受野，但本质上还是一个局部操作。自动驾驶场景恰恰是一个“局部信息会骗人”的场景——一个被大车遮挡的行人、一个只露出一半的交通标志、一片没有车道线但有车辙的路面，局部特征往往不够做出准确判断。

Transformer的自注意力机制完全不同。它在计算每个位置的特征时，会和整张图上所有其他位置做加权交互，注意力权重自动告诉模型“该看哪里”。这意味着目标检测不再依赖局部外观是否完整，而是可以把远处、边缘处的微弱线索汇聚起来。这一下就把CNN的天花板打破了。

还有一个更关键的维度是时域。CNN做时序建模，通常是在特征图上做光流或者用循环结构，非常吃力。Transformer可以做跨帧注意力——把上一帧和当前帧的特征序列放到一起，让模型自己学习帧与帧之间目标的对应关系。对于遮挡恢复、静止目标判断、横穿目标预测这类场景，时序注意力的收益是实打实的。在一些项目的实车对比里，单纯把感知骨干从CNN换成带时序的Transformer结构，雨天和夜间场景的漏检率就能下降不少，靠的就是它能把“曾经出现过的目标”记住并在当前帧找回。

2.2 BEV统一空间：Transformer重塑感知坐标系

Transformer在自动驾驶里最漂亮的应用，是把多个摄像头的2D图像特征统一变换到鸟瞰视角（BEV）下的3D空间。传统做法是每一个摄像头各做各的检测，再用后融合把结果投到车体坐标系，这个过程会有大量信息损耗——同一目标在两路摄像头下可能被检测成两个目标，也可能因为视角不同产生严重的位置误差。

基于Transformer的BEV感知，是先让每个摄像头提取2D图像特征，然后用一组可学习的“空间查询”在BEV栅格上做交叉注意力，把2D特征“抬”到3D空间里。一句话概括，就是模型自己学会了在不同摄像头之间做几何校准和特征融合，不需要手工设计外参融合规则。这对量产来说有一个隐含红利：只要模型训练充分，摄像头安装位置的微小偏差可以在模型内部被吸收掉，产线标定压力会小一些。

当然，BEVTransformer也不是没有代价。注意力计算的复杂度是O(N²)级别的，其中N是特征序列长度。图像分辨率越高、BEV栅格越细，计算量涨得就越快。量产芯片上的INT8精度能不能扛住注意力层的数值敏感度，这是个必须提前验证的工程问题。我后面会专门讲量化这部分，因为这是在项目里最容易翻车的地方。

2.3 从感知骨干到端到端：Transformer的扩展空间

2023年的另一个趋势是“端到端”开始从demo走向台前，而Transformer正是端到端架构的骨架。所谓端到端，简单说就是从传感器输入直接输出驾驶轨迹，中间的感知、预测、规划不再拆成独立的模块，而是一个大的神经网络联合优化。这条路特斯拉在FSD Beta上走得比较靠前，国内2023年也有几家公司开始展示类似方案。

但作为一线的量产从业者，我的态度比较务实：端到端是方向，但现阶段更需要的是把Transformer先稳稳地用在感知和预测模块上，把行车、泊车两个场景的数据统一到一个模型框架里。大多数玩家现在做的还是“感知端到端、规控能力尚可”的渐进路线。Nullmax这类公司的价值也正在于此——不是去赌终局，而是用Transformer把当前可量产的能力一次性做透。

3. 量产行泊一体的架构拆解：从芯片选型到软件集成

3.1 域控制器与芯片平台的选型逻辑

聊行泊一体，第一个绕不开的就是硬件平台选型。2023年市面上主流量产级智能驾驶SoC，主要是几家：英伟达Orin系列、高通Snapdragon Ride、地平线征程5系列、TI的TDA4系列。选哪颗芯片，直接决定了算法复杂度上限和整体成本。

我个人在对比这些平台时，会抓三个指标：AI算力（TOPS）、工具链成熟度、功能安全等级。英伟达Orin的量化工具和生态最成熟，Transformer类模型在上面优化相对顺手，但成本偏高。地平线征程系列在国内客户支持上响应快，BPU架构对Transformer有一些定制优化，而且价格上有优势。高通Ride在CPU和GPU均衡性上不错，适合需要高算力但不想绑定CUDA生态的团队。

需要注意的是，算力数字本身不能直接等效于“能跑多少TOPS模型”。同样的Transformer结构，在不同芯片上的实际帧率可以差出三四倍。原因在于注意力算子未必被芯片特定的NPU指令集优化到位，很多时候要靠手写一些C算子或者调整矩阵分块策略。所以选型阶段一定拿真实模型做benchmark，而不是只看跑分表。

3.2 一套感知栈如何同时服务行车和泊车

行泊一体在软件架构上最考验人的，是“行”和“泊”对感知的需求差异。行车要求前向最远看到200米以上，车速100公里/小时时一个感知延迟哪怕100毫秒都意味着多走3米；泊车要求车身四周2米内的障碍物精确到10厘米级别，而且鱼眼摄像头的大畸变会让Transformer的BEV网格映射出现边界误差。

在实际方案里，常见做法是把感知拆成两路：一路是远距前视（窄角摄像头+长距感知模型），一路是近距环视（鱼眼摄像头+环视BEV模型），在Transformer的特征层做一个共享backbone，然后分两个head输出。这样既能共享大部分计算量，又能针对远近不同场景做专门优化。挡位切换的逻辑要做得非常灵敏——车从行驶状态进入低速倒车状态时，系统要在几百毫秒内把感知焦点从“看远”切到“看近”，这个切换在旧方案里是两套系统之间的硬切换，在行泊一体里则是同一套系统内部的软切换，体验会顺滑很多。

3.3 规划控制一体化的难点

行泊一体的规控层同样有挑战。行车时用的是Frenet坐标系下的轨迹规划，泊车时更多用混合A*或者Reeds-Shepp曲线，两种算法在同一个架构里共存，需要做好上下文隔离。我见过一些方案直接在一个规划器里同时处理两种场景，结果就是行车变道和泊车绕障的逻辑互相干扰，调试起来非常痛苦。

更合理的做法是有一个场景仲裁模块，负责根据当前ODD判断进入“行车模式”还是“泊车模式”，然后调度对应的规划器。仲裁的触发条件不能只靠导航地图，必须结合实时感知——比如地库出口坡道这种模糊地带，车速从低速爬升到中速的过程里，仲裁可能有多次抖动。这块需要通过大量实车数据去标定阈值，是行泊一体项目里最耗时的一环。

4. Nullmax的路线选择：把Transformer打磨成可量产产品

4.1 视觉立场的底气从哪里来

Nullmax这个公司，放在国内自动驾驶圈里算是风格比较鲜明的一家。核心团队有特斯拉Autopilot团队的背景，因此从创立开始就坚持视觉为主的路线。这个选择在2016、2017年看起来有点“逆流”——当时行业普遍迷信激光雷达，但Nullmax的判断是：要做量产，成本是第一约束，摄像头是唯一信息密度与成本比例最优的传感器。到今天回头看，这个判断已经被市场验证了，纯视觉或者视觉为主已经成为量产主流选项。

但必须说清楚，视觉为主的路线对算法架构的要求高得多。摄像头没有激光雷达那样精确的深度信息，所有距离估计都得靠几何关系和网络隐式学习。这就对Transformer这类能建模全局上下文的结构提出了刚需——它必须把多视角、多帧的信息榨干，才能补上深度估计的先天不足。

4.2 Transformer在Nullmax体系里的实际落点

从公开分享和一些行业交流来看，Nullmax的感知架构已经全面转向基于Transformer的BEV感知，并且重点解决了两件事：一是模型轻量化，让Transformer在征程、Orin这类量产芯片上达到实时的推理速度；二是把行泊两套感知需求统一到同一个BEV空间里。

轻量化这件事值得展开讲。Transformer模型动辄几十兆参数，直接端到端部署在车端芯片上根本不现实。业内通行的做法是结构剪枝、权重共享、蒸馏。Nullmax这类走量产路线的公司，基本是把一个教学版的超大Transformer通过蒸馏压缩到一个能在INT8精度下稳定推理的小模型。难点在于注意力层的QKV矩阵相比卷积层对量化误差更敏感，所以分通道量化、混合精度量化这些技巧都得用上。我试过在项目里复现类似流程，光是找一组稳定的量化校准集就要花掉一两周时间，这事没有捷径。

4.3 量产交付视角：算法只是起点，工程才是护城河

参加过量产项目的人都知道，算法在理想数据集上跑得再漂亮，距离真正交付还有十万八千里。Nullmax的工程实践里，有几个点我觉得很值得借鉴。第一是芯片适配做到“一套算法、多平台部署”，算子和中间表示尽量抽象化，这样即使客户中途换芯片平台，迁移成本也可控。第二是极端场景的兜底逻辑，Transformer感知在雨雪、逆光、夜间这些场景可能退化，必须有一层基于视觉特征+毫米波雷达输入的规则兜底，保证降级时系统仍有基础能力。第三是数据闭环的节奏控制，量产之后每天都在产生新数据，怎么筛选有效场景回传、怎么标注、怎么触发模型的增量训练，这比模型结构本身更能决定体验迭代的速度。

5. 踩坑实录：Transformer量产项目里的真问题与排查思路

5.1 注意力层量化掉点的怪现象

我自己的项目里，最头疼的问题就是Transformer模型在FP32精度下测试指标很好，转成INT8后漏检率直接翻倍。排查下来，问题出在注意力分数的动态范围上。不同场景下，QK点积的数值范围可能差异极大，全局用一个量化scale就会把低注意力区域的数值压没。解决思路是分块量化，或者对softmax之前的中间值做额外的统计修正。此外，LayerNorm在量化后也会产生偏差，通常需要特定算子融合。这些经验，常规的模型压缩教程里基本不会讲。

5.2 泊车场景的地库铁柱和悬空障碍物

行车场景训练数据多，泊车场景却很容易翻车。地库里的铁柱在鱼眼摄像头下反光严重，容易被识别成可通行空间；悬空吊牌和消防栓也容易导致碰撞。这些问题本质上不是模型结构的问题，而是训练数据分布问题。我的经验是在训练集里刻意增加强反光材质和低矮悬空物的样本，同时利用Transformer跨帧注意力把不同帧的同一障碍物关联起来，降低单帧误检。另外，泊车场景里的“停车位线”识别对BEV分割精度要求极高，线宽一两个像素的偏差在鱼眼畸变下就会被放大成几十厘米的位置误差，这块需要针对性地增加车位线掩码的loss权重。

5.3 系统级冗余和安全兜底的底线

量产交付中最高压的问题是功能安全。行泊一体系统哪怕在泊车模式，车速虽然低，但并不意味着可以放松安全要求。Transformer模型本身是黑盒，无法穷举验证，因此必须在系统层面做冗余——比如环视感知的障碍物结果要和超声波雷达的测距交叉验证，行车模式下的AEB必须独立于主感知栈工作。我在设计这种兜底逻辑时有一个原则：算法负责尽可能做得聪明，规则负责保证永远不蠢。行业里很多过度宣传“纯AI解决一切”的说法，到了法规认证阶段是站不住脚的。

6. 写在最后：参会之后，我对行业节奏的几个观察

从这场大会以及这一年和同行交流的体会来看，2023年确实是Transformer在量产车上的“从1到10”之年。几年前大家还在争论该不该上BEV，现在已经在为量产车型的Transformer模型迭代效率较劲了。行泊一体的价值也不再需要反复论证，各家都在把精力和预算投到这个方向上。我个人的感觉是，技术选型的天花板正在从“算法能不能做到”转向“工程能不能稳定交付”，而这恰恰是大量工程师积累经验、建立壁垒的地方。

最后分享一个实操层面的小技巧：如果你的团队正准备把Transformer模型部署到量产芯片上，一定要在最早就把量化感知训练（QAT）放进流程里，不要等模型训练完再去做后训练量化（PTQ）。PTQ在Transformer上几乎没有不踩坑的，晚发现一天，返工的周期就是一个版本迭代。这套经验我在三个项目里反复验证过，提前做QAT能省掉至少一半优化周期。行泊一体的路还很长，但摸清楚这些工程规律之后，路会好走很多。