英伟达Alpamayo 2 Edge：2.45B骨干+0.2B专家，端到端智驾怎么跑？

它叫 Alpamayo 2 Edge，是英伟达11月10日刚推出的一款端到端自动驾驶模型。VLM 骨干约 2.45B、动作专家约 0.2B，运行在车规级芯片 DRIVE AGX Thor 上。

不过“懂端到端”这四个字，倒真不是标题党在蹭流量。眼下各路 AI 争相替人说话、大模型一个劲儿自言自语，英伟达力挺的这姑娘（划掉）这模型，是真·人间清醒。

按照英伟达的设想，Alpamayo 2 Edge 要让车里的 AI 不光能看懂路，还能理清复杂的交通关系、判断潜在风险，再依据场景自己生成驾驶动作。说白了，就是让 AI 从会看、会理解，再往前走到会开车。

当然，让 AI 在服务器里做推理，跟让它在高速行驶的车里做推理，完全是两码事。车载算力就那么多，响应时间也卡得很死，模型既得扛住复杂场景的推理，又不能让大把计算资源耗在没完没了的思考上。

针对这个矛盾，Alpamayo 2 Edge 拿出了一套新设计：普通端到端模型输入图像、直接输出轨迹，中间过程是个黑箱。Alpamayo 2 Edge 则被强制生成 Chain-of-Causation（因果链）推理——不只要把车开起来，还得讲清楚为什么这么开。

那么，汽车到底需要怎样一个“懂端到端”的 AI，才能既想得明白，又开得及时？这套新 VLA 给出的技术方案挺有意思。

01

让模型自己决定推理开销

Alpamayo 2 Edge 的一个核心设计，是让模型学会判断什么时候需要展开完整推理。自回归语言模型下，推理文本越长，生成耗时越高；而车载系统还得给视觉编码和轨迹生成留出计算资源。

为此，NVIDIA 引入了 Adaptive Reasoning，并设计了特殊标记 <NOMINAL>。模型一旦判断当前属于常规驾驶状态，就可以直接输出这个标记，终止显式推理文本的生成；碰上复杂的交通交互，再生成完整的 Chain-of-Causation（CoC）推理链。

有个关键点容易被误读：<NOMINAL> 并不等于把视觉网络关掉，模型也没有绕过之后的动作计算。它动的是语言模型的输出形式，让常规场景下用掉的推理 Token 变少。公开架构里看不到单独的外置风险分类器，至于两种输出模式如何取舍，只能靠模型在训练过程中自己学。

那模型又怎么知道什么场景需要推理？这就牵涉到 CoC 的数据构建。

NVIDIA 的自动标注流程先从车辆轨迹里提取 Meta-Action，也就是自车的高层运动行为，再依据行为发生变化的时间点定位关键帧，然后调用 VLM 生成场景因素与驾驶动作之间的因果解释。标注还要过一道验证：解释有没有画面依据，描述的动作跟实际轨迹对不对得上。

这里有个重要的设计取舍：驾驶视频里全是连续画面，可并不是每一帧都会产生新的驾驶决策。要是逐帧生成推理文本，训练集很容易堆进大量重复描述。

以 Meta-Action 变化为锚点，监督就能集中在车辆行为发生变化的时刻，让模型去学障碍物、交通参与者和道路条件是怎么影响自车动作的。

NVIDIA 用 Alpamayo 2 Super 来生成 CoC 自动标注，再通过离线蒸馏训练 Edge 模型。公开数据约包含 115,000 小时多摄像头驾驶视频，以及 370 万条 CoC 推理标注。

举个例子，前方车辆减速时，模型得结合左侧来车、道路边界和自身速度，判断能不能绕行。CoC 要表达这些因素与减速、等待或转向之间的联系，同时不能引用决策发生之后才出现的信息。

这样一来，模型学到的东西分两层：复杂场景下怎么组织因果解释，常规场景下什么时候可以省掉显式解释。前者提供驾驶推理监督，后者控制文本生成成本。

