Mercedes-Benz 与 NVIDIA 自动驾驶合作将安全主张置于检验之下

Mercedes-Benz 和 NVIDIA 于 2026 年 10 月 16 日扩大了自动驾驶联盟，尽管安全验证、驾驶员责任和真实世界部署等问题仍未得到解决。如今，Mercedes-Benz 与 NVIDIA 的自动驾驶合作涵盖的技术栈，已远超普通芯片供应协议。

两家公司计划将 Mercedes-Benz 的车辆工程和 MB.OS，与 NVIDIA Hyperion 硬件、Alpamayo 驾驶软件以及 Halos 安全系统相结合。这一组合将支持现有驾驶辅助、城市点到点驾驶、自动泊车以及未来的 SAE Level 4 应用。

此次公告也是对 Tesla 和 Waymo 的战略回应。这两家竞争对手在各自的驾驶系统中拥有更多内部控制权。Mercedes-Benz 押注，汽车制造商与 AI 基础设施公司能够在不放弃对车辆、品牌或客户体验控制权的前提下，实现同等程度的整合。

这使得该合作比又一项汽车 AI 公告更具影响力。真正的竞争发生在共享平台与专有自动驾驶项目之间。Mercedes-Benz 和 NVIDIA 现在需要证明，双方分担的职责能够形成统一、可验证的安全论证。

Mercedes-Benz 与 NVIDIA 的自动驾驶合作超越单一车型

扩展后的协议将现有的量产合作关系转化为覆盖多个车辆自动化等级的共同路线图。

Mercedes-Benz 和 NVIDIA 在一份从 Stuttgart 和 Santa Clara 发布的联合公告中介绍了此次合作延展。两家公司没有披露合同金额、排他期限，也没有公布每项计划功能的具体上市时间表。

双方的自动驾驶协议列出了四个核心组成部分。Mercedes-Benz 提供 MB.OS——其车辆操作系统——以及汽车工程和安全流程。NVIDIA 提供 Hyperion、Alpamayo Stack 和 Halos。

MB.OS 协调车辆核心领域，包括自动驾驶、信息娱乐、舒适功能和充电。它还为 Mercedes-Benz 提供了一个软件层，可通过空中更新交付经批准的功能。

NVIDIA Hyperion 是一种参考架构，将车辆计算机与摄像头、雷达、激光雷达及其他传感器连接起来。参考架构定义了兼容的硬件和软件组件应如何在量产车辆内部协同工作。

Alpamayo Stack 提供具备感知、规划和 AI 推理能力的驾驶软件。NVIDIA 表示，该软件能够评估复杂交通情境，同时支持城市辅助驾驶、主动安全和自动泊车。

Halos 是 NVIDIA 面向 AI 驱动车辆的安全框架。该系统包括开发流程、验证工具、硬件保障措施，以及旨在约束 AI 行为的并行安全栈。

这种并行设计很重要。AI 模型可以解读异常场景并提出驾驶动作，而一条更可预测的软件路径则会检查该动作是否处于既定安全边界内。

两家公司表示，这些技术将支持高级驾驶辅助系统和未来的 SAE Level 4 车辆。Level 4 意味着，自动化系统可在定义的运行区域内完成全部驾驶任务，无需期待人类接管。

这一描述并不意味着每一辆搭载 NVIDIA 技术的 Mercedes 都会成为自动驾驶车辆。自动化等级取决于车辆、传感器、软件审批、运行条件和当地法规。

Mercedes-Benz 已为这一更广泛的计划奠定了量产基础。其 MB.DRIVE ASSIST PRO 系统提供先进的 SAE Level 2 辅助，这意味着驾驶员仍负有责任，且必须监督车辆。

据 Mercedes-Benz 介绍，该系统在 2025 年底前已于中国上市。公司还计划在 2026 年期间将其引入美国。

当前配置使用约 30 个传感器，包括 10 个摄像头、5 个雷达传感器和 12 个超声波传感器。Mercedes-Benz 列出的计算性能最高可达每秒 508 万亿次运算。

这些数字显示出现代辅助系统需要多少感知与处理能力。它们并不能证明该系统能够在无人监督的情况下安全运行。

