GPU 集群管理

K8S 默认调度器的三大不足：

1. 无 Gang Scheduling：默认调度器逐 Pod 调度，如果 8 卡 Job 只调度了 7 个 Pod，第 8 个因资源不足 pending，则前 7 个占着资源却无法训练，造成资源浪费（"资源碎片化"问题）
2. 无队列/公平性：默认调度器只有 PriorityClass，没有 Queue 级别的公平性保证。大量小 Job 可以饿死大 Job，反之亦然
3. 无拓扑感知：默认调度器不知道 GPU 之间的 NVLink 拓扑关系，可能把 TP 组的 Pod 调度到 NVLink 不连通的节点上，导致通信性能下降 10 倍

改造的核心原则是"最小侵入"——尽量在 K8S 已有框架上扩展，而不是替换。Scheduling Framework 的插件机制正好提供了这个能力。

💡 K8S 默认调度器对 GPU 训练的三大硬伤：无 Gang、无公平、无拓扑。改造思路是在 Scheduling Framework 上做扩展，而不是替换调度器。

实现机制：

1. 用户创建 PodGroup CRD，声明 minMember（最少需要同时运行的 Pod 数量）
2. Volcano 的 gang 插件在 PreFilter 阶段检查：如果当前可调度资源不足以满足 minMember，则整个 PodGroup 的所有 Pod 都不调度
3. 调度成功后，如果部分 Pod 失败导致运行中的 Pod 数 < minMember，则杀死所有 Pod（保证 All-or-Nothing 语义）

PodGroup CRD (minMember=8)
    ↓
gang 插件 PreFilter: 可调度 Pod 数 >= minMember?
    ├── Yes → 正常调度所有 Pod
    └── No  → 所有 Pod 状态设为 Unschedulable，等待资源释放

缺陷：

1. 资源浪费：等待期间所有 Pod 占着资源不动（"占坑不拉屎"问题）
2. 死锁可能：两个 Gang Job 各占部分资源，都等对方释放 → 死锁
3. 无弹性：minMember 是固定的，不能根据当前资源动态调整
4. 粗粒度：只有全部调度或全部不调度，没有部分调度 + 排队的中间态

💡 Gang Scheduling 的核心矛盾是 All-or-Nothing 语义和资源利用率之间的博弈——解决思路是弹性 Gang + Backfill 填充。

GPU 利用率低的根因是碎片化——大量的资源被占而不用或低效使用。优化从四个维度入手：

💡 GPU 利用率优化的核心是降碎片——调度层面 Gang+Backfill，多租户层面弹性配额，共享层面 MIG/MPS，三个维度叠加可以从 30% 提到 70%+。

核心矛盾：训练任务 GPU 利用率接近 100%，会争抢推理任务的 GPU 时间片，导致推理延迟飙升。

隔离方案（从强到弱）：

推荐方案：

1. 延迟敏感推理（P99 < 50ms）：物理隔离，专用节点
2. 中等延迟推理（P99 < 200ms）：MIG 隔离，推理占 1-2 个 MIG Instance，训练占其余
3. 离线推理：与训练混部，低优先级，利用训练空闲时间

💡 训练和推理混部的关键不是共享，而是隔离——延迟敏感推理用 MIG 硬件隔离，离线推理才考虑时间片共享。

拓扑质量评估三维度：

关键指标排序：

1. NVLink 全连接度（影响 TP 性能，权重最高）
2. InfiniBand 收敛比（影响 DP/PP 通信）
3. GPUDirect RDMA 支持（影响跨节点 TP 通信效率）
4. NUMA 一致性（影响单节点内数据搬运延迟）

💡 评估拓扑质量的核心是看通信热点——NVLink 全连接度决定 TP 上限，IB 收敛比决定跨节点通信带宽，GPUDirect RDMA 决定跨节点通信延迟。

传统路径（无 GPUDirect RDMA）：

GPU A 显存 → CPU A 内存 → NIC A → 网络 → NIC B → CPU B 内存 → GPU B 显存
   │                                                           │
   └── 2 次 PCIe 搬运 + 1 次 CPU 拷贝 ──┘── 2 次 PCIe 搬运 + 1 次 CPU 拷贝 ──┘

GPUDirect RDMA 路径：

