企业官网建设流程全解析

简介：这份报告由辰韬资本、南京大学上海校友会自动驾驶分会与九章智驾联合撰写，聚焦端到端自动驾驶这一行业共识，面向自动驾驶从业者、研究者及投资机构，系统梳理了2023年以来端到端技术从概念兴起、玩家布局到量产落地的完整脉络。报告基于对30余位行业一线专家的访谈，提出一套可供参考的定义与术语体系，将技术架构划分为感知端到端、决策规划模型化、模块化端到端和One Model端到端四个阶段，并辨析其与大模型、世界模型、纯视觉方案的关系。内容详解UniAD、DriveDreamer、GAIA-1等关键技术进展，分别梳理主机厂、算法公司、生成式AI公司和学术机构的代表成果，同时直面训练数据、算力需求、测试验证、组织资源投入等落地挑战；针对车端算力不足与可解释性两类质疑也给出相反辨析。资源为1个PDF文件，压缩包约4.49MB，已有222人学习使用，适合希望快速把握端到端行业动态、技术路线差异与投资机遇的读者深度阅读。

1. 端到端自动驾驶在 2024 年真正落地了吗：先分清“量产叙事”和“工程现实”

2024 年，智能驾驶发布会几乎都在讲端到端自动驾驶，但真正落到量产车的方案其实分成好几种：有的只是把感知和预测合并成一个网络，有的则从传感器输入直接输出自车轨迹，规划完全交给神经网络。差别看似在架构图上，实际牵动数据、标注、仿真、车端算力一整条产业链，选错路线很难靠后期优化补救。这篇笔记把端到端自动驾驶的行业发展现状和技术落地路径拆开讲：先分清楚不同玩家的路线差异，再讲透一体化模型和数据闭环怎么搭，最后落到车端部署参数和从仿真到真车的踩坑记录。适合正在评估端到端路线、负责量产智驾算法或要做技术选型的同行，按这个框架对照自己手头的项目，会少走很多弯路。

2. 端到端自动驾驶的行业格局：三类玩家、两条路线与算力分水岭

2.1 三类玩家在 2024 年的位置：量产交付、全无人运营与方案供应商的路线差异

2024 年端到端自动驾驶的赛道里，玩家大致能分成三类，每一类对“端到端”的定义都不一样，这是行业报告里最容易混淆的地方。

第一类是量产车企。它们的目标是让城市导航辅助驾驶在更多城市开放，端到端主要用来解决复杂路口博弈、无保护左转、人车混行这类规则规划很难写干净的场景。常见做法是感知和预测走端到端，规划层仍然保留规则或者优化器做安全约束。这类玩家最在意的是“能否按期交付”和“接管率能不能压下来”，对模型黑匣子的容忍度很低。

第二类是跑高阶无人驾驶运营的 Robotaxi 公司。它们的终局是去掉安全员，端到端模型往往做得更激进，直接从多传感器输入到自车轨迹输出，因为只有这样才能逼近人类驾驶员的反应速度。代价是车队规模大、数据闭环完整、车端算力堆得高，单台车的硬件成本和测试成本都远超量产车。

第三类是传统 Tier1 和独立算法供应商。它们向车企输出端到端方案、域控或者工具链，真正的落地难点不在模型本身，而在“出了事故谁负责”。车企采购时通常会要求模型输出具有可解释性接口，所以这类供应商交付的多数是带中间监督信号的半端到端方案，而不是纯粹的单一神经网络。

2.2 技术路线对比：全局端到端、模块化端到端与混合式方案的落地成熟度

把三类玩家的技术方案拉平看，2024 年真正在跑的其实是三条路线：全局端到端、模块化端到端和混合式方案。三者的差异不在“网络多深”，而在“端到端的边界画在哪”。

