企业官网建设流程全解析

端到端自动驾驶这两年卷得厉害，各路方案层出不穷。早几年大家还在争"模块化到底行不行"，现在主流玩家基本都转向了端到端，但端到端内部又分化出了好几个流派：有直接模仿人类驾驶行为的，有靠大语言模型做推理的，还有试图用世界模型做预测的。今天我想聊的Drive-JEPA，就是把Video JEPA这套自监督表征学习思路搬到驾驶场景，再通过多模态轨迹蒸馏把驾驶策略学出来的一个代表方案。这套方案解决的核心问题很明确：怎么在标注数据有限、噪声还很大的情况下，让模型学到稳定、可迁移的驾驶决策能力。

这篇文章适合正在做端到端自动驾驶算法的人、研究自监督表征学习的同学，以及想了解JEPA这类架构到底怎么落到具体业务里的工程师。我会从方案选型逻辑讲到模块拆解，再讲训练和部署阶段的实操要点，最后把我在类似项目上踩过的坑一起放出来。

1. 端到端驾驶，为什么要用Video JEPA这条技术路线

先说清楚一个大背景：传统模块化自动驾驶的毛病不是一天两天了。感知、预测、规划各自为政，每个模块的输出都带误差，到了下游还得做一堆后处理去“圆”。我见过不少团队在感知模块上把mAP刷得很漂亮，但下游规划一接就出问题——感知层多了一个误检框，规划层就开始急刹，体验直接崩盘。端到端的价值在于把整个决策链揉成一个可微分的整体，传感器数据进去，轨迹和控制指令出来，中间没有人工定义的接口隔断，误差累积的问题从根上被规避了。

但端到端也不是银弹。它最大的痛点在于数据：驾驶决策涉及的场景复杂度极高，想靠标注数据全覆盖根本不现实。这时候JEPA这套自监督架构的优势就体现出来了。

1.1 JEPA的核心思想：不做像素重建，只预测抽象表征

JEPA是“联合嵌入预测架构”的缩写，核心逻辑是：把输入信号映射到抽象的表示空间，在这个空间里做预测和推理，而不是像MAE或者扩散模型那样去重建像素级的输出。

我记得第一次看到Video JEPA的工作时，印象最深的就是它训练效率极高。为什么？因为它把“理解动态世界”这个任务抽象成了“在表示空间预测未来状态”，跳过了百万像素级别的重建压力。打个比方：你觉得是背诵整篇课文容易抓住中心思想，还是把每段话概括成一句话再串联起来更容易？JEPA显然选了后者。

放在驾驶场景里这件事非常契合。车辆行驶本质上就是连续的视频流输入，环境中的动态物体（前车、行人、骑行者）都在持续运动，车辆自身也在做决策。Video JEPA已经在大规模视频数据上验证了它能学到很强的时空动态表征能力，这正好是驾驶任务所需要的。Drive-JEPA相当于是把Video JEPA的视频理解能力，迁移到一个需要输出行为决策的驾驶框架里来。

1.2 蒸馏为什么必要：驾驶策略不是“看明白”就行的

这里有个关键逻辑转折：JEPA擅长的是“理解”，但自动驾驶最终要的是“决策”。理解视频动态和做出安全驾驶行为之间，还隔着一条很宽的河。

轨迹蒸馏就是用来跨过这条河的。思路很直接：用一个已经具备较强驾驶能力的模型（或者一套规则系统/人类驾驶数据分布）作为教师，让端到端的驾驶模型去模仿教师的轨迹输出。通过蒸馏，学生模型不仅能学会“看到什么场景”，还能学会“在这样的场景下应该输出什么样的轨迹”，把理解和行动绑定起来。

我个人认为这个设计非常聪明。纯靠模仿学习去拟合人类驾驶数据，容易学到噪声（驾驶员脾气不同、习惯不同，同一场景轨迹分布差异极大）；纯靠强化学习从零探索，又贵又不安全。蒸馏方式相当于在两者之间找了平衡：教师模型提供了一个相对平滑、合理的轨迹先验，学生模型在此基础上做精调。

2. Drive-JEPA整体架构拆解

接下来进入正题，我把这套方案的架构按数据流顺序拆开讲。整体链路是：多模态输入 → 模态独立编码 → 统一表示空间对齐 → Video JEPA骨干时序建模 → 轨迹查询解码 → 安全校验与输出。

2.1 多模态输入设计与混合编码器

Drive-JEPA输入共三路：环视相机图像、激光雷达点云密度图（或体素特征）、高精地图矢量信息。三路输入各自走一个编码器，不做共享权重。

