英伟达发布 Alpamayo 2 Edge 端到端自动驾驶模型，闭环表现提升 48.9%

英伟达于 11 月 10 日发布端到端自动驾驶模型 Alpamayo 2 Edge，该模型采用双模块架构：视觉语言模型（VLM）骨干约 2.45B 参数，负责场景理解与因果推理；独立的扩散动作专家约 0.2B 参数，负责生成连续控制量。模型运行在车规级芯片 DRIVE AGX Thor 上，目标是在车载算力与响应时间约束下，让 AI 不仅能看懂道路，还能理解复杂交通关系并自主生成驾驶动作。

传统端到端模型直接从图像输出轨迹，中间过程是黑箱。Alpamayo 2 Edge 被要求生成 Chain-of-Causation（因果链，CoC） 推理，即不光要开车，还要解释为什么这么开。但车载系统算力有限，若每帧都生成完整推理文本，延迟将难以接受。为此，英伟达引入 Adaptive Reasoning 机制，并设计特殊标记 NOMINAL：当模型判断当前属于常规驾驶状态时，直接输出该标记以结束显式推理文本的生成；遇到复杂交通交互时，再展开完整的 CoC 推理链。需要说明的是，NOMINAL 并不关闭视觉网络，也不跳过后续动作计算，它改变的是语言模型的输出方式，减少常规场景下的推理 Token。

CoC 的训练数据构建依赖自动标注流程。英伟达先从车辆轨迹中提取 Meta-Action（自车高层运动行为），再根据行为变化的时间点定位关键帧，随后调用 VLM 生成场景因素与驾驶动作之间的因果解释，并验证解释是否有画面依据、描述的动作是否符合实际轨迹。公开数据约包含 115,000 小时多摄像头驾驶视频，以及 370 万条 CoC 推理标注。英伟达使用 Alpamayo 2 Super 生成 CoC 自动标注，再通过离线蒸馏训练 Edge 模型。

在输入设计上，模型每轮处理 6 路摄像头、22 帧图像。前向广角和长焦各提供 5 帧，覆盖过去 2 秒、1 秒、0.5 秒、0.1 秒和当前时刻；左右侧向与后向四路摄像头各提供 3 帧，覆盖过去 1 秒、0.1 秒和当前时刻。此外，模型还接收 20 个历史 Ego Pose，按照 0.1 秒间隔覆盖过去 1.9 秒，并转换到当前自车坐标系。Ego Pose 描述车辆自身的位置和姿态变化，与摄像头提供的外部环境视觉信息结合，帮助模型理解道路中其他参与者的相对运动。

动作专家接收 VLM 输出的场景语义、导航条件和 CoC 推理作为条件，生成每个时间步的加速度和曲率，再通过 Unicycle Model 积分形成车辆轨迹。模型最终输出 64 个 Waypoints，覆盖未来 6.4 秒，每 0.1 秒一个点，包含 XYZ 位置和 3×3 旋转矩阵。连续动作采用 Flow Matching 训练，公开推理配置默认执行 10 步 Euler 积分。训练时，VLM 接受未来轨迹 Token 和 CoT 文本监督，动作专家接受加速度与曲率的 Flow Matching 监督。一个关键实现是 Detach 梯度隔离：动作专家接收 VLM 输出的条件特征，但动作损失不会反向更新 VLM，以减少连续控制目标对语言视觉骨干的梯度干扰。

为评估推理质量，英伟达引入 AlpaJudge，提供 Reference-Based（RB）和 Reference-Free（RF）两个版本。RB 接收问题、参考解释和模型生成的候选解释，判断两段文本的对齐程度，但不读取图像；RF 则不需要参考解释，输入包括前向广角和长焦摄像头画面、自车 Meta-Action 历史与未来，以及模型生成的 CoC，从动作匹配、安全性、场景依据、要素完整性和因果一致性五个维度评价推理质量。RF 将动作匹配与安全性合并为动作评分，占综合评分的 60%；场景依据、要素完整性和因果一致性构成另外 40%。由于 RF 使用了未来 Meta-Action，它主要用于离线评估和训练，不参与车辆实时决策。

