端到端自动驾驶的三条主线：从GTC‘26看数据、部署与评测

每年GTC这类全球GPU技术大会一开，自动驾驶圈就像过年一样热闹。作为一个常年泡在端到端模型训练里的算法工程师，我这两天基本是白天开多个直播分屏，晚上刷技术博客和社区讨论，GTC‘26的大部分公开议题我都过了一遍。周围不少朋友问我同一个问题：算力堆这么猛，各家方案五花八门，端到端时代自动驾驶的主线到底是什么？

这个问题看着简单，真回答起来却容易绕晕。因为GTC’26上发布的东西实在太多了：新一代车规级算力平台、基础模型、仿真工具、数据管线、安全验证工具……如果只看单点技术，会觉得全是主线；如果只看商业叙事，又会觉得全是广告。所以我这篇文章想做的事情很简单：以算法工程师的视角，把GTC‘26公开信息里跟自动驾驶最相关的部分拆开，提炼出三条真正值得关注的主线，再把我自己在落地端到端模型过程中踩过的坑和总结的方法一并写出来。你可以把它们当作参会笔记加实践手册，也可以当作判断行业走向的参考框架。

1. 端到端成为主旋律，背后是技术路线的彻底转向

自动驾驶的技术路线，这几年经历了一个很有意思的反复。早几年行业主流还是模块化：感知出检测框和轨迹，预测模块出未来几秒的意图，规划控制模块做避障和路径跟随。每个模块单独训练、单独评测，接口定义得清清楚楚。这套体系的优点是逻辑透明、出了问题容易定位；缺点是感知和规划之间存在大量信息损耗。

1.1 模块化方案为什么走到天花板

举个真实场景。高速上前方有卡车，货厢上掉下一块塑料布，人在车里能看到“那是一块飘动的软性障碍物”，经验上知道压过去可能有风险，应该提前减速或者绕一点。模块化系统里，感知模块大概率把塑料布识别成“未知物体”，但边界框表达不了“软”“飘动”“可能受到气流影响”这些信息；预测模块面对一个从未见过的物体类别，只能给出保守默认行为，规划模块接到一个高不确定性的输入，往往就选择急刹或者停在原地。不是某一个模块做错了，而是整个流水线的表达方式限制了系统对复杂世界的理解。

另一个问题是规则和模型之间的边界很尴尬。业界常说长尾场景是自动驾驶最大的敌人，可长尾的定义本身就在变。一个场景初看很罕见，积累一段时间后可能变成常规场景，比如某些城市的特殊路口标线、特定季节的落叶覆盖车道。传统方案里这类场景基本靠人工写规则或者加模型分支，每增加一类情况就要更新一次接口，系统复杂度呈指数上升，最后维护成本高得吓人。参加过大型自动驾驶路测项目的人都懂，模块化系统的代码仓库到后期几乎不敢大改，牵一发而动全身。

1.2 端到端到底改变了什么

端到端路线想要解决的，恰恰是这个从感知到决策的连续表达问题。不再依赖人为分割的子任务，而是用一个可微分的神经网络把传感器输入映射到驾驶行为输出。好处非常直观：所有信息在模型内部自由传递，没有中间格式的截断；整个系统的行为不是由规则逐条拼出来，而是从大量真实驾驶数据里学出来的。用一句大白话说，传统方案像是一个照着说明书做事的新手司机，端到端模型更像一个跑过很多路、遇到情况能凭直觉处理的老司机。

从GTC‘26的技术展示来看，行业已经明显从“要不要做端到端”的争论阶段，进入到了“怎么把端到端做好”的工程化阶段。大会上的几个重点方向——基础世界模型、大规模数据平台、车端部署的算力保障——都指向同一个共识：端到端不是某一个模型的品牌标签，而是一整套围绕数据、算力、评测的基础设施工程。谁的基础设施更扎实，谁才能真正把端到端从Demo变成可量产的产品。

这正好回答了一个经常被问的问题：为什么感觉每家都在谈端到端，但落地节奏不一样？因为端到端模型本身的网络结构反而不是最难的，难的是喂给它的数据、承载它的算力、验证它的方式。

