多租户 GPU 调度与容量规划

状态：草稿（2026-10-07 更新，2026-10-09 补充借用上限实测数据）。 本文基于官方文档与论文确认的叙述，其中**第 3 节末尾的三项实测（gang 调度比较、同类群组借用与抢占、借用上限与回收速度）**是在一次性单节点集群中直接测量的值。其余章节尚未实测（未实测）。 请先阅读文末的“确认的版本与日期”以及“未确认的内容”。 编写规则：以实测数据为基础，未能测出的内容标记为“未实测”。

目录

• 1. 默认调度器的局限性
• 2. Kueue：准入层
• 3. Volcano 与选择标准
  • 实测：当两个需要同时启动 4 个 Pod 的作业竞争时
  • 实测 2：同类群组借用、归还、优先级抢占
  • 实测 3：借用上限与回收速度
• 4. 拓扑感知放置
• 5. 优先级与抢占设计
• 6. GPU 共享与隔离的局限性
• 7. 动态资源分配（DRA）的当前状态
• 8. 容量规划
• 小规模共享中常见的陷阱
• 动手尝试
• 面试中可能会问到的问题
• 常见误区
• 参考资料
• 外部依据
• 确认的版本与日期

要让多个团队共享使用 GPU 集群，需要三项能力：保证各团队配额但允许借用剩余资源的配额机制、针对分布式训练等需要多个 Pod 同时启动的作业的 gang 调度，以及在保障推理服务的同时挤出批处理作业的抢占策略。默认调度器无法直接提供其中任何一项。本文将探讨辅助手段的设计差异、隔离局限性以及计算容量的顺序。

读完本文后，你将能够在面试中解释以下内容：

1. 默认调度器的 GPU 模型（整数扩展资源）为什么不足以支持 gang 调度和公平共享，以及 Kueue 是准入层而 Volcano 是调度器的区别。
2. time-slicing、MIG 和 MPS 能够划分什么以及无法隔离什么，以及不同信任级别下的选择。
3. 根据请求率和延迟目标逆算 GPU 数量的顺序（吞吐量、并发度、KV 缓存、富余量、容灾）以及利用率指标的陷阱。

1. 默认调度器的局限性

• 整数扩展资源：设备插件文档指出，扩展资源仅支持整数，不能超额认购（oversubscribe），且无法在容器之间共享。请求量与限制量必须相同。
• Pod 级别的决策：kube-scheduler 会逐个 Pod 进行过滤和打分来选择节点。如果一个需要 8 个 GPU 的作业的 8 个 Pod 中只有 6 个获得了位置，这 6 个 Pod 就会占用 GPU 并等待其余 Pod。这就是需要 gang 调度的原因。
• 原生 gang 调度尚不是默认功能：在 Kubernetes 1.37 中， PodGroup API（scheduling.k8s.io/v1beta1）和 GenericWorkload 开关虽然处于 beta 阶段，但默认是关闭的。文档指出最小数量（minCount）保证仅适用于初始放置。
• 没有队列与公平性: ResourceQuota：像 requests.nvidia.com/gpu这样，仅限制命名空间总量，而没有队列、借用和归还机制。
• 抢占以 Pod 为单位：被牺牲的 Pod 拥有体面终止宽限期（termination grace period），因此腾出位置需要时间，且对 PodDisruptionBudget 的遵守是尽力而为的（best-effort）。 preemptionPolicy: Never意味着不抢占其他 Pod，并不意味着自己不会被抢占。

2. Kueue：准入层

flowchart LR
  J["Job (queue-name 레이블)"] --> LQ["LocalQueue (네임스페이스)"]
  LQ --> CQ["ClusterQueue (쿼터, cohort)"]
  CQ -- "쿼터 예약과 승인" --> W["Workload 승인, 파드 생성"]
  W --> KS["kube-scheduler가 노드 배치"]
  KS --> DP["디바이스 플러그인 또는 DRA"]