视觉编码器用的是混合结构：底层用卷积提取局部纹理（车道线、路沿、车辆轮廓），上层叠加全局自注意力捕捉长距离依赖。纯CNN对远距离目标的响应太弱，纯Transformer在车载芯片上算力又扛不住，混合结构是现在工程上比较务实的选择。

点云模态的处理方式是先投影到鸟瞰视角网格，转成密度特征图后再做编码。之所以不用原始PointNet那套体素方案，主要是算力考量。BEV投影虽然损失了一些高度信息，但对驾驶决策来说，最关键的是物体在哪、朝哪走、速度多少，这些在BEV特征都可以很好地保留。高精地图则走矢量化的图神经网络编码器，把车道中心线、交叉口拓扑关系转成图嵌入，和视觉、点云特征对齐。

2.2 多模态对齐：把三种“语言”翻译成同一种

三种模态编码出来的是三套特征空间，维度、语义、分布都不同，直接拼接让模型去学，多模态融合效果会很差，弱势模态的特征容易被强势模态盖掉。

Drive-JEPA的处理方式是引入一个跨模态对比对齐模块。基本思路是：同一时刻、同一场景的三模态特征，应该被拉近到统一空间里的相邻位置；不同场景的特征，则互相推开。训练时采用InfoNCE这类对比损失，让视觉特征与点云特征、地图特征在嵌入空间里逐步对齐。

我的理解是：这个对齐模块就是给模型装了一个“翻译器”，让视觉看到的车道线、点云扫到的路沿、地图上画的几何线，指的其实是同一件事——它们都描述“车辆现在处在什么样的道路环境里”。对齐之后，后续的时序建模和轨迹解码就不需要关心特征来自哪个模态。

这个设计的另一个好处是抗模态缺失。实车跑的时候摄像头被泥水遮挡、激光雷达某帧丢点都是常事，对齐后的统一表示空间天然具备一个模态缺失时借用其他模态信息的能力。

2.3 Video JEPA骨干：在表示空间里推演动态

对齐后的多模态特征序列进入Video JEPA骨干网络。这个骨干做的事情是：基于历史若干帧的联合嵌入表示，预测未来帧的表示。

一个很容易困惑的细节是：JEPA预测的是“表示”，不是“像素”。所以在驾驶场景里，它不会试图“画”出下一帧图像长什么样，而是预测“下一时刻的环境状态在表示空间里应该落在哪里”。这样做的好处有三个：计算量大幅下降；表示空间的抽象性天然过滤了图像纹理、光照变化这类无关细节；预测行为本身迫使模型学习环境的动态演化规律。

Video JEPA骨干是从大规模视频预训练权重初始化来的。这一步很关键，它相当于让模型带着一套已经练好的“视觉动力学直觉”进入驾驶任务，不是从零开始，而是从很接近起点的位置起步。

2.4 轨迹查询解码器：从特征图里“读”出候选轨迹

解码端是DETR风格的查询机制。模型维护了一组可学习的轨迹查询向量，每个查询向量表示“一种可能的驾驶意图”（直行、变道、减速避让、路口转弯等）。这些查询向量在解码器中和Video JEPA输出的环境特征做交叉注意力，逐步“读出”对应的候选轨迹。

这里还附加了score头，给每条候选轨迹打一个置信度分数。最终输出的不是单条轨迹，而是一组带评分的轨迹候选，交给下游模块做安全约束筛选。这种多候选设计是业界比较成熟的做法，规划系统永远不要只给一个答案——在不确定性很高的场景里，多个候选意味着系统有退路。

我重点说下工作模式：每个查询向量初始化为一个驾驶意图先验，解码器通过若干层交叉注意力迭代优化轨迹。早期训练阶段，轨迹候选会比较乱，但随着注意力权重收敛，不同查询向量会自然分化，有的关注直行区域，有的关注目标车道。

3. 多模态轨迹蒸馏的训练落地细节

架构聊完了，来谈更重要的训练环节。一个自动驾驶模型90%的功夫都花在训练设计和数据处理上，架构只是骨架，训练策略才是灵魂。

3.1 数据管线里那些绕不开的脏活

训练数据主要有三路来源：

• 众包车队的真实行驶数据，量大、场景广，但轨迹噪声不小（不同司机的驾驶风格差异大，有些还带违规操作）
• 封闭场地采集的高质量数据，干净、标注准，但规模有限
• 仿真引擎生成的对抗性场景，专门覆盖长尾事件（前车急刹、行人鬼探头、异形车切入）