因此，扩展后的协议改变的是合作规模，而非当前功能的法律含义。它将已在交付的 Level 2 产品，与迈向更高自动化程度私人车辆和自动驾驶豪华轿车的发展路径连接起来。

它还连接了软件更新、AI 训练、仿真、车辆集成和量产验证。合作伙伴不再只是共同解决一个孤立功能，而是在为多个车型项目构建可复用的基础。

更广泛的范围也造成了核心张力。通用平台可以缩短开发周期，但每增加一个应用场景，工程师必须预见和控制的故障集合就会扩大。

NVIDIA Hyperion 对 Mercedes-Benz 为何重要

Mercedes-Benz 正利用 NVIDIA 的平台分摊自动驾驶成本，同时让 MB.OS 位于技术供应商与客户之间。

在内部开发自动驾驶技术，所需的不只是编写车辆软件。汽车制造商还需要专用计算机、传感器接口、训练基础设施、仿真环境、安全工具和庞大的工程团队。

Tesla 围绕自身车辆、驾驶数据、神经网络和定制计算能力构建了其中大部分系统。Waymo 则围绕严格定义的 Level 4 运营构建了一套集成化自动驾驶系统。

Mercedes-Benz 选择了第三条路线。它保留对车辆行为、集成和客户体验的责任，而 NVIDIA 提供计算与 AI 基础的大部分能力。

这一方法让 Mercedes-Benz 能够获得 NVIDIA 汽车客户共享的基础设施。NVIDIA 可以将研发成本分摊至汽车制造商、出行公司和 robotaxi 项目。

对 Mercedes-Benz 而言，这种安排降低了独立复刻每一层技术的需求。随着车型项目从受监督辅助迈向更高自动化，它也提供了能够持续演进的软件基础。

NVIDIA 希望让 Hyperion 成为汽车行业的标准基础。其平台支持不同传感器配置，并允许客户使用选定组件或更完整的 NVIDIA 软件栈。

这种灵活性在商业上至关重要。汽车制造商通常不希望供应商决定车辆的每一个元素，尤其是在软件日益塑造产品差异化和客户数据的情况下。

在这一安排中，MB.OS 充当 Mercedes-Benz 的控制层。即使 NVIDIA 在底层提供重要技术，它仍让汽车制造商能够管理功能、更新及面向驾驶员的界面。

这一架构类似于其他平台市场。供应商打造可复用的计算和软件组件，而制造商将这些组件适配到自己的产品中。

不过，车辆带来的后果比个人电脑或手机更严苛。软件故障可能立即产生物理风险，而车辆平台必须在多年内保持可维护性。

因此，NVIDIA 的汽车战略对 Qualcomm 和 Mobileye 形成的压力，不亚于对 Tesla 或 Waymo 的压力。Qualcomm 销售汽车计算平台，而 Mobileye 则结合芯片、地图、驾驶辅助软件和安全技术。

一项行业平台分析将供应链依赖视为汽车制造商的一项担忧。该分析还指出，Qualcomm 和 Mobileye 提供了相互竞争的方案。

依赖可能以多种形式出现。如果车辆项目与 NVIDIA 的工具、计算硬件、模型格式和验证流程紧密绑定，Mercedes-Benz 可能面临转换成本。

这并不意味着 Mercedes-Benz 会自动失去控制权。该公司可以定义车辆要求、维护 MB.OS、选择传感器、验证功能，并控制经批准功能如何交付给客户。

如果一个通用供应商层变得难以替换，风险就会增加。平台可以在一个产品周期内简化开发，却可能在下一个周期限制架构自由度。

NVIDIA 同样受益于反馈循环。更多车辆项目会带来更多集成经验、测试需求和开发工具。这些改进又能吸引更多制造商。

这正是 Mercedes-Benz 与 NVIDIA 自动驾驶合作的重要性不止于两家公司的原因。它检验的是：共享 AI 平台能否支持差异化车辆，而不会将汽车制造商降格为硬件集成商。

如果这一模式奏效，其他制造商将获得一种替代方案，无需为完整自动驾驶项目投入资金。如果它失败，垂直整合的竞争对手将获得证据，表明关键驾驶技术无法在合作伙伴之间被清晰分割。

