任务调度理论

目标函数 · 经典算法 · 多资源公平 · 批调度 · 拓扑感知 · 排队论 · 架构演进 · 面试题精讲

Module Switcher

任务调度理论

内容模块

理论基础

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

经典调度算法是所有调度系统的基础。不管你用的是 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 + 拓扑打分，抢占用代价感知。

面试金句

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

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

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

举个例子：同样的集群，如果你优化平均 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 集群不是单资源系统。一个训练任务同时消耗 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 集群特有的延伸。"

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

分布式训练、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 但训练继续。

面试金句

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

内容模块

AI 集群与面试

拓扑感知调度：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 怎么调度

问题定义

集群同时存在不同型号、显存容量和互联能力的 GPU，任务有精度、显存、算力和拓扑需求。调度器需要避免高端卡被低需求任务长期占用，也不能把任务放到“数量够但跑不动”的节点。

回答框架

资源画像

型号、显存、精度能力、拓扑、健康、成本

任务画像

最低显存、兼容型号、并行规模、SLO、预计时长

Filter

不兼容、容量不足、拓扑不满足直接排除

Score

碎片、性能匹配、数据位置、能耗与价格

运行时反馈

实际吞吐、OOM、干扰、预测误差回写画像

Q: 为什么不能统一换算成“标准 GPU 单位”？

不同模型对算力、带宽、显存容量和互联的敏感度不同，GPU 性能不是一个固定比例。统一单位可用于粗粒度配额计量，但放置仍应基于任务—硬件匹配或性能预测，并保留不可运行的硬约束。

场景二：多租户配额与弹性借用

采用“保障额度 + 弹性借用 + 有界回收”：

保障额度：租户在竞争时至少可获得的份额。
弹性借用：其他队列空闲时允许短期超额使用。
回收策略：有需求恢复时按优先级、运行代价和 Checkpoint 状态回收。
公平指标：单资源可用 Max-Min，多资源使用 DRF 或带权扩展。

仅比较 GPU 数量不够，还要考虑不同型号价值、CPU/内存/NIC 配套以及共享实例的干扰。

Q: 弹性借用会不会让保障额度失效？

借用必须伴随可执行的回收规则。新需求到来时，系统先停止继续借用，再优先回收低优先级、可 Checkpoint、剩余时间长或重启代价低的任务，并设置宽限期与最大回收速率，避免抖动。

场景三：GPU 碎片如何治理

碎片类型	例子	治理方法
数量碎片	多节点各剩 1 卡，8 卡任务无法启动	Bin Packing、Gang、预约与重排
显存碎片	卡上剩余显存分散，任务无法放置	MIG/HAMi/显存感知、合适共享策略
型号碎片	高端卡被兼容低端卡的任务占用	能力匹配、机会成本打分
拓扑碎片	卡数够但不在同一 NVLink/NIC 域	拓扑资源模型与联合分配
时间碎片	大任务等待期间资源短时空闲	Backfill 与运行时长估计

碎片率必须和排队时间、JCT、抢占浪费一起观察；把卡塞满不一定让用户更快。

常见误区

把公平等同于每个租户平均分卡。
只做 Bin Packing，不预留大规模 Gang 任务的成组资源。
共享 GPU 时只计算显存，不建模 SM、带宽和故障干扰。
性能预测结果没有置信区间却直接成为硬约束。

场景一：Gang Scheduling

分布式训练通常需要多个 Worker/Rank 同时启动；如果只调度了一部分，已占 GPU 的 Pod 也无法有效训练，形成资源死锁式浪费。

作业提交

声明 minAvailable、角色和资源需求

队列准入

判断配额、优先级和整组可用性

资源预留

对候选节点执行原子 Reserve

Permit

等待所有成员满足条件

Bind

成组提交，失败时整体回滚

Gang 不代表所有 Pod 同一时刻物理启动，而是避免“部分成员长期占着资源却无法形成可运行集合”。

场景二：Backfill

大任务等待成组资源时，可让预计运行时间较短的小任务填补空档，但必须保证不会推迟已承诺的大任务启动时间。

Backfill 依赖：

对等待作业建立保守预约窗口。
估计候选小任务的运行时间或可中断性。
超时可终止或 Checkpoint，避免小任务越跑越久。
监控估计偏差，防止系统性饿死大任务。

Q: Backfill 和普通 Best-Effort 有什么区别？

Backfill 以“不破坏前序作业的资源预约”为约束，利用可证明的时间空洞；普通 Best-Effort 只是低优先级使用空闲资源，若没有运行时长或回收机制，可能阻塞大任务。

场景三：代价感知抢占

抢占决策应最小化总损失，而不是简单杀最低优先级：

成本	判断信号
已完成工作浪费	已运行时间、剩余时间估计
恢复成本	最近 Checkpoint、Checkpoint 大小、加载速度
分布式放大	抢占一张卡是否导致整个 Job 重启
业务影响	Deadline、SLO、租户保障额度
碎片收益	抢占后是否真的组成目标资源集合

先尝试队列借用回收、缩容、暂停或迁移；只有收益明确时再终止任务。

场景四：弹性训练与故障感知

调度器只能决定资源，训练框架必须支持成员变化、Rendezvous、数据分片重平衡、学习率/Global Batch 语义和 Checkpoint。弹性扩容不一定提高效率：跨节点拓扑变差、通信增大或数据重分片都可能抵消新增算力。

故障处理要区分：

设备故障：Xid/ECC/掉卡，隔离设备或节点。
Rank 故障：判断能否局部重启或需要整组恢复。
网络分区：防止重复训练成员和一致性问题。
Checkpoint 故障：验证可读性和版本，而不只看文件存在。

Q: 什么时候适合抢占一个训练任务？

目标任务优先级或保障需求足够高，被抢占任务有较新 Checkpoint、恢复成本可控，而且释放资源能够形成目标任务真正需要的拓扑集合时。若只释放零散 GPU 或导致一个大作业整体重启，抢占收益可能为负。

常见误区

Gang 只配置 minAvailable，却没有超时、回滚和队列准入。
Backfill 不估计运行时间，也没有终止边界。
把“Pod 能重启”误认为“训练状态能恢复”。
弹性扩容只看卡数，不重新评估通信和 Global Batch 语义。

场景一：拓扑感知放置

硬约束与软目标

硬约束：卡数、显存、型号、健康、同一故障域或指定互联能力。
软目标：优先同一 NVLink/NVSwitch 域、GPU 与 NIC 同 NUMA、减少跨 Socket/跨机通信。

采集拓扑

GPU-CPU-NIC、PCIe Root、NVLink/NVSwitch、网络域

映射并行策略

TP 更敏感带宽，DP 更依赖跨机 Collective

Filter

排除不能形成所需拓扑集合的节点

Score

比较通信代价、碎片、数据位置与拥塞

运行时校准

NCCL 时间、链路吞吐和 Step Time 回写

Q: 为什么 Node 上有 8 张空卡，8 卡训练仍可能很慢？

卡可能分属不同 PCIe Root 或 NUMA 域，GPU-NIC 路径也可能跨 Socket；调度数量满足但通信代价很高。还要检查进程 Rank 与拓扑映射、NCCL 选择的链路以及是否与其他任务争用互联。

场景二：训练和推理混部

在线推理关心 P99、容量冗余和快速扩缩；离线训练关心吞吐、JCT 与 Gang。混部可提高利用率，但必须建立隔离和可回收边界：

策略	适用性	风险
独立节点池	最稳定、边界清楚	利用率可能较低
MIG	推理规格稳定、需要强隔离	Profile 碎片和重配成本
MPS/Time-Slicing	轻负载或可容忍干扰	P99 抖动、故障域扩大
低优先级训练借用	推理有稳定保留容量	回收速度与 Checkpoint 成本

混部决策要以推理 SLO 为硬约束，训练吞吐收益为优化目标；不能只因为 GPU-Util 低就自动塞入训练任务。

场景三：海量小 GPU 作业

短作业下，调度、镜像拉取、容器启动和结果提交可能比 GPU 计算本身更贵。设计重点从单次最优变成控制面吞吐：

Admission 层做限流、合并和配额，防止 API Server 被突发请求打满。
调度 Cache 与索引减少全量扫描，用分层队列隔离租户。
尽量复用 Worker/容器或使用常驻执行器，摊薄冷启动。
镜像预热、数据局部性和批量提交降低 I/O 开销。
使用 Best-Fit/Backfill 控制显存碎片，但设置最大等待时间。

Q: 如何评估调度器在海量小作业下是否成为瓶颈？

分解提交到运行的时间：准入排队、Scheduling Cycle、Binding Cycle、kubelet/CRI 启动、镜像和数据准备。监控队列长度、调度吞吐、P95/P99 调度延迟、失败重试、API Server 和 etcd 压力，并对比作业实际 GPU 运行时间。如果控制面开销接近作业计算时间，应优先做常驻执行、批量化和缓存。