1.3 从GTC’26看路线共识

我在GTC‘26的演讲里注意到一个细节：几乎所有自动驾驶相关的分享都不再强调“我们比模块化强多少”，而是直接默认观众已经理解端到端的价值，开始讲数据、评测、部署这些工程问题。这个信号非常强烈，说明行业共识已经形成，技术竞争的核心正式转移。接下来要比拼的，不是谁的模型更花哨，而是谁的工程闭环更高效。所以后文我会用三个主线来拆解GTC’26的实质内容，每条线都对应一个决定量产成败的工程维度。

2. 算力、数据、模型，GTC‘26上这三条腿缺一不可

每次GTC大家最先关注的永远是芯片。这次GTC’26也不例外，新一代车规级计算平台的发布直接拉高了整个行业的算力预期。

2.1 算力平台：数字之外的三个真相

作为算法工程师，我特别想提醒一点：别只看T算力数字，更要看平台整体能提供的有效计算能力。所谓有效计算能力，指的是在一个模型真正跑起来之后，能够稳定达到的实际吞吐，既要考虑内存带宽、缓存层级，也要考虑算子效率。现在车端模型越来越大，从几年前几百万参数的感知小模型，到如今动辄上亿参数的视觉语言动作模型，模型体量提升十倍，对算力的需求提升可能超过二十倍，因为注意力机制的计算复杂度和序列长度之间是平方关系。

这里多说一句内存带宽的瓶颈。很多车载计算平台宣传时的算力指标很高，但真实部署一个端到端模型时，常遇到的不是算力不够，而是带宽不够、显存不够。比如一个高分辨率多视角图像输入，光是一帧图像送入模型前的预处理和特征图搬运，就会吃掉大量带宽。GTC‘26上展示的车载平台方向，比较务实的几个点包括统一内存架构、高带宽片上存储、以及在硬件级别为Transformer类算子做加速。这些相对“枯燥”的细节，比单纯堆稀疏算力值重要得多。

另一个容易忽略的点是能效和散热。端到端模型持续满负荷运行时，功耗曲线比传统感知模型陡得多。GTC’26上讨论车端芯片时，多次提到“性能功耗比”而不是绝对峰值算力，这背后就是量产车对功耗和散热的极强制约。做算法的人如果只关心模型复杂度，很容易设计出在云端跑得很爽、上车却因为发热直接降频的方案。

2.2 模型层面：从感知决策一体到多模态融合

数据是GTC‘26上另一个反复被强调的方向。很多大会演讲里提到“数据引擎”“数据工厂”这类概念，背后的逻辑很清晰：端到端模型参数量大，需要覆盖的场景多，而真实路采数据里绝大部分都是平淡无奇的常规驾驶，真正有价值的稀有场景可能只占总数据量的百分之零点几。没有一套庞大的数据采集、切片、筛选、标注、增强的流水线，端到端模型根本喂不饱。

模型层面也一样。GTC’26上关于端到端模型的讨论已经不再局限于视觉输入的感知决策一体，而是更多强调多模态、大语言模型、世界模型的融合。比如让模型理解交通指示牌上的临时文字，光靠视觉特征是不够的，需要语言模型帮忙解析语义；又比如面对施工路段的临时改道，模型如果具备一定的常识推理能力，就能更快理解场景意图。这些能力正在从论文走向原型，慢慢成为新一代端到端方案的标配。

算力、数据、模型这三者在GTC‘26上的关系，我总结成一个三角：算力是底座，数据是燃料，模型是引擎。单独强调任何一项都会出问题。算力强但数据弱，模型训练不出来；数据强但算力弱，训练周期和成本失控；模型好但工具链差，落不了地。这也是为什么头部玩家都在同时押注三条线，而不是只挑其中某一项单点突破。

3. 主线一：数据闭环与可扩展的仿真世界

我去年参与过一个端到端泊车项目的早期验证，整个过程中最痛苦的不是模型结构，而是数据的分布被人为扭曲了。当时为了快速做出效果，我们用了大量园区固定车位的采集数据，结果模型在普通路边停车场景里频繁误判。这让我彻底意识到一个问题：端到端系统能力的上限，很大程度等于数据覆盖的上限。要突破这个上限，必须有系统化的数据闭环。

