说到端到端自动驾驶最近行业内讨论最热的方向之一就是结合了JEPA联合嵌入预测架构的Drive-JEPA世界模型端到端框架。这套方案核心思路是让车辆在抽象的向量空间里提前“推演”下一秒场景而不是像传统预测模型那样逐像素重绘画面并把预测结果直接用于下游规划决策。对于做过视觉模型、或者研究过传统两段式自动驾驶方案的人来说这个概念转变带来的性能增益是实打实的。这篇文章我会从JEPA的来源讲起把Drive-JEPA的架构拆开给出训练环节的实操建议和踩坑记录适合正在做感知、预测、规划方向的技术人员也适合准备踏入端到端领域的同学参考。1. 项目概述端到端驾驶为什么会走上JEPA这条路1.1 传统感知-预测-规划链路的核心痛点先交代背景。当前量产智驾方案大多还是模块化思路传感器数据进来先做目标检测和语义分割再做人、车、障碍物的轨迹预测然后进入规划模块生成可行驶轨迹最后交给控制模块执行。每个模块独立开发和评测理论上每个子任务都能用最好的模型但实际操作中模块间的信息接口是“缩水”的。举个例子感知模块输出目标框、速度和类别这些信息已经从图像里抽走了大量细节。预测模块拿到这些离散化信息根本没法还原“那个行人身体重心正在微微前倾下一秒可能加速闯入”这类连续物理特征。于是预测只能给一个宽泛的概率分布规划模块拿到这个分布后为了安全只能极度保守。整个链路像传话游戏每个环节都在压缩信息最终丢掉的是驾驶决策最关键的那一点信息。这也是端到端方案兴起的直接原因直接拿传感器图像进网络不对中间表征做人为压缩让模型自己去学什么值得保留、什么可以丢弃。理论和实证都表明在同等算力条件下端到端模型在复杂城市路口的决策上限远高于模块化方案。1.2 端到端路线当前的落地瓶颈端到端虽然上限高但工程落地的门槛也很明显。最大问题是数据标注。一个完整的端到端规划数据集需要把每帧图像上所有障碍物的行为意图、轨迹点、车道中心线都标出来。做过这方面工作的人都知道高质量逐帧标注的单价有多高一个几万帧的数据集可能让团队预算直接归零。更麻烦的是长尾场景覆盖不足。普通路采一百小时可能连一个“前车突然切出后紧急制动再变道绕障”的黄金样本都凑不齐。模型在没见过这个组合模式前几乎不可能在真车上从容处理而真实道路上这类场景恰恰是安全性的试金石。JEPA这类自监督预训练方法的价值就在这里把海量零标注的路采视频利用起来。车天天在路上跑视频是“免费”的让模型先从这些视频里学会“一个场景如何演化为下一个场景”的底层规律。到了精调阶段只需要少量带轨迹标注的数据就能把驾驶能力“唤醒”。数据效率的提升是我认为这套框架最有现实意义的贡献。1.3 Drive-JEPA这个名字拆开看Drive-JEPA本质上是一个数据高效的世界模型驱动端到端框架。名字三个部分各有含义Drive代表为驾驶任务而生JEPA则指联合嵌入预测架构——一种在表示空间而非像素空间做自监督预测的训练范式。整套框架最重要改动是把预测目标从“像素空间”搬到了“BEV特征空间”。像素空间预测等于要求模型背下云的运动、树叶的晃动这类视觉噪声BEV特征空间预测等于要求模型关注“车道、障碍物、路权”这些真正影响驾驶行为的语义。只此一项就让下游规划器拿到了质量完全不同的未来信息。2. 核心原理拆解JEPA到底是怎么做到“预判”的2.1 JEPA与自监督学习的家族位置要理解JEPA先看它在无监督表征学习路线里的位置。常见的路线可以粗分成三类生成式重建比如把输入图挡掉一部分让模型把像素补出来。缺点是计算量大而且模型把大量算力消耗在恢复视觉细节上而不是学高级语义。对比学习同一张图做两次不同数据增强让模型输出表示尽量一致同时让不同图像的表示尽量分开。缺点是有时候会出现“捷径解”负样本选择的调参也很敏感。联合嵌入预测JEPA走的是第三条路它只预测目标表征不做像素重建也基本不依赖负样本工程靠着EMA机制保持目标分支稳定。JEPA在驾驶场景里优势明显驾驶环境本质上是部分可观测、但强结构化的。在表示空间里做预测既能跳过像素级重建的巨大计算开销又能抓住场景中真正决定驾驶行为的抽象元素比如其他车的运动趋势、路权边界的变化。2.2 世界模型预测的是“世界的状态”而不是“画面”“世界模型”这个说法在业内有点被用滥了。我在本文里指的世界模型是“能够基于当前可观测状态预测未来若干步场景状态演化的可学习模块”。在Drive-JEPA里这个模块就是JEPA预测头给定当前时刻的BEV特征Z_t输出未来时刻的特征估计Z_tΔ。它不输出一个“未来画面”输出的是一个向量或者一组向量。向量里的维度不需要人肉去解释但必然编码了“那条车道会不会通畅”“那个行人是否要横穿”这类规划关心的因素。这一点和视频预测有本质区别。视频预测模型需要生成逼真的未来帧但真实世界的物理运动千奇百怪——雨滴打在玻璃上的形状变化这类细节对驾驶决策毫无意义却占据绝大部分计算成本。JEPA主动把这类噪声扔掉只保留行为决策关心的信息。这既是计算效率的优化也是表征质量提升的关键。2.3 Drive-JEPA的网络结构与数据流我把整个网络拆成四段按数据流顺序讲第一段是多视角图像编码。输入是车端多路环视相机图像。每个视角先经过一个共享权重的主干网络现阶段常见的是ResNet类或ViT类结构提取各视角图像特征再通过视角投影和特征采样把图像特征映射到以车为中心的三维体素网格最后压成BEV平面特征。这一步直接决定了系统感知范围的形状和分辨率。第二段是时序建模与上下文。单帧BEV特征缺乏历史信息。Drive-JEPA使用轻量级的时序交叉注意力模块让当前帧特征和过去3到5帧特征在注意力层交互输出一个上下文增强后的BEV特征序列。这一步让模型具备“运动惯性”意识知道前车的相对加速度并不是凭空出现的。第三段是JEPA预测头也就是世界模型核心。anchor分支接受当前上下文BEV特征target分支在未来时间戳取对应特征。预训练时预测器通过几层MLP或Transformer模块从anchor特征生成对未来嵌入的估计。损失函数比较这个估计和target分支真实输出的相似度回传并只更新预测器部分。第四段是规划解码器与安全校验。预训练完成后冻结或低学习率微调主干与时序模块附加规划头。规划头本质是回归解码器输入上下文特征和导航意图输出一连串未来轨迹点最后经过可行驶区域过滤、交通标识约束、动力学可行性校验的轻量规控模块输出给底盘执行。这里有个关键训练细节预训练阶段的模型结构和精调阶段的模型结构在主干、时序模块、预测头上必须尽量对齐。如果预训练一套结构、精调又换一套预训练学到的时间演化规律就迁移不过去效果会大打折扣。3. 实操训练指南从数据集到模型上车3.1 数据采集与筛选策略JEPA预训练的数据不需要标注但没有筛选的话纯喂垃圾视频等于把模型练废。我的经验是从四个维度做清洗速度阈值过滤剔除长时间车速低于1m/s的静止片段这类片段没有足够运动信号预测目标近似空集学了也白学。画面质量过滤剔除严重曝光、镜头污损、夜间无有效道路灯的片段。场景多样性约束按天气、时间段、道路等级做分层采样避免模型把“白天城市晴天”这一种分布当成世界全貌。轨迹完整性检查剔除长时间定位丢失的数据后续做坐标系对齐时没有GPS参考就无法把各帧图像对应到准确空间网格。有条件的话建议优先做相机内外参的统标定确保所有路采数据都在同一坐标系下不然后期喂给BEV网络会出现额外的对齐误差。3.2 预训练阶段参数经验表下面这张表是我基于实际操作整理的一组参考参数跑起来比较稳可以作为初始基线配置项建议取值说明BEV网格分辨率0.4m兼顾车道级细节和计算量BEV感知范围前后各80m覆盖高速主车流交互场景时序长度5帧10Hz覆盖0.5秒上下文预测未来时刻1.5秒相对anchor的滞后量EMA更新率0.9950.99偏激进0.999收敛过慢预训练批大小64按GPU显存调整学习率3e-4 warmup用AdamWwarmup前500步几个踩了之后才明白的要点EMA更新率直接影响JEPA的稳定性但更关键的细节是在训练最开始的少量步数内把EMA系数从较低值线性warmup到目标值否则模型前期梯度波动非常大。BEV分辨率不建议低于0.3m遇到宽体货车或者多车道大路口时0.5m很容易丢失人行横道线等细结构。预训练时目标嵌入维度拉到256维以上也不划算后续规划头关心的是少数关键模式过高的维度纯粹浪费算力还容易过拟合噪声。3.3 精调阶段与规划头设计JEPA预训练完成后要让输出变成轨迹需要加规划头。常见做法有三种直接接一个Transformer解码器回归轨迹点。接离散化分类头在预定义的数百条候选轨迹里选一条再用回归头微调坐标。接“轨迹生成打分”两阶段头先生成若干粗候选再用带碰撞检测模块的评估器排序。实际落地时我更推荐第三种。原因在于它能天然接入规则约束比如检测到碰撞概率高的候选直接降权在安全性和可解释性上都有优势。代价是结构稍复杂需要多写一些后处理逻辑。精调阶段的标注没那么夸张每帧只需要标出“当前自车未来数米的行驶轨迹点”和“碰撞/事件标签”。这些标注在数据采集时可以直接从底盘定位系统拿到不需要人工手绘成本非常低。这正是JEPA路线最吸引人的地方大量免费视频做预训练少量低成本轨迹标签做精调。3.4 从仿真到真车的验证步骤训练完别急着上真车推荐一个三级递进验证流程。第一级是开环离线仿真直接拿真实路测数据回灌模型输出轨迹对比人类轨迹计算横向和纵向L2误差、碰撞率。这一级能发现车道线跨越、目标物重叠这类明显问题。第二级是闭环仿真平台把模型放到仿真环境里在可交互交通流中自主决策。重点观察模型能不能完成基础变道超车、路口左转、行人避让。这个阶段至少跑满一百个种子场景统计任务完成率和安全事件率。第三级是封闭场地真车冒烟把模型部署到测试车在低风险场地跑直线、跟停、绕桩三类基础任务检查轨迹是否平滑、是否存在不该有的急刹、方向盘是否有高频抖动。我见过不少团队第一级做得很好就以为没问题结果封闭场地一跑就发现方向控制高频抖动。原因在于开环L2误差会把“画出一条平均轨迹”的平庸模型评为满分而闭环和真车看的是轨迹随场景动态变化的稳定性两者不是一回事。4. 调参踩坑实录Drive-JEPA落地最常遇到的问题4.1 损失曲线锯齿状震荡现象是验证集损失反复横跳偶尔一次“暴跌”后又回到高位。这种场面十有八九不是损失函数问题而是数据管线bug。重点排查三处anchor和target的时间戳是否严格对齐多机器并行加载数据时时间索引容易错位。数据增强是否同时应用到了anchor和target分支如果只增强一个分支模型会学到“瞎猜”。EMA分支是否意外参与了梯度传播。检查一下loss回传计算图target侧编码器应当处于完全stop-gradient状态。我遇到过的一个案例是并行数据加载时某个worker的时间戳解析函数写错了时区损失曲线看起来就是锯齿状异常排查了两天才定位到问题教训相当深刻。4.2 多相机BEV拼接错位典型现象是车静止时BEV俯视图里的车道线在相邻相机交界处出现断裂。排查顺序先确认各相机外参标定日期车辆运行一段时间后外参是会漂移的。然后做静态重建验证如果静态对齐没问题但动态错位问题就出在时序对齐模块。动态错位大概率是各相机曝光时间不一致导致同一时刻画面在时间上并不完全同步。解决办法是开启相机硬件同步或者做曝光时刻补偿。早期我甚至怀疑过BEV网络设计本身后来发现就是设备侧同步没打开。4.3 低速场景规划输出出现小圆圈低速停车场“画圈”出现频率不低。根因是JEPA预测头在接近静止状态时时间维度上信息逐渐趋同模型区分“向前挪了0.3m”和“完全不动”的能力变弱。改进方案有两个方案一是给预测头加一个自车速度输入条件显式告诉模型当前速度量级。这能帮模型把输出偏移约束到匹配的尺度操作最简单、效果也最直接。方案二是在损失函数里增加输出平滑项比如轨迹点的二阶差分惩罚项鼓励相邻轨迹点加速度连续。但这样做会牺牲一些极低速下的灵活性。实际处理时两个方案我都做了低速段的稳定性提升非常明显轨迹也很少再出现画圈的情况。4.4 评测集分数高但真车体验差这不是JEPA特有的坑而是整个端到端领域的通病。在公开数据集评测时模型可以超过人类驾驶的弧线但真车上一跑就发现它不太会博弈、不懂得适时让行。原因是公开数据集中每个场景是短片段切开的模型在单帧对单帧的开环评测里根本没有闭环压力。我的处理方式是在内部建立一套真车体验量化评分卡包含四个硬指标平均接管距离、每百公里紧急制动次数、方向盘修正频率、乘客侧向加速度暴露时间。任何模型上线前把这四项跑出来和现有版本对比。如果只有公开评测集分数好看真车指标却全面退步那就说明模型在偏向“模仿能力”而非“驾驶能力”这时候需要回到训练数据层面重新审视分布偏好。5. 从Drive-JEPA延伸出去这套框架后续还能怎么玩核心内容过了一遍最后分享一些基于这套路线的延展判断和开发心得。JEPA路线真正的价值不在“预测更准”而在“数据更省”。一套端到端系统的迭代速度最终会被数据瓶颈卡死。让模型从无标注视频里学世界演化再从少量标注里学驾驶行为是我认为会持续进化的技术方向。从工程角度说这套框架对显存要求依然高预训练阶段建议至少8卡级别的配置同时对数据管线的重视程度要远大于对模型本身的调参。把时间花在数据清洗和结构对齐上收益远高于反复调学习率。最后一个小建议如果正在做任何自监督视频模型给EMA写入checkpoint时别偷懒一定要定期手动恢复验证。一旦EMA和在线参数不同步训练曲线会莫名变差排查起来特别痛苦。这套方案后续如果能进一步把局部地图、语音交互这类多模态信息纳入世界模型的输入我相信预判能力还会再上一个台阶。对个人开发者来说即使一时没有车端资源先在公开自动驾驶视频数据上把JEPA预训练流程跑通也是一条很值得的起步路径。