Scheduling Theory

任务调度理论

目标函数 · 经典算法 · 多资源公平 · 批调度 · 拓扑感知 · 面试题精讲

schedulingtheoryfairnessbatchtopology

Module Switcher

任务调度理论

理论基础2

公平性与批调度2

AI 集群与面试2

内容模块

经典调度算法

基础★☆☆⏱ 15 min

一句话结论

经典调度算法（FIFO/SJF/SRTF/EDF/RR/优先级）是所有调度系统的排序基础，关键不是背名字，而是说清每个算法的最优条件、失败条件，以及在 GPU 集群里如何分成"排序层（谁先被考虑）+ 放置层（放到哪里，Bin Packing vs Spread）"组合使用。

复习定位

维度	内容
所属模块	任务调度理论
章节类型	系统类
解决问题	围绕经典算法、多资源公平、Gang/Backfill、拓扑感知和抢占代价建立 GPU 集群调度理论答案。
面试抓手	回答时先定范围，再讲核心链路，最后落到工程风险和面试追问。

经典调度算法：从直觉到数学

经典调度算法是所有调度系统的基础。不管你用的是 K8S 默认调度器、Volcano 还是自研调度器，底层的排序逻辑一定逃不出这几个经典算法的思想。面试中，面试官期望你不只是知道算法名字，还能说清楚：为什么这个算法最优？最优的条件是什么？在什么条件下它会失败？

操作系统算法到 AI 集群调度的映射

FIFO、SJF、Round Robin、优先级、CFS 这些名字来自操作系统，但在 AI Infra 里会变成队列排序、准入控制、租户公平、抢占和节点放置策略。学习时建议把它们分成两层：排序层决定“谁先被考虑”，放置层决定“放到哪里”。

OS 调度概念	核心含义	集群调度中的对应物	AI Infra 注意点
FIFO / FCFS	按到达顺序执行	队列按提交时间排序	大 gang 任务可能造成 head-of-line blocking
SJF	短任务优先	短实验、短 inference batch、短 pipeline stage 优先	需要运行时长预测，长任务要配 aging 防饥饿
Round Robin	时间片轮转	队列/租户轮转，按 ClusterQueue 轮转取任务	GPU 任务不适合频繁时间片切换，但适合队列级轮转
优先级调度	高优先级先执行	PriorityClass、Queue priority、抢占	低优任务要有 aging 或保障份额，否则会长期饥饿
CFS	按虚拟运行时间实现公平份额	按 dominant share、quota debt 或保障度做公平调度	多资源场景不能只按 GPU 数公平，要看 CPU/内存/GPU/NIC 的主导资源

基础调度策略详解

1. FIFO（First In First Out）

定义：先到的任务先调度。不看任务大小、不看优先级、不看紧急程度。

怎么理解：超市排队。先来先结账，不管你买 1 件还是 100 件。

优点：实现最简单，不需要任何预测信息（不需要知道任务运行多久），天然公平（按到达顺序）。

致命问题：Head-of-line blocking：如果队首是一个 10 小时的训练任务，后面 100 个 5 分钟的实验任务全部被阻塞。

面试中怎么答：FIFO 是所有调度器的默认起点。面试时不要说"FIFO 不好"——要说"FIFO 在什么场景下够用，什么场景下不够"。对于同质任务（运行时间差不多），FIFO 就够了。对于异质任务（短实验 + 长训练），FIFO 的 head-of-line blocking 就不可接受了。

2. SJF（Shortest Job First）

定义：运行时间最短的任务优先调度。不可抢占——一旦开始就必须跑完。

核心性质：SJF 最小化平均等待时间

直觉证明：假设队列里有任务 A(1h) 和 B(10h)。如果先 A 后 B：A 等 0h，B 等 1h，平均等待 = 0.5h。如果先 B 后 A：B 等 0h，A 等 10h，平均等待 = 5h。短任务排前面，它们的等待时间短（因为本身短），长任务无论排哪里都要等，放后面只增加一个"短任务的执行时间"。所以短任务优先永远不劣。

致命问题：饥饿：如果短任务源源不断到达，长任务可能永远排不上。

前提条件：必须知道任务的运行时间。在 GPU 集群里，用户声明、历史统计或在线预测可以提供这个信息。

面试中怎么答：面试官问"为什么 SJF 最优"，你应该：(1) 说"它最小化平均等待时间"；(2) 用简单的数字例子说明；(3) 补"但它会导致饥饿，需要 aging 或配额保障来缓解"。

3. SRTF（Shortest Remaining Time First）

定义：SJF 的抢占版本。按剩余时间排序，新来的短作业可以打断正在执行的长作业。

和 SJF 的本质区别：SJF 按总执行时间排序，任务一旦开始就不可中断。SRTF 按剩余时间排序，每当新任务到达时重新排序，可以抢占。

什么时候比 SJF 更好：当任务到达时间不确定时。例如多 agent 工作流中，不断有新 stage 到达。SRTF 可以让新来的短 stage 立即执行，避免被正在执行的长 stage 阻塞。

额外代价：(1) 需要抢占机制；(2) 需要更精确的剩余时间预测；(3) 抢占本身的成本（训练任务可能需要回滚到 checkpoint）。

怎么理解：SJF 像"餐厅只接受预约，上桌了就不赶人走"。SRTF 像"急诊室分诊——新来了更急的病人，正在处理的可以先放一放"。

4. EDF（Earliest Deadline First）

定义：截止时间最近的任务优先调度。可抢占。

适用场景：有明确 deadline 的任务。如实时系统、数据 Pipeline（"明早 8 点前必须跑完"）、模型发布倒计时。

最优性：在任务可抢占且 deadline 可知的前提下，EDF 是最优的——如果 EDF 都调不了，没有任何算法能调。

局限：(1) 需要知道 deadline；(2) 系统过载时，所有接近 deadline 的任务会"集体崩溃"；(3) GPU 训练任务通常没有明确的 deadline，所以 EDF 在 GPU 集群中用得少。

怎么理解：EDF 像"赶飞机"——谁离登机时间最近谁先走安检。

5. Round Robin

定义：每个任务分配一个时间片，时间片用完就换下一个任务。循环往复。

优点：绝对公平——每个任务获得相等的 CPU 时间。

局限：(1) 上下文切换开销大——GPU 训练任务切换代价极高（模型加载 + NCCL 重建），不适合频繁切换；(2) 时间片大小难选——太小浪费切换时间，太大又退化成 FIFO。

GPU 集群里几乎不用：因为 GPU 任务不能"切一小段就换"。但"按队列轮转调度"的思想（如 Kueue 的 ClusterQueue 轮转）是 Round Robin 的变体。

6. 优先级调度

定义：按静态或动态优先级排序调度。优先级可以基于业务重要性、紧急程度、资源效率等。

静态 vs 动态优先级：静态优先级在提交时确定，运行中不变。动态优先级可以变化——例如 aging（等待越久优先级越高）、或者基于 QAD（保障度低的队列优先级提升）。

问题：低优先级任务可能饥饿。需要 aging 或配额保障来缓解。

算法对比与选择

算法	可抢占	需要预测	最优性	饥饿风险	GPU 集群适用性
FIFO	否	否	同质任务最优	无	默认基线
SJF	否	是（运行时间）	最小化平均等待	长任务饥饿	短实验优先场景
SRTF	是	是（剩余时间）	最小化平均等待	长任务饥饿	多 agent 工作流
EDF	是	是（deadline）	实时最优	过载崩溃	Pipeline 场景
Round Robin	是	否	公平最优	无	几乎不用
优先级	可选	否	取决于优先级设定	低优先级饥饿	最常用

实际系统的组合策略

真实调度器不会只用一个算法，而是组合使用：

排序阶段

优先级 + SJF，同优先级内按运行时间排序

准入阶段

Gang 检查 + Quota 检查

放置阶段

Bin Packing + 拓扑打分

抢占阶段

优先级 + 代价感知

面试中，你要说清楚"每个决策点用了哪个算法的什么思想"，而不是笼统地说"用了 SJF"。

Bin Packing vs Spread

这是放置策略的经典对比，面试中经常出现。

Bin Packing

定义：尽量把任务塞到已有节点，减少碎片。它来自装箱问题：给定一批物品和若干箱子，希望用尽可能少的箱子装下所有物品。在调度里，物品是 Pod/Job 的资源需求，箱子是 Node 或资源池。

类比：装箱——先把一个箱子装满，再开新的。

GPU 集群为什么常用：GPU 是昂贵资源，碎片化（节点 A 剩 1 GPU，节点 B 也剩 1 GPU，但需要 2 GPU 的任务放不进去）是最大浪费。Bin Packing 尽量让某些节点跑满，留出完整的空闲节点给大 gang。

风险：(1) 单节点故障影响更多任务（爆炸半径大）；(2) 热点——某些节点过于拥挤。

Bin Packing 在调度器里怎么实现

层次	做法	直觉	风险控制
Filter	过滤放不下 CPU/内存/GPU/端口/拓扑约束的节点	先保证可行	不要为了装箱破坏硬约束
Score	给“放入后剩余资源更少、更紧凑”的节点更高分	优先填满已有节点	加入温度、故障域、拓扑质量权重
Reserve	暂存被选节点上的资源占用	避免并发调度重复占用	失败时必须 Unreserve
全局队列	把小任务回填到碎片，把大任务留完整资源窗口	减少碎片累积	配合 backfill 和 aging 避免大任务/小任务互相伤害

Spread

定义：尽量把任务分散到不同节点。

类比：分散投资——不把鸡蛋放在一个篮子里。

适用场景：在线推理服务——需要高可用，节点挂了不能影响所有副本。

风险：碎片化——每个节点都剩一点 GPU，但凑不出大块。

选择建议

场景	推荐策略	原因
离线训练	Bin Packing	减少碎片，大 gang 更容易放得下
在线推理	Spread	高可用，单节点故障影响小
混合部署	推理 Spread + 训练 Bin Packing	不同任务类型用不同策略
多租户实验平台	Bin Packing + 故障域约束	减少碎片但避免单点故障

经典算法面试问答

Q: Head-of-line blocking 怎么解决？

核心回答

三种思路：

预测驱动排序：SRTF/SJF 让短任务先执行，减少被长任务阻塞的概率。这解决的是"队首长任务阻塞后面短任务"的问题。
抢占：长任务阻塞时强制让位给高优先级任务。这解决的是"正在执行的任务不能被打断"的问题。
多队列：不同类型任务分开排队，互不干扰。这解决的是"不同类型任务对延迟要求不同"的问题。

组合使用

实际系统中常常同时使用多种：SRTF 排序 + 抢占 + 分队列。例如 K8S 调度器有多个 Queue（ActiveQ、BackoffQ、UnschedulableQ），在 ActiveQ 内部按优先级排序，高优先级任务可以触发 preemption。

面试要点：三种思路各有适用场景，实际系统是组合使用的。

Q: SJF 为什么最优？会有什么问题？

最优性证明（直觉版）

SJF 最小化平均等待时间。把短任务排前面，它们的等待时间短（因为本身短，不会让后面等太久）。长任务无论排哪里都要等前面的任务，放后面只增加一个"短任务的执行时间"，放前面却让所有后面的人都多等它的长时间。所以短任务优先永远不劣。

问题：饥饿

如果短任务源源不断到达，长任务可能永远排不上。一个训练 20 小时的大任务，如果前面总有 5 分钟的实验任务插队，它可能等一天都启动不了。

解决

(1) Aging：等待时间越长优先级越高。等了 N 小时的长任务优先级会超过刚到的短任务。(2) 配额保障：每个租户至少获得一定比例的调度机会。(3) 词典序排序：先看保障度（是否满足配额），再看运行时间。保障度不足的任务优先，同保障度内按 SJF 排序。

面试要点：说清楚最优性 + 饥饿问题 + 三种解决思路。不要只说"SJF 最优"而忽略饥饿。

Q: 抢占的代价有哪些？怎么降低？

代价

(1) 进度浪费：被抢占作业已完成的计算全部丢失（除非有 checkpoint）。一个训练了 20 小时、3 小时没 checkpoint 的任务被抢占，回滚到 17 小时前的状态。(2) 重启开销：重新排队、加载模型/数据、重建 NCCL 通信组——可能需要 5-30 分钟。(3) 系统开销：保存状态、清理资源、通知相关组件。

降低代价

(1) Checkpoint 机制：定期保存进度，减少进度损失。代价是 I/O 开销。(2) 代价基抢占：选择沉没成本最小的牺牲者——checkpoint 新鲜、运行时间短的任务优先被抢占。(3) 在自然间隔抢占：在 stage 边界、epoch 结束时抢占，进度损失为零。需要训练框架配合。(4) 优雅终止：通知任务"请 checkpoint 后退出"，给 5 分钟优雅期。(5) 弹性训练：缩减 world size 而非杀掉整个任务，释放部分 GPU 但训练继续。

面试要点：抢占不是免费的。列出具体代价，再给出具体降低方案，比只说"可以做抢占"更有区分度。

Q: 多维资源调度的挑战？

核心回答

GPU 集群的资源是多维的——CPU、内存、GPU、网络带宽。三个核心挑战：

碎片化：某些维度剩余很多，但另一个维度不够，整个节点不可用。例如一个节点剩 7 GPU 但内存用完了，那 7 GPU 也是浪费的。
耦合性：GPU 任务通常也需要大量 CPU 做数据预处理。一个任务分配了 8 GPU 但 CPU 不够，数据加载跟不上，GPU 在等数据。
异构性：不同 GPU 型号性能差异大。1 张 H100 ≈ 4 张 V100，但调度器可能只看到"1 张 GPU"。

解决思路

DRF 从理论上解决公平性，但实际中还需要拓扑感知（NVLink 拓扑）、亲和性约束（CPU-GPU NUMA）和异构资源表达（GPU flavor）。

面试要点：多维资源调度的核心挑战是"碎片化 + 耦合性 + 异构性"，不是简单地"维度多了"。

Q: 调度延迟和调度质量的 trade-off？

核心矛盾

更好的调度决策需要更多信息（拓扑、负载预测、历史数据）和更多计算（更复杂的打分函数），但用户不想等太久——任务提交后应该尽快开始。

四种解决方式

(1) 两阶段调度：Filter 快速排除明显不行的（几十毫秒），Score 只在少量候选中精选（几百毫秒）。大部分节点在 Filter 阶段就被淘汰了。(2) 缓存：Informer 本地缓存节点和 Pod 信息，避免每次调度都查 API Server。(3) 近似算法：不需要最优解，"足够好"就行。例如只对 top-K 候选节点做详细打分。(4) 异步：Bind 阶段异步执行，不阻塞下一个 Pod 的调度周期。调度器和 binder 是并行工作的。

K8S 的实际做法

K8S scheduler 的一个 scheduling cycle 约 10-100ms。它用 Informer cache + 两阶段 Filter/Score + 异步 Bind 来保证延迟可接受。

面试要点：调度是"质量 vs 延迟"的 trade-off，K8S 用缓存 + 两阶段 + 近似 + 异步来平衡。

Q: 面试官问"你怎么选择调度算法"，怎么回答？

回答框架

不要说"我选 XX 算法"，而要说"我根据场景选择"：

先定场景：推理/训练/实验平台？不同场景对延迟、吞吐、公平性的要求不同。
再看约束：是否有 gang 需求？是否有 deadline？是否需要预测运行时间？
然后选排序策略：同质任务用 FIFO，异质任务用优先级 + SJF，有 deadline 用 EDF。
最后说组合：实际系统是组合使用的——排序用 SJF/DRF，准入用 Gang/Quota，放置用 Bin Packing + 拓扑打分，抢占用代价感知。

面试金句

"调度算法的选择不是非此即彼，而是根据场景在经典算法的基础上组合和调整。关键是说清楚每个决策点用了什么思想、为什么这样选。"

关联模块

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

内容模块

目标函数与评价指标

基础★☆☆⏱ 12 min

一句话结论

调度本质是多目标优化问题，学算法前要先想清楚优化什么：Waiting Time、JCT、Makespan、Throughput、Utilization、Fairness、SLO violation、Preemption Cost 各代表不同视角，而且互相冲突（公平 vs 利用率、短作业优先 vs 长作业饥饿、拓扑最优 vs 调度延迟），所以要按场景先定硬约束再定优化目标——在线推理把 SLO 当硬约束，离线训练优化 JCT 和利用率。

复习定位

维度	内容
所属模块	任务调度理论
章节类型	系统类
解决问题	围绕经典算法、多资源公平、Gang/Backfill、拓扑感知和抢占代价建立 GPU 集群调度理论答案。
面试抓手	回答时先定范围，再讲核心链路，最后落到工程风险和面试追问。

为什么调度要先定目标函数

很多人学调度会直接跳到算法——"怎么排序、怎么打分、怎么抢占"。但调度本质上是一个多目标优化问题：你在优化某个指标的同时，必然在牺牲另一个指标。如果不确定优化什么，算法就无从谈起。

举个例子：同样的集群，如果你优化平均 JCT，短作业优先（SJF）是最好的；但如果你优化公平性，SJF 会让长作业饥饿。两个目标都合理，但策略完全不同。

所以学调度的第一步，不是学算法，而是搞清楚每个指标衡量什么、谁在用它、它和别的指标怎么冲突。

核心指标详解

1. Waiting Time（等待时间）

定义：从任务提交到任务开始执行的时间。注意是"开始执行"，不是"执行完毕"。

为什么重要：它衡量的是用户感知的响应速度。一个实验提交后等了 2 小时才开始跑，体验就很差。对于交互式任务、开发调试和在线推理，等待时间是最直接的体验指标。

面试中怎么用：当面试官问"你的调度器如何改善用户体验"，如果你的系统侧重排队策略，waiting time 就是你最该展示的指标。但要注意，降低等待时间不等于降低 JCT——一个任务可能等 1 分钟就启动了，但跑了 10 小时。

怎么理解：想象你在超市排队。Waiting time 就是你从拿号到开始结账的时间。前面人少就快，前面有个人买了一整车东西就慢。SJF 相当于"买得少的人先结账"。

2. JCT（Job Completion Time）

定义：从任务提交到任务完成的总时间 = waiting time + execution time。

为什么重要：对于离线训练、批处理和 HPC 任务，用户最关心的是"我什么时候能拿到结果"，而不是"什么时候开始跑"。JCT 是 AI 训练调度论文里最常用的指标。

面试中怎么用：面试官问"你的调度策略对训练任务有什么好处"，你应该从 JCT 切入，但要分解成 waiting time 和 execution time 分别说明。例如拓扑感知调度不改变等待时间，但通过减少通信开销来降低 execution time，从而降低 JCT。

怎么理解：JCT = 排队时间 + 跑的时间。改善排队靠排序和准入策略，改善跑的时间靠拓扑放置和资源分配。

3. Makespan

定义：一批任务中，最后一个完成的时间。衡量的是"整批活什么时候干完"。

为什么重要：在批处理场景下，运维更关心"这批任务什么时候全部跑完"而不是单个任务体验。例如一个数据 Pipeline 要在明早 8 点前跑完，makespan 就是关键指标。

面试中怎么用：问"你怎么衡量一个批调度系统的效率"时，makespan 是答案之一，但要补一句——它和公平性冲突，因为最优 makespan 可能意味着某些任务被无限推迟。

怎么理解：Makespan 是站在管理员视角，JCT 是站在用户视角。两个视角对"好调度"的定义不同。

4. Throughput（吞吐量）

定义：单位时间内完成的任务数，或单位时间内处理的 token/images 数。

为什么重要：集群运营商和平台团队最关心吞吐，因为它直接对应资源产出效率。同样 100 张 GPU，如果调度策略能让每天完成的训练任务数从 50 增加到 80，相当于节省了 37.5% 的硬件成本。

面试中怎么用：不要把吞吐和利用率混淆——吞吐是产出，利用率是资源使用率。高利用率不一定意味着高吞吐（可能在跑低效任务），但低利用率通常意味着吞吐也不高。

怎么理解：吞吐 = 集群的"产出速度"。利用率 = 集群的"忙碌程度"。忙碌不等于高效。

5. Utilization（资源利用率）

定义：已使用资源 / 总资源。常见的有 GPU 利用率、CPU 利用率、内存利用率、网络带宽利用率。

为什么重要：GPU 利用率是 AI Infra 里最常被关注的指标。一个 8 卡 A100 节点的 GPU 利用率如果只有 30%，意味着 70% 的算力在闲置，而一张 A100 售价超过 1 万美元。

常见误区：高利用率 ≠ 好调度。如果一个调度器把所有任务都塞到少数节点上，利用率确实高，但可能牺牲了拓扑质量、公平性或故障隔离。利用率是一个"不该太低，但也不是越高越好"的指标。

面试中怎么用：当面试官问"怎么提高 GPU 利用率"，你应该先问"什么类型的任务"。在线推理可以通过 continuous batching 提高；离线训练可以通过 bin packing 减少碎片；GPU sharing 可以让小任务合用一张卡。但每种方法都有代价——bin packing 可能增加故障爆炸半径，GPU sharing 可能有性能干扰。

6. Fairness（公平性）

定义：不同用户或团队之间资源分配的均衡程度。常用指标包括 dominant share 的基尼系数、max-min fairness 偏差、SLO violation 率等。

为什么重要：多租户 GPU 集群里，如果只用 throughput 做目标，调度器会偏向"资源效率高"的大团队，小团队的任务可能永远排不上。公平性保证每个团队都能获得合理份额。

面试中怎么用：公平性通常和利用率冲突。面试时要说明"怎么定义公平"比"要不要公平"更重要。是按 GPU 数量公平，还是按 dominant share 公平，还是按配额保障度公平？不同的定义会导致不同的策略。

怎么理解：公平不是均分。团队 A 有 100 个 researcher，团队 B 有 5 个 researcher，均分 50/50 对 B 来说过于慷慨。按人头、按配额、按保障度是三种不同的公平定义。

7. SLO Violation Rate（服务等级违约率）

定义：不满足服务等级目标（如延迟 P99 < 200ms、任务 24h 内完成）的请求或任务比例。

