最近和几个做智驾的朋友聊天发现大家对“端到端”这个词的理解差距比想象中大。有人觉得端到端就是把感知、预测、规划全塞进一个网络有人觉得只要上了Transformer就算端到端还有人直接把大模型塞进车机说这是“新一代智驾大脑”。你问十个工程师可能能给你八个版本的定义。这篇东西不打算写成教科书就按我这几年在数据闭环、模型训练和实车测试里踩出来的经验从数据、方法、测试和展望四条线把端到端自动驾驶的真相聊透。内容适合正在做量产智驾的工程师、想转行进自动驾驶算法的新人以及那些天天被“端到端”刷屏但又不知道它到底靠不靠谱的产品经理和投资者。一句话概括端到端赌的是“用足够好的数据替代人类手写的规则”但这条路远没有宣传语那么平坦。1. 端到端自动驾驶到底在赌什么1.1 传统模块化方案的问题出在哪老一套自动驾驶pipeline是感知、预测、规划、控制四个模块各管一段感知模块输出障碍物框和车道线预测模块输出未来轨迹规划模块基于这些结果生成路径控制模块再去跟踪。听起来很合理但实际工程里每级之间都在丢信息。最典型的例子感知模块为了“稳定输出”会把障碍物框做卡尔曼滤波平滑或者只保留置信度高于0.5的目标。这个门槛一设那些置信度只有0.4的真车就被无声无息地过滤掉了。到了规划模块它根本不知道有这个东西存在自然不会避让。模块化架构的错误传播是叠加式的上游漏掉一个目标下游所有模块的计算都建立在错误基础上而且这个错误很难回溯到底是谁造成的。还有一个更隐蔽的问题中间表示是人为定义的。你告诉网络“输出车道线、输出障碍物框”但真实驾驶里大量信息是无法用框和线表达的比如路面湿滑程度、前车司机是不是在犹豫、旁边大车的轮胎是否压线。这些细节被中间表示过滤完决策模块拿到的是“简化过的世界模型”上限从架构上就被锁死了。1.2 端到端想怎么解决这个问题端到端的核心思路是让网络直接从传感器原始数据学习到控制指令或规划轨迹中间不再人为指定“应该看到什么”。感知、预测、规划变成网络内部的隐式表征由数据自己决定什么信息重要、什么信息可以丢。这句话听起来很爽但它实际上是在赌一件事当数据量足够大、模型容量足够大、算力足够强的时候数据驱动的隐式推理能力能超过人类手工设计规则的表达能力。用大白话说人类写规则只能覆盖“见过的问题”而端到端系统试图通过大量数据学会“处理没见过的问题”。我经常跟人打比方传统方案像一本详尽的操作手册手册里没写的场景系统就不会处理端到端方案像一个开了十年车的老司机他没法解释自己是怎么判断前车要变道的但就是能提前松油门。1.3 “端到端”这个词已经被叫滥了现在市面上的端到端主要有三个层次差别非常大。第一层是感知端到端。输入多路相机输出BEV鸟瞰视角特征或占据网格代表工作是BEVFormer这类架构。这一层目前量产最成熟因为它的输出还是结构化的方便后续规则模块去用。第二层是决策规划端到端。输出不只是感知结果而是把预测、决策、规划一起做了直接给出一段未来轨迹或连续控制指令。UniAD这类全栈方案属于这个范畴。第三层是真正意义上的全栈端到端。输入原始图像和激光雷达点云输出方向盘转角、油门刹车开度中间没有任何人工定义的任务监督。这套路在研究圈火但真正量产落地的极少。我建议所有看技术方案的人先问一句“你们说的端到端是哪一段”再谈效果。不然很容易被宣传话术带偏。很多号称端到端的系统其实只是把感知模块换成了更好用的BEV网络决策还是规则树在管这本身没错但别混淆概念。类型输入与输出代表思路量产成熟度感知端到端多传感器 - BEV/占用网络BEVFormer高决策规划端到端中间表征 - 轨迹/动作UniAD中全栈端到端原始信号 - 转向/加速VLA、Diffusion Policy低真正的全栈端到端反向传播必须从规划的loss一路穿过感知的所有层。这个要求看起来简单实际上梯度要在多层query、注意力和时序融合结构里稳定传回去既不能消失也不能爆炸工程难度比单纯把三个模型拼起来高一个量级。2. 数据端到端系统的隐形天花板2.1 不是“数据够多”就够了端到端系统的上限不是由模型结构决定而是由数据决定的。这句话现在几乎成了行业共识但很多人对“够多”的理解太天真。早期我们用公开数据集训练像nuScenes、Waymo Open Dataset拿过来就试结果发现模型在验证集上表现不错一到自采数据上就崩。原因很简单公开数据的传感器配置、天气分布、路况类型和你的目标场景不可能完全一致模型会把“风格特征”当成“语义特征”学进去。比如某个数据集的车辆主要是轿车和SUV端到端模型可能就隐式地把“小目标”和“低风险”绑定在一起遇到三轮车、洒水车就不知道怎么处理。端到端训练需要的数据至少满足四个条件时序完整、传感器同步、自车状态准确、场景覆盖充分。缺一个模型都会学到错误的东西。最实际的例子是时间戳没对齐相机图像和CAN总线车速相差100毫秒模型就可能学会“看到障碍物后马上加速”因为100毫秒前障碍物还在很远的位置当前时刻的速度标签已经变小了。这种特征你在loss曲线上根本看不出来只有实车测试才会暴露。2.2 采集、清洗和标注的真正难点采集环节最大的难点不是把车开出去拍视频而是怎么确定“什么数据值得采”。端到端模型长尾问题严重常规道路开一万公里可能80%的数据都是直线跟车和匀速巡航这些数据对模型能力提升非常有限。你需要的是cut-in场景、异型车、复杂路口、临时施工、被遮挡的行人这些边角料。我见过很多团队的做法是“先全部录回来再筛选”。这样可以但存储和标注成本很高。比较靠谱的方法是影子模式车端跑着一套基线规则系统同时记录传感器的原始数据。当影子系统的驾驶决策和人类驾驶员行为偏差超过阈值时自动触发数据回流把那一段clip存下来。这个触发条件本身就是一个工程问题阈值设太松回传的数据全是普通场景设太紧长尾场景一辈子也触发不了。数据清洗也有一堆坑。GPS信号丢失、相机遮挡、传感器标定漂移都会产生坏数据。我的处理习惯是先做时间戳对齐再用物理约束做合理性检查。比如加速度超过6m/s²且没有对应紧急制动事件、方向盘转角速率超过车辆物理极限、车速和GPS位置矛盾这些clip直接丢弃。类似的场景在工业设备数据采集里也一样用Modbus或OPC UA读PLC数据时同样需要做数据质量判断否则一个通信抖动就能让你训练出一个“假故障”模型。数据增强方面图像类增强亮度、对比度、裁剪、翻转大家都熟但轨迹类数据不能随便玩。左右翻转在简单场景可行在中国靠右行驶、有明确车道语义的场景里翻转会破坏交通规则约束模型可能学会“逆行超车”。所以我现在的原则是感知部分可以做较强增强轨迹部分只能用小幅噪声扰动不能做结构性改变。import numpy as np import pandas as pd # 示例做端到端训练前的基础数据体检 df pd.read_csv(clips.csv) speed df[speed].to_numpy() ts df[timestamp].to_numpy() acc np.diff(speed) / np.diff(ts) bad_acc np.where(np.abs(acc) 6.0)[0] bad_speed np.where(speed -0.5)[0] print(f异常加速度帧数: {len(bad_acc)}) print(f负车速帧数: {len(bad_speed)})2.3 开源数据集和仿真数据到底能用多少现在可用的自动驾驶开源数据集不少nuScenes有1000个场景、Waymo Open有数千段带标注的序列、Argoverse 2涵盖地图和多传感器数据。它们的共同问题是标注成本高、场景分布偏“安全城市道路”极端驾驶场景少。做研究足够做量产数据底座远远不够。仿真数据是另一个话题。很多人问用游戏引擎能不能生成端到端训练数据比如把欧卡2Euro Truck Simulator 2里的自动驾驶Mod当真。我的看法是这类游戏可以帮你熟悉数据pipeline但别指望它训练出能上路的模型。游戏物理和渲染是为“体验真实”服务不是为“传感器物理特性”服务。相机畸变、曝光延迟、雷达反射模型、路面摩擦系数都和真实世界差别太大。专业一点的仿真平台像CARLA能提供比较接近真实的传感器模型但依然存在sim-to-real的鸿沟。我的经验是仿真数据最适合训练“通用驾驶常识”比如交通规则、车辆跟随、车道保持最不适合训练长尾细节和交互博弈。你要么把仿真当成测试环境要么把仿真数据占比控制在20%以内用来补充正常场景的覆盖度长尾场景还是要靠真实数据闭环去采集。3. 方法从UniAD到VLA主流技术路线盘点3.1 UniAD这把火是怎么烧起来的UniAD是第一个把感知、预测、规划统一进一个网络、并拿到顶级会议奖项的工作它的价值更多在于证明“全栈联合训练”是可行的而不是直接告诉你量产怎么做。它的架构里设计了几组querytrack query负责跟踪物体map query负责建模地图motion query负责预测轨迹planning query负责输出自车规划。这些query在Transformer decoder里层层交互梯度可以贯穿整个网络。这样做的好处是中间结果仍然有一定的可解释性你可以单独看跟踪结果和预测结果出问题时比较容易定位。但UniAD路线也有明显的工程痛点。它需要同时优化好几个任务跟踪、建图、轨迹预测、规划各有一个lossloss权重稍微设置不好就会出现某个任务“躺平”的现象。我做过实验当规划loss权重太大时感知任务退化得非常快因为模型发现“只学规划、不学感知”一样可以把训练集的loss降下来结果就是验证集上感知指标掉得惨不忍睹但规划分数很好看。这种畸形模型一旦上实车遇到没见过的场景完全依赖隐式记忆表现非常吓人。所以实际训练UniAD类模型时我强烈建议保留中间任务指标作为“健康检查”不能只看最终规划loss。跟踪准确率掉了、地图mAP掉了就要及时调权重否则模型的泛化能力是虚的。3.2 大模型进入驾驶VLA的诱惑与风险2024年之后端到端自动驾驶最热的方向变成了视觉语言动作模型也就是VLA。核心思路是把视觉tokenizer、大语言模型和动作解码器串在一起让模型既懂视觉语义又会输出驾驶动作。VLA最吸引人的地方是它可以借力大语言模型的常识推理能力。比如遇到“前方有学校的减速带”传统端到端模型需要见过类似的视觉样本才能学会减速而VLA模型可以结合语言知识理解“学校路段要慢行”这个抽象规则在一定程度上缓解长尾问题。2024年出现的VLA相关开源工作也验证了语言指令可以作为辅助信号让模型在同一段场景下根据“注意安全”或“尽快通过”输出不同风格的轨迹。但VLA的问题同样突出。第一是计算量7B以上的模型跑在车规芯片上延迟很难压进100毫秒。第二是数据需求更夸张视觉语言预训练需要海量通用图文数据驾驶数据只占其中一小部分怎么防止模型把“看图说话”的能力错误映射到驾驶决策上是没人解决的难题。第三是幻觉大模型会一本正经地输出不合理的动作比如前方车辆已经刹停模型可能基于语言知识认为“前方场景常见可以绕行”而这个绕行动作在物理上是碰撞。我的判断是VLA这条路线更适合做“副驾驶”或者“教练模型”在量产车上直接作为主控决策至少目前还有很远的距离。它最有希望的应用是车机语音交互和场景解释而不是方向盘和油门。3.3 训练稳定性的几个关键工程细节端到端模型训练比普通视觉模型更脆弱我踩过的坑可以列出一长串。梯度裁剪一定要上。端到端模型的loss经常在起步和急刹处突然变成NaN因为动作空间中存在很大的不连续梯度。开环训练时模型看到一个紧急场景可能从“加速”跳变到“急刹”loss瞬间爆炸。用torch里现成的clip_grad_norm_就能解决大部分情况。optimizer torch.optim.AdamW(model.parameters(), lr1e-4) # 端到端模型在起步和急刹处极易出现NaN梯度裁剪是标配 torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0)EMA比直接保存最优checkpoint更靠谱。端到端模型训练波动很大验证集上最好的checkpoint往往是碰巧在某个噪声点上用指数滑动平均EMA得到的模型权重要稳定得多。我现在的习惯是训练时维护一份EMA权重用它做测试和实车验证而不是拿某一步的原始checkpoint去测。Teacher forcing会带来分布偏移。训练时我们给模型喂真实的历史轨迹作为输入让它预测下一步推理时模型用的是自己预测的历史轨迹误差会逐步累积。这是端到端规划模型的核心痛点。缓解手段包括在训练中随机混入模型自己的预测结果scheduled sampling以及使用DAgger这类交互式学习范式让模型自己跑一小段轨迹一旦偏离专家轨迹就切换成专家输出并让模型学习这个纠偏过程。数据混采策略不能全是难样本。我曾经试过为了提高长尾能力把所有难样本挑选出来训练结果模型在所有常规场景全部退化连直线跟车都开始画龙。后来把正常样本和困难场景样本按8:2比例混合效果立刻正常。端到端模型需要一个平稳的“驾驶基线”基线不稳长尾学得再多也没有意义。4. 测试与落地怎么证明它靠谱4.1 开环指标好看不代表能上车端到端模型最常见的评测方式是开环在测试集上运行模型把预测轨迹和人类驾驶员真实轨迹做比较算位移误差、加速度误差。这类指标可以快速筛选模型但不能作为上车依据。原因很简单开环测试不反馈。模型预测偏离了真实轨迹没有任何后果它不用承担“撞车”或“压线”的责任。实践中经常出现这种情况两个模型的位移误差只差0.05米但一个在实车测试中完美通过路口另一个在同一个路口差点撞到护栏。因为位移误差是平均指标它无法体现极端情况下的行为质量。真正的驾驶安全性往往取决于少数几个关键时刻的决策而不是平均轨迹贴合度。更讽刺的是开环指标可以被“刷”。模型如果倾向于保守跟着历史轨迹平滑输出不搞激进操作开环误差通常很低但实车上它可能该走不走、该超不超被后车疯狂按喇叭。这种“开环学霸、实车学渣”的模型我在评测中见过不止一次。4.2 仿真测试能覆盖多少场景闭环仿真测试是必选项。把模型接进仿真环境让它自由决策才能暴露出轨迹预测误差累积、决策抖动、卡死状态等问题。CARLA是学术界用得最多的仿真器工业界也有不少自研的仿真场景库。但仿真环境有两个天然缺陷。第一是传感器仿真不够真实尤其激光雷达和相机的低光表现真实世界里的镜头眩光、传感器噪声、运动模糊很难建模。第二是动力学的简化车辆横纵向动力学的非线性、轮胎打滑、路面起伏仿真器往往倾向于“理想化”。模型在仿真里学到的激进驾驶策略可能在真实车辆上直接失控。这里必须提一下欧卡2这类游戏。很多人拿它做自动驾驶演示画面确实好看但它的物理引擎和服务于驾驶模拟体验不是为传感器算法验证设计的。你可以用它理解自动驾驶系统的交互逻辑拿来做训练数据或正式测试并不可取。专业自动驾驶测试要么用CARLA这类学术仿真器要么用商用的高保真仿真平台配合真实道路数据回放。4.3 实车闭环与安全兜底实车测试才是端到端模型真正的试金石。但端到端模型上车不能直接裸奔。我的建议是至少保留三层安全兜底。第一层是输入检查相机标定异常、IMU漂移、时间戳断裂时系统要能主动降级到保守模式。第二层是实时规则监控端到端模型输出的轨迹如果跨越实线、靠近路沿、速度超过限速规则系统要能介入修正。第三层是最小风险策略当模型连续输出异常轨迹、置信度持续偏低系统应该自动靠边停车或请求驾驶员接管。这个设计思路和“端到端是主角规则是约束”并不矛盾。真正量产上车的那部分端到端能力通常被限制在ODD设计运行域之内超出边界必须交给兜底系统。很多事故问题不在端到端模型本身而在ODD边界定义得太模糊系统在它不擅长的地方强行运行。评价实车端到端系统除了接管率、碰撞预警次数之外我还会看一个容易被忽略的指标无效犹豫率。端到端模型经常出现频繁微调方向、反复踩油门又松开的行为这种“犹豫”在安全指标上不算事故但对乘客来说非常不舒服也会加速执行器磨损。实车测试阶段建议引入主观乘坐评价至少要有连续驾驶一小时不让人觉得累这条线。测试层级核心指标常见误区开环数据集评测位移误差、碰撞标签分数高不等于决策质量好闭环仿真任务完成率、事故率仿真物理模型过度理想化封闭场地紧急避障、泊车成功率场景太少模型易过拟合公开道路实车接管率、乘坐舒适度测试里程不足样本偏差大5. 展望我看到的坑和可能的方向5.1 未来两三年数据闭环比模型结构更值钱现在很多团队热衷于换新模型架构从BEVFormer换到VLA从单阶段换到多阶段。但我的观察是端到端系统在量产上的瓶颈不在模型而在数据运营能力。谁能低成本地采到更多长尾场景数据谁能把数据自动标注得又快又准谁就能让模型更快迭代。数据闭环本质是一个运营系统需要车端触发、云端筛选、自动标注、场景重生、回归测试全链路打通。这里面每个环节都有工程挑战但没有任何一个环节需要“灵光一现”。它更像是在建一座数据工厂而不是在写一篇论文。至少在未来两三年数据工厂的运转效率决定了端到端智驾的天花板。5.2 世界模型和合成数据正在改变长尾问题的解法世界模型是一个我很看好的方向。它让模型观察一段真实视频学习环境动态规律然后生成“如果当时车辆做出另一个决策世界会怎么演化”的想象场景。这相当于给端到端系统装了一台“内部模拟器”可以在不增加真实采集成本的情况下生成大量安全关键场景。但世界模型本身也有可靠性问题。生成出来的视频可能会违反物理规律比如车辆突然消失、行人穿过车体。把这种假数据喂给端到端模型模型可能会学到不存在的驾驶行为。所以现在更现实的做法是用世界模型做场景扩展把真实场景里的车辆位置、速度做小幅扰动生成新的变体而不是从零生成一个完全虚构的场景。5.3 量产形态大概率是双轨制最后说我对“端到端安全”量产形态的判断。完全黑盒的端到端在短期内不可能成为合法且安全的主控因为事故归责和可解释性要求摆在那里。更多的是“端到端负责主决策规则系统负责约束和兜底”的双轨制。端到端模型就像一个经验丰富的司机规则系统像车上的安全员安全员不一定天天干预但一旦发现越界就立刻接管。这个双轨制对端到端模型的影响是模型输出的轨迹必须是一个“规则系统能理解、能修正”的结构化结果而不是只输出方向盘转角。如果规则系统只能看着转角干瞪眼那它根本无法判断模型在想什么兜底就成了一句空话。所以我在做架构选型时一直倾向于让端到端先输出未来3秒的离散轨迹点再让下游规则层做安全校验而不是直接输出连续控制命令。根据我个人实际操作的经验做端到端项目时最忌讳“一步到位”。先在一类场景上跑通闭环比如城市无保护左转拿到固定数据集、固定评测指标、固定安全兜底策略模型换了一版又一版你都知道好在哪差在哪。等这条pipeline稳定了再逐步扩展场景。端到端这个东西听着很酷真做起来就是一场拼数据、拼工程、拼耐心的持久战。