第 14 章 AI InfraGPU分布式训练

第 14 章 集群架构与调度

第14章 集群架构与调度

本章覆盖 GPU 集群的组网与三网分离设计、HPC 与 Kubernetes 双轨调度体系、批调度与多租户 QoS，以及数据中心功 耗液冷与整集群设计实践。各调度器的全部命令行参数、具体版本差异与厂商细节不在本章展开。

14.1 GPU 集群网络拓扑设计

GPU集群的网络拓扑设计是决定大规模AI训练效率的核心基础设施命题。随着模型参数规模突破万亿、训练节点数达到万 卡级别，网络通信开销已从“可忽略的次要因素”上升为“制约训练效率的首要瓶颈”。Meta在其2022年Research SuperCluster（RSC）论文中明确指出：在16,000个A100 GPU上训练大语言模型时，网络通信占据端到端训练时间的比 例可达40%以上。 本节系统分析四种主流GPU集群网络拓扑方案，从带宽对分比、超额认购比、成本复杂度等维度进行对比剖析。

14.1.1 Fat-Tree 拓扑

Fat-Tree（胖树）是传统高性能计算和早期GPU集群中使用最广泛的拓扑结构。其核心思想是：叶层（Leaf/ToR）交换机 负责连接计算节点，脊层（Spine）交换机提供叶层之间的全连接，随着层级上升，链路带宽逐步“增胖”。 经典Fat-Tree拓扑特征： 标准的2层Fat-Tree逻辑拓扑如图14-1所示。假设每个ToR连接 k 个下行端口（面向计算节点）和 k 个上行端口（面向 Spine），Spine交换机数量也为 k ，则总GPU节点数为 k²/2 。以400Gbps端口的64口交换机为例，可支持2048个GPU节 点。 Spine Layer: k switches Spine 1 Spine 2 Node 1 Spine k Leaf/ToR Layer: k switches Node 2 ToR 1 Node k^2/2 ToR 2 ToR k 图14-1 二层 Fat-Tree 逻辑拓扑 超额认购比（Oversubscription Ratio）： Fat-Tree的关键设计参数是超额认购比。在1:1非阻塞Fat-Tree中，每块GPU获得与上行链路等价的跨机通信带宽——即每 个GPU可用的上行带宽等于其下行带宽（例如每个GPU独享400Gbps）。但这种全带宽Fat-Tree的成本极高：要达到1:1的 超额认购比，网络设备成本可能占到集群总成本的15%-25%。 实践中，多数训练集群采用2:1甚至3:1的超额认购比。以NVIDIA DGX SuperPOD参考架构为例：每个DGX节点配备8块 H100 GPU，通过8块ConnectX-7网卡（每卡400Gbps）接入网络，单节点上行总带宽为3.2Tbps。以32个节点（256 GPU）为组网单元计算，上行总带宽约102.4Tbps，需4台64端口QM9700交换机（4×64×400Gbps）才能提供1:1的 Fat-Tree上行连接。 带宽对分分析： 对N个节点的Fat-Tree网络，对分带宽定义为将网络平分为两组时，两组之间可用的总带宽。在1:1 Fat-Tree中，对分带宽 为 N × GPU_BW / 2 ，即任意节点都能以线速与另一半节点通信。但对于AI训练中典型的AllReduce通信模式，Fat-Tree 拓扑容易在上行链路产生热点拥塞，尤其是在Ring-AllReduce算法下。

14.1.2 Dragonfly+拓扑

Dragonfly+是Cray（现HPE）提出的直接拓扑结构，旨在以更低的设备成本实现接近Fat-Tree的性能。其核心设计思想是 将节点组织成“组”（Group），组内全连接，组间通过自适应路由（Adaptive Routing）实现多路径负载均衡。 Dragonfly+拓扑特征： •组内连接：每个组包含 a 个路由器，组内所有路由器之间通过全连接互联，形成一个小型全连接子网。 •组间连接：每个路由器通过 h 条全局链路连接至其他组的路由器，全局链路的分配遵循循环排列规则，确保每个组到 其他组的路径数相等。 •自适应路由：Dragonfly+的关键创新在于自适应路由——当一条跨组路径出现拥塞时，数据包可自动切换到另一条间接 路径（通过中间组中转）。 ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Group 0 │ │ Group 1 │ │ Group 2 │ │ ┌─┐ ┌─┐ │ │ ┌─┐ ┌─┐ │ │ ┌─┐ ┌─┐ │ │ │R│──│R│ │ ─── │ │R│──│R│ │ ─── │ │R│──│R│ │ │ └─┘ └─┘ │ │ └─┘ └─┘ │ │ └─┘ └─┘ │ │ ┌─┐ ┌─┐ │ │ ┌─┐ ┌─┐ │ │ ┌─┐ ┌─┐ │ │ │R│──│R│ │ │ │R│──│R│ │ │ │R│──│R│ │ │ └─┘ └─┘ │ │ └─┘ └─┘ │ │ └─┘ └─┘ │ └─────────────┘ └─────────────┘ └─────────────┘ 成本效率分析： 与传统Fat-Tree相比，Dragonfly+的电缆和设备成本可降低约40%-50%。其代价是路由复杂度增加：自适应路由需要对 拥塞状态进行实时感知，引入额外的延迟抖动。对于AI训练这种对尾部延迟高度敏感的负载，Dragonfly+需要精心调优的 路由策略来平衡负载。 AI训练的适配性： AllReduce通信模式在Dragonfly+上有天然优势：由于组内全连接，组内Ring-AllReduce的通信效率极高；而跨组 AllReduce可通过多路径并行传输降低拥塞概率。Meta的Research SuperCluster（RSC）早期实验采用过类似 Dragonfly+的Clos-Dragonfly混合拓扑。

14.1.3 Rail-Optimized 拓扑

Rail-Optimized拓扑是NVIDIA为DGX SuperPOD和HGX平台专门设计的网络架构。其核心思想是将InfiniBand网络 按“Rail”（轨道）组织，每个Rail对应一个逻辑交换机平面，每个DGX节点在每个Rail上贡献一块GPU网卡。 Rail-Optimized工作原理： 在8-GPU的DGX节点中，每个节点有8块ConnectX-7网卡。设计8个InfiniBand交换机Rail（Rail 0至Rail 7），每个Rail上 的交换机连接每个DGX节点的同一块网卡（例如Rail 0连接所有节点的网卡0）。 DGX Node 0: GPU0▶NIC0──Rail 0 Switch───┐ GPU1▶NIC1──Rail 1 Switch───┤ ... ├─ full-mesh AllReduce GPU7▶NIC7──Rail 7 Switch───┘ DGX Node N: GPU0▶NIC0──Rail 0 Switch───┐ GPU1▶NIC1──Rail 1 Switch───┤ ... ├─ full-mesh AllReduce GPU7▶NIC7──Rail 7 Switch───┘ Rail-Optimized对AI训练的优势：

  1. AllReduce效率最大化：基于Rail-Optimized的Sharp（Scalable Hierarchical Aggregation Reduction Protocol）可 在交换机内部完成Reduce操作。相比 Ring-AllReduce 需要 O(N) 步（2(N-1) 次收发）依次传递数据，Sharp 通过树 形聚合将通信轮数降低到 O(log N) 步，并将归约计算卸载到交换机执行，从而在大规模集群上获得接近线速的 AllReduce 性能。
  2. 故障隔离：每个Rail独立运行，单个Rail的交换机故障只影响每节点一块GPU的通信，不会导致整体训练中断。
  3. NCCL拓扑匹配：NCCL（NVIDIA Collective Communications Library）的Rail算法针对这种拓扑做了深度优化，使 Ring-AllReduce和Tree-AllReduce可以充分利用Rail结构，其具体通信流程在训练后端平面设计中说明。 NVIDIA Quantum-2平台：基于NVIDIA Quantum-2（NDR 400Gbps）交换机的Rail-Optimized SuperPOD可支持最多 128个DGX H100节点（1024块H100 GPU）。按每 GPU 一条 400 Gbps 网卡计算，总聚合单向带宽约 51.2 TB/s（1024 × 400 Gbps ÷ 8），在 1:1 非阻塞 Fat-Tree 下对分带宽（bisection bandwidth）约为 25.6 TB/s。 14.1.4 3D-Torus 拓扑 3D-Torus是一种直接互联拓扑，每个节点与其在三维网格中的6个邻居直接相连（前后左右上下），且每个维度的首尾节 点也相连形成环（Torus）。 3D-Torus的特征： Google的TPU Pod采用了2D-Torus（v2/v3）和3D-Torus（v4/v5）拓扑。以TPU v4 Pod为例，4096个TPU v4芯片被组 织在3D-Torus拓扑中，每个TPU芯片通过 6 条专属高速链路（ICI - Inter-Chip Interconnect）与相邻芯片互联。根据 Google 官方数据，整个 TPU v4 Pod 的对分带宽（bisection bandwidth）约为 24 TB/s，全 Pod all-reduce 带宽可达约 1.1 PB/s。 z=z+1

▲ │ x=x-1 ◀───┼───▶ x=x+1 │ ▼ z=z-1 (y dimension perpendicular to page) 3D-Torus在AI训练中的表现： •数据并行友好：AllReduce在3D-Torus上可沿每个维度分别归约，利用环通信特性的叠加实现高效聚合。 •模型并行友好：TP（Tensor Parallelism，张量并行）/PP（Pipeline Parallelism，流水线并行）切分可以沿Torus的 某个维度就近放置，最小化跨片通信延迟。 •扩展性限制：随着规模扩大，3D-Torus的平均跳数（hop count）以 O(N^{1/3}) 增长，最大直径（diameter）成为尾 部延迟的主要来源。 Google在TPU v5p中将Torus拓扑与光路交换（OCS - Optical Circuit Switching）结合，使得拓扑可以在线重构，动态适 应不同并行策略的通信需求。

14.1.5 拓扑方案对比与选型

四种拓扑方案的关键属性对比如表14-1所示。 表14-1 主流网络拓扑方案对比 拓扑方案 成本 AllReduce性能 扩展性 故障韧性 典型规模 Fat-Tree (1:1) 极高 优 (Sharp) 受限于Spine端口 好 ≤2000 GPU Fat-Tree (2:1) 高 良 中等 好 ≤4000 GPU Dragonfly+ 中 良 (自适应路由) 优 一般 5000+ GPU Rail-Optimized 高 优 (Sharp) 受限于Rail数 优 ≤1000 GPU/Rail簇 3D-Torus 低 良 受限于直径 优 (多路径) 4000+ TPU Meta RSC的设计启示： Meta的Research SuperCluster（RSC）采用了Wedge400C ToR + Minipack2 Spine的Fat-Tree架构，2:1超额认购比，结 合F16模块化数据中心设计。RSC部署了16,000块A100 GPU，在训练OPT-175B模型时，通过NCCL拓扑文件优化和IB Sharp技术，将通信时间压缩到总训练时间的25%以下。 网络规模估算公式： 对于一个N个GPU的训练集群，所需的总网络带宽下限为： Bmin = N × BGP U /Oratio 其中B 为单GPU网卡带宽，O 为目标超额认购比。例如，一个2048块H100的集群，单GPU网卡400Gbps，目标超 额认购比1.5:1，则总上行带宽需求为 2048 × 400 / 1.5 ≈ 546 Tbps ，对应约1365个400Gbps交换机端口（546133 GP U ratio Gbps ÷ 400 Gbps）。 实际部署中，还需考虑NCCL通信算法优化、Sharp交换机聚合、以及容错路由的额外开销。推荐在初次部署时预留20% 的端口余量用于未来扩容和故障替换。

14.2 三网分离设计

在大规模AI训练集群中，网络流量呈现出鲜明的异构特征：训练后端流量带宽极高、对尾部延迟极端敏感；管理流量零散 但不可中断；存储流量持续但带宽可控。将这些流量混合在同一张网络上，会导致“吵闹邻居”（Noisy Neighbor）效应 ——管理平面的广播风暴可能阻塞AllReduce的关键数据包，存储平面的数据迁移可能挤占训练通信的带宽。 三网分离设计正是针对这一问题的系统性解决方案。本节详细阐述计算/管理平面、训练后端平面、存储平面的独立设计 与协同运作，整体架构如图14-2所示。

14.2.1 三网架构总览

三网分离的核心理念是“物理隔离、逻辑协同”：每台计算节点至少配备三套独立的网络适配器，分别接入三个物理网络 平面。 ┌──────────────────────────────────────────────────────────────┐ │ DGX/GPU Compute Node │ │ ┌──────────────┐ ┌──────────────────┐ ┌──────────────┐ │ │ │ 1GbE/25GbE │ │ 400Gbps IB/RoCE │ │ 100GbE/200GbE│ │ │ │ Management │ │ Training Backend │ │ Storage │ │ │ └──────┬───────┘ └────────┬─────────┘ └──────┬───────┘ │ └─────────┼───────────────────┼───────────────────┼────────────┘ │ │ │ ┌──────┴───────┐ ┌──────┴───────┐ ┌──────┴───────┐ │ Management │ │ Training │ │ Storage │ │ Network │ │ Backend │ │ Network │ │ (North-South)│ │ (East-West) │ │ (East-West) │ └──────────────┘ └──────────────┘ └──────────────┘ 图14-2 AI集群三网分离架构

14.2.2 计算/管理平面

管理平面承载集群的“控制流量”：SSH登录、监控数据采集（Prometheus Node Exporter、DCGM Exporter）、容器镜 像拉取、配置管理（Ansible/Salt）、调度器信令（SLURM controller通信、K8s API Server）、以及用户Jupyter Notebook/VSCode等交互式工作负载的Web流量。 网络规格： •带宽需求：通常使用1GbE或25GbE即可满足绝大多数场景。每节点平均管理流量带宽约100-500Mbps。 •交换机选型：标准数据中心ToR交换机（如Arista 7050SX3系列、Cisco Nexus 9300系列），每端口25GbE，上行可配置 100GbE。 •协议：标准TCP/IP协议栈，无需RDMA支持。 IP地址与VLAN规划： 管理平面通常采用带外（Out-of-Band）管理网段，通过BMC/IPMI接口实现远程电源管理。典型配置： Management plane IP planning example: VLAN: 100 (management VLAN) Subnet: 10.100.0.0/16 IP allocation:

     - 10.100.0.1/16: management gateway
     - 10.100.0.10-19: core switch management ports
     - 10.100.1.0/24: rack 1 nodes (10.100.1.1~10.100.1.254)
     - 10.100.2.0/24: rack 2 nodes
     - 10.100.254.0/24: storage management ports

容器镜像分发优化： 管理平面的一个重要负载是容器镜像拉取。当Kubernetes调度一个PyTorch Job到100个节点时，100个kubelet同时从镜 像仓库拉取同一镜像，可能导致管理平面拥堵。解决策略包括：

  1. 镜像预拉取（Pre-pulling）：通过DaemonSet在集群空闲时预先拉取常用镜像到每台节点。
  2. P2P镜像分发（Dragonfly/Kraken）：在节点间通过P2P方式分发镜像层，避免集中访问中心镜像仓库。
  3. 节点级镜像缓存：使用containerd的本地镜像存储层，结合镜像层去重减少磁盘占用。

14.2.3 训练后端平面

训练后端平面是AI集群网络的“心脏”，承载着模型训练中所有的GPU间通信（AllReduce、AllGather、ReduceScatter 等）。这是对网络带宽和延迟要求最高的平面。 网络规格： •带宽：每GPU至少配备400Gbps（H100 DGX节点：8 GPU × 400Gbps = 3.2Tbps/节点）。新一代B200/GB300平台已 提升至800Gbps/GPU（配套ConnectX-8 SuperNIC）。 •延迟：端到端延迟需控制在微秒级别（InfiniBand NDR 交换机直通延迟 < 0.1μs，端到端 MPI 消息延迟 约1-3μs； RoCEv2 端到端 约5-10μs）。 •协议：InfiniBand（IB）或RoCEv2（RDMA over Converged Ethernet）。IB在性能和生态上仍占优势，RoCEv2在成本 和灵活性上有竞争力。 两种协议对AI训练的适用性对比如表14-2所示。 表14-2 InfiniBand 与 RoCEv2 对比 维度 InfiniBand (NDR) RoCEv2 单端口带宽 400Gbps (NDR) / 800Gbps (XDR) 400Gbps 端到端延迟 <1μs (交换机)，约3μs (端到端) 约5μs-10μs 拥塞控制 基于信用的无损控制 DCQCN/ECN（调优复杂） Sharp聚合 原生支持 需交换机支持 成本 高（专用交换机+网卡） 中（标准以太网交换机） 生态成熟度 NVIDIA NCCL深度优化 需额外调优 UEC 1.0 与 AI 网络 2025 版图：Ultra Ethernet Consortium（UEC）2025 年发布 1.0 规范，AI 网络从 InfiniBand 一家独 大进入三足鼎立。UEC 三大关键技术：(1) 选择性重传（Selective ACK 替代 IB 的 Go-Back-N），10K GPU 规模下 0.01% 丢包时 P99 AllReduce 抖动从 2× 降至 +20%；(2) Packet Spraying：每个包独立选路替代 ECMP per-flow hash，消除 链路热点；(3) 网内聚合：在交换机端做 Reduce，目标延迟 < 2μs。 同时 NVIDIA Spectrum-X 在以太网上实现自适应路由和拥塞控制，已成为 RoCEv2 的主要竞争方案。选型决策已不再是 单纯的“训练用 IB”——UEC 以太网方案在供应链安全性和成本上的优势（交换机价格约为 IB 交换机的一半）正在重塑 AI 网络的格局。 在 8-Rail 配置（如 DGX H100 SuperPOD）下，NCCL Rail 算法自动检测 Rail 拓扑，在每个 Rail 上独立执行 ReduceScatter，交换机内 Sharp 完成 Reduce，最后跨 Rail 执行 AllGather，将 AllReduce 的通信轮数缩减到理论下 界。Rail 的组网概念已在拓扑设计中说明。