为什么重要：在线推理场景下，SLO 是最核心的约束。GPU 调度不能只追求利用率，而要保证推理服务的 tail latency 满足 SLO。

面试中怎么用：如果面试官问"在线推理和离线训练怎么混部"，SLO violation rate 就是衡量混部是否成功的指标。推理的 SLO 是硬约束，训练可以弹性让步。

8. Preemption Cost（抢占代价）

定义：抢占一个正在运行的任务所造成的进度损失、重启成本和系统开销。

为什么重要：传统调度论文里抢占就是"杀掉低优先级，运行高优先级"，但在 AI 训练里，一个训练任务被抢占后可能要回滚到数小时前的 checkpoint，重新加载模型和数据，重建 NCCL 通信组。这些代价远大于一个在线服务 Pod 被驱逐后重启。

面试中怎么用：如果你研究的是训练任务调度，抢占代价是你必须要考虑的维度。面试时应该说明"代价基抢占"怎么选择牺牲者——不是简单看优先级，而是看 checkpoint 新鲜度、运行时长、释放资源量和重启成本。

不同场景的指标优先级

面试中最常问的问题之一就是"这个指标在你的场景里排第几"。没有统一答案，但可以按场景给出典型排序：

在线推理场景

SLO / Tail Latency——推理服务的核心承诺
Throughput——单位时间处理的 token/请求数
GPU Utilization——但不应牺牲 SLO
Fairness——多模型之间

推理场景不太关心 JCT 和抢占——推理请求是毫秒级，没有 checkpoint 概念。

离线训练场景

JCT——用户最关心什么时候出结果
GPU Utilization——训练成本高，碎片化是浪费
Fairness——多团队共享时避免饥饿
Preemption Cost——训练抢占代价大

训练场景不太关心单个请求延迟和 SLO。

实验平台场景

Waiting Time——实验反馈速度决定研发效率
Fairness——多个 researcher 共享集群
Utilization——但不应过度影响反馈速度

实验平台的特点是短作业多、交互性强、用户等待容忍度低。

大模型预训练场景

Stability——训练一旦开始，尽量不中断
Topology Quality——通信效率直接影响训练速度
Fault Tolerance——硬件故障必须快速恢复
Utilization——但稳定性更重要

大模型预训练的特点是时间长（数周到数月）、GPU 多（数百到数千）、中断代价极高。这个场景下，频繁抢占、gang 不满足、拓扑差都是不可接受的。

指标之间的典型冲突

理解冲突比理解指标本身更重要。面试中如果能说清楚冲突和权衡，比单纯罗列指标更有区分度。

公平性 vs 利用率

严格配额可以保证公平，但可能导致某些队列空闲时其他队列不能用。例如团队 A 的 32 张 GPU 配额只用了 10 张，团队 B 的任务在排队，但配额不允许 B 借用 A 的空闲 GPU。解决方式是弹性借用——允许借用，但在保障租户需要时能回收。

短作业优先 vs 长作业饥饿

SJF/SRTF 能降低平均 JCT，但长作业可能永远排不上。解决方式是 aging（等待越久优先级越高）或配额保障（每个租户至少获得一定比例的调度机会）。

拓扑最优 vs 调度延迟

等待同机柜或同 NVLink 资源可以提升训练性能，但会增加排队时间。如果所有任务都要求"最优拓扑"，大部分时间 GPU 在等完美组合而不是干活。解决方式是设定可接受的拓扑质量阈值，超过阈值就不等了。

抢占效率 vs 进度损失

抢占可以快速释放资源给高优先级任务，但训练任务的 checkpoint 可能是 1 小时前的，被抢占意味着 1 小时的计算白费。解决方式是代价基抢占——优先抢占 checkpoint 新鲜、运行时间短的任务。

装箱 vs 故障域隔离

Bin packing 降低碎片，但把任务集中到少数节点会增加单节点故障的影响范围。解决方式是按故障域分级——在线服务尽量分散，训练任务可以集中但需要快速恢复机制。

公平性、吞吐量、延迟、资源利用率的 trade-off

调度系统不可能同时把所有指标都推到最优。面试里最重要的不是说“我都优化”，而是说明你的场景下哪个指标是硬约束、哪个是优化目标、哪个可以让步。

优化目标	常用策略	通常牺牲什么	适用场景	风险
公平性	quota、DRF、CFS-like share、aging	短期利用率和整体吞吐	多租户平台、共享 GPU 集群	严格隔离会让空闲配额不能被借用
吞吐量	SJF、batching、bin packing、提高并发	单个任务延迟和长任务公平	离线批处理、低优训练队列	短任务偏置导致长任务饥饿
低延迟	优先级、预留资源、抢占、spread	资源利用率和吞吐	在线推理、交互式 notebook、紧急任务	预留过多会造成 GPU 闲置
高资源利用率	backfill、bin packing、GPU sharing、超卖	SLO、故障隔离、公平性	成本敏感平台、离线混部	“忙但没产出”，或互相干扰

回答模板：先说场景，再定硬约束，然后说明优化目标和牺牲项。例如在线推理把 SLO 当硬约束，训练队列把利用率/JCT 当优化目标，多租户平台把公平性当底线。

在线调度 vs 离线调度

在线和离线不是“线上服务”和“离线任务”的简单同义词，而是算法是否提前知道完整输入的区别。在线调度只能看到已经到达的任务，必须边到达边决策；离线调度提前知道全部任务、资源和运行时间，可以做全局优化。

维度	在线调度 Online Scheduling	离线调度 Offline Scheduling
信息可见性	只知道当前和历史任务，不知道未来	提前知道完整任务集合和约束
决策方式	每个任务到达时立即或短时间内决策	可以全局搜索、排序、规划
典型系统	K8s scheduler、在线推理调度、交互式实验平台	批处理排程、生产计划、trace replay 仿真
评价重点	竞争比、延迟、鲁棒性、实时响应	全局最优性、makespan、平均 JCT
工程难点	未来不确定、任务时长预测不准、不能频繁反悔	求解复杂度高，假设可能不符合真实在线环境

AI 集群大多数实际调度是在线调度，但会吸收离线思想：用历史 trace 训练预测器，用未来资源释放估计做 backfill，用离线仿真评估策略。

回答结构

当面试官问"你怎么衡量调度系统的好坏"，用这个框架回答：

先定场景——推理、训练、实验平台、大模型预训练？不同场景的指标优先级不同。
再说核心指标——选 2-3 个最重要的，说清楚定义和为什么重要。
然后说冲突——这些指标之间的矛盾是什么，你怎么权衡。
最后说实验——你用什么 trace、什么 baseline、什么 workload 证明了你的策略改善了哪些指标。

Q: 面试官问"JCT 和 waiting time 有什么区别"，怎么回答？

定义区别

JCT = waiting time + execution time。Waiting time 只衡量排队，JCT 衡量从提交到完成的全部时间。

策略含义不同

降低 waiting time 靠排队策略（排序、准入、抢占）。降低 execution time 靠放置策略（拓扑、资源分配、GPU sharing）。降低 JCT 需要两者配合。

例子

拓扑感知调度可能不改变 waiting time（甚至可能增加，因为等更好拓扑），但通过减少通信开销降低了 execution time，最终 JCT 反而更低。

面试要点：JCT 是用户视角的全链路指标，waiting time 只反映排队阶段。两者改善手段不同。

Q: GPU 利用率高是不是就说明调度好？

不一定

高利用率可能意味着：(1) 确实调度合理，资源被高效使用；(2) 任务都挤在少数节点，牺牲了拓扑和故障隔离；(3) GPU 在做无效计算，例如 NCCL 等待、数据加载瓶颈或 MPS 干扰。

怎么判断

看利用率的同时看吞吐、JCT 和 SLO。如果利用率高但吞吐低，说明 GPU 在"忙但没产出"。如果利用率高但 JCT 也在增加，说明调度可能在做过度装箱。

面试要点：利用率是必要条件但不是充分条件。要结合产出指标一起看。

Q: 调度论文里一般报告哪些指标？怎么设计消融实验？

核心指标

离线训练论文通常报告 JCT（平均和中位数）、waiting time、GPU 利用率。多租户论文加上公平性（dominant share 偏差或配额保障度）。在线推理加上 SLO violation rate 和 tail latency。

消融设计

每次去掉一个机制，看哪个指标退化了。例如去掉拓扑感知，JCT 可能增加但 waiting time 不变；去掉公平性，小团队的 waiting time 可能急剧增加；去掉抢占，高优先级任务的 waiting time 增加。

基线选择

和默认 scheduler 比，和 Volcano/Kueue 比，和同领域论文比。如果只和自己去掉了某些机制的版本比，说服力有限。

Q: 面试官问"你的调度器优化了什么指标，牺牲了什么"，怎么回答？

回答结构

(1) 优化了什么：明确说指标名，例如"优化了 P90 JCT，降低了 25%"。(2) 牺牲了什么：例如"在极端负载下，短作业的 waiting time 略有增加，因为我们优先调度 gang 任务"。(3) 为什么可接受：例如"增加的 waiting time 在 5 分钟以内，但 gang 任务的 JCT 改善了 30%，整体集群利用率提高了 15%"。

为什么这样回答好

面试官不期望你优化所有指标，但期望你说清楚权衡。能说清楚"牺牲了什么、为什么可接受"比"什么都优化了"更有说服力。

Q: Makespan 和平均 JCT 有什么区别？优化一个会改善另一个吗？

定义

Makespan 是"最后一个任务什么时候完成"，平均 JCT 是"所有任务的平均完成时间"。Makespan 是管理员视角，平均 JCT 是用户视角。

关系

优化平均 JCT 通常会让短任务先跑（SJF），但这可能推迟长任务的完成时间，从而增加 makespan。反过来，如果优化 makespan，可能需要所有任务并行跑，但这会增加资源竞争和通信开销，单个任务的 JCT 不一定改善。

什么时候用哪个

批处理和数据 Pipeline 关心 makespan；交互式训练和实验平台关心平均 JCT；多租户平台还要看公平性。

关联模块

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

内容模块

多资源公平调度

进阶★☆☆⏱ 18 min

一句话结论

多资源公平的核心是怎么在多维资源空间里定义"公平"：从单资源的 Max-Min Fairness 和 Proportional Share 起步，DRF 用 dominant share（每个用户占比最高的那维资源）做公平定义并保证 Sharing Incentive/Envy-freeness/Pareto Efficiency 三性质，工程上再用 Elastic Quota（min/max）和 QAD（保障度连续值）落地，最后叠加异构 GPU、拓扑、弹性和抢占代价四个 GPU 集群特有难点。

复习定位

维度	内容
所属模块	任务调度理论
章节类型	系统类
解决问题	围绕经典算法、多资源公平、Gang/Backfill、拓扑感知和抢占代价建立 GPU 集群调度理论答案。
面试抓手	回答时先定范围，再讲核心链路，最后落到工程风险和面试追问。

多资源公平：调度方向的核心基本功

GPU 集群不是单资源系统。一个训练任务同时消耗 GPU、CPU、内存、网络、存储带宽和拓扑位置。多资源公平要解决的问题是：当不同租户的资源需求形态不同，系统如何定义"公平"。

为什么这个问题难？因为"公平"本身就没有唯一答案。团队 A 跑 CV 任务需要大量 GPU 但很少内存，团队 B 跑 NLP 任务 GPU 和内存需求差不多。如果只看 GPU 数量均分，B 觉得 CPU 被忽视；如果只看内存均分，A 觉得 GPU 被忽视。所以核心问题是：在多维资源空间里，怎么定义"公平"这个概念。

基础概念：从单资源公平到多资源公平

Max-Min Fairness（单资源）

这是公平性算法的起点，只处理一种资源。

定义：按需分配，每个用户至少获得 1/N 份额，不需要更多的用户把多余份额让给需要的人。递归地最大化最小分配。

手动推演：集群有 100 张 GPU，4 个用户分别需要 50、30、15、40 张。

初始每人 100/4 = 25 张。用户 3 只需要 15，多出 10。
剩余 75 张分给 3 人，每人 25。用户 2 只需要 30，已拿 25，还需 5，多出 20。
剩余 60 张分给 2 人，每人 30。用户 1 需要 50 但只拿到 30，用户 4 需要 40 也拿到 30。
最终：用户 1 = 30，用户 2 = 30，用户 3 = 15，用户 4 = 30。

怎么理解：Max-Min Fairness 就像分蛋糕——先均分，吃不完的人把多余的分给不够的人，反复进行直到没有人能拿到更多。它保证"最穷的人尽可能不穷"。

局限：只处理单一资源。如果集群有 GPU 和 CPU 两种资源，用户 A 需要 (8 GPU, 2 CPU)，用户 B 需要 (2 GPU, 8 CPU)，Max-Min Fairness 不知道怎么在两个维度上同时定义"公平"。

Proportional Share（按比例分配）

定义：按权重分配资源。团队 A 权重 3，团队 B 权重 1，那 A 拿 75% 的资源，B 拿 25%。

适用场景：适合有明确组织权重的治理场景，比如公司级"大团队多分，小团队少分"。

局限：权重是人为设定的，不自动处理多维瓶颈。如果团队 A 权重高但只消耗 GPU，团队 B 权重低但 CPU 是瓶颈，按权重分 GPU 可能对 B 来说 CPU 完全不够。Proportional Share 不理解"哪种资源是瓶颈"。

怎么理解：Proportional Share 像"按出资比例分红"，简单直接但不关心每个股东实际缺什么。

DRF（Dominant Resource Fairness）详解

DRF 是多资源公平调度的基石算法，由 Ghodsi et al. 2011 提出。几乎所有面试里问到"多资源公平"都期望你从 DRF 开始回答。

核心思想

每个用户的主导资源（dominant resource）是它在所有资源维度中占比最高的那一维。DRF 试图让不同用户的 dominant share 尽量接近，而不是让某个维度的资源被某个用户独占。

逐步推演

集群有 <9 CPU, 18 GB 内存>。用户 A 的任务需要 <1 CPU, 4 GB>，用户 B 的任务需要 <3 CPU, 1 GB>。

Step 1：计算每个用户每个维度的占比

用户 A 一个任务占 CPU 1/9 ≈ 11%，内存 4/18 ≈ 22%。A 的主导资源是内存，dominant share = 22%
用户 B 一个任务占 CPU 3/9 ≈ 33%，内存 1/18 ≈ 6%。B 的主导资源是 CPU，dominant share = 33%

Step 2：每次选择 dominant share 最低的用户分配一个任务

Round 1：A 的 dominant share = 0，B = 0。先给 A。A 运行 1 个任务：A 的 share 变为 (1/9, 4/18)。
Round 2：A 的 dominant share = 4/18 ≈ 22%，B = 0。给 B。B 运行 1 个任务：B 的 share 变为 (3/9, 1/18)。
Round 3：A 的 dominant share = 4/18 ≈ 22%，B = 3/9 ≈ 33%。给 A。A 运行第 2 个任务：A = (2/9, 8/18)。
Round 4：A 的 dominant share = 8/18 ≈ 44%，B = 3/9 ≈ 33%。给 B。B 运行第 2 个任务：B = (6/9, 2/18)。
Round 5：A 的 dominant share = 8/18 ≈ 44%，B = 6/9 ≈ 67%。给 A。A 运行第 3 个任务：A = (3/9, 12/18)。
Round 6：资源余量：CPU = 9-3-6 = 0。CPU 用完了，无法继续分配。

最终分配：A 运行 3 个任务，B 运行 2 个任务。A 的 dominant share = 12/18 ≈ 67%，B 的 dominant share = 6/9 ≈ 67%。两者主导资源份额相等，这就是 DRF 的目标。

DRF 的三个关键性质

Sharing Incentive（共享激励）：每个用户分到的资源不少于均分。如果用户独占集群，不会比共享时更好。
Envy-freeness（无嫉妒）：没有任何用户会觉得别人的分配比自己的更好。A 不会想和 B 换。
Pareto Efficiency（帕累托效率）：不存在另一种分配方式能让某个用户更好而不让其他用户更差。

怎么理解这三个性质：Sharing Incentive 是"参与比不参与更好"；Envy-freeness 是"没有后悔"；Pareto Efficiency 是"没有浪费"。三个一起保证"公平且高效"。

DRF 在 GPU 集群中的应用

GPU 集群的资源维度通常是 <GPU, CPU, 内存, 网络带宽>。一个训练任务的 dominant resource 通常是 GPU，但如果一个任务只用 1 GPU 但消耗大量 CPU 做数据预处理，那 CPU 可能是它的 dominant resource。

实际部署中的变体：原生 DRF 不理解异构 GPU、拓扑位置和任务优先级。工业界通常用 DRF 的思想做基础，然后叠加：(1) 按 GPU flavor 分开算 dominant share；(2) 拓扑位置作为软约束在 Score 阶段叠加；(3) 优先级作为权重乘在 dominant share 上。

Elastic Quota 和 QAD：从理论到工程

DRF 是理论算法，Elastic Quota 和 QAD 是工程落地方案。面试中如果你能从 DRF 过渡到工程实现，会很加分。

Elastic Quota

核心思想：每个队列/租户有 min（保障量）和 max（上限）。min 保证资源不比这个少，max 限制最多用这么多。当某些队列的 min 没用完时，其他队列可以临时借用超过自己 min 但不超过 max 的资源。

手动推演：集群 100 张 GPU。队列 A min=30, max=60；队列 B min=50, max=80。

队列 A 当前用了 10 张，队列 B 当前用了 50 张。A 的 min 没用完（还剩 20 张保障量），B 已经用满自己的 min。
B 想启动新任务需要 10 张 GPU。此时 B 的 min 已满足，它可以借用 A 空闲的 20 张。B 的使用量变为 60，不超过 max=80。
后来 A 提交了新任务需要 20 张 GPU。调度器需要从 B 那里回收 20 张（B 借用了 A 的配额），让 A 的使用量从 10 增加到 30（达到 min）。

怎么理解：Elastic Quota 像"公司工位"。你的团队保障有 30 个工位（min），但上限是 60 个（max）。如果你只坐了 10 个，其他团队可以临时坐。但你回来的时候，坐你工位的人必须让出来。

关键难点：回收策略。从谁那里回收？回收多少？回收的任务怎么处理？这直接决定了 Elastic Quota 在生产环境是否可用。

QAD（Quota Assurance Degree）

定义：QAD = 实际获得资源 / 保障配额。如果队列 A 的保障量是 30 张 GPU，当前只拿到 27 张，QAD = 27/30 = 0.9。

和 Elastic Quota 的区别：Elastic Quota 用 min/max 做离散阈值，QAD 用连续值表达保障程度。

为什么 QAD 更好：

更细粒度：不是"满足/不满足"的二值判断，而是"满足到什么程度"。调度器可以设 QAD 阈值（如 ≥ 0.95），低于这个值就触发回收。
更适合做抢占决策：抢占谁的资源？看哪个借用者的 QAD 最低、哪个保障租户的 QAD 最不满足。这比简单的"超过 min 就回收"更精确。
更容易做渐进式回收：不需要一次性把所有借用资源都回收回来，而是回收到 QAD 达标为止。

怎么理解：QAD 像"手机电量百分比"。不是说"有电/没电"，而是告诉你"还剩 90%"。调度器看到 QAD < 0.95，就知道需要开始"充电"了。

三者关系总结

机制	解决什么问题	优势	局限	怎么理解
DRF	多维资源的公平定义	理论优美，有数学性质保证	不理解拓扑、优先级和工程约束	分蛋糕的数学理论
Elastic Quota	保障+弹性的工程实现	落地简单，min/max 直观	回收策略粗糙，没有连续保障度	工位的保障和借用
QAD	保障度的精细表达	连续值、可设阈值、可渐进回收	需要持续监控和计算	手机电量百分比

GPU 集群里的公平性难点

理论算法在 GPU 集群里会遇到哪些"理论没覆盖"的问题？面试中如果你能说出这些，说明你不只是背了算法，而是理解了工程现实。

1. 异构 GPU：1 张 H100 ≠ 1 张 V100

问题：DRF 的基本假设是同类资源可互换。但 H100 的算力约是 V100 的 4 倍。如果一个用户分到 8 张 V100，另一个分到 8 张 H100，按数量看"公平"了，但实际算力差距巨大。

解决思路：(1) 按 GPU flavor 分开计算 dominant share——H100 是一种资源，V100 是另一种。(2) 用算力等价因子归一化——1 H100 ≈ 4 V100，然后按归一化后的量做公平分配。(3) Kueue 的 ResourceFlavor 天然支持这种拆分。

面试怎么答：先说"异构 GPU 打破了 DRF 同类资源可互换的假设"，然后给出 2-3 种解决思路，最后说"选择哪种取决于集群异构程度和运维复杂度"。

2. 拓扑资源：同样是 8 张 GPU，性能可能差 2 倍

问题：8 张 GPU 在同一节点 NVLink 互联，和 8 张 GPU 分散在 4 个节点，训练吞吐可能差 2 倍以上。DRF 不区分拓扑位置。

解决思路：拓扑在 Score 阶段叠加，不在 Fairness 阶段处理。Fairness 只管"数量公平"，Topology 只管"位置优化"。

面试怎么答：DRF 保证份额公平，拓扑保证性能最优，两者是不同层面的问题。不要试图在 DRF 里加入拓扑——会让问题无解。

3. 任务弹性：4 卡能跑，8 卡也能跑

问题：有些训练任务可以弹性伸缩（4/8/16 卡都行），有些必须固定 world size。如果只看"分配了多少 GPU"，弹性任务可能总是拿到更多。

解决思路：弹性任务的 GPU 需求按"目标 world size"算 dominant share，而不是按"实际拿到多少"。这样弹性任务借到额外 GPU 不会影响公平性计算。

4. 抢占成本：长时间训练被抢占代价极高

问题：DRF 不理解抢占代价。如果为了满足另一个用户的 dominant share 而抢占一个训练了 20 小时的任务，公平性指标改善了，但实际产出可能变差了。