我一般会建议同行优先看混合式方案。它不是保守，而是工程上最容易守住安全底线。全局端到端的吸引力很大，但它的 corner case 调优成本极高：模型在某个路口表现出问题，你很难定位是感知特征污染了规划，还是训练数据里这个场景太少。混合式方案把安全兜底留在规则层，出了问题可以先查规则层是否误判，再查模型输出是否异常，排查路径清晰很多。

2.3 城市 NOA 与无图化：为什么 2024 年是端到端上车的时间窗口

技术路线成熟是一回事，有没有上车窗口是另一回事。2024 年的特殊性在于三件事同时发生了。

第一，城市道路场景把规则 pipeline 逼到了极限。传统模块化系统在高速上够用，但进到城市路口，目标类型多、意图混乱、博弈频繁，规则代码越堆越多，边界越堆越模糊，几乎到了人力不可维护的程度。

第二，200TOPS 级算力的域控开始在主流车型上普及。之前端到端模型只能在实验室跑，原因不是算法不成立，而是车端跑不动。算力下放直接改变了成本结构，让一体化模型在量产硬件上有了物理前提。

第三，无图化趋势把高精地图的成本压力变成了技术倒逼。高精地图覆盖慢、维护贵，行业转而要求系统实时建图。端到端模型把在线建图和感知放进同一个网络，正好踩在这股趋势上。综合看，算力、场景复杂度、数据获取成本三个变量都到位了，端到端上车就不再是发布会口号，而是一个有时间窗的工程选项。

3. 端到端系统的技术底座：一体化模型、数据闭环与训练评测

3.1 从分模块 pipeline 到一体化模型：为什么规划 loss 能反向修正感知

传统自动驾驶系统的信息流是串行的：检测、跟踪、融合、预测、规划，每个模块的输出都要经过固定格式的接口传给下一个模块。接口设计本身就是在压缩信息，比如目标列表里只保留位置、速度、朝向和类型，丢掉的是目标过去几帧的交互意图和场景上下文。感知模块漏检一个行人，后面所有模块都无从补救，误差只能一级一级向下传。

端到端一体化模型的思路是让梯度贯穿整个网络。多路摄像头输入先通过 BEV 编码器变成鸟瞰视角特征，再用一组可学习的动态目标 query 和静态地图 query 去查询特征，最后用一个规划头直接输出自车未来若干帧的轨迹。训练时规划 loss 会反向传播到 BEV 特征层，等于告诉感知层“这个区域对开车决策更重要，特征要更细”，感知层的学习目标从“检测得准”变成了“辅助规划决策”，这是它与传统 pipeline 本质的区别。

一体化模型也不是完全不要中间监督。在实践中，预测头会输出目标轨迹，地图头输出车道线和路沿，这些中间任务既提供可解释信号，也防止共享 backbone 被规划任务带偏。规划 loss 的权重通常会设得比其他任务高一些，但高多少需要调试，权重太大感知头容易退化，权重太小规划又学不到交互博弈。

3.2 数据闭环是端到端的真正门槛：采集、标注、场景挖掘与 GT 生成

端到端模型的胃口比传统模块化大得多，因为一个模型要同时学感知、学意图、学驾驶行为，数据量级直接决定模型上限。数据闭环的核心不是“多存数据”，而是“知道该采什么、该标什么、该重放什么”。

第一步是采集。量产车在影子模式下跑，系统只在后台推理不接管，当出现接管、急刹、大曲率、感知低置信这些信号时，自动把前后一段传感器数据上传。这样车队跑得越久，长尾场景覆盖越密。第二步是标注。动态目标要做时序标注，包括身份关联、速度、意图分类；静态要素要标车道线、路沿、停止线；遮挡区域还要做物理一致的推理标注，不能只标看得见的框。第三步是 GT 生成和场景挖掘，把真实路测数据重建成交互场景，再通过特征聚类找出模型表现差的场景族。