不过，自动生成的 CoC 仍可能继承教师模型的偏差，解释和实际驾驶动作是否一致，还得在后续训练中检验。

02

从看懂场景到输出连续轨迹

场景分析做完，模型还得把判断变成车辆能执行的运动轨迹。这项活儿，Alpamayo 2 Edge 交给了独立的 Diffusion Action Expert（约 0.2B 参数），与 VLM 骨干（约 2.45B 参数）搭成双模块架构。

输入设计同样围绕驾驶场景展开。模型每轮处理 6 路摄像头、22 帧图像。前向广角和长焦各给 5 帧，覆盖过去 2 秒、1 秒、0.5 秒、0.1 秒和当前时刻；左右侧向与后向四路摄像头各给 3 帧，覆盖过去 1 秒、0.1 秒和当前时刻。

前向摄像头保留更密集的历史信息，用来识别道路变化和前方交通参与者的运动状态；侧后方画面则补充周边车辆信息。除此之外，模型还接收 20 个历史 Ego Pose，按 0.1 秒间隔覆盖过去 1.9 秒，并转换到当前自车坐标系。

这里的 Ego Pose 很关键。摄像头提供外部环境的视觉信息，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。连续控制目标对语言视觉骨干的梯度干扰因此被削弱，两个模块各管各的：一个优化语义理解，一个优化运动生成。

问题也随之而来。VLM 对场景的理解要是出了偏差，动作专家没法用自己的训练损失直接修正上游表征。模型因此还需要一套独立评价机制，既检查推理文本有没有场景依据，也检查生成的轨迹是否对得上对应的驾驶意图。

03

让推理质量进入训练反馈

为此 NVIDIA 引入 AlpaJudge，把 CoC 推理质量变成可评估的训练信号。它有两个版本：Reference-Based（RB）和 Reference-Free（RF）。

RB 的输入是问题、参考解释和模型生成的候选解释，由它判断两段文本的对齐程度，图像并不读取。所以它适合已有专家标注的样本，却没法独立判断解释是否符合实际画面。

RF 则不需要参考解释。前向广角和长焦摄像头画面、自车 Meta-Action 历史与未来，再加上模型生成的 CoC，都是它的输入。推理质量从五个维度评：动作匹配、安全性、场景依据、要素完整性和因果一致性。

综合评分里，动作匹配与安全性被合并为动作评分，占 60%；场景依据、要素完整性和因果一致性构成另外 40%。驾驶行为与语言解释就这样被放进同一套评价框架，光看文本流不流畅来判断推理质量的做法被避开了。

因为用到了未来 Meta-Action，RF 主要用于离线评估和训练，不参与车辆实时决策。它管的是两件事：模型生成的解释是否符合场景证据，解释表达的驾驶意图是否与实际动作对应。

AlpaJudge 还参与训练数据筛选。NVIDIA 的实验显示，评分筛选之后，中间分数样本在精选数据中的占比从原始数据的 27% 提高到 81%。中间分数样本往往保留更多学习空间；低分样本可能来自错误标注，也可能对应模型尚未掌握的困难场景，仍需人工复核。

评分机制进一步进入后训练。模型生成候选 CoC 和轨迹后，训练流程结合推理质量、轨迹误差与驾驶舒适度计算奖励，同时保留轨迹质量约束，免得模型只顾优化解释文本。

NVIDIA 在一组基于 Alpamayo 2 Super 的后训练实验中发现：使用 AlpaJudge 奖励，模型评分提升 10.2%，人工评价提升 11.4%；换成基线奖励，模型评分提升 13.4%，人工评价却只提升 1.8%。两组结果说明，模型自身评分与人工判断之间可能存在偏差，推理奖励需要经过人工校准。