解决思路：在抢占决策中叠加代价感知——不是简单地选 dominant share 最高的抢占，而是选"释放资源量 / 抢占代价"比值最高的牺牲者。

从公平性到队列设计

面试中经常问"怎么设计一个多租户 GPU 集群的队列系统"。这里把公平性理论映射到工程实现。

队列五大能力

能力	解决什么问题	设计要点	不做的后果
Quota（配额）	团队资源保障	min/max、hard/soft、按 GPU flavor 区分	大团队占满所有资源，小团队永远排不上
Borrowing（借用）	提高利用率	空闲资源可借，但要记录来源和可回收性	保障配额空闲时其他人在排队，利用率低
Reclaim（回收）	保障租户需要资源时拿回来	选择低优先级、低沉没成本、checkpoint 新鲜的任务	保障形同虚设——借出去的资源收不回来
Admission（准入）	避免已运行任务半死不活	资源不够时先排队，而不是让部分 worker 占住 GPU	部分 Pod 占住 GPU 但 gang 凑不齐，GPU 空转
Hierarchy（层级）	组织结构复杂时治理	公司/部门/团队多级队列与权重	100 个团队用扁平队列，配额管理爆炸

队列设计的面试回答框架

先说 Quota：每个队列有保障配额（min）和上限（max），min 是硬承诺，max 是弹性天花板。
再说 Borrowing：空闲资源允许借用，但标记为"可回收"——保障租户需要时必须能拿回来。
然后说 Reclaim：回收策略是关键——优先回收 QAD 低的借用者、沉没成本小的任务、checkpoint 新鲜的任务。
再说 Admission：Gang 任务要准入控制——没有足够资源就不让任何 Pod 启动，避免 partial allocation。
最后说 Hierarchy：公司/部门/团队三级队列，权重在各级分配。

多租户 GPU 调度器：公平性怎么落地

多租户场景不能只靠 Kubernetes Namespace 或 ResourceQuota。真正的公平调度至少要有队列、配额、借用、回收、优先级和审计。面试回答时可以从“保障谁、允许谁借、从谁回收、怎么避免饥饿”四个问题展开。

机制	解决的问题	设计要点	常见追问
队列 Queue	把不同团队/业务隔离成可治理单元	支持层级队列：公司 / 部门 / 团队 / 项目	为什么不用一个全局 FIFO？
配额 Quota	给团队资源保障和上限	min 是保障，max 是上限；按 GPU flavor 拆分	H100 和 A100 能不能混算？
借用 Borrowing	避免空闲配额浪费	空闲资源可借，但要记录 owner 和 borrower	借用资源什么时候归还？
回收 Reclaim	保障租户需要资源时拿回来	优先回收低优先级、checkpoint 新鲜、沉没成本小的任务	如何避免回收造成大量损失？
优先级 Priority	表达业务重要性	线上推理、紧急评测、关键训练高于 best-effort 实验	低优任务会不会永远饿死？
Aging	避免长时间等待	等待越久，动态优先级越高	aging 会不会破坏业务优先级？

面试口径：公平不是平均分资源，而是在保障配额、弹性借用和可控回收之间取得平衡。

高优任务抢占低优任务：代价不能忽略

抢占是解决高优任务等待的手段，但在 AI 训练里非常昂贵。一个 Pod 被杀不只是“重启一下”，还可能丢失 checkpoint 之后的训练进度、重建 NCCL 通信组、重新加载模型和数据。

代价	含义	缓解方式
进度损失	回滚到上一次 checkpoint	checkpoint-aware preemption，优先抢 checkpoint 新鲜任务
重启成本	排队、拉镜像、加载模型、初始化通信	镜像预热、本地缓存、NCCL 初始化优化
通信重建	DDP/NCCL world 重新建立	弹性训练或 gang 级别重启
用户体验	长期训练被频繁打断	抢占次数限制、冷却时间、优雅抢占
系统抖动	大量任务被杀和重启造成控制面压力	分批抢占、限速、队列级回收

工程上常用一个简化打分：释放资源价值越高越适合抢，占用资源越少但 checkpoint 很旧的任务不一定适合抢。

$$\text{preemption\_score} = \text{release\_value} / (\text{checkpoint\_age} + \text{restart\_cost} + \text{disruption\_penalty})$$

Q: 为什么只用 ResourceQuota 不够做 GPU 多租户调度？

核心回答

Namespace ResourceQuota 是静态上限——"你最多用这么多"。但 GPU 多租户需要：(1) 排队——满了之后不是拒绝，而是排队等待；(2) 公平分享——不同租户按份额或 dominant share 分配；(3) 借用与回收——空闲资源允许借用，但保障租户需要时能拿回来；(4) Gang admission——一组 Pod 要么全放行，要么全排队；(5) 按 GPU flavor 区分配额——A100 和 H100 不能混着算。ResourceQuota 做不到这些。

为什么这样设计

ResourceQuota 是 K8S 早期为在线服务设计的，假设每个 Pod 独立运行、资源需求固定、不需要排队。GPU 训练任务打破了所有这些假设。

面试要点：ResourceQuota 是"静态上限"，GPU 多租户需要的是"动态排队+公平+借用回收+Gang 准入"。

Q: DRF 的 dominant share 计算过程，能手动推一遍吗？

场景

集群 <9 CPU, 18 GB 内存>。用户 A 任务需要 <1 CPU, 4 GB>，用户 B 任务需要 <3 CPU, 1 GB>。

推演

A 的主导资源是内存（4/18 > 1/9），B 的主导资源是 CPU（3/9 > 1/18）。DRF 优先给 dominant share 低的用户分配。

Round 1: A(0,0) B(0,0) → 给 A → A=(1/9, 4/18), dominant=4/18

Round 2: A=4/18 B=0 → 给 B → B=(3/9, 1/18), dominant=3/9

Round 3: A=4/18 B=3/9 → 给 A → A=(2/9, 8/18), dominant=8/18

Round 4: A=8/18 B=3/9 → 给 B → B=(6/9, 2/18), dominant=6/9

Round 5: A=8/18 B=6/9 → 给 A → A=(3/9, 12/18), dominant=12/18

Round 6: CPU 余量 = 9-3-6 = 0，停止。最终 A=3任务, B=2任务, 双方 dominant share 均为 67%。

面试要点：能手动推演 DRF，说清楚 dominant resource 是哪一维、每轮为什么选这个用户、什么时候停。

Q: Elastic Quota 的回收策略怎么设计？

核心回答

回收要解决三个问题：从谁那里回收、回收多少、回收的任务怎么处理。

从谁那里回收

优先选择：(1) 借用量最大的队列——他们超出保障最多，回收对他们的 QAD 影响最小；(2) 正在运行的任务中沉没成本最低的——刚启动不久的、checkpoint 新鲜的；(3) 优先级最低的任务。

回收多少

渐进式回收，不是一次全收。目标是让保障租户的 QAD 恢复到阈值（如 0.95）。例如保障租户差 5 张 GPU，就回收 5 张，不多收。

回收的任务怎么处理

三种方式：(1) 优雅终止——等任务 checkpoint 后停止（延迟最高但对用户最友好）；(2) 检查点后终止——触发一次紧急 checkpoint，然后停止；(3) 立即终止——对低优先级或短任务适用。具体选哪种取决于任务的 checkpoint 频率和优先级。

面试要点：回收不是简单的"杀掉低优先级"，而是要考虑沉没成本、渐进式回收和优雅终止。

Q: 如果两个用户的 dominant resource 一样怎么办？

核心回答

DRF 退化成单资源公平分配。如果两个用户的 dominant resource 都是 GPU，那 DRF 等价于在 GPU 维度上做 Max-Min Fairness。这不是 bug，而是 DRF 在特定负载下的自然行为。

实际影响

GPU 集群里很多用户的主导资源都是 GPU。这时候 DRF 的多资源优势不明显，更像是"GPU 数量的 Max-Min Fairness"。但加入 CPU、内存、网络带宽后，不同用户的 dominant resource 就会分化。

面试要点：说清楚 DRF 在不同负载下的退化行为，比单纯背算法更能展示理解深度。

Q: DRF 的 Sharing Incentive 性质是什么意思？为什么重要？

定义

Sharing Incentive：每个用户在共享系统里分到的资源，不少于把总资源均分后自己独占那一份。即：参与共享不比独占差。

为什么重要

这是公平性的底线。如果某个用户发现"我参与共享拿到的资源还不如我自己独占 1/N 集群"，他就没有动力参与共享，整个多租户系统的基础就崩了。

反例

如果用"按 GPU 数量均分"，但某个用户需要的资源主要是内存（他的任务每个只需要 1 GPU 但要 64GB 内存），均分 GPU 后他拿到的内存可能远低于 1/N。这时 Sharing Incentive 被违反了——他参与共享不如独占。DRF 通过看 dominant resource 来保证这一点。

面试要点：Sharing Incentive 是"参与共享的最低动力"，DRF 通过 dominant share 来保证这一点。

Q: 面试官问"你怎么设计多租户 GPU 集群的公平性"，怎么回答？

回答框架（4 步）

定义公平：先说在 GPU 集群里"公平"是多维的——GPU、CPU、内存、拓扑。用 DRF 的 dominant share 定义公平。
工程实现：DRF 是理论，工程上用 Elastic Quota + QAD。min 保障、max 上限、空闲借用、QAD 驱动回收。
GPU 特有问题：异构 GPU 按 flavor 分开算、拓扑在 Score 叠加、弹性任务按目标 world size 算、抢占要代价感知。
验证方法：用 dominant share 的基尼系数或 QAD 分布衡量公平性，用 JCT 和利用率衡量效率，看公平性和效率的 trade-off。

面试金句

"公平性不是均分，而是在多维资源空间里让每个用户的瓶颈资源都不吃亏。DRF 解决了定义问题，Elastic Quota + QAD 解决了工程实现问题，异构 GPU 和拓扑是 GPU 集群特有的延伸。"

关联模块

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

内容模块

批调度、Gang 与 Backfill

进阶★☆☆⏱ 18 min

一句话结论

Gang、Backfill、Bin Packing、Preemption 是批调度的四个不同决策层：Gang Scheduling 是 all-or-nothing 准入语义（防 partial allocation 导致 GPU 空转），Backfill 是队列利用率优化（保护队头大任务 reservation 的前提下让短任务插空），Bin Packing 是节点放置策略，Checkpoint-aware Preemption 是代价感知的运行时回收，配合 Elastic Training 还能用缩容代替杀任务。

复习定位

维度	内容
所属模块	任务调度理论
章节类型	系统类
解决问题	围绕经典算法、多资源公平、Gang/Backfill、拓扑感知和抢占代价建立 GPU 集群调度理论答案。
面试抓手	回答时先定范围，再讲核心链路，最后落到工程风险和面试追问。

批调度：训练任务和普通在线服务的分水岭

分布式训练、HPC 和大规模批任务通常不是单 Pod 独立运行，而是一组进程共同完成一个 job。批调度关注的不只是单个 Pod 能否放下，还包括一组 Pod 是否能同时启动、是否会造成资源碎片、是否会让大作业长期排队。

为什么批调度是 GPU 集群独有的问题？因为在线服务的每个 Pod 是独立的——挂一个副本不影响其他副本。但分布式训练的所有 worker 是一个整体——少一个 worker，NCCL AllReduce 就会阻塞，所有 GPU 空转。这种 all-or-nothing 的语义是批调度的核心。

本页问题归类：Gang、Backfill、Bin Packing 分别解决什么

这几个词经常被一起问，但它们不是同一层问题。Gang Scheduling 是准入/启动语义，Backfill 是队列利用率优化，Bin Packing 是节点放置策略。三者可以组合在同一个调度系统里。

概念	所在决策层	回答的问题	典型场景	主要风险
Gang Scheduling	准入控制 / Permit / PodGroup	一组 worker 是否能一起启动	分布式训练、MPI、HPC、强同步任务	等待时间增加，资源凑齐前不能启动
Backfilling	队列调度 / reservation	队头大任务暂时跑不了时，碎片资源能否先给短任务用	HPC、AI 训练队列、多租户实验平台	预测不准会延迟被保护任务，短任务可能过度插队
Bin Packing	节点放置 / Score	任务应该放到哪些节点，如何减少碎片	GPU 训练、批处理、成本敏感离线任务	热点、故障爆炸半径、拓扑质量下降
Preemption	运行中资源回收	高优任务来了，能否打断低优任务释放资源	混部、紧急任务、quota reclaim	训练进度损失、checkpoint 和重启成本

Gang Scheduling 详解

问题背景：Partial Allocation

假设一个 64 卡训练任务需要 8 个节点每个 8 GPU。如果默认调度器只找到了 7 个节点的资源，它会先启动 56 个 worker。这 56 个 worker 启动后执行 NCCL init，发现 world_size=64 但只有 56 个 rank 在线，于是阻塞等待。56 张 GPU 完全空转，而第 8 个节点的资源被其他小任务占走了。

这就是 partial allocation 问题——部分 Pod 先启动，但无法正常工作，白占 GPU。如果同时有 10 个大任务都在等资源，每个都先启动一部分，集群可能完全卡死。

Gang Scheduling 的核心语义

All-or-nothing：一组 Pod 满足最小可运行数量后再整体放行，否则一起等待。

概念	含义	设置建议	设错了的后果
PodGroup	一组需要共同调度的 Pod	按训练 job 划分，一个 job 一个 PodGroup	组太大会增加等待时间，组太小失去 gang 语义
minAvailable	最小可运行 Pod 数	通常等于 world_size，弹性训练时可以小于	太低：部分 Pod 空转；太高：永远等不到资源
Permit	绑定前等待同组 Pod 凑齐	设超时时间，超时后释放已预留资源	不设超时：已预留资源被占住，其他任务用不了

Gang Scheduling 的实现方式

方式 1：Volcano PodGroup

Volcano 引入 PodGroup CRD，其中 minMember 字段定义 gang 大小。调度器在准入阶段检查：集群是否有足够资源同时满足 PodGroup 中 minMember 个 Pod？不够则整组放入 UnschedulableQ 等待。

方式 2：K8S Scheduling Framework Coscheduling 插件

在 QueueSort 阶段把同 PodGroup 的 Pod 排在一起；在 Permit 阶段等待同组 Pod 都通过 Filter；超时后 Unreserve 释放已预留的资源。

方式 3：Kueue Workload + LocalQueue

Kueue 在 ClusterQueue 层做准入控制——只有当 ClusterQueue 有足够配额和资源时，Workload 才被准入。Workload 本身是一组 Pod 的集合，天然有 gang 语义。

Gang Scheduling 的面试回答框架

问题是什么：partial allocation 导致 GPU 空转。
解决思路：all-or-nothing，凑齐再启动。
实现方式：PodGroup + Permit 阶段等待 + 超时释放。
代价：增加大作业等待时间，因为必须等到所有资源同时可用。
优化：弹性训练降低 minAvailable，backfill 利用等待期间的碎片资源。

适合和不适合的场景

适合 Gang	原因	不适合 Gang	原因
PyTorch DDP / MPI / Horovod	rank 必须同时在线，少一个会阻塞 collective	普通 Deployment 副本	每个副本独立服务，不需要 all-or-nothing
强同步 HPC job	进程之间有严格 barrier 和同步通信	无状态 worker 队列	worker 可以独立消费任务，缺几个只影响吞吐
多节点 benchmark	需要固定 world size 和拓扑，才能得到可比结果	弹性推理服务	副本数可以随负载扩缩，不要求同时启动
需要拓扑一致性的训练任务	要一次性拿到同类型 GPU、同网络域资源	短小 best-effort job	等待 gang 资源可能比执行时间还长

回填调度：保护队头任务的插空运行

队头大任务暂时凑不齐资源时，FIFO 会把后面的任务一起挡住，导致碎片 GPU 空转。回填调度的核心做法是：先给队头任务计算一个未来启动时间，再允许后面的短任务或可抢占任务利用当前空闲资源，但不能破坏队头任务的启动时间。

例子：Job-A 是队头任务，需要 64 张 GPU，当前只有 8 张 GPU 空闲，预计 30 分钟后能凑齐 64 张。严格 FIFO 会让这 8 张 GPU 空闲 30 分钟；回填调度会允许 Job-B（2 GPU，5 分钟）和 Job-C（4 GPU，20 分钟）先跑，但不会允许 Job-D（8 GPU，2 小时）启动，因为它会延迟 Job-A。

任务	资源需求	预计运行时间	是否可回填	原因
Job-B	2 GPU	5 分钟	可以	能在 30 分钟窗口内结束
Job-C	4 GPU	20 分钟	可以	能在队头任务启动前释放资源
Job-D	8 GPU	2 小时	不适合	会占用队头任务 30 分钟后的资源

一句话：回填不是让小任务无条件插队，而是在保护队头任务 reservation 的前提下利用碎片资源。

Backfill 要判断哪些条件

调度器要先回答三个问题：队头任务什么时候能启动，后面的任务现在能不能跑，后面的任务会不会影响队头任务启动。只要其中一个问题回答不清楚，回填就可能从“提高利用率”变成“破坏公平性”。

需要的信息	具体含义	GPU 场景里的细化
当前可用资源	现在有多少资源可以立刻分配	不能只看 GPU 总数，还要看型号、显存、节点内空闲卡数和拓扑
队头任务需求	队头任务要什么资源才能启动	例如 64 张 H100、8 台 8 卡节点、同一 RDMA 网络域
运行中任务完成时间	未来什么时候会释放资源	依赖用户声明、历史统计、训练进度或在线预测
候选任务画像	后续任务是否适合插空运行	优先选择短任务、低优先级任务、可抢占任务、checkpoint 新鲜任务
租户状态	任务所属团队是否欠账或超额使用	回填不能长期占用资源不足租户未来应拿回的资源

经典策略对比

策略	保护对象	优点	缺点	适用场景
Conservative Backfill	队列中所有已等待任务	公平性更好，等待时间更可预测	过于保守，可回填空间少，实现复杂	强公平、多租户保障要求高的集群
EASY Backfill	只保护队头任务	实现简单，资源利用率高，最常见	队头后面的大任务可能被短任务反复插队	工程系统和面试讨论中的默认版本
Prediction-aware Backfill	由运行时间预测决定保护窗口	能更充分利用碎片窗口	预测不准会延迟被保护任务	有历史任务数据或在线进度信号的系统

EASY Backfill 最值得重点掌握。它只给队头任务建立 reservation，后面的任务可以被回填，只要预计结束时间早于 reservation time，或者任务本身可抢占。为了避免后续大任务饥饿，工程上通常会加 aging、最大等待时间、租户公平或 quota debt 约束。

EASY Backfill 的调度流程

取队头任务

每轮调度先看队列第一个任务

尝试直接启动

如果队头任务现在能启动，直接调度

估计最早启动时间

根据 running jobs 的预计完成时间模拟未来资源释放

建立逻辑预留

记录 reservation time 和资源需求，避免后续任务破坏预留

扫描后续任务

逐个判断候选任务是否能使用当前碎片资源

检查结束时间或抢占能力

能按时结束，或可在 reservation time 被抢占，才允许回填

到期回收

回填任务超时未结束时优雅退出或强制抢占

head = queue.first()

if can_schedule(head):
    schedule(head)
    return

head_start_time = estimate_earliest_start(head, running_jobs)
reserve(head, head_start_time)

for job in queue.after(head):
    if not fits_current_free_resources(job):
        continue
    if estimated_finish(job) <= head_start_time:
        schedule_as_backfill(job)
    elif job.is_preemptible:
        schedule_as_preemptible_backfill(job, deadline=head_start_time)

GPU 集群里的工程难点

难点	为什么更难	工程处理
GPU 型号不等价	队头任务要 H100 时，V100 空闲也没用	按 GPU type 建模资源池，reservation 和 backfill 都带型号约束
拓扑不是总数问题	8 张空闲卡分散在 4 台机器上，无法满足单机 8 卡任务	Filter 阶段检查节点、NVLink、机架、RDMA 网络域
Gang Scheduling	训练任务通常是一组 worker，不是单个 Pod	以 PodGroup 或 Workload 为单位做回填判断
运行时间预测误差	训练时长受 epoch、数据量、checkpoint、提前停止和干扰影响	给预测时间加 buffer，降低高不确定任务的回填优先级
抢占成本高	训练任务被杀可能丢失长时间进度，还要重建 NCCL	优先回填短任务、best-effort 任务、checkpoint 新鲜任务
多租户公平	利用率优化可能压制资源不足租户	结合 quota、QAD、tenant debt 判断能否借用碎片资源

如果要讲得更像 AI Infra，可以说调度器在 Filter 阶段判断候选任务是否能使用碎片 GPU，在 Score 阶段选择最不影响未来 reservation 的节点，在 Reserve 阶段标记这些资源属于 backfill usage。到 reservation time 时，如果回填任务还没结束，就按可抢占策略回收。

如何避免 GPU 碎片：从放置到队列的组合拳

GPU 碎片的典型问题是：集群总共还剩 8 张 GPU，但分散在 8 台机器上，每台只剩 1 张；一个需要单机 8 卡或 8 卡同拓扑的任务仍然无法运行。解决碎片不能只靠节点打分，需要队列、放置和回填一起设计。

手段	作用	适用场景	代价
Bin Packing	把小任务尽量塞满已有节点，保留完整空闲节点	离线训练、批任务	热点和故障爆炸半径增加
Topology-aware placement	优先保留完整 NVLink / 机架 / RDMA 域	TP、MoE、NCCL-heavy 任务	调度等待可能增加
Backfill	用短任务填碎片，但不破坏大任务 reservation	HPC / AI 训练队列	依赖运行时间预测
Defragmentation	迁移或抢占低优任务，合并碎片资源	需要启动大 gang 时	抢占和重启成本
资源分层	按 GPU flavor、拓扑域、队列分池	异构 GPU 集群	资源池太细会降低利用率

长任务和短任务混部：不能只用 FIFO

长任务需要稳定资源和较低抢占率，短任务需要低等待时间和快速反馈。只用 FIFO 会被队头大任务阻塞；只用 SJF 会让长任务饥饿。实际系统通常组合使用多队列、aging、backfill 和 quota。