Kueue 文档指出，将 Pod 放置到节点上的工作由 kube-scheduler 负责，自动扩缩容由 cluster-autoscaler 负责。Kueue 决定作业何时开始（创建 Pod）以及何时停止。

apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata: {name: team-a}
spec:
  cohortName: all-teams
  queueingStrategy: BestEffortFIFO
  preemption: {reclaimWithinCohort: LowerPriority, withinClusterQueue: LowerPriority}
  resourceGroups:
  - coveredResources: ["nvidia.com/gpu"]
    flavors:
    - name: gpu-pool
      resources: [{name: nvidia.com/gpu, nominalQuota: 8, borrowingLimit: 4}]

Job 通过 kueue.x-k8s.io/queue-name 标签选择 LocalQueue，优先级则通过与 Pod 分离的 WorkloadPriorityClass（标签 kueue.x-k8s.io/priority-class）来赋予。抢占分为基于优先级的默认方式，以及比较主导资源份额（Dominant Resource Share, DRS）的公平共享方式。最新的 v0.20.0（2026-09-30）不再提供 v1beta1，仅提供 v1beta2。由于它还支持 Deployment、StatefulSet 和 LeaderWorkerSet，因此可以同时管理推理服务与训练。多集群分发机制 MultiKueue 目前处于 beta 阶段。

waitForPodsReady如果所有 Pod 未能在限时内准备就绪，就会中止作业并将其退回队列。文档将其称为基于时间限制的实现，并指出由于顺序准入，准入可能会变慢。本文将其与原生 gang 调度区分开来探讨。

3. Volcano 与选择标准

Volcano 是一个独立的批处理调度器。 PodGroup的 minMember以 gang 为单位， Queue拥有 weight（相对份额）、 capability（上限）和 guarantee, reclaimable。调度器运行 enqueue, allocate, preempt, reclaim, backfill 动作，并在配置文件中以分层方式配置 gang, priority, drf（主导资源公平性，DRF）、 proportion, binpack 等插件。在 v1.15.0 中，gang 感知抢占进入了 alpha 阶段，最新的稳定版本系列是 v1.15.3（2026-09-30）。NVIDIA 的 KAI Scheduler 也作为一个独立的调度器，主张分层队列、基于时间的公平共享和拓扑感知（最新版本未确认）。

如果保留默认调度器且目的是实现团队配额与借用，Kueue 是候选；如果希望在调度器内部强力使用 gang 和队列，则 Volcano 或 KAI 是候选。将两者叠加使用在同一个 Pod 上的支持范围尚未确认。

实测：当两个需要同时启动 4 个 Pod 的作业竞争时

我们亲自测试了第 1 节中的“Pod 级别决策”是否真的会导致死锁，以及两个工具是如何解决它的。

环境与方法。 在 4 vCPU、4GiB 虚拟机内的一次性单节点 k3s（v1.36.5）中，向节点状态通告了 8 个扩展资源 example.com/gpu （实际并没有 GPU，Pod 只是 sleep ）。一个作业包含 4 个 Pod，每个 Pod 请求 2 个资源，因此一个作业将耗尽全部 8 个资源。当同时提交作业 A 和 B 时，需求为 16，供给为 8。测量“单个作业的 4 个 Pod 全部变为 Running 的时间”，在删除被接受的作业后，还测量了等待中的作业全部启动 4 个 Pod 所需的时间（Pod 终止宽限期 0 秒，重复 3 次）。分别通过各自的清单（manifest）安装了 Kueue v0.20.0 和 Volcano v1.15.3。

