阿里大型生产级 AI 集群

引言

需求高本身并不意味着有效利用率高。ASI 集群代表着巨额资金投入，即便 利用率只变化 1%，也会产生显著的运营影响。然而，空闲 GPU 仍可能无法使用，原因包括：空闲资源分散在不合适的节点上、没有匹配的 CPU 容量、不满足网络局部性要求，或者被留作应对生产需求随时间波动的余量。因此，资源管理的主要问题并不只是填满空闲 GPU，而是在拓扑、优先级和干扰约束下 ，把异构工作负载需求与异构硬件相匹配。本文从测量走向实践：先分析资源为何变得不可用（碎片化），再介绍已经部署、能够回收部分损失容量的机制，最后指出仍需新系统支持的开放问题。

诊断 GPU 碎片。 我们首先说明，GPU 碎片是 ASI 中空闲 GPU 无法被分配的主要原因 。碎片来自多个方面：分数 GPU 分配、多 GPU 节点中遗留的零散 GPU、GPU 节点上 CPU 容量不足，以及网络拓扑约束。尽管先前工作讨论过前三种来源，我们的追踪数据表明，由于 GPU 共享极少使用 ，分数 GPU 碎片在 ASI 中已只是次要因素。真正占主导的是零散 GPU、CPU 瓶颈和拓扑约束。拓扑影响对于大型 GenAI 训练和服务作业尤其重要，因为这些作业依赖并行策略，需要跨多个 GPU 节点进行高带宽部署。

为缓解碎片，我们开发了 IPC（迭代式分区整合，iterative partitioned consolidation），一种适用于超大规模 GPU 集群的实用去碎片算法。IPC 通过快速分区搜索和逐出链调度生成迁移决策，同时满足亲和性规则和锁定任务约束。我们还提出一个基于熵的拓扑感知分配指标，在条件允许时优先把任务集中到更少的接入交换机之下。在追踪回放实验中，IPC 能在数分钟内作出迁移决策，并把存在零散资源的节点数减少 20.2%。

IPC具体包含三个关键思路：

  • 分区搜索：155,410 块 GPU 的全集群太大，直接寻找全局最优迁移方案计算成本很高。IPC 把节点随机划分成多个小分区，并行寻找每个分区内的整理方案，因此能在几分钟内作出决策。
  • 逐出链调度：迁移一个任务时，目标节点可能没有足够空间。IPC 会先迁走目标节点上的另一个任务；如果那个任务的目标节点也没有空间，就继续递归迁移，形成一条“逐出链”。类似于：
Job-1：节点 A → 节点 B
Job-3：节点 B → 节点 C
Job-7：节点 C → 节点 D

通过一连串迁移，最终腾空节点 A。

  • 遵守生产约束。IPC 不能随意移动所有任务：
    • 标记为锁定的关键任务不能迁移；
    • 必须满足亲和性、反亲和性规则；
    • CPU 和 GPU 资源都要满足；
    • 采用“先在新节点启动，再关闭旧实例”的方式，尽量避免服务中断。

这里还提到了一个拓扑感知分配指标。它与 IPC 是两个配套但不同的机制：

  • IPC 负责把已经碎片化的资源重新整理；
  • 拓扑感知分配负责在放置新作业时，尽量把 GPU 集中在少数几个接入交换机（ASW）下面，避免从一开始就把作业分散得太开。

论文使用“熵”衡量分散程度：

  • GPU 集中在一个 ASW 下：熵低，优先选择；
  • GPU 平均散布在多个 ASW 下：熵高，尽量避免。

缓解资源利用不足。 接下来我们说明，生产环境中的资源预留构成第二类容量损失。用户为应对流量昼夜波动、故障切换冗余和大型活动峰值而预留容量，导致大量 GPU 在非高峰时段闲置。追踪数据显示，午夜前后的空闲备用容量峰值可达 10,000 GPU 小时。普通的尽力装箱无法解决这一问题：生产作业必须拥有有保障的可用性，而灵活作业只能在不危及高优先级工作负载时使用这些空闲容量。

ASI 通过两类优先级以及已经部署的抢占式调度框架 SpotGPU 来处理这一矛盾。高优先级（HP）作业获得资源保障，并可以从低优先级（LP）竞价作业手中收回资源；后者以折扣价格使用弹性容量。与以往的工作负载分析不同，我们的追踪数据包含作业优先级元数据，因此可以直接研究这项策略。 SpotGPU 结合两种机制：其一是“备用”（Standby），HP 用户借此明确释放暂时闲置的资源；其二是感知抢占成本的调度器，它在放置 LP 作业时，尽量减少 HP 作业收回容量所造成的无效计算。二者共同在保持 HP 资源可用性的前提下收割空闲资源。