策略	解决什么	注意点
多队列	把交互式短任务、长期训练、best-effort 分开治理	队列之间需要公平共享
SJF / 预测排序	降低短任务等待时间和平均 JCT	长任务要 aging 兜底
Backfill	让短任务利用大任务等待期间的碎片窗口	不能破坏大任务 reservation
Checkpoint-aware preemption	必要时回收资源给高优任务	不能频繁打断长任务
Elastic training	长任务可以先小规模启动，资源充足后扩容	训练框架要支持 world size 变化

Elastic Training：弹性训练如何支持

弹性训练允许训练任务在不同 worker/GPU 数量下继续运行，例如先用 32 卡启动，后续扩到 64 卡，资源紧张时缩回 16 卡。它能降低 gang 的启动等待，但需要训练框架、调度器和 checkpoint 协同。

能力	设计要点	风险
弹性资源声明	声明 min/max/target，例如 min=16、target=64	min 太低会导致训练效率差
弹性准入	达到 min 就可启动，后续根据空闲资源扩容	过早启动可能拖长整体训练
动态 membership	rank/world size 变化时重建通信组	NCCL、优化器状态和数据分片要一致
checkpoint 支持	扩缩容时保存/加载一致状态	checkpoint I/O 压力变大
调度策略	扩容只使用不破坏高优 reservation 的资源	弹性任务可能长期占用借用资源

面试口径：弹性训练用更复杂的训练框架能力换更短等待时间和更高利用率，不是调度器单独能完成的。

立即运行还是等待更好的资源组合？

这是 AI 集群调度的核心取舍：立刻运行可以降低 waiting time，但可能拿到差拓扑、低性能或造成碎片；等待更好资源可以提高训练吞吐和后续调度质量，但会增加排队时间。

判断维度	倾向立即运行	倾向等待
任务类型	短实验、低通信 DP、best-effort	大模型预训练、TP/MoE、强拓扑任务
等待成本	用户交互强，等待成本高	任务运行很长，等待几十分钟可接受
性能损失	差拓扑影响小	差拓扑会导致训练吞吐腰斩
资源碎片	当前放置不会破坏大块资源	当前放置会打散完整 8 卡节点
预测置信度	不知道未来资源何时释放	能可靠预测 reservation window

$$\text{schedule now if } \text{waiting\_cost} > \text{performance\_loss} + \text{fragmentation\_cost}$$

工程实现通常不是精确求解，而是设阈值：拓扑质量分数达到阈值就运行；等待超过超时时间就降级；高优任务可以抢占或预留。

QAD-aware Backfill

在多租户 GPU 集群里，回填不能只看任务大小和运行时间。假设 A 团队长期资源不足，队头任务来自 A；B 团队已经拿到了超过保障份额的资源，后面有一个短任务想回填。即使 B 的任务很短，也不能长期占用 A 未来应恢复的资源。

QAD-aware Backfill 可以把候选任务分成三类：资源不足租户的短任务优先回填；资源正常租户的短任务按普通规则回填；资源充足或长期借用的租户只能使用不会影响 under-served tenant 恢复路径的碎片资源。这样 Backfill 同时服务两个目标：提高利用率，避免破坏租户保障。

候选任务来源	回填倾向	原因
资源不足租户	优先	回填有助于缩小保障缺口
资源正常租户	正常判断	按运行时间、资源匹配和抢占能力决定
资源充足租户	谨慎	不能让已经占优的租户继续挤压欠账租户

面试怎么回答

Backfill 的核心是：队头任务暂时跑不了时，不让资源空着，而是允许后面的小任务先利用空闲资源，但不能影响队头任务未来启动。

一个简单实现是：每轮调度先看队头任务，如果它能启动就直接启动；如果不能启动，就根据当前运行任务的预计结束时间估计队头任务最早什么时候能凑齐资源，并为它建立逻辑预留。然后扫描后面的任务，找当前资源能满足、预计能在队头任务启动前结束，或者本身可抢占的任务，把它们作为回填任务调度。

在 GPU 场景下，回填判断不能只看 GPU 数量，还要看 GPU 型号、拓扑、是否需要 Gang Scheduling，以及任务是否可抢占。如果运行时间预测不准，可以加安全 buffer，只选择短任务或 best-effort 任务回填；如果到队头任务预留启动时间时回填任务还没结束，就抢占回收资源。

面试金句：Backfill 解决的是“队头任务暂时跑不了但资源不该空着”的问题，关键约束是不能破坏队头任务的未来启动时间。

Checkpoint-aware Preemption 详解

抢占在 AI 训练里不能只看优先级，还要看沉没成本。一个已经训练 20 小时但 3 小时没 checkpoint 的任务，被抢占代价可能远高于刚启动 5 分钟的任务。面试中如果只说"抢占低优先级"，是不够的——需要说清楚"代价感知抢占"。

传统抢占 vs 代价感知抢占

维度	传统抢占	代价感知抢占
选择标准	优先级最低	抢占代价最低
考虑因素	只有优先级	沉没成本、checkpoint 新鲜度、重启成本
释放效率	可能杀了一个大任务才释放 1 张 GPU	选择释放资源量/代价比值最高的牺牲者
用户感知	"我跑了好久突然被杀了"	"刚启动不久就被调度走了，还算合理"

抢占代价的五个维度

维度	含义	怎么衡量	调度含义
Checkpoint age	距离最近 checkpoint 的时间	当前时间 - 最近 checkpoint 时间	越短越适合被抢占——回滚损失小
Runtime so far	已经运行多久	当前时间 - 启动时间	越长沉没成本越高，不适合抢占
Release value	抢占后能释放多少关键资源	任务占用的 GPU 数量和拓扑质量	释放整组 NVLink GPU 比释放分散 GPU 更有价值
Restart cost	重启需要的额外成本	镜像拉取时间 + 模型加载时间 + NCCL 初始化时间	重启成本高则降低抢占优先级
Tenant debt	租户是否长期超额使用资源	历史借用时长和借用量的加权和	超额租户更适合被回收

抢占决策的打分函数

一个简化的代价感知抢占打分函数：

\text{preemption\_score}(victim) = \text{release\_value}(victim) / (\text{checkpoint\_age}(victim) + \text{restart\_cost}(victim))

选择 \text{preemption\_score} 最高的牺牲者。直觉：释放资源量越大越好，回滚损失和重启成本越小越好。

手动推演：需要释放 4 张 GPU。

任务 X：占 8 GPU（同节点 NVLink），运行 20 小时，1 小时前 checkpoint，重启需 30 分钟。score = 8 / (1 + 0.5) = 5.33
任务 Y：占 4 GPU（跨节点），运行 2 小时，5 分钟前 checkpoint，重启需 10 分钟。score = 4 / (0.08 + 0.17) = 16
任务 Z：占 2 GPU，运行 5 分钟，无 checkpoint（刚启动），重启需 15 分钟。score = 2 / (0.08 + 0.25) = 6.06

选择 Y：虽然只释放 4 张 GPU（刚好够用），但 checkpoint 新鲜、运行时间短，抢占代价最低。如果需要 8 张 GPU，就选 X。

优雅抢占 vs 强制抢占

优雅抢占：通知任务"请尽快 checkpoint 并退出"。任务收到信号后做一次 checkpoint，然后主动退出。优点：进度零损失；缺点：等待时间不确定。

强制抢占：直接杀掉 Pod。优点：立即释放资源；缺点：进度可能回滚到上次 checkpoint。

实际做法：给一个优雅期（如 5 分钟），超时未退出则强制杀掉。这样既给任务机会做 checkpoint，又不会无限等待。

弹性训练与调度

弹性训练把"固定 world size"变成"可变 world size"，可以缓解资源碎片和排队时间。调度器不一定要等到 64 张 GPU 才启动任务，而是可以先用 32 张运行，后续资源释放后再扩容。

弹性训练怎么工作

传统训练：world_size=64 固定，必须凑齐 64 张 GPU 才能启动。NCCL 通信组在启动时确定，运行中不变。

弹性训练：world_size 可变。训练框架（如 PyTorch Elastic/torchrun、Elastic Horovod）支持动态 rendezvous——worker 数量变化时重新组建通信组，调整 batch size 和 learning rate，然后继续训练。

弹性训练的调度好处

场景	没有弹性	有弹性
资源碎片	需要 64 卡但只有 56 卡空闲，任务继续排队	先用 56 卡启动，等剩余 8 卡释放后扩容
GPU 回收	必须杀掉整个任务来释放 GPU	缩减 world size 释放部分 GPU，训练继续
优先级抢占	高优先级任务来了，低优先级任务被全部杀掉	低优先级任务缩减 world size，释放的 GPU 给高优先级

弹性训练的代价

训练吞吐变化：从 64 卡缩到 32 卡，每步训练时间翻倍。
Batch size 和 learning rate 需要适配：worker 数量变化时，global batch size 变了，learning rate 通常需要线性缩放（或按其他规则调整）。
重同步成本：worker 变更时需要重新 rendezvous、重建 NCCL 通信组、调整数据分片。这个过程可能需要几分钟。
不是所有任务都支持：有些模型（如大模型张量并行）对 world size 有严格限制，不能随意缩。

弹性训练的面试回答框架

问题：固定 world size 导致排队时间长、碎片利用率低、抢占代价大。
解决：world size 可变，训练框架支持动态 rendezvous。
调度配合：Gang 的 minAvailable 可以小于 world size，资源够 minAvailable 就启动，后续扩容。
代价：batch size/learning rate 适配、重同步成本、不是所有模型都支持。

Q: Gang、Backfill、Preemption 三者怎么一起用？

核心回答

三者分别处理不同的问题，不是替代关系：

Gang：保证分布式训练不会 partial allocation——要么全启动，要么全等。
Backfill：在 Gang 等待期间利用碎片资源——让短任务先跑，不影响大 gang 预计启动时间。
Preemption：在高优先级任务需要资源时释放——选择代价最小的牺牲者。

组合使用

流程：(1) 新 gang 提交 → 检查资源是否够 → 不够则进入等待队列（Gang 语义）；(2) 等待期间，小任务可以 backfill 利用空闲资源（Backfill）；(3) 当高优先级 gang 到来且资源不够时，选择代价最小的运行中任务抢占（Preemption）；(4) 被抢占的任务如果有弹性训练能力，可以缩减而非杀死。

面试要点：三者是互补的——Gang 保证原子性，Backfill 提高利用率，Preemption 保证优先级。缺了任何一个，系统都有明显缺陷。

Q: Gang Scheduling 会导致大作业饥饿吗？怎么解决？

问题

会。如果集群里小任务源源不断，每次释放的 GPU 都被小任务抢占，大 gang 可能永远凑不齐资源。这叫"大作业饥饿"。

解决思路

(1) 资源预留：为大 gang 预留资源，不允许小任务占用预留部分。(2) Aging：等待时间越长，gang 的调度优先级越高，最终总能排到队首。(3) Backfill 约束：小任务 backfill 时必须保证不推迟 gang 的预计启动时间。(4) 弹性训练：降低 minAvailable，用更少的 GPU 启动，减少等待时间。

面试要点：Gang 的饥饿问题是经典面试题。要从"预留、aging、backfill 约束、弹性"四个角度给出解法。

Q: 为什么 GPU 集群的 Backfill 比 CPU 集群难做？

核心回答

三个原因：

GPU 任务通常是独占整卡：CPU 任务可以只占 0.5 核，留下 0.5 核给别人。但 GPU 任务通常独占整卡，不像 CPU 可以"挤一挤"。所以 GPU 集群的 backfill 窗口更难找——只有整卡空闲时才能 backfill。
Gang 语义增加了约束：不是"1 个 Pod 能放就行"，而是"一组 Pod 必须同时能放"。大 gang 等待期间，碎片可能分散在不同节点，小 gang 也放不进去。
拓扑约束：即使有空闲 GPU，如果拓扑位置不合适（如跨节点太多），backfill 任务的性能可能很差，不值得跑。

怎么缓解

GPU sharing（MPS/time-slicing）可以创造 backfill 机会——让小任务和已有任务合用同一张卡。代价是可能的性能干扰。

面试要点：GPU 独占性 + Gang 语义 + 拓扑约束，三重限制让 GPU 集群的 backfill 更难。

Q: 如果 checkpoint 频率很低（如每 4 小时一次），抢占决策应该怎么调整？

核心回答

checkpoint 频率低意味着 checkpoint age 可能很大，抢占代价高。调整策略：

优先抢占刚启动的任务：它们没有太多进度可损失。
触发紧急 checkpoint：通知任务"请立即做一次 checkpoint"，等待完成后抢占。虽然增加了延迟，但避免了小时级的进度损失。
考虑优雅抢占：给任务更多时间来 checkpoint 和退出。如果是训练任务，5-10 分钟的优雅期可能换来巨大的进度保护。
调整 checkpoint 频率策略：如果集群经常需要抢占，可以建议用户提高 checkpoint 频率，或者平台提供自动异步 checkpoint。

面试要点：低 checkpoint 频率让抢占代价飙升。解决方案不是"不做抢占"，而是"做代价感知抢占 + 优雅终止 + 紧急 checkpoint"。

大模型训练被抢占时，如何弹性伸缩而不中断？

Megatron/DeepSpeed 这类大模型训练通常依赖固定 world size、张量并行、流水线并行和数据并行组合。严格 Gang 模式下，少一个 rank 就会阻塞 collective；如果发生节点故障或高优先级抢占，传统做法是整组失败后从 checkpoint 重启。弹性训练的目标是把“整组重启”变成“保存状态、重建 rank 拓扑、继续训练”。

环节	要做什么	关键风险
故障/抢占感知	平台发现节点 NotReady、Pod eviction、PriorityClass 抢占或任务心跳丢失	误判会导致不必要重组
优雅冻结	通知 trainer 停止取新 batch，等待当前 micro-batch / pipeline flush 完成	强杀会丢进度，pipeline 中间状态难恢复
保存 checkpoint	保存模型参数、优化器状态、LR scheduler、RNG、数据迭代器、并行拓扑 metadata	ZeRO/TP/PP 分片 checkpoint 与新 world size 不兼容
重新 rendezvous	按剩余或新增 GPU 重建 rank/world size、DP/TP/PP group、NCCL communicator	TP/PP 通常有整除和拓扑约束，不能任意缩放
状态重分片	把旧 checkpoint 转换到新并行配置，重新切分 optimizer/model state	转换成本和共享存储带宽可能成为瓶颈
恢复训练	从同一个 global step / consumed samples 继续，调整 global batch 和 LR 规则	batch size 改变会影响收敛，需要策略约束

面试要点：弹性训练不是 scheduler 单独完成的能力，而是 调度器 + 训练框架 + checkpoint 格式 + 共享存储 协同。调度器负责 min/max/target 资源和抢占策略，训练框架负责 rank 重组和状态恢复。

Megatron/DeepSpeed 场景下的弹性边界

不是所有并行维度都适合频繁变化：

并行维度	是否适合弹性变化	原因	调度建议
Data Parallel	相对适合	DP rank 数变化主要影响 global batch、梯度同步组和数据分片	优先在 DP 维度做扩缩容
Tensor Parallel	不适合频繁变化	模型层内权重和通信 pattern 与 TP degree 强绑定	尽量固定 TP，并放在同 NVLink 域
Pipeline Parallel	谨慎变化	层切分、micro-batch、pipeline bubble 与 stage 数绑定	只在大规模重启或计划性调整时变化
ZeRO DP Sharding	可变化但依赖 checkpoint 转换	优化器状态和参数分片跟 rank 数相关	使用通用/可重分片 checkpoint 格式

因此，一个实用策略是：TP/PP 固定，DP 弹性。例如每个节点内 8 卡固定做 TP=8，节点数变化只改变 DP 组数量。这样拓扑约束更稳定，checkpoint 重分片也更可控。

Checkpoint 如何高效保存和恢复？

大模型 checkpoint 的难点不是“把文件写下来”，而是状态巨大、分片复杂、恢复拓扑可能不同。高效 checkpoint 要同时降低保存停顿、恢复重分片成本和共享存储压力。

状态	为什么必须保存	遗漏后果
模型参数	训练主体状态	无法恢复模型权重
优化器状态	Adam moment、ZeRO shard 通常比参数还大	恢复后收敛曲线异常或等价于重新 warmup
LR scheduler / global step	保证学习率和训练步数一致	学习率错位，训练不稳定
RNG state	保证 dropout、数据增强、采样可复现	恢复前后结果不可复现
Data loader / consumed samples	避免重复或跳过数据	训练样本统计错误
Parallelism metadata	记录 TP/PP/DP/ZeRO 分片方式	新拓扑无法正确重组 checkpoint

工程优化手段：

分布式并行写：每个 rank 写自己的 shard，避免单 rank 聚合所有状态。
异步 checkpoint：训练线程尽快继续，后台 I/O 写入共享存储；需要额外内存或 staging buffer。
增量/差量 checkpoint：只保存变化状态，降低 I/O，但实现复杂。
分层存储：本地 NVMe 做 staging，后台刷到 NFS/S3/HDFS；恢复时优先读本地或同机架副本。
通用 checkpoint 格式：保存足够 metadata，支持从 TP/PP/ZeRO 的某种分片恢复到另一种分片。

Q: 如果高优先级任务抢占 16 张 GPU，低优大模型训练如何不中断？

回答框架

优先判断低优训练是否支持弹性。如果支持，尽量在 DP 维度缩容，而不是整组杀掉。调度器给 trainer 发送优雅抢占信号，trainer 完成当前 step 或 pipeline flush 后保存 checkpoint，释放被抢占节点，剩余 worker 重新 rendezvous，按新的 DP size 重建通信组并从同一 global step 继续。

关键细节

TP/PP 尽量不变；checkpoint 要在共享存储上；恢复后要调整 global batch 或 gradient accumulation，保持有效 batch size 尽量稳定；如果无法弹性缩容，则做 checkpoint-aware preemption，选择 checkpoint 最新、重启成本最低的任务牺牲。

面试金句：大模型弹性训练通常不是“随便少几张卡继续跑”，而是“固定 TP/PP，优先弹性 DP，并通过 checkpoint 重分片恢复”。

Q: Checkpoint 频率怎么选？越频繁越好吗？

核心回答

不是。频率越高，抢占回滚损失越小，但 I/O 开销越大、训练停顿越多、共享存储压力越高。频率应该由失败率、抢占率、单次 checkpoint 耗时和可接受回滚时间共同决定。

工程公式

可以用近似目标：最小化 checkpoint_overhead_per_hour + expected_lost_work_per_hour。如果集群抢占频繁或硬件故障率高，就提高 checkpoint 频率；如果是稳定独占集群，就降低频率并做异步 checkpoint。

面试要点：checkpoint 是保险，不是免费操作。频率要根据故障/抢占概率和 I/O 成本折中。

参考资料

DeepSpeed training/checkpointing 文档：覆盖 ZeRO、模型并行、checkpoint API 和大模型训练状态管理。
Universal Checkpointing 论文和 DeepSpeed 教程：强调 checkpoint 应支持不同并行配置之间的转换，用于故障恢复和弹性资源管理。
DeepSpeed elastic training 资料：说明动态 GPU 可用性变化时，需要 launcher、checkpoint 和 rank 重组协同。

Q: 面试官问"你怎么设计训练任务的抢占策略"，怎么回答？

回答框架

先说为什么训练抢占和普通 Pod 抢占不同：训练抢占有沉没成本（进度损失）、重启成本（模型加载+NCCL 重建）、拓扑成本（好的位置被让出来了）。
再说代价感知抢占：不是简单看优先级，而是看 \text{release\_value} / (\text{checkpoint\_age} + \text{restart\_cost})。选这个比值最高的牺牲者。
然后说优雅抢占：给任务优雅期做 checkpoint，超时后强制终止。
最后说弹性训练：如果任务支持弹性，可以缩减 world size 而不是杀掉，释放部分 GPU 但训练继续。

面试金句

"训练任务的抢占不是简单的优先级排序，而是代价优化问题。好的抢占策略选择'最值得杀'的牺牲者——释放资源多、进度损失少、重启成本低。"

关联模块

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

内容模块

拓扑感知调度

精通★☆☆⏱ 18 min

一句话结论

拓扑感知调度优化的不是 GPU 数量，而是 rank 通信图到硬件数据路径图的映射代价：节点内 NVLink/NVSwitch 比跨机 InfiniBand 快 10-50 倍，而通信又占训练时间 30-50%，所以 Tensor Parallel/MoE 必须放进同一 NVLink 域、GPU 与 NIC 要做 NUMA 对齐，再用拓扑质量阈值在等待时间和训练性能之间权衡。

复习定位

维度	内容
所属模块	任务调度理论
章节类型	系统类
解决问题	围绕经典算法、多资源公平、Gang/Backfill、拓扑感知和抢占代价建立 GPU 集群调度理论答案。
面试抓手	回答时先定范围，再讲核心链路，最后落到工程风险和面试追问。

拓扑感知调度：GPU 集群调度的核心差异点

普通 CPU 调度通常只关心资源数量是否足够，而 GPU 训练调度必须关心"资源之间的连接关系"。同样是 8 张 GPU，同机 NVSwitch、同机 PCIe、跨机 RDMA、跨机柜网络，对训练吞吐的影响完全不同。

为什么拓扑这么重要？因为大模型训练的通信时间可能占到总训练时间的 30-50%。如果 8 张 GPU 在同一节点用 NVLink 互联，AllReduce 一个 1GB 的梯度张量可能只需要 0.5ms；但如果 8 张 GPU 分散在 4 个节点走 InfiniBand，同样的操作可能需要 5ms。10 倍的差距，乘以每步训练都要做一次，最终训练速度可能差 2 倍以上。

拓扑层次：从芯片到机房

理解拓扑感知调度，必须先理解 GPU 集群的物理拓扑层次。每一层有不同的带宽、延迟和调度含义。

