K8s GPU调度插件：容器算力编排

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

设备插件：烤箱管家的登记册

后厨里那台限量版烤箱，并不会自己开口说话。主厨老 K 要知道它今天在不在、能不能用、能烤多大尺寸的食材，全靠一位专门负责打理它的“烤箱管家”。在 K8s 集群里，这个管家就是设备插件（Device Plugin）。GPU 是一种异构硬件，CPU 和内存可以用“核数”“吉字节”这种通用单位上报，但 GPU 的规格五花八门——显存多大、算力多强、是否支持某些特性，调度器根本听不懂。设备插件就是硬件与调度器之间的“翻译官”。

设备插件以 DaemonSet 方式跑在每个 GPU 节点上，它做两件核心的事。第一件叫 ListAndWatch：它持续盯着这台机器上的 GPU 数量与健康状态，一旦有 GPU 掉线或恢复，就立刻通知 kubelet（节点上的“分店店长”）。第二件叫 Allocate：当调度器决定把一个 Pod 放到这个节点时，插件负责真正把 GPU 设备“交到”容器手里——告诉容器运行时该挂载哪个设备文件、注入哪些环境变量。NVIDIA 官方提供的 nvidia-device-plugin，就是这样一个成熟管家。

调度主流程：从点单到上菜的六步

把整个调度过程拆开看，就像后厨处理一道菜：客人点单 → 前台记录 → 排菜总管安排灶台 → 厨师拿到食材和灶台 → 开火。K8s 里的 GPU 调度主流程同样清晰。

第一步，设备插件启动后，通过 Unix 套接字向本节点的 kubelet 注册，说：“我是 GPU 管家，我这有 4 块卡。”第二步，kubelet 把这个信息上报给集群大脑 API Server，节点容量里就多了 nvidia.com/gpu: 4 这一项。第三步，用户创建 Pod 时，在资源请求里写明“我要 1 块 GPU”，这相当于客人在菜单上勾选了“需要烤箱”。第四步，调度器（kube-scheduler）遍历所有节点，找到 GPU 余量足够的那个。第五步，调度器把 Pod 绑定到节点，kubelet 收到指令后调用设备插件的 Allocate 接口。第六步，插件把 GPU 设备文件挂载进容器，容器启动，烤箱正式点火。

这个过程看起来简单，但每个环节都有讲究。比如调度器在判断“GPU 余量”时，依据的是节点上剩余的可分配数量，而非物理总量——因为有些卡可能已被其他 Pod 占用。在 Kubernetes 中，GPU 是扩展资源（Extended Resource），它有一条铁一样的规矩：只能声明整数数量。你无法申请 0.5 张 GPU。

整卡分配：一人一炉的奢侈与浪费

老 K 后厨有 4 台烤箱，如果每道菜都需要完整一台，那当然谁来了给谁一台，互不干扰。这就是整卡分配——K8s 默认的 GPU 调度方式。整卡分配的优点非常直观：隔离性好，一个任务不会影响另一个；调度逻辑简单，调度器只需要做减法。但它的缺点同样致命：显存浪费。

假设一台 A100 GPU 有 80GB 显存，你的推理模型只需要 12GB 显存。在整卡模式下，这个 Pod 也必须独占一整张 A100，剩下的 68GB 全部闲置。对于动辄数万美元一块的 GPU，这是巨大的浪费。这在后厨里就像：为了热一碗汤，把整个烤箱都占用了，其他所有菜都得等着。

正是在这种浪费的驱动下，社区开始探索“把一个烤箱当多个用”的办法——也就是共享调度。整卡分配是基线，共享机制是优化。理解这一点很重要：K8s 本身不会自动知道 GPU 可以共享，它需要额外的插件和配置才能实现。

共享调度：把烤箱切成格子、排成档期

共享调度的思路，就像老 K 对烤箱的两种改造方案。方案一：排档期（时间分片）。 三份菜轮流用同一台烤箱，你烤 20 分钟，我烤 20 分钟，他再烤 20 分钟。在 GPU 领域，这就是 Time-slicing 时间分片：多个 Pod 共享一张 GPU，按时间片轮转执行。它的实现成本低，几乎不用改硬件，NVIDIA 官方插件通过环境变量就能开启。但缺点明显：如果几个 Pod 同时有计算需求，它们要排队，单个任务的完成时间会变长。