3.1 数据闭环的四个环节

所谓数据闭环，简单说就是四个环节：采集、挖掘、训练、评测，形成一个不断迭代的循环。车队在真实道路上跑，车辆自动把一些特殊场景——比如近距离切入、异形车、夜间逆光、非机动车混流——打包回传到数据中心。数据平台对这些片段做自动场景分类和难例挖掘，挑选出对提升模型能力最有价值的样本，经过清洗和标注后进入训练集。模型重新训练后再回到车上跑新路线，这个循环周而复始。

孤立看每个环节好像都不复杂，但实际落地时全是细节。单说难例挖掘，你就得回答：什么样的样本算难例？如果按模型置信度低来采样，大量低置信度样本其实是感知正常但语义边界模糊的普通案例；如果按人工规则去筛，又没法覆盖模型的各种弱点。我在GTC‘26看到的趋势是利用基础模型做场景理解，自动给数据打上“行为级标签”，比如“前方车辆长时间压线但不并线”“行人在路口停留张望”这类有语义的行为片段，再结合模型在仿真器里面的失败轨迹，组合起来排队喂给训练系统。

还有一个经常被低估的环节是数据清洗。端到端模型对数据噪声非常敏感，一段GPS抖动厉害的数据、一个标注框偏移了几像素的样本，都可能干扰模型学到的驾驶策略。我们内部建了一套多层过滤机制：先做传感器质量检查，再做标注一致性校验，最后用一个小型预训练模型做行为合理性打分。三轮筛下来，能进入训练集的数据往往只剩原始采集量的百分之几，但训练效果反而更稳定。

3.2 世界模型：仿真从规则驱动到数据驱动

数据闭环的另一半是仿真世界。这几年“世界模型”这个词被反复提及，不少人不理解它和传统仿真的区别。传统仿真是规则驱动的：美术师建好道路模型，程序写好人车运动逻辑，传感器模型中规中矩地渲染。优点是可控，缺点是真实感有限，很多传感器细节和物理交互表达不出来。世界模型是从海量驾驶视频里学到场景演变规律，你在训练集里给它一段路况，它能生成接下来几秒里可能出现的画面变化，甚至带有一定的多视角一致性。这种生成能力不是简单插帧，而是从语义层面理解场景中每个元素未来可能的运动方式，相当于模型内部自带了一个可微分的小型物理引擎。

这个能力对端到端训练特别有价值。因为端到端模型要学的是“什么状态会导致什么后果”，如果只用标签数据做行为克隆，很多危险场景在真实数据里出现的频次太低，模型根本学不到。世界模型可以主动生成这类边缘场景，比如前车急刹、行人突然横穿、路面施工挪锥桶，甚至可以组合出“前车急刹的同时右侧出现非机动车”这种多层突发，极大扩充了模型见过的状态空间。

3.3 合成数据使用的分寸感

但我要给所有急着上世界模型的人泼一盆冷水：生成式场景不能全信。我们做过一个试验，让世界模型生成雨夜场景来补充训练，结果模型在合成的“雨滴轨迹”上过拟合严重，真实雨夜反而表现变差了。后来检查发现，是世界模型生成画面的伪影分布和真实传感器噪声分布存在系统性偏差。合理的做法是让合成数据跟真实数据混在一起配比训练，同时拿一份真实验证集定期抽查生成场景的可信度，千万别把生成数据当成免检的真实数据。

除了场景生成，仿真在评测环节的作用也容易被低估。GTC‘26上不少演讲都在推“闭环仿真评测”取代传统开环指标。所谓开环指标，就是给模型一段录好的输入，看输出的轨迹和真实轨迹有多接近；闭环仿真则是把模型接进仿真环境里，让它自己开车走完整段路，看是否发生碰撞、是否违反交规、乘坐是否舒适。别看只是这个区别，对模型的打磨方向影响巨大。只有开环指标的话，模型很容易学会“抄答案”——预测结果和真实轨迹的重合度高，但让它自己在仿真里开，几分钟后就压线甚至撞墙。这事我们踩过一次之后，就把开环指标当成辅助参考，最终考核一律上闭环场景。

