NVIDIA发布Halos物理AI安全系统

物理AI的安全必须贯穿硬件、软件、AI模型、运行环境和部署生命周期的每一层，而不是部署前的一次性检查——这是NVIDIA在2026年9月21日发布的这篇博文中传递的核心判断，也是其Halos全栈安全系统试图解决的问题。

Physical AI safety means proving that AI-driven machines — AVs, humanoid robots, industrial robots and more — behave safely when their decisions turn into physical action.

为什么现在必须谈这个问题

ABI Research预测到2035年全球L3至L5级自动驾驶汽车保有量将达到4900万辆，Omdia估计2026至2035年间工业机器人部署量约为6000万台。这两个数字放在一起意味着什么？意味着未来十年内，数千万台由AI驱动、能够自主决策并直接作用于物理世界的机器将进入人类共享的道路、工厂和仓库。这不是实验室里的demo，而是大规模商业部署。

自动驾驶经过多年测试和基准评估后正在持续商业化扩张，机器人则正接近类似的拐点。制造商、监管机构、保险公司和工作场所安全团队需要的是证据——证明硬件、软件、AI行为和运行环境能够在无人工干预的情况下协同安全运行。注意这里的措辞：不是"声称安全"，而是"提供证据"。这是从技术自信到工程可验证性的根本转变。

四个结构性变化定义了新安全模型

NVIDIA在文中明确提出四个转变，每一个都值得拆开来看。

动态环境需要上下文感知的安全。道路、工厂和仓库无法通过静态区域或物理屏障完全控制。自主系统必须感知变化的条件、调整行为，并在意外发生时达到安全状态。这句话的潜台词是：传统的"围栏式安全"——把人机隔离、把场景限定——在开放动态环境中已经失效。安全必须从被动隔离转向主动感知与响应。

AI行为需要自己的保障体系。测试必须在传统功能安全（functional safety）之外，评估AI软件本身，使用设计时、运行时和验证时的多层防护栏。新兴标准如ISO/IEC TS 22440开始专门针对AI特有风险。这意味着过去以硬件失效为核心的ISO 26262框架已经不够用了——AI模型的不可解释性、分布外泛化、长尾场景处理，都需要新的方法论。

部署是持续进行的。自动驾驶汽车和机器人通过软件和模型更新、新任务和变化的条件不断演进。实质性变更可能需要额外的安全测试。这一条直接挑战了"一次性认证"的思维模式。如果一台机器人在部署后通过OTA获得了新能力，原有的安全认证还有效吗？NVIDIA的答案是：安全必须被"运营化"（operationalized），贯穿设计、部署和验证全过程。

规模化验证需要仿真和合成数据。潜在场景的数量和复杂性要求将真实世界测试与仿真、合成数据生成和场景重建相结合。这不是锦上添花，而是必要条件——你不可能在真实道路上穷举所有边缘情况，但仿真可以。

Halos到底覆盖了什么

NVIDIA Halos被定义为"首个也是唯一一个面向物理AI的全栈安全系统"。这个"首个也是唯一"需要审慎看待——它反映的是NVIDIA的自我定位，而非独立的第三方评估结论。但拆解其架构，确实能看出覆盖面的广度。

在自动驾驶方向，Halos横跨五层：硬件层由NVIDIA DRIVE AGX Thor提供安全工程化的加速计算，NVIDIA Hyperion提供L4级自动驾驶的全栈车辆平台和参考架构；操作系统和中间件层由Halos OS提供基于ASIL-D认证DriveOS的统一软件基础，Halos Core和Halos Middleware支持系统隔离、监控和确定性通信；端到端模型层由NVIDIA Alpamayo提供开放的推理视觉语言动作模型，为长尾场景带来可解释性；仿真和验证层由Halos Safety Evaluation Framework提供工具和指南；Halos AI Systems Inspection Lab则将安全、网络安全和AI安全要求转化为可重复的检查。