常见误区

把拓扑标签当作静态真相，不处理设备故障和节点变更。
把训练吞吐优化直接套到在线推理，忽视尾延迟。
用共享机制提高名义利用率，却没有干扰监控和降级策略。
小作业只优化 Score 算法，不测 API、队列、绑定和启动链路。

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

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 训练集群调度系统，要求公平且高效。

设计要点

配额管理
- 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 集群调度平台，现在要在这个平台基础上优化调度策略。集群由一批机器组成，每台机器有若干张 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 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，因为这个场景主瓶颈是显存装箱和作业调度吞吐。

内容模块

调度理论与架构演进

Little's Law：排队论的基础恒等式

Little's Law 是排队论中最普适、最有用的公式，不需要任何假设，适用于任何稳定的排队系统：

L = λ × W

其中：

L：系统中（排队中 + 服务中）的平均顾客数（或平均任务数、平均请求数）
λ：长期平均到达率（单位时间到达的顾客/任务数）
W：顾客在系统中平均停留时间（等待时间 + 服务时间）

直觉理解：想象一个 GPU 集群，每小时来 100 个任务（λ = 100 个/小时），每个任务从提交到完成平均要 0.5 小时（W = 0.5 小时，即 30 分钟），那么系统中平均有 L = 100 × 0.5 = 50 个任务在同时运行或等待。这就像水管：流入速度 × 水在管中停留时间 = 管中存水量。

Little's Law 在 AI Infra 的应用

1. 容量规划

问题：在线推理集群，QPS = 1000，每个请求平均处理时间（含排队）是 100ms，需要多少并发槽位？

L = λ × W = 1000/s × 0.1s = 100

结论：系统需要至少容纳 100 个并发请求。如果每个 GPU 能处理 20 并发，那么至少需要 5 张 GPU。

2. 队列深度估算

问题：离线训练集群，每小时提交 20 个训练任务，平均每个任务从提交到开始运行要等 2 小时，队列平均有多长？

L = 20 个/小时 × 2 小时 = 40 个任务在排队或运行

3. 排队时间反推

问题：如果你观察到队列平均有 30 个任务等待，到达率是每小时 10 个，那么平均等待时间是多少？

W = L / λ = 30 / 10 = 3 小时

面试注意：Little's Law 没有假设到达分布或服务时间分布，也不需要系统是 Markovian，对任何稳定系统都成立。这是它最强大的地方。

Kendall 记号：描述排队模型的标准语言

Kendall notation 用 A/S/c/N 来描述排队模型：

符号	含义	常见取值
A	到达过程（Arrival）	M（Markovian/Poisson 到达，记忆性）、D（Deterministic 确定）、G（General 一般）
S	服务时间分布（Service）	M（Exponential 指数分布，记忆性）、D（确定）、G（一般）
c	服务台数量（Servers）	1, 2, ..., c
N	队列容量（可选）	∞（默认，无限队列）、N（有限，满了就拒绝）

记忆性（Memoryless Property）：指数分布的关键性质是"无记忆"——已经等了 t 时间，剩余等待时间的分布和刚开始等时一样。这就是 M 的含义。

M/M/1：单服务台模型，利用率-延迟曲线的来源

M/M/1 是最简单也是最重要的排队模型：Poisson 到达、指数服务时间、1 个服务台。

核心公式

ρ = λ / μ          # 利用率（utilization）
Wq = ρ / (μ(1-ρ))  # 排队等待时间（不含服务时间）
W = 1 / (μ - λ)    # 系统总时间 = 等待 + 服务

其中：

μ：服务率（单位时间能服务完的任务数）
ρ：利用率，必须 < 1 系统才稳定

关键现象：利用率接近 1 时等待时间爆炸

看数值例子，假设 μ = 10 个/小时（服务率固定）：

到达率 λ	利用率 ρ	排队时间 Wq	等待 vs ρ=0.5
5/小时	50%	0.1 小时 = 6 分钟	基准
7/小时	70%	0.23 小时 ≈ 14 分钟	2.3 倍
8/小时	80%	0.4 小时 = 24 分钟	4 倍
9/小时	90%	0.9 小时 = 54 分钟	9 倍
9.5/小时	95%	1.9 小时 = 114 分钟	19 倍
9.9/小时	99%	9.9 小时 ≈ 10 小时	99 倍

这就是曲棍球棒（hockey-stick）曲线：利用率在 0-70% 时延迟增长平缓，超过 80% 后等待时间急速上升，ρ→1 时 Wq→∞。

AI Infra 启示

GPU 集群绝不能追求 95%+ 利用率：

在线推理集群：目标利用率 50-70%，因为对延迟敏感，需要预留 headroom 应对突发流量
离线批处理训练：可以推高到 80-90%，因为对排队延迟容忍度高，但超过 90% 还是会导致队列雪崩
为什么不能 99% 利用率：因为到达率不是恒定的，总有波动。平均 90% 利用率意味着峰值时可能到 99%，等待时间直接爆炸。这就是为什么需要准入控制（Admission Control）——当集群已经高负载时，拒绝或排队新任务，而不是全部放进来让所有人都慢。

M/M/c：多服务台模型与 Erlang-C

M/M/c 有 c 个相同的并行服务台，这更符合真实的 GPU 集群（多台机器、多张 GPU）。

关键指标

利用率：ρ = λ / (cμ)，必须 < 1
Erlang-C 公式：计算"一个到达的任务需要等待"的概率 P(wait)，这是呼叫中心、客服排队系统设计的核心公式
多服务台的好处：同样的总服务能力，多台并行比单台快。例如 c=2、μ=5（总服务能力 10）比 c=1、μ=10 的等待时间短。因为单台被占时新任务只能等，两台时另一台可能空闲。

AI 集群直觉

GPU 集群本质上是 M/M/c 模型：c 是 GPU 总数（或某种 GPU 型号数量）。Erlang-C 可以估算"提交一个任务需要排队的概率"。但实际 AI 集群比 M/M/c 复杂：任务大小不同（1 GPU 到 1024 GPU）、有 Gang 调度需求、服务时间分布不是指数分布，所以更多用 M/G/1 的直觉。

M/G/1：服务时间有方差时排队会更糟

M/G/1 是"Poisson 到达、一般（任意）服务时间分布、单服务台"模型。这是最接近真实 AI 集群的简单模型，因为真实的任务运行时间不是指数分布——有 5 分钟的小实验，也有 10 天的大训练，方差很大。

Pollaczek-Khinchine 公式

Wq = (λ · E[S²]) / (2 · (1 - ρ))

其中：

E[S]：服务时间 S 的期望（平均值）
E[S²] = Var(S) + (E[S])²：服务时间的二阶矩，包含了方差信息
Var(S)：服务时间方差

关键洞察：方差放大排队

公式告诉我们：即使平均服务时间 E[S] 和利用率 ρ 相同，服务时间方差 Var(S) 越大，排队等待时间 Wq 就越长。

数值例子：λ = 8/小时，E[S] = 0.1 小时（6 分钟），所以 ρ = 0.8：

场景	服务时间分布	E[S²]	Wq
所有任务都是 6 分钟	确定分布（Var=0）	0.01	(8×0.01)/(2×0.2) = 0.2 小时 = 12 分钟
一半 3 分钟，一半 9 分钟	两点分布（有方差）	0.015	(8×0.015)/(2×0.2) = 0.3 小时 = 18 分钟
一半 1 分钟，一半 11 分钟	大方差	0.061	(8×0.061)/(2×0.2) ≈ 1.22 小时 ≈ 73 分钟

同样的平均服务时间、同样的 80% 利用率，仅仅因为"长短任务混跑"，排队时间从 12 分钟变成 73 分钟——涨了 6 倍！

AI Infra 直接启示

在线和离线必须分离：Prefill（短，几十到几百 ms）和 Decode（长，几秒到几十秒）不要用同一个队列；在线推理（短，SLO 严格）和离线训练（长，无 SLO）必须分开。混合跑不仅方差大，而且长任务会阻塞短任务，违反短任务的 SLO。
大小训练任务尽量分离：小实验（几分钟到几小时）和大训练（几天到几周）分队列，避免小实验被大任务堵死，也避免大任务被大量小任务插队导致饥饿。
预测误差的影响：对短任务运行时间估计过准很重要，对长任务估计误差影响相对小——因为 M/G/1 公式里是 E[S²]，短任务的 S² 本来就小，估计偏差带来的方差影响相对更大。

调度算法的排队论最优性

SRPT/SJF 的最优性

在 M/G/1 模型中，Shortest Remaining Processing Time (SRPT) 调度策略可以最小化平均响应时间。SRPT 是 SRTF 的排队论名称——总是选择剩余处理时间最短的任务，可抢占。

当任务到达时间相同（batch 场景）时，非抢占的 SJF 也能最小化平均响应时间。

