Jimmy Song – 生产落地

平台责任：DGX、HGX、MGX 与整机思维

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

相关的采购问题不是“里面是什么 GPU”，而是“我们得到怎样的支持边界和经过验证的升级路径？”

四个标签，四种责任

标签	传递什么信号	该问的问题
DGX	NVIDIA 整机系统与支持模型	什么经过了验证？故障归谁？
HGX	供 OEM 实现的加速服务器平台	实际出货的是哪套机箱/拓扑/固件？
MGX	模块化参考架构	哪些模块今天和明年经过组合验证？
云 GPU	供应商自有物理平台即服务	真实的拓扑、租户与可用性契约是什么？

表 1: DGX/HGX/MGX/云 GPU 的责任分层

**DGX：整机系统责任。**DGX 是 NVIDIA 的整机系统与软件产品，价值在于 GPU、网络、存储、系统软件、支持与生命周期的验证组合。
**HGX：面向系统构建者的平台设计。**HGX 被 OEM 用来构建加速系统，最终服务器取决于 OEM 的 CPU、机箱、固件、网卡、存储、散热和服务方案，两台贴着 HGX 标签的服务器在运营上可能截然不同。
**MGX：模块化参考架构。**NVIDIA 把 MGX 描述为面向 OEM/ODM 的开放模块化参考架构，支持 GPU、CPU、网络、PCIe 与机架级设计的组合（宣称超过 100 种）。MGX 是一套设计词汇，不是一台固定设备。

这与世代、模块与产品语言的五层词汇一脉相承：平台标签回答的是“集成度与责任的边界在哪里”。

功耗、散热与可维护性是算力特性

一台高密度 GPU 服务器是一个电气与热学系统。功率上限会影响持续性能（见微架构的功耗墙）；散热设计影响降频、噪声、维护和机架密度；液冷改变机房要求与服务流程；备件策略影响可用性。

不要仅凭基准图表批准集群

把机架功率、单节点功耗、散热容量、线缆与交换机布局、故障更换、固件所有权、以及排空并恢复一个节点所需的时间都算进采购决策。功耗与散热的更多运营视角见容量经济与AI 时代的功耗维度。

总结

平台选型的本质是选择责任边界：DGX 把验证与支持打包，HGX 把责任切给 OEM 与集成商，MGX 提供组合词汇，云 GPU 把一切变成服务契约。无论选哪条路，功耗、散热与可维护性都不是“机房的事”，而是算力特性本身。

参考资料

NVIDIA MGX Platform for Modular Server Design。

容量经济：购买、租赁还是组合

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

核心变量不是每 GPU 小时的价格，而是每单位有用完成工作的价格。

买还是租，是一条利用率曲线

租赁把硬件所有权变成可变容量，可以缩短实验启动时间；购买在利用率稳定时改善控制力、数据本地性和摊销；混合策略可以预留可预测的基线容量，并向云或专业供应商突发。

每单位有用产出的成本 = (计算 + 存储 + 网络 + 电费 + 支持 + 工程 + 故障储备) / 完成的工作量

这个分式是诊断工具，不是完整的经济模型：它把“单价比较”换成了“总拥有视角”。

容量决策表

因素	租赁占优当……	购买占优当……
需求	突发或不确定	稳定的高利用率
时间	立刻需要容量	有整合投入的时间
数据	数据能安全廉价地移动	数据本地性主导
硬件	供应商有确切 SKU/拓扑	需要受限的定制设计
运维	供应商支持有价值	自有强大平台团队
风险	需要灵活性	能吸收残值与故障

表 1: 租与买的决策因素

度量利用率悬崖

一个集群可能在总体上“很忙”，而昂贵的 GPU 碎片化地散在各节点上，等待某个作业需要的精确拓扑（NUMA与调度问题域的碎片问题）；反过来，集群利用率低也可能只是因为作业被卡在策略瓶颈后面。

不要只看全网平均值

度量每 GPU 利用率、排队时间、碎片化、内存余量和作业完成情况，而不是一个机群平均数。把“忙”翻译成“每单位有用产出的成本”，采购决策才有依据。

总结

容量决策是经济学的延伸，经济学跟随架构，架构跟随工作负载契约（见生产架构）。租买组合的答案不在供应商的报价单里，而在你自己的利用率曲线与成本分式里。

生产架构：契约、节点池与平面划分

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

在写 YAML 之前先写契约：工作负载契约是硬件、节点池、配额与 SLO 的共同依据。

工作负载契约

