英伟达把 AI 工厂装进集装箱，把运维指标换成 goodput

一、先把来源分层说清#

最后一行是这个选题里最值得注意的空白：厂商把 goodput 当成核心指标推，但没给口径。 这件事后面第六节给了一套可执行的定义。

二、DSX POD：把机架组装搬进工厂#

官方对 DSX POD 的描述是：一个完整的英伟达 Vera Rubin AI 工厂的参考设计，由合作伙伴在模块化集装箱内建造，在出厂前完成集成与验证，到场后接入已经准备好的站点的电力、冷却与网络。

它搬走的是这些工序：计算、网络、布线、机架级供电、液冷——全部从「数据中心现场施工」挪进「制造工厂」。官方给的收益是交付时间从六个月压到最短 14 天。

黄仁勋在新闻稿里的那句原话值得抄下来：AI 工厂只有在开始产出 token 的那一刻才创造价值，而不是在施工完成的时候。

生态名单是这份新闻稿里信息量最大的部分。参与建造与集成的伙伴包括 Anduril、ARMADA、Bull、Crusoe、DayOne、Dell、Delta、Eaton、富士康（Ingrasys）、GIGABYTE、HPE、Lenovo、Pegatron、QCT、Schneider Electric、Vertiv、Wistron，官方说法是2027 年初在全球范围提供。

这里有一个常被忽略的前提，值得单独讲：官方措辞是「接入已经准备好的站点」（prepared site）。DSX POD 压缩的是工厂内部的集成与安装工序，站点侧的电力到位、冷却管网、建筑与并网审批并不在其中。所以「六个月变 14 天」在真实项目里的落点，通常取决于场地准备是否与工厂制造并行推进——这两条线只要有一条没并行，整体工期就还是被它卡着。这不是官方说的，是我按官方措辞读出来的边界，选型时值得照着核。

三、Minerva：把五层遥测连成一张图#

Minerva 的定位是 AIOps 平台，官方的核心动词是「连」（connect）。它接的遥测横跨五层：

1. GPU：包括 ConnectX SuperNIC、BlueField DPU 这类卡上网络部件；
2. 网络：NVLink 向上扩展交换机、Spectrum-X 东西向与南北向以太网；
3. 存储与调度器：NCCL 通信、作业调度器；
4. AI 作业本身：训练与推理任务；
5. 站点设施：官方表述里的 site 层信号。

把这些信号连起来之后，它做的事情是三件：

• 建动态知识图。 把基础设施实体（GPU、SuperNIC、交换机、线缆）和跑在上面的作业在逻辑上映射到一起。官方举的用法是：把「某个训练作业变慢了」追到具体是哪个部件拖的——在几十万卡的工厂里也能追。
• 每秒分析数十亿数据点，用有监督加无监督的机器学习：学正常行为基线、检测没见过的异常、预测正在酝酿的故障、按工厂拓扑关联相关事件。
• 把事件风暴收敛成一条带根因的事件。 不是把每个症状都推给运维，而是聚合成一个可操作项。

交互层有两个入口：平台原生的 AI 助手（名字叫 Sherlock，多智能体架构），以及一个 MCP server——意味着外部 agent 工具（Claude 一类）可以直接查它的实时遥测。官方明确留了两种收尾方式：人工确认后动手修，或者通过基础设施 API 接到自动化流程里。

采用方名单：IREN 已经用上了，其 CTO 的说法是运维团队第一次在网络、GPU 和跑在上面的作业之间有了同一个视图，于是可以把重心从排障挪向前瞻性维护。此外 Aolani、Bitdeer AI、IBM、Jio、Lambda、Quake AI、Tesla 计划部署；Dell、Lenovo、Supermicro 会把它并进各自的 AI 工厂运维产品线。Bitdeer 那边还补了一条部署形态：可独立部署，也集成进 NVIDIA DSX OS。

四、官方没给的数字，第三方给了#