理解仍然存在的异构性挑战。 即便部署了应对碎片化和利用不足的机制，仍有若干问题尚未解决， 因为它们源于硬件、网络拓扑和工作负载行为中更深层的异构性。

  • 第一：ASI 采用多个厂商的 GPU 以降低供应链风险，但用户最初对 XPU-A 的采用速度明显慢于 NVIDIA GPU。尽管 XPU-A 的理论规格优于 NVIDIA H20，其开箱即用的 GenAI 性能却只有H20 的80%，原因是关键内核尚未匹配硬件执行特征。我们对 XPU-A 的初步 LLM 服务优化把性能最高提升了43%，并使 XPU-A 的 HP 需求增加到原来的 2.5 倍；但如何在异构加速器上支持多样化模型架构，仍是开放问题。
  • 第二：硬件异构性与网络局部性之间存在冲突。系统可以利用异构 GPU，把不同工作阶段匹配到不同硬件能力。然而在 ASI 中，异构 GPU 往往位于不同接入交换机（ASW）之下。 我们的基准测试显示，与跨 ASW 部署相比，同一 ASW 下的部署可将 allreduce 带宽提高 27%。对于预填充-解码（PD）分离这类通信敏感工作负载，调度器必须在硬件专门化收益与通信实例相距更远的代价之间作出权衡。
  • 第三：在线推理为共置留下了很大空间，但现有隔离机制还无法轻松利用这一机会。在线推理的 GPU SM 利用率中位数只有 6%。GenAI 服务经常耗尽 GPU 内存，却留下大量闲置计算资源；经典 DNN 服务则往往同时低估内存和计算资源。把这些工作负载共置本可提升效率，但静态分区和时间共享等现有 GPU 共享技术要么切分过于僵化，要么无法提供在线服务所需的延迟隔离。同样，ASI 会把纯 CPU 作业与 GPU 作业共置以利用空闲 CPU 周期，但这可能让 GPU 训练工作负载的P90 SM 利用率下降 18%。

我们认为，ASI 的观察并不只适用于这一部署，因为它们揭示了大规模 AI 基础设施同时包含异构工 作负载、加速器、优先级与拓扑时必然出现的资源管理问题。我们公开了脱敏后的 ASI 追踪数据，并分享生产实践中的机制与开放挑战，希望能够推动更高效的 GPU 集群管理研究。

背景

ASI 集群。 ASI 是一个共享、多租户 GPU 集群，为数十个内部部门提供基础设施服务；这些部门的 业务覆盖电商、广告、本地生活、物流、金融科技和内容平台。各部门从 ASI 租用计算资源，用于开发和部署机器学习服务，而无需自行运营独立 GPU 集群。为保证资源分配公平，ASI 采用配额制：租户申请的资源不得超过分配给它的配额。ASI 自 2022 年启用以来，一直承载这些部门的关键业务。

ASI 集群的网络拓扑与资源规模

ASI 采用胖树网络：每个 8-GPU 节点连接到接入交换机（ASW），ASW 再通过汇聚交换机（AGG）互联。每个 ASW 汇聚 32-64 个节点，因此一个 ASW 域大约覆盖256-512 块 GPU；同一 ASW 下的 GPU 是同构的。由于网络并非完全无阻塞，作业若部署在同一 ASW 下就能以全带宽通信，而跨 ASW 的作业需要经过更多交换层级，有效带宽会下降。这一拓扑直接影响放置：通信敏感作业要求 ASW 内分配，进而限制调度器自由装箱的程度。第 4.1 节将量化其对碎片化的影响。

工作负载范围。 ASI 必须同时服务两类工作负载：快速增长的 GenAI 模型和成熟的经典 DNN。 LLM 和基于扩散的图像/视频生成等 GenAI 模型可能申请非常大的资源；追踪数据中最大的单个 GenAI 作业同时使用了 2,000 多块高端 GPU，消耗超过 800,000 GPU 小时。经典 DNN 仍是点击率（CTR）预测、推荐和光学字符识别（OCR）等高吞吐生产服务的核心，在追踪数据中仍占在线推理 GPU 小时的约 70%（图 3）。这些类别共处于同一集群，使 ASI 必须管理资源形态、 运行时间、优先级和放置约束差异显著的工作负载。追踪数据覆盖这一共享集群中的大规模训练与推理，但不包含超大规模基础模型预训练；后者通常运行在采用最先进硬件的专用集群上。

追踪数据。 ASI 记录了研究生产资源管理问题所需的元数据，包括作业类型、优先级、模型信息、 硬件类型、利用率指标和网络拓扑；以往公开追踪数据从未同时提供这些信息。如表 1 所示，ASI 追踪数据在作业量和集群规模上都比先前研究大至多两个数量级，同时覆盖了异构程度高得多的 GPU 机群。

ASI 追踪数据与既有公开集群追踪的对比

工作负载特征分析

追踪数据概览

追踪信息。 ASI 追踪记录了在上运行多种机器学习的训练、推理和开发。对于每项工作，它详细记录了执行请求、执行时间、执行持续时间以及 GPU 和 CPU 利用率，包括作业、任务和实例。我们还使用提升提示进行补充。机器遥测包括 GPU 规格、节点级利用率，由守护进程查询 Linux 内核和 GPU 驱动（例如 NVML）获得。

作业、任务和实例。 与先前的研究一样，用户提交作业。每个作业包含一个或多个承担不同角色的任务；每个任务又运行一个或多个实例，每个实例封装在一个 Kubernetes Pod 中（包含一个或多个容器）。ASI 使用定制 Kubernetes 管理这些 Pod，允许用户指定细粒度的资源请求和限制。

作业类型。 ASI 的作业覆盖机器学习从开发到部署的完整生命周期，可分为四类：

  • 开发作业通常是交互式的，开发者通过 Jupyter Notebook 等环境进行模型开发、调试和分析。
  • 训练作业执行迭代优化来更新模型参数。其持续时间从微调任务所需的几分钟，到大型模型预训练所需的数月不等。
  • 离线推理作业执行批量推理，例如评估和数据处理，通常对延迟不敏感。
  • 在线推理作业承载对延迟敏感的服务。

ASI 作业、任务、实例与 Kubernetes Pod 的层级关系