契约内容：模型与版本、精度、内存占用、序列长度、批次、并发、延迟/吞吐目标、故障恢复、检查点、数据路径、安全边界和预期增长。它与基准与验收的验收清单是同一件事的两面：一份定义“要什么”，一份验证“拿到了什么”。

GPU 节点池是产品档位

不要把异构机群当作每个节点都可互换来运营。按 GPU 世代、内存档位、外形规格、互连、工作负载类别、可用区和生命周期阶段建池，一致地打标签和污点（见放置策略），实验池与生产池分开。每个池对应一种平台责任边界与一种成本结构（见容量经济）。

五个平面

平面	职责	控制手段
控制	API、调度器、准入、自动伸缩、策略	RBAC、配额、优先级、队列
GPU 计算	驱动、运行时、插件、工作负载容器	金丝雀节点、污点、版本锁定
数据	数据集、模型、缓存、检查点	局部性、完整性、加密、保留
网络	训练集合通信与服务流量	RDMA 策略、分段、拥塞
可观测	健康、容量、作业、SLO、成本	DCGM、Prometheus、日志、追踪

表 1: 生产 AI 平台的平面划分

这张表与控制面地图的分层互为镜像：地图讲“哪些组件在哪一层”，平面讲“哪类责任归谁管”。

命名空间契约

apiVersion: v1
kind: ResourceQuota
metadata:
 name: gpu-team-quota
 namespace: ai-team
spec:
 hard:
 requests.nvidia.com/gpu: "8"
 limits.nvidia.com/gpu: "8"
 requests.cpu: "64"
 requests.memory: 512Gi
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
 name: inference-pdb
 namespace: ai-team
spec:
 minAvailable: 2
 selector:
 matchLabels:
 app: inference

具体的配额键与控制器行为应对照集群的资源模型验证，尤其在使用 DRA 或共享设备时。

总结

生产架构 = 契约（要什么）+ 节点池（放在哪）+ 平面（谁负责）+ 命名空间（归谁用）。这四件事写清楚，端到端实战中的每一条命令才有了上下文。

NVIDIA × CNCF：开放 AI 基础设施运动

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

“Kubernetes 是 AI 数据中心的关键操作系统，是现代 AI 工厂的编排层。”（黄仁勋，KubeCon EU 2026）这不是营销话术：NVIDIA 已是 CNCF 白金会员并在积极贡献代码。

为什么 NVIDIA 全力押注开源

NVIDIA 在 2024–2026 年的战略转变引人注目：一家靠专有软件（CUDA、cuDNN、TensorRT）构筑护城河的公司，正在系统性地开源其 Kubernetes 与 AI 基础设施组件。为什么？

答案是 NVIDIA 的竞争优势已经上移。GPU 硬件就是护城河，短期内没有人在硅片上追上 NVIDIA。把基础设施层开放并交给社区治理，意味着更多工程师学会在 NVIDIA 硬件上构建、更多面向 NVIDIA GPU 的集成存在、更少企业客户被许可问题卡住。

CNCF 贡献版图

贡献	是什么	状态
KAI Scheduler	开源 Kubernetes GPU 调度器：成组调度、拓扑感知放置、分层队列	CNCF Sandbox（2025）
NVIDIA GPU DRA Driver	发布 ResourceSlice 并处理 DRA 分配的驱动实现	捐赠给 CNCF / Kubernetes 项目（2026 年 4 月）
Grove	编排 AI 工作负载（推理集群、LLM-d 集成）的开源 Kubernetes API	随 DRA 捐赠一同开源
380 万美元 GPU 捐赠	捐给 CNCF 的云 GPU 额度，用于真实 GPU 上测试 Kubernetes	于 KubeCon EU 2026 宣布
GPU Operator	自动化整个 GPU 栈生命周期的 Operator（Apache 2.0）	2020 年建立，积极维护
NVCF（NVIDIA Cloud Functions）	GPU 函数服务的控制平面	2026 年 4 月开源
Kubernetes AI 一致性	与 CNCF 合作定义 AI 工作负载一致性测试	2026 年进行中

表 1: NVIDIA 的主要 CNCF 贡献

对本书主线而言，最重要的是前两行：KAI Scheduler 补上了调度器缺口，DRA Driver 捐赠让数据平面·DRA的路径有了社区治理的驱动实现。

KAI Scheduler 深入解析

KAI（Kubernetes AI）Scheduler 2025 年 4 月以 Apache 2.0 开源并被 CNCF Sandbox 接纳。它解决了默认 kube-scheduler 在 GPU 工作负载上的三个关键缺口：