14.2.4 存储平面

存储平面承载训练数据的读写和模型检查点的保存。与训练后端不同，存储流量是“持续性、带宽可控、对瞬时抖动容忍 度较高”的。 网络规格： •带宽：每节点100Gbps-200Gbps以太网，根据数据集大小和检查点间隔确定。 •协议：NFSv4、Lustre（LNet over Ethernet）、NVMe-oF（NVMe over Fabrics）、S3 over HTTP。 •隔离必要性：大数据集加载时的峰值流量可达100Gbps/节点，如果与训练后端混合，将严重干扰AllReduce通信。 并行文件系统客户端网络配置：

Lustre client LNet configuration

/etc/modprobe.d/lnet.conf

options lnet networks="tcp(eth2)" routes=""

 # or use multi-NIC
 # configure LACP bonding for storage
 # /etc/sysconfig/network-scripts/ifcfg-bond0
 DEVICE=bond0
 BONDING_OPTS="mode=4 miimon=100 lacp_rate=fast"

存储平面流量特征分析： 以训练Llama 2 70B模型为例，在2000个H100 GPU上： •数据加载：每个GPU的DataLoader需要约2-5Gbps的存储读取带宽（取决于样本大小和预处理方式）。 •检查点保存：每N步（如1000步）需要将70B × 2 bytes = 140GB的模型权重写入并行文件系统。使用异步检查点 （Async Checkpointing）可将写入阻塞时间压缩到秒级。 •推荐为存储平面分配每节点100Gbps的以太网连接，并启用Jumbo Frame（MTU 9000）减少协议开销。

14.2.5 典型部署案例

案例1：NVIDIA DGX SuperPOD (H100) NVIDIA的DGX H100 SuperPOD参考架构是一个三网分离的典型案例： •管理平面：每DGX节点1个1GbE BMC口 + 1个25GbE管理口，接入管理交换机。 •训练后端：8个ConnectX-7 IB NDR（400Gbps）网卡，接入8个Rail的Quantum-2 IB交换机，支持Sharp网络内计算。 •存储平面：2个ConnectX-6 Lx以太网卡（25GbE×2），LACP绑定为50Gbps，接入存储网络。 案例2：大型企业混合云AI集群 某大型金融企业在私有数据中心部署了800个H100 GPU的AI训练集群： •管理平面：25GbE ToR交换机，VLAN隔离管理流量、Kubernetes API流量和用户流量。 •训练后端：400Gbps RoCEv2（Cisco Nexus 9000系列交换机），启用ECN标记和DCQCN拥塞控制，经内部团队三个月 调优将PFC暂停帧发生率降至<0.01%。 •存储平面：200Gbps专用以太网交换机，连接WekaFS并行文件系统集群。每节点一个200Gbps网卡，通过PCIe Gen4 ×16接入。 案例3：Meta Research SuperCluster Meta的RSC在16,000个A100 GPU上采用了类三网分离的设计： •管理/前端：25GbE管理网络，覆盖所有计算节点和存储节点。 •训练后端：200Gbps InfiniBand HDR，采用Clos拓扑（非Rail结构），2:1超额认购比。Meta团队通过在NCCL中实现自 定义拓扑感知通信算法，在2:1超额认购比下仍实现了接近理论值的AllReduce带宽。 •存储：AirStore数据存储系统，通过独立的100GbE网络连接到AI集群。RSC的设计经验表明，在万卡规模下，存储平面 的网络带宽需求会随着数据加载的并行度增加而线性增长。

14.2.6 常见设计误区

  1. 误区：训练后端和存储平面可以合用RoCE网络。 实际上，NCCL AllReduce通信对尾部延迟极度敏感（单个GPU的网 络抖动会导致AllReduce全组降速），而存储I/O会产生不可预测的突发流量。合用网络导致的PFC风暴可能使AllReduce 延迟从微秒级飙升到毫秒级，训练吞吐下降30%以上。
  2. 误区：管理平面带宽越低越好。 虽然日常管理流量不大，但故障恢复场景下（如NCCL超时触发连接重建、大量容器日 志回传），管理平面可能成为恢复速度的瓶颈。建议至少25GbE。
  3. 误区：光纤模块可以随意混用。 400Gbps光模块（QSFP-DD）有多个供应商和型号，不同型号的功耗、信号质量、延 迟差异显著。混用可能导致链路偶尔出现CRC错误，在训练中表现为NCCL超时。应统一使用同一批次的光模块。

14.2.7 RDMA 网络配置与调优

RDMA 网络达到满带宽吞吐，网卡配置与内核参数是关键。训练后端平面通常用高速网卡（400Gbps 级别）配合 RoCEv2 或 IB 承载 NCCL 通信，本节给出从拥塞控制到网卡虚拟化、再到内核参数与验证的完整配置链路。

  1. RoCEv2 拥塞控制调优 RoCEv2 依赖无损网络保证（PFC/ECN），调优目标是消灭 PFC 风暴、把端到端延迟控制在微秒级： •ECN 先于 PFC 触发（最关键原则）：交换机侧 ECN 阈值（建议 ECN_MIN≈200KB、ECN_MAX≈400KB）须显著低于 PFC XOFF 阈值（通常 1-2MB），让拥塞控制在数据包被暂停前生效，避免 PFC 级联传播。阈值倒置是最常见配置错 误，可导致 AllReduce 延迟从微秒级飙升至毫秒级。 •DCQCN 参数：RoCE 端点启用 DCQCN 拥塞控制，调整 rtt_res 、 rate 相关参数适配集群规模；浅缓冲交换机需更 激进的 ECN 标记。 •流量隔离与优先级：将 AI 训练流量绑定到独立的 PFC 优先级（如 CoS 3），与存储流量严格隔离；DCQCN 的拥塞通知 包（CNP）分配独立且更高的 DSCP 值（通常 DSCP=48），避免 CNP 本身被拥塞丢弃导致控制环路失效。 •MTU 全链路统一：AI 训练流量推荐 MTU=4096，需在网卡、中间交换机和 OS 三层一致配置。MTU 不匹配是导致 NCCL 性能劣化且难以诊断的常见隐患。 •监控指标：通过 ethtool -S ethX | grep pause 或 DCGM 实时监控 PFC 暂停帧，生产目标是暂停帧发生率 < 0.01%；同时监控 CNP 生成速率，高 CNP 速率（>1% 数据包）表明网络持续拥塞需进一步调优。 经过上述调优，RoCEv2 在 400 Gbps 链路上的端到端延迟可从默认配置的 15-30μs 降低至 5-8μs，接近 InfiniBand 水 平，AllReduce 吞吐损失可控制在 5% 以内。
  2. SR-IOV 网卡虚拟化 SR-IOV（Single Root I/O Virtualization）将单个物理网卡虚拟化为多个 VF（Virtual Function），每个 VF 可直通给独立 容器/VM，实现网络隔离与性能保障。物理网卡（PF）承载管理面，VF 承载数据面。

Enable SR-IOV and create VFs (mlx5 NIC as example)

Require SR-IOV enabled in BIOS and vfio-pci module loaded

modprobe vfio-pci echo 8 > /sys/class/net/enp3s0f0np0/device/sriov_numvfs # create 8 VFs ip link show # verify VFs are created K8s 中通过 SR-IOV Network Device Plugin 把 VF 作为资源暴露给 Pod（ sriov.intel.com/vf: "1" ），配合 Multus CNI 让 Pod 同时接入管理网与训练后端网。关键约束：VF 数量受网卡型号限制（如 ConnectX-7 单 PF 最多 128 VF），且 VF 的 QoS（带宽上限）需在 PF 上配置。 3) 内核参数与 CPU 绑核 RDMA 满带宽运行依赖内核网络参数的配套调整：

 # Key sysctl for RDMA and network performance
 sysctl -w net.core.rmem_max=67108864        # large receive buffer for high-speed bursts
 sysctl -w net.core.wmem_max=67108864
 sysctl -w net.core.netdev_max_backlog=10000
 sysctl -w net.ipv4.conf.all.rp_filter=0     # disable reverse path filtering for multi-path

网卡与 CPU 绑核：RDMA 中断与队列绑定到与 GPU 同 NUMA 节点的 CPU 核，避免跨 NUMA 访问； mlx5 驱动支持 irqbalance 禁用后手动绑核。 4) 满带宽验证 配置完成后须验证实际吞吐而非只信理论值： • ib_write_bw / ib_read_bw ：测单流 RDMA 读写带宽，确认接近网卡线速。 •NCCL AllReduce 测试：测集合通信吞吐，确认达到预期（如 400Gbps 网卡对分带宽下的 AllReduce 速率）。 •多流并发：单流达标但多流差，通常是 ECN/PFC 阈值或哈希不均问题。 5) IB 子网管理 IB 网络的配置与 RoCE 不同，依赖子网管理器（Subnet Manager，SM）维护路由表。生产环境 SM 需冗余部署（主 备），节点上线时自动接入子网；拓扑感知（按 rail 组网）时 SM 配置需匹配物理拓扑，否则流量跨 rail 绕行，吞吐打 折。典型 QoS 配置如下：

IB subnet manager configuration example

/etc/opensm/opensm.conf

subnet_prefix 0xfe80000000000000 console off log_file /var/log/opensm.log qos TRUE qos_max_vls 4 qos_high_limit 0 qos_vlarb_high 0:4,1:4,2:4,3:4 qos_vlarb_low 0:1,1:1,2:1,3:1 qos_sl2vl 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15

14.3 HPC 调度器的 AI 适配

HPC领域数十年的资源调度经验为AI工作负载管理提供了成熟的基础设施。SLURM、PBS Pro和IBM LSF等传统HPC调度 器仍在大量AI集群中扮演核心角色——尤其是在传统超算中心和国家实验室建设的AI计算平台上。然而，AI工作负载（尤 其是大模型分布式训练）与传统的MPI并行作业存在本质差异，需要对这些调度器进行针对性的适配。

14.3.1 AI 工作负载调度特征

将AI训练作业映射到HPC调度框架中，需要在调度粒度、资源请求方式和作业生命周期管理上做出关键调整。传统HPC作 业与AI训练作业的差异对比如表14-3所示。 表14-3 传统HPC作业与AI训练作业对比 特征维度 传统HPC作业 AI训练作业 资源粒度 CPU核 GPU设备 并行方式 MPI进程 torchrun + NCCL多进程 作业时长 分钟到小时 数天到数周 弹性需求 几乎不需要 可容忍（Elastic Training） 检查点频率 低频（手动） 高频（每N步自动） 失败重试 从头开始 从检查点恢复 网络拓扑 关注进程放置 关注GPU拓扑感知

14.3.2 SLURM GPU 调度

SLURM（Simple Linux Utility for Resource Management）是AI集群中使用最广泛的HPC调度器。其通过GRES （Generic Resource Scheduling）机制支持GPU资源管理。 GRES GPU配置： 在 slurm.conf 中启用GPU GRES支持：

 # slurm.conf GPU GRES configuration
 GresTypes=gpu
 # declare GPU resources in node
 NodeName=gpu[001-200] NodeAddr=10.100.1.[1-200] \
   CPUs=256 Sockets=2 CoresPerSocket=64 ThreadsPerCore=2 \
   RealMemory=515000 Gres=gpu:H100:8 \
   Feature=H100,ib_ndr

gres.conf配置文件：

 # /etc/slurm/gres.conf
 # requires precise mapping of GPU devices to CPU cores
 Name=gpu Type=H100 File=/dev/nvidia0 Cores=0-31
 Name=gpu Type=H100 File=/dev/nvidia1 Cores=32-63
 Name=gpu Type=H100 File=/dev/nvidia2 Cores=64-95
 Name=gpu Type=H100 File=/dev/nvidia3 Cores=96-127
 Name=gpu Type=H100 File=/dev/nvidia4 Cores=128-159
 Name=gpu Type=H100 File=/dev/nvidia5 Cores=160-191
 Name=gpu Type=H100 File=/dev/nvidia6 Cores=192-223
 Name=gpu Type=H100 File=/dev/nvidia7 Cores=224-255

GPU拓扑亲和性： SLURM通过 nvml-auto-affinity 插件实现GPU-CPU的NUMA亲和绑定：

 # enable GPU topology awareness
 TaskPlugin=task/affinity,task/cgroup
 # optional: enable NVML auto GPU-CPU affinity
 # SchedulerParameters=gpu_affinity=nvml

提交AI训练作业：

 #!/bin/bash
 #SBATCH --job-name=llama2-70b-train
 #SBATCH --nodes=64
 #SBATCH --gpus-per-node=8
 #SBATCH --gres=gpu:H100:8
 #SBATCH --ntasks-per-node=8
 #SBATCH --cpus-per-task=16
 #SBATCH --mem=0                    # use all node memory
 #SBATCH --time=7-00:00:00          # 7 days
 #SBATCH --partition=gpu-h100
 #SBATCH --output=%x-%j.out
 #SBATCH --error=%x-%j.err
 #SBATCH --exclusive                # exclusive node
 # get the master node address and port for distributed training

export MASTER_ADDR=$(scontrol show hostnames "$SLURM_JOB_NODELIST" | head -n1) export MASTER_PORT=29500

launch torchrun via srun

srun --container-image=nvcr.io#nvidia/pytorch:24.01-py3
torchrun \

   --nnodes=$SLURM_NNODES \
   --nproc_per_node=8 \
   --rdzv_id=$SLURM_JOB_ID \
   --rdzv_backend=c10d \
   --rdzv_endpoint=$MASTER_ADDR:$MASTER_PORT \
   train.py --model llama2-70b --config config.yaml

GPU亲和性（GPU Affinity）： SLURM可以控制每个任务可见的GPU设备列表：

 # use CUDA_VISIBLE_DEVICES to restrict visible GPUs per task
 # in sbatch script:
 #SBATCH --gpus-per-task=1
 # SLURM automatically sets CUDA_VISIBLE_DEVICES
 # or manually specify GPU binding
 #SBATCH --gpu-bind=single:1     # bind 1 GPU per task
 #SBATCH --gpu-bind=closest      # auto-select NUMA-closest GPU

作业数组（Job Array）与超参数搜索：

 # hyperparameter search: 100 combinations running
 #SBATCH --array=0-99
 #SBATCH --gpus-per-node=1
 # select hyperparameters based on SLURM_ARRAY_TASK_ID
 LR_LIST=(1e-4 2e-4 5e-4 1e-3 2e-3)
 BATCH_LIST=(32 64 128 256 512)
 IDX=$SLURM_ARRAY_TASK_ID
 LR=${LR_LIST[$((IDX / 5))]}
 BATCH=${BATCH_LIST[$((IDX % 5))]}

python train.py --lr $LR --batch-size $BATCH

14.3.3 调度算法基础

调度算法决定了在资源受限时“谁先运行、何时运行”。理解经典批调度算法的原理与缺陷，是分析生产集群调度行为、 诊断调度异常的前提。

  1. FIFO与优先级队列 FIFO（First In First Out）按提交顺序执行作业，实现简单、行为可预期，但存在两个经典缺陷： •队头阻塞：一个长作业占据队首时，其后所有短作业全部等待，集群整体周转时间被拉长。 •饥饿（Starvation）：引入严格优先级后，高优先级作业持续插队，低优先级作业可能无限期等待。 与之相关的优先级倒置（Priority Inversion）指低优先级作业持有某资源（如独占节点）不放，阻塞了高优先级作业的运 行。SLURM 通过多因子优先级（ PriorityType=priority/multifactor ）综合多个维度计算优先级，并配合抢占机制 缓解上述问题。
  2. EASY Backfill回填 回填（Backfill）在不推迟“预留作业”启动时间的前提下，把空闲资源临时分配给低优先级作业，是提升 HPC 集群利用 率的决定性机制。EASY（Extensible Argonne Scheduling System）Backfill 是最经典的回填算法，其核心约束有三条：
  1. 队首最高优先级作业被视为预留作业（Reservation），先估算其预计开始时间。
  2. 后续低优先级作业只能利用该作业开始前的空闲空隙，且必须在其开始前完成。
  3. 低优先级作业不改变预留作业的启动时间——这是回填与抢占的本质区别。 SLURM 通过 SchedulerType=sched/backfill 启用，并用 SchedulerParameters 调优：
 # slurm.conf backfill configuration
 SchedulerType=sched/backfill
 # window: only backfill within 1 day ahead
 # resolution: re-evaluate every 60 seconds
 # continue: keep scheduling after job start
 SchedulerParameters=bf_window=86400,bf_resolution=60,bf_continue
 # create an explicit reservation for a large job

