2026年1月28日
作者:Ekin Karabulut, Hagay Sharon, Omri Cohen and Julie Adrounie
某机构 Run:ai v2.24 引入了基于时间的公平共享,这是一种新的调度模式,为 Kubernetes 集群中的超配额资源带来了具有时间感知能力的公平共享调度。该能力构建于为某机构 Run:ai 提供动力的开源 KAI 调度器之上,解决了共享 GPU 基础设施中一个长期存在的挑战。
考虑两个优先级相同的团队共享一个集群。团队 A 持续提交较小的作业,而团队 B 需要运行一个需要更多资源的大型作业。每当资源释放时,团队 A 的小作业立即适配并被调度。团队 B 的大型作业则继续等待足够的资源变得可用。在此之前,团队 A 的下一个小作业就会占用释放的容量。结果是:尽管两个团队具有相同的优先级和配额,团队 A 一个接一个地运行作业,而团队 B 的作业却在队列中无限期等待。
基于时间的公平共享通过赋予调度器“记忆”来解决这个问题。调度器不再只计算单个时刻的公平份额,而是跟踪历史资源使用情况,并根据过去的消耗调整每个队列的份额。最近使用更多资源的团队在超配额分配中获得较低的分数,而一直等待的团队则会获得提升。
基于时间的公平共享使得在数天和数周内实现成比例的计算时间成为可能。这实现了 GPU 资源的真正时间共享,为偶尔出现的大型作业提供突发访问,并使资源规划与每周或每月的 GPU 小时预算保持一致。重要的是,保障配额和队列优先级继续像以前一样工作。
企业部署显示出一个一致的模式:当组织从静态 GPU 分配转向动态调度时,集群使用变得动态得多。超配额资源(保障配额之外的共享池)成为最常用的资源类型之一。团队经常超出其保障分配,从而提高 GPU 利用率并为研究人员提供更多计算时间。
这使得超配额公平性变得至关重要。当集群价值的很大一部分来自这个共享池时,该池需要随着时间的推移公平分配。
经典的无状态公平共享算法分两个阶段分配集群资源。首先,它分配应得配额,即每个队列有权获得的保障资源。这种分配始终首先发生,不受历史使用情况的影响。基于时间的公平共享不会改变此行为。
在满足应得配额后,任何剩余容量成为超配额池,这是一个共享的盈余,队列根据其权重竞争该池。这正是瞬时公平性失效的地方。
在分配超配额资源时,调度器:
fairShare = remainingCapacity × (weight / totalWeights)问题就在这里。考虑以下两种竞争超配额资源的队列类型。
当队列具有相同权重时:两者都获得相同的计算公平份额。当一个作业完成后资源变得可用时,两个队列处于完全相同的状态——相同的分配(零),相同的公平份额,都有待处理作业。调度器看不出它们之间的区别,回退到平局决胜机制(队列创建时间戳,然后按字母顺序),同一个队列每次都获胜。
当队列具有不同权重时:权重较高的队列获得较大的公平份额,这是正确的。但瞬时计算并不跟踪队列是否随着时间的推移实际获得其比例份额。例如,如果队列 A 的权重为 3,队列 B 的权重为 1,调度器正确地计算出 A 有权获得 75% 的超配额资源(3/4),B 有权获得 25%(1/4)。但是,如果队列 A 提交大型工作负载,而队列 B 提交许多小型工作负载,则队列 B 更容易适应其公平份额,而队列 A 的大型作业会将其推至超出公平份额。调度器继续偏好队列 B,因为在每个决策点它看起来都“分配不足”。随着时间的推移,队列 B 最终运行的工作负载远远超过其 25% 的配额。
在这两种情况下,调度器都没有记忆。它不知道一个团队刚刚完成了一个作业,而另一个团队已经等待了几个小时。
基于时间的公平共享的核心思想很简单:对于每个队列,将其在配置的时间窗口内实际消耗的超配额资源比例与基于其权重本应收到的比例进行比较。然后相应地进行调整。
例如,如果队列 A 的权重为 3,队列 B 的权重为 1,则队列 A 应获得 75% 的超配额资源,队列 B 应获得 25%。如果调度器回顾过去一周,发现队列 A 实际消耗了 90%,而队列 B 只获得了 10%,它将提升队列 B 的有效权重并降低队列 A 的有效权重,使未来的分配趋向于 75/25 的分配比例。
其他一切保持不变。应得配额仍然首先得到保障。优先级排序仍然适用。队列层次结构像以前一样工作。基于时间的公平共享只改变超配额池的分配方式。
调度器使用三个输入来调整每个队列的有效权重:
当一个队列消耗超过其公平份额时,其有效权重会降低。当它被资源匮乏时,其有效权重会提升。这样,分配会随着时间的推移自然回归到预期的比例。
基于时间的公平共享可以直接从 UI 启用或禁用(参见某机构 Run:ai 文档的节点池部分),而窗口大小、窗口类型和衰减率等参数可以通过 API 进行调整,以平衡响应性和稳定性。由于这些设置是每个节点池配置的,管理员可以在专用节点池上进行实验,而不会影响集群的其余部分。
值得注意的几个细节:
本节通过一个真实场景展示基于时间的公平共享如何解决异构集群中的资源争用问题。
一个 100-GPU 的集群由两个具有非常不同工作负载模式的机器学习团队共享。LLM 团队专注于后训练和推理,拥有 30 个保障 GPU。视觉团队专注于计算机视觉研发,拥有 20 个保障 GPU。两个团队具有相同的超配额权重。超配额池中剩余的 50 个 GPU 可用于突发工作负载。
LLM 团队运行面向客户的推理端点,服务于生产流量。这些推理工作负载持续使用 10 个 GPU。它们至关重要,绝不能中断。其配额中剩余的 20 个 GPU,加上超配额池的访问权限,可在团队偶尔需要根据客户反馈改进模型时用于后训练作业。
视觉团队专注于计算机视觉研究:运行 VSCode、测试架构、超参数搜索和训练目标检测模型。他们有一系列持续的训练作业,经常使用超配额池。
问题:突发访问受阻
某天,LLM 团队完成了一批客户反馈的分析,准备启动后训练运行。该作业需要 60 个 GPU;他们自己的 20 个 GPU 配额加上超配额池中的 40 个 GPU。下面概述了启用和不启用基于时间的公平共享时会发生什么。
没有基于时间的公平共享
LLM 团队的推理服务没问题,保障配额运行完美。但是,他们的后训练作业实际上被资源匮乏了,因为一个具有持续工作负载的团队垄断了超配额池。偶尔使用的用户永远得不到机会。
图 1. 没有基于时间的公平共享,LLM 突发作业保持待处理状态,而视觉团队继续使用超配额资源
启用基于时间的公平共享
启用基于时间的公平共享后,调度器会跟踪历史使用情况。当 LLM 团队提交其后训练作业时:
如果后训练作业运行时间足够长,两个团队最终会时间共享超配额资源。LLM 团队运行一段时间,积累使用量。随着其历史使用量的增长,视觉团队变得相对更匮乏并开始获得优先权。资源在两者之间来回振荡(有时 LLM 作业运行,有时视觉作业运行),导致随着时间的推移实现公平共享,而不是一个团队垄断资源池。
图 2. 启用基于时间的公平共享后,LLM 突发作业被调度,资源在团队之间公平振荡
基于时间的公平共享支持几种重要模式,包括:
基于时间的公平共享解决了瞬时公平共享调度中的一个基本限制:缺乏记忆。通过跟踪历史使用情况,调度器在时间窗口内公平分配超配额资源,而不仅仅是在每个调度决策时刻。保障配额保持不变——像推理端点这样的关键工作负载仍然受到保护。
准备好开始了吗?某机构 Run:ai v2.24 包含基于时间的公平共享,可通过平台 UI 进行简单配置。设置是按节点池配置的,因此很容易在专用池上进行实验,而无需在整个集群中强制执行新模式。
基于时间的公平共享也可在开源 KAI 调度器中使用。完成配置步骤,启用 Prometheus,设置参数,然后开始调度。
想先试用一下基于时间的公平共享吗?查看基于时间的公平共享模拟器,您可以在其中模拟随时间变化的队列分配。在简单的 YAML 文件中定义您的队列、权重和工作负载,运行模拟,并可视化资源如何在竞争团队之间振荡。FINISHED
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。