刚从会场回来我坐在回程的车上手机相册里全是PPT截图和展台照片。这一次的GTC 26确切地说我是抱着一个疑问去的自动驾驶的端到端这两年已经成了行业里最响亮的口号但口号喊到今天主线到底是什么是端到端大模型本身还是数据闭环又或者是那套长期没人敢拆开讲的安全验证体系我听了十几场关于自动驾驶的分享也跟不少同行在现场争论过。结论有点出乎意料——大多数人在台上聊的“端到端”其实根本不是同一个东西。有人聊的是感知到规控的“一个大模型走到底”有人聊的只是用学习的方法替换某个模块还有人聊的是拿生成式仿真批量制造困难场景再去训练模型。这中间的差异比很多人想象中大得多。1. 从会场得出的第一个印象关键词从“算力”变成了“系统”先说个直觉上的变化可能更有参考价值。往年去参加这种技术大会大家围在展台前问的最多的总是“你这块芯片的算力到底多少”“推理延迟多少毫秒”“能支持多大的模型并行”。但今年明显不同了问得最多的问题变成了“你的数据闭环怎么和训练侧打通”“仿真器里的场景覆盖率能做到多少”“端到端模型的中间变量怎么可视化”。这个变化不是偶然的。当端到端架构开始进入量产讨论周期大家关心的问题自然从“模型能不能跑”变成了“系统怎么把它养大、怎么让它可解释、怎么在事故之后能追溯”。我在一个分会场的问答环节里看到前排提问的人拿着一个小本子上面密密麻麻写着关于数据筛选和自动标注的细节问题场面跟往年追问芯片架构的场景形成了挺有意思的对比。1.1 分论坛主题的重心偏移我挑了几场自动驾驶相关的分论坛内容占比非常能说明问题。真正讲模型结构创新的大概只占三分之一剩下三分之二都在讲工程基础设施训练数据怎么回流、仿真场景怎么自动生成、车载推理引擎怎么做灵活裁剪、影子模式怎么用线上数据反哺离线训练。有一场分享让我印象特别深刻那位演讲者把自家系统的迭代流程完整过了一遍车上回传的长尾数据先经过自动挖掘和场景聚类再由人工标注介入一小部分接着进仿真器做回归测试最后才进入训练任务队列。整个过程里模型结构本身反而是最不常变动的那一环。这个视角让我重新审视了自己团队里“重模型轻数据”的习惯。1.2 三个让我停下脚步的反差第一个反差是台上演讲人说到“端到端”时几乎没有一个人敢说自己的系统是纯端到端都会在后面补一句“我们保留了安全层”或者“在规控端会做一层规则校验”。第二个反差是展台工程师聊起“世界模型”时更多是在聊仿真器怎么生成更真实的动态物体而不是在做纯视频预测。第三个反差是几乎所有人在讨论量产时都在反复提及“可解释性”和“回归测试”这跟几年前那种“直接让网络自己学就完事”的氛围明显不同。这三个反差基本勾勒出了这一届大会里自动驾驶技术讨论的真实面貌口号还在但大家已经开始做那些又琐碎又关键的工程化收尾工作。2. 端到端的三种实现路线以及为什么量产最终会选混合如果你去问十个人“端到端自动驾驶是什么”大概能得到五六种答案。我在会场上听到的最有信息量的表达是一位同行说的——“端到端是目标不是架构”。这句话值得展开说说。2.1 纯端到端理论最优雅工程最头疼纯端到端的定义很简单传感器原始数据进来控制指令出去中间的所有步骤都由一个深度网络完成。感知、预测、规划、决策全部融进同一个优化目标梯度可以畅通无阻地从方向盘回传到摄像头。好处是联合优化信息不会在模块间传递时丢失系统上限理论上更高。问题也很现实。第一中间过程不透明一旦出现决策异常你根本不知道是哪一层出了问题第二模型训练对数据覆盖度的要求极高任何一个没见过的场景都可能把网络带偏第三安全验证难度极大第三方监管和内部审计完全没法对这种结构做量化评估。在GTC的会场里真正声称自己在量产车上跑纯端到端的方案几乎没有。大家都在讲概念落地的都在给自己留后路。2.2 中间表征加端到端把不可解释变回可解释这一届最主流的声音其实是“保留中间表征的端到端”。也就是前端感知部分仍然可以端到端学习但网络会输出几类结构化的中间结果例如占用网格、鸟瞰视角下的目标边界框、车道拓扑等再用这些结果去驱动下游的规划决策模块。这个设计的高明之处在于它保留了端到端的“可微性红利”至少感知到规划这一段的梯度链路没有被切断同时又给了算法工程师一个可视化的中间层。出了badcase工程师可以立刻判断是不是感知错、预测错还是规划错不用像面对纯端到端那样直接开始检查整个训练集。在展台交流时有个做决策模块的朋友跟我聊他说他们内部宁愿花大量时间设计这些中间表征也不愿意接受一个完全不可解释的黑盒。原因很简单——靠“概率大概率接近正确”是没办法过安全评审的。2.3 规则安全兜底端到端时代的保险杠第三种路线是前两种方案之外都会配一个规则安全层。这个安全层可以很简单就是一组保底策略比如“与前车距离低于阈值就强制动”“超出车道边界就接管”也可以是一套更系统的约束优化器。它的作用和汽车的安全气囊很像大概率用不上但只要用上一次就知道它值回票价。端到端时代的规则安全底难点不在于规则怎么设计而在于接口怎么定。安全层需要拿到一个统一的、可信的状态估计结果而这个结果本身可能就来自端到端的中间输出。如果中间输出不稳定安全层也会跟着误报。所以我在会场听到的一个普遍提法叫“输出对齐”先约束中间表征的分布再让安全层做兜底判断顺序不能反。3. 世界模型和数据闭环真正的主线还是昂贵的故事“世界模型”是这两年在自动驾驶圈子里出现频率最高的词之一。这个词在不同语境下含义差别很大有人拿它描述下一代仿真器有人拿它描述车端的长时序预测能力还有人拿它当融资PPT的关键词。我的看法比较务实世界模型是工具不是目的。它的价值要看放在哪个环节里用。3.1 世界模型在自动驾驶里的实际用法把世界模型放到自动驾驶场景里最现实的一个用法是做场景生成。传统仿真器靠手工搭建道路模型和物体模型覆盖率有限维护成本高。世界模型则可以从大规模真实驾驶数据中学习场景演化的规律生成逼真的动态交互场景前车突然变道、行人从视障区域穿出、雨天反光导致的感知退化等等。但这里有一个工程细节经常被忽视生成的场景到底有没有对准长尾分布的探针如果世界模型只是把训练集里的分布又重复了一遍那它对提升边缘case帮助不大。真正有价值的做法是通过数据挖掘先找到那些真实采样中数量极少、但规律明显的突发事件再用世界模型把它们扩展成可变参数的大规模测试集这样才能测出系统的鲁棒性。3.2 数据闭环不是一个“系统”而是一种组织能力我在会上听到一个说法很喜欢数据闭环不是一个流水线系统而是一种组织能力。含义是数据从车上回传经过筛选、清洗、标注、训练、仿真评测、再部署这一整个链条能不能转起来靠的不是某个平台工具而是工程团队之间怎么协作。会上某家公司分享了一个案例他们只花了不到三个月就让模型在某个特定长尾场景下的通过率从60%提升到95%。拆开看技术动作并不复杂回传数据里挖出高频误检类型自动清洗后进入标注队列只标注了不足两百帧样本全量微调两轮再用仿真器做五百个变体场景回归。这里最关键的一点是他们把线上运营数据与离线训练工具链打通了模型上线后第二天就能看到实时反馈。3.3 仿真是不是端到端时代的突破口仿真在当前自动驾驶体系里的地位已经从“验证工具”升级成了“主战装备”。尤其是端到端模型进入量产准备期后纯靠真实道路测试远远满足不了迭代速度。有数据说在仿真环境里跑一万公里的成本仅为真实路测的百分之几这个比例差距直接决定了谁的迭代周期短。但仿真远没有想象中完美。域差是最大的坑仿真里渲染出来的传感器数据哪怕是神经渲染器做的也仍然可能存在纹理、光照、反射上的细微差异这些差异会在模型过拟合仿真数据后变成实车上的奇怪表现。我听到最务实的方案是“混合测试”把真实回放片段和生成场景混合在一起按比例控制仿真数据在训练集里的占比。比例怎么定没有标准答案各家都在互相抄作业。4. 那张我和同行争论了一整晚的架构图在会场临结束前我和几位做自动驾驶的朋友在走廊里聊起来最后干脆找了块白板画了一张端到端系统的架构草图。架构图的过程不重要重要的是我们几个人在图上卡住的两个分歧点恰好映射了整个行业端到端路线之争的核心。4.1 场景一张极简的端到端架构画法白板上的图大致是传感器原始信号进入一个统一的神经网络骨干骨干输出动态占用网格和语义地图再接出一个规划解码头规划解码头输出短短几秒内的轨迹点最后轨迹送进一个规则安全校验模块校验通过才下发到底盘控制。这张图本身没有太多新意但当我们试图细化每一个部件的职责边界时分歧就开始了。有人觉得规划解码头应该直接输出控制信号去掉中间轨迹表示有人坚持轨迹这一步不能省因为下游安全层的判定逻辑建立在对目标轨迹的解释上。这个争论持续了大概半小时最后谁也没说服谁。4.2 争议焦点一安全边界放模型里面还是外面第一个核心分歧是安全边界的位置。我的观点是端到端模型的输出必须经过一个独立安全层安全层有自己的规则和验证逻辑不跟模型共享参数。原因很简单你要给不可知的风险设置一个可证明的兜底。另一位同行的观点刚好相反他认为安全规则如果放在模型之外在极端情况下可能和模型的意图冲突比如模型已经判断可以通过某个空隙但规则层因为一个过严的阈值直接判定全刹停车上体验会非常突兀。他主张把安全规则软化成模型训练目标的一部分用大量碰撞仿真数据去“教会”模型避开危险只在最后一层保留极少数硬规则。我们最后达成的共识是短期量产方案不可能离开硬安全层但硬安全层的触发阈值不能拍脑袋定必须和其他模块一起在仿真里做联合调参。否则它要么太敏感天天误触发要么太迟钝真的到了边界时又拦不住。4.3 争议焦点二地图先验该不该进端到端第二个分歧是关于高精地图和端到端网络的关系。近两年行业里“无图化”的声量很大意思是让车端模型只依赖在线感知结果不依赖高精地图来定位和规划。听起来很彻底但真做量产的人都知道纯在线感知会带来更大的不确定性。我个人的倾向是“轻地图、重感知”地图提供拓扑先验感知负责动态修正。也就是说端到端模型仍然要学习理解车道拓扑但只需要一个轻量化的先验结构作为初始化而不是把完整的高精地图特征直接灌进网络。会场上有一位做测试验证的同行提了一个很扎实的问题如果地图和感知出现不一致系统应该信谁这问题的标准答案听上去简单——“不一致时以感知为准”但实际落地时还要考虑地图更新的频率、感知置信度的阈值、切换时的平顺处理。这些问题没有唯一解只能在具体场景里反复测。5. 回到标题里的问题端到端时代的主线到底是什么如果非要用一句话回答标题里那个问题我的答案是主线不是“端到端模型”而是“可闭环的数据系统工程”。模型结构会持续演进今天以Transformer为主明天可能就是世界模型后天再换个新骨架但真正沉淀下来、构成技术护城河的是如何让数据在整个系统里顺畅地流动、高效地转化。5.1 主线是数据系统工程不只是模型我见过一些团队一个月能迭代二十版模型却极少去复盘从数据回传到模型上线的全链路时效。对比之下某头部团队的最大优势其实是他们的数据闭环用时短新算法从提出到上车验证中间每一个环节都是相对自动化的人工介入被压缩到了最关键的地方。这种效率差异最终会反映在单次迭代解决问题的速度上。在端到端架构里模型把大量中间环节压缩进了一个大的搜索空间那么数据规模和数据质量就决定了这个搜索空间里最优解的位置。谁能在更短时间里用更有效的方式把错例转化成训练样本谁就能更快逼近那个全局最优。5.2 谁在按这条主线做事谁只是换个说法这次GTC 26里我发现那些技术分享做得扎实的团队全部都在强调数据流和工具链细节数据格式怎么统一、标注接口怎么标准化、仿真与评测怎么串起来、模型版本怎么兼容。相反越往上讲抽象叙事的越容易把“端到端”“世界模型”当做一个概念符号来讲背后的系统能力反而经不起追问。区别一个方案是“真主线”还是“换说法”有个比较直接的观察指标去看他们每周迭代发布的内容里模型结构改动和数据管道改动的占比。如果模型结构改动频繁而数据管道常年不变大概率还是在写论文逻辑如果两者同步演进才说明真正在做系统工程。5.3 给同行的一句话别被架构名词带走端到端只是工具箱里的一把好用的扳手不是整个汽车。真正的竞技场在于你有没有办法证明系统在任何条件下都是安全的并且能持续用数据刷新这个“证明”的覆盖范围。舞台上的叙事可以很华丽但落地的主线永远是那些枯燥的数据、评测、仿真和回归链路。跑完这次会我回到工位上的第一件事就是让团队重新梳理了当前的数据回流链路看看到底哪一段耗时最长。结果我们发现卡点不在模型训练而在于场景挖掘和自动标注之间的接口。这个问题不解决的话哪怕模型结构再先进也很难变成量产车上的真实能力。