scontrol create reservation starttime=now+2h duration=24:00:00
nodes=gpu[001-064] user=ai-user reservationname=big-run 作业显式预留可用 --reservation=big-run 提交，EASY Backfill 的调度空隙如图14-3所示。 Queue (priority order) Node timeline Job A: 64 nodes, 7 days (he Reserved: Job A (64 nodes) ad) Job C: 16 nodes, 1 day Idle gap: 32 nodes Job B: 32 nodes, 2 days Backfill: Job B fills gap 图14-3 EASY Backfill 预留空隙示意 3) 公平共享与 FairTree 公平共享（Fair-share）让历史上使用资源较少的用户或队列获得更高优先级，抑制“先到先得”造成的不公平。SLURM 的 FairTree 算法通过树状结构描述账户层级，其优先级衰减模型为 F/2^depth ： •根节点携带总份额 F（默认 1），每下降一层，该账户分得父节点份额的 1/2 。 •深度为 d 的账户理论份额为 F / 2^d ，即账户层级越深份额指数衰减。 •实际优先级还叠加使用量修正：近期使用越多，份额得分越低，从而向使用较少的账户倾斜。 配置示例：

 # slurm.conf fair-share configuration
 PriorityType=priority/multifactor
 PriorityFlags=FAIR_TREE,NO_NORMAL_ALL
 PriorityWeightFairshare=5000
 PriorityWeightQOS=1000
 # prior usage decays over 24 hours
 PriorityDecayHalfLife=24:00:00
  1. 抢占的三种模式 SLURM 抢占支持 cancel 、 requeue 、 suspend 三种模式，对 AI 作业的适配性差异显著，如表14-4所示。 表14-4 SLURM 抢占模式对比 模式 行为 GPU 显存 作业恢复 AI 适配性 cancel 直接终止作业 立即释放 需重新提交 低（丢失进度） requeue 终止并重新排队 立即释放 重新调度后从 checkpoint 恢复 高（配合高频 checkpoint） suspend SIGSTOP 挂起 保留（HBM 不释放） 恢复信号继续 低（显存无法回收） AI 训练推荐 requeue 配合检查点，原因有三： •显存不可挂起： suspend 保留的是内存，GPU HBM 仍被进程独占，无法被其他作业复用，对提升利用率毫无帮助。 •checkpoint 恢复成本低：训练每 N 步写一次 checkpoint，重新排队后从最近 checkpoint 继续，丢失的算力仅为若干 分钟。 •释放资源立即见效： requeue 释放 GPU 后可立刻承载高优先级作业，配合 --requeue 与 --qos=preemptible 即 可实现。
  2. SLURM QoS与优先级配置 大规模AI集群需要精细的作业优先级管理，通过 QoS 定义与抢占参数组合实现：
 # SLURM defines QoS levels
 # sacctmgr add qos critical Priority
 # sacctmgr add qos normal Priority
 # sacctmgr add qos preemptible Priority
 # submit preemptible job
 #SBATCH --qos=preemptible
 #SBATCH --requeue             # auto-requeue after preemption
  1. 多级反馈队列与 AI 场景 多级反馈队列（MLFQ）维护多个递减优先级的就绪队列，作业根据累计运行时长被降级到低优先级队列，在队内按时间 片轮转。它同时兼顾短作业优先响应与长作业不饥饿，是操作系统与在线服务调度的经典算法。 MLFQ 在 AI 场景的适用性有限：GPU 作业不适合时间片式抢占（进程上下文切换无法回收显存，NCCL 集合通信被切碎 后性能崩塌），且训练作业时长均匀（数天到数周），短任务优先的收益不明显。因此 GPU 批调度的主流组合是优先级加 回填加公平共享，MLFQ 仅适合混部集群中对 CPU 在线服务的排队控制。 工程要点 调度算法是 AI Infra 工程中最常被深究的核心问题，掌握以下要点有助于准确分析生产集群的调度行为： •F/2^depth 模型：fairshare 随账户深度指数衰减，是 FairTree 与线性加权最本质的差异，也是预测多级账户共享份额 的基础。 •EASY Backfill 约束：回填不得推迟最高优先级作业的预计开始时间，这是回填与抢占的本质区别。 •requeue 选择理由：从“GPU 显存不可 suspend 回收”与“checkpoint 恢复成本”两个角度说明为何 AI 训练选 requeue。 •算法适配边界：MLFQ 不直接适用于 GPU 调度，根源在于 GPU 资源的不可抢占性与训练作业的时长均匀性。

14.3.4 PBS 与 LSF 的 GPU 支持

PBS Pro GPU配置：

 # declare GPU resources in PBS
 # qmgr -c "create resource gpu type=gpu flag=nh"
 # qmgr -c "set node gpu-node01 resources_available.ngpus=8"
 # submit GPU job
 #PBS -l select=16:ncpus=64:ngpus=8
 #PBS -l walltime=168:00:00
 #PBS -q gpu_queue
 torchrun --nnodes=$(wc -l < $PBS_NODEFILE) \
   --nproc_per_node=8 train.py

IBM LSF GPU配置：

lsb.resources configuration

Begin Resource RESOURCENAME TYPE INTERVAL LOCATION gpu Numeric 1 [all] End Resource

14.3.5 SLURM 与 K8s 混合调度

 # submit job
 #BSUB -n 128
 #BSUB -gpu "num=8:mode=exclusive_process"
 #BSUB -W 168:00
 #BSUB -q gpu_h100
 # LSF GPU exclusive mode options
 # mode=exclusive_process: each GPU assigned to a single process
 # mode=shared: multiple processes can share one GPU

在大型AI平台中，SLURM和Kubernetes通常共存： •SLURM：负责大规模“批训练”作业（64+节点、数天运行时间），直接管理裸金属GPU节点。 •Kubernetes：负责交互式开发（Jupyter Notebook）、模型服务（推理）、小规模实验（1-4节点）。 两者的协调通过以下模式实现：

  1. 分区模式：集群物理分区，SLURM管理训练区，K8s管理服务区，通过RoCE/IB网络互通。
  2. 分层模式：K8s集群运行在顶部，通过Virtual Kubelet或KubeRay将批训练作业转发到底层SLURM集群。
  3. 统一接口：用户通过统一平台提交作业，平台根据作业特征（资源规模、运行时长、弹性需求）自动路由到SLURM或 K8s。

14.4 Kubernetes GPU 调度深度

Kubernetes作为云原生编排的事实标准，正在迅速渗透AI Infra领域。截至Kubernetes 1.30，GPU调度已经从简单的 “设备计数”演进为支持拓扑感知、MIG分区、动态资源分配和时间共享的全功能框架。本节深入剖析K8s GPU调度的核 心技术和生产实践。

14.4.1 NVIDIA Device Plugin 架构

NVIDIA GPU在Kubernetes中的调度始于Device Plugin机制。其工作流程如下： ┌──────────────┐ ┌──────────────────────┐ ┌──────────────┐ │ kubelet │────▶│ NVIDIA Device Plugin│────▶│ nvidia- │ │ (per node) │◀────│ (DaemonSet Pod) │◀────│ driver │ └──────┬───────┘ └──────────────────────┘ └──────────────┘ │ │ ListAndWatch (gRPC) ▼ ┌───────────────┐ │ kube-scheduler│ │ (centralized) │ └───────────────┘

  1. NVIDIA Device Plugin以DaemonSet形式部署在每个GPU节点上。
  2. Plugin启动后，扫描节点的GPU设备，通过gRPC向kubelet注册 nvidia.com/gpu 资源。
  3. kubelet将该资源上报至API Server，使scheduler能够进行GPU感知调度。
  4. Pod请求GPU时，scheduler选择满足 nvidia.com/gpu 数量要求的节点。
  5. Pod创建时，kubelet调用Device Plugin的 Allocate() 方法，Plugin通过设置环境变量 （ NVIDIA_VISIBLE_DEVICES ）将指定的GPU分配给容器。 Device Plugin核心配置：

NVIDIA Device Plugin DaemonSet

apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset namespace: kube-system spec: selector: matchLabels: name: nvidia-device-plugin-ds template: metadata: labels: name: nvidia-device-plugin-ds spec: containers: - name: nvidia-device-plugin-ctr image: nvcr.io/nvidia/k8s-device-plugin:v0.15.0 env: - name: FAIL_ON_INIT_ERROR value: "false" # enable MIG support - name: MIG_STRATEGY value: "mixed" # none, single, mixed # time-slicing configuration - name: NVIDIA_DEVICE_PLUGIN_MPS value: "false" securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] volumeMounts: - name: device-plugin mountPath: /var/lib/kubelet/device-plugins volumes: - name: device-plugin hostPath: path: /var/lib/kubelet/device-plugins

14.4.2 MIG 在 Kubernetes 中的支持

NVIDIA MIG（Multi-Instance GPU）允许将一块物理H100/H200/A100 GPU分割为多个独立的GPU实例，每个实例拥有 专属的SM、显存、L2缓存和内存带宽。在Kubernetes中，Device Plugin自动发现MIG分区并暴露为独立资源。 MIG资源类型：

 # H100 MIG configuration
 # each instance is exposed as
 # query MIG resources on node

$ kubectl describe node gpu-node-01 | grep nvidia.com

   nvidia.com/mig-1g.10gb:     7   # 1 compute slice (~18 SMs) + 10GB
   nvidia.com/mig-2g.20gb:     3   # 2 compute slices (~36 SMs) + 20GB
   nvidia.com/mig-3g.40gb:     2   # 3 compute slices (~54 SMs) + 40GB
   nvidia.com/mig-4g.40gb:     1   # 4 compute slices (~72 SMs) + 40GB
   nvidia.com/mig-7g.80gb:     1   # 7 compute slices (132 SMs, full GPU) + 80GB
 # Pod requests MIG instance

apiVersion: v1 kind: Pod metadata: name: inference-pod spec: containers:

  • name: inference image: nvcr.io/nvidia/tritonserver:24.01-py3 resources: limits: nvidia.com/mig-1g.10gb: 1 # request 1 1g.10gb MIG instance

MIG配置管理：

 # configure via mig-manager
 # cluster admin declares MIG configuration
 # mig-config.yaml

apiVersion: v1 kind: ConfigMap metadata: name: default-mig-config namespace: gpu-operator data: config.yaml: | version: v1

     mig-configs:
       all-1g.10gb:
         - devices: all
           mig-enabled: true
           mig-devices:

"1g.10gb": 7

       all-3g.40gb:
         - devices: all
           mig-enabled: true
           mig-devices:

"3g.40gb": 2

14.4.3 GPU 共享机制比较

 # specify MIG configuration in node
 # kubectl label node gpu-
 # switching MIG configuration requires draining
 # kubectl drain gpu-node-01
 # kubectl label node gpu-
 # kubectl uncordon gpu-node-01

在K8s中实现GPU共享有四条技术路线，各有优劣，对比如表14-5所示。 表14-5 GPU共享机制对比 方案 隔离级别 显存隔离 故障隔离 性能开销 适用场景 MIG 硬件级 严格 强 几乎无 推理、中小规模训练 方案 隔离级别 显存隔离 故障隔离 性能开销 适用场景 vGPU (GRID) 虚拟化层 软件隔离 中 5-15% 虚拟桌面、轻量推理 MPS 用户态多路复用 无 弱 低 多进程共享GPU Time-slicing k8s调度层 无 无 低 开发测试、低利用率场景 时间切片（Time-slicing）的局限性： 时间切片是最容易实现的GPU共享方案（在Device Plugin层实现），但存在严重局限：

Time-slicing configuration example

version: v1 sharing: timeSlicing: resources: - name: nvidia.com/gpu replicas: 4 # virtualize each GPU into 4 replicas

14.4.4 GPU Operator 全栈管理

 # Problem: when 4 Pods share one GPU via time-slicing,
 # memory is not isolated. If Pod A loads a 10GB model
 # and exits, there is no automatic memory cleanup
 # mechanism for the freed GPU memory segments.

NVIDIA GPU Operator整合了GPU基础设施的全生命周期管理： ┌─────────────────────────────────────────────────────┐ │ GPU Operator (Helm Chart) │ ├─────────────────────────────────────────────────────┤ │ ┌───────────────────┐ ┌────────────────────────┐ │ │ │ GPU Driver │ │ Container Toolkit │ │ │ │ (DaemonSet) │ │ (containerd/docker │ │ │ │ ┌──────────────┐ │ │ hook injection) │ │ │ │ │ nvidia-driver│ │ └────────────────────────┘ │ │ │ │ DaemonSet │ │ ┌────────────────────────┐ │ │ │ └──────────────┘ │ │ Device Plugin │ │ │ └───────────────────┘ │ (GPU enumeration) │ │ │ ┌───────────────────┐ └────────────────────────┘ │ │ │ DCGM Exporter │ ┌────────────────────────┐ │ │ │ (GPU metrics) │ │ GPU Feature Discovery │ │ │ └───────────────────┘ │ (Node Labels) │ │ │ └────────────────────────┘ │ └─────────────────────────────────────────────────────┘ GPU Operator安装： helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update helm install gpu-operator nvidia/gpu-operator \

   --namespace gpu-operator --create-namespace \
   --set driver.enabled=true \
   --set driver.version=550.54.15 \
   --set toolkit.enabled=true \
   --set devicePlugin.enabled=true \
   --set dcgmExporter.enabled=true \
   --set migManager.enabled=true \
   --set gfd.enabled=true    # GPU Feature Discovery

GPU Feature Discovery（GFD）自动为节点打上 GPU 属性标签，供拓扑感知调度使用：

14.4.5 DRA 与拓扑感知调度

 nvidia.com/gpu.product=Tesla-H100-PCIe-80GB
 nvidia.com/gpu.count=8
 nvidia.com/gpu.memory=81920
 nvidia.com/gpu.compute.major=9
 nvidia.com/gpu.compute.minor=0
 nvidia.com/cuda.driver-version=550.54.15
 nvidia.com/gfd.timestamp=1710000000

Kubernetes 1.26引入的Dynamic Resource Allocation（DRA）为GPU调度提供了更灵活的模型：

DRA example (K8s 1.28+)

apiVersion: resource.k8s.io/v1alpha2 kind: ResourceClaimTemplate metadata: name: gpu-claim-template spec: spec: resourceClassName: nvidia-gpu.nvidia.com parametersRef: apiGroup: gpu.resource.nvidia.com kind: GpuClaimParameters name: h100-8gpu

Pod uses GPU via claim

apiVersion: v1 kind: Pod metadata: name: training-pod spec: containers:

  • name: trainer image: nvcr.io/nvidia/pytorch:24.01-py3 resources: claims:
    • name: gpus resourceClaims:
  • name: gpus source: resourceClaimTemplateName: gpu-claim-template Topology Manager 避免跨 NUMA 分配： DGX H100 节点内 GPU0-7 通过 NVSwitch 4.0 全互联（每对 GPU 900 GB/s 双向），不存在经由 PCIe Switch 或 UPI 的 GPU 间通信路径——这两个路径仅影响 CPU-GPU 或 CPU-CPU 通信。但对于非 NVSwitch 的 GPU 配置（如 A40/L40S PCIe 版本），GPU 间 P2P 确实受 PCIe 拓扑约束：同 PCIe Switch 下 P2P 约 32-64 GB/s（取决于 PCIe 代数），跨 NUMA 经 UPI 则降至 20-40 GB/s。Kubernetes 原生 Device Plugin 不感知 GPU 拓扑，默认调度可能为申请 2/4 块 GPU 的作业 分配跨 NUMA 的 GPU，导致 AllReduce 带宽大幅下降、训练吞吐损失 30-40%。 在 kubelet 中启用 Topology Manager 可避免该问题：

kubelet configuration

topologyManagerPolicy: single-numa-node topologyManagerScope: pod cpuManagerPolicy: static 配置 single-numa-node 策略后，kubelet 在同时分配 CPU 和 GPU 时会保证 Pod 的所有 GPU 位于同一 NUMA 节点， 对 4 GPU 训练作业可将 AllReduce 带宽从跨 NUMA 路径提升至 NVSwitch 路径。 关键 NCCL 环境变量： NCCL_SOCKET_IFNAME 限定跨节点通信网卡（避免误选管理网/存储网）； NCCL_IB_DISABLE=0 启用 InfiniBand/RoCEv2； NCCL_IB_GID_INDEX=3 使用 RoCEv2 GID； NCCL_IB_TC=106 使 DSCP 标记与交换机 QoS 队列对齐。在 Rail-Optimized 拓扑中 NCCL 会自动选择 Rail-AllReduce 算法，有效带宽可达理论线速的 85-90%。

14.4.6 kube-scheduler 框架

kube-scheduler 以 Pod 为单位执行调度周期（Scheduling Cycle）与绑定周期（Binding Cycle）两个阶段：先过滤 （Filtering，预选）再评分（Scoring，优选）。过滤阶段逐节点执行谓词检查（资源是否满足、节点选择器、污点容忍、 亲和性、端口冲突），若无节点通过则进入重试队列并触发抢占；评分阶段对候选节点打分排序，得分最高者胜出（同分 轮转）。两个周期由 Scheduling Framework 的扩展点解耦，各扩展点的时机与用途如表14-6所示。 表14-6 Scheduling Framework 扩展点 扩展点 周期 用途 PreFilter 调度 预处理并缓存调度数据（如资源需求汇总），快速否决 Filter 调度 逐节点过滤（预选），返回通过节点集 PostFilter 调度 Filter 无节点通过时运行（默认执行抢占） PreScore 调度 评分前的预计算（如数据对齐） Score 调度 为每个候选节点打分（优选） NormalizeScore 调度 归一化并加权合并各插件分数 Reserve 调度转绑定 在节点上预留资源（周期边界，失败则回滚） Permit 绑定 允许或拒绝或等待，可跨节点同步（Gang 等待常用） PreBind 绑定 绑定前处理（如 CNI 分配网络地址） Bind 绑定 将 Pod 绑定到选定节点 PostBind 绑定 绑定成功后的通知（如指标上报） 扩展点按调度框架的固定顺序执行，如图14-4所示。 PreFilter Filter PostFilter PreScore Score Reserve Permit PreBind Bind PostBind 图14-4 kube-scheduler 调度框架扩展点 优先级与抢占（Preemption）： PriorityClass 定义 Pod 的调度优先级，value 越大越优先（系统级可达 1e9）。当无节点通过过滤时，kube-scheduler 运行抢占算法选择牺牲者（victims）： •候选牺牲者的优先级必须低于被抢占 Pod。 •抢占算法优先选择能释放足够资源、且对既有工作负载破坏最小的节点与 Pod 组合，即 PBD（Preemption Based on Disruption）策略，尽量避开受 PDB（PodDisruptionBudget）保护的 Pod。 •抢占成功后，被抢占 Pod 的节点记录在 NominatedNodeName ，待牺牲者终止后抢占者绑定到该节点。 PBD 的核心权衡：用抢占换吞吐，但以牺牲低优先级作业的稳定性为代价，因此生产集群常将优先级与配额（Quota）结 合使用。 GPU 场景下原生 kube-scheduler 的不足： •无 Gang 调度：逐 Pod 调度，分布式训练作业可能部分调度成功部分 Pending，造成 GPU 空占。 •无拓扑感知：不感知 NUMA 与 NVLink 拓扑，可能为多卡作业分配跨 NUMA 的 GPU。 •无装箱优化：默认 LeastAllocated 分散放置，加剧碎片化，不为大作业预留整节点。 •无作业级排队与公平：批训练作业缺乏回填、预留、公平共享等机制。 调度器扩展方式（三种路线）： •Scheduler Extender：通过 HTTP 接口扩展过滤与评分，接入简单但单次调用开销大、扩展点有限，已渐被弃用。 •自定义调度器：fork kube-scheduler 并嵌入自定义插件（对应不同 schedulerName ），灵活但需维护整个调度器。 •Scheduling Framework 插件：官方推荐路线，以轻量插件挂载到扩展点。GPU 装箱即通过 NodeResourcesFit 插 件的 scoringStrategy 实现。