4. 主线二：车端部署，算力、带宽和安全的三角博弈

很多人对端到端有个误解，以为端到端模型就是把所有事情交给一个大模型，车端只需要把模型部署上去就完事了。实际操作过之后就知道，真到了部署环节，你需要面对的问题一丁点不比训练少，甚至更磨人。

4.1 延迟预算与模型压缩

先说算力规划和延迟预算。一个量产级端到端系统，从传感器拿到原始数据，到方向盘或电控指令输出，整个链路往往要求在一个比较严格的时间窗口内完成，比如100毫秒量级，有的场景甚至要压缩到几十毫秒。这意味着模型的前向推理时间、后处理时间、通信开销全部要算进预算里。我们做驾驶决策类模型时会给自己定一个明确的延迟分区：传感器预处理占多少毫秒、骨干网络占多少毫秒、规划头占多少毫秒、冗余校验占多少毫秒，每一段都要压到可控范围，否则任何抖动都可能触发安全降级。

为了把大模型塞进车载计算平台，压缩手段是绕不开的。量化几乎是标配，把模型参数从32位浮点降到16位甚至8位整数，推理速度能提升数倍，显存占用也能减少大半。但量化也不是白拿的，训练时轻微的数值抖动在低比特下会被放大成明显的精度损失。我们的经验是量化对结构和激活函数非常敏感，某些位置用8位根本不行，得退回到16位，或者用混合精度量化，按敏感度分配不同层级的比特数。

类似地，知识蒸馏也常用：用一个效果好的教师大模型，训练一个更小的学生模型去逼近它的行为，换体积和延迟的下降。蒸馏的效果很依赖师生模型之间的结构差异和数据分布，我们一般会用大量离线和在线数据混合，防止学生模型只学到教师模型的表面偏好。

4.2 部署中最容易被低估的内存带宽

部署时最容易被低估的问题是内存带宽。我刚做第一个端到端模型部署时，满脑子想着怎么把算力用满，结果瓶颈完全不在计算单元。模型体量上去之后，每一帧特征图都要反复读写，带宽一旦不够，再大的算力也是空转。后来我们用了几个土办法来缓解：把特征图融合通道，减少中间张量数量；把部分算子搬到更接近计算单元的片上缓存；甚至通过调整任务的并行度减少数据搬运次数。GTC‘26上各大计算平台都在强调统一内存和高带宽互联，其实就是意识到这个瓶颈不是软件层面能单独解决的，必须硬件协同。

另一个部署阶段的隐藏问题是软件栈的碎片化。同一个模型在不同规格的硬件平台上跑，算子融合策略、推理引擎选择、精度设置都可能有差异。我们在某次项目里就遇到过：模型在开发板上验证通过，换到另一个平台后，某些算子竟然不支持，只能重写适配层，白白耽误了快两周时间。所以现在做模型选型时，我们会提前确认目标平台的算子支持和性能基线，把这个因素写进需求文档。

4.3 端到端时代的系统级安全

接着就是安全和冗余。这是我在GTC‘26上看到讨论密度最高的主题之一，也是我认为端到端时代最容易被公众误解的点。很多外行以为端到端意味着“把命交给一个神经网络”，行业内几乎没人会这么想。量产系统里呈现出来的端到端，通常是“端到端主模型+规则和安全兜底模块”的组合架构。主模型负责绝大多数场景下的类人驾驶，安全兜底模块负责监控主模型的输出是否越界，比如速度是否超限、是否切入不可行驶区域、长时间无有效输出等。一旦触发，系统会降级到保守模式或者请求驾驶员接管。

这里有个细节值得展开：监控模块怎么判断“主模型行为异常”？我们常用的思路是行为预测一致性校验，拿一个相对简单的动力学模型或规则安全模型，预测主模型输出后一个短时窗口内会发生的轨迹，再和主模型实际执行的指令做对比，偏差超过阈值就判定异常。还有一些团队会给主模型自身加一个不确定性头，让它输出每个决策的置信度。但这个方案在训练时特别容易出问题——模型学到的是高置信度地犯同样的错误，置信度完全不可信。所以我还是更推荐独立的监控逻辑，尽量不要复用主模型内部的信号。

