GTC‘26观察：端到端自动驾驶的工程底座与数据闭环

先说个实话，GTC'26 的议程刷遍算法圈的那几天，我整个人是有点兴奋又有点焦虑的。兴奋的是，端到端自动驾驶已经不再是 PPT 里的概念，而是被拆成了一套可拆解、可落地、可验证的工程体系；焦虑的是，当大家聊“端到端”时，往往只盯着某个大模型，却忽略了一个更根本的问题——支持模型持续进化的底座，是否已经够稳。

我在自己的日常工作中，常年要和感知、预测、规划、仿真相绑在一起，这种视角让我对“端到端时代”的理解可能和纯算法研究不太一样。这篇文章不打算复读那些宏观叙事，只从一个算法工程师的实操视角，把 GTC'26 上反复出现的信息密度，拆成几条值得随身携带的主线。如果你也正在做相关方向，或者正准备跳进这个领域，希望这些内容能帮你少绕一点弯。

1. 主线为何不是模型，而是三段式闭环

1.1 今年大会反复出现的高频词

如果把 GTC'26 上各个技术专场的关键词做一个简单汇总，出现频率最高的不是某个模型结构、不是某个损失函数，而是下面这些听起来没那么“性感”的词汇：实时推理、世界模型、数据自动标注、评测基准、车端计算平台。

这个现象挺有意思。两三年前，行业里还在比拼参数量、训练数据规模，以及某个公开榜单上的三个点提升。但现在你再听报告，很少有人在台上花大篇幅介绍“我们又发明了一个新模块”。各家叙事重心出奇一致地放在了同一个方向上：怎么让模型被真正量产、怎么让数据闭环转起来、怎么让评测体系跟上模型的迭代速度。

这说明行业已经从“证明端到端可行”的阶段，走到了“把端到端做成稳定产品”的阶段。模型结构确实重要，但当大家都用类似的多模态编码器、类似的 Transformer 解码器时，架构上很难再拉开决定性差距。真正的差距，转移到了模型之外的工程系统里。

1.2 模型趋同，工程能力才是分水岭

模块化方案和端到端方案的争论，我前前后后经历了不止一轮。早些年大家会纠结一个核心问题：感知是否还要单独输出障碍物框，规划是否还要显式轨迹。但 GTC'26 上我听到的绝大多数量产案例，都已经不再纠结这种二选一了。

你最后会发现，实际落地的架构几乎都是混合形态：主干用端到端模型统一优化，但中间保留了若干可干预的安全接口。真正拉开团队之间差距的，是下面这些琐碎却致命的环节：

• 数据分布怎么治理，困难场景如何被自动发现并回灌到训练集；
• 仿真器能不能以极高的逼真度生成边缘场景，同时保持较小的 sim-to-real 差异；
• 车端芯片的部署效率能不能撑起端到端模型每秒几十次的前向计算；
• 评测体系能不能回答“模型整体变好了”，而不是“只是榜单变好了”。

这些问题有一个共同特征：它们都无法靠单一算法模块解决，必须横跨算法、数据、系统工程三块领域。想靠一个大牛的模型结构打天下，在这个阶段已经不太现实了。

1.3 底座咬合后产生的飞轮效应

把视角拉高一点来看，我理解的端到端主线，是一套正循环：真实车辆在路上采集场景，后台用自动标注生成训练样本，仿真器批量合成稀缺交互，模型在统一评测集上验证，通过后再部署到车端。部署之后，车端继续产生新数据，回传后台，开启下一轮迭代。

这条循环链路上，任何一环掉链子，都会拖慢整个项目。数据回传如果还靠人工拷贝，那一天的可用片段非常有限；仿真器如果生成的内容失真，模型在虚拟世界里越练越偏，上线后反而更容易出事。所以我觉得，主线并不是某一次算法突破，而是“让闭环更快、更稳、更可解释”这套工程能力。

2. 端到端架构演进：结构趋同，难点在夹层

2.1 两类端到端的形态对照

如果硬要把端到端模型分类，我习惯分成两种形态。

从量产角度看，大多数成熟团队不会走到全黑箱那一端。全栈式端到端看起来很美，但一旦出现事故案例，你很难回答监管或者工程团队“为什么模型这么做”的问题。所以当前的主流做法是混合形态：主干是一个端到端模型，训练时在中间层挂上多个监督头，部署时只保留推理主路径，再用外部安全模块做兜底。

2.2 中间表示保留哪些，丢掉哪些

我踩过最深的一个坑，是一开始把全部中间表示都当成“多余”的丢掉了。后来实测发现，完全去掉几何相关的中间量，模型在夜路和雨天场景里会出现很诡异的预测跳动。现在我们在架构设计上遵循几条朴素原则。

