NVIDIA Minerva：按作业诊断，告警整合

1. 从设备状态转向作业影响

分布式训练即由多个设备分担计算的训练，其进度取决于最慢设备的速度。即使设备没有完全停机，仅在负载下出现的细微错误也可能拖慢整个作业，一个故障还可能引发多台设备的信号和告警。

Minerva 从 GPU、交换机、网卡、存储设备和调度器等处收集指标，即以数值记录的状态测量值，以及日志和连接信息。它自动发现关联，构建描述设备与作业连接关系的知识图谱；NVIDIA 技术博客称，其每小时处理数十亿个指标和日志数据点。

借助这一结构，可以从异常接口逐步缩小范围，定位相关节点、网络路径和受影响的作业。反过来，也可从作业标识符出发，沿着 GPU、主机、网络设备和相关日志进行排查。这种方式以作业为中心，而非在传统的各设备界面间来回切换。

2. 同时检测已知错误与未知异常

监督学习模型查找已知的重要错误，并关联处置指南；无监督模型即无需标准答案、从数据中寻找模式的模型，则将没有预设错误特征，即区分错误的独特模式的行为，与同类设备进行比较。综合观察温度、功率、时钟频率、利用率和作业状态，即使数值仍在规格范围内，也能发现与同类设备不同的性能退化。基于自然语言处理的检测也能在日志中找出首次出现的模式。

据公司公布，在同时运行多节点训练作业的数据中心中，Minerva 从约 40万个接口中找出了一条带宽下降的 NVLink 连接，并确认受影响的作业。诊断仅用数分钟，而非数小时；运维团队停止向问题节点分配作业，重新安排作业后，隔离链路进行维修。

3. 将多个告警归并为一个事件

利用设备连接结构的关联引擎，即将关联信号归并以查找原因的功能，会把依赖路径相同的事件与异常归并为一次故障事件；依赖路径是指一台设备的状态会影响到的连接路径。NVIDIA 表示，在所支持的场景中，通知和工单大幅减少。运维人员可在较小的排查范围内确认原因，再通过平台界面或现有工作流程继续处置。

据公司公布，在交换机重启导致拥塞扩散的案例中，接收暂停帧等 81个事件和异常被归并为一次故障事件。NVIDIA 估计，这缩短了维修时间，并节省了约 54小时的集群运行时间。

另一个案例中，无法从低功耗状态唤醒的 NVMe 存储设备引发输入输出错误，拖慢了该节点上的作业。据公司公布，找到原因、停止向该节点分配作业并退回故障设备后，估计节省了 5,530小时的作业运行时间。

交互式助手 Sherlock 基于实时遥测和知识图谱，让用户能够询问特定作业延迟的原因，或哪些设备的状态发生了变化。外部 AI 工具也可通过 MCP 服务器查询相同的运维信息。

4. 现场采集、集中分析与部署条件

采集器栈需要直接访问被监控设备，因此部署在现场。它支持拉取或推送数据，平台栈则负责关系建模与信息补充、机器学习、存储和展示。也可以在每个数据机房部署采集器，并单独运行平台。

1.0.1 指南列出的测试集群每节点最低要求为 64个虚拟 CPU、128GB 内存和 1TB 磁盘。这些要求适用于单机架或集成 10台 Spectrum 交换机的测试环境。

不过，该版本的发行说明指出，不支持云端或服务化部署。用于连接外部工具的 MCP 服务器为测试版功能，且仅支持查询。

这种方法将分散的数据和告警关联到作业上下文，以缩短排查时间，但也要求管理现场采集基础设施以及存储和处理资源。随着保留设置和数据量变化，所需资源也会增加。

以下是指南中的请求示例，用于将网络模型中已登记的设备标记为维护状态。

curl --request PUT \
--url "https://<platform-host>/minerva/api/v2/network/leaf01" \
--header "Content-Type: application/json" \
--header "X-Api-Key: <api-key>" \
--data '{"status":{"admin_state":"MAINTENANCE"}}'

5. 不同数据类型的保留期限不同

指南中的采集情况文档列出了各类数据的一般保留期限。通用指标与事件存储的保留期限最长，数据包级事件存储的最短，因此可回溯的历史记录范围取决于需要排查的数据类型。

表：各数据存储的一般保留期限

条件：NVIDIA Minerva 1.0.1 指南中各数据源的一般保留期限

单位：天

Minerva 的核心价值在于将设备信号与作业影响关联，让 AI 工厂的故障排查能从更小的范围、更快地启动。