安全兜底和降级策略往往是端到端量产最难的部分。GTC‘26上一个让我印象深刻的说法是：端到端改变了车“怎么开”，但没改变车“怎么安全地停”。不管模型如何智能化，系统层面都必须保留清晰的失效边界。主模型可以误判物体类别，但兜底层必须保证车辆不会在没有有效指令时冲出去。这个思路听着朴素，做起来极其复杂，涉及大量系统集成和标定测试，是真正拉开不同团队工程能力差距的地方。

注意：安全兜底层的阈值不能拍脑袋定，必须要和主模型的行为分布统计对齐。我们曾经把兜底阈值设得过于宽松，结果主模型多次出现偏保守但不算违规的行为都没触发，直到有一次在匝道上差点越过路沿才暴露问题。建议每隔一段时间就用最新路测数据重新统计阈值分布。

5. 主线三：评测体系，端到端时代的“驾照考试”

聊完了数据和部署，我想专门拿出一章讲评测体系。原因是这几年我观察到不少做端到端的团队，模型训练和上车验证之间的脱节非常严重。训练时候看曲线，验证时候看指标，实际上路看表现，三套评价体系各自为战，出了问题根本说不清是哪一环导致的。

5.1 传统指标为什么失效

首先，传统模块化的指标在端到端体系里会失效。端到端系统学的是映射关系，中间没有清晰子任务，所以你很难用检测的召回率、预测的平均位移误差来指导调参。你说模型这周表现变好了，可能只是因为换了数据采样策略，而不是模型结构进步。去GTC‘26之前，我们内部就有过几轮关于“端到端模型到底用什么指标来验收”的讨论，参会的经历让我把几个方向看得更清楚了。

第一类是场景级指标。把大量真实路采片段做成带标签的场景库，每个场景覆盖一种典型挑战，比如近距离切出、汇入拥堵匝道、夜间窄路会车等。模型在这些场景上的通过率、舒适性得分、安全边际成为核心评价维度。这类指标的优点是贴近用户感受，缺点是场景库的构建成本很高，而且容易形成“榜上车神”效应——模型专门针对场景库过拟合，真实路况一变化就露馅。

第二类是泛化性指标。在模型没训练过的城市、没见过的天气条件下跑采集车，统计接管率、违规率、急刹率这类统计结果。这个方向最接近终极目标，但成本极高，而且每次评测周期很长，不太适合快速迭代阶段使用。我们一般把这类真实路测作为里程碑式验收，不放进日常训练循环。

第三类是对抗性指标，用专门构建的极端扰动来测试模型，比如传感器被部分遮挡、强光直射、标线磨损、前车抛洒物等，评测模型在这些条件下的行为稳健度。这类指标能在有限成本下模拟长尾风险，但对扰动设计者的经验要求极高，扰动过强模型必挂，扰动过弱测试毫无意义。

5.2 组合评测体系与训练嵌入

结合GTC‘26上展示的一些平台能力，我的判断是：未来两三年，主流的评测趋势会是“真实路测统计为锚、场景库为日常、对抗测试为底线”的组合模式，并且越来越依赖仿真平台在中间做快速筛选。仿真可以把场景库里的几千个场景批量并发运行，每个场景几分钟出结果，模型更新一次后几小时内就能取得整体回归报告。这在真实路测里根本不可能实现。

更重要的是，评测体系一定要从训练阶段就开始嵌入。我们现在做端到端模型时，会刻意把一些已知难例按固定比例混进训练集，同时保留一份不参与训练的“守门场景”，每次模型训练完必跑一遍守门测试。如果守门场景得分下降，哪怕训练集里的指标在上涨，我们也会放弃这次迭代。道理很简单：一个系统是否真的在进步，不是看它在见过的数据上发挥多好，而是看它在没见过的考验面前是否依然稳定。这个思路听着不复杂，但对团队的评测基础设施提出了很高要求，也就部分解释了为什么端到端项目看起来谁都能做，但量产进展天差地别。

5.3 主观体验与客观指标的鸿沟