方案二：切格子（MIG）。 像把一个大烤箱内部砌上隔板，变成 4 个小烤箱，每个小烤箱有独立的温控和空间，互不干扰。这就是 Multi-Instance GPU（MIG）：在 A100、H100 等新架构 GPU 上，硬件层面把 GPU 切分成多个独立实例，每个实例拥有独占的计算核心和显存带宽。MIG 的隔离性远好于时间分片，但实例大小是固定的（如 1g.5gb、2g.10gb 等规格），灵活性略差。

还有方案三：MPS（Multi-Process Service），它更像是“烤箱里站了多个厨师，大家共用火源但各做各的菜”。MPS 允许多个进程并发使用 GPU 的计算单元，能显著提高利用率，但显存依然是共享的——一个进程吃光显存，其他进程就会报错。三种方案没有绝对优劣，取决于场景：追求极致隔离选 MIG，追求简单共享选时间分片，追求计算并发但不在乎显存风险选 MPS。

显存隔离：一块显卡的“公寓”怎么管

共享 GPU 带来的最大隐患，是显存安全。后厨里，如果两道菜同时放进一台烤箱，彼此的油汁和酱料可能会串味，甚至一个烤糊了把烤箱弄脏，另一道菜也遭殃。在 GPU 世界里，一个 Pod 如果发生显存溢出（OOM），可能导致整张卡的健康状态异常，其他共享这张卡的 Pod 跟着遭殃——这就是“一卡崩、全卡崩”。

因此，显存隔离是混部的生命线。MIG 提供了硬件级的显存隔离：每个实例的显存是物理隔离的，一个实例 OOM 不会影响其他实例。这是它最核心的价值。相比之下，MPS 不隔离显存——所有 MPS 客户端共享同一块显存池，没有任何边界保护。时间分片更不用说，它连计算都是轮流用，显存完全共享。

在工程实践上，选择哪条路取决于你的 GPU 型号和风险偏好。如果你跑的是对外提供服务的在线推理，业务不可中断，那就必须用 MIG 这类硬隔离方案；如果你跑的是离线批处理任务，容忍偶尔重试，时间分片也够用。总之，混部之前，先问显存安全不安全。

抢占机制：VIP 客人来了怎么办

老 K 的后厨有个规矩：如果一位 VIP 客人突然到店，点了一份必须立刻烤的招牌菜，而后厨烤箱全满，那就只好把正在烤的、没那么紧急的菜先撤下来，让给 VIP。这就是抢占式调度在 GPU 场景中的写照。

K8s 中的 Pod 可以设置 priorityClassName，即优先级。当高优先级 Pod 因资源不足而无法调度时，它会触发抢占：调度器先尝试找到某个节点，驱逐（Evict）一些低优先级的 Pod，把 GPU 资源腾出来给高优先级的 Pod。被驱逐的 Pod 会进入终止流程，如果是可重试的批处理任务，它们会在其他节点重新排队。

为什么说“抢占需谨慎”？因为驱逐不是免费的。被驱逐的 Pod 如果正在做模型训练，它的进度可能丢失、需要从头再来；如果是推理服务，则可能直接导致线上请求失败。所以，合理的做法是：只有真正的紧急任务（比如线上故障修复、高优训练任务）才设置高优先级，日常任务一律平级。抢占如同一把双刃剑：用好了保业务，用滥了毁生态。

拓扑亲和性：多卡协作要住得近

当 AI 模型大到一张 GPU 装不下，就需要把模型切到多张 GPU 上并行训练，这就产生了多卡通信。后厨里，两位厨师要配合做一道菜，如果他们在同一个灶台间，喊一声就能沟通；如果相隔两层楼，就得靠对讲机，效率大打折扣。GPU 之间也一样：同一节点内的显卡通过 PCIe 或 NVLink 直连，带宽每秒可达 600GB；跨节点的 GPU 通信则要经过网络，带宽往往只有几十 GB，差了不止一个数量级。

拓扑亲和性（Topology Affinity） 要解决的就是这个问题：调度器为多卡任务分配 GPU 时，尽量把它们放在同一节点上（Node Affinity），甚至同一节点的相邻插槽上，以减少跨节点通信。这在 K8s 里通过 nodeSelector、nodeAffinity 以及自定义调度插件来实现。

我们用一个效率公式来看通信对训练的影响：假设模型并行度是 k，每次迭代需要 k 次通信，通信量占总时间的比例是 c，那么多卡加速的实际效率并不是 k 倍，而是小于 k 倍。只有当通信开销足够低（c 小），加速比才接近理想值。因此，让多卡住得近，就是让训练跑得快。

