企业官网建设流程全解析

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, threshold=0.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结构，多花时间把数据和评测的闭环跑通，让模型在你的产线上真正转起来。这是我踩了那么多坑之后，最想和同行分享的一句话。