英伟达：物理AI规模化部署，安全必须覆盖每一层

2026年9月21日，英伟达（NVIDIA）在官方博客发布文章，作者为 Riccardo Mariani，标题直译为「为什么大规模部署物理AI要求每一层都有安全保障」。文章的核心主张很直接：当自动驾驶汽车、人形机器人、工业机器人等由AI驱动的机器走上道路、进入工厂和仓库，与人共处同一空间时，安全必须贯穿硬件、软件、AI模型、运行环境和整个部署生命周期，而不能只是部署前做一次性检查。 文章先用两组预测数字说明规模。ABI Research 预计，到2035年L3至L5级自动驾驶车辆的装机量将达到4900万辆；Omdia 估计，2026年至2035年间全球将部署约6000万台工业机器人。数量越大，单次失误的社会成本越高，监管机构、保险公司和工作场所安全团队就越需要看得见、查得到的证据，证明硬件、软件、AI行为和运行环境能够在没有人工干预的情况下协同安全运行。文章对「物理AI安全」的定义也很明确：证明AI驱动的机器在决策转化为物理动作时行为安全。

为什么需要新的安全模型？文章归纳了四个转变。第一，动态环境要求情境感知式安全。道路、工厂和仓库无法完全靠静态隔离区或物理围栏来控制，自主系统必须感知变化中的条件、调整行为，并在意外发生时进入安全状态。第二，AI行为需要独立的保证。测试要在传统功能安全之外评估AI软件，并在设计时、运行时和验证时设置护栏；ISO/IEC TS 22440 等新兴标准已开始处理这类AI特有风险。第三，部署是持续的过程。自动驾驶车辆和机器人会通过软件与模型更新、新任务和变化的工况不断演进，重大变更可能需要追加安全测试。第四，规模化验证离不开仿真与合成数据。场景数量与复杂度太大，必须把真实世界测试与仿真、合成数据生成和场景重建结合起来。

在这个框架下，英伟达推出的是 Halos，文章称其为「首个也是唯一的物理AI全栈安全系统」。这一说法出自厂商本身，读者应作为厂商主张看待。英伟达称其安全基础建立在十余年自动驾驶安全研发之上，涵盖功能安全、传感器融合、AI行为保证、视觉AI、仿真和真实世界验证。同时文章强调，原则在自动驾驶与机器人之间通用，但平台、标准和证据因领域而异。 自动驾驶侧，Halos 分四层。硬件层：NVIDIA DRIVE AGX Thor 提供按安全工程设计的加速计算，NVIDIA Hyperion 提供面向L4自动驾驶的整车平台与参考架构。操作系统与中间件层：Halos OS 构建在通过 ASIL-D 认证的 DriveOS 之上，Halos Core 与 Halos Middleware 支持系统隔离、监控和确定性通信。端到端模型层：NVIDIA Alpamayo 提供开放的推理式视觉语言动作模型，为长尾场景带来可解释性。仿真与验证层：NVIDIA Halos Safety Evaluation Framework 提供工具和指南，用于生成支撑不同自动化等级安全论证（safety case）的证据。这些部分把云端的AI开发和仿真与车内部署连接起来，使安全证据能在整个车辆生命周期内保持可追溯。

机器人侧，Halos 同样分层。硬件：NVIDIA IGX Thor 是工业级模块，在同一平台上结合加速计算与功能安全，带有专用的功能安全岛（Functional Safety Island），面向 IEC 61508 和 ISO 13849 等标准开发的系统。软件：面向 IGX 的 Halos Core 提供安全相关运行功能的软件基础，包括故障检测、监控与报告，以及连接传感器、执行器和其他安全组件的通信与处理能力。实时感知：NVIDIA Holoscan Sensor Bridge 把传感器数据与AI及安全相关处理连接起来，帮助系统识别无效信息并执行预定义的安全响应。仿真与验证：NVIDIA Isaac Lab 与 Omniverse 库让开发者在各种相关工况和边缘情形下测试机器人行为，补充真实世界验证。由内向外的安全：开源的 NVIDIA Halos Outside-In Safety Blueprint 利用外部摄像头和视觉AI智能体，把感知范围扩展到机载传感器之外，支持设施级监控和功能安全用例。此外，文章还提到 NVIDIA Halos AI Systems Inspection Lab，不过所提供的原文在此处被截断，细节无从核实。

从机制上看，这套设计有三个值得注意的点。其一，安全被拆成可分别举证的层，每层对应具体的标准或认证，例如 ASIL-D、IEC 61508、ISO 13849，而不是一个笼统的「模型很安全」。其二，AI模型被当作需要自己护栏的组件：设计时、运行时、验证时三类护栏，与传统功能安全并行。其三，外部视角被纳入系统：Outside-In 蓝图用场地摄像头补足机载传感器的盲区，这与「环境无法完全用围栏控制」的前提相呼应。需要说明的是，所提供的原文没有给出性能基准、延迟数字、价格或成本数据，本文也不据此推测。

对开发者和企业的实际意义主要在流程层面。开发团队需要把安全证据当作持续产出的工件：每次模型或软件更新，都要判断是否构成重大变更、是否要追加测试，并把仿真、合成数据和真实测试的结果串成可追溯的证据链。对采购方、保险公司和监管者而言，统一的参考架构和标准映射降低了评估门槛，但也意味着评估要看证据本身，而不是供应商的品牌。对整个生态来说，安全正在从合规成本变成规模化部署的前置条件，谁能更快地产出可审计的证据，谁就更容易拿到商业许可。 挑战与展望同样清楚。第一，ISO/IEC TS 22440 是技术规范，仍属早期，AI安全的度量方法和接受准则还在形成，全栈方案与标准之间的映射需要独立审核。第二，全栈整合有锁定风险：当硬件、操作系统、模型和验证工具来自同一家厂商时，客户的迁移成本和议价空间值得关注。第三，仿真到现实的差距始终存在，合成数据能覆盖多少长尾场景，需要外部验证而非厂商自述。第四，持续部署意味着安全论证是活文档，维护成本会随车队和机器人数量增长。总体看，这篇文章更像是英伟达对物理AI安全路线的定位陈述，而不是新技术的发布；它的价值在于把行业讨论从「能不能跑」推向「能不能证明安全」。