在机器人方向，硬件层由NVIDIA IGX Thor承担，这是一款工业级模块，在单一平台上结合加速计算和功能安全，并配备专用的Functional Safety Island，设计上支持IEC 61508和ISO 13849等标准；软件层由Halos Core for IGX提供故障检测、监控和报告等安全相关运行功能的软件基础；实时感知层由NVIDIA Holoscan Sensor Bridge连接传感器数据与AI及安全相关处理；仿真验证层由Isaac Lab和Omniverse库支持；此外还有一个值得注意的"由外而内安全"（Outside-In Safety）开源蓝图，用外部摄像头和视觉AI代理扩展车载传感器之外的感知范围，支持设施级监控。

谁在真正使用这套系统

客户名单本身就是一种信号。自动驾驶领域，吉利、五十铃、日产（由Wayve软件驱动）和Einride正在NVIDIA Hyperion上构建L4就绪车辆，由Halos OS支持。Uber、Grab、Lyft等出行平台也在使用Hyperion扩展robotaxi的开发与部署。Halos AI Systems Inspection Lab的成员包括AUMOVIO、博世、Gatik、禾赛、Lucid、MIRA、onsemi、PlusAI、索尼、法雷奥和Wayve，覆盖了自动驾驶开发、ADAS、传感器、芯片、系统集成、验证和安全保障的完整链条。

机器人领域，acontis和QNX提供可预测运行安全功能的嵌入式软件，研华和NexCOBOT构建安全设计的NVIDIA IGX系统，英飞凌、恩智浦、意法半导体和德州仪器贡献传感器、安全微控制器等半导体技术。KION Group正在为自主叉车开发功能安全代理，Agility则将NVIDIA IGX Thor和Halos Core集成到其Digit 5人形机器人的安全系统中。

这些名字说明一个问题：物理AI的安全不是某一家公司能独立完成的事。从芯片到传感器到中间件到认证机构，需要整个生态系统的协同。

第三方认证的分量

在自动驾驶方向，TÜV SÜD认证了NVIDIA的汽车产品生命周期软件流程和DriveOS 6.0达到ISO 26262 ASIL D，以及汽车工程流程达到ISO/SAE 21434。TÜV Rheinland还对NVIDIA DRIVE AV进行了独立的UNECE安全评估。在机器人方向，TÜV Rheinland正在检查NVIDIA IGX Thor、Halos OS和Holoscan Sensor Bridge的功能安全认证就绪度。

ASIL D是ISO 26262中最高等级的功能安全要求，通常适用于制动、转向等一旦失效可能致命的关键系统。DriveOS 6.0拿到这个认证，意味着底层操作系统在流程和产品两个维度都经过了独立审核。但需要追问的是：ASIL D认证覆盖的是操作系统层面，而AI模型本身的决策安全性并不在ISO 26262的传统框架内——这正是ISO/IEC TS 22440等新兴标准要填补的空白。

所以这对行业意味着什么

对于自动驾驶和机器人从业者，这篇文章传递的最重要信号是：安全正在从"合规成本"变成"部署前提"。没有可验证的安全证据链，监管机构不会放行，保险公司不会承保，工作场所安全团队不会签字。NVIDIA Halos试图做的，是把安全从每个项目各自为战的工程问题，变成一套可复用、可检查、可认证的基础设施。

对于整个物理AI赛道，这意味着竞争维度正在升级。过去比的是谁的模型更强、谁的demo更炫，现在比的是谁能提供从芯片到仿真到认证的完整安全证据链。NVIDIA通过Halos把安全能力平台化，本质上是在构建新的护城河——你可以用别人的芯片，但你的安全验证流程、仿真工具链、认证路径可能都绕不开Halos生态。

对于监管和标准制定者，ISO/IEC TS 22440的出现和TÜV等机构对AI安全评估的介入，标志着AI治理正在从原则性讨论走向可操作的技术标准。但标准能否跟上AI模型迭代的速度，仍是一个未解的问题——当一台机器人的AI模型每季度更新一次，安全认证如何保持同步？NVIDIA给出的答案是"持续运营化的安全"，但这套机制的实际效果，还需要在真实部署中检验。