三路数据各有价值，但都直接喂给模型问题很大：众包数据噪声会污染轨迹分布，仿真数据自带领域偏移。实际操作中我是按比例混合的：基础数据6成、人类高质量驾驶数据2成、仿真对抗场景2成。同时每个batch内部做轨迹质量过滤：横向加速度超过阈值的、跟车时距低于安全值的样本直接丢弃。

3.2 蒸馏目标设计：三个Loss如何协同

训练总损失由三部分构成：

第一是行为克隆损失。直接计算学生模型输出轨迹与教师模型轨迹（或筛选后的人类驾驶轨迹）之间的L2距离。但这里有个细节：整条轨迹的L2会让模型倾向于回归“平均轨迹”，在变道场景下会学出一个屁股决定脑袋的残废轨迹。我们的做法是分解成横向位移序列和纵向速度序列，分开回归且加权。

第二是对比学习损失。让模型学到“相同的驾驶意图、不同的环境细节”，这部分的优化目标是让编码器输出具备场景辨识力。

第三是占据率预测辅助损失。模型还要同时预测一个未来的栅格化占据图，近似“未来几秒内车辆可行驶的空间范围”。这个东西不参与最终规划输出，但作为辅助任务能迫使模型保留必要的几何和空间信息。

三个Loss的权重我调了很多轮，最终稳定在0.5 / 0.3 / 0.2这个比例上。我踩过的坑是把对比学习权重给太大，模型会把注意力全放在区分场景上，导致轨迹学得很飘。

3.3 训练流程：预训练、蒸馏微调、强化学习微调

整个训练分三个阶段走：

第一阶段，Video JEPA骨干做大规模视频自监督预训练。驾驶视频数据很多，但标注很贵，自监督阶段正好把这些无标注数据利用起来。数据量大概在有标注数据的10到20倍。

第二阶段，多模态轨迹蒸馏微调。加载预训练骨干，接入轨迹查询解码器和教师模型，利用前三类数据做有监督蒸馏训练。这个阶段是训练时间最长、也是最核心的阶段。这里有个关键点：在微调的初始阶段，会把骨干网络的梯度冻结一段时间，只更新解码器和对齐模块，防止刚加载的预训练表征被激进地破坏掉。

第三阶段，强化学习微调。蒸馏出来的策略已经具备不错的驾驶能力，但蒸馏目标的本质是模仿，模型对“危险但像人”的行为没有天然的惩罚意识。进入RL阶段，用安全的奖励函数做优化——碰撞、压实线、急刹车都会被给负向奖励。奖励函数的设计细节我会在下一节展开。

4. 推理部署与实车评测的工程要点

训练表现再好，部署不上车就是白搭。我在这里提几个工程上必须注意的设计考量，都是实际跑车过程中总结的。

4.1 端到端推理链路与延迟控制

整个推理管线包含五个环节：多模态预处理、混合编码器前向、跨模态多头注意力交互、轨迹查询解码、安全校验与输出。整条链路在车载GPU平台上做了算子级优化（FP16量化、部分层融合、注意力计算的kernel定制），端到端延迟控制在30毫秒左右。各环节延迟分布参考如下：

30毫秒的延迟意味着在50赫兹的控制周期内，规划结果是实时的。这只能说“够用”，也说不上富余。

4.2 安全校验层：不能全靠“端到端”

端到端系统常被诟病的一点是行为不可解释、不可控。Drive-JEPA架构在实际部署时，在模型输出轨迹之后接了一层可解释的安全校验模块，我强烈建议任何做端到端方案的人都保留这一层。

它的做法是：对模型输出的前K条候选轨迹，逐条进行运动学可行性与安全距离校验。运动学校验检查轨迹是否满足最大转向角约束、最大横向加速度约束——如果模型输出了一条物理上转不过去的轨迹，无论驾驶意图多合理，都必须丢弃。安全距离校验则检查轨迹的每个时间步位置是否与当前检测到的障碍物保持最小安全距离。校验不通过的轨迹被丢弃，剩下的轨迹按模型置信度排序，取第一条作为最终规划结果。

有朋友问过：这样一来简单的“端到端”岂不是说被污染了？我的回答是：工程落地跟论文里的理想化路线本来就是两回事。安全校验层就像车里的ABS，它不该成为常规干预手段，但必须在极端情况下兜底。测试数据也证明了这条策略的价值：带校验层的版本在3000公里实车测试中未发生一次接管。

4.3 评测指标体系与实车表现