第一条，几何强相关的中间量要保留，例如可行驶区域掩码、碰撞边界距离。它们能让模型在极端光照下依然保持空间一致性的先验。第二条，语义信息交给模型自主决定是否依赖，比如交通灯状态、施工标牌，这些语义依赖传感器质量，如果摄像头被遮挡就能直接走上备用推理链路。第三条，不把规则后处理彻底删掉，而是把规则模块转成“安全包络层”，当模型输出的置信度低于某个阈值时，由规则层临时接管。

这套设计远不如纯黑箱模型听起来酷炫，但换来了两个实实在在的好处：可调试性明显上升，安全性评审时也有了可以解释的依据。

2.3 监督信号与课程学习

端到端模型最常用的训练目标是行为克隆损失，简单来说就是让模型的输出轨迹尽量贴近人类驾驶参考轨迹。但只有行为克隆是不够的，因为模型学到的往往是“这个场景下人类怎么开”，而不是“人类为什么这么开”。所以实际项目中，我几乎都会叠加一些辅助监督，比如意图预测头、对比学习损失，让模型同时学习周围交通参与者的未来动作，再训练自己决策和他人预测之间的一致性。

训练节奏同样关键。我们内部用过一段时间的课程学习：第一阶段只用简单高速和空旷城市场景，把模型基础和动态控制能力先拉起来；第二阶段加入拥堵、加塞、无保护左转等交互密集场景；第三阶段放入极端天气、模拟传感器故障等鲁棒性样本。如果一开始就把全量数据砸进去，模型容易在训练初期剧烈振荡，后期反而不易收敛。

2.4 部署时三个让算法工程师头疼的问题

部署环节里，我认为最容易被低估的是三个问题。第一个是时间同步。端到端模型输入多路传感器数据，如果摄像头的帧时间戳和设备时间戳错位，模型学到的“同时性”会被损坏。之前我们某个版本只是偏移了十几毫秒，弯道预测的误差就开始显现。

第二个是计算资源。一个在云端跑得很流畅的 Transformer 骨干，搬到嵌入式平台可能连实时性都保不住。模型的访存量、算子碎片、输入分辨率都会成为瓶颈，所以要在训练阶段就做好量化感知和结构化剪枝，而不是等部署时再说。

第三个是可复现性。端到端模型里如果存在非确定性算子，或者依赖浮点近似库，同一份权重在不同批次硬件上的行为可能不一致。我的建议是固定算子精度、关闭有损加速，至少在离线仿真回归时用同一套场景集反复比对，确保版本行为可控。

3. 数据引擎与仿真：主线的隐性心脏

3.1 数据闭环为何在端到端时代被放大

模块化时代，感知模型的迭代只需要独立的数据集，今天想刷一个检测精度，那就增加对应类目的数据就行。但到了端到端时代，输入数据和模型内部的每个模块都纠缠在一起，任何一条边缘场景数据都会顺着主干网络影响下游的轨迹预测和决策规划。

所以我越来越觉得，数据不只是“喂给模型”的生产资料，它更像是一条需要精细治理的流水线。我见过一个典型的失败项目，团队花大力气采集了几百万段数据，但内部没有对困难场景做分级，数据仓库里绝大多数是高度重复的高速巡航片段，少数几个珍贵的窄路会车片段被严重稀释。结果模型在平均指标上看着不错，一到真实城区就明显暴露出应对能力不足。

数据闭环的第一要务，就是让最稀少的场景拥有更高的训练权重和更高的数据质量门槛。数量不等于质量，分布才是。

3.2 自动标注与预标注的规模化

端到端时代，纯人工标注已经跟不上迭代节奏。现在行业里比较成熟的做法是“传感器原始数据 + 自监督模型预标注 + 人工抽检修正”。这样做的意义不只是省人力，更重要的是标注口径的一致性。

人工标注的麻烦在于，不同标注员对同一辆车、同一条边界线的判断经常有细微出入。这个噪声在模块化感知里还能用后处理抑制，但在端到端模型里会顺着梯度传导到规划网络，让模型学到摇晃的行为边界。相比之下，稳定的预标注模型输出天然一致，人工只需要修正那些模型确实搞错的部分。

我常用的流程是这样：片段回传后，先跑规则过滤器筛掉无效帧，再用预标注模型生成 3D 框和语义分割，然后进入人工抽检队列。人工只需要按一定比例抽检，不用重新全量标注，最终把修正结果再回灌给预标注模型。跑上两三个版本后，自动标注的质量会明显上升，人力消耗却不会同样增长。

3.3 世界模型：是模拟器，也是数据生成器