• 死锁确实会发生。 如果交替创建 Pod，默认调度器会将资源对半平分给两个作业，剩余的 Pod 永远无法获得位置。这表现为手握资源互相等待的形态。如果 Pod 创建顺序是集中为一个作业创建，可能不会陷入死锁，因此这是接近最坏情况顺序下的结果（未通过改变顺序进行测试）。
• 两个工具都以“全有或全无”的方式运行。 观察不到任何只运行了一部分的状态。两者的机制不同：Kueue 以作业为单位检查配额，在被接受之前不创建 Pod（作业处于暂停状态）；Volcano 则是只有在能够满足 Pod 组的最小数量时，调度器才会一次性分配位置。
• 被接受的一方并非每次都相同。 第一次测试是 B 先被接受，之后的三次是 A 先被接受。如果在相同优先级下几乎同时提交，则不应依赖顺序。如果顺序很重要，应明确指定优先级。
• 安装成本。 两个工具从应用清单到准备就绪大约都需要 20 秒（包含首次拉取镜像的时间，各测试 1 次）。
• 测试中的错误（记录）。 在首次测试中，Volcano 的等待时间测出来是 35 秒，这是因为 sleep 忽略了终止信号，导致 Pod 用尽了 30 秒的宽限期才结束的时间混入了其中。将宽限期设为 0 秒重新测量，便得到了上述的 3~4 秒。这与第 1 节中叙述的“当测量抢占或归还时间时，终止宽限期将主导时间”是同一个道理（牺牲 Pod 的正常终止宽限期）。

该数值仅在单个节点、虚假资源、两个作业以及已有镜像的轻量级容器这一条件下才有意义。随着节点增多，调度器吞吐量和位置选择将决定成本。此外，Kueue 能够避免死锁，似乎是因为配额（8 个资源）与实际可用资源相匹配。Kueue 文档指出，如果配额与实际可用资源不匹配，可能会发生死锁。生产环境中的恢复时间尺度是以分钟为单位的（如下文外部依据中 Philly 的 2~3 分钟超时和 Kueue 的 30 分钟默认超时限制）。本文中的 2~4 秒是没有竞争时的正常路径下的数值。

实测 2：同类群组借用、归还、优先级抢占

在上述环境（单节点 k3s，扩展资源 8 个， sleep 作业，终止宽限期 0 秒）中，这次我们提交了多个单 Pod（1 个资源）的作业来验证队列策略。使用的是 Kueue v0.20.0，两个团队（team-a、team-b）各自拥有 4 个配额，并且是一个可以互相借用剩余配额的同类群组（cohort）。

• 收回已借出份额并非默认行为。 Kueue 将 reclaimWithinCohort 设为 Never 时，会一直等到借用方自行结束（这里等待了 60 秒以上），而 Volcano 在默认调度器设置中没有 reclaim ，因此未发生抢占。第 5 节中“服务方收回借出分额时，批处理会被挤走”的设计只有在开启此设置后才能成立。
• 收回时间为几秒到十几秒不等，这是因为终止宽限期为 0。 由于实际的训练任务会保存检查点并退出，因此会加上宽限期的时间（与上述测试中的错误记录原因相同）。
• 被驱逐的任务并未消失，而是返回队列 ，在资源空闲时全部重新运行（3.0 秒、1.8 秒）。
• 当批量提交大量小任务时，Kueue 更慢。 我们测试了 8 个资源，一次性提交 N 个每个任务使用 1 个资源 1 秒的任务，直到全部结束所需的时间。

Kueue 的 400 个任务是通过每 30 秒记录一次进度的单独测试（以约 1.3 个/秒的速度稳定完成）测得的值。由于计算完成数量的方式存在错误，最初的测试未能获取到数值。这两种方式的结果都是理想值（8 个资源从未闲置时）的 5 到 7 倍，因此主导时间的不是调度器，而是在这个 4 vCPU VM 中创建和删除 Pod 的开销，而 Kueue 为每个任务增加了约 0.2~0.3 秒的准入处理（经计算）。在小规模下，这种差异会被 Pod 的启动时间掩盖，但这意味着如果工作负载是每秒提交几十个短任务，队列层可能会成为吞吐量的瓶颈。