作业优先级。 ASI 允许用户指定作业优先级，使调度器能够区分不同工作负载。出于脱敏目的，我 们把作业粗略分为高优先级（HP）作业和低优先级（LP）竞价作业。HP 资源价格更高，但提供不会被抢占的可用性保障；LP 作业价格较低，但可能被 HP 作业抢占。

在线推理和训练作业以 HP 为主：在线推理需要为延迟敏感服务提供高可用性，而训练需要长期稳定的资源分配以支持迭代优化。相比之下，离线推理通常是 LP，因为它对延迟不敏感，适合以低优先级运行来提升经济效率。值得注意的是，开发作业几乎全部是 HP：开发者需要稳定环境，并且必须避免环境突然终止，以便保存中间状态。

ASI 不同作业类型的优先级分布 ASI 不同优先级作业的资源需求特征

时间模式

请求与利用率的昼夜模式。 ASI 的 GPU 需求呈现明显昼夜周期。

ASI GPU 请求与利用率的昼夜和周期模式

图 5 上半部分显示，训练和在线推理作业在白天请求的 GPU 明显多于深夜。GPU SM 利用率则更为复杂（图 5 下半部分）。在线推理利用率仍有昼夜规律，因为它会跟随即时用户需求；训练利用率没有这一规律，因为长时间运行的迭代会让 GPU 昼夜持续繁忙；离线推理则呈现周周期，周末的 SM 利用率 会明显下降。 GPU 采用变化。 随着硬件供应走向多样化，ASI 中 GPU 的采用情况发生了变化。NVIDIA GPU 已 经部署多年，需求相对稳定。为缓解供应链约束并建设更可持续的基础设施，ASI 近期开始采购其他厂商的 GPU；这些非 NVIDIA 设备统称为 XPU，目前已占机群相当大的比例（见图 4 左侧）。

ASI 异构 GPU 机群的构成变化

用户起初不愿采用 XPU-A，因为它的开箱即用性能低于预期。然而从约第 120 天起，XPU-A 的采用量迅速上升（图 6），这发生在专用优化套件发布之后；该套件显著提高了 XPU-A 上的模型性能。

XPU-A 优化前后的采用量变化

开发任务运行时间最长，因为开发者会长期保持交互式编程会话。排除开发任务后，在线推理与训练任务的执行时长相近，且都长于离线推理任务。按模型类型看，推荐和计算机视觉模型运行时间也最长，因为它们主要属于在线推理；主导离线推理的 GenAI 模型则比计算机视觉和推荐模型运行得更短。 总体而言，ASI 作业执行时间中位数为 5 小时，远长于 PAI的 23 分钟和 Acme的 2 分钟。原因在于 ASI 同时包含长期在线服务和大规模训练：PAI 只覆盖 DNN 作业，而 Acme 以短时评估作业为主（占 93%）。相比之下，调度延迟很低：中位数只有 1 秒，即使 HP 任务的 P90 也只有 101 秒；与其24 小时的 P90 执行时间相比可以忽略。

空间模式

下面分析空间模式，即任务如何在集群中请求和使用资源。ASI 每 20 秒采样一次所有运行中任务的遥测数据。

GPU 与 CPU 请求。 ASI 作业请求的单作业 GPU 数显著多于较早的追踪数据。

ASI 作业的 GPU 与 CPU 请求分布

GPU 分配。 我们用 GPU 分配率衡量已被作业申请的 GPU 容量占总 GPU 容量的比例。该指标反映 资源被申请的有效程度，并直接影响收入。我们还区分只由 HP 作业带来的分配率，以及 HP 与 LP 作业共同带来的分配率，以说明 LP 工作负载提升资源分配效果。

高优先级与低优先级作业带来的 GPU 分配率

如图 9 所示，LP 作业提高了所有 GPU 类型的分配率，对高端 GPU 的提升尤其明显：全集群平均值从只有 HP 作业时的 68% 上升到 HP 与 LP 合计时的 93%。第 4.2 节将说明 ASI 如何支持 LP 竞价作业。 GPU 共享很少采用。 GPU 共享允许多个请求分数 GPU（小于 1.0）的作业在同一设备上复用，以 往系统把它视为关键效率杠杆。但在 ASI 中，GPU 共享现在很少使用，原因将在第 4.2 节讨论。

ASI 中分数 GPU 请求的分布

不同作业类型的 CPU、GPU 与显存利用率

开发任务在所有指标上的利用率最低，符合其临时性特点；训练任务利用率最高，体现其计算密集性。在线推理和离线推理的主存使用相近，但 CPU 和 GPU SM 利用率差异显著，因为在线推理由交互式用户请求驱动，而离线推理以批处理方式运行。在线推理的 GPU 显存使用也低于离线推理，因为前者主要运行标准 DNN，后者则以 GenAI 模型为主。

不同任务组合下的节点网络利用率

我们进一步分析节点级网络利用率，包括接收和发送带宽。不同作业类型的任务可以共享节点，因此我们根据节点承载的任务组合进行分组，并展示六种最常见的组合。如图 12 所示，只运行训练任务的节点具有最高网络利用率，因为 ASI 中多数训练使用依赖并行、需要大量跨节点通信的 GenAI 模型。

提高资源利用率

本节介绍 ASI 集群中观察到的两个资源管理问题：GPU 碎片化与资源利用不足，并说明在生产环境中部署的应对机制。

解决GPU碎片化

GPU 碎片会把空闲 GPU 资源打散成无法整体分配、因而不能满足资源请求的小块，缩减集群的有效容量。我们先诊断 ASI 碎片化的来源，再介绍两种针对主要来源的机制：IPC 去碎片通过整合作业来回收零散 GPU 并缓解 CPU 瓶颈；拓扑感知分配则减轻网络拓扑要求引起的碎片。

