AI 工厂是有史以来技术最复杂的运营环境之一。数十万个 GPU、NVIDIA Spectrum-X 以太网横向扩展、跨域扩展和纵向扩展网络、NVIDIA NVLink 纵向扩展网络、分布式调度器以及持续数周的长时间训练任务，都在持续同步运行。即使不同团队各自负责其遥测数据，这些层级也作为一个生产系统协同运作。在同步分布式训练中，作业的推进速度取决于其最慢的 rank。一个性能退化的 GPU、接口、存储设备或交换机路径，就可能浪费大量健康资源的有用时间。
损害良率的故障往往很隐蔽：某个 GPU 比同类设备温度高几度；某个 NVMe 设备仅在持续负载下性能下降；某台交换机产生暂停帧风暴，看起来像数十个互不相关的症状。这些信号未必会越过静态阈值。它们共同造成掉队者、步进时间延长和检查点延迟。
由于证据分散在不同团队手中，诊断变得更加困难。网络运维人员看到的是接口计数器和网络事件；计算运维人员看到的是节点和 GPU 健康状况；ML 团队看到的是变化的步进时间、失败的作业或不稳定的推理延迟。每个视角都是准确的，但它们之间的关系仍然隐藏。故障排查变成一连串的仪表盘搜索和跨团队交接，可能使一个本可控制的故障在被定位到受影响的节点或网络路径之前，演变成数小时甚至数天的生产时间损失。
本文介绍 NVIDIA Minerva 如何弥补这些运维缺口。NVIDIA Minerva 是一个 AI 原生 AIOps 平台，围绕 AI 工厂拓扑和工作负载而设计。
NVIDIA Minerva 收集整个技术栈的遥测数据，在动态知识图谱中将基础设施映射到活动作业，应用专门构建的机器学习，并将相互依赖的症状关联为高保真事件。由 AI 智能体驱动的助手和连接外部智能体工具的 MCP 服务器，为运维人员提供了一条基于同一实时证据的对话式路径。目标很实际：保住有效 GPU 小时数，让模型训练持续进行。
为什么传统监控在 AI 工厂规模下会失效
基于规则的监控假设：已知指标越过已知边界即表示已知状况。这种模型对明确的故障有效，但难以应对所谓的“灰色故障”——组件仍然可用，相关问题可能只在负载下或与同类设备对比时才显现。绝对阈值可能错过这种偏移；激进的阈值则常在正常工作负载变化时增加告警，让值班工程师去判断哪个偏差才重要。
规模还会放大告警。一个物理故障可能产生接口错误、RX（接收）暂停帧、拥塞指标、GPU 利用率变化和作业进度变慢。这些观察描述的是同一条依赖链，但不同的仪表盘或告警却把它们呈现为互不相关的事件。值班工程师收到大量告警，需要手动关联这些告警，从噪声中辨别信号，分析根本原因以及受其影响的作业。
对运维而言，工作负载才是关键单元。团队需要知道哪个作业受到影响、它占用了哪些资源、这些资源在物理和逻辑拓扑中的位置，以及当前行为与健康基线的差异。随着作业启动和停止、节点被排空、替换或恢复服务，这些上下文必须保持最新。缺少这些上下文，即使组件仪表盘显示健康，也可能同时存在作业吞吐量低下的问题，且无法给出解释。
构建基础设施与作业的实时模型
解决这些挑战需要覆盖整个 AI 工厂的端到端可见性。NVIDIA Minerva 从 GPU、Spectrum-X 和 NVLink 交换机、SuperNIC、DPU、存储、NVIDIA NCCL、调度器和 AI 工作负载中摄取指标、日志和拓扑。自动发现提供了原始遥测所缺少的关系。由此生成的知识图谱映射基础设施、调度器和工作负载元素，并在环境变化时更新这些关系。它可以跨多个数据中心，支持从工厂全局视图导航到单个接口。
拓扑图是改变调查路径的关键。从异常接口出发，运维人员可以识别其所属节点、该接口服务的网络路径、当前作业放置位置以及同一故障域内的邻近组件。从作业 ID 出发，ML 工程师可以沿 GPU、主机、NIC、交换机和日志证据追踪该工作负载。网络和计算团队可以从基础设施事件出发查看受影响的作业，或者反过来，从受影响的作业出发，使用 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 可以在一个 UI 视图中看到故障链路、受影响的作业以及两者在数据中心层级中的位置，于是他们排空并重新调度了受影响的节点，隔离该链路进行维修，并使作业恢复到全速。团队在问题扩散到整个集群之前就抓住了它，在几分钟而非数小时内完成了诊断，并保持了集群的有效吞吐量和 token 产出。
SuperNIC 主动维护
一个 GPU 节点记录了一行内核日志：平台固件报告了一个硬件错误（APEI，错误源 5）。这是该节点 SuperNIC 路径上的 PCIe 级故障。该错误足够罕见，没有任何静态规则或阈值能够捕获它，而且它没有伴随作业失败或客户投诉。
NVIDIA Minerva 的实时罕见日志异常检测将该消息标记为罕见的、前所未见的事件。平台向集群运维团队的 Slack 频道发布了告警。除了告警之外，NVIDIA Minerva 还解释了该错误的含义，并列出了分步修复措施，从错误上下文和需要检查的系统日志开始。值班工程师确认了故障，并在任何客户工作负载落到该节点之前将其从分配池中移除。这节省了故障节点因作业崩溃和重启而可能耗费的数百个 GPU 小时。
NVMe 电源故障导致的掉队作业
运维团队试图解释为什么几个训练作业运行得比预期慢。变慢指向掉队节点，但没有指向原因。
NVIDIA Minerva 的全栈作业 RCA 仪表盘将问题追踪到一台主机，其日志显示一个 NVMe 设备发生故障。该驱动器无法从低功耗状态唤醒。节点失去了对其存储的访问，引发了一系列 I/O 写入错误，拖慢了其上运行的每个作业。根因确认后，团队排空了该节点，并将故障硬件送回 RMA。该修复估计节省了 5,530 小时的作业运行时间。
暂停帧风暴
一个交换机问题产生了 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。
要了解 NVIDIA Minerva 如何与更广泛的 DSX OS 遥测栈集成，请参阅 https://docs.nvidia.com/dsx#dsx-os。