• 局限性。 任务数量在几十个以下（大规模测试最多 400 个），且只有一个节点，使用的是虚拟资源。借用上限在下面的实际测量 3 中进行了简短测试，而混合了优先级的队列的长期运行情况（低优先级的饥饿、StrictFIFO 与 BestEffortFIFO 的等待分布）未进行测量（未实测）。

实测 3：借用上限与回收速度

在 Mac（Apple M1 Max）的 Docker Desktop（8GB 内存，10 个 CPU）上的 kind 单节点（Kubernetes v1.36.1）中， 使用 Kueue v0.20.0 进行了测量。虚拟扩展资源、 sleep 任务、0 秒终止宽限期与实测 2 相同。 在一个 cohort 中设置 team-a（配额 3）和 team-b（配额 5），并开启了 reclaimWithinCohort: Any 收回。team-a 提交了 10 个占用 1 个资源的任务，随后 team-b 请求其 5 个配额。

• 借用量在上限处精确停止。 在全部 8 次采样中，最大运行数均等于“配额 + 上限”， 并且在约 12 分钟内每秒记录一次的 2,064 个队列状态中，也没有出现超过上限的时刻。
• 收回时间与借用量成正比。 Kueue 大约每 1.1 秒驱逐一个借用的任务。 因此，借用上限既是一种公平性机制，也是一个决定“服务方收回自己的份额最多需要几秒钟”的调节杆。 正如实测 2 中所述，每个牺牲的任务都会加上终止宽限期（保存检查点的时间)。
• 临时借用空闲配额的任务在 1–2 秒内就被再次驱逐了。 当某一团队的任务结束、配额空闲的瞬间，另一个团队的等待任务会借用该份额，但随着原团队的等待任务归来，该份额立即被收回，这种情况在第一个周期（约 3 分钟）内发生了两次。如果批处理任务是启动开销很大的训练任务，这种短暂的借用得不偿失，因此最好将借用上限设小，或者为批处理设置较低的优先级（第 5 节）。
• 局限性。 由于不同集群共享 Docker 导致 VM 内存耗尽区间的运行全部被判定为无效并丢弃，每个条件下的有效样本仅有 2–3 个。20 分钟以上的长期运行以及混合优先级的队列尝试了三次，但因过载失效而未能测出（未实测）。

4. 拓扑感知批处理

节点内的 NVLink 和节点间的 InfiniBand（IB）邻近性决定了训练通信速度。Kueue 的拓扑感知调度（TAS）从 v0.14 开始处于 Beta 阶段且默认开启。通过节点标签将块和机架等层级定义到 Topology中，并通过 ResourceFlavor.spec.topologyName连接，并使用 Pod 注解 podset-required-topology或 podset-preferred-topology来设定需求级别。文档指出，由于它会追踪所有 Pod 和节点，因此内存消耗会增加。Volcano 使用 HyperNode（文档中的示例 API 为 topology.volcano.sh/v1alpha1）来定义层级，并为任务赋予硬约束或软约束。多节点 NVLink 是 NVIDIA DRA 驱动程序 ComputeDomain的官方支持功能。

5. 优先级与抢占设计

为服务分配保证配额和高优先级，为批处理训练分配低优先级和借用配额。当服务收回借用分额时（reclaimWithinCohort），批处理会被挤走，因此批处理必须通过检查点来承受中断。牺牲 Pod 的终止宽限期会造成重新调度延迟，因此应将其缩减到仅保留保存检查点所需的时间。此外，根据 Kubernetes 文档，调度器无法抢占使用 DRA 资源的 Pod。

6. GPU 共享与隔离的局限性