GPU 碎片的来源。 先前工作指出了三种常见来源：

  • Fractional 分数 GPU 碎片。 生产环境中的机器学习模型可能很小。例如 ResNet-152 只有 6,000 万个参数，无法占满整块 GPU。因此，ASI 允许用户请求 0.25 GPU 等分数，使多个小模型能够共置于一块 GPU上，实现资源高效的 GPU 共享。但分数分配也会形成 GPU 内部碎片，在单块 GPU 上留下不可用的残余容量，尤其会阻碍需要整卡 GPU 的作业放置。
  • Stranded 零散 GPU 碎片。 在多 GPU 节点上，如果某作业没有申请节点中的全部 GPU，就会留下零散 GPU。 例如，把 2-GPU 任务分配到 8-GPU 节点会造成节点内碎片，剩余六块 GPU 无法满足随后到来的整节点（8-GPU）请求。
  • Insufficient CPU 不足。 GenAI 模型大量使用 GPU，但我们观察到 CPU 也可能成为 GPU 分配瓶颈。当节点能满足 GPU 请求却无法满足配套 CPU 请求时，就会出现这一情况，通常由极端 CPU/GPU 比引起（见图10 右侧）。节点 CPU 耗尽会造成 GPU 碎片。

不同资源请求配置下的 GPU 碎片来源

在 ASI 中，碎片很少由分数 GPU 引起，而是由零散 GPU 和 CPU 不足这两个瓶颈主导。图 13 在不同资源请求配置下，以不可分配的空闲 GPU 数量诊断碎片。分数 GPU 几乎没有贡献，这与图 10 左侧所示 GPU 共享很少采用相符。对于 CPU/GPU 比较高的请求（例如 1G8C 和 8G128C），主导瓶颈是“CPU 不足”：GPU 因 CPU 已耗尽而无法分配。对于中等规模配置（例如 4G32C 到8G64C），主导因素是“零散 GPU”（橙色柱）：总量上虽然有足够 GPU 容量，但它们分散在不同节点，无法调度需要连续多 GPU 分配的作业。 除上述三种已知原因外，当用户提交带网络拓扑要求的多 GPU 请求时，我们还观察到一种新的GPU 碎片来源。

网络拓扑。 LLM 等大型机器学习模型所需的总 GPU 显存通常超过一台 GPU 服务器的容量，因此标 准做法是把模型分块，并分布到多个 GPU 节点。这类模型的训练与推理都包含大量跨节点通信。 为减轻通信瓶颈，用户经常要求拓扑感知放置，例如要求分配的所有 GPU 位于同一 ASW 下。正如第 2 节所述，ASI 的胖树网络并非完全无阻塞，因此跨越多个 ASW 的作业要经过更多交换层级，有效带宽更低。基准测试显示，与跨 ASW 放置相比，把所有 GPU 共置于单一 ASW 下可以把 allreduce 带宽提高 27%。

然而，严格实施拓扑要求会引入一种新碎片：散布在不同交换机下的 GPU 不能分配给同一个作业， 使有效资源池显著缩小。为说明这一问题在 ASI 中的严重程度，我们构造了两种大规模配置，作业分别请求 128 和 256 块 GPU，每块 GPU 配套请求 12 个 CPU 核，然后测量 ASI 能够满足多少此类请求。

网络拓扑约束对大规模 GPU 请求可满足数量的影响

基线（跨 ASW）与强制 ASW 约束（ASW 内）的对比显示，实施 ASW 约束会显著减少可满足的作 业数。请求大规模同构 NVIDIA GPU 时，容量下降尤其严重，接近于零，说明严格拓扑要求会对这些高需求资源产生格外明显的影响。对较少使用的 XPU-A，影响则没那么显著。进一步地，允许异构 GPU 分配时，集群仍能为大规模请求保留更高容量。因此，在异构分配中推动使用不太热门的 GPU，能够有效缓解拓扑要求引起的瓶颈。

GPU 去碎片。 为回收零散 GPU 并缓解 CPU 瓶颈，ASI 把 GPU 去碎片作为日常维护任务运行。它 整合只占用服务器部分资源的作业，为同时需要多块 GPU 和大量 CPU 的新工作负载释放整机 GPU 容量。

挑战。 整合通过迁移运行中作业、把它们装到更少服务器上来实现，但在实时生产集群中执行迁移 面临三个挑战。

  • 第一，新作业随时可能提交，动态改变资源可用性与分配。因此 GPU 作业迁移的决策必须很快，确保迁移与调度能在数分钟内完成；集群的庞大规模使这很有挑战。
  • 第二，跨节点迁移必须满足实际集群约束，包括既有亲和性与反亲和性规则；这些规则规定任务是否能在某节点运行、某组任务是否能共置。此外，ASI 中 40% 的任务标记为“锁定”，表示其业务关键且不能迁移。
  • 第三，GPU 作业迁移与去碎片对用户必须透明。也就是说，不能对作业所用的底层机器学习框架施加限制，也不能引入服务停机。

