Slurm/K8s调度：GPU共享与切分

可视化演示

GPU资源的“两面性”：显存与算力

回到我们那间忙碌的后厨。一口大铁锅（GPU）其实包含两类宝贵的资源：灶眼的数量和火力大小（算力），以及储藏柜的容积（显存）。灶眼决定了同时能翻炒多少食材——对应GPU的计算核心（CUDA Core）数量和频率；储藏柜决定了能存放多少食材——对应显卡上的显存容量。有趣的是，一口锅的灶眼和储藏柜往往不成正比：有的锅灶眼多但储藏柜小（算力型显卡），有的锅灶眼少但储藏柜很大（显存型显卡）。

当我们说“共享GPU”时，本质上是在回答两个问题：储藏柜的格子怎么分？灶眼的火力怎么分？一个训练大语言模型的任务，像是要同时炖几百斤高汤——它对储藏柜（显存）的需求极大，动辄几十GB，但真正炒菜时也许只用一半灶眼；而一个实时图像识别任务，则像是做一道讲究速度的炝炒时蔬——要大火快炒（高算力），但食材很少（显存需求低）。因此，“一刀切”的独占模式往往造成资源浪费：大显存任务占着锅，灶眼却闲置大半。

共享的第一步，就是识别任务的“食材需求”和“火候需求”。假设一口锅的总储藏容积为 \(M_{\text{total}}\)，一道菜最少需要 \(M_{\text{job}}\) 的食材存储空间，那么这口锅最多能同时服务多少道这样的菜呢？

回到比喻里：一口储藏柜有80格，一道菜至少需要30格，那最多能同时做2道菜（80÷30=2.66，向下取整为2），剩下的20格只能闲置，这就是显存维度对共享数量的硬约束。而在算力维度上，只要任务的实际灶眼用量有富余，共享就能继续叠加——当然，这会把我们带到“轮流用锅”和“砌墙隔灶”的方案上去。

时间片调度：GPU的“轮流用锅”

后厨最朴素的分餐方案就是“排队等锅”：既然一口锅不能同时做所有菜，那就规定每道菜轮流用锅炒几分钟，由排班主管掐表切换。这就是时间片调度（Time-slicing）的核心思想——多个任务在极短的时间间隔内交替使用整个GPU。

在NVIDIA的驱动实现中，时间片调度器会让多个计算上下文（CUDA Context）共享一对GPU通道：任务A跑50微秒，切换到任务B跑50微秒，再切回任务A……由于切换频率非常高，从用户视角看，多个任务似乎“同时”在运行。这种共享方式的优点是实现简单、无需任何硬件改造，也不需要给每个任务划分固定资源边界；缺点是切换有代价，切换瞬间GPU的缓存、寄存器状态需要保存和恢复，就像厨师轮换时要洗锅、重新摆台一样，总会有几秒钟的空档。

时间片模型的算力分配非常直观：假设GPU的总算力为 \(P_{\text{total}}\)，有 \(N\) 个任务在轮流使用，那么每个任务在理想情况下的等效算力为：

时间片调度的妙处在于“看不见的排班成本”：如果每个任务的GPU利用率不足10%，时间片共享几乎是无损的——因为切换空闲时段的代价极低；可如果多个任务都很“饥饿”（各自都想要100%算力），频繁切换就会导致缓存不断被冲刷、命中率骤降，这就是时间片共享的性能天花板。它适合那些本身算力需求不高、但对显存容量有硬性要求的任务——分不到灶眼的完整火力，但至少能把食材放进储藏柜。

MIG硬件切分：后厨砌墙

时间片调度虽然灵活，但存在软肋：任务之间没有硬性隔离，一个任务崩溃可能拖累同锅的其他任务，就像一位厨师把锅烧糊了，整个后厨都得跟着呛。NVIDIA为高端GPU（如A100、H100）设计了MIG（Multi-Instance GPU）技术，相当于在物理层面给大铁锅砌上实墙，将一个GPU分割成最多7个独立的GPU实例。

MIG切分的核心特点是“硬件级隔离”。每个计算实例（Compute Instance）拥有专属的计算核心、显存带宽和L2缓存分区，以及独立的显存块——它们不再共享任何关键资源。换句话说，切分后的小实例在软硬件视角上就是一块独立的“小GPU”，有自己的显存空间和算力配额，任务完全感知不到其他实例的存在，隔离性比时间片共享强得多。