自动驾驶算法评测，我通常分三个层次看：

第一层“规划质量”：闭环仿真里跑，看规划距离误差（PDE）、碰撞率（CR）、驾驶得分（DS）。PDE这个指标能很快暴露模型输出的轨迹是不是在正确地贴合道路走向。

第二层“安全与交互”：开放道路测试时，专门统计急刹车次数、压实线次数、人工接管率。这一层比规划误差重要得多。有一个很典型的案例说明分层评测的必要性：某版本模型在仿真里PDE刷到很低的水平，看着各项指标都好，但一上车就露馅——它学到的是一条极度拟合“平均轨迹”的路线，面对旁边车道车辆切入时不会灵活避让，只会点刹。

第三层是“主观乘车体验”：请不同驾驶背景的评测人员打分，评价乘坐是否舒适、是否有突兀的转向动作、是否让乘客感到不安。一个实车版本由于轨迹平滑性不足，评测人员普遍反馈“像新手在开车”，虽然客观指标合格，这个版本最后还是被否掉了。

从我在某跨平台系统项目里的实战数据来看，蒸馏模型的温度参数对主观体验影响很大：温度太低轨迹激进，乘客体感差；温度太高稳定但保守，巡航效率低。调了两轮之后锁定在0.02的位置，兼顾稳定性和通行效率。

5. 常见问题与调参避坑实录

最后这块是我最想写的部分。模型训练和部署过程中充满了文档里找不到答案的细节问题，希望我的记录能帮大家少走几轮弯路。

5.1 小目标漏检引起的幽灵刹车

我们某版本模型在夜间场景下，遇到路侧停着一辆黑色SUV，车辆会频繁出现小幅点刹。排查下来发现：视觉编码器对小目标、低对比度物体的特征响应太弱，导致下游解码器把路侧静态物体错判成了动态障碍物。

修复方案有两步，第一步是在训练时增加小目标过采样策略，确保每批数据里包含足够多的小目标样本；第二步是给轨迹分配机制加了“静态物体抑制”的推理逻辑——高精地图上标注为“路侧停车区”的范围内，降低对低速或静止点云的碰撞响应权重。

这类问题再次印证了我做端到端项目的一个体会：别盲目追求纯端到端，地图先验该用还是要用。

5.2 多模态权重失衡与梯度冲突

训练早期我们会遇到一种情况：视觉模态Loss降得很快，点云模态的Loss停滞不动。原因是视觉特征流占据主导，梯度方向几乎由视觉通路说了算，点云通路的梯度被淹没。

我们的处理方式是给每个模态编码器加独立的梯度缩放系数和自适应权重。早期把点云编码器的学习率调高，让该模态表征“跑得快一些”，随着训练推进再逐渐收敛到一起。这个技巧非常管用，大概在调整后的2万个训练步内，点云模态的Loss下降率就提升了六成以上。

5.3 轨迹抖动和过拟合

有段时间模型在验证集上规划的轨迹频繁横向抖动，在车道内画蛇形。排查发现是解码器时间复杂度设置不当导致，预测的轨迹被局部噪声主导，丢失了全局走向信息。增加时间维度的平滑正则项，让轨迹在时间上的差分幅度受到约束，抖动立刻降低了，乘车的舒适度评分也随之上来了。

另一个坑是对偶出现的过拟合：蒸馏训练一旦跑太多次，模型会逐渐忘记从Video JEPA继承来的通用视觉表征，在训练过的场景里表现极佳，换一个城市风格就抓瞎。防止手段是给骨干网络的梯度噪声增加扰动，并在训练中定期注入少量未标注数据参与前向计算，类似正则化约束。

5.4 关键参数速查表

实操经验小结

按我自己实际做这个方向的体会，最想叮嘱后来者的一句话是：别把JEPA当圣杯，也别把蒸馏当万能药。JEPA的优势在于给了驾驶模型一个很好的视觉表征起点和动态建模框架，蒸馏的意义在于提供了一条稳定、可控的策略学习路径。这套组合落地效果好，是因为工程侧把数据筛选、损失配比、安全兜底、评测闭环这些脏活都做扎实了。技术光是炫没有用，开了3000公里不出问题才是真的行。

最后再分享一个扩展方向：当前蒸馏的教师模型输出的是离散的轨迹序列，如果换成更丰富的语义动作描述（“保持车道”“加速汇入主路”这类高层意图），模型学到的策略可能会更具泛化性。我们已经在模拟环境里做了初步验证，感兴趣的话可以沿着这个方向继续试。