企业官网建设流程全解析

简介：《2024端到端自动驾驶行业发展及技术落地报告》面向自动驾驶从业者、研究者与投资人士，系统梳理端到端技术从行业共识走向量产落地的关键问题。报告辨析端到端与大模型、世界模型、纯视觉方案的关系，提出感知“端到端”、决策规划模型化、模块化端到端与One Model端到端四阶段划分，并分析主机厂、算法公司、生成式AI公司及学术机构的进展。内容还讨论数据与算力需求、测试验证、组织资源投入等落地挑战，展望模块化端到端2025年上车及对通用机器人的启发。共1个PDF文件，压缩包约4.49MB，便于检索与阅读。已有224人学习，适合用来快速建立行业框架、把握技术路线分歧与投资机遇，并为企业技术创新和业务布局提供参考。

1. 端到端不是“一个模型”：定义之争先于技术之争

端到端自动驾驶这两年成了行业共识，但这份共识里藏着分歧。一份面向 30 余位一线专家的行业调研里，约九成受访者表示所在公司已投入端到端研发，可一旦问到落地时间、技术终局和行业格局，答案几乎五五开——一半人认为两到五年内上车，另一半把时间表推到五年开外；一半人认为端到端是终局方案，另一半只当它是备选之一。这种“战略一致、战术分裂”的状态，根子不在工程能力，而在定义：有人把决策规划模块换成神经网络就自称端到端，有人坚持只有单一网络从传感器直出轨迹才算。定义不统一，讨论就没法对齐。这份报告的价值恰在这里——它给出两条可判定的标准：感知信息无损传递、系统可全局优化。围绕这两条，架构演进被切成四段，很多争议当场就散了。

2. 四阶段演进：梯度能不能穿过模块边界，才是分水岭

把自动驾驶架构拆成四段，不是为了分类学上的整齐，而是因为每一段背后有一条硬约束在变：模块之间的接口传的是什么，以及误差信号能不能从最终输出一路回流到最前端的传感器编码器。这两件事决定了系统的优化范围是局部的还是全局的，也决定了泛化能力的上限在哪里。理解了这条主线，再看那些“某某方案算不算端到端”的争论，就变成了一个可以查证的技术问题，而不是立场问题。

2.1 前两个阶段：把规则换成模型，接口还是“人话”

传统自动驾驶架构是从机器人领域继承来的，感知、定位、预测、决策规划、控制五个模块各司其职。感知用摄像头、激光雷达、毫米波和超声波去检测车辆、行人、交通标志，输出的是人类定义好的抽象：障碍物框、车道线、可行驶区域。这套划分的好处很实在——每个模块可以独立开发、独立验证，出了问题能快速定位到是哪一环。代价同样实在：整个系统的灵活性和泛化性被模块边界锁死了。

第一阶段叫感知“端到端”。多传感器融合的 BEV 视角加上 Transformer 和跨传感器注意力机制，让感知模块内部先实现了模块级的端到端，检测精度和稳定性比上一代明显提升。但决策规划仍然是规则驱动，状态机加规则库，工程师手工维护。第二阶段是决策规划模型化：预测、决策、规划被合并进同一个神经网络，应对复杂路况的上限确实提高了——模型不够大就扩模型重训，比维护一个越来越臃肿的规则库容易得多。

问题出在接口上。这两个阶段里，感知和规划之间传递的仍然是“人话”：障碍物在哪、边界在哪。为了让每个模块能独立训练和验证，接口必须统一抽象成人类可理解的形式。这个设计带来的便利是真的，信息损失也是真的——把立体的、连续的真实世界压缩成几个框和几条线，材质、光照、未定义类别的异形障碍物、其他车辆意图的模糊性，全在压缩过程中被丢掉了。

2.2 模块化端到端：接口从人类定义退回特征向量

第三阶段的改动看起来很小，实质上很关键。感知模块不再输出人类定义的检测结果，而是直接给出稠密特征向量；预测决策规划的综合模型基于这组特征输出运动规划结果。接口从“人类可理解的抽象”退回“网络自己学出来的表示”，信息不再被强制压缩成几个语义标签。工程师血泪经验里最典型的一类 bug——感知明明看到了，但因为目标类别不在定义集合里而被过滤掉——在这个结构下有了被规避的可能。

