Kubernetes 2026：AI 工作负载正在改变调度器的设计方向

Kubernetes 2026AI 工作负载正在改变调度器的设计方向一、默认调度器对 AI 工作负载的失配从filter/score到拓扑感知Kubernetes 默认调度器的核心假设是工作负载之间没有硬件拓扑依赖。一个 Pod 调度到哪个节点主要看 CPU 和内存的剩余量加上亲和性/反亲和性的软约束。这个模型对 Web 服务、微服务这类无状态负载够用对 AI 训练和推理工作负载就是灾难。AI 工作负载有三个 Kubernetes 原生调度器无法理解的特性。第一GPU 拓扑亲和性——分布式训练要求参与训练的 GPU 共享同一个 NVSwitch 或 NVLink 域跨节点甚至跨 NUMA 的 GPU 通信会导致训练吞吐下降 30%~60%。第二显存作为一等资源——Kubernetes 的 resource request 只关注这块 GPU 有没有被占用不关心占了多少显存、还剩多少、碎片率如何。第三工作负载的排队语义——AI 任务通常以队列方式提交Job/JobSet而非长期运行的服务调度器需要理解这个队列里前面还有多少任务、它们的资源需求是什么做全局的负载均衡。二、GPU 拓扑感知调度NVLink 域的发现与绑定GPU 拓扑感知的核心是让调度器理解节点的物理 GPU 拓扑图并以此约束 Pod 的放置决策。这张拓扑图对应一个 8 卡 H200 节点。如果启动一个 4 卡分布式训练任务最优调度是选择 GPU 0-3共享 NVSwitch 0在同一个 NUMA 0 域内而不是 GPU 2-5跨 NVSwitch会引入跨域通信延迟。实现上有几个技术路径在演进NRI (Node Resource Interface)Kubernetes 1.31 引入的节点资源接口允许调度器插件通过标准 API 获取节点的硬件拓扑信息包括 GPU、NUMA、PCIe 互联关系。相比之前的 Device Plugin 方案NRI 提供了更丰富的拓扑元数据。拓扑约束标注节点通过 Node Feature Discovery 暴露 GPU 拓扑标签如nvidia.com/gpu.nvswitch.count调度器在 filter 阶段按标签筛选候选节点在 score 阶段按拓扑亲和度打分。Gang Scheduling 协议分布式训练要求要么所有 Worker 同时运行要么一个都不启动all-or-nothing。Volcano 的 Gang Scheduling 提供了这种语义避免部分 Worker 启动后等待资源导致的资源僵持。三、从静态配额到弹性 GPUMIG 与 vGPU 的调度实践NVIDIA MIG (Multi-Instance GPU) 将一张物理 GPU 切分为多个独立实例每个实例有专属的显存、缓存和计算单元。这解决了AI 推理不需要整张 H200但独占模式又浪费的矛盾。在实践中MIG 调度需要处理几个细节切分配置的动态管理MIG 配置一旦设定修改需要重启 GPU。生产环境的策略通常是预定义几种切分模板如1g.10gb、2g.20gb、7g.80gb根据工作负载类型分配而不是频繁动态切换。碎片化问题当一个 GPU 被切分成 7 个1g.10gb实例后如果要调度一个需要7g.80gb的训练任务调度器需要判断是否反向合并——销毁所有小实例重新配置为完整 GPU。这里的决策逻辑需要结合任务优先级和等待队列。指标暴露Kubernetes 的 Device Plugin 需要暴露每个 MIG 实例的显存使用率、SM 利用率和温度到 Prometheus让 HPA/VPA 能基于这些指标做自动伸缩。// MIG 实例的调度决策是否应该触发反向合并 func shouldDefragMIG(device map[string]*MIGStatus, pendingJob *AITrainingJob) (bool, string) { fragmentedGPU : totalFreeMem : 0 for gpuID, migs : range device { for _, mig : range migs { if mig.Status idle isFragment(mig.Profile) { fragmentedGPU gpuID totalFreeMem mig.MemoryMB } } } // 碎片化的小实例累加能凑出大任务所需的显存且任务优先级足够高 if totalFreeMem pendingJob.MemoryMB pendingJob.Priority PriorityHigh { return true, fragmentedGPU } return false, } func isFragment(profile string) bool { // 1g.10gb 或 2g.20gb 等小切分视为碎片 return strings.HasPrefix(profile, 1g.) || strings.HasPrefix(profile, 2g.) }这段逻辑的关键在于Priority阈值。生产环境通常会设一个严格的值——仅当任务是 P0 级别的紧急训练任务时才允许触发反向合并因为合并操作会中断所有运行中的小实例推理服务。四、边界分析修改调度器不是银弹GPU 拓扑感知调度虽然正确但有两个现实约束需要正视。调度延迟的增加拓扑感知调度需要额外的约束匹配计算。在一个 200 个节点的集群中从简单的 CPU/内存匹配到 GPU 拓扑图匹配调度延迟可能从毫秒级增加到百毫秒级。对于批量提交的训练任务可以接受对于需要秒级扩容的推理服务就存在风险。供应商锁定风险NCCL 拓扑文件和 MIG 配置都是 NVIDIA 私有生态的一部分。如果未来切换到 AMD ROCm 或 Intel Gaudi整个拓扑感知层的代码需要重写。建议的做法是抽象一个TopologyProvider接口让不同 GPU 供应商的实现解耦——虽然这会增加初期工程工作量但基础设施工程师应该习惯这种为解耦多写代码的做法。适用边界GPU 拓扑感知调度适用于分布式训练2 卡以上和高显存带宽要求的推理场景如大尺寸扩散模型。对于单卡推理、CPU 推理和轻量训练任务默认调度器已经足够拓扑感知反而增加了不必要的复杂度。不适用场景不要试图用调度器解决所有 AI 工作负载的放置问题。对于需要全互联all-to-all通信的千卡级别大模型训练调度器能提供的优化有限——真正的瓶颈在网络结构Spine-Leaf vs. Dragonfly和集合通信算法Ring vs. Tree AllReduce这不是调度器层面能处理的问题。五、总结Kubernetes 调度器正在经历自诞生以来最深刻的一次架构调整——从面向无状态微服务的通用调度进化为理解 GPU 拓扑、显存管理和排队语义的 AI 工作负载调度器。三个具体趋势值得关注。第一NRI 生态的成熟会让调度器插件从猜测硬件拓扑变为查询硬件拓扑精度和效率都有数量级提升。第二MIG 和 vGPU 的混合管理将成为推理集群的标配调度器需要同时理解物理 GPU 拓扑和逻辑切分状态。第三Gang Scheduling 将从分布式训练的刚需逐步延伸到多模型推理管线的编排。对于云原生工程师现在就该在测试环境跑起 Volcano GPU Operator NFD 的组合建立 GPU 拓扑感知调度的实验环境。基础设施不需要漂亮话但需要早做准备。资料说明本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论不应视为行业事实。可参考 0730 资料来源索引并在发布前将具体来源贴到对应断言之后。