14.4.7 GPU 资源碎片化与装箱优化

碎片化的根源是 GPU 以整卡粒度分配，而节点容量固定。8 卡节点若先后被 3 卡、5 卡作业占用，空闲余量合计 8 卡却跑 不了任何新的 8 卡作业——剩余碎片无法组合利用。作业规模越多样、节点 GPU 数越少，碎片化越严重。

  1. 装箱策略 NodeResourcesFit 插件的 scoringStrategy 决定评分偏好：

scheduler config: pack jobs tightly onto few nodes

apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles:

  • schedulerName: default-scheduler plugins: score: enabled: - name: NodeResourcesFit

weight: 2 pluginConfig:

  • name: NodeResourcesFit args: scoringStrategy: type: MostAllocated # MostAllocated or LeastAllocated resources: - name: nvidia.com/gpu

weight: 3 •MostAllocated：优先放置到利用率高的节点，把小作业“压实”，保留整节点给大作业，减少碎片。 •LeastAllocated：优先放置到利用率低的节点，负载均衡、故障域分散，但会加剧 GPU 碎片。 GPU 批训练场景应选 MostAllocated：多卡作业（如 8 卡）需要整节点，密集装箱能显著提高大作业的可调度成功率； 对故障域敏感的在线推理才倾向 LeastAllocated。 2) 整卡分配策略 AI 训练推荐按整卡（card-level）分配而非按显存切分，原因有四： •训练显存需求大且动态：模型权重、梯度、优化器状态通常占满单卡显存，MIG 切分后装不下或严重限制 batch。 •P2P 依赖整卡：NCCL 的 NVLink P2P 在 MIG 实例之间不可用，跨实例通信回退到 PCIe，AllReduce 带宽大幅下降。 •共享导致性能抖动：MPS 或时间切片下计算资源争抢，训练吞吐不可预测，且无显存隔离。 因此生产环境对训练作业一律以 nvidia.com/gpu: 8 整卡请求，推理场景才按需选择 MIG 或共享。 3) 业界实践 •Volcano：提供 binpack 与 proportion 等 action 组合， binpack 按资源权重紧凑放置。 •Kueue：以 ClusterQueue 的 nominalQuota 配合 ResourceFlavor 按 GPU 型号划分队列，间接实现池化。 •Koordinator： DeviceShare 与装箱策略结合，支持 GPU 整卡优先、碎片补充的混合分配。 •节点池划分：按 GPU 型号与数量分池（如 h100-8、h100-4、a100-8），池内 GPU 同构，从源头上减少异构碎片，也 便于故障隔离与整池替换。 4) 碎片度量化指标 •可调度剩余 GPU 数：对申请 R 卡的作业，统计满足 free >= R 的节点上的空闲卡数之和（或可凑出的整 R 数），反 映“看得见用得上”的真实容量。 •装箱效率：定义为实际已分配 GPU 数占节点 GPU 总量的比例： allocated GPU slots Packing Efficiency = total GPU slots 装箱效率低于 50% 时，即使 GPU 满负荷，碎片化也已实质降低大作业的可调度能力，应触发节点池重排或回收策略。

14.4.8 GPU 故障与调度联动

GPU 硬件故障有四种典型形态，如表14-7所示。 表14-7 GPU 故障类型与检测 故障类型 表现 检测手段 Xid 错误 驱动上报错误码（如 Xid 13/31/43/45/79），应用崩溃或 CUDA 调用失败 dmesg、DCGM、Xid 监听 ECC 错误 单比特（DBE 可纠正，触发显存重映射）或双比特（UBE 不可纠正） DCGM ECC 计数器、nvidia-smi -q HBM 退化 可纠正错误累积导致显存容量与带宽退化，坏块被屏蔽 DCGM memory 计数器、老化分析 NVLink 降速 链路错误导致互联带宽下降，AllReduce 变慢 DCGM NVLink 计数器、NCCL 日志 故障发现链路： •DCGM（Data Center GPU Manager）：以 dcgm-exporter 输出 Xid 计数、ECC 计数器、温度、功耗、NVLink 计数器 等指标，是最主要的信号源。 •Node Problem Detector（NPD）：以自定义插件周期执行 nvidia-smi 探活，发现异常时写入 NodeCondition （如 GPUHealthy=False ），供调度器与运维消费。 •Xid 事件监听：守护进程解析内核日志与 DCGM 的 Xid 事件流，将致命 Xid 码映射为故障类型并打点。 NPD 的自定义插件配置示例如下：

use DCGM for GPU health

configure Node Problem Detector

apiVersion: v1 kind: ConfigMap metadata: name: gpu-health-check-config namespace: kube-system data: gpu-health-monitor.json: | { "plugin": "custom", "pluginConfig": { "invoke_interval": "1m", "timeout": "30s", "max_output_length": 80, "concurrency": 1 }, "source": "gpu-health-monitor", "metricsReporting": true, "conditions": [ { "type": "GPUHealthy", "reason": "GPUIsHealthy", "message": "All GPUs are healthy" } ], "rules": [ { "type": "permanent", "condition": "GPUHealthy", "reason": "GPUUnhealthy", "path": "/usr/bin/nvidia-smi", "args": ["--query-gpu=index,name", "--format=csv,noheader"], "timeout": "10s" } ] } 故障处理链路如图14-5所示：检测到故障后，节点先被标记（taint + label），再驱逐（evict）其上的 GPU 作业，作业重 调度并从 checkpoint 恢复；随后节点进入维修（更换 GPU 或下线），回归前跑诊断验证并解除 cordon。 Detect: DCGM / NPD / Xid Mark: taint + label Evict: drain GPU workload Reschedule: restart from c Repair: replace GPU or hos Regression: verify and unc s heckpoint t ordon 图14-5 GPU 故障处理链路 弹性训练与调度： 故障后的重调度策略取决于恢复成本： •从 checkpoint 恢复：调度器只重调度故障 Pod 所在节点上的副本，其余 worker 保持存活，训练从最近 checkpoint 继续。丢失的算力约等于一个 checkpoint 周期（分钟级），是训练作业的默认策略。 •整体重启：仅当 checkpoint 不可用或故障范围过大（如整 rack 断电）时才回退，成本为数小时。 •实现上由 TorchElastic 与 NVIDIA Fault Tolerance 维护 rendezvous 与成员变更，调度器配合：故障节点置为 taint， 仅重调度其承载的 worker，避免整个作业回退到排队。 业界实践： GPU 年化故障率（AFFR）通常在 1% 到 5% 区间，万卡集群每日发生数次故障；运维侧将故障率与 MTTR 作为调度层 SLA 的核心指标，并据此设计冗余与快速替换流程。

14.4.9 异构算力池化与统一调度

云场景的算力底座常混布 NVIDIA、AMD、昇腾、寒武纪等异构芯片。异构算力池化的目标是「上层无感、统一调度、按 需匹配」——训练/推理框架按资源需求声明，调度层在异构算力池中匹配最合适的芯片类型。

  1. 异构算力抽象 异构芯片在 K8s 中的统一抽象，是把「芯片差异」收敛到设备插件与调度标签两层： •设备插件抽象：各芯片通过独立 Device Plugin 暴露资源（ nvidia.com/gpu 、 amd.com/gpu 、 ascend.com/npu 、 cambricon.com/mlu ），Pod 声明资源即可，无需感知底层芯片。 •CDI 统一注入：用 CDI（Container Device Interface）统一设备注入，消除各芯片 Runtime 差异（NVIDIA Container Toolkit、CANN Runtime 各自注入方式不同，CDI 收敛为统一规范）。 •调度标签：节点打芯片类型/型号标签（ accelerator=vendor:model ），调度器按标签匹配；能力标签（FP8 支持、 显存大小）供更细粒度匹配。
  2. 算力池化与切分 异构算力池把物理芯片抽象为可切分的算力资源： •物理卡池：整卡粒度池化（最简单，训练场景主流），调度器按卡数分配。 •切分池：MIG/vGPU 粒度切分（推理场景），单卡切分为多个算力分片，按分片售卖；异构芯片切分能力不同（NVIDIA MIG、昇腾多实例、寒武纪 vMLU），池化层需屏蔽差异。 •超卖池：对可容错的推理负载超卖（多个请求共享卡，利用率优先），对训练负载不超卖（保证性能确定性）。
  3. 多芯片调度策略 异构算力池中同一任务可能匹配多种芯片，调度策略按目标选择： •性能优先：任务声明模型与精度，调度器预估各芯片 MFU/吞吐（基于芯片评测基线），选性能最优芯片。 •成本优先：按卡时成本选性价比（结合芯片价格与利用率，衔接 TCO 模型）。 •亲和性：大模型训练绑定同一芯片型号（避免异构混部导致通信不匹配），推理可异构混部（负载独立）。 •故障隔离：单芯片型号故障只影响该型号节点，调度器将任务迁移到同型号健康节点，不跨型号（避免行为差异）。
  4. 池化层的工程要点 •配额按「算力类型 + 卡数」维度管理（租户可申请「10 卡 NVIDIA + 5 卡昇腾」），而非单一 GPU 配额。 •异构池利用率分开统计，避免「总量达标但单型号爆满」的假象。 •芯片评测基线（异构芯片的实测 MFU/吞吐数据）作为调度匹配的数据基础，未经评测的芯片型号不纳入自动匹配。

14.4.10 调度效果验证

集群管理平台把设备插件、调度框架、异构池化等单点能力放大为企业级算力服务。本节覆盖集群全生命周期、多集群、 节点、控制面治理与调度效果验证，聚焦工程落地，不重复前述调度机制本身。

  1. 集群生命周期管理 集群创建到回收的完整生命周期，由 Operator/Controller/CRD 与声明式 API 自动化驱动： •集群创建：以声明式资源描述集群目标状态（K8s 版本、节点池规格、网络插件、GPU 驱动版本），控制器据此拉起控 制面与节点池。生产常用 Cluster API（CAPI）管理集群模板、Terraform 管底层云资源、kubeadm 收敛控制面初始 化；GPU 节点创建即预置驱动、容器运行时与设备插件，避免上线后补装。 •配置与升级：集群配置以版本化 CRD 保存，变更先评审再下发；升级按「控制面先行、节点池分批」推进，节点分批 cordon/drain，升级前做 API 兼容性审计拦截废弃调用，失败自动回滚。 •扩缩容：以节点池为单位伸缩，集群 autoscaler 依据 pending Pod 与排队作业触发扩容；缩容前确认节点无 GPU 作 业且无 PDB 保护缺口，避免中断长训练。 •巡检与回收：定期巡检证书过期、etcd 快照、磁盘水位与镜像仓库连通性；闲置或过期的节点池进入回收流程，先迁 移数据后释放资源。 集群生命周期各环节构成闭环，如图14-6所示。 配置与升级 扩缩容 集群创建 巡检与回收 图14-6 集群生命周期管理闭环
  2. 多集群管理 多地域多集群是容灾与资源弹性的基础： •统一管理：采用 Hub/Spoke 模式，管理集群持有成员集群的只读视图，统一下发配置与策略；成员集群保留本地自 治，管理面故障不影响在跑作业。 •资源互调：跨集群调度把本地排队作业调度到其他地域空闲集群，前置条件为网络互通（专线/VPN）与身份打通；策 略上本地优先、异地兜底。 •版本治理：多集群维持统一版本基线，配置经 GitOps 统一下发，定期巡检校验漂移（节点标签、配额、策略差异）。
  3. 节点管理 •节点接入：GPU 节点上线前校验驱动版本、固件、IB/RoCE 网卡与拓扑亲和性，通过后置为可调度；接入流程沉淀为 自动化脚本，避免手工遗漏。 •状态管理：持续观测节点健康，NotReady 节点自动标记并告警，长期异常节点移出调度池。 •故障定界：与机器、网络底座协作定界问题归属，GPU 层（DCGM/Xid）、网络层（IB 端口降速、丢包率）、存储层 （慢盘、IO 卡顿）。定界链路为 kubelet 上报、带外（BMC/IPMI）复核、隔离节点、维修、回归验证后恢复调度。
  4. 控制面治理 控制面稳定性决定集群规模边界，各组件治理要点如表14-8所示。 表14-8 控制面组件治理要点 组件 典型风险 治理手段 关键指标 kube-apiserver 限流与请求风暴 APF 分级限流、审计裁剪 API 拒绝率、P99 请求时延 etcd 容量与性能劣化 快照与 defrag、租约治理 db 大小、磁盘 IOPS、fsync 时延 kube-scheduler 大规模集群调度变慢 压测评估、高可用部署 调度时延 P95、调度成功率 controller-manager 控制器风暴 并发与重试退避调优 队列深度、控制器失败率 kubelet 节点资源压力 镜像回收、PLEG 监控 NotReady 次数、容器重启次数 etcd 磁盘是控制面第一瓶颈：db 超过数 GB 后读写延迟显著上升，须及时 defrag 并评估瘦身（清理废弃事件与冗余 CR）。apiserver 侧常见问题是客户端全量 watch 与高频 list 造成的 watch 风暴，治理上引导客户端走 informer 缓存、 限制单客户端并发，必要时按 PriorityLevel 限流。
  5. 调度效果验证体系 调度策略上线前须量化验证，手段与指标如下： •调度仿真：离线重放真实历史负载，评估新策略的排队与分配结果，不扰动生产，适合验证优先级、装箱算法等策略级 改动。 •回放：按时间片回放线上作业流，对比新旧策略的调度结果与资源利用差异，输出量化对比报告。 •压测：构造大规模负载（万级节点、十万级作业）压测调度器吞吐与决策时延，定位调度链路瓶颈。 验证指标与生产目标如表14-9所示。 表14-9 调度效果验证指标 指标 目标 说明 排队时长 P95 < 30 分钟 作业提交到分配的时间 调度成功率 > 99% 可调度作业最终绑定节点 资源利用率 平均 > 65% 集群 GPU 综合利用率 业务 SLO 训练完成时延达标 训练完成时间符合预期

14.5 K8s 批调度与 Gang

Kubernetes的默认调度器采用Pod-Level调度模型——逐个调度Pod，不考虑Pod之间的依赖关系。在AI训练场景中，一 个分布式训练作业需要N个Worker Pod同时启动并建立通信组（例如torchrun需要所有rank就绪后才能开始初始化NCCL 进程组）。如果调度器逐个分配Pod，可能出现“部分Pod调度成功、部分Pod因资源不足Pending”的僵局——即经典的 Gang Scheduling问题。

14.5.1 Gang Scheduling 概念

Gang Scheduling（群组调度）要求一个作业的所有Pod要么全部同时调度成功，要么全部等待。这保证了分布式训练作 业的原子性： Traditional K8s scheduling (without Gang Scheduling): Timeline: ────────────────────────────────────▶ Pod A: [Running──────────────────────────] Pod B: [Pending──────────][Running─────────] ◀ Pod B starts late Pod C: [Running──────────────────────────] ▶ Result: Pod A and C wait for B, GPU resources wasted Gang Scheduling: Timeline: ────────────────────────────────────▶ Pod A: [Pending──────────][All Running────────] Pod B: [Pending──────────][All Running────────] Pod C: [Pending──────────][All Running────────] ▶ Result: all start together after ready, optimal resource efficiency Gang Scheduling的核心概念是“All-or-Nothing”——在资源不足时，已分配的资源会被回收，等待下次足够时再统一 分配。

14.5.2 Volcano 调度器

Volcano是云原生计算基金会（CNCF）的毕业项目（2022 年进入孵化，2024 年毕业），专为高性能计算和AI工作负载设 计。它通过CRD扩展了Kubernetes的调度能力。

  1. 核心 CRD 与作业模型 Volcano 以 Queue、PodGroup、Job 三类 CRD 描述资源队列、作业组与作业本身：

Queue: resource queue

apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: ai-training spec: reclaimable: true # allow reclaiming idle resources weight: 3 # queue priority weight capability: cpu: "4000" memory: "16000Gi"

     nvidia.com/gpu: "800"
 ---
 # PodGroup: defines the Pod group for Gang Scheduling

apiVersion: scheduling.volcano.sh/v1beta1 kind: PodGroup metadata: name: llama2-training-pg spec: minMember: 64 # minimum 64 Pods ready simultaneously (8 nodes x 8 GPUs) minResources: # minimum resource requirement nvidia.com/gpu: "512" # 64 Pods × 8 GPUs queue: ai-training

priorityClassName: high-priority

Job: training job definition

apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: llama2-70b-training spec: minAvailable: 64 schedulerName: volcano queue: ai-training priorityClassName: high-priority tasks:

  • replicas: 64 name: worker template: spec: containers: - name: pytorch

image: nvcr.io/nvidia/pytorch:24.01-py3 resources: limits: nvidia.com/gpu: 8 command:

           - torchrun
           - --nnodes=64
           - --nproc_per_node=8
           - train.py

