一句话结论

多租户配额管理的核心是保障性（guarantee）与弹性（elasticity）的权衡：从固定配额到 ElasticQuota 再到 QAD 驱动，本质是用越来越精细的保障信号换更高利用率，再叠加 Namespace、Queue、节点、GPU 四层隔离来约束租户间干扰。

复习定位

关联模块

• GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
• LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
• Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
• 分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

一句话结论

GPU 不是可互换的——同样数量的卡在不同拓扑下通信性能差 3-5 倍，所以调度必须感知拓扑：TP 通信频率高必须放进同节点 NVLink，DP/PP 频率低可跨节点走 InfiniBand；NCCL 据此自动选最优通信路径，拓扑错配是 NCCL 超时和训练慢的常见根因。

复习定位

节点 0: [TP group 0] ← NVLink → GPU 0-7
节点 1: [TP group 1] ← NVLink → GPU 8-15
节点 2: [TP group 2] ← NVLink → GPU 16-23
节点 3: [TP group 3] ← NVLink → GPU 24-31
节点 4: [TP group 4] ← NVLink → GPU 32-39
节点 5: [TP group 5] ← NVLink → GPU 40-47
节点 6: [TP group 6] ← NVLink → GPU 48-55
节点 7: [TP group 7] ← NVLink → GPU 56-63

Pipeline 0: 节点 0 → 节点 1 → 节点 2 → 节点 3  (PP=4, P2P over IB)
Pipeline 1: 节点 4 → 节点 5 → 节点 6 → 节点 7  (PP=4, P2P over IB)

DP group 0: Pipeline 0 和 Pipeline 1 之间 AllReduce 梯度 (DP=2, over IB)

关联模块

• GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
• LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
• Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
• 分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

一句话结论

GPU 集群规模越大故障越频繁（1024 卡 MTBF 仅约 42 分钟），所以容错的目标不是防故障而是降 MTTR：靠 DCGM/Prometheus 秒级检测，靠 Checkpoint（最优频率 T*=√(2FC)）兜底进度，靠 PyTorch Elastic 弹性缩容快速恢复，小故障弹性续跑、大故障 Checkpoint 重启。

复习定位

故障与弹性

故障类型详解

GPU 集群故障远比 CPU 集群频繁——一块 A100 的 MTBF 约 24 个月，一个 1024 卡集群的平均无故障时间仅约 24 小时。理解每种故障的特征是设计容错体系的前提。

1. GPU ECC 错误

> 类比理解：ECC 就像内存的"自动纠错笔"——单比特翻转它能自己修正（可纠正），但如果一次翻转太多比特，就修不过来了（不可纠正），只能放弃这张卡。

2. NVLink 降级

> 类比理解：NVLink 降级就像高速公路突然从 8 车道变成 4 车道——车（数据）还能走，但通行时间翻倍。

3. 节点故障

4. 网络分区

5. OOM（显存溢出）

故障响应体系

检测 → 定位 → 恢复

检测工具栈

┌─────────────────────────────────────────────┐
│              Grafana Dashboard               │
│          (可视化告警 & 历史趋势)              │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│              Prometheus                       │
│     (指标采集 + 告警规则 + 数据存储)          │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│         DCGM Exporter                        │
│    (GPU 指标: 温度/ECC/显存/利用率/NVLink)    │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│            DCGM (Data Center GPU Mgmt)       │
│        (底层 GPU 状态采集 + 诊断)             │
└─────────────────────────────────────────────┘

关键指标列表：

Checkpoint 策略

Checkpoint 是 GPU 训练容错的基石——没有 Checkpoint，一次故障就可能浪费数天的训练时间。

1. 周期性 Checkpoint（Periodic）

原理：每隔 N 步或 N 分钟保存一次完整的模型状态。

实现：

# PyTorch 示例
for step, batch in enumerate(dataloader):
    loss = model(batch)
    loss.backward()
    optimizer.step()

    if step % checkpoint_interval == 0:
        torch.save({
            'step': step,
            'model_state_dict': model.state_dict(),
            'optimizer_state_dict': optimizer.state_dict(),
        }, f"checkpoint_{step}.pt")

优点：实现简单，所有框架原生支持 缺点：保存期间训练暂停（大模型 Checkpoint 可能耗时 10-30 分钟）；存储开销大

> 手动推演：假设 175B 参数模型，FP16 存储： > - 模型参数：175B × 2B = 350 GB > - 优化器状态（Adam）：175B × (2+4+4)B = 1.75 TB（含 momentum + variance） > - 单次 Checkpoint 约 2.1 TB，每次保存需 10-20 分钟 > - 如果每 1000 步保存一次，训练有效利用率降低约 2-5%