MIG实例的算力配额取决于显存切分的比例。设GPU总计算能力为 \(P_{\text{total}}\)，某实例被分配的显存占比为 \(f_{\text{slice}}\)（例如将40GB显存从80GB中分出，\(f_{\text{slice}}=0.5\)），则该实例理论上获得的算力为：

MIG的最大价值是“确定性性能”：多租户场景下，互不信任的任务（比如两家公司的模型训练）可以安全地跑在同一块物理GPU上，彼此性能不受到干扰。但它也有代价——MIG的切分粒度是离散的（如1g.5gb、2g.10gb、7g.40gb等固定模板），不能随意微调；且一旦切分完毕，每个实例的资源就是钉死的，无法像时间片那样灵活弹性调度。这就像砌好的隔断墙不能随着客人多少随时拆改。

Slurm共享实现：学校的场馆预约系统

Slurm是超算和数据中心最常用的作业调度系统。它就像大学图书馆的场馆预约系统：用户先提交作业申请（申请单），说明要用几口锅（GPU数量）、多大储藏柜（显存）、什么时段（时间限制），然后由Slurm的调度器根据各“场馆”的空闲情况统一排班。

要让Slurm支持GPU共享，最关键的是配置GRES（Generic Resource）插件。管理员需要在slurm.conf中声明节点的GPU资源类型，并在提交作业时用--gres=gpu:2声明需要几块GPU。然而，传统的Slurm只以“整卡”为粒度分配GPU，一台GPU被分配给一个作业后就完全独占。要实现“一卡多作业”，需要借助额外的机制：一种是使用cgroup将GPU显存和计算资源做限额隔离，另一种是让多个作业通过设置CUDA_VISIBLE_DEVICES共享同一块物理卡（配合MIG使用）。

实际共享时，系统需要量化资源利用率。设某GPU在时间窗口 \(T_{\text{total}}\) 内实际有计算任务的时间为 \(T_{\text{busy}}\)，则该GPU的利用率：

Slurm的优势在于“成熟的排队与优先级策略”：它支持多队列（对应用户或项目）、优先级抢占、关联资源限制等高级特性，特别适合离线批处理场景——提交训练任务后排队等待分配。但Slurm对GPU共享的细粒度控制相对粗糙：如果不用MIG，它很难精确限制某个作业的显存上限；如果不用类似MPS（多进程服务）的插件，计算资源共享也基本靠“自觉”。

K8s共享实现：按需点餐的容器调度

如果说Slurm是“提前预约的场馆”，Kubernetes（K8s）就是“按需点餐的智能餐厅”：用户提交一个Pod（相当于点一份菜），K8s的调度器（kube-scheduler）在毫秒级内找到合适的“餐桌”（节点）把它安排下去。它天生面向容器化的微服务，特别适合在线推理和弹性训练场景。

K8s共享GPU的起点是DevicePlugin机制：NVIDIA提供的device-plugin守护进程定期向kubelet报告节点上的GPU资源数量，使之成为可调度的扩展资源nvidia.com/gpu。这样一来，Pod在YAML中声明resources.limits: nvidia.com/gpu: 1，调度器就会把Pod调度到有空闲GPU的节点上。但这个机制只解决“整卡分配”，不支持一块卡分给多个Pod。

要支持共享，社区衍生出两条路：一是时间片共享，通过修改device-plugin将一块卡虚拟成多个资源单位（例如1卡虚拟为10个nvidia.com/gpu单位），多个Pod轮流使用；二是显存隔离式共享（vGPU方案），类似给每个Pod分配独立的显存上限和算力配额。调度器在决定Pod放到哪块GPU上时，需要综合评分。设候选GPU的显存剩余率为 \(U_{\text{mem}}\)、与已调度Pod的亲和度评分为 \(A_{\text{share}}\)，则综合调度得分为：

K8s的GPU共享方案生态丰富：从开源的时间片虚拟化（如NVIDIA的time-slicing device plugin）到商业化的vGPU方案（如阿里云的cGPU、腾讯的vCUDA），都试图在“共享”和“隔离”之间找到平衡点。与Slurm相比，K8s更强于弹性伸缩：推理服务高峰时自动扩展Pod数量，低谷时自动缩容，GPU资源随业务潮汐动态调配。但牺牲的是排队与优先级管理的能力——K8s的调度器对“优先级队列”的支持不如Slurm成熟。

性能开销与隔离性：共享的代价

天下没有免费的午餐。GPU共享带来了高利用率，同时也不可避免地引入性能开销。我们可以把这些开销分成两类：计算干扰和显存争抢。