官方博客对效果的描述是定性的三条：更长的中断间隔（MTBI）、更快的修复时间（MTTR）、更高的洞察密度。一个具体数字都没给。

第三方给了两个，但要注意来源层级——Bitdeer AI 博客说这是英伟达内部 AI 工厂测试的结果：

• 一起 NVMe 掉电故障，MTTR 从数天级停机降到六小时；
• 一次事件风暴里 81 条噪音事件被收敛成单条告警，省下 54 小时集群在线时间。

这两个数字的用法要小心：它们是单例，不是统计口径，而且经过一次转述。当你要拿它给老板算 ROI 时，请把它们当「量级参考」而不是「预期值」——真正该做的是在自己的集群上先把 goodput 的定义和采集打通，再去看基线。

五、goodput 到底是什么#

官方的定义是四个组成项：GPU 小时、goodput、集群在线率、token 产出。翻成人话，一座 AI 工厂的良率问的是三个问题：

• 有多少卡在跑？（GPU 小时、在线率）
• 那些卡跑的部分是不是有用的？（goodput）
• 整座工厂产出了多少 token？

第二问是关键，也是传统监控最容易骗人的地方。DCGM_FI_DEV_GPU_UTIL 显示 100% 的卡，完全可能正卡在等通信、等数据、或者在功耗与温度双重限制下跑低频——它「很忙」，但没在做有用功。这也是官方博客开头专门点的那类警号：某张卡比同伴更热、某块 NVMe 在负载下降速。这类劣化不会让作业报错，只会让它变慢，然后在一个大集群里被平均掉。

所以 goodput 的正确读法不是「吞吐」，而是「有效工作量 ÷ 可用容量」。有了这个口径，一个部件级的劣化就能被折算成 GPU 小时，再折算成钱。

六、代码：用 DCGM 指标算一页良率报表#

下面这套口径可以直接跑。核心是三条 PromQL——注意指标名用的是 DCGM exporter 官方计数器文件里的真名（DCGM_FI_DEV_GPU_UTIL / DCGM_FI_PROF_PIPE_TENSOR_ACTIVE / DCGM_FI_DEV_XID_ERRORS）：

# 在跑的卡数
count(DCGM_FI_DEV_GPU_UTIL)

# 有效算力占比（tensor 管线活跃周期比例，0-1）
avg(DCGM_FI_PROF_PIPE_TENSOR_ACTIVE)

# 出过 XID 错误的卡数（>0 即最近一次报错）
count(DCGM_FI_DEV_XID_ERRORS > 0)

# 「假忙」卡数：利用率不低，但 tensor 管线几乎不动
count((DCGM_FI_DEV_GPU_UTIL > 50) and (DCGM_FI_PROF_PIPE_TENSOR_ACTIVE < 0.10))

# 产出：由框架侧上报的累计 token 计数
sum(ai_factory_tokens_total)

把这几条折成 GPU 小时的脚本如下（--mock 用内置样本验口径，不带参数则查真实 Prometheus）：

#!/usr/bin/env python3
"""factory_yield.py — 把 DCGM 指标折算成「AI 工厂良率」的一页报表。"""
import argparse, json, random, urllib.parse, urllib.request

QUERIES = {
    "gpus":         "count(DCGM_FI_DEV_GPU_UTIL)",
    "tensor":       "avg(DCGM_FI_PROF_PIPE_TENSOR_ACTIVE)",
    "xid":          "count(DCGM_FI_DEV_XID_ERRORS > 0)",
    "falsely_busy": "count((DCGM_FI_DEV_GPU_UTIL > 50) "
                    "and (DCGM_FI_PROF_PIPE_TENSOR_ACTIVE < 0.10))",
    "tokens":       "sum(ai_factory_tokens_total)",
}


def prom_range(base, expr, minutes, step=60):
    end = int(__import__("time").time())
    q = urllib.parse.urlencode({"query": expr, "start": end - minutes * 60,
                                "end": end, "step": step})
    with urllib.request.urlopen(f"{base}/api/v1/query_range?{q}", timeout=20) as r:
        return json.load(r)["data"]["result"]