2. 异步 Checkpoint（Async）

原理：将模型状态拷贝到共享内存后立即恢复训练，由后台线程负责持久化到存储。

流程：

训练进程 ──copy──→ 共享内存 ──background──→ 持久存储
   │                                         │
   └── 立即恢复训练 ←──────────不等待──────────┘

优点：训练暂停时间极短（通常 < 1 秒） 缺点：需要额外内存（2 倍模型状态）；共享内存拷贝仍然有 CPU 开销；极端情况下可能丢失最后几个 step 的数据

3. 增量 Checkpoint（Incremental）

原理：只保存与上次 Checkpoint 相比发生变化的部分（通常是优化器状态的增量）。

优点：存储和 I/O 开销大幅降低（增量通常只有全量的 5-20%） 缺点：恢复时需要回放所有增量，恢复链越长越慢；需要管理 Checkpoint 版本链

4. 分布式 Checkpoint（Distributed）

原理：每个 Rank 只保存自己负责的分片，恢复时各 Rank 读取自己的分片即可。适用于 ZeRO 或 TP 分片场景。

优点：每个节点只写一小部分数据，I/O 并行化，保存速度快 缺点：恢复时必须保证 Rank 映射不变（或支持重映射）；需要元数据协调

> 为什么大模型必须用分布式 Checkpoint？ > 以 175B + ZeRO-3 为例，每张 GPU 只存 1/N 的参数。如果每张卡独立保存自己的分片，单卡 I/O 仅约 350GB/N。假设 N=1024，每卡仅 ~350 MB，保存时间从分钟级降到秒级。

Checkpoint 策略选择

> 实践建议：生产环境通常组合使用——异步 + 分布式 + 定期全量（作为增量基线）。

Checkpoint 频率的数学推导

核心问题：多久保存一次 Checkpoint 最优？

建模：

• C = 单次 Checkpoint 的开销（保存时间）
• F = 平均故障间隔（MTBF）
• t = 每步训练时间
• T = 两次 Checkpoint 之间的训练时间

推导：

- C/T：Checkpoint 的稳态开销 - T/(2F)：故障导致的平均进度丢失

1. 每次 Checkpoint 浪费 C 的时间
2. 故障发生时，平均丢失 T/2 的训练进度
3. 单位时间的总浪费 = (C/T) + (T/(2F))

`` d/dT [C/T + T/(2F)] = -C/T² + 1/(2F) = 0 T² = 2FC T* = √(2 × F × C) ``

1. 对 T 求导令其为零：

手动验证：

• F = 24 小时，C = 15 分钟
• T* = √(2 × 24 × 15) = √720 ≈ 26.8 分钟
• 即约每 27 分钟保存一次 Checkpoint 最优
• 对应步数：如果每步 2 秒，则约每 800 步保存一次

> 面试金句：「Checkpoint 频率的最优解是 T* = √(2FC)，本质上是在 Checkpoint 固定开销和故障导致的进度丢失之间找平衡点。」

弹性训练

PyTorch Elastic / torchrun

核心思想：允许训练过程中动态改变 world_size（GPU 数量），故障时自动缩容继续训练，新节点加入时自动扩容。

关键组件：

Rendezvous 流程（手动推演）：

初始: 8 GPU (world_size=8), Rank 0-7

Step 1: Rank 3 故障
  └── Watchdog 检测到 Rank 3 心跳超时

Step 2: 触发 Rendezvous
  ├── 存活 Rank [0,1,2,4,5,6,7] 进入 Rendezvous
  ├── 等待 min_nodes=6（最少需要 6 个节点才能继续）
  └── 新 world_size = 7

Step 3: 状态重分配
  ├── 从最近 Checkpoint 恢复模型状态
  ├── 数据集按 7 份重新分片
  └── 优化器状态重新分配（ZeRO 场景）

Step 4: 继续训练
  └── 从 Checkpoint 对应的 step 继续训练

torchrun 启动示例：

torchrun \
  --nnodes=4:8 \        # 最少 4 节点，最多 8 节点
  --nproc_per_node=8 \  # 每节点 8 GPU
  --rdzv_id=job-001 \   # Rendezvous ID
  --rdzv_backend=c10d \ # 协调后端
  --rdzv_endpoint=master:29500 \ # 协调地址
  train.py

关键参数解释：