time-slicing 会将资源按 replicas的倍数进行夸大宣传，并且 DCGM（Data Center GPU Manager）导出器在此模式下无法关联每个容器的指标（GPU Operator 文档）。Ampere 架构之后的某些 GPU（如 A100、H100、B200 等）支持 MIG，但在已确认的 NVIDIA 支持列表中没有消费级 GPU，若要更改配置，该 GPU 上必须没有用户工作负载。从驱动 r610 开始，MPS 开启静态 SM 分割后可实现部分隔离，监控工具会将客户端的使用量汇总到 MPS 服务器进程中。因此，对于互不信任的租户应使用 MIG 或专用节点，而对于同一团队的轻量级任务则使用 time-slicing 或 MPS。Kueue 配额是记账工具，而不是安全边界。

7. 动态资源分配（DRA）的当前状态

DRA 允许通过 ResourceClaim, DeviceClass, ResourceSlice以属性（通用表达式语言（CEL）表达式）的形式请求设备。功能门控数据（确认于 2026-10-05）如下：

NVIDIA DRA 驱动程序（kubernetes-sigs/dra-driver-nvidia-gpu，v0.5.0，2026-08-19）的 README (main) 将 ComputeDomain称为官方支持，并指出 GPU 分配尚不是官方支持且在 Chart 中默认关闭。文档网站将 MIG、time-slicing 和 MPS 列为支持的功能，但未说明其阶段，因此无法确认哪一个是最新的。Kueue v0.20 发行说明中将 DRA 设备可用性检查作为 Alpha 门控列出，而 Volcano v1.15 则将 DRA 资源计算纳入了队列配额中。

8. 容量规划

λ(요청률), 입출력 길이, 지연 목표 -> 복제본 1개의 실측 처리량과 동시성
 -> 처리량 기준 대수, 동시성(Little 법칙) 기준 대수, 키-값(KV) 캐시 한도 확인
 -> 큰 쪽 선택 -> 여유율 -> 장애 대비(N+k) -> 병렬화(텐서 병렬, TP) 단위로 올림

这是一个用于说明的示例。基准点是作者在实验环境中测得的值：在 24GB 级消费级 GPU 上，Qwen3.8-27B（NVFP4）在并发 4 请求下的总计吞吐量为 138 tok/s，KV 缓存约为 57,000 个 Token。假设请求率为 0.5 req/s，输入 1,500 个 Token，输出 400 个 Token。

1. 吞吐量：0.5×400=200 tok/s ÷ 138 = 1.45，因此需要 2 台。
2. 并发性：如果每个请求 138÷4=34.5 tok/s，则响应时间约为 11.6 秒，根据利特尔法则（Little's Law），0.5×11.6≈5.8 个请求同时进行。由于每个副本限制并发 4 个，因此至少需要 2 台（8 个槽位），槽位利用率约为 72%。
3. KV 确认：6×(1,500+400)=11,400 个 Token，在 57,000 以内。
4. 加上 30% 的负载波动余量和 1 台用于应对故障的冗余机器，总共确定为 3 台。

如果模型跨越多张 GPU（张量并行 TP），则复制单元会随 GPU 数量按比例扩大，因此需要将实例数乘以 TP 大小，当一个节点宕机时，容量会以副本单元进行缩减。

利用率指标的陷阱：NVML（NVIDIA Management Library）的 utilization.gpu是采样期间内核至少运行一次的时间比例，无法说明 SM 的实际使用程度。像 DCGM 的 SM_ACTIVE, PIPE_TENSOR_ACTIVE 这类性能剖析指标更为细致。从成本角度来看，需要同时考察分配的 GPU 时间与实际工作时间的比率（分配率）以及服务指标（队列长度、KV 缓存占用率、满足目标延迟的吞吐量）。

小规模共享中常见的陷阱

由于作者的实验环境主要基于消费级 GPU（6~24GB），且不使用多节点训练或 Kueue，因此本节并非大规模多租户的证据，而是对小规模共享中容易遇到的陷阱进行了归纳。