成组调度（Gang Scheduling）： 分布式训练作业需要 N 个 Pod 同时启动。默认调度器逐个放置 Pod，你可能落得 7/8 个 Pod 在跑、占着 7 块 GPU，而第 8 个因为找不到合适拓扑的 GPU 无法调度，7 个运行中的 Pod 全体闲置，资源在死锁中浪费。KAI 的 PodGroup 保证 N 个 Pod 原子化调度：要么全启动，要么全不启动。
分层队列管理： 团队需要 GPU 配额管理。A 队保底 16 块 GPU、空闲时可突发到 32；B 队保底 8 块。KAI 实现分层队列：保底分配受保护，高优先级作业需要时突发容量被回收。
NUMA 感知放置： KAI 读取 NodeResourceTopology 对象，在调度器层面做出满足 NUMA 约束的放置决策，在 Pod 到达 kubelet 之前，杜绝“先调度后拒绝”循环（见NUMA 感知调度）。

# 安装 KAI Scheduler
helm install kai-scheduler \
 oci://ghcr.io/nvidia/kai-scheduler/charts/kai-scheduler \
 --namespace kai-scheduler --create-namespace

# 成组调度：8-GPU 分布式训练的 PodGroup
apiVersion: scheduling.run.ai/v2alpha2
kind: PodGroup
metadata:
 name: llama-70b-training
 namespace: ml-team
spec:
 minMember: 8 # 8 个 Pod 必须同时启动
 minResources:
 nvidia.com/gpu: 8
 queue: team-ml-research
 priorityClassName: high-priority

# 带 GPU 配额的队列
apiVersion: run.ai/v1
kind: Queue
metadata:
 name: team-ml-research
spec:
 deservedGPUs: 16 # 保底分配
 maxAllowedGPUs: 32 # 集群空闲时可突发到 32
 gpuPriority: 100 # 高优先级可抢占低优先级

成组调度与队列治理正是 Volcano 与 Kueue的核心语义；KAI 的加入让“GPU 原生”调度器在 CNCF 里有了第三个选项，也印证了生态趋势的判断：调度正在从“放置”走向“队列治理 + 资源运营”。

总结

NVIDIA 把基础设施层开源，是把护城河集中到硅片、把生态放大到软件的战略选择。对平台团队而言，这意味着控制面的可选项在变多：KAI 补调度缺口、DRA 捐赠补驱动治理、一致性测试补验收标准。评估它们时，用决策轴的框架而不是“新就上”。

端到端实战：从裸机节点到训练作业

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

每一条命令都达到生产可用。这一章是全书的“接线图”，把软件栈、设备插件、Operator、NUMA 与监控串成一条时间线。

环境

项目	值
节点 OS	Ubuntu 24.04 LTS
GPU	1× NVIDIA H100 80GB SXM5（DGX H100 节点）
Kubernetes	v1.34（DRA GA）
GPU Operator	v26.3.0
NVIDIA 驱动目标	570.x（由 GPU Operator 管理）
容器运行时	containerd v2.0

表 1: 实战环境

第 1 步：准备节点（K8s 之前）

# 在 GPU 节点上（纯净 OS，尚未装驱动）
sudo apt-get update
sudo apt-get install -y curl apt-transport-https ca-certificates gnupg lsb-release

# 安装 containerd
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor \
 -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] \
 https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" \
 | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt-get update && sudo apt-get install -y containerd.io

# 配置 containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd

# 加入集群
sudo kubeadm join <control-plane-ip>:6443 --token <token> \
 --discovery-token-ca-cert-hash sha256:<hash>

# 此刻：节点在集群里，但没有 GPU 支持
kubectl describe node gpu-node-01 | grep 'nvidia.com'
# GPU 对 Kubernetes 不可见

第 2 步：部署 GPU Operator

# 在控制平面 / 管理机上
curl -fsSL https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia && helm repo update

helm install --wait --generate-name \
 -n gpu-operator --create-namespace \
 nvidia/gpu-operator \
 --version=v26.3.0 \
 --set driver.enabled=true \
 --set driver.version='570.86.10' \
 --set toolkit.enabled=true \
 --set devicePlugin.enabled=true \
 --set dcgmExporter.enabled=true \
 --set dcgmExporter.serviceMonitor.enabled=true \
 --set migManager.enabled=true \
 --set nfd.enabled=true \
 --set gfd.enabled=true

第 3 步：观察自举顺序