• nnodes=4:8：弹性范围，最少 4 节点才能启动/继续，最多接受 8 节点
• rdzv_id：同一训练 Job 的所有 Worker 必须使用相同的 ID
• rdzv_backend：c10d（内置 TCP）、etcd（生产推荐，支持持久化）

弹性 vs 非弹性对比

弹性训练的局限

1. BatchNorm 兼容性：world_size 变化导致 global batch size 变化，BN 统计量不一致 → 需使用 SyncBN 或改用 LayerNorm
2. 学习率调整：线性缩放规则 lr = base_lr × batch_size / 256，batch size 变化时需要相应调整学习率
3. 数据分片：需要可重新分片的数据加载器（如 DistributedSampler 的 drop_last=False）
4. ZeRO 重分片：优化器状态需要按新的 world_size 重新分片，实现复杂
5. 调度器配合：需要调度器支持弹性配额（如 ElasticQuota），否则缩容后的资源可能被抢占

> 面试金句：「弹性训练的核心挑战不是技术实现，而是 world_size 变化带来的语义一致性——BatchNorm、学习率、梯度累积步数都需要适配。」

面试问答

Q1: 一个 1024 卡的 GPU 集群，故障率大约是什么量级？你会怎么设计高可用？

核心回答：

单卡 MTBF 约 24 个月，1024 卡集群的 MTBF ≈ 24/1024 月 ≈ 42 分钟。这意味着训练过程中几乎必然会遇到故障。

高可用设计层次：

1. 检测层：DCGM + Prometheus + NPD，秒级发现异常
2. 容错层：异步分布式 Checkpoint，频率按 T* = √(2FC) 计算
3. 恢复层：弹性训练（PyTorch Elastic），自动缩容继续
4. 隔离层：故障节点自动标记 unschedulable，防止新 Pod 调度上去
5. 预防层：定期 dcgmi diag 体检，提前发现 ECC 错误趋势和温度异常

为什么这样设计：高可用的核心不是"不故障"（不可能），而是"故障后快速恢复"。关键指标是 MTTR（平均恢复时间），而非 MTBF。

面试金句：「1024 卡集群的 MTBF 约 42 分钟，所以高可用的核心不是防故障，而是降 MTTR——检测快、Checkpoint 密、弹性恢复。」

---

Q2: Checkpoint 的最优保存频率怎么算？实际中你怎么定？

核心回答：

理论最优频率 T* = √(2 × F × C)，其中 F 是 MTBF，C 是单次 Checkpoint 耗时。

手动推演：

• 假设 F = 24h（256 卡集群），C = 10min（异步分布式 Checkpoint）
• T* = √(2 × 1440 × 10) = √28800 ≈ 170 min ≈ 2.8 小时

实际调整：

1. 不能比理论值更频繁：否则 Checkpoint 开销占比过高
2. 可以比理论值稍稀疏：如果训练对断点丢失容忍度低（如预训练），宁可多保存
3. 关键节点必保存：epoch 边界、学习率衰减点、验证指标最佳点
4. 生产实践：通常按步数（如每 1000 步）保存，按时间（如每 2 小时）做全量 Checkpoint

为什么这样设计：T* 是数学最优解，但实际还需考虑存储成本、I/O 瓶颈、业务容忍度。

面试金句：「Checkpoint 频率本质是 Checkpoint 开销和故障损失的帕累托最优——T* = √(2FC) 是数学最优，实际中还需叠加业务约束。」

---

Q3: 弹性训练和 Checkpoint 恢复各自的适用场景？

核心回答：

选择原则：

• 少量节点故障 → 弹性训练（缩容继续，不浪费剩余 GPU）
• 大规模故障 / 网络分区 → Checkpoint 恢复（等环境恢复后统一重启）
• 预训练（容忍弱一致性） → 优先弹性训练
• 精调 / 对齐（需要强一致性） → 优先 Checkpoint 恢复

为什么这样设计：弹性训练的"弱确定性"对大规模预训练几乎无影响（数据量大，几个 batch 的 BN 偏差可忽略），但对精调和小数据集可能显著影响收敛。

面试金句：「弹性训练和 Checkpoint 恢复不是互斥的，而是互补的——小故障弹性恢复，大故障 Checkpoint 兜底。」

---

Q4: 设计一个 GPU 集群的故障自动恢复系统

核心回答：

