英伟达推出面向 AI 工厂的运维平台 Minerva，将 GPU、网络、存储、调度器和任务遥测关联到动态知识图谱与机器学习中，聚合告警并提出可能根因，同时提供基于实时遥测的自然语言助手以协助排查和调查。公司和合作伙伴已在不同程度上试用或计划部署该平台，但独立验证、覆盖异构环境的能力与自动化修复的边界仍需更多真实部署数据检验。
英伟达于2026年10月22日发布面向 AI 工厂的智能运维平台 Minerva，试图解决大型算力集群中的一个现实问题：监控系统不断发出告警，运维人员却仍难以判断，究竟是哪一个组件拖慢了正在运行的训练或推理任务。
根据英伟达的发布公告，Minerva 将 GPU、网络、存储、任务调度器和 AI 工作负载的遥测数据关联起来，通过动态知识图谱和机器学习识别异常、聚合告警，并给出可能的故障根因。它还提供基于实时遥测的 AI 助手，让运维人员以自然语言调查集群状态。
这并不意味着平台已经获得独立验证的故障预测能力，也不意味着接入后就必须让 AI 自动修改生产系统。英伟达明确表示，团队可以保留人工修复流程，或通过基础设施 API 和外部系统接入自动化。
为什么设备正常，任务却可能跑不快
大型 AI 集群的运行效率，不只取决于安装了多少 GPU。计算节点、网络、存储与调度系统相互依赖，一个组件性能下降，可能在另一个层面表现为任务变慢。
英伟达在公告中举例说，GPU 温度高于同组设备，或 NVMe 存储设备在负载下性能下降，都可能是容易被忽略的信号。传统监控通常按专业分工呈现数据：网络团队查看交换机和接口，计算团队查看 GPU，机器学习团队关注任务进度。各自的仪表盘可以显示异常，却未必能直接解释异常之间的关系。
Minerva 的切入点是把这些视图连接起来。平台建立的动态知识图谱，不仅记录 GPU、SuperNIC、交换机和线缆等基础设施之间的关系，也把运行中的任务映射到相应设备上。按照英伟达的描述，这可以帮助操作人员从一个变慢的训练任务，追踪到可能影响它的底层组件。
这里的关键不是增加一张监控大屏，而是补上“哪一个任务依赖哪一组设备”的上下文。不过，拓扑关联能够提供排查线索，并不等于每一次相关异常都已经被证明存在因果关系。
从告警风暴到一个可处理的事件
英伟达表示，Minerva 使用监督学习和无监督学习分析遥测数据，学习正常运行模式，识别此前未出现的异常，并结合基础设施拓扑关联事件。公司宣称，平台每小时可以分析数十亿个数据点。
这一处理规模属于厂商披露，并非独立性能测试结果。它所要解决的问题，则是运维团队熟悉的“告警风暴”：同一个底层问题可能在多个组件和任务上产生症状，如果每个症状都单独上报，人员会把大量时间花在重复判断上。
Minerva 的目标是将相关症状合并为一个事件，并提供可能的根因，让团队优先处理影响较大的问题。英伟达把预期收益概括为延长任务两次中断之间的运行时间、缩短修复时间，以及减少无关告警。
官方产品页面进一步列出了它的数据范围，包括 GPU、NVLink 交换机、Spectrum-X 以太网、SuperNIC、DPU、NCCL 通信库，以及 Slurm、NVIDIA Run:ai 等调度系统。换言之，Minerva 不只是查看设备是否在线，也试图解释通信、调度和任务执行之间的相互影响。
这种设计尤其围绕英伟达自己的基础设施生态展开。现有介绍不能直接证明，它在任意异构集群中都能获得同样完整的数据覆盖和诊断效果；实际能力仍取决于接入设备、采集配置和可用的任务上下文。
AI 助手负责调查，自动修复仍有边界
产品页面将 Minerva 的原生多智能体助手称为 Sherlock。它使用实时遥测，帮助操作人员通过自然语言进行故障分诊和排查；平台还提供模型上下文协议（MCP）服务器，用于连接客户自己的智能体工具。
这让 Minerva 与单纯提供图表的监控工具有所不同，但自然语言回答不应被等同于已经验证的修复方案。根据发布公告，平台可以建议处理措施，而是否执行、由谁执行，以及是否接入自动化，仍由使用方决定。
英伟达也没有要求客户只能采用一套完整替换方案。产品页面列出了不同使用方式：只使用数据采集功能并接入 Grafana 等外部可观测性平台；在现有监控体系中加入异常检测和关联分析；或使用包含原生助手与可观测性工具的完整平台。部署方式则包括本地部署和软件即服务。
对于已有监控与工单流程的企业，这意味着 Minerva 可以作为新增的一层数据与分析能力，而不必被理解为立即取代所有现有工具。但自动化进入生产环境后，需要什么权限、哪些操作必须审批，以及失败后如何恢复，仍是运营方需要单独确定的边界。
谁在使用，谁仍处于部署计划阶段
英伟达在10月22日的公告中明确表示，IREN 已在使用 Minerva。公告引用 IREN 首席技术官 Denis Skrinnikoff 的说法称，平台让团队能够在同一个视图中观察网络、GPU 和任务，从而将更多精力投入主动维护，而不是故障排查。
同一公告把 Aolani、Bitdeer AI、IBM、Jio、Lambda、Quake AI 和 Tesla 列为计划部署的伙伴，并表示 Dell Technologies、联想和 Supermicro 将把 Minerva 纳入各自的 AI 工厂运维产品组合。这些表述分别涉及正在使用、计划部署和未来提供产品，不能合并写成所有公司都已完成生产部署。
Bitdeer AI 的情况还需要保留另一份一手材料中的不同措辞。在同日发布的公司博客中，Bitdeer AI 表示已经支持 Minerva，并将其加入自身 AI 工厂运维。这个说法比英伟达公告中的“计划部署”更进一步，但该博客没有披露覆盖的集群规模、上线范围或客户可用时间。因此，更准确的结论是：Bitdeer AI 已公开宣布支持和引入 Minerva，而其具体部署程度仍缺少公开细节。
英伟达的发布公告没有给出统一公开采购日期或价格，产品页面列出的部署与使用模式，也不足以证明所有功能已经在所有地区、面向所有客户全面开放。
有效果案例，但还不是独立评测
相比英伟达发布公告中的定性描述，Bitdeer AI 的博客补充了两个具体案例，但将其明确归于英伟达内部 AI 工厂测试。
按照该博客的说法，一个 NVMe 供电故障案例的修复时间从多日缩短至六小时；另一个案例则将81个嘈杂事件合并为一条告警，并称由此节省了54小时的集群运行时间。
这些数字有助于理解平台希望解决的问题，但证据边界同样重要：它们是合作伙伴转述的厂商内部案例，不是 Bitdeer AI 自身公开的生产测量，也不是独立第三方评测。文章未提供足以复核的完整测试方法、集群配置和对照条件，不能据此推算所有客户都能获得相同比例的改善。
对于采购方，更有判断价值的后续证据，将是实际部署后有效 GPU 小时、任务中断频率和平均修复时间的持续变化，以及这些变化是否伴随误报、漏报或额外采集开销。
从建成算力，转向让算力持续产出
Minerva 所强调的“AI 工厂产出”，并不只是 GPU 利用率。英伟达将其描述为基础设施完成的有效工作，涉及 GPU 小时、有效吞吐量（goodput）、集群正常运行时间和令牌产量。这个衡量方式关注的，是昂贵设备最终完成了多少有用任务，而不仅是设备是否开机。
它也与 AI 基础设施的交付问题形成前后衔接。AIFlux 此前报道的DSX POD 模块化 AI 工厂参考设计聚焦如何通过预集成提高部署的可重复性；Minerva 则把重点放在集群投入运行以后，如何发现性能退化并减少故障损失。更快交付和更稳定运营，解决的是同一套基础设施生命周期中不同阶段的问题。
Minerva 的发布表明，英伟达正把产品范围进一步延伸到 AI 工厂的日常运营。但平台能否把跨层遥测转化为可靠诊断、能否在减少告警的同时保留关键风险，以及自动化修复能否在可控权限下稳定工作，仍需要更多真实部署数据来回答。现阶段，能够确认的是产品定位、公开功能与伙伴表态，而不是所有预期运维收益都已得到验证。