更关键的变化在训练侧：两个模块不能再独立训练，必须通过跨模块的梯度传导联合优化。这条约束是判定的硬指标。一个方案如果感知和规划各自 backward、各自更新参数，那它就不是模块化端到端，无论宣传口径怎么写。跨模块梯度传导保证了所有训练信号都在为同一个最终目标服务，也就是全局优化，而不是各自模块内部的局部最优。

2.3 One Model：模块边界消失之后

第四阶段连感知、决策规划的功能划分都不要了，原始信号输入直接对应规划轨迹输出。有意思的是，这个概念提得比模块化端到端还早——2016 年就有芯片厂商用卷积加全连接的简单结构做过单网络端到端 Demo，输入是前视图像，输出是转向角。但那个方案规模太小、结构太简单，只能应付高速或简单路况，停留在小规模验证，离量产的可靠性差得远。

它重新回到视野，靠的是两件事：Transformer 架构的成熟，以及车端算力涨到能跑 0.1B 到 1B 参数量级的网络。理论上限更高，原因在于训练过程能覆盖更广范围的数据——真实世界里关于道路、交互、因果的所有认知都可能被吸收进同一个模型，泛化效果自然更好。而且这类架构对环境和物体交互的理解具有很强的通用性，不只服务于车，也为其他具身智能应用打了底子，最终指向跨领域模型的统一。代价是训练和调试复杂度显著上升，出问题时排查难度也水涨船高，黑匣子的味道更浓了。

2.4 一段伪代码看清“梯度断点”在哪

概念说得再清楚，不如看两行代码。下面用 PyTorch 风格写出阶段二和阶段三的核心差异，重点只有一个：.detach()有没有被调用。

import torch # 阶段二：决策规划模型化 # 感知与规划是两个独立训练的模块，接口是人类定义的检测结果 def train_stage2(sensor_input, gt_det, gt_traj): det_out = perception(sensor_input) # 输出检测框、车道线等语义结果 det_out = det_out.detach() # 关键一行：切断梯度，规划侧只拿到数值 traj = planner(det_out) # planner 看不到 perception 的计算图 loss_det = detection_loss(det_out, gt_det) loss_plan = planning_loss(traj, gt_traj) loss_det.backward() # 只更新 perception 的参数 loss_plan.backward() # 只更新 planner 的参数 # 两个 loss 各自独立反传，系统层面是局部优化

# 阶段三 / 阶段四：端到端 # 接口是特征向量，且不允许 detach，梯度必须能一路回流 def train_e2e(sensor_input, gt_traj): feat = perception_encoder(sensor_input) # 输出稠密特征，不做语义抽象 traj = planner_head(feat) # planner 直接消费特征 loss = planning_loss(traj, gt_traj) if aux_head is not None: loss = loss + 0.1 * aux_loss(aux_head(feat), gt_aux) # 辅助监督，权重需调 loss.backward() # 一次反传，编码器和规划头同时被更新 # 感知侧学到的表示，是被"最终轨迹好不好"这个目标直接塑造的

第一段代码里那句.detach()就是梯度断点。有了它，感知模块的优化目标永远是“检测得更准”，而不是“让最终轨迹更安全”。这两个目标在多数时候一致，在长尾场景里经常冲突：一个置信度 0.6 的误检，从检测指标看是负分，但如果规划模块能结合上下文判断它是反光造成的虚影并平滑绕开，对最终驾驶行为反而是正贡献。阶段二的结构没法把这种反馈传回去，阶段三可以。

第二段代码里的aux_loss权重是实际工程里需要反复调的超参。辅助监督太强，感知侧会被拽回“刷检测指标”的老路；太弱，联合训练早期梯度信号稀疏，收敛慢得让人怀疑人生。常见的做法是前若干轮给较大权重做 warmup，之后逐渐衰减到很小的值，让主损失主导。

2.5 全局优化为什么值钱：一个误检被吸收的例子