┌─────────────────────────────────────────────────────┐
│                   故障自动恢复系统                      │
├────────────┬────────────┬────────────┬──────────────┤
│  检测层     │  决策层     │  执行层     │  验证层      │
│            │            │            │             │
│ DCGM指标   │ 故障分类器  │ 节点隔离    │ 恢复验证     │
│ 心跳监控   │ 恢复策略    │ Pod 驱逐    │ 训练一致性   │
│ NCCL超时   │ 优先级排序  │ 弹性缩容    │ 指标回归     │
│ NPD事件    │ 并发控制    │ Checkpoint  │ 健康检查     │
│            │            │   恢复      │             │
└────────────┴────────────┴────────────┴──────────────┘

决策逻辑：

1. 单卡故障 → 弹性缩容（排除故障卡，继续训练）
2. 节点级故障 → 弹性缩容 + 新节点调度（如果有空闲节点）
3. 网络分区 → 缩小训练规模到同一分区内
4. 大规模故障（> 50% 节点） → 暂停训练，等待恢复后 Checkpoint 重启

关键设计决策：

• 故障分级：不是所有故障都需要同样的响应——ECC 可纠正错误只需记录，不可纠正才需要驱逐
• 恢复优先级：小任务优先恢复（恢复快，影响面小），大任务可以排队等资源
• 防抖动：故障确认需要连续 N 次检测失败（防止网络抖动导致误判）
• 人工兜底：连续故障超过阈值时，自动通知运维介入

面试金句：「故障恢复系统的核心不是技术复杂度，而是决策逻辑——什么故障用什么策略，什么规模走什么流程，需要有清晰的分级响应机制。」

---

Q5: 如何监控一个 GPU 集群？你会关注哪些指标？

核心回答：

三层监控体系：

关键告警规则：

1. GPU 温度 > 85°C → 可能散热故障
2. ECC 不可纠正错误 > 0 → 需要驱逐该 GPU
3. GPU 利用率 < 10% 且持续 5 分钟 → 可能卡死或通信死锁
4. NVLink CRC 错误持续增长 → 物理链路问题
5. Pending Pod > 阈值 → 资源不足或调度策略问题
6. 训练 Loss NaN → 学习率过大或数据问题

为什么这样设计：三层监控覆盖从硬件到业务的全链路——基础设施层发现物理故障，训练层发现性能异常，调度层发现资源瓶颈。

面试金句：「GPU 监控的核心不是指标多，而是三层联动——硬件异常要能追溯到训练影响，训练瓶颈要能定位到硬件根因。」

关联模块

• GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
• LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
• Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
• 分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

一句话结论

GPU 集群管理面试题可归到一条主线：K8S 默认调度器无 Gang、无公平、无拓扑，需在 Scheduling Framework 上扩展，靠 Gang + Backfill、弹性配额、拓扑感知（TP 锁 NVLink）和 Checkpoint/弹性恢复，把刚性、强拓扑、Gang 聚合、抢占代价重的 GPU 资源从 30-40% 利用率拉到 70%+。

复习定位

面试问答

调度框架方向

Q1: K8S 默认调度器为什么不适合 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 上做扩展，而不是替换调度器。」

---

Q2: Volcano 的 Gang Scheduling 是怎么实现的？有什么缺陷？

核心回答：

实现机制：

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. 粗粒度：只有全部调度或全部不调度，没有部分调度 + 排队的中间态

改进方案：

• Coscheduling：用队列替代 Gang，Job 进入队列排队，资源足够时一次性调度
• Elastic Gang：minMember 支持范围（如 min=4, max=8），根据资源弹性调度
• Backfill：小 Job 填充 Gang 等待期间的空闲资源

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

---

多租户方向

Q3: GPU 集群的资源利用率通常只有 30-40%，你会怎么优化？

核心回答：

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

1. 调度维度（贡献最大，可提升 20-30%）：

• Gang + Backfill：大 Job Gang 等待期间，Backfill 小 Job 填充碎片
• 拓扑感知：减少跨节点 TP，提升通信效率 → 提升有效计算时间占比
• 优先级 + 抢占：低优先级 Job 被抢占后释放资源给高优先级 Job

2. 多租户维度（可提升 10-20%）：

• ElasticQuota：空闲配额自动共享，避免"我的配额我用不完，你的配额你不够用"
• 分时复用：训练（夜间批处理）和推理（白天在线）分时共享 GPU

3. 共享维度（可提升 10-15%）：

• MIG：大卡切小卡，推理/小模型训练复用同一张 GPU
• MPS：多进程共享 GPU，适合推理场景
• 时间片：GPU 时间片调度（如 Run:ai），适合轻量级任务

4. 业务维度（可提升 5-10%）：