# 用感知 backbone 特征做困难场景挖掘的通用思路 import numpy as np from sklearn.cluster import DBSCAN feats = np.load("scene_embeddings.npy") # 每段 clip 提取一个特征向量 [N, dim] labels = DBSCAN(eps=3.0, min_samples=5).fit_predict(feats) hard_idx = np.where(labels == -1)[0] # 噪声样本常对应少见场景 scene_ids = np.load("clip_ids.npy")[hard_idx] # 回映射到原始数据片段

这里的 eps 控制聚类半径，调太小会把常见场景也切成碎片，调太大又抓不出真正的长尾。min_samples 建议保持在个位数，目的是过滤掉孤立特征。更实用的做法是把接管标签、舒适性打分和聚类结果联合起来做加权，只把“模型开得差”的场景加入训练集，而不是把所有统计离群点都当成困难样本。

3.3 训练与评测：开环指标、闭环仿真和 loss 权重的基本设置

端到端模型训练通常分两个阶段。第一阶段冻结 backbone 只训练各任务 head，让检测、地图、预测这些头先收敛，避免多任务互相干扰。第二阶段解冻 backbone 做全量微调，这时候规划 loss 开始反向影响感知特征，模型才会真正向“开得稳”的方向优化。

开环评测指标包括感知 mAP、预测 minADE/minFDE、规划碰撞率等，它们适合做模型迭代时的横向对比，但开环指标好不代表能上车。规划层完全可能平均误差很低，却在某个路口输出一条撞向路沿的轨迹。所以落地项目的评测必须跑到闭环仿真里，统计接管率、碰撞率、最大横向加速度这些下游指标。

model: backbone: bev-encoder-base bev_size: [200, 200] # BEV栅格 200x200，每格 0.4m，覆盖约 80m x 80m embed_dim: 256 train: batch_size: 64 epochs: 30 base_lr: 2.0e-4 # 全量微调比预训练低一个量级 freeze_backbone: true # 第一阶段冻结，只训各任务头 loss_weight: det: 1.0 map: 1.0 motion: 0.8 # 目标轨迹预测 plan: 1.5 # 规划 loss 权重最高

plan loss 权重给到 1.5 是基于多任务收敛均衡的常见起点。det 和 map 维持 1.0，motion 降到 0.8，是为了避免中间任务把共享特征带偏。bev_size 直接影响显存和算力，200x200 在训练卡上没问题，但上车前一般要降到 160x160 左右，后面部署部分会细说。

提示：开环指标只用于模型筛选，闭环仿真才是上车前的评审口径。不要用开环涨点直接推导实车表现，这一步的偏差是端到端项目最常见的估算误差来源。

4. 端到端模型的车端部署：算力预算、TensorRT 驯服与掉帧策略

4.1 车端硬约束：先定预算再选模型，六个参数缺一不可

端到端模型上车不能先看精度再看资源，顺序要反过来。先把车端算力、内存、带宽和延迟预算定死，再决定模型砍到多薄。量产域控的算力和散热是固定死的，模型只能去适配硬件，而不是让硬件迁就模型。

规划频率低于感知频率是刻意的。轨迹输出需要的是预测地平线和平滑性，不是极限帧率，规划头在 10Hz 下仍然能保持对前方 5-8 秒的预测覆盖。感知频率降到 15Hz 后，模型每次推理可以多留一些算力给更大的 BEV 分辨率，这是端到端部署里最常见的权衡方式。

4.2 从 PyTorch 到 TensorRT：锁 shape、FP16 起步、INT8 校准集怎么选

模型上车的第一件事是导出推理引擎，常见做法是走 ONNX 到 TensorRT。端到端模型的输入 shape 基本固定，导出时要把动态维度全部锁死，省掉运行时 reshape 和显存分配的开销。BEV 栅格尺寸、摄像头路数、序列长度这些参数在导出时就写死。

# 从 ONNX 构建 FP16 引擎并序列化保存 trtexec --onnx=e2e_bev.onnx \ --saveEngine=e2e_bev_fp16.engine \ --fp16 \ --minShapes=img:1x6x3x256x704 \ --optShapes=img:1x6x3x256x704 \ --maxShapes=img:1x6x3x256x704