def mock_series(minutes=60, step=60, n=8192, degrade_at=40):
    """样本：8192 卡集群，第 40 分钟起有 96 张卡进入「假忙」状态。
    固定随机种子，保证文中的输出可复现。"""
    random.seed(7)
    out = {k: [] for k in QUERIES}
    tok = 0.0
    for i in range(minutes // (step // 60) + 1):
        busy = 0 if i < degrade_at else 96
        tp = 0.62 - 0.0115 * (busy / 96) + random.uniform(-0.006, 0.006)
        tok += n * 41.5 * step * max(tp, 0.0)
        for k, v in (("gpus", n), ("tensor", round(tp, 4)),
                     ("xid", 1 if i >= degrade_at else 0),
                     ("falsely_busy", busy), ("tokens", round(tok, 1))):
            out[k].append(v)
    return out


def fetch(series, step_s=60):
    """比率型指标（tensor active）要乘 GPU 数；计数型（XID、假忙卡数）本身就是卡数。"""
    n = max(series["gpus"])
    step_h = step_s / 3600.0
    total_h = (len(series["gpus"]) - 1) * step_h
    integral = lambda vals: sum(vals[:-1]) * step_h

    gpu_hours = n * total_h
    tensor_hours = integral(series["tensor"]) * n
    xid_hours, busy_hours = integral(series["xid"]), integral(series["falsely_busy"])
    tokens = series["tokens"][-1] - series["tokens"][0]
    return {
        "窗口(小时)": round(total_h, 2),
        "GPU 数": n,
        "GPU 小时": round(gpu_hours, 1),
        "tensor 活跃 GPU 小时": round(tensor_hours, 1),
        "XID 影响 GPU 小时": round(xid_hours, 1),
        "「假忙」GPU 小时": round(busy_hours, 1),
        "有效 token": int(tokens),
        "良率 yield": round(tensor_hours / gpu_hours, 4),
        "token/GPU 小时": int(tokens / gpu_hours) if gpu_hours else 0,
        "XID 报废占比": round(xid_hours / gpu_hours, 5),
    }


if __name__ == "__main__":
    ap = argparse.ArgumentParser()
    ap.add_argument("--mock", action="store_true")
    ap.add_argument("--prom", default="http://localhost:9090")
    ap.add_argument("--minutes", type=int, default=60)
    a = ap.parse_args()

    if a.mock:
        data = mock_series(a.minutes)
    else:
        data = {}
        for k, q in QUERIES.items():
            res = prom_range(a.prom, q, a.minutes)
            data[k] = [float(val) for _, val in res[0]["values"]] if res else [0.0]
    for k, v in fetch(data).items():
        print(f"  {k:<22} {v}")

跑 --mock（样本数据，合成）的真实输出：

record: MOCK 样本
  窗口(小时)                 1.0
  GPU 数                  8192
  GPU 小时                 8192.0
  tensor 活跃 GPU 小时       5041.3
  XID 影响 GPU 小时          0.3
  「假忙」GPU 小时             32.0
  有效 token               753063119
  良率 yield               0.6154
  token/GPU 小时           91926
  XID 报废占比               4e-05

这份报表把三件原本混在一起的事拆开了：良率 0.6154 说明这 8192 卡一小时的容量里，只有约六成时间 tensor 管线是活跃的；XID 报废 0.3 GPU 小时说明硬报错其实极小；而**「假忙」32 GPU 小时**说明真凶是那 96 张利用率过 50%、tensor 管线却几乎不动的卡。传统只看 GPU 利用率的看板在这个场景下会显示一切正常——这正好是官方强调的「一张卡比同伴更热」那类隐性劣化。

注意口径上的两个坑：DCGM_FI_PROF_PIPE_TENSOR_ACTIVE 是比率，折 GPU 小时要乘卡数；count(...) 出来的 XID、假忙本身已经是卡数，再乘卡数就会把量级算错两个数量级。上面脚本里的 fetch() 就是为了这个才把两类指标分开处理——我自己第一版就踩了这个坑。

还有一个更隐蔽的口径问题在分母上：「GPU 小时」用的是「已交付的卡」还是「还在集群里的卡」？ 如果分母只算健康在册的卡，一台坏卡被运维摘掉之后，它就从分母里消失了——集群会因此越坏越「好看」。要让良率能横向比、能纵向看趋势，分母应当固定为已交付容量（把摘掉的卡按报废 GPU 小时记在账上），而不是随健康状态浮动。Minerva 官方把「GPU 小时」和「集群在线率」并列成两个组成项，我理解正是为了不让这两笔账互相掩盖。

七、自建集群时的落地清单#

如果你不是租方，而是自己要搭一套类似的东西，按重要性排序：

1. 先把 goodput 的定义写下来再采数据。 分子用「有效 token」还是「有效样本」？无效指哪些（padding、掉队重算、重放）？口径没定就上监控，最后只会得到一堆互相矛盾的看板。
2. 给指标打上作业标签。 知识图的价值在于能把「作业变慢」追到「哪张卡」，前提是 GPU 指标和作业 ID 能对上。这一步要在调度器接入时就做，事后补非常痛。
3. 采 DCGM_FI_PROF_PIPE_TENSOR_ACTIVE，别只采利用率。 利用率是「忙不忙」，tensor 活跃度才接近「有没有在算」。
4. 把 XID 和 NCCL 超时当作作业级信号处理。 单卡的 XID 往往只让整个作业变慢，而不是报错退出。
5. 采集频率与开销要实测。 DCP 系列指标（profiling 类）与基础计数器的采样代价不同，逐卡高频采集在大集群上本身就是一个负载，先量清楚再加密度。
6. 告警要按拓扑聚合。 官方把「81 条收敛成 1 条」当成成果，是因为事件风暴本身就是一次运维事故：一位工程师在 81 条里找根因的时间，等于集群白跑的 GPU 小时。

清单之外，还有一件可以用上面这套指标立刻做的事：预测性排空。把三类信号叠起来看——某张卡的 tensor 活跃度相对它自己的历史基线持续下滑、温度在同排卡里离群、XID 计数在累积——就足以在作业边界上把这台节点排空检查，而不是等它真报错中断整个作业。官方说的「更长的中断间隔」（MTBI）实际就是这个动作的结果。这里的关键是基线要按卡自己算，拿集群平均值当基线会把正常的热区误判成故障：同一排机柜、同一批次的卡，温度本来就是有分布的。

八、总结#

这两次发布合起来讲的其实是一件事：AI 基础设施的竞争，从「能不能买到卡」挪到了「卡到手之后能不能一直产出」。 DSX POD 把交付周期按天算，解决的是入场速度；Minerva 把五层遥测连成知识图、把 goodput 抬成核心指标，解决的是入场之后的良率。

对做基础设施的人来说，最值得立刻动手的不是等着接 Minerva，而是先把 goodput 的口径和采集打通。官方给了四个组成项却没给公式，第三方给了两个亮眼数字却是单例——这意味着现阶段谁先在自己的集群上把「有效 GPU 小时」算清楚，谁就先知道自己到底在浪费什么。上面那个 factory_yield.py 是一个起点：它能跑，也能说明问题。

参考与致谢：

• 英伟达官方博客《NVIDIA Unveils Minerva to Bring End-to-End Observability for AI Factories》（2026-10-22）
• 英伟达官方新闻稿《NVIDIA Introduces DSX POD AI Factories to Accelerate Europe’s Infrastructure Deployment》（2026-10-21）
• Bitdeer AI 博客（2026-10-22，转述英伟达内部测试数字）
• DCGM exporter 官方计数器文件 etc/default-counters.csv（指标名以此为准）
• 非投资建议；文中数字均注明来源层级，未标注者为官方口径。