Alpamayo 和 Halos 将 AI 推理与安全后备机制结合

这一技术押注将适应性 AI 与独立安全路径结合，因为仅靠学习型行为或固定规则，都无法单独应对每一种驾驶条件。

传统驾驶软件通常依赖分离的阶段：检测物体、预测移动、规划路径和控制车辆。工程师可以检查这些阶段，但脆弱的假设可能会在陌生情境中失效。

端到端 AI 采取了不同方法。它学习传感器输入与驾驶行为之间更强的关联，有望提升其在难以用手写规则应对的复杂场景中的表现。

Alpamayo 通过面向推理的模型扩展了这一思路。NVIDIA 表示，该软件能够在选择穿越异常情境的路径前，评估多种可能动作。

设想一辆配送卡车挡住了城市道路的一部分车道。车辆必须识别障碍物、解读临时道路标线、预判行人，并确定是否适合跨越车道边界。

当系统未曾预料到这种确切布局时，固定系统可能难以应对。推理模型则可以利用更广泛的上下文来评估可用选项。

然而，模型给出看似合理的解释，并不能保证动作安全。AI 系统可能以不可预测的方式失效，尤其是在传感器数据偏离其训练分布时。

NVIDIA 的答案是架构多样性。AI 路径负责感知和复杂规划，而传统安全栈与之并行运行。

安全栈可以执行涉及速度、可用空间、碰撞风险或车辆稳定性的约束。冗余计算可在硬件故障后维持关键功能运行。

传感器多样性提供了另一层保障。摄像头捕捉颜色和视觉细节，雷达估算距离和速度，激光雷达则利用反射光测量三维结构。

每种传感器都有不同弱点。摄像头可能受到眩光或黑暗影响，而雷达提供的视觉细节较少。激光雷达的性能也可能因天气、反射率或污染而变化。

为 S-Class 规划的L4 就绪架构结合了摄像头、雷达和激光雷达。NVIDIA 还描述了冗余计算和独立的软件路径。

“L4-ready”需要谨慎解读。它意味着底层架构旨在支持L4级应用，并不代表该车辆已获准在任何地方自主运行。

L4级系统还需要明确的运行设计域。该范围规定了自动化功能可运行的地点、道路类型、速度、天气条件及其他情境。

Mercedes-Benz和NVIDIA已讨论过基于S-Class打造未来自动驾驶豪华礼宾车。这类车辆可通过出行平台，在获批准区域内提供类似专车司机服务的自动驾驶出行。

受限的商业服务是合乎逻辑的早期应用。车队运营商能够限制路线、监控车辆、维护传感器，并收集详细的性能数据。

私人车辆带来的问题更棘手。车主期待广泛的地理覆盖范围，并且在看到“自动化”标签后，可能误解系统的限制。

Level 2与Level 4之间的区别尤为重要。即使系统控制转向和速度，Level 2仍要求驾驶员持续监督。

在获批准的运行域内，Level 4将驾驶任务交由系统承担。车辆必须在不依赖人类立即干预的情况下处理故障。

这两个级别之间的差距并非简单的软件升级。它改变了责任归属、故障兜底要求、测试证据和监管方式。

Mercedes-Benz通过DRIVE PILOT直接积累了关于这一边界的经验。其有条件自动化Level 3系统，已为在有限条件下获得批准的免手、免眼驾驶建立了更早的路径。

这项新合作并未抹去这段历史。相反，它在Mercedes-Benz既有的正式审批和安全责任经验之上，增加了更广泛、以AI为中心的架构。

这是支持该合作关系最有力的论点。NVIDIA提供大规模AI基础设施，而Mercedes-Benz则提供超越演示阶段所需的整车工程能力和监管纪律。

但这一组合也带来了责任认定问题。当AI行为失效时，调查人员必须弄清原因究竟来自训练数据、模型设计、传感器、集成环节，还是车辆控制系统。

并行安全栈可以降低风险，但无法让责任凭空消失。双方需要提供可追溯的证据，将模型开发与车辆层面的行为联系起来。

自动驾驶安全仍取决于人类行为