层次	典型连接	带宽	延迟	调度含义
GPU 内部	SM、HBM、L2	2-4.8 TB/s	ns 级	影响单卡性能，不由调度器直接控制
节点内 GPU 间	NVLink / NVSwitch	300-900 GB/s	μs 级	张量并行必须放这里，通信密集型任务的最高优先级放置
CPU-GPU	PCIe Gen4/5	32-64 GB/s	μs 级	数据加载和 host-device copy 需要 NUMA 亲和
节点间	InfiniBand / RoCE	200-400 Gbps	几 μs	数据并行和流水线并行的跨节点通信
机架/机柜	ToR 交换机	几百 Gbps	几十 μs	大规模训练要减少跨机柜通信，避免拥塞

怎么理解这些数字

关键不是记住具体数字，而是理解量级差异：

NVLink 比 InfiniBand 快 10-50 倍（900 GB/s vs 50 GB/s）
InfiniBand 比以太网快 5-10 倍（400 Gbps vs 40-100 Gbps）
同节点 vs 跨节点的延迟差 1-2 个数量级

这些量级差异决定了：如果你把需要频繁通信的 worker 放错了位置，性能可能直接腰斩。

通信路径模型：调度器真正要优化的对象

拓扑感知调度不是简单地区分“同机”和“跨机”，而是要把训练通信映射到真实数据路径上。单机内 GPU-GPU 通信优先使用 NVLink/NVSwitch；CPU、GPU、NIC、NVMe 等设备之间通过 PCIe 连接；跨机 GPU-GPU 通信则依赖 NIC + InfiniBand/RoCE RDMA，理想情况下使用 GPUDirect RDMA 直接读写 GPU HBM。

识别 rank 通信图

TP、DP、PP、MoE 的通信频率和通信量不同

映射硬件路径

NVLink/NVSwitch、PCIe、GPU-NIC、RDMA、机架网络

过滤硬约束

GPU 型号、显存、完整 NVSwitch 域、NIC 亲和、NUMA

按代价打分

惩罚跨 Socket、host staging、跨机架、网络拥塞和碎片化

绑定设备组合

锁定具体 GPU/NIC，避免并发调度破坏拓扑假设

因此，调度器看待“4 张 GPU”时不应该只看数量，而要判断它们之间的路径：同 NVSwitch 域的 4 卡、同 PCIe switch 的 4 卡、跨 Socket 的 4 卡、跨机器 2+2，通信代价完全不同。跨机训练还要继续看 GPU 到 NIC 是否同 NUMA、RDMA 是否能走 GPUDirect、是否会退化成 CPU host staging。

面试金句：拓扑感知调度优化的不是 GPU 数量，而是 rank 通信图到硬件数据路径图的映射代价。

不同并行策略的拓扑偏好

这是拓扑感知调度最核心的知识点。面试中经常问"为什么张量并行要放在同节点"。下面的表格解释了每种并行策略为什么有特定的拓扑偏好。

并行策略	通信模式	通信频率	通信量/步	放置偏好	为什么
数据并行	AllReduce 梯度同步	每步一次	模型参数量 × 2/N（Ring AllReduce）	跨节点可行，但需要高带宽低延迟网络	通信量与参数量成正比，但 Ring AllReduce 均摊到 N 个节点，单个节点负载不高
张量并行	层内 AllReduce/AllGather	每层前向+反向各一次	激活值大小 × 层数 × 2	强依赖节点内 NVLink/NVSwitch	通信频率极高（每层都通信），如果走网络会严重拖慢训练
流水线并行	相邻 stage P2P 通信	每个 micro-batch	激活值大小	相邻 stage 靠近，跨节点也可接受	通信量小（只传激活值），P2P 不需要全局同步，网络能承受
专家并行	All-to-All	每层 MoE	专家路由的 token 分布	需要避免跨拥塞域	All-to-All 是最重的通信模式，每个 GPU 都要和所有其他 GPU 通信
ZeRO-3	AllGather + ReduceScatter	前向+反向各 N 次	参数/梯度分片大小	通信量大，需要高带宽网络	虽然省显存，但通信开销比普通数据并行大 1.5-3 倍

3D 并行的典型拓扑布局

大模型训练通常组合使用 DP + TP + PP。以 64 GPU（8 节点 × 8 卡）训练 175B 模型为例：

TP = 8：同一节点的 8 卡做张量并行，利用 NVLink 的高带宽处理频繁的层内通信
PP = 4：跨 4 个节点做流水线，P2P 通信量小，走 InfiniBand 即可
DP = 2：2 组流水线做数据并行，每个 micro-batch 结束同步梯度

调度含义：调度器需要知道这个任务需要 4 个"完整节点"（每个节点 8 GPU 全用），而不是 32 个散落的 GPU。如果只给 4 张 GPU 在同一节点、28 张分散在其他节点，TP=8 就做不了。

拓扑感知调度的实现路径

面试中经常问"怎么在 K8S 里实现拓扑感知调度"。答案不是唯一的，要看你的集群规模和精度需求。

5 种实现方式对比

方式	做法	精度	适用场景	局限
Node Label	把 GPU 型号、机架位置标为 label	粗粒度（节点级）	简单场景，只要区分 GPU 型号	表达不了设备级拓扑（如哪几张 GPU 之间有 NVLink）
NodeFeatureDiscovery	自动发现节点硬件信息并发布为 label/extended resource	粗粒度（节点级）	不想手动维护 label	和 Node Label 一样，只到节点级
Device Plugin + Topology Manager	节点侧在设备分配时考虑 NUMA 亲和	中粒度（NUMA/PCIe 拓扑）	单节点内资源对齐	只管单节点，不管跨节点拓扑
Scheduler Plugin	在 Filter/Score 阶段读取拓扑信息，对节点或设备组合打分	细粒度（可到设备级）	需要跨节点拓扑感知	开发成本高，需要维护拓扑数据
DRA / ResourceSlice	把设备属性、容量和拓扑结构化发布，调度器基于设备级信息匹配	最细粒度	未来方向，结构化表达	K8S 1.26+ 才支持，生态尚不成熟

拓扑调度的目标函数

拓扑感知调度不是"让所有任务都拿到最优拓扑"——那会导致大量 GPU 在等完美组合。而是要找到一个可接受的拓扑质量，在等待时间和训练性能之间权衡。

五种目标

目标	含义	什么时候用	风险
最小通信代价	把通信频繁的 rank 放最近	张量并行、MoE	可能增加排队时间
最大局部性	优先同节点/同机柜	3D 并行	可能造成资源碎片
最小碎片	保留完整 GPU 组给大任务	多租户集群	可能牺牲当前任务的最优拓扑
故障域分散	避免所有副本在同一故障域	在线推理、高可用训练	增加通信开销
性能预测最优	根据模型预测不同放置的训练吞吐	有性能预测模型时	依赖预测准确性

怎么理解这些目标的冲突

最小通信代价和最小碎片是矛盾的：把通信密集的 worker 都放在一起（最小通信代价），可能导致大块 GPU 组被拆散（碎片化增加）。实际中通常的做法是：设定一个拓扑质量阈值（如"至少 70% 的 worker 在同节点或同机柜"），超过阈值就不等了。

Q: 为什么不能只用 node label 表达 GPU 拓扑？

核心回答

Node Label 只能表达节点级静态属性（如 GPU 型号、机架位置），但表达不了三类关键的设备级关系：

GPU 之间的互联关系："GPU 0 和 GPU 1 之间有 NVLink，但 GPU 0 和 GPU 2 之间走 PCIe"。这决定了哪些 GPU 组合更适合张量并行。
GPU 与 NUMA 节点的亲和性："GPU 0 离 NUMA 节点 0 更近，数据加载应该用 NUMA 0 的 CPU"。这影响 host-device copy 的延迟。
MIG slice 的归属："MIG slice 1c.0 和 1c.1 属于同一张物理 GPU，不能同时分配给不同任务"。这是资源互斥约束。

怎么解决

用 Scheduler Plugin 在 Filter/Score 阶段读取拓扑数据（如 DCGM 导出的 NVLink 拓扑），或用 DRA 的 ResourceSlice 结构化表达。

面试要点：Label 是节点级的，GPU 拓扑是设备级的。级别不同，Label 做不了。

Q: 如果集群资源不够让所有任务都拿到最优拓扑，怎么权衡？

核心回答

设拓扑质量阈值，而不是追求全局最优。

具体做法

(1) 定义拓扑质量分数：如"同节点 GPU 占比 × 1.0 + 同机柜 GPU 占比 × 0.5 + 跨机柜 GPU 占比 × 0.1"。(2) 设可接受阈值：如"拓扑分数 ≥ 0.7 就不等了，直接调度"。(3) 超时降级：等待最优拓扑超过 30 分钟，自动降级到次优拓扑。(4) 按并行策略区分：TP 任务要求高拓扑质量（阈值 0.9），DP 任务可以低一些（阈值 0.5）。

面试要点：不是"最优或不变"，而是"设定可接受的质量阈值，超阈值就调"。

Q: 怎么衡量拓扑感知调度的效果？

指标

三个维度：

训练性能提升：对比有/无拓扑感知时的 throughput（samples/s 或 tokens/s）。通常能提升 20-50%。
JCT 改善：训练性能提升 → execution time 降低 → JCT 降低。但注意，等最优拓扑可能增加 waiting time。
等待时间增加：拓扑感知调度可能让任务多等 5-30 分钟来凑更好的拓扑。需要看 JCT 的净改善是否为正。

怎么设计消融实验

(1) 去掉拓扑感知（只看资源数量，不看位置）→ 看 JCT 和 throughput 变化。(2) 只对 TP 任务做拓扑感知，DP 任务不做 → 看不同并行策略的收益。(3) 调整拓扑质量阈值 → 看等待时间和训练性能的权衡曲线。

面试要点：拓扑感知的收益看训练性能，代价看等待时间。消融实验要分别衡量两者。

Q: 面试官问"为什么张量并行必须放在同节点"，怎么回答？

核心回答

因为张量并行每一层的前向和反向都要做 AllReduce/AllGather，通信频率远高于其他并行策略。一个 70 层的 Transformer，每步训练要做 70 × 2 = 140 次集合通信。如果走 InfiniBand（延迟 ~5μs），每次通信的延迟累积到 0.7ms/步。如果走 NVLink（延迟 ~0.5μs），只有 0.07ms/步。乘以数万步训练，差距巨大。

补充

不只是延迟，带宽也是问题。NVLink 带宽 900 GB/s，InfiniBand 只有 ~50 GB/s。张量并行每次通信的激活值可能达到 GB 级别，带宽不够会严重拖慢训练。

面试金句："张量并行的通信频率是'每层每步'，不是'每步一次'。这个量级的通信只有 NVLink 承受得起。"

Q: DRA 怎么解决拓扑表达问题？

核心回答

DRA 引入了 ResourceSlice，可以结构化地描述每个设备的属性和设备间的关系。一个 ResourceSlice 可以说"这个节点有 8 张 GPU，其中 GPU 0-3 通过 NVLink 互联，GPU 4-7 通过 NVLink 互联，但两组之间走 PCIe"。调度器可以根据这些信息做设备级的拓扑匹配。

和 Device Plugin 的区别

Device Plugin 只能报告设备列表（如 nvidia.com/gpu: 8），不能表达设备之间的关系。DRA 的 ResourceSlice 可以报告结构化的设备拓扑。这是从"资源计数"到"资源关系"的进化。

面试要点：Device Plugin 是"我有 8 张 GPU"，DRA 是"我有 8 张 GPU，它们之间是这样连接的"。

面试题：多机多卡下如何最小化通信开销？

回答这类题时，不要只说“尽量放近”。更完整的回答是：先建立通信代价模型，再把并行策略映射到拓扑层次，最后在调度器的 Filter/Score/Reserve 阶段落地。

建模拓扑图：把 GPU、CPU Socket、NUMA node、PCIe root complex、NVLink/NVSwitch、NIC/RDMA、机架/交换机都建成图节点或边；边权可以表示带宽、延迟、拥塞和故障域。
识别通信模式：TP 是层内高频 AllReduce/AllGather，MoE 是 All-to-All，DP 是每步梯度 AllReduce，PP 是相邻 stage P2P。不同通信模式对拓扑的敏感度不同。
优先满足强约束：TP/MoE 优先放在同 NVLink/NVSwitch 域；GPU 与 NIC 尽量同 NUMA/同 PCIe root complex；需要 GDR 的任务避免 GPU 和 RDMA NIC 跨 Socket。
再做软打分：如果不能完全满足，就用拓扑质量分数排序，例如同 NVLink 加高分、同 NUMA 加中分、跨 Socket/跨机架加惩罚。
保留未来大块资源：不能为了当前小任务打散完整 8 卡 NVLink 节点或同机柜 RDMA 域，否则后续大任务会排队更久。

调度器视角可以抽象成：

score(placement) =
  - communication_cost(rank_graph, topology_graph)
  - fragmentation_cost(remaining_resources)
  - contention_cost(current_load)
  + locality_bonus(gpu_nic_numa_alignment)

这里的关键是 rank graph：模型并行里的哪些 rank 通信最频繁，就应该在物理拓扑里放得最近。不能只按 GPU 数量调度。

4 张 GPU 应该怎么分配？

如果一个任务需要 4 张 GPU，优先级通常是：

候选放置	优先级	原因	适合场景
同一 NVLink/NVSwitch 域内 4 卡	最高	GPU-GPU 通信带宽最高、延迟最低，TP/MoE 收益明显	张量并行、小规模预训练、通信密集训练
同一 Socket / 同 NUMA 下 4 卡	高	CPU 线程、内存、GPU、NIC 亲和性最好，减少跨 UPI/QPI	数据加载重、GDR/RDMA 依赖强
同节点但跨 NUMA / 跨 Socket	中	仍避免跨节点网络，但 CPU-GPU、GPU-NIC 可能走远端路径	DP 或通信不密集任务
跨节点 2+2 或 1+1+1+1	低	NCCL 通信走 RDMA/以太网，延迟和带宽都更差，还增加故障面	纯 DP、资源紧张时的降级方案

跨 NUMA / 跨 Socket 的影响主要有三类：

Host-device copy 变慢：DataLoader 线程和 pinned memory 如果在远端 NUMA，H2D 拷贝会经过跨 Socket 互联。
GPU-NIC 路径变差：GPU 和 RDMA NIC 不在同一 PCIe root/NUMA 时，GPUDirect RDMA 可能退化，增加 CPU/内存中转和链路延迟。
NCCL 拓扑选择受影响：NCCL 会根据 NVLink、PCIe、NIC 拓扑选择 ring/tree，但差拓扑会让 collective 的慢边拖累整体。

面试可以这样答：如果是 4 卡 TP，我倾向于同节点同 NVLink 域；如果是 DP，跨节点也能接受但要保证 RDMA 网络质量；如果同时有 RDMA 通信，就要把 GPU 和 NIC 做 NUMA 对齐。

基础知识补全：NUMA、PCIe、NVLink、RDMA 分别影响什么

概念	是什么	调度里为什么重要
NUMA	多 Socket 服务器中，每个 CPU Socket 有本地内存，访问远端内存更慢	CPU 线程、内存页、GPU、NIC 要尽量同 NUMA，否则数据加载和网络路径变慢
PCIe root complex	CPU 到外设的 PCIe 根路径，GPU/NIC 可能挂在不同 root 下	决定 GPU-GPU P2P、GPU-NIC GDR 是否走本地路径
NVLink / NVSwitch	NVIDIA GPU 间高带宽互联	TP、MoE、频繁 collective 的核心拓扑资源
RDMA / InfiniBand / RoCE	跨节点低延迟高带宽网络，可绕过 CPU 做远端内存访问	多机训练、跨节点 AllReduce、KV cache 迁移和 P/D 分离推理都依赖它
GPUDirect RDMA	NIC 直接访问 GPU 显存，减少 CPU bounce buffer	要求 GPU 与 NIC 拓扑亲和，否则带宽和延迟可能明显退化

Q: 如何设计一个拓扑感知 GPU 调度算法？

回答框架

先把任务抽象成 rank 通信图，把集群抽象成硬件拓扑图，然后做约束过滤和代价打分。Filter 阶段保证 GPU 型号、显存、同节点/同 NUMA、GPU-NIC 亲和等硬约束；Score 阶段最小化通信代价和碎片代价；Reserve 阶段锁定具体 GPU/NIC，避免并发绑定时重复分配。

工程落点

短期可以用 Node Label + Scheduler Plugin + NVIDIA/DCGM 拓扑发现；节点内用 kubelet Topology Manager 对齐 CPU/Memory/Device；更长期可用 DRA ResourceSlice 表达 GPU/NIC/NUMA 属性，让 scheduler 直接做设备级匹配。

面试金句：拓扑感知调度不是“找 4 张空闲 GPU”，而是“找通信图和硬件图代价最小的一组 GPU”。

参考资料

Kubernetes Topology Manager 文档：说明 kubelet 如何协调 CPU Manager、Memory Manager、Device Manager 的 NUMA hint，避免 CPU 和设备跨 NUMA 分配。
NVIDIA rack-scale topology-aware scheduling 文章：强调 NVLink domain、clique/partition、GPU fabric 等硬件拓扑需要被调度系统理解。
AKS DRANET / DRA RDMA 资料：展示 GPU 与 RDMA NIC 同 NUMA 对齐对 GPUDirect RDMA 的重要性。

关联模块

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

内容模块

GPU 调度场景题库

精通★☆☆⏱ 70 min

一句话结论

GPU 调度场景题不要只背“队列、打分、抢占”这些概念。面试官通常在考三件事：你能不能把业务场景讲具体，能不能把 GPU 从“几张卡”拆成显存、算力、拓扑、成本、租户配额等可调度条件，能不能说明方案落到 Kubernetes 节点标签、资源池、准入层和调度器扩展时到底做哪些动作。

回答时建议按这个顺序展开：先澄清任务类型和约束 -> 解释资源和任务画像 -> 说调度链路怎么改 -> 说异常和回退 -> 说指标如何证明有效。这样每个场景都能讲到 8-10 分钟，而不是只报几个名词。

常用术语先解释

术语	白话解释	在回答里怎么用
资源规格 / 卡型资源池	把同样叫 GPU 的资源按型号、显存、网络、成本、节点池区分开	H100 80GB、A100 40GB、A10 24GB 是不同资源规格，不能只当成 `nvidia.com/gpu=1`
node pool	一批同质或用途相近的节点池	在线推理池、离线训练池、H100 高端池、A10 低成本池
作业画像	调度器对任务需求的结构化描述	需要多少显存、是否多机、是否需要 NVLink、预计时长、是否可抢占
Gang / 组调度	一组 Pod 必须一起启动，否则训练跑不起来	8 卡分布式训练不能先启动 7 个 worker 占着资源空等
Backfill	在不影响大任务预约启动的前提下，让短任务填资源空洞	64 卡任务还差 16 卡时，用 1-2 卡短任务临时填空
抢占代价	抢掉一个任务带来的进度损失和恢复成本	GPU 训练抢占要看 checkpoint 新鲜度、运行时长、模型加载成本
拓扑感知	调度时考虑 GPU 与 GPU、GPU 与 NIC 的物理连接关系	TP 更想放同节点 NVSwitch，跨节点会被 RDMA 和交换机瓶颈限制

场景题总览

场景	面试官真正想看	关键词
异构 GPU 调度	你是否能把 GPU 从“数量”升级成卡型 / 显存 / 性能 / 拓扑资源	节点标签、资源池、型号匹配、性能归一
多租户配额	你是否理解公平和利用率冲突	quota、fairshare、cohort、借用、回收
Gang / 组调度	你是否知道分布式训练 All-or-Nothing 语义	PodGroup、minAvailable、准入、死锁
Backfill	你是否能处理大任务等资源时的小任务填空	短作业、预计时长、reservation
抢占	你是否知道 GPU 训练抢占代价很高	priority、checkpoint、victim cost
碎片治理	你是否能解释 GPU 利用率低的结构性原因	bin packing、defrag、reservation
拓扑感知	你是否知道同样 GPU 数量性能可能差很多	NVLink、NVSwitch、RDMA、NUMA、NIC affinity
训练/推理混部	你是否能保护在线 SLO	MIG、MPS、time-slicing、priority、isolation
海量小 GPU 作业	你是否能考虑调度器吞吐和显存切分	fractional GPU、best-fit、batch scheduling
弹性训练	你是否能把调度和训练框架语义结合	min/max workers、elastic quota、world size
故障恢复	你是否能把调度和稳定性闭环	DCGM、Xid、drain、reschedule、checkpoint

通用回答骨架

澄清场景

训练/推理/评测/小作业，单 Pod 还是多 Pod，在线还是离线

定义资源

GPU 型号、显存、CPU、内存、网络、存储、拓扑、故障域

确定硬约束

显存够、型号兼容、Gang 满足、SLO 不破、租户 quota 不越界

选择目标

吞吐、等待时间、JCT、公平性、SLO、利用率、成本

设计策略

队列排序、准入、Filter/Score、Backfill、抢占、弹性

工程落地

GPU 插件、节点标签、准入控制、调度扩展、资源看板和监控指标

验证效果

queue time、JCT、GPU util、fragmentation、SLO violation、preemption cost

1. 异构 GPU 调度

典型题目

公司有一个共享训练集群：老节点是 A10 24GB，主力节点是 A100 40GB / 80GB，新采购了一批 H100 80GB。现在用户提交任务只写 gpu: 4，结果出现三类问题：

BERT 微调、图片离线推理这类轻任务占了 H100，成本很高。
70B 模型 SFT 被调到 A10，显存根本不够，反复 OOM。
需要 8 卡 NVLink 的张量并行任务，被拆到多台普通 A100 节点，训练速度很差。

面试官问：你会怎么改造调度系统？

先把题目讲清楚

这里的核心矛盾不是“调度器认不认识 GPU 型号”，而是 nvidia.com/gpu=1 这个资源太粗了。对 CPU 任务来说，1 核 CPU 之间差异相对小；但对 AI 任务来说，1 张 A10、1 张 A100、1 张 H100 完全不是同一种资源。它们的显存、算力、精度能力、互联、价格都不同。

