NVIDIA 的 Minerva 把整个 AI 工厂画成知识图谱，让一次变慢的训练能被追到那根线上

2026 年 10 月 22 日，NVIDIA 发布了 Minerva。官方给的定位是 AIOps 平台，做的事说起来朴素：把基础设施的遥测和 AI 负载的遥测接在一起，再用专门训练的模型把数据变成「及时、可行动的判断」。但真正说明问题的，是发布稿开头那段描述 AI 工厂的话——成千上万块 GPU 在高速网络上协同训练和推理，在这种规模下，一个降级的部件就能拖慢整个作业，而征兆往往极难发现：某块 GPU 比同伴热一点，某块 NVMe 在高负载下掉性能。这类信号传统监控抓不住，因为它们不是「挂了」，而是「比兄弟差一点」。Minerva 想解决的正是这个。

Minerva 把 GPU、SuperNIC、交换机、线缆和作业连成一张图。

一、它衡量的是产率，不是可用性

官方把指标定义得很清楚：AI 工厂产率（yield）＝基础设施产出的有效工作，用 GPU 小时、goodput、集群可用性和 token 产出四项来衡量。这四个词放在一起是刻意的。GPU 小时只说明你买了多少；goodput 说明其中有多少真的推进了作业；可用性说明集群有没有在跑；token 产出把这个抽象数字翻译成业务能听懂的东西。为什么这个区分有价值？因为一个集群可以做到 92% 的利用率却少了三成有效产出——被慢节点拖住的作业照样占着 GPU，采样率不会掉，账单不会少。所以在设计自己的看板时，第一块图不该是利用率曲线，而应该是「每有效 GPU 秒产出多少 token」，它比账单更早动。

-- Yield is the only metric that survives a budget review.
-- GPU hours alone tell you what you paid for; goodput tells you what you got.
WITH per_node AS (
  SELECT
    node_id,
    sum(seconds)                                        AS wall_seconds,
    sum(seconds * busy_fraction)                        AS busy_gpu_seconds,
    sum(seconds * useful_fraction)                      AS useful_gpu_seconds,
    sum(tokens_generated)                               AS tokens
  FROM gpu_samples
  WHERE ts >= now() - INTERVAL '24 hours'
  GROUP BY node_id
)
SELECT
  round(sum(useful_gpu_seconds) / sum(busy_gpu_seconds) * 100, 2) AS goodput_pct,
  round(sum(busy_gpu_seconds) / sum(wall_seconds) * 100, 2)       AS utilisation_pct,
  round(sum(tokens) / nullif(sum(useful_gpu_seconds), 0), 2)      AS tokens_per_useful_gpu_second,
  count(*)                                                         AS nodes
FROM per_node;

-- Two clusters can show 92% utilisation and differ by 30% on yield.
-- Track tokens per useful GPU-second; it moves before the bill does.

二、把拓扑当连接键：从作业追到那根线

发布稿里最关键的一句技术描述是：Minerva 会构建一张动态知识图谱，把 GPU、SuperNIC、交换机、线缆这些基础设施和跑在上面的作业逻辑地映射起来。这句话的分量在于「逻辑映射」四个字——大多数团队根本不存拓扑。机器清单有，交换机配置有，作业调度记录也有，但「这个作业跑在这批节点上、这批节点挂在那个 leaf 交换机下、那块 GPU 的 NIC 走的是这根线」这条链路，通常只存在于某个人脑子里。没有它，一条「NCCL 超时」的告警只能告诉你症状，告诉不了你影响面。有了它，同一份告警就能带上 blast radius：是一块 GPU 的问题，还是一个机架的问题？这决定了你是派一个人，还是叫上半个团队。

// Topology is the join key that nobody stores. Minerva's pitch is that
// it does: GPUs, SuperNICs, switches, cables and jobs in one graph.

// Given a training job that lost throughput, walk from job to the
// physical component that changed, and stop at the first shared ancestor.
MATCH (j:Job {id: $job_id})-[:RAN_ON]->(n:Node)
MATCH (n)-[:HAS_GPU]->(g:GPU)
MATCH (g)-[:ATTACHED_TO]->(:NIC)-[:CABLE]->(sw:Switch)
WHERE g.hotspot_c > g.peer_median_hotspot_c + 5
   OR sw.crc_errors_1h > 100
RETURN
  j.id            AS job,
  collect(DISTINCT n.id)  AS nodes,
  collect(DISTINCT g.id)  AS suspect_gpus,
  collect(DISTINCT sw.id) AS suspect_switches,
  count(DISTINCT n.id)    AS blast_radius
ORDER BY blast_radius DESC;

// The blast radius is the point. One bad switch is a rack problem;
// one bad GPU is a node problem. Same alert, different page.

三、数十亿点每小时的异常检测，靠的是同伴基线