世界模型是我觉得这届大会里最值得关注的新方向。它本质上是一个以视频或者状态序列为学习目标的大模型，能够根据初始帧预测未来一段时间的交通状态。这个能力对端到端自动驾驶的价值非常直接，传统仿真器需要人工编写交通流规则，而世界模型试图从大量真实驾驶数据里直接学习交通参与的复杂动态。

世界模型在数据闭环里有两个角色。第一个是数据生成器，专门生成真实场景里难以采集的交互事件，例如低速泊车时突然出现的横向闯入者，或者大雾天里突然蹿出的行人。第二个是模拟器，用世界模型做轨迹评估，减少对高精度物理引擎的依赖。

不过我在实操中对世界模型保持一个清醒的认识：它生成的内容未必符合真实世界的长尾分布，有时候甚至会生成“视觉上自然、但行为上违反交规”的场景。所以使用世界模型生产的数据必须经过规则校验，脱敏以后再做光照和视角扰动，不能直接混进真实采集样本，否则会让模型学到虚假相关性。

3.4 评测体系要防“内卷式刷榜”

端到端模型最怕的，是指标无法反映真实能力。很多团队还在用“平均接管里程”作为核心指标，其实这个指标太粗。连续跑一百公里和连续跑十个不同复杂度路网，平均接管里程可能一样，但系统能力的可信度完全不是一个量级。

我习惯把评测拆成一张多维卡片，防止单一指标掩盖真实缺陷。

这套评测卡片的重点是做正交分解。某次升级在安全性上提升，但边界能力下降，那就应该针对边界数据做补采和训练，而不是整个模型回滚。评测标准也不是静止的，必须定期混入新场景，否则模型会慢慢退化成“刷库工具”。

4. 算力底座：算法工程师怎么选型

4.1 车端平台的约束：时延和带宽高于峰值算力

很多同行选车端平台时，习惯先看峰值算力，觉得只要 TOPS 够高就万事大吉。但真正上车之后就会发现，算力只是必要条件，内存带宽和时延往往更容易卡脖子。

一个端到端模型要同时处理多路高分辨率摄像头输入，运行 BEV 编码、占用网络解码和执行规划头。每个环节都要搬运大量中间特征图，如果芯片的内存带宽撑不住，即便算力再高，实际推理帧率也会被拉到很低。我之前遇到过模型参数量不大，但因为特征图太大，访存长时间占满，最终推理性能只能跑到设计目标的百分之六十左右。

所以看车端芯片，不要只盯“多少 TOPS”，我会更关注这几件事：单位时间能稳定跑出多少帧、内部存储带宽是否充裕、常用算子在低精度下的加速比、生态工具链能不能直接支持自己用的训练框架。这些指标比一个营销性的峰值数字更能预测项目成败。

4.2 云端训练集群的成本意识

训练端到端模型时，显存和通信开销是绕不开的两座大山。参数规模变大之后，单纯加大数据并行已经不够用了，需要混合并行策略，让模型并行和数据并行搭配使用。与此同时，梯度检查点、激活重计算这些技术如果不提前安排好，显存会很快爆掉。

在实际项目中，我一般会把三个指标盯紧：集群利用率、有效训练吞吐、checkpoint 恢复耗时。有些团队把大量时间花在人工调超参数上，却忽略了集群本身的机器利用率。如果显卡有一半时间在等待通信或者等待读取数据，算法再强也跑不出应有的节奏。

另外，存储系统的吞吐也经常被低估。端到端模型训练会产生庞大的高频 checkpoint，如果存储跟不上，训练中断后的恢复时间可能长达几小时。提前设计好增量保存和异步落盘机制，会让团队从崩溃边缘解脱出来。

4.3 上车前的工程验证方式

模型在正式上车前，我强烈建议先做桩端测试和影子模式测试。桩端测试就是把车载计算平台接到一段固定数据流上，连续跑几百个离线场景，看延时分布、内存峰值、是否有算子不兼容或者进程崩溃。

影子模式是让新模型在驾驶员正常开车的过程中后台推理，但不介入任何控制。这个阶段最有价值的产出，是“模型决策和人类驾驶员决策的重合度分析”。如果新版本在某个路口频繁和驾驶员意图产生冲突，说明这里存在明显的剩余风险，需要针对性补充训练。

这套验证体系用很低的成本，就能提前暴露纯离线评测发现不了的问题。比如算子碎片、显存泄漏、多进程干扰引起的时延波动，这些坑往往比模型精度问题更致命，也更容易在量产前夕突然爆发。

5. 常见坑与排查实录

5.1 模型“什么都对，一出事全错”