所以要把 GPU 从“数量”升级成“资源画像”。可以把资源规格理解成更有语义的卡型标签：比如 a10-24g、a100-40g、a100-80g-nvlink、h100-80g-nvswitch。面试里不需要绑定某个具体系统名，直接说平台维护一张“GPU 资源规格表”或“卡型资源池”即可。

10 分钟回答展开

资源侧建模

先在集群侧维护 GPU 资源目录，而不是只看 Kubernetes 的 extended resource。每个节点或节点池记录：

字段	例子	为什么重要
型号	A10 / A100 / H100	决定算力、支持精度和成本
显存	24GB / 40GB / 80GB	决定模型能不能放下
互联	PCIe / NVLink / NVSwitch	决定 TP、MoE、AllReduce 性能
网络	普通以太网 / IB / RDMA	决定跨节点训练性能
成本	每小时价格或内部成本权重	避免小任务浪费高端卡
健康状态	正常 / Xid 频发 / ECC 风险	避免把任务调到坏卡

这里最容易混的是“发现卡型”和“改资源名”。可以先拆成三个问题：

问题	谁负责	结果是什么
K8S 知道有几张 GPU	NVIDIA device plugin	节点 `allocatable` 里出现 `nvidia.com/gpu: 8`
K8S 知道是什么卡型	GPU Feature Discovery + Node Feature Discovery	节点 label 里出现 `nvidia.com/gpu.product`、`nvidia.com/gpu.memory`
是否把资源改名 / 切成共享份额	device plugin 的 ConfigMap	例如把 `nvidia.com/gpu` 暴露成 `nvidia.com/gpu.shared`，或者把一张卡切成多个 time-slicing 副本

所以，ConfigMap 确实存在，但它主要配置 device plugin “怎么暴露资源”，不是凭空告诉集群“这台机器是 H100”。卡型信息仍然来自节点上的发现组件读取真实硬件，然后写 Node label。平台再根据这些 label 把节点归入 A10、A100、H100 等资源池；健康状态由 DCGM / Xid 监控实时回写，坏卡自动从可调度资源池里摘掉。

管理员视角可以这样讲：

安装 NVIDIA 驱动和容器运行时

节点上的容器能访问 GPU

部署 NVIDIA device plugin

kubelet 看到 nvidia.com/gpu 这种可分配资源

配置 device plugin ConfigMap

配 MIG、time-slicing、renameByDefault 等资源暴露方式

部署 Node Feature Discovery

集群具备给 Node 写硬件特征 label 的能力

启用 GPU Feature Discovery