不过，AlpaJudge 只能评价模型生成的解释，连续驾驶中的动作后果它衡量不了。NVIDIA 于是又把模型接入 AlpaGym 和 AlpaSim，做闭环强化学习。

仿真环境里，模型接收摄像头画面、自车状态和路线信息，生成轨迹后交给仿真车辆执行，环境再返回新的画面和运动状态，模型接着做下一轮决策。训练过程因此能观察到当前动作如何影响后续场景，并根据连续驾驶结果更新策略。

NVIDIA 披露，Alpamayo 2 Edge 经过闭环强化学习后，驾驶表现较未使用该轮 RL 的较优检查点提升 48.9%。在 AlpaSim 的 875 个场景中，每个场景执行三组 rollout，平均每发生一次责任事故或驶离道路事件前行驶约 15.15 公里。

开放环评估使用 1,392 条样本，在 5 秒处测得 minADE₆ 为 0.52 米。两组数据量的不是一回事：闭环结果反映模型在持续交互中的驾驶表现，开放环结果衡量固定输入下的轨迹误差。AlpaJudge 检查解释质量，AlpaGym 检验动作后果，训练反馈因此分出了不同层面。

模型训练完成后，还要针对 DRIVE AGX Thor 做推理优化。NVIDIA 提供的部署流程包含 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 的参考配置下，NVIDIA 公布的 Pixel-to-Trajectory 时延为 160–190 ms，具体取决于 CoC 文本长度。

模型从拿到图像输入到输出轨迹，推理环节花掉的时间就是这一数字；传感器采集、定位、控制器执行与安全监控这几块合起来构成的整车响应周期，并不算在里面。

04

“会说话”不难，难的是“说得起”。

传统端到端模型被人挑毛病，重点不在开得好不好，而在说不清自己为什么这么开。Alpamayo 2 Edge 的因果链推理就是冲着这一点来的：它给出的不是“前方有车→刹车”这种结果，而是一整套因果解释。

从 Alpamayo 2 Edge 展示的技术路线看，自动驾驶 VLA 的研发已经走到更具体的一步：模型得看道路状况来决定推理挖多深，还得把对场景的理解变成符合车辆运动学的连续动作。

这套设计的用意不难读出来：既然你说自己懂因果，那就交给评分器去判。英伟达也专门提醒过，推理分高不等于车开得好，必须跟碰撞、偏离车道、轨迹误差这些指标放在一起报告。

与此同时，模型被提了两方面要求：一是判断当前交通环境里哪些因素会影响驾驶决策，二是管住推理过程带来的计算开销，好让后续轨迹生成赶得上时间。

这里有一个很现实的工程矛盾。模型对复杂场景判断不足，就可能过早切进 NOMINAL 模式，漏掉本该处理的交通因素；可要是模型频繁展开长 CoC，语言解码又会吃掉更多时间，拖累整条推理链路的执行效率。

所以自适应推理的效果，不能光看文本质量，还得把模式选择、轨迹质量和实际响应时间放在一起评估。尤其在连续的交通交互里，模型能不能及时察觉场景变化、在需要时调整推理策略，会直接影响到后面的驾驶动作。

回到开篇那个问题：我们要的是 AI“真懂”，还是“表现得懂”、懂到足以通过 AlpaJudge？

就目前公布的结果来看，NVIDIA 已经把模型架构、自动标注、强化学习和车载部署之间的完整技术路径摆了出来，但仿真环境里的表现，还得拿到不同道路条件、传感器组合和车辆动力学环境里去检验。

对自动驾驶来说，模型生成轨迹只是决策链路里的一环。Alpamayo 2 Edge 把推理过程也纳入了计算资源分配和训练优化，VLA 的工程设计空间因此又宽了一些。

接下来，这套架构能不能在真实车辆上稳住复杂交通交互，将决定它的技术方案能走多远。

参考链接：https://developer.nvidia.com/blog/running-av-reasoning-models-within-onboard-compute-and-latency-limits