自动驾驶开发者需要能在车载系统的算力和延迟约束内运行的推理模型。更大规模的模型为开发这些能力提供了基础，但要将其部署到车辆中，还需要进行额外工作来缩减模型体积、保留有用的推理能力，并在目标硬件上验证性能表现。
NVIDIA Alpamayo 2 Edge 正是针对这一需求推出的自适应推理视觉-语言-动作（VLA）模型，专为在 NVIDIA DRIVE AGX Thor 上实时运行而设计。该模型基于 NVIDIA Cosmos 3 Edge 的 20 亿参数 Nemotron 推理骨干网络构建，并搭配一个扩散式动作专家模块，利用环视摄像头观测数据、时序上下文和导航输入来生成因果链（Chain-of-Causation，CoC）推理及未来行驶轨迹。该模型具备自适应推理能力，仅在需要时生成推理内容，从而减少不必要的 Token 生成，在常规驾驶场景下节省推理算力。
Alpamayo 2 Edge 在 NVIDIA AlpaGym 中通过闭环强化学习（RL）进行后训练，相较于未使用闭环强化学习的最优检查点，其闭环驾驶性能提升了 48.9%。这些能力共同为开发者提供了一个强大的、适配边缘计算的基础，助力将基于推理的驾驶能力引入车载系统栈中。
要让推理模型足够紧凑以适配车载部署，一个关键挑战随之而来：在缩减模型规模的同时，保留其推理质量和驾驶行为的表现。这需要一种衡量推理质量的方法，并利用该反馈来改进模型。NVIDIA AlpaJudge 是用于 Alpamayo 2 Edge 开发过程的人工校准评估与奖励模型，用于评估推理轨迹、筛选高价值训练数据，并提供强化学习奖励信号。
本文将介绍 Alpamayo 2 Edge，阐述其在 DRIVE AGX Thor 上的推理优化方案，并探讨在自动驾驶开发流程中使用 AlpaJudge 的三种方式：
在 PhysicalAI-AV 样本上运行 AlpaJudge-RB 和 AlpaJudge-RF，检查其评分结果，并将评估方法适配到策略生成的推理内容上
筛选能够揭示有用学习机会的训练样本
使用与人类评判一致的推理评分作为后训练的奖励信号
这些工作流程共同将面向边缘计算的驾驶模型与一套可重复的测量和改进流程连接起来。
将基于推理的驾驶能力带到边缘端
车载驾驶模型必须在系统的推理预算内，解读不断变化的场景并生成有用的行驶轨迹。关键问题在于，模型在这一约束下能保留多少驾驶和推理能力。
为了平衡模型容量与效率，Alpamayo 2 Edge 采用了多项新特性：
一个基于 Nemotron 的 20 亿参数推理骨干网络，其规模适配车载推理需求
自适应推理机制，减少不必要的 Token 生成，在常规驾驶场景下节省推理算力
离线蒸馏，使用 Alpamayo 2 Super 生成的 CoC 推理自动标注数据进行训练
在 AlpaGym 中进行闭环强化学习后训练，模型在仿真环境中端到端地从自身行动的后果中学习
多分辨率输入，高效地在线编码环视观测数据
采用 DFlash2 的推测解码技术，在不牺牲质量的前提下加速在线推理
借助 NVIDIA TensorRT 和 NVIDIA TensorRT-Edge-LLM 实现量化和推理加速方案
下图展示了这些设计选择如何转化为实际能力，将 Alpamayo 2 Edge 与 Qwen-Drive-1.0 在闭环驾驶、开环轨迹预测以及场景理解与推理方面进行了对比。
早期合作伙伴的反馈也印证了 Alpamayo 2 Edge 在驾驶性能和推理速度方面的表现：
"在获得 Alpamayo 2 Edge 的早期访问权限后几天内，我们就让它在基于我们自己伦敦街道录像重建的 NuRec 场景中实现了闭环运行。在早期仿真测试中，Edge 保持车道的成功率是 Alpamayo 1.5 的两倍多，从车道偏移中恢复的频率高出约 40%，而且在相同 GPU 上，开箱即用的规划速度大约是我们手动调优的 Alpamayo 1.5 服务器的两倍。" ——PORT 公司首席技术官 Matas Simonavicius
"尽管传感器配置存在较大差异，但在零样本评估中，Alpamayo 2 Edge 展现出令人印象深刻的泛化能力，相较于 Alpamayo 2 Super，其位移误差（minADE）降低了 13.6%，3 秒时的横向预测误差（RMSE）降低了 46.1%。在我们自己的驾驶数据上进行微调后，相较于 Alpamayo 2 Edge 基线模型，位移误差进一步降低了 44.2%。从拿到模型到在真实车辆上完成首次测试，我们只用了几天时间。" ——Niulinx 联合创始人兼运动规划负责人 Luca Crotti
"在不到 48 小时内，我们就让 NVIDIA 的 Alpamayo 2 Edge 在 AGX Thor 上以 10 Hz 的频率实现了实时规划运行。"——Embedl 首席执行官兼联合创始人 Hans Salomonsson
Alpamayo 2 Edge 代码库中的推理脚本展示了该模型的运行方式：它接收随时间变化的环视摄像头观测数据、导航文本以及历史自车运动信息，生成 CoC 推理轨迹和未来行驶轨迹。
（代码示例略）
值得注意的是，该模型现在有时会生成特殊的 <NOMINAL> 标记来代替推理轨迹，以此表示当前为常规驾驶状态，从而节省推理算力。
部署过程中保持质量稳定
从 Hugging Face 下载模型时，默认情况下 Alpamayo 2 Edge 的权重以 BF16 格式表示，可直接作为 PyTorch 模型在任何受支持的 NVIDIA GPU 上运行。然而，要在 DRIVE AGX Thor 上实现实时运行，Alpamayo 2 Edge 还需要进一步进行推理优化。
Alpamayo 开发者中心提供了 DRIVE AGX Thor 部署工作流程的完整方案：准备 Alpamayo 2 Edge 检查点和 DFlash2 草稿模型、校准 FP8 精度范围、导出 ONNX 计算图、使用 TensorRT Edge-LLM 插件构建 TensorRT 引擎，并运行 Python 测试工具。该方案的参考配置是在搭载 DRIVE OS 7.2.7.0、CUDA 13.4 和 TensorRT 11.3.1.9 的 DRIVE AGX Thor-X 上测得的。
按照 Alpamayo 2 Edge 部署方案完成模型、评估输入和引擎的准备工作后，即可运行该程序包（命令示例略）。
该方案详细记录了导出、构建、校准溯源、硬件要求以及各阶段的性能测量数据，方便开发者在自己的 DRIVE AGX Thor 配置上复现延迟和配对质量检验结果。作为参考，优化后的模型从像素输入到轨迹输出的推理延迟为 160 毫秒至 190 毫秒，具体取决于推理量的多少。相同的方案检验还将优化后的模型输出与基于相同输入和固定种子动作噪声构建的 BF16 PyTorch 参考模型进行了比较。
使用 AlpaJudge 评估推理能力
轨迹指标描述的是模型如何进行规划或驾驶。而推理评估则增加了另一个维度：模型的解释是否识别出了相关的场景背景，以及是否支撑了其所描述的决策。AlpaJudge 为 Alpamayo 2 Edge（以及此前的模型）开发过程中这一方面的评估提供了人工校准的评判工具。以下工作流程描述了如何开展这种评估，以及如何将其用于模型改进。
根据可用输入选择合适的评判模型
AlpaJudge 提供两种检查点变体。应根据待评估样本可用的证据类型来选择相应变体。
RB（基于参考）衡量的是与所提供参考答案的一致程度，而非独立核查场景本身。RF（无需参考）不需要参考推理依据，但需要同步的视觉证据和格式化的元动作背景信息。
工作流程一：在 PhysicalAI-AV 样本上运行 AlpaJudge
示例笔记本提供了一个很好的入门起点，可视化展示数据、元动作背景、候选推理依据以及与 PhysicalAI-AV 样本相关联的参考推理依据。随后可用策略生成的 CoC 轨迹对同一记录重新评分。在输出中保留片段 ID、时间戳、摄像头名称和动作背景信息，以便在评分较低时能够追溯到具体场景。
在开环评估中，可将候选解释和轨迹与记录的标注进行比较。在闭环评估中，可利用该次演练中的观测和动作背景信息，对策略每次决策时的解释进行评分。较高的推理评分表明推理依据符合评判标准，而碰撞、偏离道路、近距离接触和轨迹等指标则分别描述驾驶行为的不同方面。应将这些指标一并呈现。
第一步：搭建环境并打开笔记本
（具体命令示例略）
笔记本使用的是片段 030c760c-ae38-49aa-9ad8-f5650a545d26 中 5.1 秒处的画面。它解码了前广角和前长焦摄像头在 -1.0 秒、-0.5 秒和 0.0 秒（按时间先后排序）的画面帧。示例中的推理依据和元动作字符串是人工编写的，数据集提供的是摄像头画面。若使用不同的时刻，需同时替换所有文本字段。
第二步：下载两个评判模型检查点
（具体细节略，模型加载需要 CUDA GPU，权重大约需要 5GB 显存，不含激活值所需空间）
第三步：评分并检查两种输出结果
先运行笔记本中固定的施工区域样本。使用记录的检查点和输入数据，冒烟测试报告的 RB 一致性得分为 0.999，RF 综合得分为 0.842。RF 的五项子评分分别评估动作/参考一致性、动作安全性、组件锚定性、组件完整性和因果一致性。
（代码示例略）
若要评估 Alpamayo 2 Edge 本身，需在所选片段上运行其推理脚本，并检查 output.json 中 text.cot 字段下生成的推理依据。在加载 AlpaJudge-RF 的六帧画面时，使用相同的片段和决策时刻，并用生成的字符串替换笔记本中手动编写的推理依据。提供与此决策相匹配的元动作历史和未来信息，而非直接套用笔记本中施工场景的示例。如果有专家参考 CoC 轨迹可用，可将其作为 answer 传入 RB，并将 Edge 生成的 CoC 作为 student 传入。
工作流程二：筛选高价值训练样本
AlpaJudge 的评分在训练数据筛选中很有价值，因为得分最高和最低的样本往往服务于不同目的。基于参考的评分极低可能表明存在标签不匹配、演练失败或确实是困难案例。应在丢弃这些案例前进行审查；一概剔除低分片段也会移除策略需要学习的稀有失败案例。而得分极高则可能说明当前模型已经能够始终如一地解释这些场景，从中已学不到太多新内容。中间范围的数据往往对进一步训练最具参考价值。
将此方法应用于自有数据集，首先需要每个片段的候选 CoC 演练结果和固定的 AlpaJudge 检查点。对每个候选结果与配对的参考答案进行评分（若使用 AlpaJudge-RB），记录评分、片段 ID 以及任何场景元数据，然后对低分和安全关键案例进行人工审查。在开发集上设定筛选阈值，按场景类型和驾驶操作对保留集进行分层，并保持留出的评估集不受影响。对信息量大的片段进行重采样用于进一步训练，并将新检查点与相同的基线集进行比较。
工作流程三：将推理评分用于后训练
公开的 Alpamayo 强化学习方案提供了一个具体范例，展示了如何在开环 GRPO 训练中加入推理奖励。该方案生成多组策略演练结果，解码每个 CoC 和轨迹，计算轨迹误差和舒适度，然后调用一个可插拔的推理评判模块，最终将这些项组合为一个标量奖励值。当每个样本都有参考推理轨迹时，AlpaJudge-RB 可作为该评判模块：传入固定的驾驶问题、参考答案作为 answer、采样得到的 CoC 作为 student，然后将返回的一致性概率作为推理信号。
可以通过将文本对批量传入 score_reference_based 函数，编写一个适配器来实现该方案中 BaseReasoningGrader.score(predictions, references) -> Tensor[N] 的接口规范。将该适配器注册到 GRADER_REGISTRY 中，并将推理奖励配置指向对应的检查点。奖励函数应保留其轨迹门控机制，并同时记录两项分量得分，这样策略就不太可能仅凭流畅但错误的驾驶解释而获得高额总奖励。
开始使用 Alpamayo 2 Edge 和 AlpaJudge
这些工作流程构成了一个可重复的开发循环：运行边缘模型、结合轨迹和安全指标对其推理进行评分、筛选高信息量片段，并将下一个候选模型与初始基线进行比较。对于同时使用强化学习训练策略的团队，AlpaJudge 可以通过如上所述的适配器提供推理奖励信号。
可在 Hugging Face 上探索 Alpamayo 2 Edge 和 AlpaJudge。如需讨论和开发者问答，请访问 Alpamayo 开发者论坛。如需了解更多信息，可查阅 Alpamayo 开放平台及其最新发布版本，以及支撑 Alpamayo 开发的前沿研究成果。