这个命令把 batch、相机路数、通道、高、宽全部固定成 1x6x3x256x704，避免推理时动态 shape 带来的额外开销。FP16 是量产起步配置，精度损失小、CUDA core 吞吐翻倍。INT8 量化能再压一倍的算力，但校准集的选择直接决定量化后规划轨迹会不会抖。

import numpy as np # FP16 与 INT8 引擎的轨迹输出对比，只看最大单点误差 fp16_traj = infer_engine("e2e_bev_fp16.engine", sample_input) # [1, 10, 2] int8_traj = infer_engine("e2e_bev_int8.engine", sample_input) max_err = np.abs(fp16_traj - int8_traj).max() print(f"max trajectory error: {max_err:.3f} m")

INT8 校准集不能只抽常规道路样本，要把夜间、雨天、强逆光、施工改道这些困难场景混进去。不然校准统计出来的激活值分布和真实运行分布不一致，量化后感知精度看似没掉，规划轨迹却可能出现毛刺。我一般会要求校准集中困难场景占比不低于三到四成，量化后轨迹最大单点误差控制在 0.3 米以内，同时跑一遍闭环仿真确认碰撞率不反弹。

4.3 延迟优化的三个抓手：BEV 分辨率、多视角并行与掉帧优先级

推理引擎构建完，延迟优化才刚开始。端到端模型的计算热点高度集中：BEV 编码器、跨视角注意力、规划头的自回归解码。其中 BEV 编码器往往吃掉接近一半的延迟，优先动它。

第一个抓手是 BEV 分辨率。训练用 200x200，车端可以降到 160x160，每格分辨率从 0.4 米调整到 0.5 米，感知半径不变，计算量明显下降。第二个抓手是多视角并行。六路摄像头输入到 BEV 编码器之前可以拆到多个 CUDA stream 里并行处理，再在特征融合处汇合，能压掉一部分串行时间。第三个抓手是 CUDA graph，把整条推理链路的 kernel 启动开销吃掉，减少 CPU 和 GPU 之间的同步点。

掉帧策略同样要提前定好。感知频率可以降，规划频率不能降；当域控负载超过阈值，模型先砍感知帧，规划输出始终保 10Hz。如果规划侧也出现超时，必须触发降级模式，切到规则兜底路径，而不是让模型丢帧硬算。延迟验收要在域控满载、散热稳定之后测，空转测出来的数字没有参考价值。

注意：量化不是白拿的。INT8 后的轨迹精度必须放到安全层约束里看，安全层阈值本来就是按 FP16 标定的话，量化模型的毛刺会让安全层频繁介入，最终体验比不开量化还差。

5. 从仿真到真车：端到端落地最容易踩坑的 5 个记录

5.1 仿真里跑得好，真车却频繁接管：先查仿真场景的分布偏差

现象是闭环仿真通过率很高，模型上车跑同一段路却频繁输出让驾驶员不适的轨迹，接管率远超预期。

原因是仿真场景重建时用了自车采集的 GT 数据，目标车辆的位置和速度被 GT 标得“太干净”，交通流分布和真实路况的博弈强度差距很大。模型在仿真里学到的是“别人都让着我”的静态分布，真车上遇到真实驾驶员加塞、压线、犹豫不决就开始翻车。

解决思路是仿真器里引入真实交通流回放和高强度博弈场景，不要只回放 GT 数据本身。人工设置拥堵切入、变道博弈、鬼探头遮挡等压力场景，让模型在训练阶段就见过“不舒服”的交互。

5.2 感知指标正常，规划却画龙：多任务损失平衡的坑

现象是检测 mAP、地图 IoU 都正常，但规划轨迹有轻微左右摆动，安全层频繁介入修正方向。

原因是规划 loss 权重太大，把共享 backbone 的特征全往规划任务上带，感知任务退化成了辅助信号。感知头虽然指标没崩，但特征表达里对静态结构的边缘信息变得模糊，规划头拿到的地图特征不够锐利，轨迹就开始抖。

