为什么默认调度程序对于 AI 来说是错误的
Kubernetes 专为无状态、水平可扩展的 Web 服务而设计。其默认调度程序针对将各个 Pod 放置在有空间的节点上进行了优化，将每个 Pod 视为独立于其他 Pod，并在容量压力发生变化时适时驱逐。这种行为适合微服务。对于人工智能工作负载来说，这几乎是完全错误的。
AI 训练作业不是单个 pod，它是一组 pod，必须一起启动，必须共同运行以实现 GPU 间网络性能，必须共享紧密的拓扑以保持高带宽互连的利用，并且必须在安全抢占之前进行检查点。按照默认的 Kubernetes 策略进行调度，训练作业会部分启动，让一两个 Pod 等待容量、超时、从零重新启动，并在不产生任何结果的计算上烧钱。
推理工作负载有一个不同但相关的问题。对延迟敏感的服务流量被安排在竞争同一物理 GPU 的批处理作业旁边，而在凌晨 3 点触发的 p99 延迟页面通常是由调度程序引起的，而不是由模型引起的。当实际修复是在集群配置中时，团队花了一周的时间调试模型。
到 2026 年，在 Kubernetes 上大规模运行 AI 意味着用专门为工作负载设计的控件来替换或补充默认调度程序。安装内容和配置方式的具体细节是利用率为 40% 的集群与利用率为 75% 的集群之间的区别，这就是让工程师感到沮丧的配置不足与能够收回成本的平台之间的区别。
帮派调度：Kueue 和 Volcano
组调度（Gang Scheduling）——保证作业的所有 Pod 同时获得资源，或者没有资源——是训练工作负载最重要的功能。如果没有它，部分启动的作业会闲置其他工作负载可以使用的容量。有了它，训练容量就可以得到有效利用，队列行为也变得可预测。
两种开源解决方案已融合为 2026 年的生产默认方案：
- 库埃。 Kubernetes 原生，存在于 kubernetes-sigs 生态系统中，旨在作为准入控制层位于现有集群之上。提供队列、工作负载准入、团队之间的公平共享、资源风格和拓扑感知的放置策略。对于想要 Kubernetes 优先且无需运营开销的组织来说，这越来越成为默认选择。
- 火山。 CNCF 托管，专注于批量调度，对组调度、作业级策略和复杂工作负载拓扑提供强大支持。对于纯批处理工作负载，比 Kueue 更深入的功能集，操作起来稍重。当工作负载组合以推理要求有限的训练为主时适用。
拓扑感知的布局和网络
大模型训练受到 GPU 间通信的瓶颈。现代培训库采用高带宽互连的特定拓扑；默认的 Kubernetes 调度程序不知道两个 Pod 是否位于同一节点内直接连接的 GPU 上、机架内的同一交换机节点上，或者分布在超额订阅的网络结构中。
修复方法是具有显式提示的拓扑感知调度。 Kubernetes 拓扑管理器与 GPU 运算符的组合现在公开了拓扑标签，使调度程序可以共同定位紧密耦合的作业。在多节点训练中，Kueue 的拓扑感知放置策略与 GPU 操作员的设备插件报告相结合，已经变得足够可靠，可以作为生产基础设施。
对于大规模推理，多实例 GPU (MIG) 分区是一种未得到充分利用的控制，它允许单个高端数据中心 GPU 以可预测的延迟托管许多较小的推理工作负载 - 前提是调度程序具有 MIG 感知能力。 MIG 感知调度在操作上比标准 GPU 调度更复杂，但推理工作负载的成本经济性使得持续批量部署的运营投资值得。
推理调度有根本的不同
适用于训练的调度模式不适用于推理。这两个工作负载类别具有根本不同的要求，集群架构必须明确承认这些要求。
- 培训需要协同定位、组调度、对长队列时间的容忍、抢占时的检查点和恢复以及面向批次的吞吐量优化。
- Inference 希望根据请求并发性自动缩放、跨副本的水平分布、亚秒级 p99 预算的延迟保证、抗抢占性（这将导致用户可见的事件）以及流量突发时缩放至零的经济性。
2026 年生产推理模式
两种开源模式已经融合，成为 2026 年 Kubernetes 上人工智能推理的生产默认模式：
- Knative-on-KServe for HTTP inference workloads.在首次请求时提供从零缩放、从零缩放，以及由请求并发性、GPU 利用率或自定义指标触发的自动缩放。 HTTP 端点后面的同步推理的正确默认值。
- Ray Serve 用于更复杂的推理拓扑。多模型路由、模型组合、跨请求动态批处理、部署图编排。当推理架构非常重要时，这是正确的选择 - 每个请求管道化多个模型、A/B 路由逻辑、条件模型选择。
在一个集群上运行训练和推理
在初始分离实验产生双重操作开销后，大多数企业团队最终会在同一集群上运行训练和推理。当配置明确确认工作负载分割时，共享集群模式将在 2026 年发挥作用。
操作模式：Kueue处理训练入场和排队； KServe 或 Ray Serve 处理推理部署；两者都与 GPU 运算符共存，用于设备报告和拓扑标记；配置抢占策略，因此训练不能抢占推理，但低优先级训练可以抢占其他低优先级训练。结果是一个集群，其中推理延迟是可预测的，训练吞吐量很高，并且团队运行一个生产环境而不是两个。
配额、公平共享和 GPU 分配的政治
当基础设施团队开始在 Kubernetes 上调度 AI 工作负载时，最让他们感到惊讶的操作问题并不是技术性的。这是政治性的：谁获得 GPU、何时获得以及由谁在相互竞争的请求之间进行裁决。默认的先到先得的方式恰好产生了读者所期望的结果——一个团队抓住整个集群进行多天的训练，其他团队则等待，在冲刺计划中出现士气低落的争议，并最终升级为领导层进行仲裁。
Kueue 的 ClusterQueue 和 LocalQueue 原语让平台团队将集群划分为具有保证容量、可借用容量和优先级的命名队列，这些队列在代码中而不是在会议中解决仲裁。对于中型人工智能组织来说，一个有用的起始拓扑：
- 每个团队有一个保证队列，其大小可以覆盖团队第 50% 的负载。这是每支球队始终可以信赖的场地。
- 一个可借用池的大小可以吸收超出每队保证底线的突发容量。当其他团队没有使用时，团队可以使用超出其保证分配的资源，并在竞争发生时将其归还。
- 一个共享的低优先级实验队列，可以容忍抢占。休闲研究和探索性工作在这里进行；争用抢占可以在生产工作需要时释放容量。
- 保护生产的抢占策略：仅对低优先级队列启用抢占，因此临时实验不会杀死投入了数小时进度的生产训练运行。
可观察性是成功的一半
无法测量的调度程序无法调整。到 2026 年，任何 GPU 集群都会出现三类指标，平台团队每天检查一次，机器学习团队每周检查一次仪表板：
- 每个节点、每个队列、每个团队的 GPU 利用率。 “分配的 GPU”和“实际使用的 GPU”之间的区别就是金钱的隐藏之处。底层训练框架公开的模型 FLOP 利用率 (MFU) 是训练集群上信号最高的单一指标。
- 每个队列和每个优先级的队列等待时间。生产队列的等待时间激增是公平份额策略配置错误、底线配置不足或工作负载模式偏离原始规模假设的早期指标。
- 每个队列和每个作业的抢占计数。抢占超过 5% 作业的集群要么配置不足（增加容量），要么配置错误（重新审视抢占策略）。无论哪种方式，它都没有处于健康的运行状态。
- 作业完成时间分布。需要花费中位时间 5 到 10 倍时间的作业的尾部是操作异常所在的地方。 P99 完成时间告诉团队的不仅仅是平均值。
- GPU 内存利用率。成本归因图的另一半；计算利用率不足但内存饱和的作业与两者均利用率不足的作业具有不同的操作影响。
- 每个功能的成本归因。集群运营指标与 FinOps 成本故事之间的联系；每个工作都带有标签，让团队将成本归因于触发工作负载的产品功能。
行之有效的推出计划
对于已经有机发展但现在遇到日程安排障碍的团队来说，务实的 90 天序列在大多数情况下都能干净利落地完成升级。周期结束时的胜利通常是巨大的：利用率提高 15-25 个百分点，队列等待投诉急剧下降，而且最重要的是，集群不再成为依赖它的 ML 团队的瓶颈。
- 第 1-2 周。安装 GPU 运算符（如果尚未存在），获取流入可观察性堆栈的 DCGM 指标、基线当前利用率和等待时间数字以进行比较。
- 第 3-4 周。站起来 Kueue，将一个团队的工作负载迁移到具有显式容量分配的队列，将集群的其余部分保留为默认调度作为基准。单团队试点让平台团队在扩展之前了解运营模式。
- 第 5-8 周。将 Kueue 覆盖范围扩大到其余团队，引入优先级类别，仅对最低优先级队列启用抢占。将队列模型传达给团队，以便他们了解操作期望。
- 第 9-12 周。为多 GPU 训练添加拓扑感知的布局，设置有关每个队列的等待时间和利用率的可观察性仪表板，与 ML 团队一起回顾新模型如何影响他们的工作流程。
推出期间的常见故障模式
产生 GPU 调度部署的重复模式在仪表板上看起来很成功，但在实际中却让 ML 团队感到沮丧：
- 容量保证设置过高。如果每个团队的保证楼层总和超过集群的实际容量，则排队系统将无法兑现保证，并且输掉比赛的团队的结局会比原来的先到先得模式下的情况更糟。
- 未配置可借用容量。如果楼层以上没有可借用的容量，即使容量闲置，团队也无法爆发。利用率保持低位；平台团队因“新的排队系统有限制”而受到指责。
- 抢占启用过于激进。如果为标准优先级类别而不是仅为低优先级类别启用抢占，则生产训练运行会因临时实验而损失数小时的进度。信任损失很难挽回。
- 与机器学习团队没有沟通。排队模型是面向用户的改变； without explicit communication of how it works, ML teams interpret normal queue waits as the cluster being broken.
- 已跳过拓扑感知放置。队列基础设施已正确配置，但拓扑提示未公开，因此多 GPU 训练作业最终会在慢速网络结构上进行调度，并且运行速度比在更简单的拓扑上要慢。
- 可观测性发布晚了。团队在没有显示计划是否正常工作的仪表板的情况下配置计划。盲目调谐比测量调谐更困难。
为什么这种情况在基础设施领域会变得更加复杂
将 GPU 调度视为“平台管道”（一项持续的优化规则而不是一次性项目）的组织往往会在接下来的几个季度中实现复合收益。随着团队根据实际工作负载模式调整排队拓扑，第二年利用率又上升了 5-10 个百分点。由于拓扑提示捕获了原始放置次优的情况，因此每次训练运行的成本会下降。无需重新架构集群即可吸收新的工作负载模式。
将升级视为一次性项目的组织会在 12-18 个月内恢复到类似默认的模式。随着团队轮换，Kueue 配置受到的关注较少；停止检查拓扑提示；仪表板保持打开状态，但没有人阅读它们。集群利用率慢慢回落到 Kueue 之前的基线，并且每 GPU 小时的成本回升。
两种结果之间的结构性差异在于，团队是否将 GPU 调度视为需要运营所有权的资产，或者视为交付后成为其他人的问题的项目。资产框架可以产生持久的利用率收益。
常见问题
平台团队在确定 AI 工作负载的 GPU 调度升级范围时提出的常见问题：
- 我应该使用 Kueue 还是 Volcano？ Kueue 适用于 2026 年的大多数企业集群——它是 Kubernetes 原生的，操作更简单，并且功能集已经成熟，可以覆盖常见案例。如果工作负载组合以复杂的批量训练为主，并且团队可以吸收额外的操作复杂性，则火山爆发。
- 如何处理训练、推理和笔记本的混合工作负载？ Kueue 用于训练准入，KServe 或 Ray Serve 用于推理，以及用于笔记本容量的每用户 TTL 策略。三种工作负载类别具有不同的调度要求；将它们合并到一个队列中会对所有三个队列产生次优结果。
- 共享集群上训练与推理能力的正确比例是多少？取决于工作负载。生产型 AI 车间通常在稳定状态下运行 60-80% 的推理和 20-40% 的训练；研究密集的环境则相反。测量实际需求并进行调优；正确的答案是针对特定团队的经验答案。
- 这如何与多云策略相互作用？ Kubernetes 调度原语在很大程度上可以跨云提供商移植。 GPU 特定的配置（运营商版本、MIG 支持、拓扑报告）因云和区域而异；平台工程计划中跨云变化的预算。
- 什么时候 Kubernetes-on-GPU 不再是正确的答案？当部署足够小（单节点、单 GPU）时，Kubernetes 的运营开销超过了收益。低于该阈值，更简单的容器编排甚至直接 GPU 调度可能是合适的。在其之上，Kubernetes 加上 Kueue 是既定的默认设置。