官方说 Minerva 每小时分析数十亿个数据点，用有监督和无监督的方法学习正常行为、发现从未见过的异常、预测即将发生的故障。这句话里最容易被忽略的是「学习正常行为」——它意味着基线是相对的，不是绝对的。对硬件遥测来说这是唯一可行的做法：同一批 GPU 在不同固件版本、不同进气温度、不同邻居负载下的温度分布本来就不同，写死一个「超过 85 度告警」的阈值，要么天天误报，要么把真问题漏掉。可行的替代是按机架分组，用中位数和 MAD（中位数绝对偏差）算稳健 z 分数：MAD 不会被异常点本身拉偏，这正是我们要找的东西。这一点在自己搭监控的时候可以直接抄。

一颗 GPU 比同批兄弟热 8 度，就是一整个作业变慢的起点。

// Peer-relative detection beats static thresholds on hardware that
// drifts with firmware, workload mix and inlet temperature.
import statistics

def peer_anomalies(samples, metric="hotspot_c", k=6.0):
    """samples: [{gpu_id, rack_id, ts, hotspot_c}, ...]"""
    by_rack = {}
    for s in samples:
        by_rack.setdefault(s["rack_id"], []).append(s)

    flagged = []
    for rack_id, rows in by_rack.items():
        values = [r[metric] for r in rows]
        med = statistics.median(values)
        # MAD resists the very outliers we are hunting.
        mad = statistics.median([abs(v - med) for v in values]) or 0.1
        for r in rows:
            score = 0.6745 * (r[metric] - med) / mad
            if score > k:
                flagged.append({
                    "gpu_id": r["gpu_id"],
                    "rack_id": rack_id,
                    "score": round(score, 2),
                    "value": r[metric],
                    "peer_median": med,
                })
    return sorted(flagged, key=lambda x: -x["score"])

# Run per rack, not per cluster: inlet temperature and neighbour load
# differ by rack, and a cluster-wide median buries a hot rack.

四、事件风暴收敛成一条工单

发布稿里有一句很实在的描述：与其把每一个症状都发给运维，它可以把一场事件风暴聚合成一条聚焦的事件，并带上可能的根因。这是运维里最贵的那个问题——不是发现故障，而是同时收到 40 条告警时判断它们是不是同一件事。技术上它依赖两样东西：拓扑（共享同一台交换机的告警大概率同源）和去重规则（子症状在父故障存在时应该被压制）。规则的写法比工具的选择更重要：先按机架、交换机、作业分组；父告警存在时压制子告警；把「五条以上同作业告警」折叠成一条并附上疑似部件；以及一条铁律——ECC 不可纠正、NVLink down、热关机这三类信号永远不压制，它们是硬件完整性信号，不是噪音。

# An event storm is a topology problem wearing an alerting costume.
# Group by shared physical ancestor before paging a human.
correlation:
  window: 10m
  group_by:
    - topology.rack_id
    - topology.switch_id
    - job.id
  rules:
    - name: suppress_children_of_switch
      when: any(alert.name == "switch_crc_errors")
      suppress:
        - gpu_xid_error
        - nccl_timeout
        - job_throughput_drop
      reason: "child symptoms of one fabric fault"

    - name: single_ticket_per_job
      when: count(alert.job.id) >= 5
      collapse_to: job_throughput_drop
      attach: [suspect_components, blast_radius]

    - name: never_suppress
      alerts: [ecc_uncorrectable, nvlink_down, thermal_shutdown]
      reason: "hardware integrity signals are never noise"

# Result: one page with a blast radius instead of 40 pages with a start time.

五、人在回路还是自动修复：先写策略，再谈自动化

Minerva 提供原生 AI 助手，也能连外部 agentic 工具，官方描述是：操作员可以用自然语言查询集群健康状态，并拿到推荐的修复动作；团队可以选择保留人工执行，或者通过基础设施 API 和外部系统把动作接到自动化上。这句话里的自由度就是风险所在。工程上的正确做法是先给动作分级：重启空闲容器是低风险、可以直放；排空节点、重置 NVLink 是中风险、需要一个当班人点头；驱逐作业、刷固件是高风险、要作业 owner 或变更委员会批。然后所有由 agent 发起的动作先走 dry-run，把「将要做什么」写进工单，人批准后再真执行。dry-run 的成本几乎为零，而它拦下的那一次误驱逐，可能就是一个训练了三周的作业。

从「一堆告警」到「一条工单」，差的是拓扑和去重。

// Remediation through infrastructure APIs is the part that needs a policy,
// not a demo. Dry-run first, then require a named approver for anything
// that moves a job or drains a node.

REMEDIATION = {
    "restart_idle_container":   {"risk": "low",    "approval": None},
    "drain_node":               {"risk": "medium", "approval": "oncall"},
    "reset_nvlink":             {"risk": "medium", "approval": "oncall"},
    "evict_job":                {"risk": "high",   "approval": "owner"},
    "firmware_update":          {"risk": "high",   "approval": "change_board"},
}

def remediate(action, target, incident, dry_run=True):
    policy = REMEDIATION[action]
    if dry_run:
        return {"would_do": action, "target": target, "risk": policy["risk"]}
    if policy["approval"] and not incident.get("approved_by"):
        raise PermissionError(f"{action} needs {policy['approval']} approval")
    return infra_api.execute(action, target, incident_id=incident["id"])

# Write the dry-run output into the ticket. The agent proposes,
# the human approves, the API executes, the graph records what changed.