评测体系里还有一个容易被忽视的点：主观体验与客观指标之间的差距。把“舒适性”几个字拆成加速度变化率、转向抖动、跟车时距，再做乘客打分回归，你会发现线性加权的客观指标跟乘客主观感受往往不严格相关。有的模型客观指标非常漂亮，急刹少、偏移小，但乘客就是觉得开得“别扭”。后来我们引入了一些序列层面的评分模型，把一段时间的驾驶行为作为整体评分，再和客观指标一起看，才慢慢把体验问题转化为可以迭代的工程问题。这件事也提醒我，端到端领域的评测，不能只做工程层面的一对一映射，研究的其实是“怎么定义好的驾驶行为”这个本质问题。

6. 落地实践中的踩坑记录与排查思路

前面聊的都是趋势和体系，这一节我想分享一些实战层面的东西。都是我们在实际项目里踩过的坑，不一定每个都适用于所有团队，但遇到类似情况时至少能帮你少走弯路。

6.1 三组高频坑：数据、仿真、部署

先说说训练不稳定。端到端模型，尤其是融合了注意力机制的驾驶模型，训练时loss曲线经常出现“看着在收敛，突然跳变”的情况。我们排查后发现，最常见的原因是数据分布被打乱——某个批次的样本里混入了大量高难度场景，导致梯度方向剧变；另一个常见原因是学习率策略和模型规模的匹配问题，大模型用固定学习率很容易震荡，必须配合预热和衰减计划。解决方法是把训练数据按场景类型分批，每个批次从各批中按比例采样，保证每个batch的难度分布稳定；学习率则根据loss的滚动均值做自适应调整，不能只靠手调。

再说一个仿真和真机表现不一致的经典问题。仿真里测得好好的，真机上一跑就露怯，这种问题十有八九出在传感器数据分布上。仿真渲染的图像往往是“干净”的，真实相机的情绪、过曝、模糊、运动噪声都没法完全模拟。解决思路有几个方向：一是在仿真场景里加入传感器噪声模型，别只用理想化参数；二是把真实路采数据的一部分直接注入仿真测试链路，看看模型是吃了数据还是吃了环境；三是保留一部分真实路测作为不可妥协的最终验收方式，仿真成绩只作为门槛，不作为交付标准。

关于车端算力不足的应对。很多团队最开始只有一台测试车或者一个仿真平台，模型很大但部署设备算力有限。低成本起步的经验是：先跑一个经过蒸馏的小型化版本，把业务逻辑验证清楚，再逐步扩大容量。不要一上来就追求刷爆榜单的巨型模型——榜单上的大模型在真实部署时往往要面对延迟、功耗、稳定性一堆问题。我们有过一次反向教训：把一个竞赛级大模型搬到车端后，算力占用直接顶满，触发了系统的过温保护，整个测试被迫中断。从那之后我们在选型时会把“部署条件”作为模型设计的前置约束，而不是最后短板。

6.2 排查速查表与迭代习惯

我再整理一张排查速查表，整理几个我们经常遇到的异常现象和对应排查方向：

这页速查表不追求覆盖所有情况，核心价值是提醒一个习惯：先定位问题所在的环节，再动手调参数。端到端系统是一个整体，但排查时必须尽量隔离变量。否则很可能出现调了半天数据，最后发现是服务器端的推理卡顿造成的误判。

最后说一个我特别想强调的认知：端到端模型的迭代速度，本质上取决于你有多快能发现并归类失败案例。我自己习惯的做法是，每天自动跑一遍全量测试场景，生成失败case清单，按“数据问题、模型问题、系统问题”三类打标。数据问题进入采集或标注队列，模型问题进入训练迭代目标，系统问题单独提给工程侧。坚持这个流程三个月后，整个团队的迭代效率会有肉眼可见的提升。这个习惯也是我在看完GTC‘26、把主线梳理清楚之后最大的领悟：端到端自动驾驶的制高点，不在于某一次发布的模型或芯片带来了多少惊喜，而在于你是不是把最枯燥的数据、评测、部署工程都做扎实了。技术选型会变，产品形态会变，但围绕高质量数据和可靠系统化评测构建的工程底座，才是真正的大主线。