watch kubectl get pods -n gpu-operator
# 预期顺序（与 GPU Operator 章的八步对应）：
# 1. node-feature-discovery 启动 → 打 OS/内核标签
# 2. nvidia-driver-daemonset 启动 → 编译并加载 nvidia.ko（首次 2–5 分钟）
# 3. nvidia-container-toolkit 启动 → 配置 containerd
# 4. gpu-feature-discovery 启动 → 打 GPU 型号标签
# 5. nvidia-device-plugin 启动 → 注册 nvidia.com/gpu
# 6. nvidia-dcgm-exporter 启动 → 暴露指标
# 7. nvidia-mig-manager 启动 → 管理 MIG（空闲）
# 8. nvidia-operator-validator 启动 → CUDA 冒烟测试

kubectl describe node gpu-node-01 | grep -A3 'Allocatable'
# Allocatable:
# nvidia.com/gpu: 1 ← 成功！GPU 已注册

第 4 步：运行 GPU 验证 Pod

kubectl run nvidia-smi-test \
 --image=nvcr.io/nvidia/cuda:12.6.0-base-ubuntu22.04 \
 --restart=Never \
 --limits='nvidia.com/gpu=1' \
 -- nvidia-smi

kubectl logs nvidia-smi-test
# +---------------------------------------------------------------------+
# | NVIDIA-SMI 570.86.10 Driver Version: 570.86.10 CUDA Version: 13.1|
# +-------+---------------------+------+------+------------------------+
# | 0 | NVIDIA H100 80GB HBM3 On | 00000000:1E:00.0 |
# +-------+---------------------+------+------+------------------------+
# | 30W / 700W | 1023MiB / 81920MiB | 0% Default |
# +---------------------------------------------------------------------+

kubectl delete pod nvidia-smi-test

第 5 步：配置 NUMA 感知调度

# 在 GPU 节点上配置 kubelet
sudo tee -a /var/lib/kubelet/config.yaml << 'EOF'
cpuManagerPolicy: static
topologyManagerPolicy: single-numa-node
topologyManagerScope: pod
memoryManagerPolicy: Static
reservedMemory:
- numaNode: 0
 limits:
 memory: 4Gi
EOF

# 策略变更后必须清理管理器状态
sudo systemctl stop kubelet
sudo rm -f /var/lib/kubelet/cpu_manager_state
sudo rm -f /var/lib/kubelet/memory_manager_state
sudo systemctl start kubelet

sudo journalctl -u kubelet | grep -i topology
# 'topology manager policy: single-numa-node'

第 6 步：运行分布式训练作业

---
apiVersion: batch/v1
kind: Job
metadata:
 name: pytorch-training
 namespace: ml-team
spec:
 template:
 spec:
 restartPolicy: Never
 nodeSelector:
 nvidia.com/gpu.product: NVIDIA-H100-80GB-HBM3
 tolerations:
 - key: nvidia.com/gpu
 operator: Exists
 effect: NoSchedule
 containers:
 - name: trainer
 image: nvcr.io/nvidia/pytorch:25.03-py3
 command:
 - python
 - -c
 - |
 import torch
 print(f'CUDA available: {torch.cuda.is_available()}')
 print(f'GPU count: {torch.cuda.device_count()}')
 print(f'GPU name: {torch.cuda.get_device_name(0)}')
 x = torch.randn(4096, 4096, device='cuda')
 y = torch.mm(x, x)
 print(f'MatMul result shape: {y.shape} -- GPU compute verified!')
 resources:
 limits:
 nvidia.com/gpu: '1'
 memory: 64Gi
 cpu: '16'
 requests:
 nvidia.com/gpu: '1'
 memory: 64Gi
 cpu: '16'
 env:
 - name: NCCL_DEBUG
 value: INFO
 - name: CUDA_VISIBLE_DEVICES
 value: '0'

第 7 步：用 DCGM 监控

kubectl get svc -n gpu-operator | grep dcgm
# nvidia-dcgm-exporter ClusterIP 10.96.xxx.xxx 9400/TCP

kubectl port-forward svc/nvidia-dcgm-exporter 9400:9400 -n gpu-operator &
curl -s localhost:9400/metrics | grep DCGM_FI_DEV_GPU_UTIL
# DCGM_FI_DEV_GPU_UTIL{gpu='0',UUID='GPU-xxxx',...} 87.0

# 训练期间的关键指标（口径详见“可观测”部分）：
# DCGM_FI_DEV_GPU_UTIL -> 活跃 matmul 期间应为 85-99%
# DCGM_FI_DEV_MEM_COPY_UTIL -> 数据加载期间升高
# DCGM_FI_DEV_FB_USED -> 显存占用（警惕逼近上限的 OOM）
# DCGM_FI_DEV_POWER_USAGE -> H100 SXM 满载应为 600-700W
# DCGM_FI_DEV_GPU_TEMP -> 满载通常 65-80°C（健康）
# DCGM_FI_DEV_XID_ERRORS -> 必须为 0，非零立即排查
# DCGM_FI_DEV_SM_CLOCK -> 应处于加速频率（H100 约 1800 MHz）