• time-slicing 无法隔离内存: replicas增加并 failRequestsGreaterThanOne: true即使阻止单个 Pod 请求多个份额，GPU 内存（VRAM）也不会被划分。如果一个 Pod 用尽了 VRAM，其余的就会因为内存不足（OOM）而崩溃。逐个节点应用通常更安全，因为如果一次性在多个节点上应用，可能会由于容器运行时配置问题导致 GPU 长期无法使用的事故。
• 共享同一张显卡的服务会遭遇任务级故障：如果不同的服务共享同一张显卡，OOM 会导致部分调用失败。如果一个任务由几十个调用组成，调用失败率会以任务为单位放大，导致几乎没有完整成功的任务。其原理可以通过算术验证（用于解释：每次调用 5%，30 次调用时的成功率约为 21%）。最好按显卡数量整理服务数量，并记录优先级的准则，即将用户直接使用的服务排在批处理式生产任务之前。
• 静态放置：如果每个节点只有一个 GPU，副本就不会重叠，因此用 nodeSelector固定节点，并将部署策略设为 Recreate。内存使用率设置（如 vLLM 的 GPU 内存使用率等）有时需要调低，因为驱动程序或 WSL 等环境预先占用的内存可能会导致无法以默认值启动。
• 不信任 Pod 的 GPU 配额设为 0：在运行用户代码的命名空间的 ResourceQuota中放入 requests.nvidia.com/gpu: "0"来阻止 GPU 请求。在下方的“动手尝试”中将验证此行为。

动手尝试

此操作为只读，或者在临时命名空间中结束。在撰写本文时并未实际运行验证。

# 읽기 전용: 노드별 GPU 광고량과 할당 상태
kubectl get node -o custom-columns='NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu'
kubectl describe node NODE | grep -A8 "Allocated resources"

# 임시: 쿼터 0에서 거절, 쿼터 해제 후 Pending 사유 확인 (정리 포함)
pod() { cat <<EOF
apiVersion: v1
kind: Pod
metadata: {name: want-gpu}
spec:
  containers:
  - {name: c, image: busybox, command: ["sleep","60"], resources: {limits: {nvidia.com/gpu: $1}}}
EOF
}
kubectl create ns lab-gpu
kubectl -n lab-gpu create quota gpu-zero --hard=requests.nvidia.com/gpu=0
pod 1 | kubectl -n lab-gpu create --dry-run=server -f -
kubectl -n lab-gpu delete quota gpu-zero
pod 99 | kubectl -n lab-gpu create -f -
kubectl -n lab-gpu describe pod want-gpu | tail -8
kubectl delete ns lab-gpu

第一个请求会因超出配额而被拒绝，第二个 Pod 应保持 Pending 状态并通过事件提示 GPU 不足。双方都不会占用 GPU。请不要在与他人共用的集群中进行 Kueue 练习，而只在一次性集群（如 kind 等）中进行。安装命令（kubectl apply --server-side -f https://github.com/kubernetes-sigs/kueue/releases/download/v0.20.0/manifests.yaml）会向整个集群添加自定义资源（CRD）。

面试中可能会出现的问题

1. 使用默认调度器运行分布式训练会有什么问题？ 可能会按 Pod 单位进行调度，导致部分 Pod 持有 GPU 的同时发生死锁。可以通过 Volcano 的 PodGroup、处于 Beta 阶段的原生 PodGroup，或者 Kueue 的超时机制来弥补，需了解最后一种是基于超时实现的。
2. 如何选择 Kueue 和 Volcano？ Kueue 适合在保留 kube-scheduler 的同时叠加配额、借用和公平共享功能。Volcano 则适合即便需要运营新的调度器，也要强力使用 Gang、队列和拓扑结构的情况。
3. 如何在保障推理服务的同时运行批处理训练？ 为推理服务赋予保障配额和高优先级，并让批处理从 cohort 中借用资源。由于回收时会被抢占，因此需要设计好检查点（checkpoint）和终止宽限期。
4. GPU 共享方式与隔离限制有哪些？ 时间切片（time-slicing）没有内存和故障隔离；MIG 提供硬件隔离，但支持的 GPU 受限；MPS 可能会传播错误。对于不信任的租户，应使用 MIG 或专用节点。DRA 正朝着以属性方式表达这一方向发展，各项功能的成熟度各有不同。
5. 如何根据请求率和延迟目标计算 GPU 数量？ 分别计算吞吐量、利特尔法则（Little's Law）的并发度以及 KV 缓存限制，选择较大的一方，并根据冗余率、N+k 和并行化单位进行提升。观察使用率时，不能只看 utilization.gpu，还要结合 SM（流式多处理器）活跃度和推理延迟指标一起看。