IPC 算法。 我们设计并部署了 IPC（迭代式分区整合）。这一实用算法获取当前节点和任务状态的 快照，生成一组任务迁移决策，目标是尽可能腾空更多节点。上述三个挑战分别对应 IPC 的三项设计：

  • 分治使集群规模下的决策保持快速；

  • 逐出链调度在迁移期间满足亲和性、反亲和性和锁定任务约束；

  • 迭代过程则逐轮增加腾空节点数。为保证对用户透明，IPC 采用“先建后拆”：先在目标节点启动新实例，再终止旧实例，从而消除服务停机。

  • 分治。 为快速生成迁移决策，IPC 随机把集群节点划分为互不相交的组，每组构成一个独立子问题， IPC 在其中尝试腾空尽可能多的节点。这些子问题可以完全并行，从而加速集群规模下的决策。

  • 逐出链调度。在每个组内 IPC 根据优先级与启发式指标（例如节点承载的 Pod 数）为所有节点打分，并优先选择优先级更高、Pod 更少、因而更容易腾空的节点。算法 1 给出一个分区上的伪代码。

IPC 去碎片效果与拓扑感知分配指标

PC 递归构建逐出链：如果目标节点无法容纳某项任务，就递归地从该目标节点迁走 其他任务，直至所有 Pod 都得到放置，或达到递归深度上限 K。实际部署中 K 取 3。

算法1: 逐出链调度

输入：节点分区 N，最大深度 K。输出：迁移动作集合 M。

  1. 初始化 M 为空；将分区内节点排序得到列表 L。
  2. 对 L 中每个节点 n：令该节点的迁移动作集合 M_n 为空，并设 feasible=true。
  3. 对 n 中每个任务 task：调用 Eject(task, K)，递归搜索长度小于 K、同时满足实际约束与资源请求的可 行逐出链 C。
  4. 若 C 非空，把 C 加入 M_n；否则令 feasible=false，并结束本节点搜索。
  5. 若 feasible 为真，把 M_n 加入 M；否则把 n 标记为不可迁移。
  6. 返回 M。
  7. 迭代。 为腾空尽可能多的节点，IPC 会多轮迭代运行分治和逐出链调度，每轮都尝试腾空节点。

经验表明第三轮之后的边际收益很小，因此最多运行五轮。

这张图主要讲两件事：IPC 去碎片的实际效果，以及如何用“熵”让 GPU 尽量集中在少数 ASW 下。

1. IPC 为什么使用启发式算法

IPC 已经在 ASI 调度器中运行多年，可以在2分钟内生成迁移决策。这里指的是“算出怎么搬”，不一定包括所有任务真正搬完的时间。

在两个月的历史任务回放中，IPC 将“没有被完全占满的节点数”减少了20.2%。这不代表 GPU 利用率直接提高20.2%，而是说明更多零散任务被集中到少数节点，释放出了更多完整节点。

以前使用 Kubernetes 的普通驱逐机制：

驱逐任务 → 随机重新调度到其他节点

任务可能再次散落到整个集群，未必能缓解碎片。IPC 则会提前计算完整的逐出链，确保搬迁后能够真正清空节点。

论文没有追求数学上的最优解，因为计算成本太高：

  • 25个节点：产生4,000个二元变量和800条约束，Gurobi约5分钟才能求出最优解。
  • 100个节点：需要约两天。
  • IPC实际一个分区包含500个节点，直接求全局最优基本不可行。

而且数学最优方案可能要求同时迁移大量 Pod，生产环境也难以承受。因此 IPC 选择“速度快、迁移量可控、结果足够好”的启发式方案。

2. 为什么要做拓扑感知分配

ASW 是接入交换机。同一个作业的 GPU 如果分散在多个 ASW 下，GPU之间的通信要经过更多网络层级：

同一 ASW：GPU → ASW → GPU

跨 ASW：GPU → ASW → 上层网络 → ASW → GPU

为了减少跨 ASW 通信，ASI 尽量把一个大型作业的 GPU 集中到少数 ASW 下。

但“集中程度”需要一个可以计算的指标，因此论文引入了熵：

\[ H=-\sum_{i=1}^{n}p_i\log(p_i),\qquad p_i=\frac{g_i}{G} \]

其中：

  • (G)：作业申请的 GPU 总数。
  • (g_i)：分配在第 (i) 个 ASW 下的 GPU 数量。
  • (p_i)：该 ASW 所占的 GPU 比例。
  • (H)：GPU 分布的熵。

3. 熵怎么理解

假设作业需要8张GPU。

全部放在一个 ASW：

ASW-1：8张
分布比例：[1]
H = 0

这是最集中的情况，熵最低。

平均分布在两个 ASW：

ASW-1：4张
ASW-2：4张
分布比例：[0.5, 0.5]
H ≈ 0.693

平均分布在四个 ASW：

ASW-1：2张
ASW-2：2张
ASW-3：2张
ASW-4：2张
H ≈ 1.386

所以：

熵越低 → GPU 越集中 → 网络路径通常越短
熵越高 → GPU 越分散 → 跨 ASW 通信可能越多

ASI 的调度策略会在每次选择 ASW 时，计算加入该 ASW 后的熵，然后选择让熵最低的方案。

整段话的核心是：

IPC 用快速启发式迁移清理已经形成的 GPU 碎片；拓扑感知分配则尽量把新任务的 GPU 集中到少数 ASW 下，从源头减少网络通信和拓扑碎片。前者负责“事后整理”，后者负责“事前避免”。

算法2: 拓扑感知GPU分配

这个算法的核心思想很简单：

给一个大型作业分配 GPU 时，每一轮都选择能让 GPU 分布最集中的 ASW，尽量减少跨交换机通信。

它负责生成新作业的 GPU 分配计划，并不直接执行 Pod 迁移；需要跨 ASW 整理已有任务时，才会调用前面介绍的 IPC。