# GPU 健康诊断
kubectl exec -n gpu-operator -it nvidia-dcgm-exporter-xxxxx -- dcgmi diag -r 1
# -r 1 短诊断（30 秒）/ -r 2 中等（90 秒）/ -r 3 完整 burn-in（约 10 分钟）

总结

七步走完，恰好对应全书的机制链条：容器运行时与驱动（软件栈）→ 设备注册（设备模型）→ Operator 自举（GPU Operator）→ 拓扑对齐（NUMA）→ 负载（工作负载）→ 验收（可观测）。把这套流程套进实施顺序的阶段 1–3，就是一台 GPU 节点从上架到生产的完整剧本。

安全、可靠性与生命周期

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

一个平台可靠，是指它能可预见地失败并恢复，而不是它从不报错。

安全边界

GPU 工作负载常常携带模型权重、专有数据和凭据。实施最小权限 RBAC、镜像溯源与扫描、秘密管控、网络策略、命名空间隔离，以及受限的主机设备接口访问。

特权组件需要更高级别的信任审查

驱动容器和特权 DaemonSet（NVIDIA 驱动容器、HAMi 核态模块、DRA 驱动等）应接受比普通应用 Pod 更高级别的信任审查，它们运行在主机内核边界上。

可靠性是恢复时间

GPU 故障在单节点上罕见，在大型机群中却常见，要按机群规模做概率预算。使用检查点、幂等作业、重试预算、优雅终止、健康门禁、副本容量和有文档的隔离（quarantine）流程。检查点策略与训练作业的恢复契约直接相关（见工作负载物理的训练一节）。

版本矩阵

Kubernetes 版本: ______________________
节点 OS / 内核: ________________________
GPU 型号 / 固件: _______________________
NVIDIA 驱动: ___________________________
CUDA 运行时 / 工具链: ___________________
Container Toolkit: _____________________
GPU Operator / 插件 / DRA: _____________
框架 / 推理引擎: _______________________
NCCL / RDMA 栈: ________________________
已验证的工作负载镜像摘要: ______________

这份矩阵是软件栈“兼容性方向”一节的落地工具：尽可能一次只升级一个维度。当协同升级无法避免时，对整栈做金丝雀（流程见GPU Operator的升级循环），而不是孤立地测试组件。

总结

安全回答“谁可以碰什么”，可靠性回答“坏了之后多久恢复”，生命周期回答“变更如何被验证地推进”。三者共同的生产出口，是下一章实施顺序的验收清单。

实施顺序：从工作负载定义到生产化

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

阶段 0 的产出物是一份工作负载画像，不是一个 GPU 品牌。

阶段 0：定义工作负载

写下工作负载契约、内存预算、精度、并发与失败行为。这是生产架构工作负载契约的第一次落地。

阶段 1：验证单节点

检查拓扑与健康（检查仪式），运行驱动/运行时冒烟测试、内存与计算基线，以及一个代表性应用。

阶段 2：验证单服务器

运行一块、两块和全部 GPU，记录扩展效率、内存余量、集合通信时长、功率与失败行为；单节点内外的行为差异见互连与集合通信。

阶段 3：验证 Kubernetes

应用标签、污点、配额、一个诊断 Pod 和一个代表性工作负载，验证分配、重启、日志、指标和排空行为，一条龙的完整命令见端到端实战。

阶段 4：验证多节点

运行一个已知良好的集合通信基准和真实工作负载，测试网络故障、节点故障、检查点恢复和排队行为。

阶段 5：生产化

补上 SLO、容量预测、准入控制、镜像溯源、金丝雀升级、操作手册与责任归属。生产始于恢复路径被演练之时。

验收清单

序号	验收检查	完成
1	工作负载契约包含精度、内存、延迟/吞吐与恢复行为	☐
2	GPU SKU、外形规格、内存、功率、链路与拓扑被精确记录	☐
3	驱动、CUDA、运行时、插件/DRA、Operator、框架与 NCCL 版本已锁定	☐
4	单 GPU、单节点与多节点基线已记录	☐
5	排队时间、吞吐、错误、温度与内存余量可观测	☐
6	升级、排空、检查点、隔离与更换手册已测试	☐

表 1: 上生产前的六项验收

总结

六个阶段把全书的机制变成一条时间线：先定义再验证、先单点再集成、先演练再生产。验收清单六项全勾之前，你拥有的是一套很有希望的组件；六项全勾之后，你才拥有一个平台。