但最优不等于最公平

SRPT/SJF 的问题：长任务饥饿。如果短任务持续到达，长任务可能永远排不上。实际系统需要：

Aging：等待时间越长，优先级越高，最终超过新来的短任务
多队列 + 配额保障：每个租户/类型有最低资源保障，保障用完再按 SRPT 竞争
公平共享（如 DRF）：不追求最小化平均响应时间，而是追求公平性

Processor Sharing (PS) 的角色

Processor Sharing（时间片轮转的极限，每个任务获得 1/n 的服务能力）下，所有任务的期望响应时间是相同的，与服务时间分布无关——但代价是平均响应时间比 SRPT 长。这就是为什么公平和效率是 trade-off。

准入控制：什么时候应该拒绝新任务？

从 M/M/1 公式我们知道，ρ→1 时 Wq→∞。这意味着当集群已经接近满负载时，继续接受新任务会让所有人都变慢——包括已经在运行的任务吗？不，运行中的任务不受影响，但排队中的所有任务等待时间都会变长，而且新加入的任务也加入排队，形成"越满越慢、越慢越堆"的正反馈。

准入控制策略：

当集群利用率超过阈值（如 85%）时，新任务进入排队队列而不是立即调度
或者根据队列长度拒绝低优先级任务（load shedding）
在线服务：快速失败比长时间排队更好——排队超过 SLO 就直接拒绝，返回 429/503，让客户端重试或降级

类比：高速路堵车时，入口匝道限流（on-ramp metering），不让更多车上来，反而让整体通行更快。如果不限流，高速路彻底堵死，谁都走不了。

排队论面试问答

Q: 为什么集群利用率到 80% 以上等待时间会暴涨（用排队论解释）？

核心解释：M/M/1 公式

用 M/M/1 排队模型的等待时间公式：Wq = ρ/(μ(1-ρ))。当利用率 ρ = λ/μ 接近 1 时，分母 (1-ρ) 趋近于 0，排队等待时间 Wq 呈双曲线增长，数学上 ρ→1 时 Wq→∞。

数值上：ρ=50% 时等待时间基准为 1x；ρ=80% 是 4x；ρ=90% 是 9x；ρ=95% 是 19x。这就是"曲棍球棒曲线"——70% 之前延迟增长平缓，80% 之后急速攀升。

直觉理解

系统总有波动：到达率不是恒定的，任务大小也有差异。平均 80% 利用率意味着忙的时候（流量高峰、大任务扎堆）实际利用率可能瞬时到 95%+，这时候临时形成的队列需要很长时间才能消化。利用率越高，系统消化突发排队的能力越弱。

工程结论

GPU 集群目标利用率：在线推理 50-70%（需要低延迟 SLO），离线训练 80-90%（可容忍排队），绝不要追求 95%+。同时需要准入控制——集群高负载时排队或拒绝新任务，而不是全部放进来让大家一起慢。

面试要点：给公式 + 数值例子 + 直觉 + 工程建议，不要只说"因为排队"。

Q: Little's Law 怎么用在容量规划上？

公式

L = λ × W——系统中平均并发数 = 到达率 × 平均停留时间。这个公式不需要任何分布假设，对任何稳定系统都成立。

容量规划例子

在线推理场景：QPS = 1000（λ = 1000/s），每个请求从进入到返回平均 100ms（W = 0.1s，含排队和服务），那么系统需要同时处理 L = 1000 × 0.1 = 100 个并发请求。如果单 GPU 能承载 20 并发（考虑 KV Cache、batch size），至少需要 5 张 GPU；再考虑冗余和峰值，通常留 30-50% headroom，配 7-8 张。

离线训练场景：每天提交 100 个训练任务（λ ≈ 4.17/小时），要求平均等待不超过 2 小时（W = 2 小时），那么集群平均要容纳 L = 4.17 × 2 ≈ 8 个任务。如果每个任务平均用 8 张 GPU，集群需要 64 张 GPU 以上才能满足这个等待时间目标。

反向使用

观察现有系统队列长度 L 和到达率 λ，可以反推平均等待时间 W = L/λ——这比直接统计等待时间更简单。

面试要点：Little's Law 是容量规划的第一性原理，用具体的 GPU 场景举例比抽象解释更有说服力。

Q: 为什么大小 job 混跑会导致排队更严重？

核心解释：M/G/1 Pollaczek-Khinchine 公式

M/G/1 排队模型的等待时间公式：Wq = (λ·E[S²])/(2(1-ρ))，其中 E[S²] = Var(S) + (E[S])²。这说明：即使平均服务时间 E[S] 和利用率 ρ 完全相同，服务时间方差 Var(S) 越大，排队等待时间就越长。

数值例子

假设平均服务时间都是 6 分钟，ρ=80%：所有任务都是 6 分钟（方差为 0），排队 12 分钟；一半 3 分钟一半 9 分钟（方差 9），排队 18 分钟；一半 1 分钟一半 11 分钟（大方差），排队 73 分钟——涨了 6 倍。

AI Infra 中的具体场景

(1) Prefill（几十到几百 ms）和 Decode（几秒）混跑——方差大，短请求被长请求阻塞。(2) 在线推理（毫秒到秒级）和离线训练（小时到天级）混跑——在线 SLO 无法保证。(3) 小实验（几分钟）和大训练（几天）混跑——小实验排队长，大任务也可能被小任务插队饥饿。

工程结论

必须按任务类型分队列：在线/离线分离、大小任务分离、不同 SLO 等级分离。分队列后每个队列内部服务时间方差小，排队时间自然降低。这比优化调度算法更有效。

面试要点：用 M/G/1 公式说明"方差伤害"，举具体的 AI 场景，给出"分队列"的解决方案。

Q: GPU 集群目标利用率应该多少？

分场景回答

工作负载类型	目标利用率	原因
在线推理（延迟敏感）	50-70%	需要 headroom 应对突发流量（流量可能瞬时翻倍），延迟 SLO 严格，排队代价高
离线批处理训练	80-90%	排队延迟可以容忍，高利用率意味着更低成本，但超过 90% 会导致队列雪崩
开发/实验平台	60-80%	用户期望快速启动（交互式体验），又希望不浪费资源，介于两者之间
混部集群	70-85%	用离线任务填在线的闲时资源（潮汐部署），在线高负载时抢占离线

为什么不能追求 95%+？

(1) M/M/1 告诉我们 ρ→1 时等待时间指数增长；(2) 负载不是恒定的，平均 95% 意味着峰值时必然过载，队列雪崩；(3) 高利用率下故障恢复慢——一个节点挂了，它的任务需要迁移，而其他节点都很忙，迁移的任务排很久才能重启。

成本 vs 体验的 trade-off

利用率每提高 10%，基础设施成本降低约 10%，但排队延迟可能增长 2-3 倍。在线服务宁可多花点机器钱也要保证体验（用户延迟高就走了），离线任务可以用排队换成本。

面试要点：分场景给数字，解释背后的排队论原因，提到成本-延迟 trade-off。

为什么调度器架构重要？

调度器的架构决定了三个核心问题：

决策质量（Optimality）：能否做出全局最优的放置决策？还是只能看到局部信息？
可扩展性（Scalability）：集群规模到 1 万、10 万节点时还能工作吗？每秒能调度多少任务？
并发度（Concurrency）：多个调度器/多个框架能不能并行做决策？冲突怎么解决？

这三个目标是互相矛盾的：全局最优需要看所有信息，但全局信息在大规模下难维护；并行决策提高吞吐，但会产生冲突。不同架构就是在这个三角中做不同的权衡。

架构一：集中式/单体调度器（Centralized/Monolithic）

代表系统：Google Borg、Kubernetes 默认调度器、早期 Hadoop MapReduce

核心设计

所有调度决策都由一个中央调度器进程做出。所有任务提交到全局队列，调度器按顺序处理，一个一个地做"可行性检查（Filter）+ 打分（Score）+ 绑定（Bind）"。

Borg 的关键设计

Cell 规模：单个 Borg cell 可以管理上万台机器，同时运行数千个作业、数十万个任务
两阶段调度：先做 feasibility check（过滤掉不满足资源/约束的节点），再做 scoring（对可行节点按优先级、资源匹配度、抢占代价等打分），选最高分节点
共享状态缓存：调度器有本地缓存（watch API Server），不需要每次都查全量状态，提高调度吞吐
优先级 + 抢占：高优先级任务可以抢占低优先级任务，保证线上服务质量
资源回收（Reclamation）：对低优先级任务使用的"预留但未使用"的资源进行回收，给高优任务用

K8s 默认调度器

K8s kube-scheduler 是典型的集中式调度器：

