NVIDIA Minerva：让遥测数据驱动GPU算力效率提升
NVIDIA推出AI工厂专用AIOps平台Minerva，通过动态知识图谱整合GPU、网络、存储及工作负载的全栈遥测数据，利用机器学习检测灰色故障，将大量关联告警压缩为单一事件，并通过AI智能体Sherlock支持自然语言根因分析，内部测试显示可显著减少告警噪声、提升有效GPU使用时长。
AI工厂是人类创造的技术最复杂的运营环境之一。数十万个GPU、NVIDIA Spectrum-X以太网横向扩展、跨域扩展和纵向扩展结构、NVIDIA NVLink纵向扩展结构、分布式调度器，以及长达数周的训练任务，都需要持续协同运作。即便不同团队各自掌管自身的遥测数据，这些层级在功能上仍是一套统一的生产系统。在同步分布式训练中，一个任务的推进速度取决于其最慢的计算节点。一个性能下降的GPU、接口、存储设备或交换机路径，就可能让大量健康资源的有效工作时间被白白浪费。
真正影响产出效率的故障往往十分隐蔽：某个GPU的温度比同类设备高出几度；某个NVMe设备只在持续高负载下才出现性能下滑；某台交换机产生的暂停帧风暴，表现出来的症状像是几十个毫不相关的问题。这些信号未必会触碰到固定阈值，但它们叠加在一起，就会造成任务滞后、单步耗时延长、检查点延迟保存等问题。
诊断之所以困难，是因为证据分散在不同团队手中。网络运维人员看到的是接口计数器和网络事件；计算运维人员看到的是节点和GPU健康状况；机器学习团队看到的是不断变化的单步耗时、任务失败或不稳定的推理延迟。每个视角各自都是准确的，但它们之间的关联关系却隐藏在表象之下。排查问题就变成了一连串的仪表盘搜索和跨团队协作，往往会让一个本可局部控制的故障，在定位到受影响节点或网络路径之前，演变成数小时甚至数天的生产时间损失。
本文介绍NVIDIA Minerva如何解决这些运营难题。Minerva是一款围绕AI工厂拓扑结构与工作负载专门设计的原生AI运维（AIOps）平台。
NVIDIA Minerva跨技术栈采集遥测数据，将基础设施映射到动态知识图谱中的实际运行任务，运用专门构建的机器学习模型，并将相关联的异常症状关联为高置信度事件。一个由AI智能体驱动的助手以及连接外部智能体工具的MCP服务器，让运维人员能够基于同一套实时证据进行对话式排查。其目标十分实际：保留有效的GPU工作时间，确保模型训练持续推进。
基于规则的监控方式，假设某个已知指标跨越某个已知边界就意味着某种已知状况。这种模式适用于明确的故障，但在应对所谓的“灰色故障”时就显得力不从心——组件依然处于可用状态，而相关问题可能只在高负载下或与同类设备对比时才会显现。绝对阈值可能会忽略这种细微变化。而过于激进的阈值设置，常常会在正常的工作负载变化中产生大量警告，最终还是需要值班工程师自行判断哪些偏差才真正值得关注。
规模扩大还会带来告警放大效应。一个物理故障就可能同时产生接口错误、接收端暂停帧、拥塞指标、GPU利用率变化以及任务进度变慢等多种表现。这些观测结果本质上描述的是同一条依赖链，但分散的仪表盘或告警系统却将它们呈现为互不相关的事件。值班工程师收到大量告警后，还需要人工关联这些告警，从噪声中提取有效信号,分析根本原因,并确定受影响的任务。
对于运维而言，工作负载才是最关键的分析单元。团队需要知道哪个任务受到影响、它占用了哪些资源、这些资源在物理和逻辑拓扑结构中的位置,以及当前行为与健康基线之间的差异。随着任务的启动和停止，以及节点的下线、更换或重新投入使用，这些上下文信息必须保持实时更新。如果缺乏这种上下文，一个显示健康状态的组件仪表盘就可能与糟糕的任务吞吐量同时存在，却无法给出任何解释。
解决这些难题需要对整个AI工厂实现端到端的可见性。NVIDIA Minerva从GPU、Spectrum-X和NVLink交换机、SuperNIC、DPU、存储设备、NVIDIA NCCL、调度器以及AI工作负载中摄取指标、日志和拓扑信息。自动发现功能补全了原始遥测数据所缺失的关联关系。由此生成的知识图谱将基础设施、调度器和工作负载各要素映射起来，并随着环境变化持续更新这些关系。它可以跨越多个数据中心，支持从全工厂视图导航至单个接口的细粒度查看。
拓扑图谱是改变排查路径的关键所在。从一个异常接口出发，运维人员可以识别出其所在节点、所服务的网络路径、当前任务分配情况，以及同一故障域内的相邻组件。从一个任务ID出发，机器学习工程师可以沿着GPU、主机、网卡、交换机和日志证据追踪整个工作负载的运行轨迹。网络团队和计算团队可以从一个基础设施事件出发查看受影响的任务，反之也可以从受影响的任务出发，借助NVIDIA Minerva排查根本原因。所有人都基于同一份实时的因果关系图开展工作，而不必再费力核对各自独立的清单。
NVIDIA Minerva每小时处理数十亿条指标和日志数据点，运用专门为AI工厂基础设施和工作负载开发的监督式与非监督式模型。监督式检测能够识别已知的严重错误模式，并可将已识别的状况与具体的修复方案关联起来。非监督式模型则覆盖那些没有预定义特征的行为模式，它们会学习某个硬件或逻辑组件的正常模式，并与相关同类设备进行比较。
同类比较之所以重要，是因为某项测量数据单独来看可能显得正常，但放在特定情境中却可能是异常的。某个网络接口上持续出现的错误，单独看可能显得正常，但与其他接口对比后，就会显现出异常。某个GPU的温度可能仍在规格范围之内,但在相同负载下却明显比同系列GPU运行得更热。多变量模型可以结合温度、功率、时钟频率、利用率和工作负载状态，在组件彻底失效之前就检测出这种性能下滑。
日志分析也采用类似的处理方式。基于自然语言处理的异常检测能够发现前所未见的新模式,而监督式匹配则能识别已知的严重错误。检测结果可以反馈到调度器工作流中，使受影响的节点在另一个任务分配到它之前，或在检查点之间的安全时刻被及时下线。
拓扑感知关联技术将检测结果与运维人员的行动连接起来。关联引擎的算法利用知识图谱来判断哪些事件共享同一条依赖路径。随后，下游症状会被归并为一个事件,而不是分散成多个争夺注意力的独立告警。
其结果是告警噪声减少，而上下文信息增多。NVIDIA Minerva可以将冗余事件和相关指标序列合并为一个单一信号，并附带受影响的拓扑和工作负载信息。NVIDIA的测试显示，在其支持的场景中，通知事件和工单数量显著减少。运维人员仍需借助NVIDIA Minerva提供的其他功能来确定根本原因,但他们的排查范围已大幅缩小。一旦NVIDIA Minerva生成高置信度事件，团队就可以通过平台界面或现有工作流来处理它。
经过关联处理的证据仍需要进一步解读。NVIDIA Minerva内置了一个名为Sherlock的原生AI智能体，它以实时遥测数据和知识图谱为基础，运维人员可以询问某个任务为何在特定时间段内变慢、哪些组件发生了状态变化,或者其他节点是否存在于同一故障域中。Sherlock让网络运维、计算运维和站点可靠性工程（SRE）团队能够用自然语言向系统查询根本原因分析结果。
Sherlock能够展示支撑证据并给出修复建议，而不需要每位运维人员都精确掌握具体的指标、仪表盘或查询语言。这为经验较少的运维人员打开了一条通往专业知识的通道，而这类知识以往往往需要上报给专家才能获得。它在运维工作流中的价值，取决于Sherlock所提供证据的质量——每一条建议都能追溯回支撑它的遥测数据和拓扑信息。
NVIDIA Minerva的MCP服务器让外部智能体工具也能查询同一套运营上下文信息。各团队可以将实时的AI工厂证据整合进自己的工作流程中。缓解措施可以保持人工审批，也可以根据本地策略和操作风险自动执行特定动作。
在一个同时运行大量多节点训练任务的大型AI数据中心里，一名SRE工程师注意到某个任务的单步耗时在缓慢恶化。没有明显故障，没有触发告警，也没有明显的元凶。如果靠人工排查，需要在GPU、NVLink交换机、SuperNIC和网络结构之间花费数小时进行逐一排查，而任务却一直在以较低吞吐量持续消耗GPU工作时间。
而借助NVIDIA Minerva的全栈AIOps调试功能,系统摄取了来自工作负载拓扑每一层的遥测数据。异常检测在约40万个接口中，精准找出了那一个正在悄然丢失带宽的NVLink连接。随后，系统将这台NVLink交换机与流量经过它的训练任务关联起来。此时，SRE工程师能够在一个界面视图中同时看到故障链路、受影响的任务，以及两者在数据中心层级结构中的具体位置,他们随即将受影响节点下线并重新调度，隔离故障链路以便维修，并让任务恢复到满速运行状态。该团队在问题扩散到整个集群之前就发现了它，诊断时间从数小时缩短到几分钟，并保持了整个集群的有效吞吐量和Token产出率。
某个GPU节点记录了一行内核日志：平台固件（APEI,错误源5）报告了一个硬件错误。这是节点SuperNIC路径上的一个PCIe级别故障。该错误发生频率极低,任何静态规则或阈值都无法捕捉到它，而且既没有导致任务失败，也没有引发客户投诉。
NVIDIA Minerva的实时稀有日志异常检测功能，将该消息标记为一次此前从未出现过的罕见事件。平台随即向集群运维团队的Slack频道发出了警报。在发出警报的同时，NVIDIA Minerva还解释了该错误的含义，并给出了逐步修复指南，从错误上下文开始，逐步指导需要检查哪些系统日志。值班工程师确认了故障，并在任何客户工作负载分配到该节点之前，将其从分配池中移除。这一举措避免了一个故障节点可能因任务崩溃和重启而造成的数百个GPU工作小时的损失。
运维团队当时正试图弄清楚，为什么多个训练任务的运行速度低于预期。这种减速现象指向了滞后节点，但一时找不到确切原因。
NVIDIA Minerva的全栈任务根本原因分析仪表盘，将问题追溯到一台主机，其日志显示有一个NVMe设备出现故障。该驱动器无法从低功耗状态中唤醒。该节点因此失去了存储访问能力，引发了一系列I/O写入错误，拖慢了该节点上运行的所有任务。确认根本原因后，团队将该节点下线，并将故障硬件寄回进行RMA（退货换货）处理。这次修复预计节省了5530个任务运行时数。
一次交换机故障引发了接收端暂停帧、GPU利用率飙升，以及数千条指标序列异常。该事件最终表现为多达81个嘈杂的独立事件。来自多台设备的告警纷至而来，但没有一个能解释这次减速的真正原因。根本原因是一个页面错误迫使一台网络交换机重启。这次重启引发了拥塞,并在整个网络结构中蔓延，接收端暂停帧在交换机之间传播，链路反复断开，GPU温度和利用率也出现了异常波动。
NVIDIA Minerva的拓扑感知关联技术，将这81个独立的事件和异常都关联到了受影响的任务上，并将它们作为单一事件发送给团队。将其作为一个事件而非81个独立事件来处理,大幅缩短了修复时间，为集群节省了约54小时的总体运行时间。
NVIDIA的内部测试显示，通过主动维护，平均无故障间隔时间（MTBI）得到提升；通过自动化根本原因分析，平均修复时间（MTTR）显著缩短；同时告警噪声也大幅减少。这些改进共同作用,通过最大限度减少停机时间，提升了有效GPU工作小时数。
NVIDIA Minerva的开发正朝着与NVIDIA DSX OS融合对齐的方向推进。它复用了DSX OS中经过挑选的健康状态与弹性恢复组件（例如NVIDIA Attribution），并计划进一步深度集成。从数据采集器开始，NVIDIA Minerva的部分功能模块将成为DSX OS中的开源组成部分。这为遵循NVIDIA参考架构提供了一套模块化的遥测基础，同时保持了可观测性、分析能力和自动化功能的可组合性。
随着AI工厂规模和复杂度的不断增长，传统监控手段与运营实际需求之间的差距正在不断扩大。NVIDIA Minerva通过统一GPU、网络、存储和工作负载的遥测数据，实现了端到端的可观测性，从而能够检测到静态阈值所无法捕捉的细微性能下降。
通过将嘈杂的事件风暴归并为单一的可执行事件，并借助对话式AI实现智能体式调试，NVIDIA Minerva将原本需要数小时跨团队协作的故障排查工作,转变为几分钟内即可完成的引导式排查。
如需了解AIOps如何提升您的AI工厂的GPU利用率和可靠性，请访问NVIDIA官方网站Minerva产品页面。
如需了解NVIDIA Minerva如何与更广泛的DSX OS遥测技术栈集成，请参阅NVIDIA DSX OS相关文档。