AlpaJudge 还参与训练数据筛选。英伟达的实验显示，经过评分筛选后，中间分数样本在精选数据中的占比从原始数据的 27% 提高到 81%。评分机制进一步进入后训练：模型生成候选 CoC 和轨迹后，训练流程结合推理质量、轨迹误差与驾驶舒适度计算奖励，并保留轨迹质量约束。英伟达在一组基于 Alpamayo 2 Super 的后训练实验中发现，使用 AlpaJudge 奖励后，模型评分提升 10.2%，人工评价提升 11.4%；使用基线奖励时，模型评分提升 13.4%，人工评价却只提升 1.8%。两组结果说明，模型自身评分与人工判断之间可能存在偏差，推理奖励需要经过人工校准。

由于 AlpaJudge 只能评价模型生成的解释，无法完整衡量连续驾驶中的动作后果，英伟达又将模型接入 AlpaGym 和 AlpaSim 进行闭环强化学习。在仿真环境中，模型接收摄像头画面、自车状态和路线信息，生成轨迹后由仿真车辆执行，环境再返回新的画面和运动状态，模型继续作出下一轮决策。英伟达披露，Alpamayo 2 Edge 经过闭环强化学习后，驾驶表现较未使用该轮 RL 的较优检查点提升 48.9%。在 AlpaSim 的 875 个场景中，每个场景执行三组 rollout，平均每发生一次责任事故或驶离道路事件前行驶约 15.15 公里。开放环评估则使用 1,392 条样本，在 5 秒处测得 minADE₆ 为 0.52 米。这两组数据衡量的内容不同：闭环结果反映模型在持续交互中的驾驶表现，开放环结果衡量固定输入下的轨迹误差。

模型训练完成后，还需针对 DRIVE AGX Thor 进行推理优化。英伟达提供的部署流程包含 FP8 量化校准、ONNX 导出和 TensorRT Engine 构建，并结合 TensorRT Edge-LLM 插件与 DFlash2 speculative decoding。DFlash2 使用轻量 Draft 模型并行提出候选 Token，再由目标模型验证，减少自回归解码的等待时间。结合 NOMINAL 对常规场景推理文本的压缩，系统从文本生成长度和解码执行两个环节控制计算开销。在 DRIVE AGX Thor-X、DRIVE OS 7.2.7.0、CUDA 13.4 和 TensorRT 11.3.1.9 的参考配置下，英伟达公布的 Pixel-to-Trajectory 时延为 160–190 ms，具体取决于 CoC 文本长度。需要注意，这个数字描述的是模型从图像输入到轨迹输出的推理耗时，不包含传感器采集、定位、控制器执行和安全监控组成的整车响应周期。

从产业角度看，Alpamayo 2 Edge 展示了一条将推理过程纳入计算资源分配和训练优化的技术路径。传统端到端模型被诟病的核心不是开得不好，而是说不清为什么这么开，因果链推理直接回应了这一点。但这里存在一个现实的工程矛盾：如果模型对复杂场景的判断不充分，可能过早进入 NOMINAL 模式，遗漏需要处理的交通因素；如果模型频繁展开长 CoC，语言解码又会占用更多时间，影响整条推理链路的执行效率。因此，自适应推理的效果不能只看文本质量，还需结合模式选择、轨迹质量和实际响应时间进行评估。英伟达也特别提醒，推理分高不代表车开得好，必须和碰撞、偏离车道、轨迹误差等指标一起报告。

目前公布的结果显示，英伟达已展示了模型架构、自动标注、强化学习和车载部署之间的完整技术路径，但仿真环境中的表现仍需经过不同道路条件、传感器组合和车辆动力学环境的检验。对于自动驾驶而言，模型生成轨迹只是决策链路中的一个环节，这套架构能否在真实车辆上稳定处理复杂交通交互，将决定其技术方案能够走多远。