单进程运行，通过 Informer 缓存集群状态
调度周期：Scheduling Queue → Filter → Score → Reserve → Permit → Bind
默认串行调度一个 Pod，可通过 scheduler framework 扩展
v1.26+ 支持 Scheduler Profile，可配置多个不同配置的调度器，但本质还是"多个集中式调度器"，每个调度器还是单进程串行

优缺点

维度	评价
决策质量	高——能看到全局状态，做出全局最优（或近似最优）决策
实现复杂度	低——所有逻辑在一个进程里，没有分布式一致性问题
可扩展性	有瓶颈——单进程调度吞吐有限，万级节点集群需要性能优化（缓存、增量调度、近似算法）
多框架支持	差——所有任务类型都要适配同一套调度逻辑，框架定制难

Borg 怎么解决单进程瓶颈？

乐观并发：调度时基于缓存做决策，Bind 时如果资源已被占用就重试，不需要全局锁
分 Cell：不是一个大集群管所有机器，而是分成多个独立的 cell（每个 cell 几万台机器），每个 cell 有自己的调度器
批量调度：对同类型的小任务做批量调度，减少重复计算
得分近似：不需要绝对最优，对 top-K 节点做精确打分，其余快速过滤

架构二：两级调度（Two-Level / Two-Tier）

代表系统：Apache Mesos、Hadoop YARN

核心设计思想

把调度分成两层：

第一层（中央 Resource Master）：决定"给哪个框架多少资源"，负责资源分配和公平性
第二层（框架调度器 Application Master）：决定"把这些资源给我的哪个任务、启动在哪里"，框架自己做任务调度

关键机制是资源 Offer（资源邀约）：Master 主动给框架发 Offer（"我这儿有这些空闲资源，你要不要？"），框架接受或拒绝。

Mesos 具体工作流程

1. Slave 节点上报空闲资源给 Mesos Master
2. Master 按 DRF（Dominant Resource Fairness）算法决定给哪个 Framework 发 Offer
3. Master 向 Framework Scheduler 发送 Resource Offer
4. Framework 检查 Offer：符合自己需求就 Accept，否则 Decline
5. Accept 的话，Framework 告诉 Master 在哪些节点上启动哪些 Task
6. Master 把 Task 发给对应 Slave 的 Executor 启动

DRF 公平性

Mesos 用 DRF 做多资源公平分配：每个框架有一个"主导资源（Dominant Share）"——对 CPU 密集型框架是 CPU 份额，对内存密集型是内存份额，对 GPU 训练是 GPU 份额。DRF 让所有框架的主导资源份额相等，这是多资源下的 max-min 公平。

优缺点

维度	评价
多框架支持	非常好——Hadoop/Spark/MPI/在线服务都可以接入，每个框架有自己的调度逻辑
可扩展性	好——框架并行调度，Master 只做资源分配不做任务调度，压力小
决策质量	低——框架只能看到 Master 给自己的 Offer，看不到全局资源；"Pessimistic Offer"策略下给了一个框架的资源其他框架暂时不能用，资源利用率低
优先级反转风险：高——低优框架拿了 Offer 但不释放，高优框架等不到资源；或者框架拒绝了 Offer 但资源在 Offer 期间被锁
实现复杂度	中——两层之间需要协议，框架需要自己实现调度逻辑

Mesos Offer 机制的问题：

悲观并发（Pessimistic Concurrency）：资源 Offer 发给一个框架后，这些资源在被接受/拒绝/超时前，其他框架看不到——相当于被锁住了，利用率低
框架信息不全：框架不知道"下一个 Offer 什么时候来"、"还有多少资源"，可能做出次优决策（比如接受一个不够大的 Offer，因为怕等不到更好的）
不适合 Gang Scheduling：大的分布式训练需要同时拿到 N 张 GPU，但 Offer 是分批给的，框架很难凑齐 Gang

这也是为什么 Mesos 在 AI 训练场景用得不多——Gang 调度和拓扑感知需要全局视图。

架构三：共享状态调度（Shared-State）

代表系统：Google Omega、Microsoft Apollo

核心设计思想

针对两级调度"框架看不到全局状态"和集中式"单进程瓶颈"的问题，Omega 提出了共享状态 + 乐观并发控制：

全集群状态复制：每个调度器（可以有多个，每个可以负责不同类型任务）都有一份完整的、一致的集群状态副本（通过 Paxos/Raft 类共识协议复制）
并行独立决策：每个调度器基于自己看到的全局状态，独立、并行地做调度决策，不需要等 Master 分配 Offer
事务提交冲突解决：调度器做出决策后，以事务（Transaction）的形式提交到共享状态存储。如果两个调度器的决策冲突（比如同时把同一个任务/资源分配给了不同地方），其中一个事务会 abort，重试即可

和 Mesos 的本质区别：Mesos 是"悲观锁"——Offer 期间资源被锁；Omega 是"乐观并发"——大家都能看、都能改，冲突了再重试。

和集中式的本质区别：集中式只有一个调度器做决策；Omega 可以有多个调度器并行做决策，每个都看全局状态。

工作流程

1. 所有 Cell State 通过 Paxos 复制到每个 Scheduler 副本
2. Scheduler A 和 Scheduler B 同时看到全局空闲资源
3. Scheduler A 决策：任务 X 放节点 1，生成事务 T1
4. Scheduler B 决策：任务 Y 放节点 1，生成事务 T2
5. T1 先提交成功，节点 1 资源被标记为已用
6. T2 提交时发现节点 1 资源不足，abort，Scheduler B 基于新状态重新决策
7. Scheduler B 重试：任务 Y 放节点 2，提交成功

优缺点

维度	评价
决策质量	高——每个调度器都能看到全局状态，和集中式一样
并发度	高——多个调度器并行决策，没有中央瓶颈
多框架支持	好——不同框架可以有自己的调度器，共享全局视图
冲突问题	高负载下冲突率高，大量事务 abort 重试，反而降低吞吐（thrashing）
实现复杂度	高——需要分布式共识、事务冲突检测、重试机制

Omega 的冲突问题（Conflict Thrashing）：

当集群负载很高、空闲资源很少时，多个调度器都盯着同一块空闲资源，大家都做决策、提交冲突、abort、重试——调度器都在忙着重试，有效吞吐反而下降。这和数据库高并发写时的锁冲突类似。Omega 的解法是：

不同调度器负责不同类型的任务，减少资源竞争
高优先级任务的事务优先提交，减少低优任务的无效重试
冲突退避：abort 后等一会再重试，不要立即重试

架构四：混合/分布式/优化调度（Hybrid/Distributed）

代表系统：Firmament、K8s 多调度器、Volcano/Kueue（队列层）

Firmament：基于最小费用最大流的全局优化

Firmament 把调度问题形式化为min-cost max-flow（最小费用最大流）问题：

构造一个流网络：源点 → 任务节点 → 机器节点 → 汇点
边的容量：任务到机器的边容量为 1（一个任务放一台机器），机器到汇点的容量是机器的资源量
边的费用：任务放某台机器的代价（不满足亲和性代价高、满足局部性代价低、抢占代价等）
求 min-cost max-flow，就能得到全局最优的放置方案

Firmament 可以做到接近全局最优的决策质量，同时流算法的增量更新让它有不错的扩展性。Google 的一部分 Borg 调度逻辑已经使用了类似的优化方法。

局限：流算法有计算开销，万级任务规模需要近似和增量优化；Gang 调度等复杂约束需要特殊建模。

K8s 多调度器（Multiple Schedulers）

K8s 从 v1.x 就支持运行多个调度器：

Pod 通过 spec.schedulerName 指定用哪个调度器
不同调度器可以有完全不同的 Filter/Score 插件和策略
例如：默认调度器处理普通 Pod，GPU 调度器处理 GPU 任务，批处理调度器处理 AI 训练任务

这其实是一种"共享状态"的轻量实现——所有调度器都 watch 同一个 API Server，看到相同的集群状态，调度决策通过 Bind 时的资源检查来解决冲突（相当于乐观并发）。但 K8s 本身不做事务冲突的自动重试，需要调度器自己处理。

Volcano/Kueue 是什么？不是全功能调度器

面试中经常被问：Volcano、Kueue、YuniKorn 这些是调度器吗？答案是：它们主要是队列/批处理层，运行在 K8s 默认调度器之上，不是替代 kube-scheduler。

组件	定位	核心能力
K8s kube-scheduler	核心调度器	Pod→Node 放置、Filter/Score/Bind、资源分配
Volcano	批调度增强	Gang Scheduling、Queue、公平性、DRF、Job/TaskGroup 管理
Kueue	队列层（Job 排队）	多租户队列、配额/公平、Preemption、Job 准入控制，不做 Pod 放置
YuniKorn	资源调度器	可以替代 kube-scheduler，也可以作为 K8s 调度器插件，侧重分层队列和公平

关键区分：

Kueue 不做 Pod 放到哪个 Node 的决策——它只决定"哪个 Job 先放行、放行多少资源"，放行后的 Pod 还是交给 kube-scheduler 去放节点
Volcano 有自己的调度器（volcano-scheduler）可以替代 kube-scheduler，但大多数场景是配合使用