端到端模型的典型崩溃模式，是整体指标很好，却在个别长尾场景里表现得一塌糊涂。原因其实不复杂，罕见事件在训练语料里占比太少，模型没有足够的梯度信号去专门处理这些情况。

排查的时候，不要只盯着整体损失，而是按场景维度分组去看。把“正常城区”“雨天夜间”“无保护左转”“施工改道”分别拉出来统计，看崩溃集中在哪一类。然后再确定是数据缺失，还是模型容量不够。

针对这种问题，我比较推荐的思路是“锚定策略”。把少量人工核验过的极端场景，以高权重反复送入训练集，同时在推理侧保留规则安全包络。当模型置信度低于阈值时，系统主动降速或转入保守策略，宁可不作为，也不要乱作为。

5.2 数据失衡导致的“选择性眼瞎”

这个坑我踩过不止一次。某个项目里，模型对汽车和卡车的检出精度很高，但一到摩托车就频繁漏检。刚开始我还以为是模型结构问题，后来一查训练分布，才发现摩托车在总样本里的占比低得可怜。单纯增加整体数据量，只会让占主导的汽车类别继续膨胀，摩托车类别依然拿不到足够的梯度。

正确的做法是困难样本挖掘和针对性增广。在车端回传阶段，用一个小模型过滤出“模型输出和人工标注差异大”的片段，这种片段往往就是当前模型的能力盲区。训练阶段再针对这些盲区做几何扰动、光照扰动、天气扰动，最后在评测阶段单独统计每个小类别的召回率，防止它们被平均指标掩盖。

5.3 过拟合到历史闭环数据

场景库如果长期不更新，模型迭代会慢慢退化成“刷库”。我印象很深的一次，我们团队试图提升无保护左转的通过率，就在固定场景集上反复调阈值和重训练，虚拟库里的成绩一路见涨，结果到真实城区一试，表现比之前的版本还要差。

从那以后，我给自己立了一个规矩：评测集每个月至少要混入百分之十五到二十的新场景。新场景一部分来自真实路采，一部分来自仿真生成的组合式变体。评测基准不能是固定不变的试卷，模型能力上去了，试卷难度也要跟着调整。这听起来像是额外工作量，但恰恰是防止模型在闭环数据上自嗨的有效手段。

5.4 版本灰度与回退机制

端到端模型更新后直接全量上线，风险太大。更稳妥的办法是灰度发布。第一步先在影子模式下跑大量真实路段，积累新模型与人类驾驶员决策的差异；第二步在小范围车队里开启辅助干预，设置严格的干预条件；第三步再逐步扩大覆盖范围。

灰度发布需要一套可观测性平台支撑，至少要能回答三个问题：新版本在哪些路段表现更差、是否出现异常急刹、是否出现预测震荡。如果任何一项指标明显恶化，就要立刻回退到上一稳定版本，同时保留现场数据进入训练闭环。版本迭代不是越快越好，稳定可控比跑得更快重要得多。

6. 给算法同行的几条实在建议

6.1 把“闭环周期”当成北极星指标

如果让我用一句话概括 GTC'26 上看到的端到端主线，我会说，主线是“闭环收敛速度”。谁能更快地把一个问题从出现、复现、修复到回归验证，谁就更容易在量产战场上站稳。

因此，算法工程师的目光最好不要只停留在模型效果上。多去理解数据采集、自动标注、仿真评测是如何衔接的，主动推动工具链的自动化，这带来的个人价值提升，往往比单纯训练一个大模型要更持久。

6.2 端到端时代下适合深耕的方向

如果让我给年轻同行一些方向参考，我会重点推荐三个方向。第一个是数据与仿真工程，包括自动标注、世界模型、基于闭环的数据治理；第二个是模型部署与硬件协同优化，包括量化、剪枝、分布式训练和推理加速；第三个是安全与评测体系，包括行为一致性验证、边缘场景缺陷分析、灰度发布机制。

这三个方向都属于“基础设施型”能力，它们不惊艳，但门槛高、迭代深，而且直接决定端到端模型能不能真正落地量产。

6.3 最后的一点个人体会

看完这届 GTC'26，我的整体感受是，行业正在从“参数量的暴力美学”切换到“工程系统性的沉稳力量”。对普通算法工程师来说，这反而是一个好消息。模型结构越来越趋同，意味着决定上限的不再是某个天才式的网络设计，而是谁愿意沉下心去打磨数据、算力和评测之间的衔接。

这件事没法靠一夜爆肝完成，但它一旦稳定运转，就会形成非常深的工程护城河。我个人这几年的体会是，真正能让人摆脱焦虑的，不是追每一个新模型的名字，而是把自己脚下那段闭环里的每个环节都打磨得足够可靠。与各位共勉。