GPU集群抢占式调度：给紧急任务开一条“急诊通道”

可视化演示

交互展示抢占触发条件、三种抢占策略对比和检查点恢复机制，理解多租户环境下的资源调度与SLA保障

抢占触发条件

急诊分诊台上，护士手握电话：120 报告三分钟后送来一位心梗病人。分诊护士要回答一个关键问题——现在就要清空手术室，还是先等等？答案取决于两条硬指标：新病人是否比正在手术的病人危急得多？手术室门口的常规病人是否已经等了太久、再拖要出医疗事故？

GPU 集群的调度器也在做同样的分诊。它以事件驱动的方式监听任务状态变化，抢占触发条件归结为三类：高优任务插队、排队超时提升和人工优先级调整。高优任务插队是最常见的触发点——当一个新的高优任务提交，且当前所有 GPU 都被占用时，调度器会比较新任务与运行中任务的优先级。注意，不是“新任务优先级更高就抢”，而是必须高出一个阈值 Δ。这个阈值是防抖设计：集群里任务进进出出，优先级波动是常态，设太小会导致调度器频繁打断任务，检查点开销甚至超过抢占收益。

排队超时提升是防止任务“饿死”的第二道保险。一个低优任务如果在队列里等待超过 SLA 承诺的上限（比如 2 小时），系统会动态上调它的优先级，直到它能抢占一个 GPU。这相当于分诊台承诺：“普通病人等待不超过 4 小时，超时自动升级为加急。”人工调整则是管理员用命令把某个任务标记为紧急，对应救护车直接打电话指定手术室。

分诊台最后给出结论：抢不抢，不是看心情，而是看两条量化指标的“或”运算。急诊通道的大门，始终由规则把关，而不是调度员拍脑袋——这正是抢占式调度在工业集群里能被信任的前提。

抢占策略设计

急诊科主任面临一个更棘手的抉择：手术台上有两台常规手术，一台刚开腹 10 分钟，另一台已经缝合到最后一层。现在必须腾出一间手术室抢救心梗病人——停哪台？答案显而易见：停缝合到一半的那台太可惜，不如停刚开腹的。

这就是抢占策略设计的核心：决定“抢谁”以及“怎么抢”。业界有两大模式：全抢占（Preemption）和半抢占（Graceful Preemption）。全抢占简单粗暴——调度器立刻杀掉或挂起低优任务，把资源让给高优任务，适合任务有完善检查点、抢占成本低的场景。半抢占则像医生缝合完最后一针再下台——给被抢占任务一个宽限期（Grace Period），允许它把当前迭代跑完、保存检查点后主动退出，适合无法强制中断的场景。Slurm 里的 CANCEL/REQUEUE 对应全抢占，CHECKPOINT 模式则更接近半抢占。

选定模式后，还要选受害者。调度器不会随机挑一个任务下手，而是计算每个候选任务的抢占代价：运行进度越多，被夺走时浪费的计算量越大；优先级越高，动它引发的“民愤”越大。所以最优受害者往往是“进度少、优先级低”的任务——就像急诊医生选择开腹不久的病人，而不是缝合到一半的病人。

急诊科的智慧在于：抢救不是把手术室掀个底朝天，而是精确选择代价最小的停台方案。集群管理员配置抢占策略时，本质上就是在给调度器写一本“停台手册”——明确哪些台子可以停、停之前给多少时间穿针引线。

检查点机制

被暂停的手术为什么能无缝续接？因为主刀医生留下了详细的手术记录：切到第几层、出血量多少、缝了几针、用了哪种麻醉。没有这份记录，重新打开腹腔等于从零开始，病人白挨一刀。

GPU 任务的“手术记录”就是检查点（Checkpoint）。它是一份完整的训练状态快照，通常包含四类内容：模型权重、优化器状态（如 Adam 的一阶二阶动量）、当前 epoch 和步数、随机数生成器种子及学习率调度器状态。缺了任何一项，恢复后的训练就“失忆”——要么精度异常，要么数据顺序错乱。这就是为什么框架广泛采用 torch.save 与 torch.load 配合 model.state_dict() 与 optimizer.state_dict() 落盘的原因。

检查点的保存频率是个权衡艺术。存太频繁，IO 开销拖慢训练——假设每 10 分钟存一次、每次花 30 秒，训练有效时间就少了 5%；存太稀疏，一旦被抢占，丢失的进度太多。工业界常用的做法是周期快照 + 异步落盘：每 N 个 step 触发一次内存快照，再用后台线程写入分布式文件系统。恢复流程则像一个标准抢救预案：加载权重 → 装载优化器状态 → 恢复随机种子 → 续跑。断点续跑的恢复时间完全取决于检查点加载的 IO 速度。

