端到端不是终点：自动驾驶的隐形主线在数据与验证

1. 从一个算法工程师的视角看GTC‘26端到端不是终点主线还在后面先说结论这次GTC‘26我最大的感受不是“端到端又往前迈了一步”而是“端到端终于开始回答‘接下来怎么走’这个问题了”。作为一名常年泡在自动驾驶感知和规划算法里的工程师我过去几年对GTC的态度是又爱又怕。爱的是每次都有硬核新东西怕的是会场上满屏“端到端”三个字但细听下来各家讲的基本还是同一个故事用一个大模型把感知、预测、规划全部塞进去输入传感器数据输出轨迹。故事好听落地难。今年不一样。端到端依然是绝对主角但讨论的焦点已经从“要不要端到端”变成了“端到端之后系统的主线到底是什么”。这个转变比任何单点技术突破都更值得关注。这篇文章不打算复述发布会上的每一页PPT我想以一个长期做模型训练、上车调试、也踩过无数坑的算法工程师身份聊聊我对GTC‘26上几个关键信号的理解端到端架构的下一步难点在哪、数据闭环为什么突然变得比模型结构更值钱、车端计算平台会怎么变、以及“世界模型”和“仿真”到底是不是同一回事。看完你大概就能明白为什么我说端到端时代的“主线”其实已经从模型本身转移到了模型之外的东西。2. 端到端架构的“下半场”从模型结构转向系统能力2.1 端到端的上半场把问题“压扁”过去两三年端到端方案的核心思路是“化繁为简”。传统自动驾驶系统是串行流水线感知出目标预测出轨迹规划出控制每一环独立训练、独立调试误差层层传递任何一个环节出问题后面全崩。端到端的做法是把这条流水线“压扁”用一个大的神经网络直接从原始传感器输入映射到驾驶决策中间不再显式维护目标列表、车道线、轨迹预测结果。好处很明显没有中间表示就没有信息损耗数据驱动代替规则驱动面对长尾场景时理论上更灵活整个系统的训练目标可以统一成“最终驾驶行为”而不是一堆代理目标。我在GTC‘26上听到的一个比喻挺贴切传统方法是先分别造好发动机、变速箱、底盘再凑成一辆车端到端是直接训练一个“会开车的人”。但问题也恰恰出在这——人会开车是因为人有长期记忆、有对场景的理解、有在错误中自我纠正的能力而现在的端到端模型大多只有“看一步走一步”的反应能力。2.2 下半场的三个核心矛盾这次会上某厂商的分享给了我很大启发他们把端到端下半场的挑战归纳成三个矛盾我深以为然第一个矛盾是“数据多”与“数据好”的矛盾。端到端模型对数据量的胃口是无底洞但并不是所有数据都有价值。高速上开着巡航跑一万公里有效信息可能还没城市路口堵车十分钟多。如何从海量数据里筛出“难例”、“边界案例”、“有教学意义的数据”比盲目堆数据更重要。第二个矛盾是“模型大”与“可解释性”的矛盾。端到端模型是个黑盒它为什么在这个路口选择减速而不是绕行工程师很难回答。可自动驾驶是安全攸关系统需要向监管、保险、公众解释行为的合理性。这个矛盾不解决端到端很难真正大规模落地。第三个矛盾是“训练强”与“验证难”的矛盾。模型在训练集上表现很好但怎么证明它在没见过的场景里也安全传统模块化系统每个模块都能单独做测试端到端系统却只能整体验证而整体验证需要近乎无穷的场景覆盖。这三个矛盾指向同一个答案端到端系统的能力边界已经不在网络结构里而在数据的组织方式、验证的方法论、以及车端平台的支撑能力上。2.3 主线判断数据闭环与验证体系所以我的判断是端到端时代的主线绝不是继续把模型做得更大、更黑而是围绕两个“外围系统”展开一是数据闭环系统。怎么从路上跑的车上把有价值的数据采集回来怎么自动挖掘难例怎么高效标注怎么用标注后的数据反哺训练再让新模型回到车上去发现问题——这个循环的效率和自动化程度决定了模型迭代速度的上限。二是离线验证与仿真系统。在模型上车之前怎么在虚拟环境里跑数万公里、覆盖数万个长尾场景用可量化的指标证明新模型比旧模型更好这是比模型结构本身更关键的基础设施。GTC‘26上几乎所有的重磅发布包括新的计算平台、新的仿真工具链、新的数据挖掘方案其实都是在为这两条主线服务。想通了这一点再看展台上的各种展示思路就清晰多了。3. 数据闭环真正的“护城河”不再是模型而是数据挖掘与自动标注3.1 数据流水线的重构从“采回来再说”到“按需采集”传统的数据采集策略基本上就是“车装传感器到处跑把数据存下来回库房再挑”。这种做法最大的问题是算力、存储、标注人力全花在了低价值数据上。我在GTC‘26上看到一个很有意思的方案在车端直接做初筛。车上的计算平台实时跑一个轻量版模型判断当前帧是否值得回传——比如检测到异型车辆、施工区域、突然切入的电动车、罕见的路口拓扑马上打标签并回传如果就是普通的跟车巡航数据直接丢弃。这样一来回传的数据量可能减少80%但有效难例的密度却翻了好几倍。这个思路我特别认同。数据闭环的第一环你说到底是“采”但真正值钱的是“怎么决定采什么”。端到端模型最缺的永远不是重复数据而是能修正行为边界的“疑难杂症”。与其盲目扩充车队规模和存储阵列不如在车端多放一个“数据价值判断器”。3.2 自动标注人机协作的边界在哪里标注一直是数据闭环里最贵、最慢的环节。传统3D框标注一个熟练标注员一天标几百帧就到顶了成本高、一致性还差。GTC‘26上提到的新一代自动标注框架让我觉得这个环节终于要迎来质变了。现在的自动标注不再只是“模型出一个框人工确认一下”那么简单而是用上了时序自动跟踪 多传感器融合 大模型辅助生成的组合拳。具体展开说先用预训练模型对连续视频帧做初步检测和跟踪生成时序一致的3D轨迹候选框再用激光雷达点云和摄像头图像进行交叉验证把纯视觉不好判定的深度、遮挡问题修掉最后对于模型置信度比较低的复杂场景才由人工介入做细粒度调整。我算过一笔账如果自动标注可以把人工介入率压到20%以下那么标注成本几乎能下降一个数量级数据闭环的迭代周期也能从“周级”变成“天级”。但这里面有一个关键约束自动标注的框架必须和训练框架深度打通。如果标注模型和生产模型是两套体系标注结果的一致性就成了大问题模型学到的反而是标注意见分歧的噪声。提示自动标注不是“让机器代替人”而是“让机器把人从重复劳动中解放出来集中精力处理机器搞不定的长尾”。这里面最考验工程能力的是自动标注置信度阈值的设定——阈值太高人工介入太少错误标注漏进训练集阈值太低人工负担没降下来。这个东西没有通用最优值需要根据模型在验证集上的错误模式反复调。3.3 难例挖掘从被动收集到主动搜索难例挖掘Hard Example Mining在传统目标检测里就是老话题但在端到端时代它的内涵变了。以前难例挖掘针对的是“感知没认出这个目标”现在难例挖掘针对的是“整体驾驶行为不合理”。怎么定义“行为不合理”GTC‘26上提到利用大模型对驾驶片段进行“行为评分”尤其关注换道太晚、刹车过急、绕行路径不自然这类问题。大模型先对片段给出粗粒度评价再用规则和仿真器做细粒度场景复现定量分析问题触发的原因。这个方案给我最大的启发是难例挖掘的目标不是找“模型会犯错的场景”而是找“模型犯的错会导致乘客不安、安全风险上升、或交通效率下降的场景”。这两者之间的差异决定了数据闭环的导向——前者是让模型“见多识广”后者是让模型“举止得体”。对于初创团队我建议先别急着自建完整的自动标注系统。可以先用开源模型半自动标注工具搭一个最低可用闭环把难例挖掘规则用脚本跑起来重点验证“数据筛选-标注-训练-评估”的通路是否顺畅。跑通之后再逐步迭代自动化程度。一上来就追求全自动大概率会被复杂工程链路拖垮。4. 车端计算平台端到端模型对算力和带宽的新需求4.1 端到端模型的“算力饥渴”到底有多严重端到端模型动辄几十亿甚至上百亿参数输进去的是多路高分辨率视频流推理过程不仅要跑神经网络还要做时序融合、注意力计算计算量比传统模块化系统高出一个数量级不止。我在GTC‘26上看到某计算平台的参数单芯片算力已经突破千TOPS级别但让我更惊讶的不是算力数字本身而是平台的设计思路变了不再只是堆算力而是强调“算力按需弹性分配”。以前是感知一块算力、规划一块算力、控制一块算力各自独立。端到端情况下所有模块合成一个模型但对算力的需求并不是恒定不变的。城市拥堵路段需要处理大量动态障碍物算力需求峰值极高高速巡航时场景相对简单不需要满负荷运行。弹性算力分配就是要让模型在复杂场景下自动占用更多算力在简单场景下释放资源用来跑数据挖掘、在线评估等后台任务。4.2 数据带宽被很多人忽略的瓶颈模型算力话题很热但到实际部署时我遇到的最大瓶颈往往是数据带宽而不是算力。端到端模型需要把全分辨率的原始传感器数据送进网络不能像传统方案那样先压缩、降采样、只保留感兴趣区域。多路8M像素摄像头每秒30帧再加上激光雷达点云数据吞吐量能轻松跑到每秒几十GB。这个数据量不要说芯片外部存储带宽扛不扛得住光是芯片到传感器的物理链路就要重新设计。GTC‘26上我看到一个很务实的方向在传感器端做“感知友好的压缩”。不是通用的视频压缩而是基于感知任务特性把对驾驶决策最关键的语义信息保留完整其他背景区域适度压缩。这有点类似人类视觉——中央凹区域看得很清楚余光区域捕捉运动信息即可。这种“感知压缩”可以在保证模型性能几乎不掉的情况下把带宽需求砍掉一半以上。4.3 车端“模型即服务”的架构演进在软件架构层面端到端时代的车端平台也越来越像“模型运行时”而非“功能集合”。具体体现在三个变化上模型管理支持同时驻留多个版本的感知模型、驾驶模型可以在线灰度切换不用整个系统重启动态加载根据当前场景地库、城市、高速、极端天气动态加载对应的专业场景模型避免用一个“全能模型”在所有工况下硬撑车载学习利用车辆运行时的数据在离线侧完成模型更新再通过OTA下发而不是指望车端做实时在线训练。这里我要特别强调“OTA灰度发布”的重要性。端到端模型是数据驱动出来的任何一次训练数据分布的轻微变化都可能导致模型行为在某个角落发生突变。如果没有一套可靠的模型分级发布机制——先在仿真里跑再在一小批车上跑确认没问题再全量推送——那每一次模型更新都像一次盲赌。我在实际项目中就吃过亏。有一次新版模型在仿真测试里各项指标都优但上了几台测试车后发现某个特定路口的掉头动作变得过于激进。就是因为新版训练数据里混入了一批较激进的人驾数据模型把“风格”也学进去了。仿真测试没有覆盖到这个具体路口导致问题到路测才暴露。后来我们把“分场景指标看板”加进了仿真评估体系才把这个漏洞堵上。注意车端计算平台的选型不能只看算力总和要看“实际构成的端到端部署形态下能否把模型跑到实时”。很多GPU/NPU芯片官方标称算力很高但网络结构一旦涉及长序列时序注意力内存访问模式、算子调度效率都会影响实际性能。我的建议是在选型阶段就把目标模型跑一遍性能工程分析不要轻信纸面数字。5. 仿真与世界模型验证体系的升维之战5.1 为什么仿真成了端到端的“命门”传统自动驾驶的验证覆盖可以靠“里程”积累——在公开道路上跑多少公里遇到多少场景基本是可控的。但端到端模型的验证根本没法依赖道路里程。举个例子你想验证模型在“小学生突然从路边停靠的公交车前跑出来”的场景下的反应。这种场景在自然驾驶中出现的概率极低你可能跑十万公里都遇不到一次但自动驾驶系统必须正确处理。怎么办只能靠仿真去构造。GTC‘26上反复强调的一个概念是“基于场景的验证”Scenario-based Validation。不要试图用海量随机仿真攒里程指望能碰巧覆盖你要的长尾场景而要把精力集中在构造极端场景精确控制变量测试模型在特定边界下的行为。这就像考驾照考官不会让学员在大马路上随机开两个小时就判定你会不会开车而是专门考“侧方停车”“坡道起步”“窄路会车”这些特定技能点。仿真验证的逻辑也一样场景库的设计质量直接决定了验证体系的可信度。5.2 世界模型VS传统仿真器各自的定位GTC‘26上“世界模型”World Model这个词频繁出现。很多人以为世界模型就是更高级的仿真器其实二者的关系不像替代更像互补。传统仿真器基于物理引擎和规则建模路面摩擦系数、车辆动力学、交通流规则都是人工设定好的。它的优势是精确可控力矩、加速度、碰撞响应都能精确复现劣势是不够真实尤其是对复杂视觉细节的还原很差传感器数据像是“渲染出来”的和真实数据存在域差domain gap。世界模型则完全不同。它从海量真实驾驶数据里学习场景的演化规律给定一段起点视频和一个控制指令世界模型预测出下一帧画面从而“续写”出一个连贯的驾驶场景。它生成的不是抽象的传感器点云/边界框列表而是像素级真实的连续画面。但世界模型的致命问题是不可控。它生成什么场景取决于模型在数据里学到了什么分布你没法精确指定“这里要有行人穿行”更没法保证生成的场景符合物理规律。我曾经跑过一些公开世界模型Demo画面看起来非常真实但仔细看会发现偶尔有车辆重叠、路灯消失等不符合物理的异常。所以我更倾向于把两者分开用世界模型用来做数据增强和场景探索生成大量与真实分布接近的新场景让模型见识更多“同龄人”扩大有效训练集的覆盖面传统仿真器用来做行为验证和极限测试精确构造法规边界、物理极限、碰撞原场景检验模型是否满足硬性安全要求。二者结合才能构成一个既“广”又“准”的验证体系。GTC‘26上某些方案已经尝试把世界模型生成的多样化场景灌入传统仿真器做物理约束过滤筛选后送入验证流程。这种“用世界模型的海量性补传统仿真器的多样性用传统仿真器的精确性补世界模型的不可控”的思路我看是未来的大方向。5.3 离线评估指标的高阶玩法端到端模型的评估光看“碰撞率”和“接管率”远远不够。这两个指标太粗撞不撞、接管不接管只反映了极端结果没法揭示模型行为的内在质量。GTC‘26上我看到很多团队开始把评估指标拆得更细比如驾驶风格量化急加速次数、急刹车次数、换道频率、跟车时距分布舒适度指标纵向冲击度、横向加速度变化率合规性指标是否压实线、是否闯黄灯、路口通行是否礼让预测对齐度模型对周围车辆行为的预测与真实行为的偏差随时间的变化率。这些指标组合起来可以构建一个“行为画像”让工程师一眼看出模型偏保守还是偏激进、在哪种场景下容易动作变形。我所在的团队已经把“分场景行为画像”作为模型上车的门禁条件只有各项指标都落在设定区间内才允许进入真实道路测试。实操心得离线评估指标不能只看均值要看分位数。新模型可能平均碰撞率、平均接管率都比旧模型好但在5%的危险尾场景下表现不如旧模型。这种情况在端到端模型迭代中非常常见——均值被大量常规场景拉低危险场景的退化被掩盖。我建议把每个核心指标分别统计P50/P90/P99P99不达标直接打回宁可保守也不能带上一个容易在极端场景掉链子的模型上路。6. 工具链与开发流程算法工程师的日常变成了什么样6.1 端到端提速的关键模型迭代的工程闭环模型迭代在过去是“数据齐了训一个模型看指标再训一个”这个循环以“周”为单位。端到端时代这个循环必须缩短到“天”甚至“小时”级因为模型太大了、场景太多了慢吞吞的迭代节奏根本追不上需求。我在GTC‘26上特别关注了训练推理一体化的技术栈进展。所谓“训练推理一体化”不是概念宣传而是实际工程训练时用到的算子、微调时的权重结构、部署时的量化策略尽可能保持同构避免“训练时表现很好部署后因为量化、裁剪导致行为漂移”的老问题。传统工作流里训练和部署是两拨人、两套框架中间还要做格式转换、算子替换、精度对齐任何一个环节不匹配都可能导致性能损失。端到端模型对这种不一致更为敏感因为行为是整体涌现的输出层的一个微小偏差经过时序传播会被放大成完全不同的驾驶决策。所以我的建议是工程架构上要把训练、量化、编译、部署拉通成一条流水线所有环节的精度和算子行为都要有自动校准机制。不要等部署完再去查哪里对不上那会浪费大量时间。6.2 模型评估中的分阶段验证策略我自己的团队现在把模型上车流程拆成四个阶段每一阶段都有明确门槛通过才能进入下一阶段离线回归验证在固定测试集上进行行为和指标回归重点查“相比旧模型的意外退化”仿真大规摸验证在场景库中跑数万条场景生成行为画像比对P50/P99指标受限道路测试在封闭试验场、特定开放路段少量测试由安全员实时监控全量路测与OTA灰度先小批量车运行一周收集对比数据再逐步扩大范围。这套流程的本质是把“模型可信度”分级。每一级验证都要消耗资源上了越高级别发现问题修复的成本越高。所以我在日常操作中特别重视第一阶段的离线回归——虽然它最“土”但往往是发现问题效率最高的环节。只要规则明确、测试集覆盖得好大量问题都能在几分钟内定位根本不用上仿真和路测。6.3 值得自建的工具场景管理、版本管理、归因分析GTC‘26上工具链的繁荣让人目不暇接但我不建议什么工具都往上套。真正值得自建的我个人认为有三个第一个是场景管理平台。把真实数据、仿真数据、世界模型生成数据全部打上标签按场景类型、难度、路线区域组织起来。这样模型训练和验证时可以精准抽样按需组合而不是把所有数据倒进一个巨大的数据湖里每次都“全量随机”抽样。第二个是模型版本管理系统。端到端模型的迭代太频繁模型文件和训练数据版本、代码版本、配置版本之间需要强制对应关系。没有一套严格的版本血缘管理出问题后根本不知道是哪个环节引入的。第三个是归因分析工具。模型行为出现问题时需要回溯“是训练数据导致的还是模型结构导致的还是场景分布变化导致的”我曾经遇到过一个案例某版本模型在雨天场景接管率上升排查到最后发现是训练数据里雨天场景的比例比上一版提高了导致模型过度拟合雨天特征在非雨天场景行为出现偏移。这类问题如果没有归因分析工具光靠肉眼在场景库里找差异简直是大海捞针。6.4 人机协作工程师的新角色端到端时代算法工程师的工作重心也从“调网络结构”转向“调数据分布、调评估规则、调验证场景”。很多人觉得这是“去技术化”我觉得恰恰相反——结构的创新空间已经很有限但对数据、评估、验证的系统性理解反而成了真正的竞争力。一名合格的端到端自动驾驶算法工程师现在最好还要懂一点数据处理、云计算、仿真器原理甚至要懂一点车辆动力学。因为你要能和仿真团队讨论物理引擎精度的问题能跟数据团队讨论标注体系的问题能跟部署团队讨论量化精度的问题。这是挑战也是机会。7. 给从业者的实战建议三件立刻能做的事7.1 从“模型优先”转向“数据策略优先”不论你现在用的是成熟开源方案还是内部自研模型我强烈建议把数据策略的权重提到最高。具体可以做这三件事在车端部署一个“数据价值筛选器”哪怕一开始用非常粗糙的规则如检测到新目标类别、传感器自检异常等也能显著提高回传数据质量建立难例库的“红黑榜”红榜放模型做得差的场景黑榜放模型表现优秀但容易遗忘的场景每个迭代周期都针对红榜做专项数据增强用“场景增量”而不是“总里程”来评估数据收益。同样是一万公里数据包含5000个关键场景变化的数据其训练价值远高于平稳运行的普通数据。7.2 升级仿真验证体系补上行为画像如果你们团队现在还是只看碰撞率、接管率建议尽早引入行为画像指标。具体做法固定一批典型场景城市跟车、无保护左转、自行车混流、施工绕行在这些场景里用固定规则统计模型的急刹率、压线率、让行次数等行为指标给出P50/P90/P99分位数。不要嫌指标多端到端模型的行为差异就是在这些细粒度统计里暴露出来的。7.3 提前布局端到端工具链的“短板”工具链的短板往往不是最热门的训练框架而是容易被忽略的数据版本管理、模型依赖追踪、基于大模型的数据自动标注。这些环节市场上现成方案不算成熟自研成本又不是特别高但价值极大。越早布局后面迭代效率的优势会越明显。比如数据版本管理我们一开始用的是一套简单的元数据数据库每次训练之前记录数据集的哈希值和筛选规则。后来发现这还不够——难例库在不停更新同一个数据集哈希下内部样本的分布其实已经变了。于是我们改成记录“数据集的逻辑视图”包括筛选条件、样本来源、标注版本才真正做到了训练结果的可复现。这个坑希望你可以提前避开。8. 写在最后主线是体系的升级不是单点的堆叠回到标题里的问题端到端时代自动驾驶的主线到底是什么我的答案非常明确主线不是模型本身而是围绕模型的“数据闭环、验证体系、车端支撑、工具链”的系统性升级。端到端把算法问题简化成了一个“大模型学习问题”但与此同时把工程问题巨大化了——数据怎么来、怎么标、怎么验证、怎么部署、怎么监控、怎么迭代每一条都是深水区。GTC‘26给我的总体印象是行业的头号玩家们已经意识到了这一点因此所有重磅发布都指向了“模型外围”更强的车端算力是为了把模型跑得更稳世界模型和仿真平台是为了把模型验证得更透数据工具链是为了把模型喂得更准。我个人有个体会端到端自动驾驶的真正门槛不是某个天才的模型结构而是一整套精密配合的体系能力。这种能力没法靠一两篇论文堆出来必须在工程实践中一点点打磨。作为算法工程师与其焦虑模型结构落不落后不如先看看自己团队的数据闭环跑得有多顺、验证体系有多扎实、工具链有多顺手——这些才是决定端到端落地速度的隐形主线。如果你也在做端到端相关的工作我特别建议你把GTC‘26上关于数据挖掘、自动标注、场景验证的讨论翻出来细看哪怕只看技术分享的路基也比反复琢磨那几个知名模型的开源代码有收获。至少就我个人而言今年从会上带走的最有价值的东西不是某个新模型的名字而是“端到端之后工程体系的优先级要整体前移”这个判断。