AI 工厂是迄今为止技术上最复杂的运营环境之一。数十万个 GPU、NVIDIA Spectrum-X 以太网横向扩展、横向扩展和横向扩展结构、NVIDIA NVLink 纵向扩展结构、分布式调度器和为期数周的训练均以连续的步长运行。即使不同的团队拥有自己的遥测技术，这些层也能作为一个生产系统发挥作用。在同步分布式训练中，作业以最慢的速度推进。一个性能降低的 GPU、接口、存储设备或交换机路径可能会浪费大量运行良好的资源。
损害产量的故障通常很微妙：GPU 的运行温度比其他 GPU 高出几度。只有在持续负载下，NVMe 设备才会失去性能。交换机会生成类似于数十种不相关症状的暂停帧风暴。所有这些信号都不一定跨越静态值。它们共同创造出杂乱无章、延长步长时间和延迟检查点。
由于证据分散到各个团队，诊断变得更加困难。网络操作员可以看到接口计数器和网络事件。计算运算符可查看节点和 GPU 运行状况。ML 团队会发现步骤时间不断变化、作业失败或推理延迟不稳定。每个视图都是准确的，但它们之间的关系仍然是隐藏的。分诊将成为一系列仪表板搜索和跨团队交接的环节，在识别受影响的节点或网络路径之前，可以将包含的故障转化为数小时或数天的生产时间损失。
本文将介绍围绕 AI 工厂拓扑和工作负载设计的 AI 原生 AIOps 平台 NVIDIA Minerva 如何解决这些运营差距。
NVIDIA Minerva 在整个堆栈中收集遥测数据，将基础设施映射到动态知识图形中的活跃作业，应用专用机器学习，并将相关症状与高保真事件关联起来。AI 智能体驱动的助手和 MCP 服务器连接到外部代理工具，为操作员提供了一条通过相同的实时证据进行对话的路径。目标是切实可行的：保持有效的 GPU 运行时间，并持续进行模型训练。
为什么传统监控会在 AI 工厂规模上崩溃
基于规则的监控假设跨越已知边界的已知指标表示已知状况。该模型适用于明显的故障。它难以应对所谓的“灰色故障”，即组件仍然可用，并且相关问题可能仅在负载下或与同行比较时才会出现。绝对值可能会错过偏移。在正常工作负载发生变化时，严格的值通常会增加警告，从而让随时待命的工程师来决定哪些偏差很重要。
缩放功能增加了警报放大功能。一个物理故障可能会产生接口错误、RX (接收) 暂停帧、拥塞指示器、GPU 利用率变化以及作业进度变慢。这些观察结果描述了相同的依赖关系链，但单独的仪表板或警报会将它们显示为不相关的事件。待命工程师会收到大量警报，并需要手动关联警报、确定噪音信号、分析根本原因以及遇到的作业。
对于操作而言，工作负载是重要的单元。团队需要了解哪些作业会受到影响、占用哪些资源、这些资源在物理和逻辑拓扑中的位置，以及当前行为与正常基准的区别。当作业开始和停止时，以及当节点被耗尽、替换或返回服务时，该上下文必须保持最新。如果没有它，运行良好的组件仪表板就会与糟糕的作业吞吐量共存，无法提供任何解释。
构建实时的基础设施和作业模型
解决这些挑战需要整个 AI 工厂的端到端可见性。NVIDIA Minerva 从 GPU、Spectrum-X 和 NVLink 交换机、SuperNIC、DPU、存储、NVIDIA NCCL、调度程序和 AI 工作负载中提取指标、日志和拓扑。自动发现功能提供原始遥测数据所缺乏的关系。生成的知识图谱会映射基础设施、调度程序和工作负载元素，然后随着环境的变化更新这些关系。它可以跨多个数据中心，并支持从整个工厂视图导航到单个界面。
拓扑图是改变研究路径的关键。从异常接口开始，操作员可以识别其节点、所服务的结构路径、当前作业位置以及同一故障域中附近的组件。从作业 ID 开始，ML 工程师可以通过 GPU、主机、网卡、交换机和日志证据追踪工作负载。网络和计算团队可以从基础设施事件开始，查看受影响的作业，或者反过来查看受影响的作业，并使用 NVIDIA Minerva 调查原因。每个人都根据相同的当前因果图工作，而不是调节单独的清单。
使用专用机器学习检测灰色故障
NVIDIA Minerva 利用为 AI 工厂基础设施和工作负载开发的监督式和无监督式模型，每小时处理数十亿个指标和日志数据点。监督式检测可识别已知的关键错误模式，并可以将已识别的情况与特定的补救指导联系起来。无监督式模型涵盖无预定义签名的行为。他们学习硬件或逻辑组件的正常模式，并将其与相关同行进行比较。
同行比较很重要，因为测量结果在孤立的情况下看起来是可以接受的，但在上下文中仍然是异常的。网络接口上的持续错误可能看起来很正常，但与其他接口相比，它们非常明显。GPU 温度可能保持在规格范围内，同时运行温度远高于同等负载下的同类 GPU。多变量模型可以结合温度、功率、频率、利用率和工作负载状态，在组件发生彻底故障之前检测到性能下降。
日志也会受到类似的处理。基于 NLP 的异常检测覆盖了之前未见过的模式，而监督匹配可识别已知的关键错误。检测可以输入调度程序工作流，以便在其他作业落地之前或在检查点之间的安全点耗尽受影响的节点。
将事件风暴分解为可采取行动的事件
拓扑感知相关性将检测与操作员操作联系起来。相关引擎的算法利用知识图谱来确定哪些事件共享依赖项路径。然后，下游症状被归类为一个事件，而不是争抢注意力。
其结果是，警报噪声更少，上下文更丰富。NVIDIA Minerva 可以将冗余事件和相关指标序列分解为单个信号，并附加受影响的拓扑结构和工作负载。NVIDIA 测试显示，受支持场景的已通知事件和工单显著减少。操作员仍然需要使用 NVIDIA Minerva 提供的其他功能确定根本原因，但他们从更小的搜索空间开始。在 NVIDIA Minerva 创建高置信度事件后，团队可以通过平台 UI 或现有工作流程处理该事件。
代理式调试
相关证据仍然需要解释。NVIDIA Minerva 包含一个名为 Sherlock 的原生 AI 智能体，该智能体以实时遥测和知识图为基础，因此操作员可以询问为什么特定作业在特定间隔内速度变慢，哪些组件改变了状态，或者其他节点是否共享相同的故障域。Sherlock 使网络运营、计算运营和站点可靠性工程 (SRE) 团队能够以人类语言查询系统以进行根本原因分析。
Sherlock 可以提供支持证据并建议采取补救措施，而无需每个操作员知道确切的指标、仪表板或查询语言。这为经验不足的操作员提供了获取传统上需要上报给专家的领域知识的途径。它在运营工作流程中的价值取决于 Sherlock 提供的证据。推荐系统会返回支持该推荐系统的遥测和拓扑结构。
NVIDIA Minerva 的 MCP 服务器允许外部代理工具查询相同的操作上下文。团队可以将实时 AI 工厂证据整合到自己的工作流中。缓解措施可以由人类批准，也可以根据当地政策和行动风险自动执行。
NVIDIA AI 工厂用例
检测 40 万接口 AI 工厂中的单条链路性能下降
在同时运行许多多节点训练作业的大型 AI 数据中心中，SRE 发现一项作业的步骤时间逐渐变得更糟。没有严重的失败，没有警觉，也没有明显的罪魁祸首。手动追踪意味着需要在 GPU、NVLink 交换机、SuperNIC 和网络结构中进行数小时的分诊，而作业则会在吞吐量降低的情况下持续消耗 GPU 数小时的时间。
相反，NVIDIA Minerva 的全栈 AIOps 调试从工作负载拓扑的每一层获取遥测数据。异常检测发现，在大约 40 万个接口中，只有一个 NVLink 连接正在悄无声息地丢失带宽。然后，它将该 NVLink 交换机链接到流量通过该交换机的训练作业。现在，SRE 可以在一个用户界面视图中看到故障链路、受影响的作业，以及两者在数据中心层次结构中的位置，他们排空并重新调度了受影响的节点，隔离了该链路以进行修复，并将作业恢复到全速运行状态。在问题扩散到整个集群之前，该团队发现了这个问题，在数分钟 (而非数小时) 内诊断出问题，并保持车队的良好输出和 token 生产。
SuperNIC 主动式维护
GPU 节点记录了一个内核行：平台固件报告的硬件错误 ( APEI，错误源 5) 。这是节点 SuperNIC 路径上的 PCIe 级故障。这种错误非常罕见，没有任何静态规则或值会被捕获，而且不会出现作业失败或客户投诉。
NVIDIA Minerva 的实时罕见对数异常检测将这一消息标记为罕见且前所未见的事件。该平台向集群运营团队的 Slack 频道发布了警报。在发出警报的同时，NVIDIA Minerva 还解释了错误的含义，并从错误上下文和要检查的系统日志开始，制定了分步修复方案。该呼叫工程师确认了故障，并在任何客户工作负载降临之前将节点从分配池中删除。这样一来，在发生故障的节点上节省了数百个 GPU 小时，从而导致作业崩溃和重启。
NVMe 电源故障导致的杂乱作业
运营团队试图解释为什么一些训练任务的运行速度比预期慢。减速指向的是杂乱的节点，而不是成因。
NVIDIA Minerva 的全栈作业 RCA 控制面板将问题追踪到一个主机，其日志显示 NVMe 设备发生故障。驱动器无法从低功耗状态中唤醒。该节点无法访问其存储，这引发了一系列 I/ O 写入错误，拖累了其上运行的每个作业。在确认根本原因后，该团队耗尽了节点，并将有故障的硬件发回 RMA。该修复程序估计可节省 5530 小时的作业运行时间。
暂停帧风暴
交换机问题产生了 RX 暂停帧、GPU 利用率峰值和数千个指标序列。这一事件多达 81 起杂事件。许多设备都发出了警报，但没有一台设备能够解释这一增长放缓的原因。原因是分页错误迫使网络交换机重启。重启引发了网络拥塞，RX 暂停帧在交换机之间传播，链路反复中断，GPU 温度峰值和利用率异常。
NVIDIA Minerva 的拓扑感知关联将 81 个独立事件和异常与受影响的作业关联起来，并将其作为单个事件发送给团队。将修复时间从原来的 81% 缩短到单个事件，并节省了约 54 小时的集群总正常运行时间。
将运营收益转化为有用的计算
NVIDIA 的内部测试表明，通过主动维护，中断之间的平均时间 (MTBI) 有所增加，同时通过自动根本原因分析减少了平均修复时间 (MTTR) ，警报噪声也显著减少。通过更大限度地减少停机时间，从而增加有效的 GPU 运行时间。
与 DSX OS 融合
NVIDIA Minerva 是在与 NVIDIA DSX OS 对齐融合的情况下开发的。它重复使用并计划集成选定的 DSX OS 运行状况和恢复组件，例如 NVIDIA Attribution。从数据采集器开始，NVIDIA Minerva 功能将成为 DSX OS 的开源部分。这提供了与 NVIDIA 参考架构保持一致的模块化遥测基础，同时保持可观察性、分析和自动化组合。
弥合差距
随着 AI 工厂的规模和复杂性不断增加，传统监控与运营现实之间的差距也在扩大。NVIDIA Minerva 通过统一跨 GPU、网络、存储和工作负载的遥测技术来弥合这一差距，从而提供端到端可观测性，以检测静态值错过的细微性能下降。
通过将杂的事件风暴分解为单个可操作的事件，并通过对话式 AI 实现代理式调试，NVIDIA Minerva 将分诊从数小时的跨团队交接转变为几分钟的引导调查。
要了解 AIOps 如何提高 AI 工厂的 GPU 利用率和可靠性，请访问 https://www.nvidia.com/en-us/networking/products/software/minerva/。
有关技术文档和部署指南，请参阅 https://networking-docs.nvidia.com/minerva/1.0.1..0.1。
要了解 NVIDIA Minerva 如何与更广泛的 DSX OS 遥测堆栈集成，请参阅 https://docs.nvidia.com/dsx#dsx-os。