手术记录越详细，抢救后恢复越快；但记录本身也占用医生时间。GPU 集群的检查点设计就是在这对矛盾中找平衡——让“病历”足够细，又不至于让医生光顾着写病历忘了做手术。

保护与SLA

急诊室的秩序不能失控：如果救护车一辆接一辆地送来病人，普通门诊的病人是不是永远排不上手术？医院对此有明文规定——择期手术病人等待超过一定时限，必须安排手术，哪怕要临时加台。这条规定，就是医院的"SLA"。

GPU 集群里，SLA 保护是抢占式调度的刹车片。没有它，低优先级任务可能被反复抢占，“饿死”在队列里——永远无法完成，GPU 浪费在反复保存与恢复检查点上。三种常见保护机制构成了护栏：最小运行时间保障，任务一旦开始运行，在至少 X 分钟内禁止被抢占，相当于手术后病人入住恢复室，不会被立刻赶走；排队超时升级，低优任务排队超过 SLA 上限后自动提权，保证它能抢到资源；抢占次数上限，单个任务在一天内最多被抢占 K 次，超过后调度器拒绝再抢它——相当于合情合理的“免死金牌”。

此外还有配额与权限控制：不是任何用户都能提交高优任务。集群通过优先级配额（如 Slurm QOS 的 GrpTRES、K8s 的 ResourceQuota）限制高优任务的总量，防止有人滥用急诊通道。SLA 的量化指标通常是任务排队时间 P95 分位数：系统承诺 95% 的任务等待时间不超过规定值，剩余的 5% 允许超限。

急诊室不会让普通病人等到天荒地老。SLA 保护的实质，是把“不饿死任何人”从道德口号变成可量化的数学约束——这是共享 GPU 集群在多团队协作中维持信任的基石。

Slurm配置实践

医院的信息系统里，每个科室都有应急响应等级：急诊科最高，门诊部最低。Slurm 就像这套信息系统——管理员在配置文件中定义谁有资格抢占、怎么抢。

Slurm 抢占调度的第一站是 slurm.conf 的全局配置。PreemptType 指定抢占插件，常用 preempt/qos（按 QoS 优先级抢占）；PreemptMode 决定抢占动作：OFF 完全关闭，CANCEL 直接取消低优任务，REQUEUE 取消后让任务重新排队（无检查点则从头跑），CHECKPOINT 先保存检查点再抢占——生产环境推荐 REQUEUE 或 CHECKPOINT。

第二站是 QOS 关联：每个任务队列（Partition）绑定指定的 QoS，QOS 里配置 Priority 数值或 GrpTRES 资源上限。高优 QOS 的任务可以抢占低优 QOS 的任务，优先级数值差满足 PreemptExemptTime 的豁免规则——任务运行超过豁免时间后不再接受抢占。最后，禁止抢占的配置用 PreemptExemptTime 或单独设置任务的 --no-requeue 标志实现，相当于给重要任务贴“免打扰”标签。

管理员在 Slurm 里的工作，就像给医院各科室设定响应等级：急诊科随时可以叫停门诊，但门诊病人等久了也会自动升级。配置的关键是先想清楚业务优先级分层，再落成 QOS 数字——而不是等出了事故才手忙脚乱。

K8s配置实践

如果说 Slurm 是老牌三甲医院的信息系统，K8s 就是互联网医院的新架构——一切都是声明式配置，调度器像 AI 分诊机器人一样自动化运作。

K8s 的抢占机制核心是 PriorityClass 资源对象。管理员先定义一个调度优先级类（如 high-priority 值 1000），Pod 通过 priorityClassName 引用它。调度器为每个待调度 Pod 计算优先级数值；当高优 Pod 无法找到满足资源需求的节点时，就会进入抢占流程：找出所有可能腾出资源的低优 Pod，驱逐它们，让高优 Pod 落座。preemptionPolicy 参数可以设置 Never，表示该 PriorityClass 的 Pod 永不抢占别人，只做排队等待。

K8s 的驱逐比 Slurm 更温和——遵循 PDB（PodDisruptionBudget） 保护，确保每次驱逐不会让某个服务的副本数低于红线；真正的驱逐动作是向 kubelet 发送优雅终止信号，给 Pod 留出退出时间，运行中的进程收到 SIGTERM 后可以尝试保存状态。这就是 K8s 的“半抢占”底色。

K8s 的抢占哲学和急诊室一样：不动最危重的病人，专挑已完成治疗、即将出院的床位周转。POD 被驱逐不是灾难——弹性本来就是云原生的底色，而抢占只是让资源流动得更聪明。

平衡与调优