四种架构对比表

架构类型	并发决策	决策全局最优性	可扩展性	实现复杂度	多框架支持	典型系统
集中式/单体	低（串行）	高（全局视图）	中（单进程瓶颈，但可通过缓存/分 Cell 扩展）	低	差（单一调度逻辑）	Borg, K8s 默认调度器
两级/双层	高（框架并行）	低（框架只看 Offer）	高（Master 轻量）	中	好（框架自定义逻辑）	Mesos, YARN
共享状态	高（多调度器并行）	高（全视图复制）	中高（高负载冲突 thrashing）	高（需要共识/事务）	好（多调度器）	Omega, Apollo
混合/分布式	中高（取决于具体设计）	非常高（优化算法）	中（流算法开销）	高	中	Firmament, K8s 多调度器

演进趋势与 AI Infra 的选择

架构演进脉络

集中式 → 两级调度 → 共享状态 → 混合/多调度器
(Borg)    (Mesos)     (Omega)    (Firmament/K8s)

演进方向不是"后者替代前者"，而是"针对不同场景选择合适架构"：

小规模集群/统一工作负载：集中式最简单最可靠
多种异构框架（Hadoop/Spark/MPI/Web Service）：两级调度或共享状态
需要极致调度质量：全局优化（Firmament 风格）

AI 训练集群为什么适合集中式（Borg 风格）？

大规模 AI 训练（万卡级别）有几个特殊需求：

Gang Scheduling：分布式训练需要同时拿到所有 GPU（all-or-nothing），要么一个 Job 的 N 张卡全到位，要么一个都不启动——否则拿到部分卡的任务只能空等，浪费资源。两级调度的 Offer 机制很难凑齐 Gang。
拓扑感知：多机训练需要考虑 NVLink/NVSwitch/机架/网络拓扑（同机 > 同机架 > 同 Spine），这需要全局视图才能做最优放置——局部视图下做不了拓扑优化。
碎片化问题：GPU 是稀缺资源，碎片化（每个节点剩 1-2 张卡，但需要 8 卡的任务放不进去）代价极高，全局 Bin Packing 比局部决策减少碎片。
故障域感知：大训练 Job 的 Worker 要分散到不同故障域，避免一个机架断电整个 Job 挂掉，这也需要全局视图。
任务类型相对统一：AI 集群主要是训练 Job（和少量推理/开发），不像 Borg/Mesos 时代有 MapReduce/Spark/Web Service/Cron 等五花八门的框架，不需要强"多框架自定义调度"能力。

结论：万卡级 AI 训练集群，通常采用 Borg 风格的集中式调度 + 本地缓存 + 乐观并发 + 分 Cell/分区架构：

调度器有全局视图，做 Gang/拓扑/碎片优化
通过缓存、批量调度、近似算法解决单进程性能瓶颈
规模太大时分多个 Cell/分区，每个分区独立调度
上层用 Kueue/Volcano 做队列管理、多租户公平、配额，底层还是集中式放置

调度器架构面试问答

Q: Borg 和 K8s Scheduler 有什么区别？

核心定位

Borg 是 Google 内部使用了十多年的生产级集群管理系统，经过了万台规模、百万任务的验证；K8s 是 Borg 的开源"精神续作"，设计思想来自 Borg，但更通用、更可扩展。

具体差异

维度	Borg	K8s Default Scheduler
规模	单 Cell 万台机器，数十万个任务	官方支持 5k 节点规模，更大规模需要调优
资源模型	细粒度，有资源回收（reclamation）——可以用低优任务的预留资源	requests/limits 模型，没有原生 reclamation，需要靠 PriorityClass/Preemption
调度算法	多年优化的成熟逻辑，有全局优化、批量调度、碎片整理等	可扩展的 Framework 插件，默认插件相对简单，高级能力靠 Volcano 等扩展
Gang 调度	原生支持	不原生支持，需要 Volcano/Kueue
高可用性	调度器有热备，故障快速切换	多副本选主，但单副本调度
扩展性	内部系统，扩展靠 Google 工程师	高度可扩展——Scheduler Framework、Webhook、自定义调度器

面试要点

不要说"K8s 是 Borg 的开源版"，要说"K8s 借鉴了 Borg 的设计思想（Pod/Service/Node、优先级抢占、两阶段调度），但为了通用性和扩展性，在默认实现上简化了很多大规模场景下的高级能力（如 Gang、资源回收、全局优化），这些能力需要通过 Volcano/Kueue 等扩展组件补充。"

Q: 两级调度（Mesos/YARN）的优缺点？适合什么场景？不适合什么场景？

优点

(1) 多框架支持好——不同计算框架（Hadoop MapReduce、Spark、MPI、Web 服务）可以有自己的调度逻辑，不需要改中央调度器。(2) 可扩展性好——中央 Master 只做资源 Offer 和公平分配，任务级调度由框架自己做，Master 压力小。(3) 框架隔离——一个框架调度器出问题不影响其他框架。

缺点

(1) 框架看不到全局资源——只能看到 Master 发给自己的 Offer，做不了全局最优决策，特别是拓扑感知和 Gang 调度。(2) 悲观 Offer 锁资源——Offer 发给框架后、被接受/拒绝前，资源被临时锁定，利用率低。(3) 优先级反转——低优框架拿着 Offer 不释放，高优框架等不到资源。(4) 响应延迟——框架要等 Offer，Offer 是周期性发的，任务启动延迟高。

适合场景

多种异构计算框架并存的大数据集群——例如同时跑 Hadoop、Spark、Storm，每个框架有自己的调度需求，统一调度器难以适配所有框架。

不适合场景

AI 训练集群——因为需要 Gang Scheduling（同时拿 N 张卡）、拓扑感知（NVLink/机架）、全局碎片优化，这些都需要全局视图，Mesos 的 Offer 机制很难做好。

面试要点：说清两级调度的核心是"Master 管资源分配，框架管任务调度"，优点是多框架和扩展性，缺点是局部视图和 Offer 锁资源。

Q: Omega 的 shared-state 怎么解决冲突？和乐观锁/悲观锁是什么关系？

核心机制：乐观并发控制（Optimistic Concurrency Control, OCC）

(1) 每个调度器都有一份全集群状态副本，基于这份状态"乐观地"做决策，不加锁。(2) 决策结果以事务形式提交给共享状态存储。(3) 提交时检查：事务涉及的资源是否被其他事务修改过？如果没有，提交成功；如果冲突（资源已被占用），事务 abort，调度器基于最新状态重新做决策。

和悲观锁的对比

	悲观并发（Mesos Offer）	乐观并发（Omega）
思想	先锁资源，再做决策，别人用不了	先做决策，提交时检查冲突
冲突少（低负载）时	性能差——锁等待开销大	性能好——无锁并行
冲突多（高负载）时	性能还行——锁保证不冲突	性能差——大量 abort/retry（thrashing）
决策质量	低——可能锁了不用	高——基于全视图决策

类比

悲观锁像"会议室预约"——先预约锁时间，别人在这个时间不能用；乐观锁像"谁先到谁用"——大家都去会议室，发现已经有人了就等会再来。预约保证你能用但可能浪费（预约了没人来），无锁效率高但人多的时候大家都在抢。

面试要点：Omega 用乐观并发，核心是"全状态复制 + 并行决策 + 事务提交 + 冲突重试"，对比 Mesos 悲观 Offer 的优劣势。

Q: 为什么 AI 训练集群适合 centralized scheduler？

AI 训练的特殊需求

大规模分布式训练（特别是万卡级 LLM 训练）有几个核心需求，这些需求天然适合集中式调度：

Gang Scheduling（all-or-nothing）：分布式训练要求所有 Worker 同时启动、同时通信。一个 1024 卡的 Job，要么 1024 张卡同时到位，要么一张都不要启动——否则拿到部分卡的 Worker 只能空等其他 Worker，浪费资源还容易超时。全局视图才能检查"是否有 1024 张卡能凑成符合拓扑的 Gang"，两级调度的局部 Offer 做不到。
拓扑感知放置：多机多卡训练的通信性能高度依赖拓扑——同机 NVLink > 同机架 RDMA > 跨机架网络。最优放置需要全局计算拓扑匹配度，局部决策（如 Mesos 框架只看 Offer）做不了全局拓扑优化。
碎片化控制：GPU 极其昂贵，碎片化（每个节点剩 1-2 张卡，凑不出 8 卡任务）是最大浪费之一。集中式全局 Bin Packing 可以最大程度减少碎片，局部决策容易导致"每个节点都剩一点，但谁都用不了"。
故障域分散：大训练 Job 的 Worker 要分散到不同机架/电源域/交换机，避免单点故障导致整个 Job 失败。这也需要全局视图。