解决方法是检查 loss 权重配比，先把规划权重降下来，恢复到 det 和 map 权重大于 motion 的状态。两阶段训练顺序也要守住：冻结 backbone 训 head 的阶段不能跳过，一上来就全量微调，多任务很容易互相带偏。

5.3 INT8 量化后轨迹出毛刺：不是精度问题，是校准集分布问题

现象是 FP16 引擎一切正常，INT8 引擎的感知指标变化很小，但规划轨迹偶发高频抖动，安全层裁切后变成一顿一顿的体感。

原因是校准集里常规场景占大头，量化统计的激活范围把高曲率、低速博弈场景覆盖得太少。规划头对轨迹点的微小数值波动敏感，量化误差被运动学约束放大。

解决方法是校准集重做，把困难场景占比提上去，并考虑把规划头单独留在 FP16。量化感知训练能彻底解决这个问题，但训练周期长，一般放到下一版模型迭代里做，当前版本优先用混合精度部署。

5.4 无图方案在地库和城市峡谷失效：实时建图不是万能的

现象是端到端模型在开阔道路表现很好，一进地库、隧道、环岛就频繁退出或者输出绕行轨迹，完全不如旧的高精地图方案稳定。

原因是实时 BEV 建图对弱纹理、重复结构、遮挡环境的稳定性天然不足。完全去掉地图先验，等于让模型在感知最差的环境里同时承担定位和规划，这是无图化被高估的地方。

解决做法是引入轻量导航先验，把车道级粗图、路由信息作为规划头的条件输入，而不是喂给感知层。保留可行驶区域检测作为兜底能力，地库和隧道场景直接降级到保守策略。

5.5 安全兜底层成了新的黑匣子：规则也需要可审计

现象是在一次危险接管复盘里，无法快速定位是模型输出有问题还是安全层误触发，两侧互相甩锅，评审会开完也没有结论。

原因是安全层规则常年累加，数量膨胀后变成了“规则黑匣子”。每条规则的触发条件、优先级、阈值之间互相影响，离线回放工具缺失，出问题只能靠人肉查日志。

解决做法是给安全层每条规则分配唯一 ID，触发时记录完整上下文，并接上离线回放平台，规则层和模型层用同一套评测闭环回归。对临界 case 做多人评审，而不是只看触发率。规则不是免费的，它同样需要维护、验证和版本管理。

6. 验证一套端到端系统能否上车：影子模式、闭环回归与 A/B 评测的实操

要判断端到端系统能不能上车，不能只看模型指标，要看一套一致的验证流程。我会按三个阶段来做，每个阶段有明确的通过标准，缺一个都不敢放手。

第一阶段是影子模式跑数据。模型在量产车队后台静默推理但不控制车辆，重点关注接管率、危险场景触发率、异常轨迹占比三组指标。影子模式至少跑一个完整季度，覆盖不同季节光照和天气，连续无高危风险事件才算通过。

第二阶段是闭环回归。每周固定跑同一套场景集，场景集在项目启动时定好，之后只增不减，不能因为模型更新就悄悄删掉难场景。对比维度包括碰撞率、平均车速、最大横向加速度，新一代模型的指标相对基线不能有明显回退。

第三阶段是 A/B 评测。新旧模型在同一批车辆、同一批路线上交替运行，驾驶员不知道当前跑的是哪个版本，统计接管率、通行效率和舒适度指数的相对变化。数据量不够时不做结论，至少积累两周以上的有效里程。

端到端项目最大的教训是评测口径必须先于模型迭代稳定下来。模型涨点很容易，但你不知道涨的点是不是评测集里偶然放水的点。我自己现在的习惯是，先花一周把评测基线、场景集、接管统计口径全部锁死，再开始碰模型结构。评测稳了，模型的每次改动才有意义。希望这套验证思路能帮到你少走弯路。

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