各个变量的含义

  • G：作业总共需要多少张 GPU。
  • N：当前可以使用的 ASW 集合。
  • Cap(s)：ASW s 下还有多少张可用 GPU。
  • G_rem：还剩多少张 GPU 没有分配。
  • P：已经生成的分配计划。
  • s*：当前这一轮选中的 ASW。
  • n：从该 ASW 中实际分配的 GPU 数量。

算法如何运行

假设作业需要8张GPU：

ASW-A：空闲6张
ASW-B：空闲4张
ASW-C：空闲4张

首先：

P = 空
G_rem = 8

算法会分别模拟：

  • 从 ASW-A 分配最多6张；
  • 从 ASW-B 分配最多4张；
  • 从 ASW-C 分配最多4张。

然后计算每种方案产生的 GPU 分布熵，选择最集中的方案。假设首先选择容量最大的 ASW-A：

P = {(ASW-A, 6)}
G_rem = 8 - 6 = 2

下一轮只需要再分配2张。算法继续比较 ASW-B 和 ASW-C，选择其中一个：

P = {
  (ASW-A, 6),
  (ASW-B, 2)
}
G_rem = 0

最终，8张GPU分布为：

ASW-A：6张
ASW-B：2张

这种 6+2 的分布比 4+4 的熵更低，因为大部分 GPU 集中在一个 ASW 下，跨 ASW 的通信规模更小。

每轮为什么分配“尽可能多”

第4行：

n = min(Cap(s*), G_rem)

分两种情况：

  • ASW剩余容量比需求多：只分配作业需要的数量；
  • ASW容量不足：把该ASW的空闲GPU全部分给作业，再去其他ASW补齐。

例如还需要3张GPU，而选中的ASW有8张空闲GPU：

n = min(8, 3) = 3

如果还需要8张，而该ASW只有5张：

n = min(5, 8) = 5

为什么选完后要把 ASW 移出集合

N = N - {s*}

因为这个 ASW 的可用GPU已经在本轮全部考虑完了，没有必要下一轮重复选择。算法继续从剩余ASW中补齐需求。

为什么单个作业有效，多个作业却不一定最优

对一个作业来说，只需要让它的GPU尽量集中即可。但多个作业会争抢同一批ASW：

作业A先占用了某个ASW的大块连续资源
                ↓
作业B到来时只能跨多个ASW分配

所以单独看作业A可能是最优的，放到整个集群中却可能影响后续作业。ASI采用的实用办法是按照GPU需求量从大到小排序，优先安排大型作业，因为大型作业更难找到满足拓扑要求的资源。

还有两个细节：

  • 如果多个ASW产生的熵相同，实际实现应优先考虑容量更大的ASW；论文伪代码没有明确写出这个平局规则。
  • 如果所有ASW都遍历完后 G_rem 仍大于0，说明当前集群无法满足该作业，实际调度器应将这次分配判定为失败或等待资源。

一句话概括：

算法2采用贪心策略，每轮尝试从一个ASW拿走尽可能多的GPU，并选择让整体分布熵最低的ASW，从而把一个作业的GPU集中在尽可能少的交换机下，减少跨ASW通信。

解决资源利用率不足

工作负载分析揭示了集群中显著的时间和空间资源利用不足（图 5、图 11）。与用户讨论后发现，主要原因是一种常见做法：用户过量配置 GPU 容量，以吸收昼夜流量峰值、维持故障切换冗余并为大型活动预留余量。这类防御性预留会让相当比例的资源长期闲置，降低集群整体效率。

把 GPU 共享作为稻草人方案。 回收未充分利用资源的一种自然办法是 GPU 共享，即把多个作业共置于一块 GPU，让它们通过时间复用填补空闲周期。ASI 虽然支持 GPU 共享，但采用率很低（图 10 左侧），原因有二。第一，GPU 的隔离能力弱于 CPU，因此共置作业会互相干扰；即便 MPS（多进程服务）和 MIG（多实例 GPU）等虚拟化机制也只能提供粗粒度且不灵活的切分。第二 ，新兴 GenAI 模型的参数和中间状态（例如 KV 缓存）会消耗大量 GPU 显存，难以让多个作业共享一块 GPU。因此，ASI 的Fractional 分数 GPU 请求几乎全部来自经典计算机视觉与推荐模型，它们用启用 MPS 的预留 GPU 服务小模型。GPU 共享只能回收单个设备内部的空闲容量；为了回收不同作业之间规模大得多的“已预留但空闲”容量，ASI 通过 SpotGPU 在作业粒度上运作。

SpotGPU。 SpotGPU 有两个目标。第一，回收已预留但空闲的 GPU 容量并重新用于有效工作，从而提高集群级利用率。第二，把这些回收容量和其他空闲资源一并以折扣竞价价格提供给运行灵活工作负载的用户。具体而言，SpotGPU 在保证安全的前提下超额订阅 HP 作业的预留容量，并把由此产生的空闲容量分配给 LP 竞价作业。LP 作业获得的资源没有保障，因此价格较低；当 HP 作业收回其预留资源时，SpotGPU 会近实时抢占正在运行的 LP 作业。

“备用”HP 任务。 为在不干扰 HP 作业的情况下回收其预留容量，SpotGPU 提供“备用”机制，并用费用返还鼓励参与。用户通过 API 把 HP 任务在自选时间窗口内标记为“备用”，例如更新其 Kubernetes Pod 标签，表示愿意暂时把任务分配到的资源释放给 LP 竞价作业。