两家公司的安全架构旨在应对技术故障，但在监督驾驶中，人们误解系统或停止注意路况同样会导致失败。

Mercedes-Benz表示，Halos通过冗余设计和护栏机制强化其安全基础。这些保障措施具有意义，但合作公告并未公布公开的脱离接管率，或经过独立审查的安全性对比数据。

公告也没有说明每项新功能将如何在各国完成验证。道路设计、标识、驾驶行为、天气和法规在不同市场间存在很大差异。

首个实际考验涉及Level 2辅助驾驶。MB.DRIVE ASSIST PRO可支持点到点城市驾驶，但驾驶员在整个行程中仍需承担责任。

Mercedes-Benz采用协作转向设计，驾驶员可以调整方向，而不会自动停用辅助功能。这种设计可让人机之间的交接不那么突兀。

该系统还依靠摄像头和其他传感器监测周边环境。驾驶员监测控制仍然至关重要，因为系统能力可能助长过度自信。

独立安全研究一再指出这一问题。在一项对14套部分自动化系统的评估中，没有任何一套获得Insurance Institute for Highway Safety的最高评级。

只有一套获得总体“可接受”评级。两套被评为“边缘”，其余系统均被评为“较差”。

这项驾驶员监测研究结果涵盖了包括Mercedes-Benz在内的多家汽车制造商系统。评估重点是防范注意力不集中和滥用的保障措施。

该测试早于完整扩展栈的推出，也并未直接衡量未来的Mercedes-Benz系统。但它仍说明，仅靠更强的驾驶软件无法解决安全问题。

驾驶员往往通过日常出行来校准信任。如果辅助系统连续数周表现良好，人们可能会降低对系统需要帮助这一罕见时刻的准备程度。

而正是在这些罕见时刻，自动驾驶系统会面对最艰难的技术条件。异常施工、紧急车辆、被遮挡的标线或行为不规律的道路参与者，都可能形成陌生的组合情境。

从监督辅助过渡到有条件自动化或高度自动化，也会造成不一致的预期。驾驶员可能会使用多辆界面相似、但法律责任不同的车辆。

清晰的产品命名在这里十分重要。营销必须区分辅助功能与自动化，不能依赖细则说明来完成区分。

控制界面也应清楚展示系统状态。驾驶员需要知道自动化何时可用、正在做什么，以及责任何时发生转移。

Mercedes-Benz与NVIDIA的自动驾驶合作还带来了第二类不确定性。AI推理可以让车辆行为更具灵活性，但这种灵活性会使验证更加复杂。

传统软件可以依据明确要求进行测试。学习型系统则反映训练数据和优化选择，无法始终归结为简单规则。

仿真有助于覆盖更多条件。NVIDIA使用高保真虚拟环境生成场景，并在道路部署前评估驾驶行为。

合成测试对于危险或罕见事件很有价值。工程师可以在改变速度、光照、能见度和参与者行为的同时，数千次重复一次险些碰撞。

仿真仍依赖于模型保真度。虚拟环境无法揭示其设计者未能准确呈现的失效模式。

道路测试则存在相反的局限：它能捕捉现实复杂性，却无法高效复现每一种罕见事件，也无法证明不存在未知故障。

最强的验证计划应结合仿真、封闭场地测试、公共道路运行、事故审查和持续的车队监控。监管机构和独立研究人员也需要获得足够证据来评估相关主张。

Mercedes-Benz的安全声誉提高了标准。客户不会只将该系统与其他驾驶辅助产品比较，也会以该品牌更广泛的、受控且可预测的工程承诺来衡量它。

NVIDIA面临的是不同的可信度考验。它必须证明，一个可复用的平台能够满足不同汽车制造商、传感器配置、车辆动力学特性和监管体系的要求。

任何一家公司都不应仅凭合作公告接受评判。相关证据将来自获批运行域、干预数据、事故报告和独立评估。

因此，核心权衡十分明确：共享AI平台可以更快扩展能力，但更快的迭代也提高了透明验证的负担。

三项信号将显示该合作是否奏效

量产可用性、可信的安全证据和Level 4运营，将决定这项协议会成为基础设施，还是停留在雄心勃勃的路线图上。