医院院长站在月中复盘会上：急诊抢救成功率是高了，可普通门诊的手术量下滑了 20%，医生们抱怨手术台被反复打断。这就是抢占式调度的永恒课题——平衡。

调优的量化目标是一个多目标优化问题：最大化 GPU 利用率（U），最小化任务平均等待时间（T_wait），同时控制抢占频率（f_preempt）。三者互相牵制：抢占太激进，高优任务爽了，但检查点开销吃掉利用率；抢占太保守，低优任务不饿死了，但紧急任务被堵在队列里。工程实践通常用加权评分法，给三个目标配权重系数 α、β、γ，再滚动观察指标曲线。

具体调优手段包括：调整抢占触发阈值 Δ（防抖），修改检查点间隔（IO 开销与进度损失的折中），设置宽限期长短（半抢占的耐心程度），以及微调 SLA 上限。推荐做法是在测试集群上回放历史任务日志，比较不同参数组合下的目标函数值——就像医院用过去一年的急诊数据做仿真，而不是直接拿病人做实验。

没有放之四海皆准的参数，只有持续观测、小心调优的耐心。医院院长最终发现：把急诊通道拓宽一点，同时给门诊安排“最长等待不超过 3 小时”的承诺，整体满意度反而最高——抢占式调度的艺术，正是在冲突的目标之间找到那道最优的窄门。

AI 应用场景

Python 演示

import heapq  class Job:    """模拟一个 GPU 训练任务"""     def __init__(self, name, priority, submit_time, duration):        self.name = name        self.priority = priority        # 数值越大越紧急        self.submit_time = submit_time        self.duration = duration        self.progress = 0.0             # 已完成 GPU 时长        self.checkpointed = 0.0         # 已保存的检查点进度     def remaining(self):        return self.duration - self.progress     def __repr__(self):        return (f"{self.name}(prio={self.priority}, "                f"progress={self.progress:.1f}/{self.duration})")  def preemptive_schedule(jobs, gpu_count=1, dt=0.5):    """逐帧推进抢占式调度, 返回事件时间线"""    queue = []          # 元组(-priority, submit_time, job)    gpus = [None] * gpu_count    timeline = []    time = 0.0    idx = 0    jobs = sorted(jobs, key=lambda j: j.submit_time)     while idx < len(jobs) or queue or any(gpus):        # 提交到点的新任务        while idx < len(jobs) and jobs[idx].submit_time <= time:            job = jobs[idx]            heapq.heappush(queue, (-job.priority, job.submit_time, job))            idx += 1         # 抢占判定: 队头任务比运行中任务更紧急则抢占        if queue:            top_prio = -queue[0][0]            for gi in range(gpu_count):                g = gpus[gi]                if g is not None and top_prio > g.priority:                    g.checkpointed = g.progress                    gpus[gi] = None                    heapq.heappush(queue, (-g.priority, g.submit_time, g))                    _, _, attacker = heapq.heappop(queue)                    gpus[gi] = attacker                    timeline.append(                        (time, f"抢占: {attacker.name}拦截了{g.name}"))                    break         # 运行与恢复: 空槽位弹队列, 正在运行则推进        for gi in range(gpu_count):            if gpus[gi] is None:                if queue:                    _, _, nxt = heapq.heappop(queue)                    nxt.progress = nxt.checkpointed                    gpus[gi] = nxt                    timeline.append((time, f"启动: {nxt.name}"))            else:                g = gpus[gi]                g.progress += dt                if g.progress >= g.duration:                    timeline.append((time, f"完成: {g.name}"))                    gpus[gi] = None         time += dt     return timeline  if __name__ == "__main__":    sample_jobs = [        Job("常规训练A", priority=5, submit_time=0.0, duration=10),        Job("紧急微调B", priority=80, submit_time=1.0, duration=4),        Job("数据分析C", priority=20, submit_time=2.5, duration=6),    ]    for t, event in preemptive_schedule(sample_jobs):        print(f"t={t:5.1f} | {event}")

1. heapq.heappush(queue, (-job.priority, job.submit_time, job))用负优先级技巧把最小堆变成“最高优先级先出队”，是抢占模拟的发动机。
2. if g is not None and top_prio > g.priority:抢占判定的核心行：只有新任务优先级严格高于运行中任务才触发，对应正文中的 Δ 阈值思想。
3. g.checkpointed = g.progress保存检查点：记录当前已完成进度，后续恢复时从这里续跑，而不是从零开始。
4. nxt.progress = nxt.checkpointed从检查点恢复：任务再次启动时，把进度设置成上次保存的值，模拟“断点续跑”。
5. timeline.append((time, f"抢占: {attacker.name}拦截了{g.name}"))把抢占事件写入时间线，便于分析调度器的行为是否符合预期。

常见误区

面试题