restartPolicy: OnFailure plugins: env: [] # environment variable passing svc: [] # auto-create Service 作业管理通过 kubectl 扩展命令完成：

view queue status

kubectl get queue -o wide

view job status

kubectl get vcjob llama2-70b-training -o yaml

suspend job

kubectl suspend vcjob llama2-70b-training

resume job

kubectl resume vcjob llama2-70b-training

 # elastic job configuration
 # set in Job spec:
 # minAvailable: 48    # minimum 48 Pods
 # tasks[0].replicas: 64   #
  1. 架构与调度周期 Volcano 完整形态由 vc-controller-manager（管理 CRD 与作业生命周期）、vc-scheduler（核心调度器）与 vc- webhook-manager（准入与资源变更）三部分组成，其中调度内核围绕 Cache、Session、Actions、Plugins 四个抽象 展开。 Cache 监听 apiserver 中 Pod、Node、PodGroup、Queue 等资源事件，维护集群状态的完整内存视图；Session 是每 个调度周期的工作单元，OpenSession 时对 Cache 做只读快照生成调度视图，CloseSession 时把本周期决策统一写回。 调度过程由一串 Action 顺序执行，每个 Action 调用一组 Plugin 获取决策依据，Action 决定做什么（流程），Plugin 决 定怎么做（策略）。 一个调度周期严格按 OpenSession → Enqueue → Allocate → Backfill → Preempt → Reclaim → CloseSession 顺序执 行，如图14-7所示。 OpenSession Enqueue Allocate Backfill Preempt Reclaim CloseSession 图14-7 Volcano 调度 Session 生命周期 各 Action 的职责： •OpenSession：对 Cache 做快照，生成调度域与待调度作业集合，重置会话级状态。 •Enqueue：入队检查，校验作业所属 Queue 的配额与状态，把满足条件的 PodGroup 放入本周期可调度集合。 •Allocate：主分配流程，按排序策略逐作业为 Pod 找节点；对 Gang 作业先预占资源，minMember 全部满足后统一 Bind。 •Backfill：回填，Allocate 后仍有空闲资源时，用低优先级小规格作业填充，提升利用率。 •Preempt：抢占，高优先级作业资源不足时驱逐低优先级作业释放资源。 •Reclaim：回收，某队列超额占用而其他队列配额不足时，回收超额部分的已分配资源（依赖 reclaimable: true ）。 •CloseSession：把本周期全部决策持久化回 apiserver 并关闭会话。 Action 与 Plugin 的常用组合见表14-10。 表14-10 Volcano 常用 Action 与 Plugin Action 职责 常用 Plugin Enqueue 队列配额入队检查 proportion、priority Allocate 主分配与 Gang 预占 gang、priority、drf、proportion、binpack、predicates、nodeorder Backfill 空闲资源回填 binpack、priority Preempt 抢占低优先级作业 priority、gang Reclaim 超额资源回收 proportion、priority
  2. Plugin 机制 •gang：校验 PodGroup 是否满足 minMember，Allocate 时全部成员可调度才提交 Bind，是 All-or-Nothing 的落地 点。 •priority：作业与队列优先级排序，决定 Preempt 时的抢占次序。 •drf：主导资源公平（Dominant Resource Fairness），按作业主导资源比例公平分配，适合 GPU 多维异构资源。 •proportion：按 Queue 权重比例分配资源，见下文。 •binpack：装箱打分，提高节点资源利用率。 •predicates：节点过滤，复用 kube-scheduler 谓词（端口冲突、污点容忍等）。 •nodeorder：节点打分排序。
  3. Gang 调度实现细节 •minMember 语义： PodGroup.spec.minMember 定义作业满员阈值，达到阈值才允许调度；Job 的 minAvailable 与任务副本数共同推导该值。 •资源预占与回滚：Allocate 阶段先在内存 Cache 中为每个 Pod 虚拟占位（Reservation），全部 Pod 都能找到节点则一 次性 Bind；任一 Pod 不满足则整体回滚预占，作业保持 Pending 等待下一 Session 重试。预占资源立即释放，不会形 成半调度僵局。 •超时与降级：PodGroup 支持 scheduleTimeout （默认 7200 秒），超时仍未凑齐 minMember 时作业被标记为 Failed 并告警，避免无限排队。用户可结合弹性作业机制调低 minAvailable ，让作业在部分资源就绪时降级启动。
  4. Proportion 队列比例调度 Queue 的 weight 字段决定队列间资源配比。proportion 插件按比例分配：队列 qi 权重 wi 的可分配比例为 wi / Σwj， 集群资源不足时按该比例收敛分配。Queue 的 capability 是硬性上限， weight 是软性份额，二者结合实现保底加弹 性的配额语义； reclaimable: true 的队列超份额占用可被 Reclaim 回收。
  5. 多调度器共存 Volcano Scheduler 以独立 Deployment 运行，与默认 kube-scheduler 不是互斥替换，而是按 Pod 的 spec.schedulerName 分流的叠加关系。声明 schedulerName: volcano 的 Pod 由 Volcano 调度，未声明的仍由默认 调度器接管：

Pod-level scheduler selection

apiVersion: v1 kind: Pod metadata: name: volcano-managed-pod spec: schedulerName: volcano # this Pod is scheduled by Volcano containers:

  • name: main image: busybox command: ["sh", "-c", "sleep 3600"] 调度器对 Pod 的所有权只由 spec.schedulerName 决定，因此同一集群可并行运行多个调度器，各自独立选主、互不干 扰。Pod 级 schedulerName 分流让 Volcano、默认调度器乃至 Kueue 类准入方案按负载类型各司其职。

14.5.3 Kueue 资源管理和队列

Kueue是Kubernetes SIG-Scheduling推出的资源管理和多租户排队框架，提供了原生的批次调度能力。 Kueue核心概念：

ResourceFlavor: defines resource variant (e.g., GPU model, node pool)

apiVersion: kueue.x-k8s.io/v1beta1 kind: ResourceFlavor metadata: name: h100-gpu spec: nodeLabels: nvidia.com/gpu.product: NVIDIA-H100-80GB-HBM3

apiVersion: kueue.x-k8s.io/v1beta1 kind: ResourceFlavor metadata: name: a100-gpu spec: nodeLabels:

     nvidia.com/gpu.product: NVIDIA-A100-SXM4-80GB
 ---
 # ClusterQueue: cluster-level queue

apiVersion: kueue.x-k8s.io/v1beta1 kind: ClusterQueue metadata: name: cluster-queue-total spec: namespaceSelector: {} # match all namespaces resourceGroups:

  • coveredResources: ["cpu", "memory", "nvidia.com/gpu"] flavors:
    • name: h100-gpu resources:
      • name: "cpu" nominalQuota: 16000
      • name: "nvidia.com/gpu" nominalQuota: 800 borrowingLimit: 200 # allowed borrowing limit
    • name: a100-gpu resources:
      • name: "nvidia.com/gpu" nominalQuota: 200

LocalQueue: namespace-level

apiVersion: kueue.x-k8s.io/v1beta1 kind: LocalQueue metadata: namespace: team-nlp name: nlp-training-queue spec: clusterQueue: cluster-queue-total

Workload: basic unit managed

apiVersion: kueue.x-k8s.io/v1beta1 kind: Workload metadata: name: llama2-train namespace: team-nlp spec: queueName: nlp-training-queue podSets:

  • name: worker count: 64 template: spec: containers: - name: pytorch

resources: limits: nvidia.com/gpu: 8 Volcano 与 Kueue 的能力对比如表14-11所示。 表14-11 Volcano 与 Kueue 对比 特性 Volcano Kueue Gang Scheduling 原生支持（PodGroup） 原生支持（Admission Check） 资源队列 Queue CRD ClusterQueue + LocalQueue 优先级抢占 支持 支持 公平调度 权重 + DRF Cohort + Fair Sharing 弹性作业 支持 支持（Partial Admission） K8s原生集成 替换默认调度器 基于Admission Webhook 社区成熟度 更成熟 快速发展中

14.5.4 SLURM 与 K8s 对比

对于不同类型AI工作负载的调度效率对比（基于Meta和Bytedance的实验数据），如表14-12所示。 表14-12 SLURM 与 K8s 批调度方案对比 指标 SLURM K8s+Volcano K8s+Kueue 100节点作业调度延迟 约2秒 约5秒 约3秒 Gang Scheduling保证 原生 支持 支持 容器化支持 enroot/pyxis 原生 原生 弹性训练支持 有限 完整 支持 多租户隔离 QoS+PAM Namespace+Quota Cohort+LocalQueue 作业依赖DAG 支持 原生支持 简洁 学习曲线 陡峭 中等 较低

14.5.5 批调度器对比与选型

生产环境的批调度器不止 Volcano 一种。选型需综合评估 Gang 支持、公平算法、拓扑感知、弹性、混部、云生态与生产 案例，六个主流方案的横向对比如表14-13所示。 表14-13 主流批调度器生产对比 维度 Volcano Kueue KAI Koordinator YuniKorn Armada Scheduler 归属 CNCF 毕业项目 K8s SIG 官方 CNCF 项目（字节跳 阿里云 ACK Apache 顶级 CNCF（G- 动） Research） Gang 调 PodGroup 原生 Admission AppWrappe Coscheduling CRD Application 原 原生 度 Check r 生 公平算法 DRF + proportion Cohort Fair Sharing 配额 + 优先级 ElasticQuot a DRF（YARN 传 队列权重 承） 拓扑感知 topology 插件 无内置 强（NRI + NUMA） 支持 弱 弱 弹性作业 支持 Partial 有限 支持 支持 有限 Admission 在线混部 弱 弱 强（QoS 五级） 中 弱 弱 云生态 训练算子齐备 SIG 推荐 NRI 设备生态 ACK 深度集 大数据生态 低延迟金融 成 生产案例 华为云、腾讯、 百度 各云厂商托管服 字节跳动、小红书 阿里云 ACK 务 Cloudera、腾讯 G-Research Koordinator 深入：Koordinator 的核心不是 Gang 调度，而是面向混部的完整 QoS 体系。它定义五级 Pod QoS，比 Kubernetes 原生三级粒度更细，如表14-14所示。 表14-14 Koordinator QoS 分级 QoS 全称 定位 混部能力 SYSTEM System 系统组件（kubelet、CNI） 最高优先级，不可驱逐 LSE Latency Sensitive Exclusive 独占资源在线服务 独占核，不被抢占 LSR Latency Sensitive Reserved 预留资源在线服务 预留核，可用 CPU Burst LS Latency Sensitive 普通在线服务 可用 CPU Burst 借算力 BE Best Effort 离线训练与批任务 空闲算力，可被驱逐 •CPU Burst：LS/LSR 在线服务 CPU 配额用尽但节点有空闲时，通过 cgroup CFS 带宽借用空闲算力，缓解在线延迟尖 刺，同时不破坏离线作业隔离。Koordinator 经 NRI（Node Resource Interface）与内核 cgroup 协同实现毫秒级弹 性。 •内存驱逐优先级：节点内存压力时按 QoS 从低到高选择驱逐目标——先驱逐 BE 离线作业，再考虑对 LS 做 CPU Throttle，尽量不触碰 LSR/LSE；驱逐顺序与 OOM Killer 优先级同步，保障在线 SLA。 •GPU 拓扑感知调度：以 NUMA 节点、PCIe Switch 域、NVLink/NVSwitch 域为单位进行 GPU 亲和性调度，确保同一 Gang 内的 GPU 优先通过 NVSwitch（900 GB/s）通信而非跨 NUMA 的 PCIe 路径，对小规模训练作业的 AllReduce 带 宽提升尤为明显。 •资源预留：允许为即将到来的大规模训练作业提前锁定节点而无需运行实际 Pod，缓解 Gang 调度因集群碎片化长时间 无法凑齐资源的排队问题。 •节点资源超卖：基于实际利用率动态计算可超卖容量，在不影响 Guaranteed 作业 SLA 的前提下注入 Best-Effort 作 业，是提升 GPU 利用率的核心机制。 •GPU 共享：经 Device CRD 与 NRI 管理 GPU 显存切分，支持单卡多作业共享，结合拓扑感知将共享组固定在 NVLink 域内。 •为何成为混部首选：混部核心矛盾是在线延迟与离线吞吐的平衡。五级 QoS 把在线隔离（独占核 + CPU Burst）与离 线弹性（超卖 + 优先驱逐）统一到一套机制，配合资源预留解决大作业排队，因此成为字节跳动等大规模混部场景首 选。 KAI Scheduler：阿里云容器服务 ACK 的批调度器（开源项目 KAI Scheduler），面向大规模 AI 与大数据作业。它提供两 个核心 CRD：AppWrapper 负责作业定义（Gang、优先级、Preemption），ElasticQuota 负责弹性配额（支持借还与抢 占）。它同样以独立调度器方式通过 schedulerName 接管作业 Pod，ElasticQuota 的配额借贷机制是其云上多租户场景 的核心优势，典型用于 ACK 上的推荐系统与大模型训练治理。 选型决策树： •纯批训练、作业规模固定：首选 Volcano，Gang 原生、生态成熟、与 PyTorch/TF 算子衔接顺畅。 •在线与离线混部、追求整体利用率：首选 Koordinator，五级 QoS + CPU Burst + 超卖。 •多集群统一配额、云厂商托管场景：首选 Kueue，ClusterQueue + Cohort 跨集群公平共享，SIG 官方推荐。 •大数据与 AI 混合负载、YARN 生态迁移：YuniKorn，继承 DRF 公平模型，与 Spark/Flink on K8s 集成成熟。 •阿里云 ACK 场景：KAI Scheduler，与 ACK 控制台及弹性配额原生集成。 工程要点 •Gang 调度的本质是 All-or-Nothing：Volcano 用 PodGroup 的 minMember 实现原子调度，预占不满足即回滚，杜 绝半调度僵局。 •Session 是一次调度回合：OpenSession → Enqueue → Allocate → Backfill → Preempt → Reclaim → CloseSession，Action 定流程、Plugin 定策略。 •混部首选 Koordinator 的原因：SYSTEM/LSE/LSR/LS/BE 五级 QoS，配合 CPU Burst、内存驱逐优先级与 GPU 共 享，在在线延迟与离线吞吐间取得平衡。 •schedulerName 决定调度器归属：Pod 声明 schedulerName: volcano 才进入 Volcano 调度域，多调度器可在同 一集群共存分流。

14.5.6 弹性算力调度算法

云场景算力按需伸缩，弹性调度算法决定「何时扩、扩多少、何时缩、先回收谁」。弹性调度与静态批调度的差异在于： 节点数量动态变化，且存在扩缩延迟（新节点上线需数分钟），算法须在预测与响应之间权衡。

  1. 节点池伸缩 K8s 集群的弹性通过节点池实现： •ClusterAutoscaler：监控 pending Pod，节点不足时扩容，Pod 空闲时缩容。对 GPU 集群需扩展（原生不感知 GPU 请求的异构性），且缩容要避免驱逐运行中任务。 •Karpenter：按 Pod 需求直接调度到云实例（跳过节点池中间态），创建延迟更低，按实例类型匹配 GPU（如按 8×H100 实例粒度分配）。Karpenter 更契合 GPU 集群的「整卡实例」需求。 •扩缩延迟：GPU 实例创建需数分钟（镜像拉取 + 驱动初始化），算法须提前扩容（预测性）而非请求到来才扩。
  2. 训练/推理弹性差异 训练与推理的弹性特征不同，调度算法需分别适配，对比如表14-15所示。 表14-15 训练与推理弹性差异 维度 训练作业 推理服务 弹性粒度 整作业（gang） 副本级（HPA） 伸缩驱动 排队作业数 请求 QPS/延迟 扩缩延迟容忍 高（排队等节点） 低（不能等节点） 缩容代价 检查点 + 恢复 连接排空 + 优雅退出 资源确定性 要求确定性（不可超卖） 可超卖（容错重试） 训练作业弹性：按排队长度扩容（新作业触发扩容），缩容前先 drain 并等检查点完成；推理服务弹性：按 QPS/延迟指标 扩缩副本（HPA），GPU 服务扩容受限于整卡粒度（一个副本占整卡，扩一个实例 = 加一张卡）。
  3. 潮汐调度 云平台通常白天推理高峰、夜间训练高峰（或反之）。潮汐调度在两类负载间复用算力： •错峰复用：把推理服务与训练作业按时间窗口分配算力（白天推理保 QoS，夜间训练用满算力），减少总卡数需求。 •优先级反转：训练作业低优先但可中断（可检查点），推理高优先不可中断；推理高峰时回收训练算力，低谷时训练补 满。 •预测性分配：基于历史负载曲线预测高峰时段，提前扩容/预留，避免高峰排队或低谷浪费。
  4. 回收策略 弹性场景的算力回收顺序决定稳定性：
  1. 超卖/空闲：先回收超卖与低利用率算力。
  2. 可中断任务：Spot/抢占式训练（可检查点恢复）优先回收。
  3. 低优先级推理：批量推理降级（多级 QoS 中的低优先级负载优先降级），最后才动在线推理。
  1. 弹性预算与配额 弹性不等于无限：集群设算力预算上限（成本约束），租户配额在预算内弹性；弹性扩缩触发阈值与冷却时间需调参（扩 太快浪费成本，缩太慢浪费算力）。弹性调度与计费联动（弹性算力按实际用量计费），扩缩策略是成本控制的直接杠杆。

14.6 多租户 GPU 集群与 QoS

随着AI Infra从小团队专用走向企业级共享平台，多租户（Multi-Tenancy）成为GPU集群管理的核心挑战。一个2000 GPU的集群需要同时服务自然语言处理（NLP）、计算机视觉（CV）、推荐系统（RecSys）、模型推理等多个团队的工作负 载，每个团队对GPU资源的需求特征、优先级和SLA要求各不相同。本节系统阐述多租户GPU集群的资源隔离、QoS分级 和公平调度机制。