第一个信号是MB.DRIVE ASSIST PRO的更广泛部署。在更多车型和市场中推出，将表明Mercedes-Benz能够使NVIDIA技术栈适应不同的交通规则和客户预期。

实际使用比发布公告更重要。驾驶员需要稳定的点到点辅助、易于理解的控制方式，以及在精心安排的演示之外仍可靠的行为表现。

美国市场的推广尤其值得关注。州级法规、联邦监管、多样化道路设计和诉讼风险，为监督式自动化创造了严苛环境。

Mercedes-Benz还必须解释空中更新如何改变系统行为。更新可以迅速修复问题，但也可能在客户已形成预期后改变某项功能。

第二个信号是安全披露的质量。两家公司已描述了冗余硬件、多元传感器、AI推理、仿真和并行软件栈。

这些设计选择建立了可信的工程理论，但并未揭示驾驶员介入的频率、何种条件会导致故障，或性能如何随软件版本变化。

更具体的证据将增强该合作的说服力。有用的披露内容包括运行域限制、碰撞报告、接管行为、故障恢复，以及独立测试结果。

监管批准将提供另一种形式的证据。批准并不能消除风险，但表明某一系统已针对特定用途满足明确的法律和技术要求。

第三个信号是采用Mercedes-Benz车辆和NVIDIA技术的真实Level 4服务。一项商业自动驾驶豪华礼宾车项目，将在持续的运营压力下测试完整系统。

新一代S-Class提供了一个预期基础。Mercedes-Benz与NVIDIA已描述了一种面向未来礼宾式自动驾驶出行的L4-ready车辆架构。

NVIDIA也已将其汽车平台与网约车部署联系起来。相关里程碑不是一辆配备系统的原型车，而是在获批准运行域内、无需预期车内人工兜底、搭载付费乘客的服务。

这样的推出将同时验证多个层面。车辆必须集成冗余硬件、维护传感器、运行驾驶软件、管理远程运营，并满足当地规则。

它还将检验经济性。一辆技术上具备能力的车辆，仍需要实现可接受的利用率、维护成本、清洁、保险和车队支持。

Tesla构成一种比较，因为它力图在同一组织内连接车辆制造、数据、软件和自动驾驶。Waymo则构成另一种比较，因为它依靠专用驾驶系统运营受限的Level 4服务。

Mercedes-Benz与NVIDIA选择合作，而非完全垂直整合。这一路径赋予双方明确的优势，但也在每一个关键层面增加了组织接口。

如果MB.DRIVE ASSIST PRO成功扩展，共享平台将获得量产可信度。如果安全报告变得具体且可独立测试，两家公司的主张将更具分量。

如果基于Mercedes-Benz的Level 4服务开始常规运营，这项合作就不再只是先进辅助驾驶项目。它将证明，汽车制造商与AI供应商能够共同运营高度自动化技术栈。

任何一项信号的失败都会削弱这一结论。有限的可用性将暗示集成问题，稀少的安全证据则会使核心承诺无法得到验证。

Level 4服务若延迟推出，将表明L4-ready架构距离可运营产品仍相去甚远。这种差异在公告中容易被掩盖，但在公共道路上很难隐藏。

Mercedes-Benz与NVIDIA的自动驾驶合作具有连贯的技术论点：将汽车工程、集中式计算、基于推理的AI和独立安全控制结合起来。

更艰难的考验在于制度层面。Mercedes-Benz、NVIDIA、监管机构、车队运营商和驾驶员必须共享信息，同时保持清晰的责任边界。

对开发者和企业采购方而言，这一教训并不止于汽车领域。进入实体运营场景的 AI 系统，需要的不仅是强大的模型，还需要明确边界、持续监控、可追溯的决策机制以及故障回退方案。

评估复杂 AI 项目的团队，也可以将同样的严谨方法用于自身研究。可搜索的工程知识库有助于关联需求、测试结果、事故报告以及不断变化的假设。

关注量产部署、安全证据，以及首个投入运营的 Level 4 服务。这些信号将共同揭示，这一扩大后的联盟能否将共享技术转化为可问责的自动化。