计算干扰主要来自缓存竞争。现代GPU的L2缓存是多个计算核心共享的，当一个任务频繁读写的数据恰好被另一个任务挤占出缓存时，性能就会显著下降。这就像两位厨师共用一个备料台，一个人堆满食材，另一个人找东西就要翻半天。显存争抢则是带宽层面的冲突：多个任务同时从显存搬运数据，总线带宽被瓜分殆尽。一个显存密集型任务遇到另一个同样密集的任务，两个任务的有效吞吐率可能都下降30%以上。

不同方案的隔离强度差异很大。时间片共享的隔离强度最弱——任务之间只隔着一道“屏风”；MIG的隔离强度最高——任务之间隔着实墙；而vGPU/显存限额方案居中。衡量共享效率时，可以这样建模：假设有 \(N\) 个任务并行共享，每个任务获得的等效算力为 \(P_{\text{eff}}\)，而GPU总算力为 \(P_{\text{total}}\)，共享带来的额外开销因子为 \(\alpha\)（由缓存污染、带宽争抢等引起），则系统总效率为：

理解这个公式，就理解了共享调度的本质：它是一个“多快好省”的博弈。共享可以让 \(N\) 个任务同时获得资源，提高硬件利用率，但 \(\alpha\) 的膨胀又会吞噬部分收益。调度的艺术，就是在 \(N\) 和 \(\alpha\) 之间找到平衡点——让足够多的任务共享，又不至于让干扰失控。实践中，通过监控GPU利用率、缓存命中率、内存带宽压力，可以量化 \(\alpha\)，并据此动态调整共享策略。

方案对比与选型：挑哪个“分餐方案”

后厨的分餐方式已经积累了三种主流方案：独占（整卡）、时间片共享、MIG切分，外加K8s生态下的vGPU显存方案。选型时，最先要回答的问题是：你更看重隔离性，还是更看重资源利用率？

独占方案的隔离性满分——任务完全不共享资源，性能可预测性最好，适合对性能敏感的SLA服务（如核心在线推理、模型压测），但利用率最低。时间片共享的利用率最高——不需要任何硬性分区，任务空闲的资源自动释放给其他任务使用，适合任务并发多但单个任务资源需求不高的场景（如大量小模型批量推理、数据处理管道），但性能波动大。MIG切分是折中——硬件隔离保障了性能确定性，切分粒度固定但灵活度不如时间片，适合多租户场景（如将一台A100分割给三个团队各自使用）。

成本与收益的权衡可以这样简化：一张A100的价格是固定的，独占意味着一个业务独享全部性能，但若它的实际利用率只有30%，那70%的投资就打了水漂。时间片共享可以让这张卡服务5个业务，但这5个业务各自能用的算力约为原来的20%——总产出是100%但被干扰打了折扣。MIG让3个业务各自拥有隔离的30%性能，总产出90%但稳定可控。

选型建议的黄金法则是“按任务画像匹配”：大模型训练任务（长时间、高资源消耗、对性能波动敏感）适合独占或大MIG实例；在线推理任务（短小、高频、并发多）适合时间片或小MIG实例批量部署；多团队共享一张卡时优先MIG保证公平；而K8s环境中的突发业务（高峰扩缩容）适合时间片共享的弹性机制。

工程实践与调优：管理“分餐”的实战手册

最后，让我们站在运维工程师的视角，看看GPU共享落地时需要的实战技能。

选型依据：首先要盘点业务的任务类型、显存/算力需求、QoS（服务质量）要求，然后决定共享方案。一个实用的决策树是：有强隔离需求（如不同客户的任务）→ MIG；无隔离需求但任务很多 → 时间片/vGPU；任务虽少但单个需求极大 → 独占。Slurm环境优先考虑GRES+MIG或cgroup方案，K8s环境优先考虑device-plugin扩展资源配合时间片/vGPU插件。

监控与诊断：共享后必须建立监控体系，核心指标包括：GPU计算利用率（nvidia-smi的utilization.gpu）、显存使用率、显存带宽利用率、GPU缓存命中率（可通过ncu或nvprof分析）、SM活跃度等。如果发现某个任务的性能与其他任务共享后显著下降，就要检查是否发生了L2缓存或带宽争抢，及时调整任务组合或改用隔离性更强的方案。