14.6.1 多租户模型

命名空间级隔离： 在Kubernetes生态中，多租户的最基本实现是命名空间（Namespace）+ 资源配额（ResourceQuota）： apiVersion: v1 kind: ResourceQuota metadata: name: team-nlp-quota namespace: team-nlp spec: hard:

     requests.nvidia.com/gpu: "128"
     limits.nvidia.com/gpu: "128"
     requests.cpu: "4096"
     requests.memory: "64Ti"

persistentvolumeclaims: "20" services.loadbalancers: "2" 配额模型： 软配额与硬配额的差异对比如表14-16所示。 表14-16 软配额与硬配额对比 维度 软配额（Soft Quota） 硬配额（Hard Quota） 实现 ResourceQuota + Borrowing ResourceQuota（严格上限） 弹性 允许借用空闲资源 不允许超用 适用 训练作业（弹性容忍高） 推理服务（SLA严格） 回收策略 非抢占或延迟抢占 不回收 优先级模型： apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: ai-production value: 1000000 globalDefault: false

description: "Production AI training jobs"

apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: ai-research value: 100000 globalDefault: false description: "Research experiments"

apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: ai-best-effort value: 1000 globalDefault: false description: "Best-effort spot training" preemptionPolicy: PreemptLowerPriority

14.6.2 资源隔离机制

GPU资源隔离的四层技术栈： ┌─────────────────────────────────────────────────┐ │ Layer 4: MIG hardware isolation │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │MIG 1 │ │MIG 2 │ │MIG 3 │ │MIG 4 │ │ │ │10G/1c│ │20G/2c│ │20G/2c│ │30G/3c│ │ │ └──────┘ └──────┘ └──────┘ └──────┘ │ ├─────────────────────────────────────────────────┤ │ Layer 3: MPS process-level sharing │ │ ┌────────────────────────────────────────────┐ │ │ │ MPS Server -> Multi-Client │ │ │ │ (no memory isolation, ECC err propagation)│ │ │ └────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────┤ │ Layer 2: Time slicing │ │ ┌───────┬───────┬───────┬───────┐ │ │ │ Slot1 │ Slot2 │ Slot3 │ Slot4 │ │ │ └───────┴───────┴───────┴───────┘ │ │ (no memory isolation, no fault isolation) │ ├─────────────────────────────────────────────────┤ │ Layer 1: cgroup limits │ │ ┌────────────────────────────────────────────┐ │ │ │ device cgroup + memory/CPU cgroup │ │ │ │ (device access only, no GPU usage ctrl) │ │ │ └────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────┘ MIG硬件隔离策略配置：

 # view current MIG configuration
 nvidia-smi mig -lgip
 # enable MIG

sudo nvidia-smi -mig 1

 # or configure via GPU Operator ConfigMap
 # create MIG instances
 nvidia-smi mig -cgi 9,14,14,19 -C "Enable default MIG config (profile-driven)"
 # Profile 9: 1g.10gb - 1
 # Profile 14: 2g.20gb - 2
 # Profile 19: 3g.40gb - 3

H100 MIG配置示例：

14.6.3 QoS 分级与保障

 # MIG configuration for multi-tenant inference
 # Split 8 H100 GPUs into:
 # - 4 GPUs: 7x1g.10gb profile each (28 instances total)
 # - 2 GPUs: 3x2g.20gb profile each (6 instances total)
 # - 2 GPUs: 2x3g.40gb profile each (4 instances total)
 # Total: 38 MIG instances across 8 GPUs
 # actual allocation:
 # GPU 0-3: 7x1g.10gb
 # GPU 4-5: 3x2g.20gb
 # GPU 6-7: 2x3g.40gb

GPU集群的QoS分级借鉴了网络QoS的思想，但加入了AI特有的维度：

 # Tier 1: Guaranteed
 # Resources: physically/temporally exclusive
 # Preemption: not preemptible
 # Use case: critical inference
 # Feature: MIG physical isolation

apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: guaranteed-gpu spec: reclaimable: false # resources cannot be reclaimed weight: 100 capability:

     nvidia.com/gpu: "256"
 # Tier 2: Burstable
 # Resources: baseline guarantee + borrowable
 # Use case: regular training

apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: burstable-gpu spec: reclaimable: true weight: 50 capability:

     nvidia.com/gpu: "512"
 # Tier 3: Best-Effort
 # Resources: no guarantee
 # Use case: experiments

apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: best-effort-gpu spec: reclaimable: true weight: 10 capability: nvidia.com/gpu: "256" QoS 三级模型覆盖 Guaranteed、Burstable、Best-Effort 三类队列：Guaranteed 资源物理独占、不可抢占，承载关键 推理；Burstable 提供基线保障加可借用，承载常规训练；Best-Effort 仅用空闲资源，随时可被回收，承载实验作业。

14.6.4 公平调度算法

公平调度算法解决的是多租户环境下「资源如何分」的问题。DRF（Dominant Resource Fairness）是多资源环境下的 公平调度算法，解决了传统 Max-Min Fairness 在多维资源下的公平性缺陷。

  1. 从 Max-Min 到 DRF Max-Min Fairness（最大最小公平）源自网络带宽分配，目标是让份额最小的用户先获得资源，直到与其后一位用户齐 平，再处理下一层，即递归地照顾最饥饿者。其单资源分配可表述为：在资源总量 C 下，分配向量 x 满足 ∑ x ≤ C ，且 不存在用户 i 可以在不减少他人份额的前提下提高自身份额。最大最小公平在多资源场景失效：异构任务对 GPU 与 CPU i i 的配比不同，按任务数平分反而让大需求租户吃亏，且无法表达谁的主资源是瓶颈。DRF 正是针对这一缺陷的多资源推 广。
  2. 主导资源与分配原则 每个租户根据其「主导资源」（占用比例最高的资源）获得公平份额。设租户 i 当前获得资源 j 的量 c ，资源 j 总量 R ， 则该租户对资源 j 的份额为 u = c /R ，主导资源份额定义为： ij j ij ij j cij di = max uij = max

j j Rj DRF 在容量约束下最大化所有租户中最小的主导份额： max min di s.t. ∑ cij ≤ Rj , ∀j c i i 等价地，每轮将下一份资源分配给主导份额最小的租户（Ghodsi et al., NSDI 2011）： Tenant A: each job needs 2 GPU + 8 CPU + 64GB RAM -> dominant resource: GPU (2/1024) Tenant B: each job needs 1 GPU + 32 CPU + 256GB RAM -> dominant resource: CPU (32/4096) DRF ensures: A's allocated dominant share ~ B's allocated dominant share i.e.: A's GPU share ~ B's CPU share 3) DRF 分配演算 集群总资源 9 GPU、18 CPU，租户 A 每个任务需 1 GPU + 4 CPU（主导资源为 CPU），租户 B 每个任务需 3 GPU + 1 CPU （主导资源为 GPU）。逐轮把资源分配给主导份额较小者，演算过程见表14-17。 表14-17 DRF 分配演算 轮次 分配租户 dA dB A 任务数 B 任务数 1 A 0.22 0.00 1 0 2 B 0.22 0.33 1 1 3 A 0.44 0.33 2 1 4 B 0.44 0.67 2 2 5 A 0.67 0.67 3 2 第 5 轮后 GPU 用满（3 × 1 + 2 × 3 = 9），分配终止。最终 A 得 3 个任务、3 GPU，B 得 2 个任务、6 GPU，两者主导份 额均为 2/3，GPU 作为瓶颈被用尽，CPU 余 4。公平体现在份额相等而非绝对数量相等，这是多资源公平的核心。 4) 加权 DRF 与水填充 加权 DRF（Weighted DRF）引入租户权重 w （表示优先级或购买份额），分配时比较的是归一化份额： i di arg min i wi 收敛后各租户主导份额与权重成正比，即 d /w = d /w 。实现上可将每个租户的虚拟需求乘以权重后走标准 DRF，等价 于把水填充到不同高度。加权分配循环如图14-8所示。 i i j j 计算各租户主导份额 d_i 资源是否耗尽? 否 是 选择 d_i/w_i 最小的租户 结束 按任务粒度分配一份资源 更新份额与权重 图14-8 DRF 加权分配流程 水填充（Water-filling）把每个租户看作一根水位柱，柱高即主导份额 d ，调度器总是向当前最低的柱子注水，直至某类 资源耗尽。DRF 每轮以任务为最小分配单位（离散、有颗粒度），水填充是连续模型；当任务粒度趋近于 0 时，两者收 i 敛。水填充直观解释了为何资源耗尽前主导份额始终被拉平。 5) 其他公平算法 •HDRF（Hierarchical DRF，层次化 DRF）：将 DRF 推广到层级租户树（组织→部门→团队→用户），树内每层独立运行 加权 DRF，父节点份额由其子节点聚合决定，层间按权重比例分配，用于企业多级组织结构的配额建模。 •比例公平（Proportional Fairness）：源自无线网络，目标是最大化 ∑ log(x /w ) 型对数效用，在公平与总吞吐之间折 中，能激励低需求用户让渡资源，但求解需凸优化，实时性差。 i i i •最大最小公平的局限：单资源假设、不支持权重、缺乏对低利用率的惩罚，故多资源集群普遍采用 DRF 及其变体。 6) K8s 生态实现 •Volcano proportion：Volcano 调度器的 proportion 插件按 Queue 的 weight 字段做加权 DRF，reclaimable 队列允 许回收借用资源，是 K8s 上最主流的 DRF 落地。 •Kueue Cohort 公平共享：Kueue 将多个 ClusterQueue 组成 Cohort，组内共享配额池，按 DRF 风格算法公平分配， 支持借用与归还，适配多团队共享训练集群。 •Koordinator 弹性配额：Koordinator 的 ElasticQuota 提供 min/max 两级配额，min 保障基线、max 封顶，超用部 分借用并按公平算法回收，适合突发作业。 7) Volcano 中的 DRF 实现 Volcano 以插件方式把 DRF 接入调度周期： // DRF fair scheduling pseudocode func DRFAllocate(tenants []Tenant, resources map[string]float64) { for { // select tenant with smallest dominant share t := minDominantShare(tenants) // allocate share of its dominant resource to this tenant alloc := allocateDominantResource(t, resources)

         if alloc == nil {
             break // no more resources to allocate
         }
         t.allocated += alloc
     }
 }

工程要点 •DRF 是 Max-Min 的多资源推广：任务粒度趋零时等价于水填充，资源耗尽前主导份额恒被拉平。 •加权 DRF 作用点：比较 d /w 而非 d ，收敛后份额与权重成正比。 i i i •生态对比：Volcano 用 weight 加权、Kueue 用 Cohort 共享、Koordinator 用弹性配额，公平粒度与回收策略不同。

14.6.5 多租户网络与存储隔离

GPU 之外，网络与存储是租户隔离的第二战场，涉及东西向流量、通信带宽与数据面权限。 网络隔离： NetworkPolicy是 Kubernetes 原生的命名空间级网络策略，通过 podSelector 与 namespaceSelector 组合定义入向 （Ingress）与出向（Egress）白名单，租户命名空间默认拒绝、显式放行：

deny all ingress by default in a tenant namespace

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: team-nlp spec: podSelector: {} policyTypes: - Ingress NetworkPolicy 仅覆盖 L3/L4，L7（HTTP 路由、gRPC）隔离需 Cilium 等扩展，其生效依赖 CNI 支持。 CNI 多租户方案： •Calico：基于 BGP 与 iptables/eBPF，NetworkPolicy 全功能，租户用命名空间隔离，支持 IPIP/VXLAN 封装；部署简 单，是 K8s 多租户网络的事实标准。 •IPvlan/Macvlan：Pod 直接绑定宿主机地址，二层共享、无 NAT，转发性能高；但租户间隔离弱，需结合 VRF 或路由 策略，适合网络密集但租户互信的场景。 •VPC 级隔离：每个租户独占 VPC/子网（如 AWS VPC CNI、Cilium Cluster Mesh），控制面与数据面完全隔离，跨租户 访问须显式对等，隔离最强、管理成本最高。 东西向流量隔离： 服务间互访经 Service Mesh（Istio/Ambient）或 Cilium 做 mTLS 与按命名空间/标签的路由隔离，防止 DNS 泄漏、路由 串扰与不可信租户横向移动。大型平台普遍要求租户 Pod 间默认拒绝、最小放行。 GPU 通信带宽隔离： GPU 集体通信（AllReduce、All-to-All）经 NVLink/NVSwitch（节点内）与 InfiniBand/RoCE（节点间）传输，是全集 群最敏感的共享资源。混部干扰的原理：All-to-All 是全网状流量，任一租户作业都会占满所在 GPU 域与 IB 子网的链路 队列；NVLink 无拥塞控制、RoCE 依赖 PFC 低水位，混部时出现带宽争抢与时延抖动，训练吞吐明显下降，节点内混部 时带宽利用率常降至 60% 以下。因此 GPU 通信不应跨租户混部。 拓扑感知规避：调度器按租户聚合放置（tenant-aware packing），把同租户作业尽量放入同一 GPU 域（NVSwitch 域、 同机架、同 IB 子网），在 GPU 域边界天然隔离租户通信；或为租户保留独立 IB partition 与 QoS class（PFC/ECN 策 略），从数据面切断干扰。MIG 场景下同一物理 GPU 仅允许同租户切片，避免共享 NVLink 端口。 存储隔离： •PV/PVC 按租户：命名空间内 PVC 与 StorageClass 绑定，管理员用 ResourceQuota 的 persistentvolumeclaims 计数 与 requests.storage 上限约束租户容量；可为租户配置独立 StorageClass（不同后端、不同性能档）。 •存储 Quota：CSI 层子卷 Quota（CephFS/GlusterFS），对象存储按租户建桶，用 IAM 桶策略与 STS 临时凭证做读写 与越权防护。 •共享文件系统目录级隔离：Lustre quota 支持 user/group/project 三级配额，AI 平台常为每个租户建独立子目录并分 配 project ID，按 project 设置容量与文件数硬/软上限：

set project quota for a tenant group (project id 1010)

lfs setquota -p 1010 -b 20T -B 25T -f 1000000 -F 1200000 /lustre/ai 共享盘的 IOPS/带宽隔离较弱，租户间 IO 争抢只能靠 cgroup blkio、Lustre OST 权重等限速缓解。 管理面隔离： •RBAC/ServiceAccount：以命名空间为最小授权单元，Role/RoleBinding 限定租户操作，Pod 通过 ServiceAccount 注入身份（如 Workload Identity / IRSA）访问云资源。 •单集群多租户 vs 多集群：单集群多租户共享控制面与节点池，利用率高但爆炸半径大、配额策略复杂；多集群每租户 独享集群，隔离强但碎片化与运维成本高，大型平台普遍采用两者混合。 •虚拟集群（vCluster）：每个租户一个虚拟控制面（多个命名空间聚合），底层共享真实集群，虚拟集群间 RBAC 与 NetworkPolicy 天然隔离，API 面完全独立，KubeConfig 按租户签发，兼顾隔离与利用率。 隔离强度分层： 隔离不是非黑即白，按租户信任度与合规要求选择强度，对比如表14-18所示。 表14-18 软隔离与硬隔离对比 对比项 软隔离 硬隔离 典型实现 配额 + NetworkPolicy + RBAC MIG 切分 + 独立集群 资源边界 逻辑配额，可借用与回收 物理/硬件切分，不可借用 对比项 软隔离 硬隔离 性能隔离 弱，存在混部干扰 强，带宽与显存独立 故障隔离 共享故障域，故障扩散 独立故障域，影响收敛 成本 高利用率、低闲置 资源碎片、成本高 适用场景 研究与训练 生产推理与合规要求

14.6.6 企业多租户治理与成本分摊

配额治理、成本归因与 SLA 是平台运营层的能力，决定多租户模式能否规模化运转。

  1. 配额治理流程 配额治理（Quota Governance）指对租户资源配额从申请到回收的全生命周期管理，闭环流程如图14-9所示。 用量监控与审计 闲置或超用? 是 否 团队提交申请 拒绝 评审委员会审核 通过 配额下发与通知 动态调整或回收 图14-9 配额治理闭环流程 •申请：团队提交作业类型、规模、持续时间与 SLA 等级，平台自动预检历史用量与集群空闲度，大型分配（100+ GPU）走人工评审，小分配走自动化策略。 •评审：按团队预算、项目优先级与历史效率综合判定，防止囤积（申请不用）与滥用（无预算占用）。 •下发：配额写入 ResourceQuota/ElasticQuota/Volcano Queue，同步到成本系统与用量面板，租户可自助查看。 •审计：周期对比分配量与实际用量，计算利用率，标记闲置作业与超配额使用。 •调整：低利用率配额下调或回收，高优先级项目可临时扩容，季度滚动评审校准。
  2. 成本核算与分摊 成本核算需精细化的计量机制，OpenCost/Kubecost 是常用方案：

OpenCost custom GPU pricing

ConfigMap: opencost/custom-