举个具体推演。雨夜，路面积水反射远处灯光，感知模块在车道中央给出一个低置信度障碍物。阶段二的处理链条是：这个结果传给规划模块，规划模块没有上下文去质疑它，保守起见减速甚至刹停，一次幽灵刹车就此产生。感知模块事后复盘，这次误检会被记为负样本，下次训练让它更保守——但保守的方向是错的，因为它不知道自己造成了什么后果。

端到端结构下，这次减速会体现在最终轨迹的损失里，梯度会沿着规划头一路回流到感知编码器，告诉它“这组特征导致的决策是差的”。感知侧学到的不是“别检测亮斑”，而是“在这个上下文里，这种特征不该被当成障碍物”。这种从行为结果反向塑造感知表示的机制，就是全局优化最朴素的价值。它也是模块化端到端和 One Model 共享的核心特征：结构可以不同，梯度必须连通。

3. 概念辨析：大模型、世界模型、纯视觉与端到端到底什么关系

端到端这个词热度上来之后，被拉来当同义词的概念越来越多：大模型、世界模型、纯视觉方案。三个词各自都对，但跟端到端的关系都不是等价关系。混着用会直接导致技术选型跑偏——比如以为上了大模型就是端到端，或者以为端到端必须砍掉激光雷达。把这几组关系拆开看，能省掉不少无效争论。

3.1 端到端 ≠ 大模型：参数规模是手段，梯度连通才是定义

大模型关注的是参数数量和由此产生的涌现能力，端到端关注的是结构上梯度可传导、系统可全局优化。这两件事没有必然联系。一个几百兆参数的模型，只要满足感知信息无损传递和跨模块梯度传导，它就是端到端；一个几十亿参数的模型，如果内部还在用人类定义的接口分段训练，它就不是。

目标上的差别更明显。通用大模型是多面手，参数规模大、训练数据类型广、应用范围宽，对可解释性和可靠性的要求相对宽松。端到端自动驾驶的目标窄得多也硬得多：让车安全地从 A 开到 B，基于标注数据训练，对系统可靠性要求极高。一个出错只是回答得不好，一个出错是要命的。

还有一层容易被忽略：自动驾驶语境里的“大模型”，跟自然语言处理领域的“大”根本不是一个量级。车端算力目前较大的也就几百 TOPS 级别，下一代量产平台规划中的算力也远达不到动辄 10B 甚至上百 B 的需求。所以车上的所谓大模型，实际普遍小于 1B，这个“大”是相对于原来感知系统里几百万参数的小模型而言的。不过趋势是明确的：车端模型大型化和 Transformer 化会同时发生，随着端侧算力持续上涨，两个概念在自动驾驶领域的交叉会越来越多——尤其当端到端需要解决规则方案束手无策的复杂场景时，那种依赖网络推理能力的需求，确实和大模型涌现出来的能力有相似之处。

3.2 世界模型的两条用法：数据生成器，还是直接当策略网络

世界模型指的是能学习和揭示真实世界物理规律、并据此预测未来一段时间视频的模型。它跟端到端有两种关系，行业内两种观点都有，而且都成立。

第一种用法是把世界模型当数据生成器。它天生具备根据外部条件生成视频、生成与其他车辆交互情况的能力，产出的合成数据可以直接喂给端到端模型训练。价值在于覆盖采集车拿不到的场景：碰撞、极端天气、长尾异形障碍物。这些数据靠实车采集成本高到不现实，靠模型在线生成几乎没有离线开销。对训练和测试覆盖度的提升，是传统仿真器很难追上的。

第二种用法是对世界模型做小幅改造，加几条输出链路，直接变成 One Model 端到端。理由也站得住：世界模型本身就得理解周围环境、理解交互、预测其他交通参与者行为，这些感知和预测的时序信息已经是决策规划的基础；它能在推理和理解上做到这个程度，说明内部已经抽到了物理规律，那就具备基于已有信息做推理决策的能力。初步探索已经验证了可行性，短期制约在车端算力撑不起大世界模型。后续能不能靠蒸馏或降秩在保住世界理解能力的前提下把模型裁到车端可跑，得看端侧硬件的迭代节奏。

3.3 纯视觉不是端到端的隐含前提