混部实践：白天推理，夜间训练

最后我们把所有零件组装起来，看看真实世界里的“算力混部”长什么样。所谓混部（Co-location），指把不同类型的工作负载放在同一批 GPU 上运行，让每一块 GPU 都物尽其用。最常见的组合是“在线推理 + 离线训练”：白天流量高峰，GPU 优先服务推理请求；深夜流量低，训练任务大规模占用算力。

为了实现混部，工程团队通常组合使用时间分片与 MIG。比如一台 8 卡 A100 服务器，白天用 MIG 把其中 4 卡切成 16 个推理实例，支撑在线服务；另外 4 卡用时间分片跑小规模的增量训练。到了夜间，MIG 实例缩容，所有 GPU 切换给大模型训练。这套机制背后依赖的是 K8s 的弹性调度能力：通过自定义调度器或 Device Plugin 的扩展，实现“按需分配、动态伸缩”。

混部的收益非常可观：GPU 平均利用率从 30% 提升到 85%，成本几乎下降一半。但挑战也很大——显存隔离、优先级抢占、拓扑亲和性，每一步都需要精细配置。正如老 K 说的：“烤箱还是那台烤箱，但会排班的主厨，能同时服务三倍客人。”这就是 K8s GPU 调度插件的终极价值：让容器算力编排，从“一台一客”进化为“满座翻台”。

AI 应用场景

Python 演示

class GpuDevice:    """模拟一张 GPU 卡."""    def __init__(self, gid, memory_gb):        self.gid = gid        self.memory_gb = memory_gb        self.busy = False     def allocate(self, pod):        if self.busy:            raise RuntimeError("GPU {} is busy".format(self.gid))        self.busy = True        self.pod_name = pod.name        return True     def free(self):        self.busy = False  class DevicePlugin:    """模拟设备插件：登记 GPU 并暴露给调度器."""    def __init__(self, node_name, gpus):        self.node_name = node_name        self.gpus = gpus        self.resource_name = "nvidia.com/gpu"     def list_and_watch(self):        """上报可用 GPU 数量."""        return sum(1 for g in self.gpus if not g.busy)     def allocate(self, pod):        for g in self.gpus:            if not g.busy:                g.allocate(pod)                return g.gid        return None  class Pod:    """模拟一个请求 GPU 的工作负载."""    def __init__(self, name, gpu_request, priority):        self.name = name        self.gpu_request = gpu_request        self.priority = priority  class Scheduler:    """模拟 kube-scheduler 的 GPU 调度逻辑."""    def __init__(self, plugins):        self.plugins = plugins     def schedule(self, pod):        best_node = None        best_free = -1        for plugin in self.plugins:            free_count = plugin.list_and_watch()            if free_count >= pod.gpu_request and free_count > best_free:                best_free = free_count                best_node = plugin        if best_node:            gpu_id = best_node.allocate(pod)            print("Pod {} 调度到 {} 的 GPU {}".format(                pod.name, best_node.node_name, gpu_id))            return True        print("Pod {} 等待：所有节点 GPU 不足".format(pod.name))        return False  def main():    plugin_a = DevicePlugin("node-a", [GpuDevice(0, 40), GpuDevice(1, 40)])    plugin_b = DevicePlugin("node-b", [GpuDevice(0, 80)])    scheduler = Scheduler([plugin_a, plugin_b])     pods = [        Pod("训练任务-1", 1, 100),        Pod("训练任务-2", 1, 100),        Pod("推理服务-高优", 1, 999),        Pod("离线任务-低优", 1, 10),    ]    for p in pods:        scheduler.schedule(p)  if __name__ == "__main__":    main()

1. class DevicePlugin对应真实世界中的 NVIDIA Device Plugin，负责登记 GPU 容量和分配设备。
2. list_and_watch()模拟 ListAndWatch 接口，返回当前可用 GPU 数量，供调度器决策。
3. allocate(pod)模拟 Allocate 接口，找到一块空闲 GPU 并标记为 busy。
4. class Scheduler模拟 kube-scheduler 的资源匹配逻辑。
5. if free_count >= pod.gpu_request and free_count > best_free调度核心：节点空闲 GPU 必须不少于请求量，且优先选空闲最多的节点（简单负载均衡）。
6. Pod("推理服务-高优", 1, 999)高优先级推理服务优先调度，体现抢占式调度的优先级语义。

常见误区

面试题