SpotGPU 的备用机制与抢占成本感知调度

备用任务必须能够快速恢复，因此 SpotGPU 不会销毁容器。它会断开任务的请求流量，并用 sleep 命令替换容器的主服务进程，在保持容器热状态的同时释放 CPU 和 GPU；再次激活时便可跳过代价较高的重新调度与镜像拉取。当 HP 任务必须恢复时，SpotGPU 先触发对共置竞价作业的优雅驱逐，再通知 HP 任务继续运行，从而维持 HP 的服务等级目标。 驱逐过程如下：

  • 节点代理观察到 HP Pod 到达节点；
  • 向共置的竞价 Pod 发送 SIGTERM；
  • 容器内执行用户定义的优雅关闭逻辑，最长不超过 60 秒；
  • 容器退出，GPU 被回收。

步骤（i） 、（ii）、（iv）由平台执行，快速且时间确定，因此驱逐延迟主要由用户定义的步骤（iii）决定。在部署中，平均驱逐时间为 13 秒，P95 为 48 秒，明显处于 60 秒窗口内。没有在窗口内退出的容器会通过SIGKILL 强制终止，此类情况不到全部驱逐的 5%。恢复 HP 任务时，SpotGPU 用原命令替换 sleep。图 16 显示，平均 90% 的“备用”GPU 小时都得到收割。

这段讲的是 SpotGPU 如何调度高优先级（HP）任务和低优先级竞价（LP）任务。核心原则是：

能不抢占就不抢占；HP任务确实放不下时，才选择“损失最小”的LP任务停止。

1. 为什么用检查点计算抢占成本

GPU任务会定期保存检查点。LP任务被抢占后，不必从头运行，而是从最近一次检查点恢复。

检查点A ─── 已完成但未保存的计算 ─── 被抢占
              ↑
           这部分需要重算

因此，抢占真正浪费的是“最近一次检查点之后完成的计算”，而不是任务的全部运行时间。

2. 第一阶段：先尝试不抢占地调度

HP或LP任务到来时，调度器首先筛选出GPU类型和数量满足要求的节点，然后按照三层规则排序。三层规则不是同时打分，而是逐级打破平局。

规则一：任务装箱

优先选择剩余GPU最少但又能放下任务的节点，也就是类似 Best Fit：

任务需要2张GPU

节点A：空闲2张  ← 优先
节点B：空闲4张
节点C：空闲8张

把任务放到节点A后，节点A刚好装满，避免在多个节点上留下零散GPU。

规则二：同类任务放在一起
HP任务尽量放到HP节点
LP任务尽量放到LP节点

这样做是为了隔离两类任务：

  • HP节点更加稳定，避免受到LP任务影响。
  • LP任务集中在专用节点上，将来回收资源时，可以直接抢占LP任务。
  • 不会为了抢占一个LP任务而干扰同节点上的其他重要任务。
规则三：参考历史抢占次数

对新LP任务：

选择历史抢占次数最少的节点

这样LP任务被再次抢占的概率较低，适合长期运行。

对新HP任务：

选择历史抢占次数最多的节点

这样未来可能发生的抢占会集中在原本就不稳定的节点上，其他稳定节点可以留给长时间运行的LP任务。

3. 第二阶段：HP放不下时启动抢占

如果HP任务无法通过普通方式调度，就进入抢占模式。

注意：

  • 只有HP任务可以触发抢占。
  • 新LP任务不能通过抢占其他任务来获得资源。
  • 被抢占的对象只能是LP竞价任务。

调度器会寻找这样的节点：

只要移除节点上的部分LP任务，就可以腾出足够资源容纳HP任务。

然后计算每个节点的抢占成本。

4. 抢占成本怎么计算

对于LP任务 (t)：

\[ C_t=G_t\times(time_{now}-time_{ck}) \]

其中：

  • (G_t)：LP任务使用的GPU数量。
  • (time_{now})：当前时间。
  • (time_{ck})：上次保存检查点的时间。
  • (C_t)：需要重新计算的GPU工作量。

例如：

LP任务A：使用2张GPU，距离检查点5分钟
成本 = 2 × 5 = 10 GPU·分钟

LP任务B：使用4张GPU，距离检查点3分钟
成本 = 4 × 3 = 12 GPU·分钟

虽然任务B使用的GPU更多，但它刚保存过检查点，所以抢占它只会浪费12 GPU·分钟。

这个指标同时考虑了：

  • 会损失多长时间的计算；
  • 这些计算占用了多少张GPU。

因此，比单纯按照“谁运行时间最短”选择更加合理。

5. 如何计算一个节点的抢占成本

假设HP任务需要4张GPU。

节点A上有：

LP-1：2张GPU，成本10
LP-2：2张GPU，成本40
LP-3：4张GPU，成本80

调度器按成本从低到高排列：

LP-1：成本10，释放2张
LP-2：成本40，释放2张
LP-3：成本80，释放4张

从前往后选择最小前缀，直到释放的GPU够用：

选择 LP-1 + LP-2
释放：2 + 2 = 4张GPU
总成本：10 + 40 = 50

所以节点A的抢占成本是50。

再看节点B：

LP-4：使用4张GPU，抢占成本32

只需要抢占LP-4：

释放4张GPU
总成本32

因为：

节点A成本：50
节点B成本：32

调度器最终选择节点B，把HP任务放到节点B，并抢占LP-4。

6. 为什么不用MILP直接求最优解

理论上，可以使用混合整数线性规划同时考虑所有节点、任务、GPU类型和抢占组合，找到全局最优方案。