那可扩展性怎么办？

Borg 已经证明：集中式调度配合(1)本地状态缓存减少 API Server 压力、(2)乐观并发 Bind 而不是全局锁、(3)批量调度和近似算法减少计算、(4)分 Cell（每个 Cell 几千到几万台），完全可以支撑超大规模集群。AI 集群任务类型相对统一（主要是训练 Job，不像 Borg 混跑 Web/MapReduce/ cron），单调度器压力更小。

实际架构

实际的万卡 AI 集群通常是：上层用 Kueue/Volcano 做队列管理、多租户公平、配额（Job 排队和准入），底层用集中式调度器（优化过的 kube-scheduler 或自研）做 Pod→Node 的放置和 Gang/拓扑优化——本质还是"Borg 风格集中式 + 上层队列层"。

面试要点：从 Gang/拓扑/碎片/故障域四个需求出发，说明为什么全局视图必要；再回答可扩展性问题，提缓存/乐观/分 Cell 等优化手段；最后说实际架构是"上层队列 + 下层集中式放置"。

云 GPU 经济学：为什么 Spot 便宜？

云厂商的 IDC 里总有大量空闲计算资源（用户的 On-Demand 实例没跑满、预留实例没卖完、新购机器还没上架等），与其让这些资源空着耗电，不如便宜卖出去——但有个条件：当 On-Demand 用户需要资源时，Spot 实例可以被随时回收。这就是 Spot/Preemptible/抢占式实例的本质：用可被中断换取低价。

价格对比（参考，随时间区域变动）

实例类型	A100 80GB 大概价格（小时）	相对 On-Demand	回收警告时间	是否会被回收
On-Demand（按需）	~$3.0-4.0	100%	N/A	不会（除非你欠费/违规）
Reserved/Commitment（预留）	~$1.8-2.4	60-70%（1-3年合约）	N/A	不会
Spot/Preemptible（抢占式）	~$0.8-1.5	20-40%	30s-2min	会，价格或容量变化时

关键数字：Spot 比 On-Demand 便宜 60-80%。如果能把重算浪费控制在 20% 以内，总成本只有 On-Demand 的 50% 甚至更低——这对大规模训练（几千卡跑几周）来说是百万级别的成本节省。

Spot 回收机制：什么时候会被 kick 掉？

回收原因

容量回收（Capacity Reclamation）：On-Demand 用户需要资源，Spot 实例被赶走。这是最常见原因，热门 GPU 类型（A100/H100）在白天业务高峰时容量紧张。
价格超过出价：Spot 价格是浮动的（随供需变化），如果你的出价低于当前市场价格，实例会被回收。设置"出价 = On-Demand 价格"可以规避这个原因，只承担容量回收风险。
硬件维护/退役：云厂商需要维护物理机时，Spot 实例优先被迁移/回收（On-Demand 通常会被热迁移）。

中断率参考

不同实例类型、不同可用区（AZ）的中断率差异很大：

热门 GPU（A100/H100）：5-20% 周中断率（一周内被回收的概率）
不那么热门的 GPU（如 T4、A10G、旧型号 V100）：1-5% 周中断率
CPU 实例：通常更低，1-10%
多个 AZ/多种实例类型混合：可以降低"同时被回收"的概率（协方差低）

回收信号检测

云厂商	回收警告机制	警告时间
AWS EC2 Spot	轮询 Instance Metadata Service (IMDS) `http://169.254.169.254/latest/meta-data/spot/instance-action`；也可以通过 EventBridge 事件通知	2 分钟
GCP Preemptible/Spot VM	发送 `SIGTERM` 信号给所有进程；也可以轮询 Metadata Server	30 秒（Preemptible）/ 即时后30秒（Spot 可变）
Azure Spot VM	轮询 Metadata Service `http://169.254.169.254/metadata/scheduledevents`；Scheduled Events 提前通知	30 秒
阿里云抢占式实例	实例元数据 + 云监控事件通知	1-5 分钟（可配置）

核心模式：Checkpoint-on-Revocation

用 Spot 跑训练的标准工作流程：

          ┌─────────────────────────────────────────┐
          │                                         │
          ▼                                         │
    提交训练 Job ──► 申请 Spot 实例 ──► 启动训练    │
          │                              │         │
          │                              ├─ 周期性 Checkpoint（每 N 分钟/step）
          │                              │         │
          │                              ▼         │
          │                     收到回收信号？──No──┘
          │                              │ Yes
          │                              ▼
          │                     触发紧急 Checkpoint
          │                              │
          │                              ▼
          │                     优雅终止（Cleanup）
          │                              │
          └──────────────────────────────┘
                                 自动重新提交

关键步骤详解

1. 信号检测与处理

训练进程需要注册 SIGTERM 信号处理器（GCP）或启动一个后台线程轮询 Metadata（AWS/Azure）。一旦检测到回收信号：

立即停止接受新的 batch
完成当前正在处理的 batch（不要在 step 中间保存，容易损坏 checkpoint）
触发 checkpoint 保存
Checkpoint 保存完成后，发送释放信号，让 Job 标记为失败/需要重启

重要：警告时间只有 30s-2min！Checkpoint 保存必须在这个时间内完成。HDFS/S3/对象存储上传大 checkpoint（几十 GB 到几百 GB）可能需要几分钟，因此：

平时周期性 checkpoint 到本地 SSD/内存盘，紧急时只需要把最新 checkpoint 上传到共享存储
或者持续异步上传 checkpoint，紧急时只需要等当前上传完成
模型+优化器状态 checkpoint 做分片，多 Worker 并行写，加快保存速度

2. 周期性 Checkpoint 策略

不能等回收信号来了才做第一次 checkpoint——需要平时就定期保存。Checkpoint 频率是一个 trade-off：

Checkpoint 频率	丢失工作量	Checkpoint 开销	适用场景
每 1 小时	平均 30 分钟重算	低	中断率低、checkpoint 很大（如大模型训练）
每 15 分钟	平均 7.5 分钟重算	中	大多数场景
每 5 分钟	平均 2.5 分钟重算	高	中断率高、checkpoint 小、单步计算代价高

经验公式：选择 checkpoint 间隔，使得"checkpoint 保存开销"约等于"预期丢失重算开销"——保存时间 ≈ (1/中断率) 内的平均丢失时间。但实际上，大多数团队直接配置为每 10-30 分钟，或按 step 数（如每 1000 step）。

3. 自动重试机制

Checkpoint 保存后，Job 应该由调度器/工作流管理器（如 Argo Workflows、KubeFlow、Volcano Job、Airflow）自动重新提交，从最新 checkpoint 恢复。重启时可能需要：

申请新的 Spot 实例（可能换 AZ、换实例类型）
加载 checkpoint 到新实例
重建数据加载器、NCCL 通信组
继续训练

不要让人工介入——Spot 回收是常态，必须完全自动化。

分布式训练的 Spot 容错策略

单卡训练的 Checkpoint-on-Revocation 很简单，但分布式训练（多机多卡）要复杂得多：一个 Worker 被回收，整个 Job 都要停（因为 NCCL 通信环断了，所有 Worker 都会 hang 或 crash）。

策略一：协调 Checkpoint（Elastic Training 弹性训练）

标准做法：

任意一个 Worker 检测到回收信号，立即通知所有其他 Worker（通过 NCCL 带外通信、共享存储标记、或 rendezvous 服务）
所有 Worker 同步停止训练，在当前 step 边界共同保存 checkpoint
所有 Worker 优雅退出
Job 控制器自动重新提交，申请新的 Worker（数量可能相同也可能不同，弹性训练支持 world size 变化）
新的 Worker 组加载 checkpoint，重新初始化，继续训练

框架支持：

PyTorch：TorchElastic（torchrun）原生支持弹性训练，Worker 变化时自动 rendezvous 重启
DeepSpeed：支持 checkpoint 分片保存和恢复，配合弹性训练可以处理 Worker 增减
Megatron-LM：有自己的 checkpoint 和容错机制
JAX/Flax：通过 Orbax 等库做 checkpoint

策略二：Spot + On-Demand 混合部署

把关键节点放在 On-Demand，Worker 用 Spot：

Parameter Server / Coordinator / Scheduler：On-Demand，永远不回收——这些节点挂了整个集群状态丢失，代价最大
训练 Worker：Spot，可以被回收，回收后只需要 Worker 组重建
混合 Gang Scheduling：允许部分 Gang 用 Spot，容忍一定的 Worker 流失

更极端一点：关键 Rank（如 Rank 0，负责 checkpoint 保存、日志、coordination）放 On-Demand，其余 Worker 放 Spot。Rank 0 不丢，checkpoint 机制就更可靠。

策略三：Spot Fleet / 多实例类型分散

"不要把鸡蛋放在一个篮子里"：