“端到端只能基于纯视觉”，这个说法流传很广，但它是错的。端到端对车端传感器架构几乎不造成任何影响，因为 BEV 也好、端到端也好，从传感器处理的角度都属于前融合方案，在传感器选择上相当灵活。

误解的来源有现实基础：当前视觉 BEV 的感知和跟踪架构已经是业界主流，为了更好的预测效果和更多感知信息传递，多数端到端方案直接继承了视觉 BEV 作为感知模块再往上延伸。看到的现象是“端到端方案大多用纯视觉”，被误读成了“端到端必须用纯视觉”。真正的判断依据是性价比：如果激光雷达成本大幅下降，或者 4D 毫米波的点云数量和质量快速提升，把其他类型传感器引入整个网络的感知基础是完全顺理成章的。前融合的架构本来就不排斥多模态输入。

提示：评估一个端到端方案时，先问接口传的是什么、梯度能不能跨模块回流，再问用了哪些传感器。前一个问题决定它是不是端到端，后一个只决定它的成本结构和感知上限。

4. 落地账本：数据、算力、测试验证三笔账怎么算

技术路线想清楚了，接下来是掏钱的部分。端到端落地要过的关不止一道：技术路线还没形成最佳实践、训练数据的重要性被抬到前所未有的位置、训练算力需求急剧上升、现有测试验证方法基本失效、组织资源投入需要重塑。这几件事里，有明确数量级可以先算一算的是数据和算力，最容易被低估的是测试验证。

4.1 数据：从“标注框”到“驾驶行为片段”，计量单位变了

模块化时代，数据的核心是标注：一帧图像上有几个框、几条车道线、每类的属性是什么。端到端时代，训练信号是最终轨迹，模型需要的是“在这个场景下，人类驾驶员是怎么开的”这种带时序的行为片段。计量单位从“帧”变成“clip”，标注从框变成了轨迹和驾驶意图，成本结构完全变了。

先算存储：

# 以 clip 为单位估算原始数据规模 clip_seconds = 20 # 单个片段时长 cams = 6 # 相机路数 fps = 30 bytes_per_frame = 300_000 # 压缩后单帧约 300KB per_clip = clip_seconds * cams * fps * bytes_per_frame print(f"单 clip 约 {per_clip/1e9:.2f} GB") # 单 clip 约 1.08 GB print(f"百万 clip 约 {1e6 * per_clip / 1e15:.1f} PB") # 约 1.1 PB

百万级 clip 对应 PB 级存储，这还只是原始数据。端到端对数据的要求有四层，每一层都能卡住人：数据量要够大，不然模型学不到长尾；数据标注要够准，轨迹标注错了等于教模型危险动作；数据质量要够高，采集设备的标定漂移、时间同步误差都会变成噪声；数据分布要够合理，采集车队如果常年跑高速，城市复杂路口的数据密度就上不去。

最后一条最隐蔽。数据分布失衡不会在训练 loss 上暴露，只会在特定场景的接管率上暴露，而那个场景可能几个月才遇到一次。常见的对策是按场景做重采样，给稀缺场景更高权重，或者用世界模型合成补齐。

4.2 算力：千卡到万卡是怎么估出来的

行业头部玩家的训练算力储备普遍在千卡到万卡级，这个数字不是拍脑袋的。用累计口径粗算一下就能对上：

# 粗估一个完整端到端训练周期的累计卡时 # 口径包含正式训练 + 消融实验 + 失败重跑，不是单次训练的净算力 tokens_per_sample = 120_000 # 6 路相机，每路约 2 万 token batch_size = 256 total_steps = 1_000_000 # 累计步数 params = 1e9 # 目标模型量级约 1B flops_per_token = 6 * params # 前向 + 反向约等于 6 倍参数量 total_flops = tokens_per_sample * batch_size * total_steps * flops_per_token card_flops = 1e15 * 0.4 # 单卡峰值 1000 TFLOPS，按 40% 利用率折算 card_hours = total_flops / card_flops / 3600 print(f"累计约 {total_flops/1e21:.0f} ZFLOPs，约 {card_hours:.0f} 卡时") # 累计约 184 ZFLOPs，约 128000 卡时