• 自动 Batch Size 调优：避免显存浪费
• 自动混合精度：FP16 训练，减少显存占用
• Gradient Checkpointing：用计算换显存

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

---

Q4: 训练和推理混部时，如何保证推理的延迟不受训练影响？

核心回答：

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

隔离方案（从强到弱）：

推荐方案：

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

关键细节：

• MIG 的 Instance 之间有硬件级隔离，训练的显存溢出不会影响推理
• MPS 没有硬件隔离，需要通过 CUDA_MPS_ACTIVE_THREAD_PERCENTAGE 限制训练的 GPU 时间片占比
• 时间片方案需要监控推理延迟，超过阈值时暂停训练任务

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

---

拓扑方向

Q5: 如何评估一个 GPU 集群的拓扑质量？哪些指标最重要？

核心回答：

拓扑质量评估三维度：

- NVLink 全连接度：8 卡 A100 有 6 条 NVLink/GPU，是否全连接？ - NVSwitch 有无：有 NVSwitch 则任意两卡间带宽一致（900 GB/s）；无则部分卡对带宽低 - PCIe 拓扑：GPU 是否挂在同一个 NUMA Node？跨 NUMA 访问有 20-30% 性能损失

1. 节点内拓扑质量：

- InfiniBand 网络：是否是 Fat-Tree 拓扑？是否有收敛比？（1:1 无收敛最优） - GPU 直连：是否支持 GPUDirect RDMA？（减少一次 CPU 拷贝，延迟降低 30-50%） - 网络带宽：HDR (200 Gbps) vs NDR (400 Gbps)？

1. 节点间拓扑质量：

- 所有节点是否同构？（不同型号 GPU 混部会导致负载不均） - 网络是否对称？（某些节点对之间带宽不一致会导致 AllReduce 性能下降）

1. 全局拓扑一致性：

关键指标排序：

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

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

---

Q6: 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 支持后自动启用

前提条件：

• 网卡支持 RDMA（InfiniBand 或 RoCE）
• GPU 支持 GPUDirect（A100+ 原生支持）
• 驱动和 NCCL 版本匹配

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

---

综合方向

Q7: 设计一个 GPU 集群调度器，你会怎么设计？

核心回答：

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

核心设计决策：

- 原因：保持 K8S 兼容性，复用 Pod 调度能力，降低维护成本

1. 架构选择：Scheduling Framework 扩展（不替换 kube-scheduler）

- Gang：保证训练 Job 的 All-or-Nothing 语义 - Backfill：填充 Gang 等待期间的碎片资源，提升利用率

1. Gang + Backfill：

- GPU 数量 + 显存 + NVLink 拓扑 + InfiniBand 带宽 - 不只是"GPU 数量"，还要考虑拓扑约束

1. 多维度资源模型：

- ElasticQuota（min/max），空闲配额自动共享 - QAD 驱动：保障各团队的 QAD > 0.8

1. 弹性配额：

- TP 组 → 同节点 NVLink 全连接 - PP 组 → 相邻节点（IB 直连） - DP 组 → 拓扑不敏感，跨机架即可

1. 拓扑感知调度：

- 集成 PyTorch Elastic，支持弹性缩容 - 异步分布式 Checkpoint，T* = √(2FC)

1. 故障自恢复：

为什么这样设计：

• Scheduling Framework 扩展 → 最小侵入 K8S
• Gang + Backfill → 兼顾训练语义和利用率
• 多维资源 → 匹配 GPU 拓扑约束
• 弹性配额 → 解决多租户公平性

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

---

Q8: GPU 调度和 CPU 调度有什么本质区别？

核心回答：

本质区别：

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 聚合、抢占代价重。」

---

Q9: 一个 7B 模型需要多少 GPU 资源？请详细计算

核心回答：

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

FP16 显存占用计算：

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

生产推荐：

• 训练：2-4 × A100-80G + ZeRO-2，显存充裕，通信量低
• 推理：1 × A100-80G，14 GB 参数 + KV Cache，单卡足够
• 微调 (LoRA)：1 × A100-80G，只训练少量参数，显存绰绰有余

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

---

Q10: 你提到了 DCGM，能详细说说 GPU 监控体系吗？

核心回答：

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：编程接口，用于自定义监控和自动化

关键指标分组：

生产实践：

• 每 15 秒采集一次指标（Prometheus scrape_interval）
• ECC 不可纠正错误 → 自动驱逐 Pod
• 温度 > 85°C → 告警 + 降低频率
• GPU 利用率持续 < 10% → 可能卡死，需要检查

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

关联模块

• GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
• LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
• Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
• 分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。