常见误区

• Kueue 不是调度器。它不会将 Pod 放置到节点上。
• 内存不会通过时间切片（time-slicing）被划分。宣传的数量不是隔离数，而是允许同时访问的数量。
• GPU 使用率达到 100% 并不意味着饱和。这可能只是意味着哪怕有一个内核在运行。
• 原生 Gang 调度进入 Beta 阶段并不意味着 Kueue 或 Volcano 变得多余。默认情况下它是关闭的，队列和公平共享是独立的功能。

参考资料

• https://kubernetes.io/docs/concepts/scheduling-eviction/gang-scheduling/
• https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/
• https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
• https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/
• https://github.com/kubernetes/website/tree/main/content/en/docs/reference/command-line-tools-reference/feature-gates
• https://kueue.sigs.k8s.io/docs/overview/
• https://kueue.sigs.k8s.io/docs/concepts/cluster_queue/
• https://kueue.sigs.k8s.io/docs/concepts/preemption/
• https://kueue.sigs.k8s.io/docs/concepts/topology_aware_scheduling/
• https://kueue.sigs.k8s.io/docs/concepts/multikueue/
• https://kueue.sigs.k8s.io/docs/tasks/manage/setup_wait_for_pods_ready/
• https://github.com/kubernetes-sigs/kueue/releases/tag/v0.20.0
• https://volcano.sh/en/docs/podgroup/
• https://volcano.sh/en/docs/queue/
• https://volcano.sh/en/docs/network_topology_aware_scheduling/
• https://github.com/volcano-sh/volcano/releases/tag/v1.15.0
• https://github.com/kai-scheduler/KAI-Scheduler
• https://github.com/kubernetes-sigs/dra-driver-nvidia-gpu
• https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html
• https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-operator-mig.html
• https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-gpus.html
• https://docs.nvidia.com/deploy/mps/architecture.html
• https://docs.nvidia.com/deploy/nvml-api/api/structnvmlUtilization__t.html
• https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/feature-overview.html

外部依据

未能亲自测量的规模以及死锁的实际发生频率已通过以下资料进行确认。论文中的数据直接取自 PDF 原文，未采用仅包含摘要的数据。

在外部资料中，没有直接测量 Gang 死锁发生频率的资料。《MLaaS in the Wild》(NSDI 2022) 的 PDF 文件由于超出大小限制而无法打开，因此没有使用其中的数据。

确认的版本与日期

以 2026-10-05 为准，包括 Kubernetes 1.37.1、Kueue v0.20.0 (2026-09-30)、Volcano v1.15.3 (2026-09-30)、NVIDIA DRA 驱动程序 v0.5.0 (2026-08-19)。作者的实验环境为 Kubernetes 1.34.10、GPU Operator v26.3.3。Gang 调度的实际测量是在一个独立的一次性 k3s v1.36.5 环境中进行的。

未确认的内容：在大规模节点下 Kueue 与 Volcano 的对比（测试仅使用了一个节点、几十个以下的任务）以及混合优先级的队列的长期运行表现、KAI Scheduler 的最新版本与成熟度、同时使用 Kueue 和 Volcano 配置的支持范围、NVIDIA DRA 驱动程序的 GPU 分配功能阶段（README 与文档网站内容不一致）、Kueue TAS 与 NVLink 标签的具体联动、上述命令的实际输出。容量计算属于解释性算术，应当用负载测试来代替。