跨可用区（AZ）：在多个 AZ 申请实例，不同 AZ 的容量回收是不相关的——所有 AZ 同时回收的概率极低
跨实例类型：不要只申请 A100，同时申请 A100-80G、A100-40G（如果模型放得下）、甚至 A10G 做混合部署，不同实例类型的回收不相关
Spot Fleet / Auto Scaling Group：配置云厂商的 Spot Fleet，自动在多个实例类型/AZ 中选最便宜最可用的组合

弹性训练的好处：如果支持弹性 world size，那么不需要等所有 Worker 都回来——只要拿到足够多的新 Spot 实例，就可以恢复训练（world size 变小，吞吐降低，但至少训练继续，不会空等）。

策略四：出价策略

简单但有效：把 Spot 出价设为 On-Demand 价格。这样不会因为价格上涨被回收，只会因为容量不足被回收。容量回收是真的资源不够，价格问题只是你出价不够高——用 On-Demand 价格出价可以消除价格因素导致的回收，剩下的只有容量回收，中断率会明显降低。

毕竟 Spot 价格到 On-Demand 的时候，不如直接用 On-Demand 了。

推理服务能跑在 Spot 上吗？

结论：在线推理不建议直接用 Spot，但离线批处理推理/异步推理可以。

为什么在线推理难用 Spot？

延迟 SLO：在线推理有严格的延迟 SLO（P99 < 几百 ms），Spot 被回收时 2 分钟内实例就没了——正在处理的请求会失败，新请求无法路由
冷启动开销：加载大模型（LLM 几十 GB）需要几十秒到几分钟，新实例启动后不能立刻接流量
KV Cache 丢失：推理实例的 KV Cache 都在本地 GPU 内存里，实例回收后 Cache 全丢，新实例需要重建

什么推理场景可以用 Spot？

离线批处理推理 / Batch Inference：比如"晚上把昨天的日志全部过一遍模型"、"给 1 亿张图片打标签"。这种任务没有严格延迟要求，可以拆分、可以重试、可以 checkpoint 进度，和训练一样——非常适合 Spot。
异步推理 / 消息队列驱动：请求进队列，Worker 从队列取处理，Worker 挂了请求不丢，重新入队给其他 Worker 处理。只要队列保留足够长的时间，Spot 挂了不丢请求。
Warm Pool Standby 热备：主要容量用 On-Demand，额外用 Spot 实例做"额外算力"处理突发流量。Spot 被回收时，On-Demand 容量还在，只是降容不宕机。Spot 加进来提升吞吐，被回收时 graceful drain，把正在处理的请求处理完再退出。

Spot + On-Demand 混合推理策略

                    ┌─────────────────────┐
                    │  Load Balancer      │
                    └─────────┬───────────┘
                              │
              ┌───────────────┴───────────────┐
              ▼                               ▼
     ┌─────────────────┐             ┌─────────────────┐
     │ On-Demand 池    │             │ Spot 池         │
     │ （基础容量）    │◄────────────┤ （弹性突发容量）│
     │ 永远在线        │   回收时    │ 处理多余流量    │
     │ 保证 SLO        │   drain     │ 挂了不影响服务  │
     └─────────────────┘             └─────────────────┘

On-Demand 承载保底流量（如按历史 P50 流量预留），Spot 承载流量尖峰。Spot 实例收到回收信号时，停止接新请求，处理完正在处理的请求后退出——这需要服务支持 graceful shutdown 和连接 draining（K8s 有 preStop hook + readinessProbe 可以做）。

Kubernetes 集成：Kueue/Karpenter/Descheduler

在 K8s 上用 Spot GPU 需要几个组件配合：

1. 节点标签与污点（Taint/Toleration）

Spot 节点应该被标记 capacity-type=spot 并加上污点，避免不支持容错的工作负载误调度上来：

nodeSelector:
  node.kubernetes.io/instance-type: p4d.24xlarge  # A100
  karpenter.sh/capacity-type: spot                 # Spot 实例
tolerations:
- key: "karpenter.sh/capacity-type"
  operator: "Equal"
  value: "spot"
  effect: "NoSchedule"

2. Karpenter：自动扩缩容 Spot 节点

Karpenter 是 AWS 开源的 K8s 节点自动扩缩容工具（替代 Cluster Autoscaler），可以：

根据待调度 Pod 的需求，自动申请最合适的 Spot 实例类型（在用户配置的多实例类型中选最可用最便宜的）
自动处理 Spot 节点回收——收到中断通知后自动 cordon + drain，把 Pod 驱逐到其他节点
支持 Spot diversification（跨实例类型/AZ 分散）

Karpenter 配置示例：

requirements:
- key: karpenter.sh/capacity-type
  operator: In
  values: ["spot", "on-demand"]  # 优先 Spot，不行 fallback On-Demand
- key: node.kubernetes.io/instance-type
  operator: In
  values: ["p4d.24xlarge", "p4de.24xlarge", "p3dn.24xlarge"]  # 多实例类型

3. Kueue：队列级 Spot 管理与 Preemption

Kueue 通过 ClusterQueue 和 ResourceQuota 管理 Spot/On-Demand 配额：

把 Spot 资源作为一个独立的 resource flavor，有自己的配额
支持 Preemption：当集群资源紧张、或 On-Demand 有更高优先级任务需要资源时，可以抢占 Spot 任务
Reclaimable Spot：Spot 任务被抢占时自动 checkpoint 并重新排队

4. Pod 优雅终止：preStop Hook

Pod 被驱逐时（无论是 Spot 回收还是抢占），K8s 会发 SIGTERM，然后等 terminationGracePeriodSeconds 后强杀（SIGKILL）。给训练 Pod 配置足够的优雅终止时间：

terminationGracePeriodSeconds: 300  # 给 5 分钟做 checkpoint 和 cleanup
containers:
- name: trainer
  lifecycle:
    preStop:
      exec:
        command: ["/bin/sh", "-c", "python /scripts/trigger_checkpoint_and_wait.py"]

preStop 脚本执行 checkpoint 并等待保存完成，然后退出；退出后 K8s 才会删除 Pod。

5. Descheduler：主动 Spot 驱逐

Descheduler 可以根据策略主动驱逐 Pod，比如：

Spot 价格上涨时主动驱逐，换更便宜的实例
低优先级 Spot 任务占着资源，高优任务来了需要让位置
节点利用率过低时，迁移 Pod 到其他节点缩容

成本模型：Spot 真的划算吗？Break-Even 分析

Spot 不是稳赚不赔——被回收后要重算，重算浪费时间和钱。算一下 break-even：

总成本(Spot) = Spot 单价 × 运行时间 × (1 + 浪费率 Waste Ratio)
总成本(On-Demand) = On-Demand 单价 × 运行时间

当 总成本(Spot) < 总成本(On-Demand) 时划算：
  Spot 单价 × (1 + Waste Ratio) < On-Demand 单价
  1 + Waste Ratio < On-Demand / Spot 单价
  Waste Ratio < (On-Demand / Spot 单价) - 1

数值例子：On-Demand = $3/h，Spot = $1/h（3折）：

Waste Ratio（重算浪费比例）	实际每小时成本	vs On-Demand
0%（完全不浪费）	$1.00	省 67%
20%	$1.20	省 60%
50%	$1.50	省 50%
100%	$2.00	省 33%
200%	$3.00	持平
>200%	>$3.00	亏了

结论：当 Spot 是 On-Demand 的 1/3 价格时，只要浪费率不超过 200%（平均每次回收导致重算 2 倍已运行时间），就比 On-Demand 划算。实践中，如果 checkpoint 频率合理（15-30 分钟）、重启自动化，waste ratio 通常在 5-30%，Spot 非常划算。

浪费率估算

Waste Ratio 取决于：

Checkpoint 间隔：最坏情况丢失 checkpoint 间隔内的全部计算，平均丢失间隔/2
Checkpoint 保存开销：保存 checkpoint 本身花的时间（读写共享存储）
重启开销：重新申请实例、加载模型、重建 NCCL 通信组、数据加载器 warm-up 的时间（通常 1-10 分钟）
中断频率：越频繁被回收，重启和 checkpoint 开销占比越高

公式近似：Waste Ratio ≈ (MTTR / MTTF) + (Checkpoint时间 / Checkpoint间隔)，其中 MTTR 是平均修复/重启时间，MTTF 是平均无故障时间（平均多久被回收一次）。

风险矩阵：什么任务适合跑 Spot？

