英伟达发布Minerva：为AI工厂提供拓扑感知的AIOps平台
英伟达技术博客介绍Minerva平台：它从GPU、交换机、存储和调度器收集遥测，构建动态知识图谱，用监督与无监督模型识别“灰色故障”，并把同一条依赖链上的多个告警归并为单一事件。博客给出四个内部案例，但未公布可复现的基准测试数据。
AI解读：英伟达通过技术博客发布NVIDIA Minerva，定位为面向AI工厂拓扑与负载设计的AIOps平台。它收集GPU、Spectrum-X与NVLink交换机、SuperNIC、DPU、存储、NCCL、调度器和AI工作负载的指标、日志与拓扑，并通过自动发现补全原始遥测缺失的关系，形成可更新的知识图谱。
博客称该图谱支持从单个异常网口出发找到所属节点、承载的网络路径和当前作业，也可从作业ID反向追踪到GPU、主机、网卡、交换机和日志；网络、计算和ML团队因此基于同一张因果图排查，而需要人工核对多套独立台账。
检测层使用监督与无监督模型。监督模型匹配已知关键错误并关联处置建议；无监督模型学习组件正常模式，并与同类组件比较，用于发现未触发静态阈值的“灰色故障”，例如同负载下温度明显偏高的GPU、仅在持续负载下掉速的NVMe，以及看起来正常但持续报错的网口。
Minerva的相关引擎利用知识图谱判断事件是否共享依赖路径，将下游症状合并为一个事件。博客称在一个案例中，一次因页错误引发的交换机重启，造成了可观测到的 81 个嘈杂事件，平台将其归并为单一事件，关联到受影响作业。
配套的AI代理Sherlock基于实时遥测和知识图谱回答自然语言问题，例如某作业为何在某时段变慢、哪些组件状态发生变化；MCP服务器允许外部代理工具查询同一运营上下文，处置方式可保留人工审批，或按本地策略自动化。
博客称Minerva正与NVIDIA DSX OS对齐，计划复用并整合DSX OS的健康与韧性组件（如NVIDIA Attribution），其能力从数据收集器开始将作为DSX OS的开源部分提供。
英伟达在技术博客中介绍了NVIDIA Minerva，一个围绕AI工厂拓扑和训练负载构建的AIOps平台。博客称，它把分散在GPU、网络、存储、调度器和工作负载中的遥测汇入动态知识图谱，用机器学习识别静态阈值难以捕获的“灰色故障”，并把同一条依赖链上的多个告警归并为单一事件。
博客由英伟达作者Elizabeth Goodman撰写，性质是产品介绍，附带四个英伟达内部AI工厂的使用案例。文中没有公开可供第三方复现的基准测试细节；关于减少告警、提升有效GPU小时和节省运行时间的说法，均来自英伟达自述。
为什么静态阈值监控在AI工厂里不够用
博客给出的前提是：同步分布式训练中，作业按最慢的rank推进，因此一个GPU、网卡、存储设备或交换机路径的性能退化，会浪费大量健康资源的时间。这类退化可能只是某块GPU比同负载的同伴热几度、某块NVMe在持续负载下掉速，或交换机产生pause-frame风暴，而不一定越过任何固定阈值。
英伟达认为，规则式监控擅长明确的故障，却难以处理组件仍在线、问题只在负载或同类比较中显现的情况；提高阈值敏感度又会在正常负载波动时制造大量告警。一个物理故障还可能同时表现为接口错误、pause frame、拥塞指标、GPU利用率变化和作业变慢，分散在不同团队的仪表盘上。
因此博客主张以“作业”为运营单位：团队需要知道哪个作业受影响、它占用哪些资源、这些资源在物理和逻辑拓扑中的位置，以及当前行为与健康基线的差异。这一上下文要随作业启停和节点上下线保持更新。
知识图谱与灰色故障检测
Minerva摄入来自GPU、Spectrum-X与NVLink交换机、SuperNIC、DPU、存储、NVIDIA NCCL、调度器和AI工作负载的指标、日志与拓扑，自动发现并补全组件关系，形成跨多个数据中心的知识图谱。博客称，运维人员可从异常接口出发定位节点、网络路径和当前作业，也可从作业ID反向追踪到日志证据。
检测方面，平台每小时处理数十亿指标和日志数据点。监督模型识别已知关键错误模式并关联处置指引；无监督模型学习单个硬件或逻辑组件的正常行为，再与同类组件比较。博客举例说，一块GPU的温度可能仍在规格内，但在相同负载下明显高于兄弟GPU；多变量模型可组合温度、功耗、时钟、利用率和工作负载状态，在组件彻底失效前发现退化。
日志也采用类似思路：基于NLP的异常检测发现此前未见过的模式，监督匹配识别已知关键错误。检测结果可送入调度器工作流，在下一个作业落到问题节点之前，或在两次检查点之间的安全时点，把该节点排空。
四个内部案例与归因边界
博客列出的第一个案例发生在一个约 40 万个接口的大型AI数据中心：一名SRE发现某个作业的step time缓慢变差，但没有硬故障和明显告警。Minerva的异常检测找出其中一条正在悄悄丢失带宽的NVLink连接，并把该NVLink交换机与经过它的训练作业关联起来；团队随后排空并重新调度受影响节点、隔离该链路维修。英伟达称，诊断时间从数小时缩短到数分钟。
第二个案例中，一个GPU节点记录了一条来自固件的PCIe级错误（APEI，错误源 5），没有作业失败或客户投诉。Minerva的罕见日志异常检测将这条信息标记为前所未见的事件，并向集群运维的Slack频道发出告警，附上错误含义和逐步处置建议。值班工程师确认后，在客户负载落入该节点前将其移出分配池。
第三个案例里，多个训练作业变慢，Minerva的全栈作业根因分析定位到一台主机的NVMe设备无法从低功耗状态唤醒，导致存储访问中断和一系列I/O写错误。团队排空节点并将硬件送修，英伟达估算此举节省了 5,530 小时作业运行时间。第四个案例是交换机因页错误重启引发拥塞和pause-frame扩散，平台把 81 个事件归并为一个，英伟达估算节省约 54 小时集群正常运行时间。
这些数字均为英伟达自述的估算，博客没有说明计算方式、对照组或统计口径。它们能支持“英伟达内部特定场景下观察到这些结果”的说法，不足以推断其他AI工厂会获得同等收益。
代理式排查与DSX OS整合
Minerva内置的AI代理名为Sherlock，基于实时遥测和知识图谱回答自然语言问题，例如某作业在特定时段为何变慢、哪些组件状态发生变化、其他节点是否处于同一故障域。博客称，它的建议会链接回支撑该建议的遥测和拓扑证据；MCP服务器则让外部代理工具查询同一运营上下文。
在处置环节，博客明确说可以保留人工审批，也可以按本地策略和操作风险自动执行选定动作。这一表述把自动化的适用范围留给部署方决定，而非平台默认全自动。
整合方面，Minerva正与NVIDIA DSX OS对齐，计划复用并整合DSX OS的部分健康与韧性组件，例如NVIDIA Attribution；Minerva的能力从数据收集器开始，将作为DSX OS的开源部分提供。博客没有给出开源的具体时间表或组件清单。