典型故障：共享场景最常见的故障是显存OOM——多个任务挤在一起显存超卖，需要配置好显存上限（如cgroup memory限额或MIG的显存边界）。其次是“算力饿死”：某些任务被优先级更高的任务持续抢占，导致前者的算力接近零——需要合理设置优先级和配额。还有一种隐蔽故障是版本兼容性：MIG模式要求NVIDIA驱动与容器运行时（如CUDA 11+）的特定版本支持，版本不匹配会导致实例创建失败。

最佳实践建议：

1. 混合调度：独占与共享并存，关键业务独占、弹性业务共享，避免全集群单一策略。

2. 精细化配额：每个共享任务都设置显存上限和算力上限，防止“一颗老鼠屎坏一锅汤”。

3. 动态调整：定期观察利用率报表，利用率长期低于50%的卡降低共享粒度，长期高于90%且延迟恶化则增加隔离。

4. 自动化运维：在K8s中结合HPA（水平自动扩缩）和GPU共享插件，让资源随流量潮汐自动伸缩。

AI 应用场景

Python 演示

class GpuTask:    def __init__(self, name, memory, compute):        self.name = name        self.memory = memory  # 显存需求 GB        self.compute = compute  # 算力需求 TFLOPS  class GpuScheduler:    def __init__(self, total_memory=80, total_compute=100):        self.total_memory = total_memory        self.total_compute = total_compute        self.tasks = []        self.mode = "mig"  # mig / timeslice / exclusive     def commit(self, task):        """提交任务，检查显存与算力是否可容纳"""        if task.memory > self.total_memory or task.compute > self.total_compute:            print("[拒绝] {} 超出GPU能力".format(task.name))            return False        free_mem = self.total_memory - sum(t.memory for t in self.tasks)        if free_mem >= task.memory:            self.tasks.append(task)            print("[分配] {} 占用 {:.0f}GB 显存".format(task.name, task.memory))            return True        print("[排队] {} 因显存不足等待".format(task.name))        return False     def utilization(self):        """返回 (显存利用率, 算力利用率)"""        mem_used = sum(t.memory for t in self.tasks)        comp_used = sum(t.compute for t in self.tasks)        return mem_used / self.total_memory, comp_used / self.total_compute     def timeslice_schedule(self, slice_time=0.5):        """模拟时间片轮转调度"""        print("--- 时间片调度 ---")        for i, task in enumerate(self.tasks):            print("[时间片] {} 获得 {:.1f} 单位时间".format(task.name, slice_time))     def mig_slice(self):        """按显存比例模拟MIG切分"""        print("--- MIG切分 ---")        total_req = sum(t.memory for t in self.tasks) or 1        for task in self.tasks:            ratio = task.memory / total_req            alloc = self.total_compute * ratio            print("[MIG] {} 获得 {:.1%} 算力 ({:.1f} TFLOPS)".format(                task.name, ratio, alloc))            if task.compute > alloc:                print("  [警告] {} 算力需求超出MIG配额".format(task.name))  if __name__ == "__main__":    scheduler = GpuScheduler(total_memory=80, total_compute=100)    tasks = [        GpuTask("大模型推理", memory=40, compute=50),        GpuTask("图像分类", memory=20, compute=25),        GpuTask("语音识别", memory=15, compute=20),    ]    for t in tasks:        scheduler.commit(t)     mem_u, comp_u = scheduler.utilization()    print("显存利用率: {:.0%}, 算力利用率: {:.0%}".format(mem_u, comp_u))    scheduler.timeslice_schedule()    scheduler.mig_slice()

1. class GpuTask定义任务的数据结构，包含任务名、显存需求和算力需求，类比后厨中一道菜需要的储藏格与灶眼火力。
2. class GpuScheduler调度器主类，管理总资源与已提交任务列表，类似排班主管记录每口锅的占用情况。
3. scheduler.commit(task)检查任务是否超出GPU容量，并统计显存是否足够，不够则排队等待。
4. free_mem = self.total_memory - sum(t.memory for t in self.tasks)计算剩余显存，即储藏柜还有多少空位可以放新食材。
5. return mem_used / self.total_memory, comp_used / self.total_compute分别返回显存和算力的利用率，对应监控面板上的两个核心指标。
6. def timeslice_schedule(self, slice_time=0.5)模拟时间片轮转，每个任务获得等长的GPU使用时段。
7. ratio = task.memory / total_req计算MIG切分时该任务应得的显存占比，进而推导其算力配额。
8. if task.compute > alloc检查任务的算力需求是否超出了MIG配额，若超出则给出警告，提示该任务不适合MIG的固定比例分配。

常见误区

面试题