任务类型	Spot 适用性	原因	建议
开发/实验 Job（<1小时）	✅ 非常适合	运行时间短，被回收概率低（MTTF 通常几小时到几天），就算被回收重跑代价也小	直接用 Spot，甚至可以不用 checkpoint
中小规模训练（几小时到1天）	✅ 适合	Checkpoint 做好，重启几次也能跑完，成本节省明显	周期性 checkpoint + 自动重试
分布式训练（多机多卡）	⚠️ 需要改造	一个 Worker 挂全 Job 重启，协调 checkpoint 复杂，但成本节省巨大	弹性训练 + 关键节点 On-Demand + 多 AZ/实例类型分散
大规模生产训练（几天到几周，千卡）	⚠️ Spot+On-Demand 混合	全 Spot 风险太高（每天都可能被回收几次，重启开销大），全 On-Demand 太贵	关键 Rank/PS 用 On-Demand，Worker 用 Spot 混搭；或者按比例 30% On-Demand + 70% Spot
在线推理服务（有严格 SLO）	❌ 不适合直接用	回收导致请求失败、冷启动慢、SLO 无法保证	用 On-Demand 做基础容量，Spot 做弹性突发
离线批处理推理	✅ 非常适合	没有严格延迟，可以拆任务、重试、checkpoint 进度	直接用 Spot，配合任务队列
异步/队列驱动推理	✅ 适合	请求不丢，Worker 挂了重入队	MQ 保证消息不丢，Spot 作为 Worker 池

Spot 反模式（不要这么做）

没有 checkpoint 就跑长训练：一被回收几天进度没了，浪费的算力比 Spot 省的钱多得多
所有 Worker 只在一个 AZ/一个实例类型：这个 AZ/实例类型容量紧张时，所有 Worker 同时被回收，Job 完全中断
Checkpoint 只写本地盘：实例被回收本地盘也没了，checkpoint 白做了；checkpoint 必须写共享持久存储（S3/HDFS/NFS/EFS）
Checkpoint 保存时间比警告时间长：30 秒警告但 checkpoint 要存 5 分钟，最后 SIGKILL 来了 checkpoint 没存完，文件损坏
单 Worker 挂了不处理，等所有 Worker 都超时：一个 Spot 被回收，其他 Worker 空等 NCCL 超时（可能 30 分钟），浪费算力；应该有快速失败机制

Spot 实例调度面试问答

Q: Spot 实例被回收了训练怎么办？

标准流程：Checkpoint-on-Revocation

检测回收信号：GCP 收 SIGTERM，AWS/Azure 轮询 Metadata Service 或事件通知，警告时间 30s-2min。
优雅停止：停止接新 batch，完成当前 step（不要在 step 中间保存，避免 checkpoint 损坏）。
紧急保存 Checkpoint：把模型权重、优化器状态、训练进度（epoch/step、数据加载器位置、随机种子等）保存到持久共享存储（S3/HDFS/EFS），不能写本地盘。
Cleanup 退出：释放资源，通知调度器/Job 控制器这个 Job 中断了。
自动重新提交：工作流系统（Argo/KubeFlow/Volcano）检测到 Job 失败，自动重新提交，申请新实例。
恢复训练：新实例加载最新 checkpoint，重建数据加载器、NCCL 通信组，从 checkpoint 的 step 继续训练。

关键细节

(1) 平时必须做周期性 checkpoint（每 10-30 分钟），不能等回收信号才第一次存——回收了进度全丢。(2) Checkpoint 保存必须在警告窗口内完成，大 checkpoint 做分片多进程并行写、本地 SSD 缓存、异步上传。(3) 整个流程必须完全自动化，不需要人工介入。

面试要点：按"信号检测 → 优雅停 → Checkpoint → 重试 → 恢复"流程讲，提周期性 checkpoint、持久存储、自动化这几个关键点。

Q: 分布式训练怎么应对 spot 回收？一个 Worker 挂了怎么办？

问题本质

分布式训练（数据并行/张量并行）NCCL 通信是 all-reduce/all-gather 等集合通信，一个 Worker 挂了通信环断了，其他所有 Worker 会 hang 或 crash——单卡的"自己 checkpoint 自己重启"不够，需要协调所有 Worker。

核心策略

协同 Checkpoint + 弹性训练：任何一个 Worker 检测到回收信号，立即通知所有 Rank（通过带外通信、共享存储标记、或 rendezvous）；所有 Worker 同步在 step 边界共同保存分片 checkpoint，然后一起退出；Job 控制器自动重新提交，新的 Worker 组 rendezvous、加载 checkpoint、恢复训练。框架用 TorchElastic、DeepSpeed、Megatron 的弹性训练能力支持 world size 变化。
关键节点 On-Demand，Worker Spot 混合：Coordinator/Rank 0/Parameter Server 放 On-Demand 不回收（这些节点状态最关键），计算 Worker 用 Spot；Rank 0 负责 checkpoint 协调，它不丢整个 checkpoint 流程更可靠。
多 AZ/多实例类型分散：Spot Fleet 在多个可用区、多个兼容实例类型（如 A100-40G/80G、甚至跨代）分散申请，降低同时被回收的概率——不同 AZ 的容量是独立的。
出价 = On-Demand 价格：消除因价格上涨导致的回收，只承担真正的容量回收风险，中断率降低。
快速失败机制：不要等 NCCL 默认超时（通常 30 分钟），检测到一个 Worker 失联后快速触发全 Job 停止和 checkpoint，减少空等浪费。

面试要点：先说分布式的特殊性（一个挂全挂），然后按"协同checkpoint + 混合部署 + 分散风险 + 快速失败"四个策略讲，提 TorchElastic 等框架支持。

Q: Spot 和 on-demand 比例怎么定？

核心 trade-off

Spot 便宜但会被回收（需要重算），On-Demand 贵但稳定。比例取决于：(1) 任务对中断的容忍度（checkpoint 做得好不好、重启开销大不大）；(2) 训练时长；(3) 业务对完成时间确定性的要求。

经验比例

场景	On-Demand 比例	Spot 比例	原因
开发实验（短，可重跑）	0%	100%	跑的时间短，被回收概率低；就算回收了重跑代价小，不需要保留 On-Demand
中小规模训练（几小时-1天）	0-20%	80-100%	Checkpoint 做好，重启几次也能跑完，全 Spot 最省成本
大规模分布式训练（几天-几周，千卡）	20-40%	60-80%	关键节点（Rank 0/PS/Coordinator）必须 On-Demand；计算 Worker 混合；全 Spot 风险太高，重启开销太大影响总完工时间
有截止日期的生产训练	40-60%	40-60%	不能无限等重启，需要足够的 On-Demand 容量保证进度稳定，Spot 作为加速补充
在线推理	100%（基础）+ 0-50% Spot（弹性）	只用 On-Demand 保底，Spot 做突发	SLO 不能破，Spot 挂了 On-Demand 还能服务

成本 break-even 计算

实际选择时算一下账：假设 Spot 3折，重算浪费 20%，那么 Spot 实际成本是 On-Demand 的 0.3 × 1.2 = 36%——省 64%。如果 On-Demand 占 30%、Spot 占 70%，平均成本是 0.3×100% + 0.7×36% ≈ 55%——相当于全 On-Demand 打 5.5 折，同时风险可控。

如果训练很重要怕 Spot 中断影响交付时间，可以预留 100% On-Demand 作为"保底资源池"——On-Demand 跑基础进度，有额外 Spot 就加进去加速，Spot 回收了不影响 On-Demand 继续跑（弹性训练缩容）。

面试要点：分场景给比例，讲清 trade-off，用成本 break-even 数字说话，不要给固定答案。

Q: 推理服务可以用 spot 吗？

结论：分场景

有严格延迟 SLO 的在线推理不建议直接跑 Spot，但离线批推理、异步推理可以，在线推理可以用 Spot 做弹性补充但不能做主力。

为什么在线推理直接用 Spot 不行？

(1) SLO 无法保证：Spot 被回收时 2 分钟内就没了，正在处理的请求直接失败，新请求无法路由；(2) 冷启动慢：LLM 几十 GB 模型加载到 GPU 需要几十秒到几分钟，新实例不能立刻接流量；(3) KV Cache 丢失：本地 KV Cache 全丢，即使流量切走，新实例没有 Cache 性能下降。

哪些推理场景可以用 Spot？

离线 Batch Inference：如"夜间批量跑昨日数据推理"、"给数据集打标签"——没有延迟要求，可以拆分、重试、checkpoint 进度，和训练一样，完全适合 Spot。
异步/消息队列推理：请求先进 MQ（Kafka/RabbitMQ），Worker 从队列消费处理，结果异步返回。Worker 挂了请求不丢，重新入队给其他 Worker；Spot 作为 Worker 池非常合适。
在线推理 Spot 弹性池（Warm Pool）：主力容量用 On-Demand 保证 SLO（按 P50-P70 流量预留），额外用 Spot 实例处理流量尖峰。Spot 收到回收信号时，先从 LB 摘流量（readiness fail），处理完正在处理的请求（graceful connection draining），再退出。Spot 加进来提升吞吐，被回收时只是降容不宕机。

面试要点：不要直接说"可以"或"不可以"，要分三种场景（在线SLO/离线batch/弹性补充）分别回答，讲清楚每种场景的原因和做法。