GPU A 显存 → NIC A → 网络 → NIC B → GPU B 显存
   │                                    │
   └── 省去 CPU 中转，延迟降低 30-50% ──┘

为什么重要：

1. 降低延迟：省去 CPU 内存中转，跨节点通信延迟降低 30-50%
2. 降低 CPU 开销：CPU 不参与数据搬运，可处理其他任务
3. 提升有效带宽：减少 PCIe 往返，有效带宽提升 20-30%
4. NCCL 自动利用：NCCL 检测到 GPUDirect RDMA 支持后自动启用

💡 GPUDirect RDMA 的本质是让 GPU 绕过 CPU 直接和网络对话——省两次 PCIe 往返和一次 CPU 拷贝，对跨节点 TP 和 PP 性能至关重要。

┌──────────────────────────────────────────────────────────────┐
│                     GPU 集群调度器                              │
├──────────────┬──────────────┬──────────────┬────────────────┤
│   接入层      │   调度层      │   资源层      │   观测层       │
│              │              │              │               │
│ Job 提交 API │ Queue 管理   │ GPU 拓扑感知  │ 利用率监控     │
│ 优先级/队列  │ Gang Sched   │ 显存感知     │ 故障检测       │
│ 弹性配额     │ Backfill     │ MIG/MPS 分配 │ 训练进度追踪   │
│ Job 依赖     │ 拓扑感知排序  │ 多维度资源   │ Checkpoint    │
│              │ 优先级/抢占  │              │   管理         │
└──────────────┴──────────────┴──────────────┴────────────────┘

核心设计决策：

💡 GPU 调度器的设计核心是三个"感知"：感知 Gang 语义、感知 GPU 拓扑、感知多租户公平性。缺了任何一个，要么利用率低，要么性能差，要么团队吵。

本质区别：

1. GPU 是刚性资源：不能像 CPU 那样切毫核，一张 GPU 要么给一个 Task 要么不给，碎片化严重
2. GPU 有强拓扑约束：CPU 调度几乎不关心 NUMA，但 GPU 调度如果忽视 NVLink/IB，TP 性能可能差 10 倍
3. GPU 任务是 Gang 的：CPU 的每个 Task 独立运行，GPU 训练 Job 的所有 Pod 必须同时运行
4. GPU 抢占代价极高：CPU 抢占只需要保存寄存器，GPU 抢占需要保存几十 GB 的显存状态

💡 GPU 调度 vs CPU 调度的本质区别是四个字：刚、绑、合、重——资源刚性、拓扑绑定、Gang 聚合、抢占代价重。

模型参数：7B (7 × 10⁹)

FP16 显存占用计算：

不同策略下的单卡显存需求（假设 N 卡）：

💡 7B 模型的显存瓶颈不在参数本身（14 GB），而在 Adam 优化器状态（56 GB）——所以 ZeRO-1/2 就能解决，不需要上 TP/PP。

DCGM 全称：Data Center GPU Management，是 NVIDIA 提供的 GPU 集群管理中间件。

三层架构：

┌─────────────────────────────────────┐
│       Grafana (可视化 & 告警)        │
└───────────────┬─────────────────────┘
                │ PromQL 查询
┌───────────────▼─────────────────────┐
│       Prometheus (指标存储 & 告警)    │
└───────────────┬─────────────────────┘
                │ HTTP /metrics
┌───────────────▼─────────────────────┐
│    DCGM Exporter (指标暴露)           │
└───────────────┬─────────────────────┘
                │ NVML / DCGM API
┌───────────────▼─────────────────────┐
│    DCGM (底层 GPU 状态采集)           │
└───────────────┬─────────────────────┘
                │ GPU Driver
┌───────────────▼─────────────────────┐
│    NVIDIA GPU 硬件                    │
└─────────────────────────────────────┘

DCGM 的三种使用方式：

1. dcgmi：命令行工具，用于诊断和排查（dcgmi diag -r 3 完整诊断）
2. DCGM Exporter：Prometheus 集成，持续监控（生产环境必备）
3. DCGM API：编程接口，用于自定义监控和自动化

关键指标分组：

💡 DCGM 是 GPU 监控的基石——它不是可选的，而是必须的。没有 DCGM 的 GPU 集群就像没有仪表盘的汽车，出了问题你连原因都不知道。