十二万卡时，用一千张卡跑大约五天，用一百张卡要跑将近两个月。而端到端项目的真实节奏是反复迭代：改一次网络结构、换一次数据配比、调一次损失权重，都得重新跑一轮。把消融和失败重跑算进去，千卡级储备就变成了起步线，万卡级才有迭代空间。

参与估算的参数都可以替换成自己的实际值。tokens_per_sample取决于相机路数和输入分辨率，params取决于目标模型大小，card_flops的利用率系数在 30% 到 50% 之间浮动，取决于并行策略和通信开销。模型从 1B 涨到 10B，卡时直接乘十，这就是车端模型大型化趋势背后的成本压力。

4.3 测试验证：规则化的用例库为什么失效

这一项最容易被低估。传统验证方法是基于规则的：给定一个场景，检查规划输出是否满足一组约束，比如跟车距离不小于多少、变道时横向加速度不超过多少。这套方法的前提是系统行为可预测、可分解，而端到端模型恰恰不是——它的输出是连续的轨迹，行为由数据分布塑造，用规则去卡它的中间结果基本没有意义。

更麻烦的是覆盖度问题。端到端模型的强项是泛化，能在没见过的场景里做出合理决策，但这也意味着它的行为空间比规则系统大得多。一个用例库能覆盖规则系统可能出现的分支，却覆盖不了一个学习系统的行为分布。行业现在缺的不是更多用例，是一套新的方法论和工具链：怎么定义端到端系统的通过标准、怎么构建有统计意义的场景采样、怎么用世界模型生成对抗样本来压边界。

4.4 组织：把资源从算法侧挪到数据侧

技术挑战之外还有一层更软的东西。端到端要求组织架构重塑，资源投入要向数据侧倾斜，这对现有模式是实打实的冲击。模块化时代，团队按感知、规划、控制划分，各自的 KPI 清晰；端到端时代，模块边界消失，团队边界也得跟着动，数据团队从支撑角色变成核心角色，标注、采集、清洗、场景挖掘的投入占比要显著上升。这件事在技术评估里常常被忽略，但它往往是项目延期最真实的原因。

5. 避坑与排查：端到端项目里最容易翻车的几件事

从模块化往端到端迁移，最常见的失败不是模型训不出来，而是训出来了但没人知道它到底行不行。下面几条是从行业实践里反复出现的坑，每条都按现象、原因、解决三段写清楚。

5.1 训练 loss 一路下降，接管率纹丝不动

现象：联合训练跑了几十万步，轨迹损失降得很漂亮，实车测试的接管率却没改善，甚至某些场景变差。

原因：评估指标体系还停留在模块化时代。用感知的 mAP、检测召回这些指标去衡量端到端模型，等于用上一代的尺子量新东西。端到端模型的感知表示不再是人类可解释的，中间指标和最终行为之间没有稳定映射。

解决：把评估重心整体挪到闭环指标上——接管里程、无接管行程占比、特定场景通过率，再补充一组开环的轨迹误差指标做辅助参考。中间层的可视化只用来排查异常，不用来做验收标准。

5.2 联合训练跑着跑着，感知侧“崩了”

现象：端到端联合训练几轮之后，感知编码器的特征分布剧烈漂移，辅助任务的指标断崖式下跌，主任务也没跟着变好。

原因：梯度尺度不匹配。规划损失的梯度回传到感知编码器时，量级可能比原来感知侧自己的损失大一到两个数量级，相当于用一个大锤去微调一个精密零件。学习率如果还按模块化时代的配置来，感知侧直接被带偏。

解决：分层设置学习率，编码器侧用小学习率或者加梯度裁剪；辅助损失用 warmup 加权，前若干轮给较大权重稳住表示学习，之后逐步衰减让主任务主导；同时监控编码器特征的统计量，漂移超阈值就中断排查。

5.3 模型上车跑不动，帧率掉到个位数

现象：离线评测一切正常，部署到车端推理延迟高得离谱，实时性完全不达标。

原因：直接拿训练时的完整模型上车，没考虑车端算力约束。几百 TOPS 的算力听起来不少，但端到端模型要处理多路高分辨率输入，还要维持足够的控制频率，余量远比想象中薄。