读取 GPU 型号、显存、架构、MIG 状态并生成 nvidia.com/* label

检查节点标签和资源名

看 allocatable 里的 nvidia.com/gpu / nvidia.com/gpu.shared，以及 label 里的 gpu.product / gpu.memory

配置资源池/准入规则

调度层用这些标签区分 A10/A100/H100，而不是让用户直接写复杂 label

这里的“发现”不是 Kubernetes 自带能力，也不是装完集群就天然知道卡型；它依赖管理员部署和配置这些组件。所谓自动，是指组件启动后会从节点真实硬件读取信息并持续更新 label，而不是管理员手工维护每台机器的卡型表。

典型 ConfigMap 只解决“资源怎么暴露”的问题，例如 time-slicing：

version: v1
sharing:
  timeSlicing:
    renameByDefault: true
    failRequestsGreaterThanOne: true
    resources:
    - name: nvidia.com/gpu
      replicas: 4

这表示一张物理 GPU 可以被暴露成 4 个 time-slicing 份额；如果 renameByDefault: true，资源名会从 nvidia.com/gpu 变成类似 nvidia.com/gpu.shared。但它并不负责判断这张物理卡是 A10 还是 H100，卡型仍然看节点 label。

任务侧画像

用户不能只填“几张 GPU”。平台要提供更结构化的提交入口，例如：

任务字段	示例	调度含义
最低显存	`>=40GB`	低于这个值直接过滤
可接受卡型	`A100-80G, H100-80G`	A10 不进入候选
首选卡型	`H100`	有 H100 优先，没有再降级
是否需要高速互联	`need_nvlink=true`	多卡任务优先同节点 NVLink / NVSwitch
精度要求	`fp8_required=false`	FP8 必须 H100，BF16 可用 A100
任务类型	训练 / 推理 / 评测 / Notebook	决定抢占、SLO 和队列策略

调度链路

可以分成准入、过滤、打分三步：

准入阶段

先判断租户 quota 和对应卡型资源池是否允许进入队列

过滤阶段

过滤掉显存不够、型号不兼容、拓扑不满足、健康异常的节点

打分阶段

在候选节点中按成本、等待时间、碎片程度、拓扑质量综合打分

绑定阶段

绑定具体节点或资源池，并记录这次任务用了哪个卡型

反馈阶段

采集 OOM、运行时长、GPU 利用率，用于修正任务画像

过滤和打分里最容易被追问的是拓扑：need_nvlink=true 的多卡任务，过滤阶段要求候选节点（或同一 NVSwitch / superpod 域）能一次放下整个 Gang，打分阶段再对“同节点 > 同 superpod > 跨节点”做梯度加分。这一步必须和组调度联动——先按拓扑选定一组满足 minAvailable 的节点再整体绑定，否则会出现 8 卡任务被拆到多台普通节点、训练带宽打不满的情况。

降级策略

降级不能由调度器偷偷决定，要让用户或平台模板显式表达。例如一个 LoRA 微调任务可以写：

preferred: h100-80g
acceptable: [a100-80g, a100-40g]
forbidden: [a10-24g]

如果 H100 紧张，就可以降到 A100；但 70B 推理如果最低显存 80GB，就不能降到 A10。这里体现的是“硬约束”和“偏好”的区别：显存够不够是硬约束，H100 还是 A100 是偏好或成本选择。

指标验证

落地后不能只说“更智能”。要看：

指标	说明
高端卡错配率	H100 被低需求任务占用的比例是否下降
OOM 重试率	因显存不匹配导致的失败是否下降
各卡型资源池等待时间	A10/A100/H100 是否出现单个池子严重拥塞
单位任务成本	同类任务平均 GPU 成本是否下降
性能归一吞吐	同任务在不同卡型上的吞吐是否符合预期

性能归一与跨型号配额

异构集群的配额和公平不能只数“卡数”，因为 1 张 H100 ≠ 1 张 A10。常见做法是给每种卡型一个等价系数（compute-equivalent unit），例如以 A100 为基准，H100 记 2.x、A10 记 0.3，配额、计费、fairshare 都按归一后的 GPU 当量计算。要点是：归一系数和 workload 相关（训练、推理、FP8 任务的相对加速比不同），所以系数应按任务类型分档或定期用真实 benchmark 校准，不能写死一个常数。面试时强调一句：“归一是为了让不同型号可比较和可计费，不是物理真值。”

面试追问

Q: 只用 node label 能不能解决？

label 能表达“节点是什么”，但它不是完整方案。完整方案还需要任务画像、队列配额、准入控制、Filter/Score 策略、降级规则和指标闭环。否则只是把 gpu=true 换成 gpu=h100，仍然解决不了谁能用、什么时候降级、如何避免浪费高端卡的问题。

Q: 卡型资源池分得越细越好吗？

不是。分太粗会错配，分太细会导致资源池碎片化。一般按“影响调度决策的维度”分：型号、显存、互联、成本和故障域是常见维度；驱动小版本、非关键标签不应该随便变成独立资源池。

Q: 存量任务还是只写 gpu: 4，怎么平滑迁移？

不要求用户一次性改全部提交脚本。用准入 webhook 给没有画像的任务注入默认卡型偏好（按队列 / 命名空间 / 镜像推断），同时根据历史运行数据（显存峰值、是否多机、是否用到 NVLink）回填任务画像；再用看板告诉用户“你这个任务其实只要 A100，却占了 H100”，用成本和排队数据推动用户主动填写。先保证不破坏存量，再逐步收紧默认值。

Q: 管理员到底怎么让集群知道这是 A100 还是 H100？

先装 GPU 驱动、容器运行时和 NVIDIA device plugin，让 kubelet 能看到 nvidia.com/gpu；如果要 GPU 共享或改资源名，再配 device plugin 的 ConfigMap，例如 renameByDefault 把共享 GPU 暴露成 nvidia.com/gpu.shared。但卡型识别靠 Node Feature Discovery + GPU Feature Discovery：它们读取本机 GPU 信息并写入 Node label，例如 nvidia.com/gpu.product、nvidia.com/gpu.memory。最后调度层用这些 label 建 A100/H100 资源池。

Q: 把 H100 只留给大任务，结果 H100 经常空着怎么办？

这是“高端卡保护”和“利用率”的经典冲突。纯预留会浪费，纯抢占又伤大任务。常见折中是：H100 池允许低优先级、可抢占、带 checkpoint 的短任务借用，一旦大任务来了用抢占快速回收；同时给借用任务设较短的最大运行时间或要求支持弹性缩容，让回收代价可控。判断标准是 H100 空闲率和大任务排队时间这两个指标同时不恶化。

面试金句：异构 GPU 调度的核心不是“识别型号”，而是把型号、显存、性能和成本变成可调度语义。

2. 多租户配额与弹性借用

典型题目

一个 GPU 集群给搜索、广告、推荐、算法平台四个团队共用。每个团队买了固定配额，比如推荐 200 卡、广告 100 卡、搜索 80 卡。问题是：

白天推荐团队任务少，100 多张卡空着。
广告团队临时做大促实验，排队 300 个任务。
如果完全按硬配额，整体利用率低。
如果谁有任务谁先用，推荐团队晚上提交任务时又拿不回自己的卡。

面试官问：你怎么设计多租户 GPU 配额系统？

先把公平说具体

公平不是“大家平均分”。工业里更常见的是三层语义：

语义	白话解释	例子
guarantee / deserved quota	这个团队应该被保障的资源	推荐团队至少应有 200 卡
borrowing / over-quota	别人不用时，我可以临时多用	广告临时借推荐空闲的 80 卡
reclaim / preemption	原主人要用时，借用者要归还	推荐晚上提交任务，广告 over-quota 任务被回收

10 分钟回答展开

队列模型

每个团队对应一个队列，队列上配置保障配额、最大可借额度、权重和优先级。不要只在 Namespace 上做限制，因为 Namespace 更偏权限边界，Queue 才是调度资源治理边界。

Team Namespace

控制谁能提交、权限和隔离

Team Queue

控制能用多少 GPU、能借多少、如何回收

Resource Pool

管一组真实 GPU 资源池，比如 A100 池或 H100 池

Borrowing Group

多个队列之间允许互相借用的一组共享池

准入策略

任务进入队列时先判断它属于哪个团队、请求哪个卡型资源池、当前队列是否在保障额度内。如果在保障额度内，优先准入；如果超过保障额度，要看共享池是否有空闲，以及该队列是否允许借用。

公平排序

当多个队列都想借资源时，不按简单 FIFO，而按 fairshare 或 quota debt 排序。可以这样解释：

场景	排序倾向
队列长期低于保障配额	应优先补齐
队列已经大量 over-quota	借用优先级降低
高优先级线上修复任务	可以临时插队，但要有审计
低优先级实验任务	可以使用空闲资源，但可抢占

回收策略

回收是这题的重点。不能说“直接抢占”。GPU 训练抢占很贵，所以要分层：

回收方式	适用情况
等待自然结束	原队列不急，借用任务很快结束
禁止新借用	先停止 over-quota 队列继续扩大占用
优雅抢占	通知任务 checkpoint，给宽限期
强制抢占	高优任务、SLO 或配额严重违约时使用

观测和解释

多租户系统最怕“团队觉得不公平”。所以要能解释：某个任务为什么排队、为什么被抢占、当前队列在保障内还是借用中、预计多久能获得资源。

面试追问

Q: Hard quota 和 Elastic quota 怎么选？

Hard quota 简单可解释，但利用率低；Elastic quota 利用率高，但必须配套回收和审计。GPU 集群通常用 elastic quota：保障配额保证底线，空闲借用提升利用率，回收策略保证原队列回来时拿得回资源。

面试金句：多租户 GPU 调度不是“平均分卡”，而是“保障配额 + 空闲借用 + 可解释回收”。

3. Gang / 组调度

典型题目

用户提交一个 PyTorch DDP 训练任务，需要 8 个 worker，每个 worker 1 张 GPU。默认 Kubernetes 一个 Pod 一个 Pod 调度，结果先起来 7 个 Pod，最后 1 个因为没有 GPU 一直 Pending。已经起来的 7 个 Pod 也不能训练，因为 rendezvous 等不到完整 world size，GPU 被白白占住。

面试官问：如何解决这种“部分启动导致资源浪费”的问题？

先解释为什么普通调度不够

普通 Kubernetes 调度器以 Pod 为单位，只关心“这个 Pod 能不能放到某个节点”。但分布式训练的语义是 Job 级别的：8 个 worker 要么一起达到最小可运行规模，要么都不要占资源。这就是 Gang Scheduling，也叫组调度或 All-or-Nothing 调度。

10 分钟回答展开

把 Pod 组建模成一个整体

平台需要引入 PodGroup、Workload 或 Job 级抽象，记录：

字段	示例	含义
minAvailable	8	至少 8 个 worker 到齐才启动
totalReplicas	8	目标 worker 数
resource per replica	1 GPU + CPU + memory	单 worker 资源需求
queue	team-a-training	所属队列
priority	high / normal / low	抢占和排序依据

准入阶段先判断整组是否可满足

不要让 Pod 先进入默认调度再卡住，而是在准入阶段判断：当前队列和资源池是否能同时满足 8 张 GPU、CPU、内存和拓扑要求。满足才放行，不满足就留在队列里。

预留和超时

如果资源是逐步释放的，可以为这个 gang 做 reservation。但 reservation 不能无限占着资源，所以需要超时和回滚：

发现资源即将凑齐

为 PodGroup 预留候选节点

超过等待时间仍不满足

释放 reservation

有更高优任务进入

重新评估 reservation 是否需要被抢占

资源满足

整组 Pod 同时进入绑定流程

和 Backfill 结合

Gang 会带来队头阻塞。比如 64 卡任务暂时凑不齐，不能让空闲 48 卡一直空着。可以允许短任务 backfill，但前提是不破坏大 gang 的预约启动时间。

异常处理

启动后如果某个 worker 失败，要看训练框架是否支持弹性：

情况	处理
不支持弹性 world size	整个 Job 重启或从 checkpoint 恢复
支持 min/max worker	缩到 min 继续跑，后续再扩容
单节点故障	标记坏节点，重新调度缺失 worker
rendezvous 超时	清理半启动 Pod，避免资源泄漏

常见追问

Q: Gang Scheduling 的缺点是什么？

主要是 head-of-line blocking 和资源空等。大任务需要整组资源，如果一直凑不齐，会堵住队列。解决方式是分队列、reservation timeout、backfill、elastic gang、aging，以及把 min/max worker 语义暴露给训练框架。

Q: Gang 和普通优先级抢占怎么结合？

抢占必须 gang-aware。不能只抢一个 Pod，而要判断抢占后是否能让整个 incoming gang 成功启动；victim 也最好按 Job/Gang 粒度选择，避免把别人的分布式训练打残。

4. Backfill：大任务等资源，小任务如何填空

典型题目

训练平台队首是一个 64 卡预训练任务，需要 8 台 8 卡 A100 节点同时空出来。现在集群只有 48 张 A100 空闲，预计 30 分钟后会有两台机器释放。队列后面有很多 1-2 卡的评测、LoRA 微调、小模型推理任务，很多 10 分钟内能跑完。

如果严格 FIFO，48 张 GPU 要空等 30 分钟；如果小任务随便插队，64 卡任务可能永远凑不齐。你怎么设计？

先解释 Backfill 的边界

Backfill 不是“让小任务插队”。它的定义是：在不延迟队首大任务预计启动时间的前提下，用短任务填补暂时用不上的资源空洞。所以关键是有 reservation 和预计运行时长。

10 分钟回答展开

为队首大任务做预约

调度器先估计 64 卡任务最早什么时候能启动。估计依据包括：当前空闲资源、运行中任务预计结束时间、队列配额、可抢占任务、节点拓扑。

选择可回填任务

小任务能不能 backfill，不只看卡数，还要看它是否会破坏预约：

条件	说明
预计运行时间短	必须能在大任务预约时间前结束
可抢占或可重试	估计错误时可以快速让出资源
资源形状匹配碎片	适合填 1-2 卡、小显存、零散 CPU/内存
不占关键拓扑块	不拆掉即将给 64 卡任务用的完整节点组

运行时长如何估计

工业里用户填的时长经常不准，可以用多路信息：

来源	用法
用户声明	作为初始上限，但不完全相信
历史同类任务	按镜像、入口命令、数据集、模型大小预测
在线进度	任务跑起来后修正剩余时间
超时策略	超过声明时长后降低优先级或标为不可 backfill

防止大任务饿死

要给队首任务 aging 和 reservation。也可以设置 backfill 窗口，比如距离预约启动只剩 5 分钟时，不再放新的小任务进去。

指标验证

看 GPU idle time 是否下降、大任务 queue time 是否没有显著增加、reservation miss 是否可控、backfill 任务的超时率是否过高。

面试金句：Backfill 不是让小任务随便插队，而是在不破坏大任务 reservation 的前提下填碎片。

5. 抢占与代价感知

典型题目

线上推荐模型出现质量问题，需要立即启动一个 16 卡紧急修复训练任务。但 A100 池已经满了，里面有低优先级预训练、学生实验、评测任务，还有一些正在借用别人配额的任务。你会不会抢占？如果抢，占谁？

先解释立场

GPU 抢占可以做，但不能像 CPU 短任务那样粗暴。训练任务被 kill 以后可能损失几个小时进度，还要重新拉镜像、加载数据、初始化 NCCL、恢复 checkpoint。所以抢占策略应该是“代价感知的资源回收”，不是简单按优先级杀 Pod。

10 分钟回答展开

victim 选择要考虑：

维度	含义
优先级	低优任务优先被抢
是否借用资源	over-quota / borrowed 任务优先被回收
checkpoint 新鲜度	checkpoint 越新，进度损失越小
已运行时间	刚运行不久的任务沉没成本低
释放资源匹配度	释放的 GPU 型号、数量、拓扑是否正好满足 incoming
重启成本	镜像、数据、NCCL 初始化、模型加载成本
是否 gang	避免只杀分布式任务的一部分

找候选 victim

低优先级、借用资源、可抢占

估算收益

释放 GPU 数量、型号、拓扑、CPU/内存

估算代价

checkpoint age、运行时长、重启成本、SLO 影响

选择集合

最小代价满足 incoming gang

优雅终止

通知 checkpoint，超时强杀

落地时可以分三层：

层次	策略
候选过滤	不抢线上推理、不抢保障配额内高优训练，优先找 over-quota 和低优任务
代价打分	checkpoint 越新、已运行越短、释放资源越匹配，越适合作 victim
执行协议	先发 preempt notice，给任务保存 checkpoint 的宽限期，超时后强杀

面试追问

Q: 为什么不能只按 PriorityClass 抢？

PriorityClass 只能表达重要性，不能表达抢占代价。两个低优任务里，一个刚启动 5 分钟且有 checkpoint，另一个跑了 20 小时还没有保存，如果只看优先级会做出很差的 victim 选择。

面试金句：GPU 抢占不是 kill 低优 Pod，而是用最小进度损失换足够可用资源。

6. GPU 碎片治理

典型题目

监控显示 A100 集群还有 120 张 GPU 空闲，但一个 8 卡单机训练任务一直排队。排查发现每台 8 卡机器都被零散占了 6-7 张卡，只剩 1-2 张。总量够，但凑不出一台完整 8 卡机器。你怎么治理这种碎片？

先解释碎片不是一种

GPU 碎片不是只有“卡数碎片”。AI 任务常见的是多维碎片：GPU 数量、显存、CPU、内存、NVLink 拓扑、队列配额任何一个维度不连续，都会让大任务跑不起来。

10 分钟回答展开

碎片类型	例子	治理方式
卡数碎片	每节点剩 1 卡，8 卡任务跑不了	bin packing、reservation、defrag
显存碎片	同卡剩余显存零散，小显存作业能跑，大显存作业不能跑	best-fit、fractional GPU 分桶
多维碎片	GPU 有剩余但 CPU/内存不够	多维打分、CPU/GPU 配比感知
拓扑碎片	卡数够但 NVLink 域被拆散	保留完整 clique / node group
队列碎片	某队列有资源但无任务，另队列排队	elastic quota / borrowing

回答时先说碎片的类型，再说策略组合：放置阶段用 bin packing 保留大块；队列阶段用 backfill 填小洞；资源池阶段按卡型 / topology 分池；长期用 defrag 或迁移低优任务整理资源。

更具体地说，可以分成四个动作：

调度时尽量紧凑放置：小任务优先 best-fit 到已经被使用的节点，保留完整空节点给大任务。
按拓扑保留大块资源：8 卡 NVSwitch 节点不要随便拆给零散任务；可以维护 full-node pool。
用 Backfill 填短洞：短任务可以填碎片，但不能破坏大任务 reservation。
低峰期整理资源：对可抢占、checkpoint 新鲜的低优任务做迁移或重启，整理出连续节点。

面试追问

Q: bin packing 和 spread 该选哪个？

离线训练更常用 bin packing，因为要保留完整节点和拓扑块；在线推理可能需要 spread 来降低单点故障和热点风险。不能脱离任务类型说固定答案。

7. 拓扑感知调度

典型题目

一个 8 卡张量并行任务，放在单台 H100 NVSwitch 机器上吞吐很高；但如果调度到 4 台机器、每台 2 卡，训练速度掉了一大截。用户说“我明明也拿到了 8 张 GPU”，你怎么解释？调度器怎么避免这种放置？

先解释性能差在哪里

GPU 训练不是只消耗计算，还大量消耗通信。张量并行 TP 的通信频率很高，几乎每层都有 AllReduce / AllGather。如果 8 张卡在同一 NVSwitch 域，通信走节点内高速互联；如果跨多机，就要走 NIC、RDMA、交换机，延迟和带宽都差很多。

10 分钟回答展开

并行策略	通信特征	放置偏好
TP	每层高频 AllReduce/AllGather	同节点 NVLink/NVSwitch
PP	相邻 stage 传 activation	相邻 stage 尽量近
DP	每步梯度 AllReduce	可跨节点，但需要 RDMA
EP/MoE	All-to-All	避免跨拥塞域

落地方式：

短期：node label + scheduler plugin + GPU/NIC/NUMA 拓扑缓存。
中期：device plugin 上报拓扑信息，调度器自定义 Score。
长期：DRA / ResourceSlice 表达设备级属性和拓扑。

更具体的调度链路可以这样说：

任务声明并行策略

TP/PP/DP/EP，不同策略通信图不同

构建设备拓扑图

GPU-GPU、GPU-NIC、NUMA、节点、机架

Filter

过滤掉不满足最低拓扑要求的候选

Score

给同 NVSwitch、同节点、同机架、跨机架不同代价

Bind

同时绑定 GPU 和 rank 映射，避免 rank 随机落位

Observe

采集 NCCL 带宽、step time、重传、IB 拥塞验证效果

面试追问

Q: DP 任务也必须同节点吗？

不一定。DP 主要每个 step 做梯度同步，通信频率低于 TP，可以跨节点，只要 RDMA 和网络收敛比足够。TP 更强依赖节点内 NVLink/NVSwitch，PP 关注相邻 stage 的链路，MoE/EP 关注 All-to-All 和拥塞域。

面试金句：拓扑感知调度优化的是 rank 通信图到硬件拓扑图的映射代价。

8. 训练和推理混部

典型题目

线上推理服务白天高峰需要稳定 P99，夜间低峰 GPU 利用率只有 25%。离线训练团队希望复用这些 GPU 跑低优先级训练和评测。但一旦混部，推理 P99 抖动、显存被挤占、模型加载变慢。你怎么设计训练和推理混部？

先定原则

在线推理的 SLO 是硬约束，离线训练是可让步任务。混部的目标不是“所有任务都尽量塞满”，而是在不破坏 P99 / TTFT / TPOT 的前提下吃掉低峰资源。

10 分钟回答展开

隔离方式	隔离强度	适用场景
物理节点隔离	最强	核心在线推理，严格 SLO
MIG	强	A100/H100 上推理 + 小任务混部
MPS	中	可接受一定干扰的多进程共享
Time slicing	弱	离线推理、实验任务
只按优先级抢占	弱	可重试低优训练任务

回答要点：

推理 SLO 是硬约束，训练是可让步任务。
先用节点池或 MIG 保护强 SLO 推理。
对可混部场景，用限额、优先级、监控和自动驱逐保护推理。
观测 P99、TPOT、GPU memory、SM/HBM、context switch 和训练吞吐。

可以把方案拆成三档：

档位	场景	方案
核心在线服务	搜索、广告、支付风控等强 SLO	物理隔离或独占 MIG，不和训练混
普通在线推理	P99 有要求但低峰明显	低峰允许可抢占离线任务进入，指标异常自动驱逐
离线推理/评测	SLO 弱，吞吐优先	MPS / time slicing / fractional GPU 提高利用率

混部还需要运行时控制：训练任务必须带低优先级、可抢占、显存上限；推理服务指标异常时，调度器或控制器触发驱逐；被驱逐训练任务从 checkpoint 或任务队列重试。

面试追问

Q: MIG、MPS、time slicing 有什么区别？

MIG 是硬件级切分，隔离强，适合保护推理；MPS 是多个进程共享 GPU 执行上下文，利用率高但隔离弱；time slicing 是时间片轮转，适合低优实验或离线任务，不适合强 SLO 推理。

9. 海量小 GPU 作业调度

典型题目

平台每天有几千万个 C++ / Python 小作业，单个作业只用 2-6GB 显存，运行几十秒到几分钟。它们如果每个独占一张 24GB 或 80GB GPU，利用率非常低；但如果同卡多进程，又容易 OOM、CPU/内存不够、调度器吞吐扛不住。

这个场景已经在“海量小显存作业”子页单独展开，核心是：显存主导的在线多维装箱 + 高吞吐批量调度。

10 分钟回答展开

资源画像

actual gpu_mem/cpu/mem/duration

GPU 卡型分池

型号和显存容量隔离

候选索引

remaining memory buckets + machine residual CPU/mem

Best-fit

减少显存碎片，保留大块资源

Batch scheduling

支撑几千万作业规模

反馈预测

修正用户申报，降低 OOM 和过度预留

展开时要补充三点：

问题	具体回答
为什么不能一作业一 GPU	小作业只用几 GB 显存，独占会造成显存和 SM 浪费
为什么不能简单超卖	用户申报不准，同卡 OOM 会互相影响，还会挤占 CPU/内存
调度器怎么扛吞吐	候选节点索引、批量调度、增量缓存、按剩余显存 bucket 做 best-fit

10. 弹性训练调度

典型题目

一个推荐模型训练任务最好用 8 个 worker，但 4 个 worker 也能先跑，只是速度慢一点。用户希望资源紧张时先用 4 卡启动，夜间资源多了扩到 8 卡；如果某个节点故障，也希望先缩到 6 卡继续，而不是整个任务失败。

面试官问：调度器如何支持弹性训练？

先说明弹性不是调度器单独能做

弹性训练需要三方配合：调度器负责资源变化，训练框架负责 world size 变化后的 rendezvous 和数据切分，任务代码负责 batch size、学习率、checkpoint 等语义一致性。只说“调度器扩缩容 Pod”是不完整的。

10 分钟回答展开

问题	方案
如何表达弹性	`min/target/max` workers，或 elastic workload
如何准入	至少满足 min 才启动，target/max 作为扩容目标
如何扩容	有空闲资源时增加 worker，训练框架重建 rendezvous
如何缩容	节点故障或抢占时减少 worker，继续训练
一致性风险	world size 变化影响 batch size、学习率、BN、数据切分
调度风险	扩容不能无限抢占别人，要受 quota/fairshare 约束

具体链路：

提交任务

声明 min=4 target=8 max=8

准入启动

资源达到 min 后先启动

运行监控

观察训练吞吐、队列资源、故障事件

扩容

空闲资源满足 fairshare 时增加 worker，并触发 rendezvous

缩容

节点故障或配额回收时减少 worker，训练框架重建通信组

语义修正

调整 global batch、学习率、数据 shard、checkpoint 元信息

面试追问

Q: 所有分布式训练都适合弹性吗？

不是。DP 维度通常更容易弹性，因为多几个或少几个 data parallel worker 比较自然；TP/PP 改 world size 会改变模型切分，代价很高。所以大模型训练常见做法是固定 TP/PP，优先弹性 DP。

面试金句：弹性训练不是单纯调度问题，它要求调度器、训练框架和 checkpoint/rendezvous 协同。

11. 故障感知调度

典型题目

GPU 集群里经常出现这些问题：某张卡频繁 Xid 错误，某台机器 ECC error 增多，某个机架 IB 丢包，节点偶发 NotReady。用户抱怨任务刚调度上去就失败，或者 NCCL hang 很久才超时。你怎么让调度系统具备故障感知能力？

先解释调度和故障的关系

故障感知调度不是只在任务失败后重试。更好的系统要做到三件事：坏资源不要再被分配，运行中故障能快速隔离，恢复后资源能有审计地重新加入集群。

10 分钟回答展开

健康采集

DCGM / node exporter / kubelet condition / IB metrics

资源标记

node taint、GPU device health、unschedulable

调度过滤

Filter 阶段排除坏卡、坏节点、拥塞域

任务恢复

重调度、弹性缩容、checkpoint 重启

闭环治理

故障统计、自动隔离、维修后恢复、容量扣减

指标：

GPU Xid / ECC / temperature / power。
NVLink error、PCIe replay、IB symbol error。
Node condition、kubelet/runtime health。
任务失败率、重试率、checkpoint 恢复时间。

落地动作可以更具体：

阶段	动作
采集	DCGM 采集 Xid/ECC/温度/功耗，网络侧采集 IB 错误和丢包
判定	区分临时抖动、可恢复错误、需要隔离的硬故障
标记	对坏卡、坏节点、坏拓扑域打 taint 或标记 unschedulable
调度	Filter 阶段排除坏资源，Score 阶段降低风险节点权重
运行中恢复	触发重调度、弹性缩容或 checkpoint 恢复
闭环	维修后通过 burn-in 测试，再自动或人工恢复调度

面试追问

Q: 为什么不能所有失败都直接重试？

如果根因是坏卡或坏网络，直接重试可能又调回同一类资源，形成失败风暴。故障感知调度要先隔离异常资源，再决定任务是重试、缩容、迁移还是从 checkpoint 恢复。

工业落地层次

层次	适合回答的点
Kubernetes 基础层	Device plugin 注册 GPU 数量，Node label 表达卡型和硬件特征，scheduler 做 Filter/Score/Preemption
批调度层	Job / PodGroup / Queue / Reservation 表达分布式训练、队列公平和大任务预约
平台准入层	根据租户、任务画像、卡型资源池、配额和优先级决定任务能不能进入调度
调度扩展层	深度定制拓扑、干扰预测、显存切分、抢占代价和训练框架语义
监控闭环层	DCGM、Xid、NCCL、队列等待、GPU 利用率和成本指标反向修正策略

参考资料

Kubernetes docs: scheduler framework、PriorityClass、preemption、node affinity。
NVIDIA k8s-device-plugin docs: device plugin、MIG strategy、time-slicing。
NVIDIA GPU Feature Discovery docs: GPU feature labels、NFD integration。
NVIDIA GPU Operator docs: device plugin、Node Feature Discovery、GPU Feature Discovery、MIG Manager、DCGM Exporter。
Volcano docs: Gang Scheduling、Queue Resource Management、Binpack、Preempt / Reclaim。

关联模块

多资源公平调度：DRF、Elastic Quota、借用和回收。
批调度、Gang 与 Backfill：组调度、回填、抢占和 checkpoint。
拓扑感知调度：GPU/NIC/NUMA/NVLink/RDMA 放置。
海量小显存 GPU 作业调度：短作业高吞吐和 fractional GPU 装箱。

一句话结论

GPU 集群调度不是"找一台有空 GPU 的机器"，而是在 workload 语义、多资源公平、拓扑质量、GPU 碎片、抢占代价和可观测之间做权衡；一个完整调度器要回答五个决策点：谁先调度（QueueSort）、能不能启动（Admit）、放到哪里（Placement）、是否抢占（Preemption）、运行后如何回收重试（运行时控制）。

复习定位

维度	内容
所属模块	任务调度理论
章节类型	系统类
解决问题	围绕经典算法、多资源公平、Gang/Backfill、拓扑感知和抢占代价建立 GPU 集群调度理论答案。
面试抓手	回答时先定范围，再讲核心链路，最后落到工程风险和面试追问。

调度面试题精讲：直接回答问题，不讲路线图

这一页只解决一个问题：面试官问到 AI Infra / GPU 集群调度时，应该怎么理解、怎么回答、怎么展开。每个问题都按“核心概念 → 标准回答 → 设计落点 → 常见追问”的方式组织。

总口径：GPU 集群调度不是“找一台有空 GPU 的机器”，而是在 workload 语义、多资源公平、拓扑质量、GPU 碎片、抢占代价和系统可观测之间做权衡。

先建立统一模型：调度器到底在做什么

调度器的输入是任务和资源，输出是调度决策。一个完整调度器至少要回答五个问题：谁先调度、能不能运行、放到哪里、是否要抢占、运行后如何回收/重试。

决策点	要回答的问题	常用机制	AI Infra 特殊点
排序 QueueSort	谁先被考虑	FIFO、优先级、SJF、DRF/QAD、aging	长短任务混部，不能简单 FIFO
准入 Admit	这个任务现在能不能启动	quota、gang、minAvailable、reservation	训练任务需要 all-or-nothing
放置 Placement	放到哪些节点/哪些 GPU	Filter/Score、bin packing、拓扑打分	同样 8 卡，NVLink/跨节点性能差异巨大
抢占 Preemption	高优任务来了谁让位	Priority、checkpoint-aware cost、reclaim	训练抢占会丢进度、重建通信组
运行时控制	失败、扩缩容、资源回收怎么处理	checkpoint、retry、elastic training、health check	NCCL hang、GPU Xid、节点失联都要处理

Q1：如果有一个 GPU 集群，如何设计一个任务调度器？

标准回答：我会把它设计成“队列层 + 准入层 + 放置层 + 运行时控制层 + 观测层”的调度系统，而不是只做一个节点打分器。

任务抽象：区分训练、推理、评测、数据处理。训练任务需要 gang、checkpoint 和拓扑；推理任务关注 SLA 和弹性扩缩；评测/数据任务更像批处理。
资源抽象：GPU 不只看数量，还要看型号、显存、CPU、内存、RDMA/NIC、NVLink、机架、存储、本地 NVMe 和故障域。
队列层：按团队/项目建层级队列，配置 min/max quota、优先级、可借用资源和回收策略。
准入层：检查 quota、gang minAvailable、GPU flavor、拓扑硬约束。资源不够时可以 reservation，而不是让部分 worker 先跑。
放置层：Filter 过滤不可行节点，Score 综合 bin packing、拓扑质量、碎片影响、故障域、数据 locality。
抢占与回收：高优任务或保障队列资源不足时，按 checkpoint 新鲜度、重启成本和释放资源价值选择牺牲者。
运行时控制：支持重试、checkpoint 恢复、elastic training 扩缩容、节点/GPU 健康检查。
观测层：暴露 pending 原因、等待时间、JCT、利用率、公平性、抢占损失、失败率和拓扑命中率。

一句话答案：先做多租户队列和 gang 准入，再做拓扑感知 placement，最后用 backfill、抢占和 elastic training 提高利用率。

Q2：多租户场景下，如何保证不同用户/团队之间的公平性？

核心概念：公平不是平均分 GPU，而是“有保障、有上限、可借用、可回收”。在多资源场景里，公平通常要看 dominant resource，即一个租户最紧张的资源份额。

机制	作用	怎么回答
层级队列	把公司/部门/团队/项目组织成资源治理树	每层都有 quota 和优先级，避免全局 FIFO 被大团队占满
min quota	保障资源	团队至少能拿到承诺份额，适合关键业务
max quota	限制上限	防止某个团队无限扩张
borrowing	提升利用率	别人不用时可以借，但要记录 debt
reclaim	保证公平回收	owner 需要资源时，从 borrower 低优任务回收
DRF / QAD	度量多资源公平	按主导资源份额或 quota 满足度排序
aging	防止饥饿	等待越久动态优先级越高

标准回答：我会使用层级队列 + min/max quota + DRF/QAD 排序。空闲资源允许借用，但借用资源要可回收；当保障队列资源不足时，优先抢占借用资源上的低优任务。为避免低优任务长期饥饿，需要 aging 和最大等待时间兜底。

Q3：如何处理高优任务抢占低优任务？抢占有什么代价？

标准回答：抢占不能简单“优先级高就杀低优任务”。AI 训练里抢占代价很高，需要做 checkpoint-aware preemption。

抢占代价	具体含义	设计对策
训练进度损失	回滚到上一次 checkpoint，checkpoint 之后的 step 白跑	优先抢 checkpoint 新鲜、沉没成本低的任务
重启成本	重新排队、拉镜像、加载模型、加载数据	镜像预热、模型缓存、本地缓存
通信重建	NCCL world、rank、通信组需要重建	gang 级别重启，避免只杀一部分 worker
系统抖动	大量 Pod 删除/重建冲击 API Server 和调度器	分批抢占、抢占限速、冷却时间
用户体验	低优用户训练频繁被打断	抢占次数上限、aging、可抢占队列说明

$$\text{victim\_score} = \text{release\_value} / (\text{checkpoint\_age} + \text{restart\_cost} + \text{disruption\_penalty})$$

面试展开：先判断高优任务需要释放哪些资源，再找能释放目标资源且代价最低的 victim；抢占前尽量发优雅退出信号让任务保存 checkpoint，超时后再强制终止。

Q4：如何避免 GPU 碎片？8 卡任务为什么可能跑不起来？

核心概念：GPU 碎片不是“总 GPU 不够”，而是“满足任务约束的连续/同拓扑资源不够”。例如集群剩 8 张 GPU，但分散在 8 台机器上，每台 1 张；一个需要单机 8 卡 NVLink 的任务仍然无法运行。

方法	解决什么	代价
Bin Packing	小任务尽量塞满已有节点，保留完整空节点	热点和故障爆炸半径增加
Topology-aware placement	保留完整 NVLink / 机架 / RDMA 域	等待时间可能增加
Reservation	为大 gang 任务预留未来资源窗口	短期利用率下降
Backfill	大任务等资源时，用短任务填碎片	依赖运行时间预测
Defragmentation	迁移/抢占低优任务合并资源	有重启和进度损失
资源池分层	按 GPU 型号、拓扑域、队列隔离	池子太细会降低整体利用率

标准回答：我会在 Score 阶段引入碎片惩罚：小任务优先填已有节点，大任务优先拿完整拓扑；队列层用 reservation 保护大任务，用 backfill 填补等待窗口。必要时做 checkpoint-aware defragmentation。

Q5：如何设计队列、优先级和配额系统？

标准回答：队列系统要同时表达组织结构、资源保障、业务优先级和弹性借用。

设计项	建议方案	原因
队列结构	层级队列：部门 / 团队 / 项目	方便组织级资源治理和审计
配额	min quota + max quota + flavor quota	既保障基本资源，又限制无限扩张；H100/A100 要分开
优先级	业务优先级 + 队列优先级 + aging	同时支持紧急任务和长期公平
借用	空闲资源可跨队列借用	提高利用率
回收	owner 资源不足时从 borrower 回收	保证配额承诺兑现
审计	记录 quota usage、borrow debt、preemption history	让用户知道为什么排队或被抢占

追问回答：如果面试官问“为什么不用 ResourceQuota”，回答：ResourceQuota 只能限制 namespace 资源用量，不解决队列排序、DRF 公平、借用回收、gang 准入和 GPU 拓扑放置。

Q6：如何支持 Elastic Training / 弹性训练？

核心概念：弹性训练允许任务在 min/max worker 范围内运行。例如 min=16、target=64、max=128；达到 min 就能启动，资源充足后扩容，资源紧张时缩容。

组件	要做什么	难点
任务 API	声明 min/target/max、弹性策略、扩缩容冷却时间	用户要能表达效率和资源的 trade-off
调度器	min 满足即准入，空闲资源可增量分配	扩容不能破坏高优 reservation
训练框架	支持 world size / rank membership 变化	NCCL 通信组、优化器状态、数据分片一致性
Checkpoint	扩缩容前后保持状态一致	I/O 压力和恢复时间
监控	观察扩缩容后吞吐是否真的提升	不是卡越多越快，通信可能成为瓶颈

标准回答：弹性训练用更复杂的训练框架能力换更短等待时间和更高集群利用率。它不是调度器单独能完成的，必须训练框架、checkpoint、数据加载和调度器一起支持。

Q7：如何处理长任务和短任务混部？

标准回答：不能只用 FIFO，也不能只用 SJF。FIFO 会让短任务被队头长任务阻塞；SJF 会让长任务饥饿。实际系统要结合多队列、aging、backfill、quota 和抢占成本。

策略	解决的问题	注意点
多队列	交互式短任务、长期训练、best-effort 分开治理	队列之间要有公平共享
SJF / 预测排序	降低平均等待时间	长任务要 aging 兜底
Backfill	短任务利用大任务等待窗口	不能破坏大任务 reservation
Quota	保证长任务也有资源份额	过硬会降低利用率
Preemption	高优短任务快速启动	要考虑 checkpoint 和重启成本

一句话：短任务要低等待，长任务要不饥饿；用 backfill 提高利用率，用 aging/quota 保证长期公平。

Q8：如何判断任务应该立即运行，还是等待更好的资源组合？

核心概念：立即运行降低等待时间，但可能拿到差拓扑、导致训练变慢或制造碎片；等待更好资源提高运行效率，但增加排队时间。

维度	倾向立即运行	倾向等待
任务时长	短任务，等待成本占比高	长训练，拓扑差会长期放大损失
通信强度	单卡、小 DP、低通信	TP/MoE/NCCL-heavy
拓扑影响	差拓扑只损失少量吞吐	差拓扑可能导致 step time 翻倍
碎片影响	不会打散完整节点	会破坏未来大任务资源窗口
优先级	高优/交互式任务	低优/best-effort 任务
预测置信度	不知道何时有更好资源	能预测某批资源很快释放

$$\text{schedule now if } \text{waiting\_cost} > \text{performance\_loss} + \text{fragmentation\_cost}$$

标准回答：我会给每个候选 placement 计算拓扑质量和碎片代价；如果当前 placement 的性能损失和碎片代价小于继续等待的成本，就立即运行；否则做 reservation，并允许短任务 backfill。

Q9：K8s 默认调度器为什么不够？

标准回答：K8s 默认调度器适合通用 Pod 放置，但 AI 训练需要队列公平、gang 语义、拓扑感知、GPU 设备属性和训练运行时控制。

不足	具体问题	需要的扩展
缺少 gang 语义	Pod 独立调度，部分 worker 先启动会造成 GPU 空转	PodGroup、Permit、Volcano/Kueue
队列公平不足	PriorityClass 不等于多租户公平	DRF、Elastic Quota、QAD、层级队列
GPU 拓扑弱	只看 GPU 数量，不理解 NVLink/NIC/NUMA	DRA、拓扑打分、自定义 plugin
抢占代价粗糙	默认抢占不了解 checkpoint 和训练进度	checkpoint-aware preemption
弹性训练弱	固定副本数，不表达 min/target/max	TrainingJob CRD、elastic controller

Q: 面试官让你一句话总结 GPU 调度难点，怎么说？

推荐回答

GPU 调度难在它同时是多资源、多租户、强拓扑、强同步、抢占代价高的问题。CPU 调度主要分配时间片，而 GPU 训练调度要分配一组满足拓扑和 gang 语义的设备，并且要在公平性、利用率、等待时间和训练效率之间权衡。

展开顺序

先说 gang：多 worker 必须一起启动；再说拓扑：不同 placement 训练性能差异大；再说碎片：总卡数够不代表可调度；再说公平：多团队共享要有 quota；最后说抢占：训练任务被打断有 checkpoint 和重启代价。

不要只说“资源昂贵”，要说清楚昂贵资源为什么难调度。

Q: 如果让你现场画架构图，应该画哪些模块？

模块清单

画用户提交入口、TrainingJob/InferenceJob API、队列管理器、Quota/Fairness 控制器、Scheduler、Topology/Resource Cache、Preemption/Reclaim 控制器、Job Controller、Checkpoint/Retry 控制器、Metrics/Events/Tracing。

数据流

任务提交后进入队列；队列管理器计算公平排序；scheduler 做 gang 准入和 placement；资源不足时 reservation/backfill；高优任务触发 reclaim/preemption；运行中由 controller 监控状态并处理失败恢复。

架构图要体现“队列公平 + gang 准入 + 拓扑放置 + 运行时恢复”，不要只画一个 scheduler 方框。

关联模块

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

一句话结论

多租户 GPU 调度系统的设计主线是「在公平和效率之间持续权衡」：用 QAD 连续保障度替代二元配额、DRA 弹性借用闲置资源、词典序排序先补最欠缺的租户、代价基抢占和干扰感知合用提利用率，并以 K8s Scheduler Plugin 落地。答题要先分 workload 和资源维度，再讲队列、调度流水线和 AI 特有点。

复习定位

维度	内容
所属模块	任务调度理论
章节类型	系统设计类
解决问题	围绕 GPU 集群调度、多租户公平、海量短作业装箱和吞吐优化形成可复述设计题框架。
面试抓手	回答时先定范围，再讲核心链路，最后落到工程风险和面试追问。

题目

设计一个多团队共享的 GPU 训练集群调度系统，要求公平且高效。

设计要点

配额管理
- QAD 连续信号替代二元配额（有/没有）
- DRA 弹性借用：闲置资源可借，需要时按 QAD 优先级回收
调度排序
- 词典序 (QAD↑, T̂↑)：先满足最欠缺的租户，同等 QAD 下短作业优先
- 代价基抢占：综合释放资源量和沉没成本
资源共享
- 干扰感知合用：RF 预测性能保持率 → 高于阈值才合用
- 运行时监控 + 驱逐机制保护主任务
K8s 原生
- Scheduler Plugin 覆盖 5 个扩展点
- DaemonSet 部署 MPS daemon + DCGM 监控
- Lease-based 选主保证高可用

开放题：设计面向大模型训练任务的 GPU 集群调度系统

这类题不要直接跳到某个算法。推荐按“任务抽象 → 资源抽象 → 调度目标 → 调度策略 → 拓扑感知 → 故障处理 → 观测系统 → 性能优化”的顺序回答。这样既覆盖系统边界，也能体现你知道 AI Infra 和普通 K8s 调度的差异。

1. 任务抽象：不同任务的调度语义不同

任务类型	调度特点	关键字段	控制器/对象
大模型训练任务	多 worker、强同步、需要 gang、运行时间长	world_size、min/target/max、并行策略、checkpoint	TrainingJob / VolcanoJob / PyTorchJob
在线推理任务	长期服务、SLA、流量波动、可水平扩缩容	模型、QPS、SLO、显存、batch 策略	Deployment / InferenceService
评测任务	批处理、可排队、通常可重试	数据集、模型版本、并发度、deadline	Job / Workflow
数据处理任务	I/O 密集、存储和网络敏感	输入路径、输出路径、CPU/内存/IOPS	Job / SparkApplication

2. 资源抽象：不能只抽象成 GPU 数量

资源	为什么重要	调度表达
GPU 型号	H100/A100/V100 性能和能力不同	ResourceFlavor、node label、extended resource
显存	模型能否放下、batch size 上限	GPU memory profile、MIG slice、DRA attributes
CPU / 内存	数据加载、预处理、通信线程	requests/limits、NUMA 亲和
网络	NCCL、RDMA、跨节点 AllReduce	NIC 亲和、机架/交换机拓扑
存储	数据集读取、checkpoint 写入	存储类型、本地 NVMe、带宽/IOPS
拓扑	同机、同交换机、跨机通信代价不同	Topology score、DRA ResourceSlice、scheduler plugin

3. 调度目标：先定硬约束，再定优化目标

目标	含义	对应策略	牺牲项
高利用率	减少 GPU 空闲和碎片	bin packing、backfill、GPU sharing	故障隔离、热点、SLA
低等待时间	任务提交后尽快开始	SJF、优先级、预留、弹性训练	拓扑质量、全局最优
公平性	团队之间按份额获得资源	DRF、quota、QAD、aging	短期吞吐
SLA	在线推理和关键任务不能违约	优先级、预留、抢占、隔离池	离线利用率
成本	用更少 GPU 完成更多任务	性能预测、混部、低优任务填充	系统复杂度

4. 调度策略：队列、配额、抢占、回填组合使用

队列准入：任务进入团队队列，检查 quota、优先级、GPU flavor 和 gang 需求。
排序：先按保障度/QAD 和优先级排序，同等级内可以用 SJF 或 aging。
Gang 准入：训练任务必须满足 minAvailable，否则不启动任何 worker。
放置：Filter 检查资源和硬约束，Score 综合 bin packing、拓扑、碎片、故障域。
回填：队头大任务等资源时，允许短任务利用碎片窗口。
抢占：高优任务或保障租户不足时，按 checkpoint-aware cost 回收低优任务。
运行时调整：支持 elastic training 扩缩容，或根据干扰/故障触发迁移和重试。

5. 拓扑感知：同样 8 卡，性能可能完全不同

并行方式	通信模式	放置偏好
张量并行 TP	每层 AllReduce/AllGather	同节点 NVLink/NVSwitch
流水线并行 PP	相邻 stage P2P	相邻 stage 尽量同机柜/低延迟网络
数据并行 DP	每步梯度 AllReduce	可跨节点，但要 RDMA 网络质量好
专家并行 EP	All-to-All	尽量避免跨拥塞域

6. 故障处理：训练任务的失败成本更高

故障	检测	处理
节点失联	Node heartbeat、Pod event	标记节点不可调度，任务从 checkpoint 重启
GPU 故障	DCGM、ECC/Xid、健康检查	隔离 GPU，驱逐相关任务，触发重调度
NCCL hang	训练心跳、step time 超时	dump 日志，重建通信组或整组重启
存储故障	I/O error、checkpoint timeout	重试、切换副本、降低 checkpoint 频率
抢占	队列回收或高优任务到达	优雅 checkpoint 后退出，超时强制终止

7. 观测系统：没有指标就无法调度优化

观测对象	关键指标	用途
任务状态	Pending/Running/Failed、等待原因、重试次数	解释任务为什么没跑
资源利用率	GPU util、SM Active、显存、CPU、网络、存储	判断瓶颈和资源浪费
调度指标	waiting time、JCT、队列长度、backfill 命中率	评估调度策略效果
公平性	QAD、dominant share、quota debt	判断租户是否被保障
失败率	节点故障、GPU Xid、NCCL error、OOM	做故障治理和容量规划

8. 性能优化：碎片、局部性和预测

优化方向	方法	收益
减少碎片	bin packing、reservation、defragmentation	大任务更容易启动
提升 locality	拓扑打分、GPU-NIC 亲和、同机/同机柜优先	降低通信开销
结合性能预测	预测不同 placement 的 step time 或 JCT	更准确地判断是否等待更好资源
提升启动速度	镜像预热、模型缓存、本地数据缓存	降低 cold start 和 JCT
混部优化	干扰预测、MIG/MPS、低优任务填空	提升利用率但保护主任务

回答结构

先明确 workload：训练、推理、评测、数据处理，不同任务调度语义不同。
再定义资源：GPU 不只是数量，还包括型号、显存、拓扑、网络、存储和故障域。
然后讲队列系统：多租户用层级队列、min/max quota、DRF/QAD、公平借用和回收。
接着讲调度流水线：排序、gang 准入、Filter/Score、拓扑放置、backfill、抢占。
补充 AI 特有点：GPU 碎片、NCCL、checkpoint、elastic training、拓扑感知和性能预测。
最后讲可观测和容错：等待原因、资源利用率、失败率、checkpoint 恢复和健康检查。

面试金句：GPU 集群调度不是“找有空 GPU 的节点”，而是在多租户公平、gang 语义、拓扑质量、碎片治理和抢占代价之间做持续权衡。

追问方向

追问：怎么处理大任务和小任务的矛盾？

大任务（需要 64 GPU）和小任务（需要 1 GPU）的调度矛盾：(1) Gang scheduling 保证大任务原子性。(2) Backfill 让小任务见缝插针。(3) 大任务可以拆分为弹性训练（先用 32 GPU 开始，有空闲再扩到 64）。(4) 预留机制：为大任务预留资源窗口，避免永远等不到足够资源。

追问：如何处理异构 GPU？

(1) ResourceFlavor 区分不同 GPU 型号（A100/H100/V100）。(2) 运行时间预测模型需要区分 GPU 类型——同样的作业在 A100 和 H100 上时间不同。(3) 价格/性能比引导调度：不紧急的任务用便宜 GPU，紧急任务用高端 GPU。(4) 混合精度兼容性：H100 支持 FP8，A100 只支持到 FP16/BF16。

关联模块

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

题目描述

已有一个 GPU 集群调度平台，现在要在这个平台基础上优化调度策略。集群由一批机器组成，每台机器有若干张 GPU 卡；GPU 型号不同，显存容量不同；每台机器的 CPU、内存和 GPU 配比也不固定，也就是“一张卡对应多少 CPU / host memory”并不一致。

作业侧的特点是：每天有几千万个作业，每个作业本质上是一个 C++ 进程；每个作业只占几 GB GPU 显存，通常打不满一张卡，同时还会消耗一定 CPU 和 host memory；单个作业运行几分钟到几十分钟，运行完成后释放资源。题目目标是在平台已经存在的前提下，把这些海量短作业更高效地调度到 GPU 卡和机器上，提高整体资源利用率，并最大化作业吞吐量。

输入、输出与约束

类别	内容	需要澄清的点
输入资源	机器、GPU 型号、GPU 显存、CPU、host memory、当前占用	是否能拿到每张卡剩余显存和每台机器剩余 CPU/内存
输入作业	C++ 进程、GPU 显存需求、CPU/内存需求、预计运行时长、优先级	作业资源是用户申报、历史画像，还是平台可预测
输出决策	作业放到哪台机器、哪张 GPU、同卡并发多少	需要原子 reserve，避免并发调度重复分配
硬约束	显存必须够，CPU/内存必须够，GPU 型号必须兼容	显存是主瓶颈，但不是唯一约束
优化目标	GPU 显存利用率、作业吞吐、队列等待时间、失败率	不能只看平均 GPU-Util
规模约束	每天几千万作业	调度器自身吞吐和候选召回效率非常关键

非目标

非目标	为什么先不做
从零设计调度平台	题设说平台已经存在，重点是改造调度策略和观测闭环
大模型训练 Gang Scheduling	本题作业是单进程短作业，不是多 worker 同起同停
复杂拓扑感知训练调度	每个作业只占几 GB 显存，核心矛盾先是同卡装箱和机器多维配比
只追求单作业性能最优	目标是整体吞吐和利用率，允许在可控范围内做同卡并发

一句话结论

这个场景的本质是海量短作业在异构 GPU 集群上的在线多维装箱问题。调度器不是给每个作业独占一张 GPU，而是把 GPU 显存当成主要可切分资源，同时把 CPU 和 host memory 作为硬约束；先补齐资源画像和调度观测，再做 GPU flavor 分池、候选机器快速索引、显存主导 best-fit / bin packing、短作业 backfill 和运行时反馈校准，最后再引入预测和批量调度优化吞吐。

题目边界

维度	题设信息	调度含义
集群	多台机器，每台若干 GPU，GPU 型号和显存不同	需要按 GPU flavor / memory capacity 分池
配比	每台机器 CPU/内存/GPU 配比不固定	不能只看 GPU 显存，还要防 CPU/内存成为残余瓶颈
作业	每天几千万个 C++ 进程，几分钟到几十分钟	高 QPS 在线调度，调度器吞吐和队列系统本身是关键
资源	每个作业用几 GB 显存，同时消耗 CPU/内存	显存是主瓶颈，但必须做多维约束过滤
目标	提高整体资源利用效率、最大化吞吐	优先减少 GPU 显存碎片和机器残余资源浪费
前提	平台已经存在	不是从零造平台，而是分阶段改造调度策略和观测闭环

总体思路

先建画像

作业资源需求、运行时长、GPU 型号、机器 CPU/内存/GPU 配比

再分资源池

按 GPU 型号/显存容量/机器配比拆池，避免强弱卡混用

做快速匹配

维护每张卡剩余显存和机器剩余 CPU/内存的索引

在线装箱

显存主导 best-fit，CPU/内存做硬约束，减少碎片

短作业回填

用预计时长短的作业填碎片，避免大块资源空等

反馈校准

采集实际显存峰值、CPU/内存、运行时长，修正画像

先做什么

第一步：把问题量化，而不是先改算法

已有平台上最先做的是观测和画像。没有资源画像，调度器只能按用户申报或静态规则调度，很容易出现显存碎片、CPU/内存残余无法利用、某些 GPU 型号过热、队列延迟变长等问题。

要采集什么	为什么
每个作业 requested / actual GPU memory peak	判断申报是否保守，建立显存预测或修正系数
CPU cores、RSS memory、I/O、运行时长分布	做多维约束和短作业 backfill
GPU 型号、总显存、当前剩余显存、显存碎片	做 flavor 分池和 best-fit
机器 CPU/内存/GPU 配比	找出“GPU 有剩余但 CPU/内存不够”的结构性碎片
队列等待时间、调度耗时、失败/重试原因	判断瓶颈在资源不足、匹配算法还是调度器吞吐

资源建模

资源向量

每个作业可以抽象成 (gpu_mem, cpu, host_mem, duration, gpu_flavor_constraint)，每张 GPU / 每台机器维护剩余向量。匹配时 GPU 显存是主排序维度，CPU 和 host memory 是硬约束。

模型	作用	注意点
GPU flavor	区分 A10/A100/H100 等不同显存和性能	不同卡性能不同，吞吐目标不能只看作业数
GPU memory slice	每个作业几 GB 显存，可在同卡放多个进程	需要 runtime 隔离和显存上限，否则 OOM 会互相影响
CPU / host memory	C++ 进程也吃 CPU 和内存	机器配比异构时，CPU/内存会造成“剩余显存不可用”
duration	几分钟到几十分钟	可用于短作业优先、backfill 和释放时间预测
interference	同卡多进程可能有 SM/HBM/PCIe 干扰	不能只按显存装满，还要监控性能退化

调度算法

入队

校验资源画像，按 GPU flavor / 优先级 / 时长分队列

候选召回

从索引里找剩余显存足够且 CPU/内存足够的机器和 GPU

硬约束过滤

GPU 型号、显存、CPU、host memory、租户/故障域

打分排序

best-fit 显存、减少机器残余碎片、保持负载均衡

绑定启动

原子扣减资源，启动 C++ 进程，设置显存/CPU/内存限制

运行反馈

采集峰值和时长，完成后释放资源并更新预测

主策略：显存主导的 Best-Fit Decreasing

把等待队列中可调度的一批作业按显存需求从大到小处理；每个作业优先放到“刚好能容纳它”的 GPU 上，减少大卡被小作业打散。CPU/内存作为机器级硬约束，防止显存够但进程跑不起来。

为什么不是简单 first-fit

first-fit 容易把小显存作业随机塞到大显存卡上，造成大作业找不到连续剩余显存。best-fit 会优先消耗最贴近需求的碎片，保留大块显存给后续大作业。

策略	适合点	风险
First Fit	实现简单、调度快	碎片大，异构资源浪费明显
Best Fit	减少显存碎片	需要维护高效索引，局部最优
Best Fit Decreasing	批量调度时更稳定	等待成批会增加一点调度延迟
Backfill	利用短作业填碎片	需要运行时长估计，估错会影响后续作业
Load Balancing	避免热点机器	可能牺牲装箱效率

高吞吐工程实现

这个题有“每天几千万作业”的量级，回答时必须提调度器自身吞吐。

模块	做法
资源索引	按 GPU flavor 建池；每个池维护按剩余显存排序的 GPU set；机器维度维护 CPU/内存剩余
批量调度	每轮取一批 pending jobs，批内排序和匹配，减少锁和数据库/API 往返
乐观扣减	scheduler cache 里先 reserve，启动失败再 rollback，避免并发重复分配
分片调度器	按资源池、租户或队列 shard，多实例并行调度
热路径缓存	避免每个作业全量扫描所有机器，候选召回只查相关 flavor / memory bucket
限流与降级	高峰期先用近似 best-fit，观测恢复后再做更精细 defrag

后做什么

阶段 1

资源画像、峰值采集、队列等待和碎片指标

阶段 2

GPU flavor 分池、显存 best-fit、多维硬约束过滤

阶段 3

批量调度、短作业 backfill、运行时长估计

阶段 4

预测 requested memory/duration，自动修正用户申报

阶段 5

干扰感知、碎片整理、跨池迁移或重启策略

阶段	目标	产出
1. Baseline	先知道浪费在哪里	GPU memory utilization、CPU/memory residual、queue time、失败原因
2. 装箱	提高显存利用率	flavor pool、best-fit、candidate index
3. 吞吐	支撑几千万作业规模	batch scheduling、scheduler shard、cache reserve
4. 预测	降低过度申报和 OOM	memory peak estimator、duration estimator、安全余量
5. 治理	长期稳定运行	defrag、干扰检测、SLO/告警、容量规划

关键权衡

权衡	回答口径
利用率 vs 隔离	同卡多进程能提高显存利用率，但要限制显存、CPU 和监控干扰
装箱效率 vs 调度延迟	几千万作业不能每次全局最优，必须用索引和近似算法
显存利用 vs CPU/内存残余	主维度是显存，但 CPU/内存配比异构会让剩余显存不可用
大作业 vs 小作业	大显存作业优先保留大块，小作业用 backfill 填碎片
预测激进 vs OOM	预测可减少保守申报，但必须加安全余量和失败回退

图形化回答

作业队列

job=(gpu_mem,cpu,mem,duration,flavor)

画像修正

actual peak + runtime feedback

资源池索引

flavor -> remaining gpu memory buckets

多维过滤

GPU memory + machine CPU/memory + policy

Best-Fit 打分

最小剩余显存 + 最少机器残余碎片

绑定执行

reserve -> launch process -> monitor -> release

回答结构

Q: 面试里如何回答这个场景题？

1. 先复述本质

这是海量短作业在异构 GPU 集群上的在线多维装箱问题。主瓶颈是 GPU 显存，但 CPU/内存配比异构会影响可用性，目标是在调度延迟可控的前提下提高显存利用率和作业吞吐。

2. 先做观测和画像

我不会一上来改算法，而是先采集 requested/actual GPU memory、CPU、host memory、运行时长、队列等待、调度耗时、失败原因和碎片指标，建立 baseline。

3. 再做资源池和索引

按 GPU 型号和显存容量分池，维护每张 GPU 的剩余显存、每台机器的剩余 CPU/内存，用 memory bucket 或有序结构快速找候选，避免全量扫描。

4. 调度策略

核心用显存主导的 best-fit/bin packing：优先把作业放到刚好能容纳的 GPU 上，CPU/内存做硬约束；批量调度时按显存需求从大到小，短作业可以 backfill 碎片窗口。

5. 工程化和迭代

为了支撑几千万作业，需要 batch scheduling、scheduler cache reserve、分片调度器和失败 rollback。后续再引入显存/时长预测、干扰检测、defrag 和容量规划。

一句话收束：先量化浪费，再按 GPU flavor 分池，用显存 best-fit 做在线多维装箱，靠批量调度和反馈预测把吞吐做上去。

高频追问

Q: 为什么主维度是显存，不是 GPU 利用率？

题设里每个 C++ 作业只用几 GB 显存，显然打不满一张卡，卡住的是一张 GPU 上能同时放多少进程。GPU-Util / SM 利用率当然也要看，但调度入口首先要保证显存可容纳且不 OOM；后续才用利用率和干扰指标决定是否继续提高同卡并发。

Q: CPU/内存配比异构怎么处理？

把机器看成 GPU 显存 + CPU + host memory 的多维资源。候选 GPU 显存够只是第一步，还要检查所在机器剩余 CPU/内存是否足够。打分时惩罚会造成残余资源不可用的放置，例如剩很多显存但 CPU 被打满，或者 CPU 剩很多但显存碎掉。

Q: 几千万作业下调度器怎么不成为瓶颈？

避免每个作业扫描全集群。按 GPU flavor 分 shard，维护剩余显存 bucket / 有序索引；每轮批量取 pending jobs，批内排序后匹配；scheduler cache 里乐观 reserve，启动失败 rollback；高峰期可用近似 best-fit，牺牲一点最优性换调度吞吐。

Q: 怎么衡量优化有效？

看四类指标：GPU 显存利用率和碎片率、作业吞吐和 queue time、CPU/内存残余资源浪费、失败率/OOM/重试率。不能只看平均 GPU-Util，因为这个场景主瓶颈是显存装箱和作业调度吞吐。

关联模块

多租户 GPU 调度：提供 GPU 调度系统设计的通用框架。
任务调度理论：提供 bin packing、SJF、backfill、多资源公平等算法背景。
性能预测与建模：提供显存峰值和运行时长预测的后续优化方向。
GPU 硬件与资源共享：提供同卡多进程、显存隔离和利用率诊断背景。