GTC‘26开完那周我的朋友圈几乎被两件事刷屏一是各家端到端方案的效果视频二是各种“数据清洗流水线”和“训练监控面板”的截图。说实话作为一个从规则时代一路做到现在的算法工程师这个组合很有意思。前几年大家聚会聊的是网络结构、融合时序、损失函数去年开始换成了end-to-end、planning大模型到了今年你会明显感觉到话题的重心已经不是单个模型模块而是变成了一套系统能不能自己转起来。今天我就盯着“主线”这个话题聊聊我对这场大会的看法以及这一年多干端到端项目攒下的实际心得。先放结论端到端时代自动驾驶的主线根本不是某个更牛的模型结构而是让数据、算力、评测三者形成一条能自我迭代的闭环产线。谁先把这条产线跑通谁就掌握了主动权。1. 端到端不只是换模型是把研发方式重做一遍1.1 大家都在追结构的时候真正拉开差距的是数据产线做感知的时代我们还有相对清晰的模块边界检测、跟踪、预测、规划每一块有自己独立的指标和优化目标。端到端最大的变化是把这些边界全部打掉输入传感器数据直接出轨迹或控制指令。这意味着一个问题以前任务被拆解得足够小你可以单独把感知调好再让下游规划去接盘现在模型容量有限它到底关注什么、忽略什么完全由训练数据说了算。结构的作用被数据分布压制了这点不亲自动手做一轮很难体会到。我第一次真正意识到这个变化是在做一个“行人突然横穿”的场景优化时。当时团队花了很长时间调网络结构加时序模块、加关注机制成功把离线指标刷高结果很漂亮。但上车测试换一个红绿灯路口老问题照样出现。后来复盘发现训练集里那个场景本来只有几百帧模型根本没有足够的统计证据把这个行为内化等于它只是表面记住了那一段样本。换句话讲结构再先进数据分布不对模型只是在背样本而没有真正学会应对。这之后我把大量精力放到数据产线建设上。端到端模型对数据的需求不是单纯的数量多而是分布正确。你可以把模型想象成一个新司机如果驾校只教它在空旷直线路上开它考试也许能过但遇到真正的复杂交通流完全没有应对能力。我们要做的是让数据采集、挖掘、标注、回灌这个过程快起来。在GTC‘26的很多分享里大家都把这条产线画成环形数据从车上回来经过筛选进入训练训练出的模型再跑仿真评测仿真发现的新问题又变成数据回到库里。这个闭环能转多快才是一个团队真正的护城河。1.2 我复盘的一条难例挖掘链路难例挖掘不是新概念传统做法是人工盯数据遇到接管或者检测失败就顺手下载一段。这种方式在端到端时代远远不够因为我们需要持续地供给大批量、结构化、覆盖多维度的训练场景。我自己在项目里用过的通用链路大概是这个思路先建一个很大的无标注池子数据从车端传回后不急着标先让当前模型在本地推理一遍推理时记录每个片段的预测不确定性。对于模仿学习类的模型不确定性估计常用几种方法预测分布熵、多候选轨迹的离散度、预测logits的置信度。我用的比较多的是熵和梯度信息组合熵衡量模型“犹豫不决”的程度梯度代表“如果纠正这个预测模型能学到多少新东西”。两者结合比单纯看loss值可靠得多。import torch import torch.nn.functional as F def mine_hard_samples(model, frames, threshold0.75): model.eval() hard_indices [] with torch.no_grad(): for idx, batch in enumerate(frames): logits model(batch) # 某些端到端模型输出多模态轨迹概率 probs F.softmax(logits, dim-1) entropy -(probs * probs.log()).sum(dim-1).mean() # 还可以补充一个指标预测轨迹之间的平均位移误差 # 这里简化为用熵阈值挑样本 if entropy.item() threshold: hard_indices.append(idx) return hard_indices但这样筛出来的样本会有一个结构性问题全是难样本里最极端的一批分布偏了。所以挑完之后我还会做一步场景聚类把样本映射到特征空间比如用视觉embedding做聚类把“夜间路口”和“雨天高速匝道”分开再按场景数量做平衡采样保证新数据覆盖的维度和旧的分布大致衔接。这一步非常关键不做的话模型训着训着就只会处理极少数反直觉的情况正常路段上的性能反而往下掉。1.3 真值标注的成本压缩省下来的是真金白银数据挖掘出来只是第一步更关键的问题是label从哪来。端到端规划常用模仿学习真值本身就是“人类驾驶轨迹”这部分标注起来相对便宜回放司机的方向盘转角、加速度组成一条轨迹序列就好。但如果想加辅助任务或者做更复杂的可控性约束往往还需要语义、占用栅格、目标轨迹这类标签成本立刻上去了。我的经验是能上自监督和弱监督的地方别急着上人工。比如占用栅格可以用周围几帧点云的时序信息自动生成大部分阈值得靠统计标定不需要人一块块描。目标轨迹则可以用现成追踪器在无标签视频上先打一遍筛掉低置信度片段再送人工审核人工量能下降一半以上。代价是你得维护一套自动标注流水线以及配套的质检任务。但算总账仍然很划算尤其是在新场景快速涌入时标注速度决定了你的迭代速度人工太慢就只能靠更聪明的自动化策略补位。2. 训练侧才是隐形战场把GPU集群喂饱2.1 网络结构没那么玄幻瓶颈在数据供给端到端模型的结构各家其实大差不差。主干把多路传感器编码成特征时序模块做上下文聚合输出层生成轨迹或控制指令。真正让团队之间拉开差距的往往是训练系统能不能稳定高效地跑起来。这里说的不是只用哪个框架而是一连串工程细节数据加载是不是够快、并行卡之间通信有没有均衡、checkpoint存得太频繁会不会拖慢循环、以及训练到一半会不会莫名出现loss爆炸。我第一次带端到端项目时吃过大亏模型训了两周后来发现那段时间GPU利用率只有百分之四十几原因是数据加载进程成了瓶颈。图像和点云都做了精细化预处理batch稍微变大CPU worker就崩掉DataLoader退出后训练进程还在空转。后来我把预处理前移到离线阶段线上只保留轻量解码又加了共享内存预取才把GPU利用率长期稳定在百分之八十五以上。这件事之后我养成了一个习惯每次开新一轮训练前先盯着监控看半小时确认GPU利用率和数据供给曲线别只看loss下降就觉得一切正常。2.2 记忆回放和大规模训练的三板斧端到端训练和纯离线模型的典型差异是数据永远在滚动更新。新场景不断进库模型必须学新东西但又不能把旧能力全部忘掉所以记忆回放几乎成了标配。我的做法是维护一个小的回放buffer每次训练step里除了当前轮次的新数据同时混入一小部分历史样本。这个比例很敏感太高会让模型在旧场景里原地打转太低又压不住灾难性遗忘。我通常从百分之五开始调同时盯着验证集上旧场景的指标曲线掉了就往上加稳住了就往下减。除了回放还有几个工程细节值得写出来。第一学习率warmup要做长。端到端模型参数多起步时看到一个超大loss非常正常如果直接用稳态学习率去跑梯度爆炸只是时间问题。我一般线性warmup前3到5个epoch再用cosine或常数衰减。梯度clip也一直开着默认clip到1.0等训练稳定后再观察能不能放松。第二混合精度训练必须开但loss scale要盯着。fp16混合精度下loss scale如果总是被自动拉低说明梯度里有问题大概率是数据或前处理出了状况先查这两个地方。第三checkpoint分级保存。大模型训练动辄几天中途崩溃是常态至少每固定步数存一个可恢复的版本。我团队里现在每个checkpoint都会带上数据版本号、代码commit号和训练配置否则出了实验对比问题你根本不知道模型是在什么环境里长大的。2.3 Loss怎么配端到端从来不是单一损失端到端规划的损失函数通常是一个组合。我项目里的典型配置包括模仿学习主损失预测轨迹和人类驾驶轨迹的负对数似然或者L2距离加角度惩罚辅助语义损失比如占用栅格上的cross entropy帮助模型建立空间理解还有强化或安全项对碰撞、压线、急刹给出惩罚梯度不过这部分一般不是从第一步就加入。权重不是写死不变的。我们试过在训练初期把模仿学习权重设为1.0辅助损失设得很小等到损失降到一定程度再把安全项权重拉上来。这种训练计划表需要连续盯好几轮实验才能定下来。这里有一个反直觉的经验辅助任务权重如果太大主干网络的特征表达会更多偏向语义重建而忽略决策需要的时序关联。所以每次加辅助头都要回看主任务指标不能被辅助任务的漂亮收敛曲线迷惑。如果主任务开始掉点就调低辅助权重让模型重新聚焦到“怎么开车”上。3. 评价和生成世界模型不只是讲故事3.1 开环指标好看不代表车真的会开端到端时代最危险的错觉是觉得离线指标好就等于车能开好。L2误差、模仿准确率这些开环指标只说明模型在给定真值轨迹的条件下预测得准但模型一旦自己在环境中滚动起来小误差会不断累积放大最后得到完全不同的轨迹。所以我在项目里很早就把闭环仿真评测提到了和离线训练几乎同等重要的位置。闭环评测的大致方法是让模型在仿真环境里控制自车前端输入可以是真实录制的感知序列也可以是完全合成的场景。仿真跑完统计接管率、碰撞率、驶离可通行区域次数、纵向舒适度等。这里有一个明显的坑需要注意如果仿真器本身的物理和交通流行为不太真实模型会学到“钻空子”的捷径比如在碰撞前一帧猛打方向盘或者贴着道路边界走。所以仿真难度的设计、以及对真实数据标签的校准是评测体系能否成立的前提。空谈指标没有意义指标必须和真实车上的表现有相关性。3.2 世界模型进训练闭环我踩过的一个大坑这次GTC‘26上世界模型几乎成了默认配置。很多团队展示了用扩散模型或者自回归模型生成“前方货车突然掉轮子”“暴雨夜里对向车开远光”这类高危场景再把生成的场景灌进训练集效果提升非常明显。我自己的实践里世界模型确实能补上真实采集很难碰到的长尾但前提是你能控制生成质量。我第一次用生成数据时踩了个大坑。当时把一批“极端场景”灌进训练集跑完发现模型的碰撞率不降反升。排查后才发现生成数据的分布太集中模型学到了一种非常狭窄的应对策略看到某种特殊视觉模式就猛打方向盘真实场景里只要有一点变化它就完全失效。后来我把生成数据控制在整体训练集的三成到四成以内并且每批生成数据都过一个质量过滤器用已有真值模型打分分数太低直接丢弃。另外生成场景的多样性指标也要持续监控防止模式坍缩如果生成的场景只集中在某几个embedding区间就要调整采样温度或者给生成模型加更细的场景约束。3.3 建立一套场景覆盖率矩阵比单一分数更管用评测体系不能只用一个综合分数。我现在会在核心实验报告里附一张场景覆盖率矩阵横轴是天气、道路类型、动态目标类型纵轴是一组典型危险场景每个格子里填该场景在训练集和评测集的样本量以及当前模型在该场景下的指标。这样做的好处是每次模型迭代你能快速看到哪个角落被优化了、哪个角落被遗忘了。如果综合得分涨了但矩阵里某个“前车切入”场景的表现掉了不少我会直接把它判为回归不让这个模型进发布流程。这套做法听着繁琐但在端到端时代几乎不可或缺。因为模型行为不是写死的规则你没法靠人工一段段去review它所有逻辑只能靠覆盖率和统计指标兜底。对我个人来说这种感觉就像是从“人工审计代码”变成了“给一个黑盒系统搭护栏”边界很重要。4. 算法工程师的日常变了从调网络到调配产线4.1 我的工作重心变化这一两年我的工作结构变化非常明显。以前大概八成的精力花在模型结构设计和loss调参上剩下二成处理数据。现在差不多反过来了大量时间花在数据挖掘、自动标注、评测回归、训练系统上。并不是说网络结构研究不重要而是成熟方案里基础backbone和训练trick都已经很完整大家拿到的底层模型并没有本质差距。真正能让你跑得快的是把一个场景从发现、到进入训练、再到评测回归的周期从几周压缩到几天。我见过好几个团队模型结构其实半斤八两但有的半年才更新一次版本有的不到一个月就能发一个新模型差距就在工程闭环上。数据闭环快、评测反馈快、迭代速度就快端到端时代拼的就是这个。按照我的经验如果你只是一个人带着小团队开始做这个方向不要想着一步到位建一个全国数据池。先想办法把一个小闭环跑通比如一个城市区域、十台车、每周采集十几万帧配上简单的难例筛选和自动标注跑三个月会收获一堆非常具体、可落地的工程经验比一开始就追求大而全的基建有用得多。4.2 从踩坑里总结的几个工程禁忌聊一些我踩过、或者亲眼见过的坑希望对同行有用。第一不要把手动规则和端到端模型混用太多。有些团队为了应急在模型外面挂一堆后处理逻辑比如“检测到某种标志就强制减速”。短期有效但会掩盖模型本身的问题而且会破坏端到端系统的一致性让后续评测变得不干净。端到端模型出问题应该回到数据和训练里去找原因而不是靠规则去掩盖否则越堆越乱。第二数据质量必须坚持抽检。自动标注和弱监督流水线上线之后我建议每周人工抽检比例不要低于百分之二把抽检发现的问题汇总成反馈再回灌给标注策略。这个数字不能因为业务忙就下调否则数据质量会悄悄滑坡等到上线前才发现想回头补数据就晚了。第三实验管理要上升到数据版本的高度。端到端的实验可复现性依赖数据集版本、训练配置、评测集版本这三个必须绑定。我团队内部每次训练都会自动记录一份类似“实验血缘”的文件写明用的是哪个数据版本、哪一版代码、哪一组配置、评测跑在哪个仿真器版本上。没有这一步所谓的效果对比就缺乏可信度出了问题也没法定位。4.3 给同行的一点建议如果你的团队资源有限我认真建议做垂直场景不要一上来就追全场景L4。比如只做园区低速接驳或者只做高速干线物流。垂直场景的数据分布会相对可控长尾问题少团队也更容易把闭环跑扎实。等你把某一条垂直线的小闭环做透再横向复制到其他场景会轻松得多。全场景智驾是巨头级团队的战场小团队的胜算在于比大团队更懂特定场景的痛点和数据细节然后把产线做成自己的核心能力。5. GTC‘26上的几个信号与我个人的判断5.1 世界模型从讲故事变成了上线干活世界模型在这次会上几乎是端到端系统的标配环节而且不再是单纯秀demo是明确接入训练和评测流程。我自己的理解是哪个团队能稳定生成多样化、物理合理、可控制难易度的场景谁就能在同等真实数据规模下跑出更稳的模型。未来智驾能力的竞争很大程度上会变成“场景工厂”的竞争你的世界模型能生成多少种高质量危险场景你的模型就有多强的应对能力。5.2 算力军备没停但重点从堆卡转向单位效率大会上很多人讨论车端芯片和云端集群的协同。我个人的观察是纯比算力大小已经没太多现实意义了大家更关注单位算力能跑多少token、多少层transformer以及端侧推理的延迟预算。一个模型能用更少算力在同样的延迟预算内完成推理通常比堆一个更大的模型更有价值因为整个训练闭环和发布周期会显著变短。对做工程的人来说这是更踏实的信号便捷效率永远比炫参数有意义。5.3 我的主线判断把这次大会的所有分享串起来我的判断是端到端时代的主线是建立一条自我迭代的闭环产线。具体拆成三个环节就是数据产线、训练系统、闭环评测。这三者必须放在一起优化只追求任何单项都会失衡。模型结构当然重要但它更像是产线里的一个可替换模块而不是决定胜负的唯一变量。谁的数据流更顺、训练系统更稳、评测反馈更快谁就更有机会把自动驾驶的安全与体验推向实用。最后聊点个人感受。我刚开始做自动驾驶那几年总觉得行业的核心是模型是算法创新好像谁发一个更漂亮的网络结构谁就能赢。这两年换了位置之后我反而越来越敬畏工程。端到端模型把系统问题揉进了一个巨大的非线性函数里你没法再靠看几段日志来判断它的行为是否正确只能靠数据、算力和评测这套闭环去约束它。这种变化是好事因为它把一个行业从“靠英雄”拉回到了“靠系统”。如果你也在做这个方向我建议少纠结一点SOTA结构多花时间把数据和评测的闭环跑通让模型在你的产线上真正转起来。这是我踩了那么多坑之后最想和同行分享的一句话。 
长河君 · 2026/10/22 19:30:52 · 阅读 1.2k 端到端自动驾驶的主线：数据、算力与评测闭环
GTC‘26开完那周我的朋友圈几乎被两件事刷屏一是各家端到端方案的效果视频二是各种“数据清洗流水线”和“训练监控面板”的截图。说实话作为一个从规则时代一路做到现在的算法工程师这个组合很有意思。前几年大家聚会聊的是网络结构、融合时序、损失函数去年开始换成了end-to-end、planning大模型到了今年你会明显感觉到话题的重心已经不是单个模型模块而是变成了一套系统能不能自己转起来。今天我就盯着“主线”这个话题聊聊我对这场大会的看法以及这一年多干端到端项目攒下的实际心得。先放结论端到端时代自动驾驶的主线根本不是某个更牛的模型结构而是让数据、算力、评测三者形成一条能自我迭代的闭环产线。谁先把这条产线跑通谁就掌握了主动权。1. 端到端不只是换模型是把研发方式重做一遍1.1 大家都在追结构的时候真正拉开差距的是数据产线做感知的时代我们还有相对清晰的模块边界检测、跟踪、预测、规划每一块有自己独立的指标和优化目标。端到端最大的变化是把这些边界全部打掉输入传感器数据直接出轨迹或控制指令。这意味着一个问题以前任务被拆解得足够小你可以单独把感知调好再让下游规划去接盘现在模型容量有限它到底关注什么、忽略什么完全由训练数据说了算。结构的作用被数据分布压制了这点不亲自动手做一轮很难体会到。我第一次真正意识到这个变化是在做一个“行人突然横穿”的场景优化时。当时团队花了很长时间调网络结构加时序模块、加关注机制成功把离线指标刷高结果很漂亮。但上车测试换一个红绿灯路口老问题照样出现。后来复盘发现训练集里那个场景本来只有几百帧模型根本没有足够的统计证据把这个行为内化等于它只是表面记住了那一段样本。换句话讲结构再先进数据分布不对模型只是在背样本而没有真正学会应对。这之后我把大量精力放到数据产线建设上。端到端模型对数据的需求不是单纯的数量多而是分布正确。你可以把模型想象成一个新司机如果驾校只教它在空旷直线路上开它考试也许能过但遇到真正的复杂交通流完全没有应对能力。我们要做的是让数据采集、挖掘、标注、回灌这个过程快起来。在GTC‘26的很多分享里大家都把这条产线画成环形数据从车上回来经过筛选进入训练训练出的模型再跑仿真评测仿真发现的新问题又变成数据回到库里。这个闭环能转多快才是一个团队真正的护城河。1.2 我复盘的一条难例挖掘链路难例挖掘不是新概念传统做法是人工盯数据遇到接管或者检测失败就顺手下载一段。这种方式在端到端时代远远不够因为我们需要持续地供给大批量、结构化、覆盖多维度的训练场景。我自己在项目里用过的通用链路大概是这个思路先建一个很大的无标注池子数据从车端传回后不急着标先让当前模型在本地推理一遍推理时记录每个片段的预测不确定性。对于模仿学习类的模型不确定性估计常用几种方法预测分布熵、多候选轨迹的离散度、预测logits的置信度。我用的比较多的是熵和梯度信息组合熵衡量模型“犹豫不决”的程度梯度代表“如果纠正这个预测模型能学到多少新东西”。两者结合比单纯看loss值可靠得多。import torch import torch.nn.functional as F def mine_hard_samples(model, frames, threshold0.75): model.eval() hard_indices [] with torch.no_grad(): for idx, batch in enumerate(frames): logits model(batch) # 某些端到端模型输出多模态轨迹概率 probs F.softmax(logits, dim-1) entropy -(probs * probs.log()).sum(dim-1).mean() # 还可以补充一个指标预测轨迹之间的平均位移误差 # 这里简化为用熵阈值挑样本 if entropy.item() threshold: hard_indices.append(idx) return hard_indices但这样筛出来的样本会有一个结构性问题全是难样本里最极端的一批分布偏了。所以挑完之后我还会做一步场景聚类把样本映射到特征空间比如用视觉embedding做聚类把“夜间路口”和“雨天高速匝道”分开再按场景数量做平衡采样保证新数据覆盖的维度和旧的分布大致衔接。这一步非常关键不做的话模型训着训着就只会处理极少数反直觉的情况正常路段上的性能反而往下掉。1.3 真值标注的成本压缩省下来的是真金白银数据挖掘出来只是第一步更关键的问题是label从哪来。端到端规划常用模仿学习真值本身就是“人类驾驶轨迹”这部分标注起来相对便宜回放司机的方向盘转角、加速度组成一条轨迹序列就好。但如果想加辅助任务或者做更复杂的可控性约束往往还需要语义、占用栅格、目标轨迹这类标签成本立刻上去了。我的经验是能上自监督和弱监督的地方别急着上人工。比如占用栅格可以用周围几帧点云的时序信息自动生成大部分阈值得靠统计标定不需要人一块块描。目标轨迹则可以用现成追踪器在无标签视频上先打一遍筛掉低置信度片段再送人工审核人工量能下降一半以上。代价是你得维护一套自动标注流水线以及配套的质检任务。但算总账仍然很划算尤其是在新场景快速涌入时标注速度决定了你的迭代速度人工太慢就只能靠更聪明的自动化策略补位。2. 训练侧才是隐形战场把GPU集群喂饱2.1 网络结构没那么玄幻瓶颈在数据供给端到端模型的结构各家其实大差不差。主干把多路传感器编码成特征时序模块做上下文聚合输出层生成轨迹或控制指令。真正让团队之间拉开差距的往往是训练系统能不能稳定高效地跑起来。这里说的不是只用哪个框架而是一连串工程细节数据加载是不是够快、并行卡之间通信有没有均衡、checkpoint存得太频繁会不会拖慢循环、以及训练到一半会不会莫名出现loss爆炸。我第一次带端到端项目时吃过大亏模型训了两周后来发现那段时间GPU利用率只有百分之四十几原因是数据加载进程成了瓶颈。图像和点云都做了精细化预处理batch稍微变大CPU worker就崩掉DataLoader退出后训练进程还在空转。后来我把预处理前移到离线阶段线上只保留轻量解码又加了共享内存预取才把GPU利用率长期稳定在百分之八十五以上。这件事之后我养成了一个习惯每次开新一轮训练前先盯着监控看半小时确认GPU利用率和数据供给曲线别只看loss下降就觉得一切正常。2.2 记忆回放和大规模训练的三板斧端到端训练和纯离线模型的典型差异是数据永远在滚动更新。新场景不断进库模型必须学新东西但又不能把旧能力全部忘掉所以记忆回放几乎成了标配。我的做法是维护一个小的回放buffer每次训练step里除了当前轮次的新数据同时混入一小部分历史样本。这个比例很敏感太高会让模型在旧场景里原地打转太低又压不住灾难性遗忘。我通常从百分之五开始调同时盯着验证集上旧场景的指标曲线掉了就往上加稳住了就往下减。除了回放还有几个工程细节值得写出来。第一学习率warmup要做长。端到端模型参数多起步时看到一个超大loss非常正常如果直接用稳态学习率去跑梯度爆炸只是时间问题。我一般线性warmup前3到5个epoch再用cosine或常数衰减。梯度clip也一直开着默认clip到1.0等训练稳定后再观察能不能放松。第二混合精度训练必须开但loss scale要盯着。fp16混合精度下loss scale如果总是被自动拉低说明梯度里有问题大概率是数据或前处理出了状况先查这两个地方。第三checkpoint分级保存。大模型训练动辄几天中途崩溃是常态至少每固定步数存一个可恢复的版本。我团队里现在每个checkpoint都会带上数据版本号、代码commit号和训练配置否则出了实验对比问题你根本不知道模型是在什么环境里长大的。2.3 Loss怎么配端到端从来不是单一损失端到端规划的损失函数通常是一个组合。我项目里的典型配置包括模仿学习主损失预测轨迹和人类驾驶轨迹的负对数似然或者L2距离加角度惩罚辅助语义损失比如占用栅格上的cross entropy帮助模型建立空间理解还有强化或安全项对碰撞、压线、急刹给出惩罚梯度不过这部分一般不是从第一步就加入。权重不是写死不变的。我们试过在训练初期把模仿学习权重设为1.0辅助损失设得很小等到损失降到一定程度再把安全项权重拉上来。这种训练计划表需要连续盯好几轮实验才能定下来。这里有一个反直觉的经验辅助任务权重如果太大主干网络的特征表达会更多偏向语义重建而忽略决策需要的时序关联。所以每次加辅助头都要回看主任务指标不能被辅助任务的漂亮收敛曲线迷惑。如果主任务开始掉点就调低辅助权重让模型重新聚焦到“怎么开车”上。3. 评价和生成世界模型不只是讲故事3.1 开环指标好看不代表车真的会开端到端时代最危险的错觉是觉得离线指标好就等于车能开好。L2误差、模仿准确率这些开环指标只说明模型在给定真值轨迹的条件下预测得准但模型一旦自己在环境中滚动起来小误差会不断累积放大最后得到完全不同的轨迹。所以我在项目里很早就把闭环仿真评测提到了和离线训练几乎同等重要的位置。闭环评测的大致方法是让模型在仿真环境里控制自车前端输入可以是真实录制的感知序列也可以是完全合成的场景。仿真跑完统计接管率、碰撞率、驶离可通行区域次数、纵向舒适度等。这里有一个明显的坑需要注意如果仿真器本身的物理和交通流行为不太真实模型会学到“钻空子”的捷径比如在碰撞前一帧猛打方向盘或者贴着道路边界走。所以仿真难度的设计、以及对真实数据标签的校准是评测体系能否成立的前提。空谈指标没有意义指标必须和真实车上的表现有相关性。3.2 世界模型进训练闭环我踩过的一个大坑这次GTC‘26上世界模型几乎成了默认配置。很多团队展示了用扩散模型或者自回归模型生成“前方货车突然掉轮子”“暴雨夜里对向车开远光”这类高危场景再把生成的场景灌进训练集效果提升非常明显。我自己的实践里世界模型确实能补上真实采集很难碰到的长尾但前提是你能控制生成质量。我第一次用生成数据时踩了个大坑。当时把一批“极端场景”灌进训练集跑完发现模型的碰撞率不降反升。排查后才发现生成数据的分布太集中模型学到了一种非常狭窄的应对策略看到某种特殊视觉模式就猛打方向盘真实场景里只要有一点变化它就完全失效。后来我把生成数据控制在整体训练集的三成到四成以内并且每批生成数据都过一个质量过滤器用已有真值模型打分分数太低直接丢弃。另外生成场景的多样性指标也要持续监控防止模式坍缩如果生成的场景只集中在某几个embedding区间就要调整采样温度或者给生成模型加更细的场景约束。3.3 建立一套场景覆盖率矩阵比单一分数更管用评测体系不能只用一个综合分数。我现在会在核心实验报告里附一张场景覆盖率矩阵横轴是天气、道路类型、动态目标类型纵轴是一组典型危险场景每个格子里填该场景在训练集和评测集的样本量以及当前模型在该场景下的指标。这样做的好处是每次模型迭代你能快速看到哪个角落被优化了、哪个角落被遗忘了。如果综合得分涨了但矩阵里某个“前车切入”场景的表现掉了不少我会直接把它判为回归不让这个模型进发布流程。这套做法听着繁琐但在端到端时代几乎不可或缺。因为模型行为不是写死的规则你没法靠人工一段段去review它所有逻辑只能靠覆盖率和统计指标兜底。对我个人来说这种感觉就像是从“人工审计代码”变成了“给一个黑盒系统搭护栏”边界很重要。4. 算法工程师的日常变了从调网络到调配产线4.1 我的工作重心变化这一两年我的工作结构变化非常明显。以前大概八成的精力花在模型结构设计和loss调参上剩下二成处理数据。现在差不多反过来了大量时间花在数据挖掘、自动标注、评测回归、训练系统上。并不是说网络结构研究不重要而是成熟方案里基础backbone和训练trick都已经很完整大家拿到的底层模型并没有本质差距。真正能让你跑得快的是把一个场景从发现、到进入训练、再到评测回归的周期从几周压缩到几天。我见过好几个团队模型结构其实半斤八两但有的半年才更新一次版本有的不到一个月就能发一个新模型差距就在工程闭环上。数据闭环快、评测反馈快、迭代速度就快端到端时代拼的就是这个。按照我的经验如果你只是一个人带着小团队开始做这个方向不要想着一步到位建一个全国数据池。先想办法把一个小闭环跑通比如一个城市区域、十台车、每周采集十几万帧配上简单的难例筛选和自动标注跑三个月会收获一堆非常具体、可落地的工程经验比一开始就追求大而全的基建有用得多。4.2 从踩坑里总结的几个工程禁忌聊一些我踩过、或者亲眼见过的坑希望对同行有用。第一不要把手动规则和端到端模型混用太多。有些团队为了应急在模型外面挂一堆后处理逻辑比如“检测到某种标志就强制减速”。短期有效但会掩盖模型本身的问题而且会破坏端到端系统的一致性让后续评测变得不干净。端到端模型出问题应该回到数据和训练里去找原因而不是靠规则去掩盖否则越堆越乱。第二数据质量必须坚持抽检。自动标注和弱监督流水线上线之后我建议每周人工抽检比例不要低于百分之二把抽检发现的问题汇总成反馈再回灌给标注策略。这个数字不能因为业务忙就下调否则数据质量会悄悄滑坡等到上线前才发现想回头补数据就晚了。第三实验管理要上升到数据版本的高度。端到端的实验可复现性依赖数据集版本、训练配置、评测集版本这三个必须绑定。我团队内部每次训练都会自动记录一份类似“实验血缘”的文件写明用的是哪个数据版本、哪一版代码、哪一组配置、评测跑在哪个仿真器版本上。没有这一步所谓的效果对比就缺乏可信度出了问题也没法定位。4.3 给同行的一点建议如果你的团队资源有限我认真建议做垂直场景不要一上来就追全场景L4。比如只做园区低速接驳或者只做高速干线物流。垂直场景的数据分布会相对可控长尾问题少团队也更容易把闭环跑扎实。等你把某一条垂直线的小闭环做透再横向复制到其他场景会轻松得多。全场景智驾是巨头级团队的战场小团队的胜算在于比大团队更懂特定场景的痛点和数据细节然后把产线做成自己的核心能力。5. GTC‘26上的几个信号与我个人的判断5.1 世界模型从讲故事变成了上线干活世界模型在这次会上几乎是端到端系统的标配环节而且不再是单纯秀demo是明确接入训练和评测流程。我自己的理解是哪个团队能稳定生成多样化、物理合理、可控制难易度的场景谁就能在同等真实数据规模下跑出更稳的模型。未来智驾能力的竞争很大程度上会变成“场景工厂”的竞争你的世界模型能生成多少种高质量危险场景你的模型就有多强的应对能力。5.2 算力军备没停但重点从堆卡转向单位效率大会上很多人讨论车端芯片和云端集群的协同。我个人的观察是纯比算力大小已经没太多现实意义了大家更关注单位算力能跑多少token、多少层transformer以及端侧推理的延迟预算。一个模型能用更少算力在同样的延迟预算内完成推理通常比堆一个更大的模型更有价值因为整个训练闭环和发布周期会显著变短。对做工程的人来说这是更踏实的信号便捷效率永远比炫参数有意义。5.3 我的主线判断把这次大会的所有分享串起来我的判断是端到端时代的主线是建立一条自我迭代的闭环产线。具体拆成三个环节就是数据产线、训练系统、闭环评测。这三者必须放在一起优化只追求任何单项都会失衡。模型结构当然重要但它更像是产线里的一个可替换模块而不是决定胜负的唯一变量。谁的数据流更顺、训练系统更稳、评测反馈更快谁就更有机会把自动驾驶的安全与体验推向实用。最后聊点个人感受。我刚开始做自动驾驶那几年总觉得行业的核心是模型是算法创新好像谁发一个更漂亮的网络结构谁就能赢。这两年换了位置之后我反而越来越敬畏工程。端到端模型把系统问题揉进了一个巨大的非线性函数里你没法再靠看几段日志来判断它的行为是否正确只能靠数据、算力和评测这套闭环去约束它。这种变化是好事因为它把一个行业从“靠英雄”拉回到了“靠系统”。如果你也在做这个方向我建议少纠结一点SOTA结构多花时间把数据和评测的闭环跑通让模型在你的产线上真正转起来。这是我踩了那么多坑之后最想和同行分享的一句话。