解决：训练阶段就要带着部署约束走。先确定目标平台的有效算力和延迟预算，反推模型规模上限；再用蒸馏、剪枝、量化把模型压到这个预算内，压完必须重新做闭环评测，因为压缩带来的性能损失在不同场景下分布很不均匀。这件事没有后悔药，只能前置。

5.4 实车表现和仿真结果对不上

现象：仿真里跑得好好的场景，实车上频繁出问题，而且复现困难。

原因：仿真环境和真实世界的分布差异。传统仿真器靠手工建模，传感器噪声、光照变化、其他交通参与者的行为模式都经过了简化，模型在简化世界里学到的策略迁移到真实世界自然打折。另一个常被忽略的点是标定漂移——采集车跑久了，相机外参偏移几度，训练数据里的几何关系就全错了。

解决：引入基于世界模型的仿真，让场景生成更贴近真实分布；同时把标定检查做成采集流程的强制环节，每次采集前后各校一次，漂移超阈值的数据整段丢弃。数据质量问题的排查成本远高于采集成本，宁可在源头卡住。

5.5 长尾场景的数据永远不够

现象：常规场景的表现稳步提升，但极端天气、异形障碍物、罕见交通博弈这些场景的通过率长期停滞。

原因：实车采集的长尾场景密度天然极低，靠堆采集里程去覆盖，边际收益衰减得很快。

解决：把数据闭环建起来。实车遇到的长尾场景自动触发回传，进入场景库；再用世界模型针对这些场景做变体生成，把单个案例扩成一批。同时按场景难度做重采样，让稀缺场景在训练 batch 里的占比高于其自然分布，避免被常规场景淹没。

6. 设计取舍：车载算力和可解释性真的是瓶颈吗

行业里有两个流传很广的判断，我一开始也信：车端算力不够，跑不了端到端；模型没有可解释性，出了事故没法归因，量产过不了关。把这两件事拆开算过之后，结论反过来了——它们都不是端到端落地的真实瓶颈。

车端算力的账其实好算。前面估过，车端目标模型量级在 0.1B 到 1B 之间，不是通用大模型那个尺度。几百 TOPS 的现有平台，配合量化和蒸馏，跑 1B 以内的模型是有余量的；下一代量产平台的算力规划还在往上走。真正的约束不在峰值算力，在散热和功耗——车规环境的功率预算摆在那，算力堆上去，热管理就得跟上。这是个工程问题，有明确的解决路径，不是原理性障碍。反过来说，如果谁的计划是把几十 B 的模型塞进车端，那确实是瓶颈，但那是方案选错了，不是端到端这个方向错了。

可解释性的账更微妙。端到端模型是黑匣子，这个事实没法否认。但“不可解释”不等于“不可验证”。验证一个系统，不一定非要理解它的每一个内部决策，可以通过行为层面的统计来建立信心：在多大的场景分布上、以什么样的置信度、达到什么样的接管率。这条路子在航空和工业控制里走了几十年，不是新发明。具体手段上，中间特征可以做可视化异常检测，世界模型可以生成反事实场景——“如果当时那个行人早出现半秒，系统会怎么反应”，这类问题规则系统反而不好回答，因为它得靠人去推演规则分支。

所以真正卡住端到端的，是测试验证方法论和场景覆盖度的工程化能力，以及组织能不能把资源真正挪到数据侧。可解释性是个需要长期投入的研究方向，但它不构成量产的前置门槛；算力是个需要持续投入的工程约束，但它有明确的数量级上限。把这两件事当成拦路虎，容易导致资源投错地方。

从那以后，我每次评估一个端到端方案，都强制自己先走一遍这三问：接口传的是人类定义还是特征向量、梯度断点在哪里、闭环指标怎么定义。这三问答不上来的方案，宣传口径再漂亮我也不信。希望帮到你。

这份报告的完整版本把四阶段演进的架构图、主要参与者的技术路线对比、落地挑战的分项拆解，以及端到端与通用机器人相互启发的三段式推演都摊开写了，配了几十张架构示意和趋势预测图，比这里能展开的细节密得多。想要拿到原始文档，方式在资源简介里。

本文还有配套的精品资源，点击获取