apiVersion: v1 kind: ConfigMap metadata: name: opencost-custom-pricing namespace: opencost data: pricing_config.json: | { "provider": "custom", "description": "GPU Cluster Pricing", "GPU": "8.00", # $8/GPU/hour "GPU_MEMORY": "0.05", # $0.05/GB/hour "CPU": "0.03", "RAM": "0.003", "storage": "0.0002" } 按团队成本分摊示例： Team NLP: GPU Hours: 12,800 (160 GPUs × 80 hours) GPU Memory-Hours: 1,024,000 GB-hours Total Cost: 12,800 × $8 + 1,024,000 × $0.05 = $153,600/month Team CV: GPU Hours: 6,400 GPU Memory-Hours: 512,000 GB-hours Total Cost: 6,400 × $8 + 512,000 × $0.05 = $76,800/month 成本分摊按粒度分为团队、项目、模型三级，对比如表14-19所示。 表14-19 成本分摊粒度对比 粒度 适用场景 计算口径 示例 按团队 部门预算与考核 团队内全部 GPU 用量 NLP 团队月度账单 按项目 业务线成本归因 项目工作负载用量 训练/推理/实验分账 按模型 模型研发投入核算 模型相关任务累计 某 7B 模型预训练成本 3) 定价与折扣策略 •定价策略：GPU 小时单价按卡型（H100/A100/L40S）与租户等级（生产/研发）差异化；区分标价与实际价，标价用 于内部预算，实际价按用量与折扣折算。 •Spot 与 Reserved 混合：Reserved/On-Demand 承接保障型基线（生产训练），Spot 承接可容忍中断的负载（实验、 超参搜索、推理降级副本）；平台把 Spot 折扣与抢占损失折算进有效单价，防止租户只挑 Spot 导致保障卡闲置。 •利用率折扣：实际单价等于标价乘以利用率系数，如月度利用率高于 80% 打折，激励租户回收闲置、提高卡效。 4) 租户 SLA 保障 SLA 分级与优先级、抢占策略一一映射，形成全平台的调度契约： •生产级：Guaranteed 队列，资源预留、不可抢占，失败自动重调度，承诺可用性。 •研究级：Burstable 队列，基线保障加可借用，高峰可被高优先级回收，SLA 为尽力保障。 •实验级：Best-Effort 队列，仅用空闲资源，随时可抢占。 优先级与抢占映射：PriorityClass 数值决定抢占链（生产 > 研究 > 实验），reclaimable 队列先回收借用资源再回收低优 先级作业；生产作业预占时通过 PodGroup 的 minMember 保证 gang 调度完整性，避免部分拉起。关键工作负载的资源 预留通过 PodGroup 声明：

reserve resources for critical jobs

apiVersion: scheduling.volcano.sh/v1beta1 kind: PodGroup metadata: name: weekly-benchmark-pg spec: minMember: 32 queue: reserved-resources

Volcano supports removing allocated but not running Pods from specified queue

to release resources for higher priority jobs

  1. 闲置资源回收 •空闲 GPU 检测：DCGM 采集 GPU 利用率与作业状态，利用率低于阈值（如 10%）持续 N 分钟即判空闲，涵盖空转训 练、悬挂作业与占显存不计算（idle holding）。 •抢占回收：先回收 Best-Effort 与 Burstable 的借用部分，回收前优雅排水并保存 checkpoint；训练作业依赖周期性 checkpoint 幂等续训。 •队列间借用（Cohort borrowing）：同一 Cohort 内队列共享配额池，空闲队列把额度借给繁忙队列，忙时归还； Kueue Cohort 与 Koordinator ElasticQuota 均支持，借用不破坏各队列的 min 保障。
  2. 业界实践 •Anthropic：按模型训练/推理/评估划分租户，推理与训练混合调度（先到先得加弹性），用低优先级作业吸收容量波 动。 •Inflection：以虚拟集群方式为训练团队提供隔离控制面，用队列权重表达优先级，长时间空闲训练做暂停与恢复 （pause/resume）。 多队列加弹性配额、利用率驱动的成本归因，训练作业支持抢占与 checkpoint 恢复，平台 GPU 利用率显著提升。上述 内容均依据公开资料归纳，具体细节以官方披露为准。 工程要点 •治理闭环：申请→评审→下发→审计→调整，核心在审计与闲置回收，防止配额囤积。 •成本三粒度：团队/项目/模型，实际单价与利用率挂钩，Spot 与 Reserved 折算有效成本。 •SLA 映射：优先级与抢占映射生产/研究/实验三级，先回收借用资源再回收低优先级。 •回收顺序：Best-Effort 先于 Burstable 借用部分，训练作业靠 checkpoint 恢复，以可计算性换利用率。

14.6.7 推理负载 QoS 与动态降级

数据中心推理平台常需同时承载视觉、LLM、语音、Embedding 等多类负载，资源需求与延迟敏感度差异极大。推理负 载的 QoS 与动态降级是保障核心业务稳定的关键，区别于训练作业（可等待、可中断），推理请求是延迟敏感的在线负 载，调度需以毫秒级粒度响应。

  1. 多负载分类与优先级 按延迟敏感度与资源特征划分，如表14-20所示。 表14-20 推理负载分类与调度策略 负载类型 典型代表 资源特征 延迟要求 调度策略 强实时 在线语音（STT/TTS）、视频推流 低时延、稳定吞吐 P99 < 100ms 独占/预留，抢占优先 交互式 LLM 对话、Agent 调用 吞吐 + 时延平衡 P99 < 2s 优先队列，弹性扩缩 批量 离线批推理、Embedding 批处理 高吞吐、可排队 秒级-分钟级 低优先级，空闲补齐 训练 模型训练作业 长时、可检查点 不敏感 最低优先级，可抢占
  2. 动态降级机制 负载过载时按层级降级以保住核心业务：
  1. 请求级降级：丢弃或拒绝低优先级请求（返回降级响应），保护高优先级请求延迟。批量推理优先被丢弃，在线语音最 后。
  2. 资源级降级：抢占低优先级负载的计算资源（NPU/GPU 时间片、内存），转给高优先级；批量推理让出算力给交互式 负载。
  3. 模型级降级：大模型降级为小模型（70B → 7B），或降精度档位（FP16 → INT8），牺牲质量保延迟。
  4. 能力级降级：关闭非核心能力（多模态的视觉分支、后处理增强），只保留主路径推理。
  1. 多模态共存的资源调度 视觉 + LLM + 语音共存的难点是资源特征差异大：视觉是流式、定长、高并发（多路视频帧），LLM 是变长、长时、显存 密集（KV Cache 动态增长），语音是低时延、周期性。调度策略： •算力分时：按负载特征分时段分配（如白天语音+视觉为主、夜间 LLM 批处理），用时间片错峰。 •显存预留：LLM 的 KV Cache 动态增长，需为在线 LLM 预留显存水位（防止 OOM），视觉/语音用剩余显存。 •内核级协同：多计算单元（CPU/NPU/DSP）各承担不同负载，NPU 跑核心推理，CPU 跑预处理与调度，DSP 跑轻量 信号处理（语音 VAD/AEC）。
  2. 降级策略的工程落地 动态降级须可观测、可回滚： •监控指标：各负载的 P99 延迟、吞吐、资源利用率、降级次数——延迟超标自动触发降级，恢复后自动回退。 •降级开关：四级降级策略做成独立开关，按场景组合（如仅丢弃批量 + 模型降级），避免一刀切。 •演练机制：定期人为制造过载验证降级链路，确认降级不会引发雪崩（低优先级大量重试冲击高优先级）。 •容量规划：降级是兜底，容量规划仍按峰值预留；降级次数作为容量告警信号（频繁降级 = 扩容信号）。

14.6.8 SLO/SLI 稳定性工程

多租户 QoS 分级解决「资源怎么分」，稳定性工程解决「服务好不好」。本节以 SLO 为主线，把 QoS 分级接入度量、预 算、降级的闭环，避免指标设了不用、故障靠人肉发现。

  1. SLO/SLI 定义 •SLI（Service Level Indicator）是可量化的服务质量指标，如请求成功率、P99 延迟；SLO（Service Level Objective）是对 SLI 的目标承诺，如「30 天窗口内成功率不低于 99.9%」；SLA（Service Level Agreement）是对外 契约，通常比 SLO 更保守。 •AI 推理与训练场景的典型 SLI 分四类：可用性（请求成功率、有效训练时间占比）、延迟分位（LLM 推理 TTFT、TPOT 与端到端 P99）、吞吐（QPS、token/s、训练样本吞吐）、训练进度（checkpoint 成功率、作业完成率、两次故障间隔 MTBF）。 典型 SLI 与 SLO 示例如表14-21所示。 表14-21 AI 场景典型 SLI 与 SLO 示例 场景 SLI SLO 示例 观测窗口 LLM 在线推理 TTFT P99、请求成功率 TTFT P99 < 1s，成功率 > 99.9% 5 分钟聚合，30 天 语音实时推理 端到端延迟 P99 P99 < 300ms 5 分钟聚合，30 天 离线批推理 吞吐、排队时延 吞吐达标率 > 98% 作业级 大模型训练 有效训练时间占比 月度可用性 > 99%，无 15 分钟以上中断 月度
  2. 误差预算 误差预算（error budget）等于 1 减 SLO，是允许的不达标时长上限。SLO 99.9% 时每月约 43 分钟，计算公式为 error_budget = (1 − SLO) × T ，T 为观测窗口时长。 预算消耗用燃烧率（burn rate）刻画，燃烧率等于实际错误率除以允许错误率。1 小时窗口错误率 2%（允许 0.1%）时 燃烧率为 20，属快速燃烧，预算会在数小时内耗尽，须立即响应；持续 1.1 倍的低燃烧率同样耗尽预算，用更长窗口（6 小时、3 天）的慢速燃烧告警覆盖。 预算耗尽时的策略：冻结发布（新特性暂停上线）、回滚近期变更、拒绝低优作业进入；预算富余时恢复节奏。预算按季 度重置，避免长期累积导致破罐破摔。
  3. 告警与降级熔断 •SLO 告警分级：P0 立即呼叫，由快速燃烧率触发（如 1 小时窗口燃烧率不低于 14.4）；P1 工单跟踪，由慢速燃烧触 发；P2 仪表盘观察，关注容量与水位。告警与预算消耗挂钩后，无效告警大幅减少。 •限流：按租户与优先级做 QPS 配额，令牌桶实现，超限请求排队或拒绝，防止单租户打满共享服务。 •降级：衔接前述推理负载 QoS 的动态降级机制，预算接近耗尽时按负载优先级依次降级，先丢批量后降模型档位。 •熔断：连续错误率超阈值（如 5%）触发熔断，快速失败并进入冷却（约 5 秒），半开窗口放量探测（约 10% 流量）， 恢复后全量放行。 三者配合形成闭环：限流在前防过载，熔断在中断故障传播，降级在尾部保核心业务。误差预算消耗与降级闭环如图14- 10所示。 计算误差预算消耗 燃烧率超阈值? 是 告警分级 限流/降级/熔断 采集 SLI 否 冻结发布与复盘 图14-10 误差预算消耗与降级闭环
  4. 故障演练与预案 •故障注入演练：定期（月度）对关键路径注入故障，节点宕机、网络抖动、GPU 故障、限流打满，验证降级与恢复链 路真实可用，避免预案写在纸上、演练从未执行。 •应急预案：为每个 P0 场景维护 playbook，明确恢复步骤、负责人与升级路径；设定 RTO（恢复时间目标）与 RPO （可容忍数据丢失），如推理服务 RTO 15 分钟。 •恢复与复盘：演练或真实故障后执行复盘，输出 RCA 与改进项清单并跟踪闭环；复盘聚焦系统性根因，不追个人责 任。

14.7 数据中心功耗与液冷

单GPU功耗从V100的300W跃升至H100的700W、B200的1000W，以及GB200 NVL72机架高达120kW的功耗密度，正在 从根本上改变AI数据中心的设计范式。传统的风冷方案在30kW/机架附近遭遇物理极限，液冷已成为万卡级AI训练集群的 必然选择。本节从GPU功耗特征出发，系统分析散热技术、能效优化和绿色AI实践。

14.7.1 GPU 功耗演进与 TDP

GPU功耗代际演变： 历代加速卡功耗与能效对比如表14-22所示。 表14-22 GPU 功耗代际演变 GPU型号 TDP (W) 每TFLOPS功耗 (FP16) 内存带宽 (TB/s) HBM功耗占比 V100 SXM2 300 2.4 W/TFLOPS 0.9 约20% A100 SXM4 400 1.3 W/TFLOPS 2.0 约25% H100 SXM5 700 1.4 W/TFLOPS (dense FP16: 495 TFLOPS) 3.35 约30% B200 1000 约0.6 W/TFLOPS 8.0 约35% GB200 NVL72 120000 (机架) - - - TDP vs 实际功耗： TDP（Thermal Design Power）是设计热功耗上限，实际功耗受限于：

  1. 工作负载特征：Transformer训练的GEMM运算接近TDP（90-95%），轻量推理可能仅60-70%。
  2. 功耗封顶（Power Capping）：通过 nvidia-smi 动态限制功耗上限。
  3. 频率-功耗曲线：GPU频率与功耗呈超线性关系，最后10%频率可能消耗30%功耗。
 # view GPU power status
 nvidia-smi --query-gpu=index,power.draw,power.limit,power.max_limit \
   --format=csv
 # set power cap

sudo nvidia-smi -pl 500

14.7.2 功耗管理与频率调整

view power vs frequency relationship

nvidia-smi dmon -s pucm -d 1 动态频率缩放： NVIDIA GPU的功耗管理基于P-State机制。P0为最高性能态（对应最高频率/功耗），P8为最低功耗态：

 # view GPU current P-State
 nvidia-smi -q -d PERFORMANCE
 # set GPU to P0 (locked performance)
 nvidia-smi -pm 1        # enable persistence mode
 nvidia-smi -ac 1215,1410 # set memory and core clock
 # set GPU to P8 (auto-switch, lowest power)
 nvidia-smi -acp 0       # auto-switch P-State based on GPU utilization

数据中心级功耗管理： ┌──────────────────────────────────────────────────────┐ │ DC-level Power Management │ │ ┌──────────────┐ ┌─────────────┐ ┌──────────────┐ │ │ │ Power Budget │ │ Thermal │ │ Workload │ │ │ │ Manager │ │ Monitoring │ │ Scheduler │ │ │ │ (Total Cap) │ │ (Zones) │ │ (Power-aware)│ │ │ └───────┬──────┘ └──────┬──────┘ └───────┬──────┘ │ │ │ │ │ │ │ ┌───────┴────────────────┴─────────────────┴───────┐│ │ │ Rack-level Power Distribution ││ │ │ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ││ │ │ │P0 │ │P1 │ │P2 │ │P3 │ │P4 │ │P5 │ │P6 │ ││ │ │ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ ││ │ └──────────────────────────────────────────────────┘│ └──────────────────────────────────────────────────────┘ 功耗感知调度：调度器可以将训练作业分配到当前功耗最低的机架位置，实现热负载均衡，避免局部热点触发降频。 H100 功耗封顶存在反直觉的非线性关系。 nvidia-smi -pl 500 （500W，约 71% TDP）下，典型 GEMM 训练吞吐约 85-90%——即牺牲 29% 功耗仅损失 10-15% 性能。降频至 400W（57% TDP）时性能约 70%。原因：GPU 频率-功耗呈 超线性，最后 10% 频率消耗约 30% 功耗，源自先进制程下的漏电流（Leakage Current）效应。 对于电力受限的数据中心，在 80% TDP 下运行可额外容纳 25% 的 GPU 数量，总集群训练吞吐反超全功耗配置。GB200 NVL72 机架达 120kW，必须采用液冷（直接芯片或浸没式），风冷每机架上限约 40-60kW。浸没式液冷 PUE < 1.05 vs 风 冷 1.2-1.4，长期 TCO 更具优势但初始投资高 30-50%。

14.7.3 PUE 优化

PUE（Power Usage Effectiveness）衡量数据中心的能效： Total Facility Power PUE = IT Equipment Power 理想PUE为1.0（所有电力都用于IT设备）。当前行业PUE分布如表14-23所示。 表14-23 行业 PUE 分布 数据中心类型 PUE 冷却方式 传统企业DC 1.8 - 2.5 传统风冷 节能风冷DC 1.2 - 1.4 热通道封闭 + 自然冷却 液冷DC 1.03 - 1.1 直接芯片液冷 Google TPU Pod 约1.10 液冷 + 自定义电源架构 PUE优化实践：

  1. 提升送风温度：ASHRAE TC9.9建议允许数据中心的入口温度更高（18-27°C → 25-35°C），减少冷水机组能耗。
  2. 高压直流供电：240V HVDC替代传统48V电信电源，减少AC-DC转换损耗（效率从85%提升至94%）。
  3. 自然冷却：在寒冷地区（如北欧、加拿大）使用室外空气直接冷却或间接换热，全年可节省40-60%的制冷能耗。
  4. UPS效率优化：采用在线互动式UPS（效率98%）替代双变换UPS（效率92-94%）。

14.7.4 液冷散热技术

液冷方案对比： ┌────────────────────────────────────────────────────────────┐ │ Cooling Technology Spectrum │ │ │ │ Air Cooling Direct-to-Chip Immersion │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ ~30 kW │ ▶ │ ~70 kW │ ▶ │ ~100+ kW │ │ │ │ Per Rack │ │ Per Rack │ │ Per Rack │ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ │ │ PUE: 1.2-1.4 PUE: 1.05-1.1 PUE: 1.02-1.05│ │ Cost: Low Cost: Medium Cost: High │ │ Complexity: Low Complexity: Medium Complexity: High │ └────────────────────────────────────────────────────────────┘ 直接芯片液冷（Direct-to-Chip）： NVIDIA H100/H200 NVL和B200默认采用直接芯片液冷方案： Coolant circulation loop: ┌────────┐ GPU Cold Plate ──▶ Manifold ──▶ CDU ──▶ Dry Cooler ──┘ │ GPU Cold Plate ◀── Manifold ◀── CDU ◀── Pump ◀───────┘ CDU (Coolant Distribution Unit):

 - Primary side: deionized water/glycol mixture -> Dry Cooler/cooling tower heat rejection
 - Secondary side: high-purity deionized water -> GPU Cold Plate heat absorption
 - Control: temperature, pressure, flow rate, conductivity

GB200 NVL72液冷方案： GB200 NVL72将72个Blackwell GPU与36个Grace CPU集成在单个机架中，通过液冷系统实现120kW散热。其液冷路径 为： •每个Compute Tray（含2个B200 + 1个Grace）通过热交换器将热量传导至机架级CDU。 •CDU连接到数据中心级冷却回路。 •液冷剂的入口温度为32°C（温水冷却），出口温度约45-50°C，可直接用于数据中心供暖或预热水。 浸没式液冷： 浸没式液冷分单相和两相两种方案： •单相浸没：将服务器完全浸入介电液体（如3M Fluorinert或Engineered Fluids）中，液体在泵驱动下循环带走热量。 散热能力约50-100kW/机架。 •两相浸没：利用低沸点液体在GPU热表面沸腾吸收热量，气体在顶部冷凝器中液化回流。散热能力可达150kW+/机 架，但液体成本和密封要求高。 浸没式液冷优势： •极低PUE（1.02-1.03） •零风扇噪音 •保护硬件免受氧化和灰尘 •缺点：维护复杂（液体阻燃性/腐蚀性）、硬件改造（移除风扇/散热片）、部署周期长

14.7.5 绿色 AI 与碳感知调度

碳感知调度（Carbon-Aware Scheduling）： 碳感知调度根据电网碳强度动态调整训练作业的时间窗口和地理位置：

 # carbon-aware scheduling pseudocode
 from carbon_aware_sdk import CarbonIntensityForecast
 forecast = CarbonIntensityForecast(region="us-west-2")
 optimal_window = forecast.get_lowest_carbon_window(
     duration_hours=72,
     min_gpus=512

)

 if carbon_intensity_current < threshold:
     scheduler.submit_job(job, optimal_window)
 else:
     scheduler.defer_job(job, optimal_window.start_time)

训练能耗估算： 训练一个LLaMA 2 70B模型的估算碳排放： GPU: 2000 x H100, TDP 700W Training time: 90 days (2160 hours) GPU power: 2000 x 700W x 0.9 (utilization) x 0.7 (avg power/TDP) = 882 kW Non-IT facility overhead (PUE=1.1): 882 x 0.1 = 88.2 kW Total power: 970.2 kW Total energy: 970.2 kW x 2160 h = 2,095,632 kWh Carbon emissions (US average grid ~0.4 kg CO2/kWh): 838 tons CO2 Carbon emissions (clean grid ~0.01 kg CO2/kWh): 21 tons CO2 14.8 2000-GPU 集群设计实战 本节提供一个完整的2000-GPU AI训练集群设计方案，涵盖需求分析、网络架构、存储规划、调度系统、功耗散热到物料 清单和成本的端到端蓝图。方案以H100 GPU为基准，兼顾GB200 NVL72的过渡路径。 集群设计中最容易被低估的变量是检查点写入的峰值流量：2000 GPU 同时写检查点是最容易被低估的存储网络瓶颈。按 每GPU约274 MB（FSDP分片），2000 GPU 同时写 = 548 GB/checkpoint。若写入窗口 60s，聚合写入带宽需约 9 GB/s ——看似不高。实际存在三个放大因子：(1) 同步效应：FSDP 的 FULL_STATE_DICT 模式下所有 GPU 几乎同时发起写操 作，瞬时带宽可达数百 GB/s；(2) Lustre 锁竞争：数千客户端同时 write() 到同一目录，MDS 锁压力非线性增长，单 次 checkpoint 耗时可能从理论 30s 膨胀到 3-5min；(3) 与训练流量的竞争：若存储网络与计算网络共享物理链路， checkpoint 写入会挤压 AllReduce 带宽。 业界实践：DeepSeek 通过 3FS 的链式复制替代集中式 OSS 来消除锁竞争；Meta 在 Grand Teton 中将 checkpoint 先写 本地 NVMe（< 5s），后台异步上传 S3。对于 2000 GPU 自建集群，建议为存储网络配备独立的 Spine-Leaf 拓扑，且带宽 按训练流量加 checkpoint 流量的 1.5 倍设计。

14.8.1 需求定义

训练负载画像： 各类负载的规模与网络需求对比如表14-24所示。 表14-24 训练负载画像 负载类型 比例 典型规模 运行时长 网络需求 大模型预训练 40% 512-1024 GPU 7-90天 极高（AllReduce密集） 大模型微调 30% 64-256 GPU 1-14天 高 中小模型训练 20% 8-64 GPU 1-7天 中等 超参数搜索/Ablation 10% 32-128 GPU 1-3天 中等 SLA要求： •关键训练作业：优先级最高，可抢占低优作业，24小时内恢复。 •常规训练作业：弹性容忍，允许排队等待。 •推理服务（备用容量）：使用空闲GPU，优先级最低。

14.8.2 硬件配置

节点选型（方案A：H100 SXM5基准）： Compute nodes (250 units, 8 GPU/node): GPU: 8x H100 SXM5 80GB HBM3 CPU: 2x Intel Xeon Platinum 8480C (56 cores, 2.0 GHz) RAM: 2 TB DDR5-4800 (16x 128GB) System disk: 2x 3.84TB NVMe SSD (RAID1) Local cache: 4x 7.68TB NVMe SSD (RAID0, 30TB available) Network:

     - Management: 1x 25GbE (Broadcom 57414)
     - Training backend: 8x ConnectX-7 IB NDR (400Gbps)
     - Storage: 2x ConnectX-6 Dx (100GbE, LACP)

Power: 4x 3300W PSU (N+1 redundancy) Cooling: Direct-to-Chip liquid cooling Management nodes (5 units): CPU: 2x Xeon Gold 5416S (16 cores) RAM: 256 GB DDR5 Storage: 2x 480GB SSD (RAID1) Login nodes (4 units): CPU: 2x Xeon Gold 6438Y+ (32 cores) RAM: 512 GB DDR5 GPU: 4x L40S (for interactive development) 备选方案（方案B：GB200 NVL72）： 6x rack GB200 NVL72 (each rack 36 Grace CPU + 72 B200 GPU) Total GPU: 6 x 72 = 432 B200 GPU 1 B200 ~ 2-3x H100 performance (FP8) Equivalent to: 864-1296 H100 GPU Note: GB200 NVL72 has extremely high performance density but absolute GPU count < 2000 If counted by physical B200 cards, reaching 2000 GPUs needs about 28 NVL72 racks (2000 / 72 = 27.8); counting by H100-equivalent performance (2x), about 15 racks already cover a 2000-GPU H100-equivalent scale

14.8.3 网络设计

训练后端：Rail-Optimized IB NDR Rail architecture (8 rails, 2000 GPUs = 250 nodes x 8 NICs): Rail 0..7: Rail k connects NICk of all 250 compute nodes Per rail: 8x QM9700 (64-port NDR400G), each leaf 32 down + 32 up 32 down x 8 switches = 256 ports >= 250 nodes per rail Leaf count: 8 rails x 8 = 64 QM9700 Spine layer (32 QM9700, 64-port): Each leaf has 32 uplinks -> total 64 x 32 = 2048 uplink ports 32 spine x 64 ports = 2048 -> full-mesh non-blocking (1:1) IB subnet manager: OpenSM (supports Sharp) Sharp tree: intra-rail Reduce + cross-rail Sharp aggregation 前端管理网络： Management ToR switches (34 units, covering 250 compute nodes): Model: Arista 7050SX3-48YC8 (48x 25GbE + 8x 100GbE) Connection: each management ToR connects 8-10 compute nodes Uplink: 2x 100GbE to management Spine Management Spine switches (2 units): Model: Arista 7280SR3-48YC8 (48x 100GbE) Function: aggregates all management ToRs, connects management/login nodes and storage management network 存储网络： Storage ToR switches (4 units): Model: Arista 7050CX3-32S (32x 100GbE) Connection: each connects storage servers and compute node storage NICs Interconnect: 4 switches fully connected (400Gbps backbone) 网络物料清单如表14-25所示。 表14-25 网络物料清单 Component Model Qty Unit Price ($) Subtotal ($) IB Switch QM9700 (64-port NDR) 96 65,000 6,240,000 Mgmt ToR Arista 7050SX3 34 12,000 408,000 Mgmt Spine Arista 7280SR3 2 45,000 90,000 Storage Switch Arista 7050CX3 4 18,000 72,000 IB Optical Module NDR OSFP 4048 800 3,238,400 IB Fiber Cable NDR MPO-12 20m 4048 150 607,200 Ethernet Module 25/100GbE SFP 680 200 136,000 Network Total 10,791,600

14.8.4 存储系统

混合存储架构： +----------------------------------------------------+ | Parallel File System (WekaFS/Lustre) | | High-performance layer: 8x NVMe Storage Node | | Capacity layer: S3 Object Storage Gateway | | Aggregate read bandwidth: ~400 GB/s (8 nodes x 2x 200GbE cap) | | Aggregate write bandwidth: >200 GB/s | | Usable capacity: 2 PB (NVMe) + 10 PB (S3) | +----------------------------------------------------+ Storage node configuration (8 units): CPU: 2x Xeon Gold 6430 (32 cores) RAM: 512 GB DDR5 NVMe: 24x 15.36TB NVMe SSD (Samsung PM9A3) Network: 2x 200GbE (NVIDIA ConnectX-6 Dx) Single node raw capacity: 368 TB Total raw capacity: 2.9 PB (RAID6 8+2 -> 2.3 PB usable)

14.8.5 调度与编排

混合调度架构： +---------------------------------------------------------------+ | User Access Layer | | +----------+ +----------+ +---------------+ | | | Jupyter | | VSCode | | CLI/SSH | | | +----+-----+ +----+-----+ +-------+-------+ | | +--------------+---------------+ | | v | | +---------------------------------------------+ | | | Unified Task Gateway (REST/gRPC) | | | +------+--------------------+------------------+ | | | | | | v v | | +--------------+ +-------------------+ | | | SLURM | | Kubernetes | | | | (batch) | | (service+interactive) | | | 1600 GPU | | 400 GPU | | | +--------------+ +-------------------+ | +---------------------------------------------------------------+ Partition scheme: SLURM partition: training dedicated (200 nodes, 1600 GPU) K8s partition: interactive dev + inference + light training (50 nodes, 400 GPU) Dynamic adjustment: migrate nodes between SLURM and K8s based on load SLURM配置要点：

 # slurm.conf key configuration
 PartitionName=gpu-large Nodes=gpu[001-200] Default=YES \
   MaxTime=14-00:00:00 DefaultTime=1-00:00:00 \
   State=UP OverSubscribe=EXCLUSIVE
 PartitionName=gpu-interactive Nodes=gpu[151-200] \
   MaxTime=12:00:00 DefaultTime=02:00:00 \
   State=UP OverSubscribe=NO
 # QoS configuration

sacctmgr add qos production Priority=10000
MaxWall=90-00:00:00 MaxJobsPU=10
GrpSubmitJobs=100 MaxTRESPerUser=gres/gpu=1024 sacctmgr add qos dev Priority=1000 \

14.8.6 功耗与散热

MaxWall=7-00:00:00 MaxJobsPU=30
GrpSubmitJobs=500 MaxTRESPerUser=gres/gpu=128 总功耗估算： IT equipment power: Compute nodes: 250 x 10,000W (8xH100 + CPU + RAM + NICs) = 2,500 kW Storage nodes: 8 x 2,500W = 20 kW Management/Login nodes: 9 x 1,500W = 13.5 kW Network equipment: ~40 kW IT total power: ~2,573 kW PUE=1.08 (liquid cooling): Total facility power: 2,573 x 1.08 = 2,779 kW Annual energy: 2,779 kW x 8,760 h = 24,344,040 kWh Electricity cost (0.08$/kWh): $1,947,523/year 液冷系统设计： CDU specifications (Coolant Distribution Unit): Cooling capacity: 3,000 kW (N+1 redundancy, 2 units) Primary side temperature: 25°C (supply) / 35°C (return) Secondary side temperature: 32°C (supply) / 45°C (return) Flow rate: 1,000 LPM Pump power: ~50 kW Cooling equipment: Dry Cooler: 4x 750kW (N+1) or Cooling Tower: 3x 1000kW (requires water source) Piping layout: Main supply/return pipe: DN200 (8 inch), ring between racks Rack branch pipe: DN50 (2 inch), quick-connect fittings Material: Stainless steel 316L (corrosion resistant)

14.8.7 机架布局

Data center floor layout (75 racks): Row A (12 racks): management + login + storage nodes Row B (12 racks): compute nodes (GPU001-048) Row C (12 racks): compute nodes (GPU049-096) Row D (12 racks): compute nodes (GPU097-144) Row E (12 racks): compute nodes (GPU145-192) Row F (15 racks): compute nodes (GPU193-250) + network core Per rack: Compute node rack: 4x 6U DGX nodes = 24U (42U rack, 18U remaining) Network rack: IB switches + management ToR (24U) Power density: compute node rack ~40kW (liquid cooling) 14.8.8 5 年 TCO 估算 5 年 TCO 估算如表14-26所示。 表14-26 5 年 TCO 估算 Cost Item CapEx ($) OpEx/year ($) 5-year Total ($) GPU Nodes (250 units) 62,500,000 - 62,500,000 Storage System 2,800,000 - 2,800,000 Network Equipment 10,791,600 - 10,791,600 Management Nodes 250,000 - 250,000 Liquid Cooling System 3,500,000 - 3,500,000 Facility Renovation 2,000,000 - 2,000,000 Software Licenses 500,000 200,000 1,500,000 Electricity - 1,947,523 9,737,615 Operations (5 FTE) - 1,000,000 5,000,000 Spare Parts & Maintenance - 500,000 2,500,000 Total 82,341,600 3,647,523 100,579,215

14.8.9 裸金属装机与扩容

GPU 集群以裸金属为主（容器只是用户态隔离，不引入虚拟化开销），裸金属装机与硬件运维是集群生命周期管理的基 础。规范的目标是「装机可重复、升级可回滚、故障可定位」。

  1. PXE 网络装机 大规模裸金属装机用 PXE 网络引导，避免逐台 U 盘安装，流程如下：
  1. DHCP 分配 IP。
  2. TFTP/HTTP 拉取引导内核。
  3. 加载定制镜像。
  4. 分区/RAID。
  5. 安装驱动与基线配置。
  6. 自动加入集群。 生产要点：装机镜像固化驱动、CUDA 运行时、内核参数基线，保证「镜像即环境」；装机后自动执行硬件自检 （GPU/NIC/内存/硬盘）；装机记录（MAC → 节点 → 镜像版本）入库，作为硬件资产管理基础。新节点上线前跑一遍完 整验证（GPU 压力测试、NCCL 连通、IB 吞吐），通过才接入生产。
  1. BIOS 与固件升级 GPU 集群固件包括主板 BIOS、GPU 固件（NVML 可查）、网卡固件（mlx5fw）、NVSwitch 固件。升级规范： •升级窗口：固件升级需业务停机窗口（GPU 固件升级要求节点空闲），批量滚动升级而非一次性全量。 •版本基线：维护「固件版本 × 驱动版本 × 内核版本」兼容矩阵，升级前核对；GPU 与网卡固件常需与驱动配套，混 配会导致性能降级或不可用。 •回滚方案：升级前保留旧固件版本，升级后验证（GPU 自检、NCCL 测试），失败立即回滚；带外 BMC 提供固件恢复通 道。 •带外管理 BMC：每节点 BMC 提供 IPMI 远程电源/控制台，独立于业务网络，用于节点异常时的远程诊断与重启。
  2. 容器环境系统加固 裸金属上的容器环境加固，目标「最小攻击面 + 稳定基线」： •内核与运行时基线：锁定内核版本与容器运行时版本（如 containerd），禁用不必要内核模块，设置安全基线 （ sysctl 加固项）。 •驱动与容器隔离：驱动驻留宿主（GPU 驱动不进容器），容器内仅装 CUDA 运行时；通过 CDI 注入设备，避免容器内装 驱动导致版本冲突。 •镜像安全：基础镜像固定版本 + 签名校验，限制特权容器，容器以非 root 运行（配合 GPU 设备注入仍可用）。
  3. 扩容流程 集群扩容（新节点上线）遵循标准流程：硬件验收（厂商交付检测）→ PXE 装机 → 固件/驱动/内核基线 → 硬件自检 → 单节点验证（GPU 压力、NCCL）→ 接入集群（调度器注册）→ 网络验证（新节点入 rail 后 IB 吞吐、NCCL 跨节点）→ 小规模试跑 → 全量放量。任何一步失败即隔离该节点，不污染生产。

14.8.10 实施路线图

Phase 1 (Month 1-3): Infrastructure preparation

   - Data center liquid cooling renovation
   - Power capacity expansion
   - Network cabling

Phase 2 (Month 4-5): Core deployment

   - 50-node pilot deployment
   - SLURM + K8s base platform setup
   - Storage system installation and configuration

Phase 3 (Month 6-8): Scale expansion

   - Full 250-node deployment
   - Monitoring/alerting system go-live
   - User training

Phase 4 (Month 9-12): Stable operations

   - Performance tuning (MFU improvement)
   - Cost optimization (Spot instances)
   - Automated operations
上一章

第 13 章 存储与数据工程
下一章

第 15 章 云原生 MLOps

📑 AI Infra 权威指南

1 第 1 章 AI Infra 概述 2 第 2 章 GPU 微结构 3 第 3 章 加速器与异构计算 4 第 4 章 高性能 Kernel 5 第 5 章 编译器与框架 6 第 6 章 分布式训练基础 7 第 7 章 高级并行策略 8 第 8 章 集合通信与网络 9 第 9 章 训练系统工程 10 第 10 章 推理优化与服务 11 第 11 章 模型量化与压缩 12 第 12 章 RAG 与向量检索 13 第 13 章 存储与数据工程 14 第 14 章 集群架构与调度 15 第 15 章 云原生 MLOps 16 第 16 章 性能与成本优化 17 第 17 章 AI Infra 计算 18 第 18 章 AI Infra 实践
← 返回本书大纲