但在线调度必须快速响应，MILP的求解时间不可控。因此，SpotGPU使用启发式方法：

先尝试普通调度
        ↓
失败后筛选可通过抢占腾出空间的节点
        ↓
分别计算每个节点的最低抢占成本
        ↓
选择成本最低的节点

这种方法不一定是数学上的全局最优，但计算快，适合生产环境。

需要注意，它与IPC不同：

  • IPC：通过迁移任务整理资源碎片，采用“先启动新副本、再停止旧副本”。
  • SpotGPU：为了让HP任务立即获得资源，停止LP任务；LP任务以后从检查点恢复。

一句话总结：

SpotGPU首先通过装箱、同类共置和抢占历史来尽量避免抢占；如果HP任务仍然无处可放，就选择“GPU数量 × 距离上次检查点时间”最小的一组LP任务停止，从而用最少的计算损失收回资源。

SpotGPU 的收益。 SpotGPU 把平均 GPU 分配率从 68% 提高到 93%（图 9），意味着有明显更多资源投入有效工作；图 16 还说明用户会主动通过“备用”释放预留容量，缩短闲置时段。为单独评估抢占式调度器的贡献，我们将其与一个基线比较：基线在非抢占式调度中关闭共置和驱逐感知，并在抢占式调度中随机选择牺牲者。本文调度器在不影响 HP 任务性能的情况下，把 LP 任务完成时间缩短 24%；这一收益来自计入抢占成本，从而避免丢弃已接近完成的竞价任务工作。

开放挑战

异构GPU采用不均衡

因为kernel没有适配好，导致更强的硬件跑不出效果。因此我们进行了优化：

预填充。 在预填充阶段，XPU-A 中的 Flash Attention 在因果掩码下分配不均。因果掩码让每个查询只能关注之前的键，因此计算量呈阶梯式增长，每个查询的负载随其位置增长（图 17 右）。现有内核按连续查询把任务映射给 XPU-A 的计算引擎（CE），造成严重的负载不均：负责靠后查询的 CE 仍在处理，而其他 CE 已经结束并处于闲置状态。我们改为沿注意力头分配 CE，使负载在各个 CE 之间更加均衡。这个改动虽然简单，但在 64 个注意力头、4k 上下文长度下，将预填充速度提升了 1.58 倍。

解码。 解码阶段通常使用 Paged Attention（PA。它受到内存带宽限制，因为每一步解码都要从 GPU 显存读取完整的 KV 缓存。为了充分利用 XPU 的计算单元（CU），PA 使用 SplitKV，把 KV 缓存切分成多个部分，由多个 CU 并行处理。使用 Triton将 PA 移植到 XPU-A 时，编译器反转了循环顺序，导致每个 CU 都重复执行完整计算，而不是各自处理分片，浪费了大量计算资源。我们向 Triton 注入了一个编译器 Pass，强制采用正确的循环顺序，并已把这个修复贡献回 Triton。

其他资源管理挑战

异构环境中的拓扑感知分配。 第 4.1 节说明了网络拓扑约束如何限制 GPU 分配；这些约束也与硬件异构性发生冲突。在 ASI 中，同一 ASW 下的 GPU 是同构的，因此强制 ASW 级局部性会阻止同一作业混用异构 GPU，而异构性恰恰正在成为 GenAI 的关键优化手段。

例如，PD 分离已广泛应用于 LLM 服务，每天在 ASI 中使用多达 12,000 个 GPU：预填充受计算限制，更偏好算力强的 GPU；解码受内存带宽限制，需要更高的带宽。这种异构匹配有利可图，却使远距离通信成为问题。KV 缓存必须在预填充和解码之间传输；只有 KV 缓存传输完成后，解码才能开始，因此网络性能成为瓶颈。实现高收益需要在计算性能和通信开销之间取得平衡。这种冲突不仅存在于 LLM 服务中，也存在于任何使用异构 GPU 的系统。

推理利用不足。 推理是 ASI 中最常见的工作负载，但利用率很低：聚合所有推理工作负载后，SM 利用率的中位数仅为 6%，内存利用率中位数为 30%。这包含两种不同的模式。GenAI 推理受内存限制，使用了 94% 的内存，却只使用 5% 的 SM，因此耗尽了内存，却留下了闲置的计算资源。传统 DNN 推理的内存和计算利用率都很低，仅使用 20% 的内存和 6% 的 SM。二者的资源需求具有互补性：DNN 推理只需要少量内存，可以利用 GenAI 推理留下的计算资源，而不会争抢内存。然而，实现这种共置并不容易。现有 GPU 共享机制要么缺少细粒度的空间共享；MIG过于僵化；要么依赖时间共享，但无法满足严格的延迟目标。

CPU 与 GPU 工作负载之间的共置。 与 Acme类似，ASI 的 CPU 利用率中位数只有 31%。ASI 通过把纯 CPU 工作负载与 GPU 工作负载共置来缓解这一问题，导致 80% 的节点成为“CPU 主导”节点，即 CPU 工作负载使用的核心数多于 GPU 工作负载。然而，这种做法会干扰 GPU 工作负载：与 GPU 主导节点相比，CPU 主导节点上的 SM 利用率中位数和 P90 分别下降 10% 和 18%，说明共置策略并不理想。现有利用闲置 CPU 的方案主要面向特定工作负载（例如 LoRA 适配器），限制了适用范围。要充分利用这些资源，需要同时考虑 CPU 和 GPU 的调度器，以及能够控制相互干扰的隔离机制。