Jimmy Song – 控制面治理

GPU 资源控制面地图

Jimmy Song — Tue, 30 Dec 2025 05:01:28 +0000

只有厘清控制面与数据平面的分工，才能避免 GPU 平台建设中的常见误区，实现治理与资源兑现的协同。

数据平面各章回答了“一块卡如何被切分、隔离与兑现”；从本章起，问题上升到集群与组织层面：“成百上千块卡、成百上千个租户时，谁来决定谁用哪块、用多久、不够时谁让路”。本章将为全书提供“架构坐标系”。控制面（Control Plane）主要解决队列、配额、优先级、公平性与准入等治理问题；数据平面（Data Plane）则聚焦于设备发现、切分与虚拟化、隔离、可观测与计量等资源兑现环节。通过本章的学习，你将掌握如何定位一个项目所解决的问题层级，以及不同层之间如何组合成端到端方案，避免将不相关的能力混为一谈。

这张地图要解决什么问题

在 GPU 平台建设过程中，最大的认知陷阱之一是将“调度器/队列/配额”与“虚拟化/切分/隔离”混为一谈，并用同一套指标去比较所有项目，最终导致难以落地的结论。

为此，本书采用一张简明但足够有力的分层地图，将 GPU 资源体系拆解为两个正交面：

控制面（Control Plane）：决定“谁能用、何时能用、能用多少、以什么优先级用、用不够时谁让路”。典型能力包括队列化、配额、准入、抢占、策略（公平性/优先级/拓扑偏好）等。Kueue 属于这一类。
数据平面（Data Plane）：决定“GPU 如何被暴露、如何被切分与隔离、如何被实际分配给容器、如何被计量与观测”。典型能力包括 device plugin 分配流程、MIG（Multi-Instance GPU）切分，以及健康检查等。

两者的关系可以类比为：控制面负责“秩序与治理”，数据平面负责“兑现与约束”。如果缺乏控制面，系统可能“能跑但混乱”；如果缺乏数据平面，则“规则很好但无法落地”。

下图展示了控制面与数据平面的核心关系及常见组件的分工：

图 1: GPU 控制面与数据平面架构

GPU 控制面地图：从组织治理到节点分配的五层

下文将通过五个层级，帮助你定位任何组件或方案在整个体系中的位置。这五层自上而下逐步收敛，越往下越接近“实际把 GPU 交到容器手里”。

以下图示展示了五层架构的完整体系：

图 2: GPU 五层控制面架构

Layer 0：工作负载单元（Workload Unit, WU）

在控制面治理中，关注的对象并非“单个 Pod”，而是“一个业务作业单元（Workload Unit, WU）”。这可以是分布式训练的一组 Pod、一个推理服务的扩缩容组、一个 Ray 作业，或是一批离线推理任务。

本层需要明确两个关键问题：

资源请求是“单 Pod”还是“一组 Pod”的原子集合？
如果是集合，能否接受部分启动？还是必须“全有或全无”（典型分布式训练需要这种语义）？

Layer 1：入口治理（Admission & Quota）

本层是控制面的核心“组织治理层”，主要解决“谁先开始、谁等待、谁被抢占”等问题。

以 Kueue 为例，其定位非常清晰：管理配额及作业如何消耗配额，并决定作业何时等待、何时被准入（允许创建 Pod）、何时被抢占（删除已运行的 Pod）。 Kubernetes 官方对 Kueue 的介绍也强调：它是 job queueing controller，按“作业单元”管理批处理作业，并将 Pod 级编排交由 Kubernetes 的稳定组件处理。

本层的核心产出不是“把 Pod 调度到哪”，而是：

形成队列与优先级秩序，避免资源争抢导致的组织冲突
形成可解释的配额承诺（资源承诺/归还、可审计）

Layer 2：全局调度策略（Scheduling Policy）

本层决定“调度算法与策略语义”。可以理解为：当一批作业被允许进入集群后，如何在节点层面实现公平与效率。

Volcano 的官方文档列举了其丰富的调度策略：gang scheduling、公平共享、队列调度、抢占、拓扑感知、回收、回填、资源预留等。这表明 Volcano 更像“策略型调度器/批处理调度系统”，强调作业级语义与策略插件化，而非数据平面的虚拟化机制。

本层主要解决以下典型矛盾：

分布式训练的协同调度（co-scheduling），避免部分成功导致资源碎片
多团队公平性（fair-share / queue）
资源紧张时的抢占与回填，提升总体吞吐

Layer 3：Kubernetes 编排闭环（Pod Orchestration）

无论上层采用 Kueue 还是 Volcano，最终都要回到 Kubernetes 的“Pod 生命周期”闭环：创建、调度、绑定、运行、重试、终止。

Kueue 的一个关键设计点是“准入发生在 Pod 创建之前”：当作业未被准入时，Pod 不会创建，从而避免大量 Pending Pod 堆积在集群中，减少资源死锁与噪声。

本层关注工程可控性：

控制面是否将“等待”表达为可治理对象（Workload/Queue），而非让集群充满 Pending Pod？
控制面能否与现有 workload controller（如 Job 或自定义 CRD）形成稳定集成？

Layer 4：节点分配与设备交付（Node Allocation & Device Handoff）

本层是控制面与数据平面的交界处：调度器决定 Pod 去哪个节点，节点侧负责将“具体 GPU 设备/实例”交付给容器。

Kubernetes 的 device plugin 框架定义了 kubelet 与 device plugin 的交互方式：设备插件以 gRPC 方式注册并汇报健康状态，并在 Allocate 阶段为容器做设备级准备与分配。 NVIDIA 的 Kubernetes device plugin 以 DaemonSet 形式运行，负责在节点上暴露 GPU 数量、跟踪健康状态，并允许运行 GPU 容器。

DRA（Dynamic Resource Allocation）正在改变这一层的游戏规则。Device Plugin 的 Allocate 调用发生在 kubelet 本地，调度器只知道“节点上有 N 块设备”，不知道设备属性和分配策略。DRA 通过 ResourceSlice、DeviceClass、ResourceClaim 等标准 API 对象，把设备信息从节点本地提升到控制面可见，调度器可以基于设备属性（显存、型号、拓扑等）做精确匹配，分配结果经过 API Server 持久化，可被审计和观测。关于 DRA 的详细分析，见 DRA 一章。

需要注意的是，许多“误判根因”都发生在本层：表面上是调度失败，实际问题可能出在 Allocate/设备准备阶段，反之亦然。

项目放置表：常见组件在地图中的定位

下表用于快速定位常见组件或机制在五层地图中的主要归属、核心作用及常见误用场景。

组件/机制	主要所在层	核心回答的问题	常见误用
Kueue	Layer 1（入口治理）	谁等待、谁准入、配额如何被消耗与回收	用它去“提升单节点 GPU 利用率”
Volcano	Layer 2（全局策略）	批处理/训练语义、队列、公平、gang、抢占等	把它当作“GPU 虚拟化”方案
kube-scheduler（原生）	Layer 2/3	Pod 级调度与绑定	期望它理解显存/拓扑等连续变量
Device Plugin（框架）	Layer 4	节点设备发现、健康、Allocate 交付	期望它解决队列与配额治理
DRA（Dynamic Resource Allocation）	Layer 3/4	基于属性声明设备需求，分配可审计	期望它替代隔离机制（隔离仍是数据平面的责任）
MIG（机制）	数据平面（交付到 Layer 4）	把一张 GPU 切成多个隔离实例	期望它解决跨团队公平与准入
NVIDIA k8s-device-plugin	Layer 4（实现）	暴露 GPU、健康、容器可用性	误以为它能自动带来共享与隔离策略

表 1: GPU 控制面与数据平面常见组件放置表

其中，MIG（Multi-Instance GPU）机制可以作为理解“数据平面资源单位”的锚点：它能够将一张支持 MIG 的 GPU 划分为多个彼此隔离的实例，每个实例拥有专用的计算与内存资源。

三种典型架构范式：控制面如何选型

在实际平台建设中，常见的控制面架构范式有三种，分别适用于不同的业务场景。

下图展示了三种范式的特点与适用场景对比：

图 3: GPU 平台三种架构范式对比

范式 A：原生 Kubernetes（最小闭环）

入口治理能力有限，主要依赖 Namespace、ResourceQuota 及组织流程
调度策略以 Pod 级为主
设备交付依赖 device plugin（通常为 NVIDIA plugin）

适用场景：单团队、小规模、以整卡独占为主的早期阶段。

范式 B：Volcano 作为策略调度器（偏“训练/批处理平台”）

强调作业级策略，如 gang、fair-share、queue、preemption 等
常用于训练/批处理密集场景，尤其适合需要协同调度的作业形态

适用场景：训练集群、批处理集群、需要强策略表达的场景。

范式 C：Kueue 作为入口治理（偏“多租户资源治理”）

将“等待/准入/抢占”显式化为治理对象，减少 Pending Pod 噪声
调度器可保持原生，或在策略层做适度扩展，重点建立治理秩序

适用场景：多团队共享资源池、需要配额承诺与可审计的组织型平台。

需要注意的是，这三种范式仅讨论控制面选型，并不决定最终采用 MIG、HAMi 或其他机制作为数据平面。正确的做法是先明确治理模式，再决定资源单位与隔离强度的落地方式。

控制面与数据平面的接口：需要关注的三个“契约点”

在实际系统中，控制面与数据平面之间存在三个关键契约点：

下图展示了这三个契约点在系统中的角色及常见问题场景：

图 4: 控制面与数据平面的三个契约点

详细说明如下：

资源广告（Advertise）：节点将可用 GPU（整卡或 MIG 实例）以资源形式暴露给集群。在 DRA 模式下，这一步由驱动的 ResourceSlice 替代，设备属性（显存、型号、拓扑）也同步暴露到控制面。
调度绑定（Bind）：调度器选择节点并完成 Pod 到 Node 的绑定。DRA 让调度器在这一步就能基于设备属性做过滤，而不是像 Device Plugin 那样只能按整数计数判断。
设备分配（Allocate）：kubelet 调用 device plugin 的 Allocate，完成设备交付与容器启动前准备。DRA 将这一步的结果持久化为 ResourceClaim 状态，经 API Server 审计，而非在 kubelet 本地一闪而过。

许多系统性问题都源于契约未能成立：如控制面认为资源可用，但数据平面交付失败；或数据平面可交付，但控制面缺乏准入/配额，导致整体秩序混乱。DRA 的意义正是让这三个契约点从“节点本地黑盒”变为“控制面可见的一等 API”，从而减少信息不对称导致的系统性问题。

总结

本章提出的“GPU 资源控制面地图”并不追求复杂，而在于为后续所有项目、机制与实验提供一个长期可复用的比较框架：

首先明确：你要解决的是治理秩序（控制面），还是资源兑现（数据平面）。
再选组件：Kueue、Volcano 属于控制面不同侧重点；MIG、设备插件属于数据平面资源单位与交付层。
最后用实验闭环，将“理论优点”转化为“可验收指标”。

下一章将聚焦 Kubernetes 的资源表达与边界：为什么原生语义天然偏向整卡、device plugin 能解决什么/不能解决什么，以及这些因素如何影响后续的虚拟化与共享方案选择。

参考文献

GPU 集群调度问题域：碎片、Gang 与放置策略

Jimmy Song — Fri, 28 Aug 2026 00:00:00 +0000

GPU 调度器的选型讨论常常从工具开始（用 Volcano 还是 Kueue），但工具只是答案的一半：先要理解 CPU 世界不存在的三个问题。

阅读位置：上一章《GPU 资源控制面地图》 · 下一章《Volcano》。

本章是Volcano与Kueue两章的问题域前置：那两章讲“谁提供了这些能力”，本章讲“为什么必须有这些能力”。这些问题的物理背景（拓扑、通信）见互连与集合通信。

问题一：碎片化，闲着的卡拼不出一组

GPU 以整卡为单位、单价高昂，碎片直接等于重金闲置：

节点 A（8卡）: 3×1卡 + 1×2卡 任务 → 剩 3 卡
节点 B（8卡）: 5×1卡 任务 → 剩 3 卡
节点 C（8卡）: 1×6卡 任务 → 剩 2 卡
队列: 一个 4 卡任务 → 所有节点都装不下 → 排队
全集群空闲 8 张卡, 却没有一张能被这个任务使用

两种基本放置策略（与调度器评分函数一一对应）：

装箱（binpack）：任务塞向“最满但装得下”的节点，目标是腾出整节点；
打散（spread）：负载均匀铺开，直觉是“给未来的大任务留整节点”。

反直觉但重要

在小任务为主的流量结构下，装箱通常优于打散：把小任务塞进半满节点，恰好保住了空节点给大任务；打散反而把容量撒得到处都是。“打散保护大任务”这条直觉，只有在任务规模分布偏大时才成立。判定依据应该是你自己集群的任务规模分布与排队数据，而不是直觉。

碎片的三个缓解手段：优先级抢占（杀低优任务凑大任务，前提是被抢任务有 checkpoint）、回填（backfill）（给排队任务找“现在能塞”的位置，避免队头阻塞）、弹性配额（见组合架构）。

问题二：Gang 语义，部分启动等于死锁

分布式训练的经典事故：一个 8 卡任务由 8 个 Pod 组成，原生调度器逐 Pod 处理，资源紧张时只起来了 5 个。这 5 个 Pod 里的 NCCL 在初始化时等待全部 8 个 rank，于是各占着卡互相等；第 6 个 Pod 排在队列里，而它前面的任务又在等这 5 个 Pod 占的卡，锁死了数十张卡谁也不动，直到超时。

Gang（成组）调度的语义是：任务的 minMember 个 Pod 要么全部一起调度，要么全部不调。Volcano 的 PodGroup、Kueue 的 Workload 准入都实现了这一语义。

Gang 的代价是队头阻塞：第一个等不到资源的任务可能拖住后面的任务，所以 gang 必须与 backfill 配对使用。模拟与生产数据的共同结论是：无 backfill 的 gang 在高负载下平均等待可达逐 Pod 调度的 5 倍；而逐 Pod 调度的“零等待”对分布式任务是虚假的：它用死锁换排队指标。

工程经验

“训练任务 hang 在初始化”是缺 gang 语义的标准签名。反过来，上线 gang 后排队变长，先查 backfill 是否启用，而不是回退 gang。

问题三：放置与拓扑的耦合

互连与集合通信给出的三条硬规则在调度层的落地：

张量并行任务需要“同一 NVSwitch 域”的约束，而原生调度器没有这个词汇；
现实践：大任务节点级独占（污点/标签）、注入有序的 CUDA_VISIBLE_DEVICES、跨 MIG/vGPU 实例禁止 TP；
长期方案：DRA 让设备属性与拓扑成为可声明约束。

值得注意的是，软切分会放大这个问题：HAMi 一类方案把“选哪张卡”从 kubelet 上移到自己的调度扩展，这既是机会（可以做拓扑感知的落位），也是责任（不感知就是新的盲区）。

问题域到工具的映射

问题	原生 K8s	Volcano	Kueue	HAMi（数据面协同）
碎片	无策略钩子	装箱/打散插件、backfill	准入期配额借还	卡内份额装箱（落位层）
Gang	无	PodGroup（调度器内）	Workload 准入（调度器外）	无
队列/配额	ResourceQuota（计数）	队列 + 比例公平	ClusterQueue/Cohort 借用	份额配额（gpumem/gpucores）
拓扑约束	无	节点级近似	配合拓扑感知演进	注入设备序（可做拓扑感知）

表 5: 问题域与控制面工具的对应

工具组合的常见形态：Kueue 管队列与配额（租户维度），gang 语义随 Kueue/JobSet 或 Volcano 提供，HAMi 管节点内落位与份额兑现。三者职责不同层，不是三选一，这正是组合架构的主题。

常见误区

误区	真相
Pending 就是资源不够，加机器	先区分：容量不足、碎片拼不出、还是 gang 等待
打散调度天然保护大任务	小任务为主的流量下装箱常常更好，用数据说话
K8s 会处理分布式任务的 all-or-nothing	原生不会，逐 Pod 调度 + NCCL 等待 = 死锁
抢占能解决一切排队	被抢任务没有 checkpoint 就是数据丢失事故
上了 HAMi 就不需要队列系统	份额配额与队列配额在两层，缺一不可

表 6: 调度层的常见误区

总结

GPU 调度的三个特有问题（碎片、Gang、拓扑放置）都源于“昂贵、整卡、分布式”的资源形态，而不是调度器实现不够聪明。看懂问题域之后，Volcano与Kueue的每个特性都可以对号入座；可观测与计量里的排队与碎片指标，也正是为这三个问题提供决策数据。

参考资料

放置策略：标签、污点、优先级与公平性

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

计数回答“多少块”，标签回答“哪种”，拓扑回答“哪个物理实例”；放置策略就是把这些答案写成可审计的 Kubernetes 对象。

标签与亲和性

nodeSelector 简单而精确。节点亲和性（Node Affinity）更富表达力：required 规则保护正确性，preferred 规则表达性能偏好。为架构、内存档位、互连域、可用区和生命周期阶段使用稳定标签。

不要把 GPU UUID 写进应用 YAML

避免在普通应用 YAML 里写死 GPU UUID。平台应暴露资源抽象，让分配器去选择设备，这正是DRA把选择标准变成声明式属性的原因。

污点与容忍

当普通工作负载不应消耗 GPU 节点时给它们打污点（taint）；给属于该池的工作负载加容忍（toleration）。容忍说的是“我可以在这里运行”，不是说“这是最好的节点”，把它与选择器或亲和性配对使用。设备插件路径下的典型组合：GPU 节点打 nvidia.com/gpu: NoSchedule 污点，GPU 工作负载带相应容忍。

优先级与抢占：一件锋利的工具

PriorityClass 让调度器偏袒更重要的 Pod。抢占（preemption）可以驱逐低优先级 Pod 腾出空间，但结果就是干扰。把它用于明确的业务关键性，并配合配额、检查点、优雅终止和容量余量。一个更大的数字不会让工作负载更正确。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
 name: ai-serving-critical
value: 100000
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "Critical online inference; use sparingly"

对批量训练，排队与成组准入（gang admission）可能比抢占正在运行的作业更有用（Volcano 与 Kueue 的核心语义，见控制面各章）；对在线推理，应预留容量，而不是假设抢占能满足延迟 SLO。

配额是社会架构

一个共享 GPU 集群是一个多租户系统。ResourceQuota、命名空间所有权、排队策略、公平份额调度、计费返还（chargeback）或展示计费（showback）定义了谁能消耗稀缺容量。没有这些控制，最激进的工作负载就会变成调度器意外选出的产品经理。

apiVersion: v1
kind: ResourceQuota
metadata:
 name: gpu-team-quota
 namespace: ai-team
spec:
 hard:
 requests.nvidia.com/gpu: "8"
 limits.nvidia.com/gpu: "8"
 requests.cpu: "64"
 requests.memory: 512Gi

总结

放置策略是控制面的“软”层：它不改变资源本身，只决定资源流向谁、流向哪里。标签防错配、污点防侵占、优先级保关键、配额保公平；四件工具与调度问题域的硬约束共同构成完整的放置语言。

Volcano：批处理语义与 AI 作业调度

Jimmy Song — Tue, 30 Dec 2025 05:03:16 +0000

真正可治理的 GPU 平台，必须让“资源单位”与“作业秩序”协同演进。Volcano 补齐了原生 Kubernetes 在 AI 训练和批处理场景下的调度语义缺口，让平台从“能跑”走向“可运营”。

Volcano 解决的是“秩序”，不是“资源单位”

在 GPU 场景下，Volcano 的核心价值在于为一组 Pods 提供作业级别的调度、排队、抢占、配额与公平治理能力，而不是实现 GPU 的共享或切分（这属于数据平面，如 MIG、HAMi、驱动与运行时等）。具体来说：

数据平面决定：你能把一张卡变成什么“资源单位”（整卡 / MIG / vGPU / time-slicing 等），以及隔离、干扰、可观测的下限。
控制面（Volcano） 决定：当资源紧张、队列拥塞、多个团队竞争、作业有拓扑与同步约束时，系统如何做准入、排序、成组调度、抢占与公平。

这两者正交但可组合。真正可交付的 GPU 平台，通常必须同时具备二者。

原生 Kubernetes 的调度语义缺口

AI 训练和分布式作业对调度有特殊需求。原生 Kubernetes 调度目标偏向“尽快把单个 Pod 放进去”，而 AI 训练常常要求“一个作业的一组 Pods 必须一起满足条件”。典型缺口包括：

Gang / All-or-nothing：分布式训练需要 N 个 worker/ps/launcher 同时就绪，否则要么空转，要么失败重试。
队列与配额：训练是典型的突发与长尾资源消耗，必须先排队、再准入，而不是无限制地把 Pending 堆在集群里。
优先级与抢占：同一集群既跑训练也跑推理/评测时，需要可解释的优先级与抢占策略。
公平性与组织边界：以团队、项目、租户维度做公平分享与“可审计”的资源承诺。
作业级生命周期：失败策略、重试、扩缩容、最小可运行规模等是作业语义，而不是 Pod 语义。

Volcano 的核心就是补齐这些“批处理语义”，并将其变成可运营的控制面能力。

Volcano 的控制面抽象：从 Pod 到 Job/Queue

Volcano 将调度对象从单 Pod 提升为“作业与队列”，常用抽象可以理解为三层：

Job / Task（作业与任务组）

在 Volcano 中，Job 描述一个批处理作业，由多个 Task 组成。Task 通常是一组同构 Pod（如 worker x 8），可配置最小副本数、重试策略等。

对于 AI 场景，Task 往往映射为 launcher、worker、parameter server、evaluator 等角色。

PodGroup（成组调度的原子单元）

PodGroup（或等价的 gang 语义）是 Volcano 区别于原生调度的关键。只有当满足 PodGroup 的最小资源、最小成员条件时，才会整体进入运行态，否则保持等待，避免“部分启动导致集群空转”。

这对 GPU 尤其关键。例如，8 卡训练只拿到 2 卡就先跑起来，往往会在 NCCL 或同步点反复超时。

Queue / Quota / Priority（秩序的三要素）

Queue：显式排队与准入的边界，通常映射为团队、项目或环境。
Quota：队列的资源上限、保证与借用规则（不同部署会有不同实现深度）。
Priority：在队列内与队列间做排序，并通过抢占将优先级落到执行层。

你可以把它们视为一个“资源市场”的规则集：谁先用、谁能借、谁必须让。

下图展示从单个 Pod 调度到作业级别调度的演进。队列与配额层（Queue/Quota/Priority）提供资源市场的规则集，决定谁先用、谁能借、谁必须让；成组调度层（PodGroup/Gang Scheduling）确保满足最小条件才整体运行，避免部分启动导致集群空转；作业与任务层（Job/Task）将分布式训练等作业描述为多个 Task 组（如 worker、launcher、parameter server）。Volcano 通过这三层抽象，实现了从能跑到可运营的治理能力升级。

图 1: Volcano 的控制面抽象：从 Pod 到 Job/Queue

Volcano 的调度能力：策略与插件化

Volcano 的调度能力通常以策略和插件组合呈现，常见能力包括：

Gang scheduling：满足最小规模才准入，否则持续等待。
Backfill：在不破坏高优先级作业可启动性的前提下，用小作业填空，提升整体利用率。
Preemption（抢占）：当高优作业需要资源时，按策略驱逐低优作业。
DRF/公平分享：以多资源维度（CPU、内存、GPU）做相对公平。
拓扑/亲和性协同：与 node/pod affinity、拓扑约束结合，尽量把通信密集型训练放到更优拓扑上。

需要强调边界：Volcano 不理解 GPU 干扰与隔离细节，只消费 K8s 资源模型中暴露的资源单位与约束。因此，数据平面暴露的资源单位越可声明、越可计量，Volcano 的控制面治理就越可验证。

下图展示 Volcano 的 5 大核心调度能力。Gang Scheduling（成组调度）确保满足最小规模才准入，避免部分启动；Backfill（填空调度）用小作业填缝提升整体利用率；Preemption（抢占）按策略驱逐低优作业；DRF/Fair Share（公平分享）提供多资源维度的相对公平；Topology Affinity（拓扑亲和性）优化通信密集型训练拓扑。图中特别强调了 Volcano 的能力边界：它不理解 GPU 干扰与隔离细节，只消费 K8s 资源模型，需要与数据平面协同才能实现端到端闭环。

图 2: Volcano 的核心调度能力

与 GPU 数据平面的组合方式

将 Volcano 放回本书的体系中，它需要与数据平面协作才能形成端到端闭环。以下是三种典型组合方式：

整卡分配（最小集成，最强确定性）

数据平面：NVIDIA device plugin 暴露整卡资源（nvidia.com/gpu）。
控制面：Volcano 提供队列、gang、抢占能力。
适用场景：训练集群起步期、多租户边界强、对干扰容忍度低。

MIG（硬切分：强隔离但单位离散）

数据平面：将 GPU 切成离散 MIG profile，暴露为多种资源（如不同 profile 的资源名或标签）。
控制面：Volcano 负责“作业整体满足 N 个 profile”与队列治理，调度目标变成“匹配离散资源池”。
适用场景：在线推理或多租户训练需要强隔离，但需接受碎片化与重配置运维成本。

HAMi / 共享型虚拟化（可声明共享，治理难度上升）

数据平面：将共享从“能跑”升级到“可声明、可计量、可隔离（至少部分）”。
控制面：Volcano 仍负责队列、优先级、作业语义，但需要依赖数据平面提供的计量与隔离信号，否则抢占与公平会变成“不可验证的承诺”。
适用场景：推理、评测、轻量训练的高密度混部，但必须直面 P99 干扰、噪声邻居与观测闭环。

一句话总结：Volcano 决定“谁先跑、跑多少、能不能一起跑”；数据平面决定“跑起来之后会不会互相影响、影响能否被观测与治理”。

下图展示 Volcano 与不同数据平面技术的三种典型组合。方案 A（整卡分配）：NVIDIA device plugin 暴露整卡 + Volcano 提供队列/gang/抢占，适合训练集群起步期、多租户边界强、对干扰容忍度低的场景；方案 B（MIG）：GPU 切成离散 MIG profile + Volcano 负责作业整体满足 N 个 profile，适合在线推理或多租户训练需要强隔离的场景；方案 C（HAMi/共享型虚拟化）：将共享升级为可声明、可计量、可隔离 + Volcano 提供队列/优先级，适合推理、评测、轻量训练的高密度混部场景。三种方案的核心差异在于数据平面的隔离能力与 Volcano 的治理能力的协同程度。

图 3: Volcano 与 GPU 数据平面的三种组合方式

典型 AI 场景下的使用模式

在实际 AI 平台中，Volcano 的应用模式主要包括以下几类：

分布式训练

分布式训练是最典型的应用场景。常见做法包括：

用 PodGroup/Job 把 worker、launcher 绑定成一个调度原子。
用 Queue 把团队、项目隔离，配合 Priority 处理紧急训练与回归任务。
配合 backfill 提升利用率：小作业填缝，但不阻塞大作业。

关键验收点：

“最小可运行规模”是否被严格执行，避免部分启动。
抢占是否可解释、可回溯（谁被抢、为什么、代价是什么）。
训练失败重试是否造成队列震荡与资源抖动。

评测/批量推理

评测通常是大量短作业，最怕排队开销大、抢占导致尾部变差。常见策略：

优先选择 backfill 与更温和的抢占。
在队列里设置更细的优先级层级，避免大规模短作业把长作业“饿死”。

与在线推理共存（混部集群）

这是最容易“概念上想得通，现实里翻车”的场景：

Volcano 可以把推理视为高优先级队列或作业，必要时抢占训练。
但如果数据平面没有足够隔离与计量，推理的 P99 抖动往往不是靠“抢占语义”能彻底解决的。

因此更推荐：在线推理优先靠隔离与资源单位保证（如 MIG、强隔离或专用池），Volcano 主要用于训练与批处理域。

运维与落地：让“策略”变成“可运营的规则”

在落地 Volcano 时，建议关注“规则是否可验证”，而不是功能是否齐全。具体包括：

准入与队列治理：是否有明确的队列边界，默认队列是否会成为黑洞。
资源承诺模型：Quota 是硬上限、软保证还是可借用？对应的 SLO、成本模型是什么？
抢占策略：抢占的触发条件、优先级边界、被抢作业的恢复成本（checkpoint、重跑）是否可接受。
观测闭环：至少要能回答三类问题：
- 为什么某作业排队这么久（准入、资源不足、拓扑约束、配额）？
- 为什么被抢占（优先级、队列规则、资源回收）？
- 真正的 GPU 利用率是否提升，还是只是在“排队层面看起来更有秩序”？

如果这些问题回答不清楚，Volcano 只会把复杂性从“调度器的 Pending”搬到“平台团队的工单”。

Volcano 在 GPU 平台体系中的位置

Volcano 是控制面：提供批处理语义（队列、优先级、公平、准入、成组调度、抢占）。
它不解决 GPU 的切分、虚拟化、隔离，但决定这些能力如何被组织起来交付。
在端到端体系中，Volcano 与 MIG、HAMi 等数据平面能力组合后，才可能形成“既能跑、又可治理、还能验收”的 GPU 平台。

下一章将对比 Kueue：当你更希望“沿用原生 K8s API 与生态”时，控制面该如何演进，以及 Volcano、Kueue 在不同组织与平台路径下的取舍边界。

总结

Volcano 通过补齐原生 Kubernetes 在 AI 训练和批处理场景下的调度语义缺口，使平台具备了队列、优先级、公平、准入、成组调度、抢占等可运营的控制面能力。它与数据平面能力协同，帮助构建真正可治理、可观测、可交付的 GPU 平台。实际落地时，需关注规则的可验证性和治理闭环，才能实现平台的高效与可持续运营。

NUMA 感知的 GPU 调度：三个管理器与调度器失明

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

两个完全相同的 Pod，一个达标、一个慢 35%，没有报错也没有 OOM，唯一的区别是 GPU 和 CPU 落在了哪个 NUMA 节点上。

无声的性能杀手

下面这个场景每天都在配置不当的 GPU 集群里上演：两个完全相同的 Pod，同样的模型、同样的 GPU 型号、同样的资源请求。一个达到预期吞吐，另一个慢 35%。这就是 NUMA 问题：除非专门配置拓扑管理器栈，它对标准 Kubernetes 完全不可见。物理层面的背景见作为拓扑的服务器。

三个管理器：CPU、内存、设备

Kubernetes 通过 kubelet 上三个相互独立、由拓扑管理器（Topology Manager）协调的管理器来控制 NUMA 对齐：

CPU 管理器（cpuManagerPolicy: static）： 默认 none 策略下，任何容器都可跑在任何核心上。启用 static 后，Guaranteed QoS 等级（CPU 的 request == limit 且为整数值）的 Pod 被独占式地钉在特定核心上，这些核心从共享池移除。状态记录在 /var/lib/kubelet/cpu_manager_state。
内存管理器（memoryManagerPolicy: Static）： 强制 NUMA 本地内存分配，与拓扑管理器通信报告哪些 NUMA 节点有足够预留内存。关键点：必须同时配置 reservedMemory 覆盖操作系统在各 NUMA 节点上的内存，否则内存管理器会拒绝本应放得下的工作负载。
设备管理器（带拓扑提示的设备插件）： NVIDIA 设备插件通过 ListAndWatch 的 TopologyInfo 字段报告每块 GPU 的 NUMA 亲和性，拓扑管理器收集这些提示。

拓扑管理器：协调者与策略

拓扑管理器在 Pod 准入时（先于容器创建）运行，并基于 NUMA 对齐能否达成来决定接纳还是拒绝 Pod。它不会传送内存，也不会修复糟糕的硬件设计；它协调的是必须全部给出有用提示的各个组件。

# 追求最严格 NUMA 对齐的 kubelet 配置
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cpuManagerPolicy: static
topologyManagerPolicy: single-numa-node  # 最严格：全有或全无
topologyManagerScope: pod  # 作用于整个 Pod（而非逐容器）
memoryManagerPolicy: Static
reservedMemory: # 内存管理器必配
- numaNode: 0
 limits:
 memory: 4Gi  # NUMA 0 上为 OS/系统预留
- numaNode: 1
 limits:
 memory: 4Gi

策略	行为	适用场景
`none`	默认。不强制 NUMA 对齐	开发集群、非延迟敏感工作负载
`best-effort`	偏好对齐，无法对齐也继续	有 NUMA 收益即好的混合负载
`restricted`	对齐失败则拒绝 Pod，报 TopologyAffinityError	性能敏感的生产推理
`single-numa-node`	最严格：所有资源必须来自同一 NUMA 节点	延迟关键型推理、多路 HPC

表 1: 拓扑管理器策略速查

调度器失明问题与修复

这是每个团队都会踩的根本缺口：拓扑管理器运行在 kubelet 上，只在节点层面强制对齐，而此时调度器已经选好了节点。如果调度器挑了一个无法满足 NUMA 对齐的节点，Pod 被调度过去后立刻被拓扑管理器以 TopologyAffinityError 拒绝。Pod 卡在 Pending 永不启动，集群陷入“调度器反复尝试同样几个节点、节点反复拒绝”的循环。

真实的生产故障模式

集群有 4 个 GPU 节点，每个 8 块 GPU 按 4+4 分布在 2 个 NUMA 节点上。你请求一个 4 GPU、single-numa-node 策略的 Pod。调度器看到 8 块可分配 GPU，随意挑了一个节点；但准入时，拓扑管理器发现匹配的 NUMA 节点上只剩 2 块空闲 GPU。Pod 被拒，如此循环，直到某个 NUMA 节点被完全腾空，你的训练作业永远开不了工。

修复需要三个部件协同：

NFD 拓扑更新器（Node Feature Discovery Topology Updater）： DaemonSet，从 kubelet 的 PodResources API 读取按 NUMA 划分的资源可用性，发布为 NodeResourceTopology（NRT）自定义资源，约每 60 秒更新。
NRT 调度器插件： 二级调度器或调度器插件，读取 NRT 对象作为过滤和打分依据，只在准入前把 Pod 放到 NUMA 对齐可满足的节点上。
KAI Scheduler（或类似物）： NVIDIA 的开源调度器，读取 NRT、实现成组调度，在集群层面做出 NUMA 感知放置（深入介绍见NVIDIA × CNCF）。

# 检查 NodeResourceTopology 对象
kubectl get noderesourcetopologies.topology.node.k8s.io
kubectl get nrt gpu-node-01 -o yaml | head -60
# Zones:
# - name: node-0 # NUMA 节点 0
# resources:
# - name: nvidia.com/gpu
# capacity: '4'
# available: '2' # 2 空闲，2 已分配

总结

NUMA 治理分两半：kubelet 内的三个管理器保证“放进来就对齐”，NRT 与拓扑感知调度器保证“别放到对不齐的节点”。只配前者不配后者，就会收获 Pending 循环；两者都配齐，拓扑才从性能陷阱变成可声明的约束。排障入口见故障模式与排障手册的 TopologyAffinityError 一节。

参考资料

Kubernetes 文档：Control Topology Management Policies on a node。

Kueue：配额、准入与资源治理的控制面

Jimmy Song — Tue, 30 Dec 2025 05:02:07 +0000

控制面治理是 GPU 平台化的核心，Kueue 让资源分配变得有序、可预测、可审计。

为什么需要 Kueue：从“能跑”到“能治理”

在单团队、小规模的 GPU 集群中，通常只需关注任务能否被调度：安装好 Device Plugin，配置 nvidia.com/gpu: 1，剩下交给调度器即可。但在多团队、多租户、混合负载（训练/推理/批处理/交互）的实际场景下，问题会迅速从“能不能跑”转变为“如何有秩序地跑”。

常见的治理需求包括：

谁能用？（团队/项目/环境的授权边界）
何时能用？（排队、公平、抢占、SLA）
能用多少？（配额、借用、上限、突发）
用完怎么归还与统计？（资源承诺、计量、对账）

如果缺乏“秩序与契约”，平台会反复出现以下混乱现象：

某团队临时加任务导致集群资源被挤爆，其他团队即使有业务优先级也无法及时调度。
资源被“先到先得”长期占用，高价值或紧急作业只能等待。
表面上各团队未超配额，实际 GPU 却被长期占用，平台方难以解释资源紧张的原因。

Kueue 的核心价值在于将“调度之前的治理”产品化：在资源真正分配到节点和设备之前，先完成资源的准入（admission）与承诺（reservation/assignment），让所有人对“可用资源”和“排队规则”形成共同预期。

Kueue 在系统中的位置：决定“谁先拿到切分后的资源”

在平台架构中，数据平面负责设备发现、切分/虚拟化（如 MIG、共享方案）、隔离、可观测与计量；控制面则关注队列、配额、优先级、公平性、准入与治理。

Kueue 属于控制面组件。它不负责将一张 GPU 切分为 MIG，也不直接限制容器的 SM 或显存，这些属于数据平面和驱动栈的范畴。Kueue 关注的是：在有限的可用资源下，这次机会应该分配给谁？

因此，Kueue 与 MIG/HAMi 等数据平面方案是互补关系：

可以用 MIG 提供强隔离的离散资源单位。
用 HAMi 提供可声明的共享单位。
再用 Kueue 实现多团队间资源的可控、可预测、可审计流转。

关键概念：将“排队”和“配额”显式建模

Kueue 的核心思想是：将调度请求拆分为两步：先排队与准入，再进行实际调度。

以下是 Kueue 的主要对象及其角色：

LocalQueue：团队/命名空间的入口队列

用户作业提交到某个 namespace，挂载在对应的 LocalQueue 下。
可理解为“团队的提交入口”。

ClusterQueue：全局资源池与配额承诺

定义配额、借用与公平性规则。
把集群资源（如 GPU/CPU/内存/自定义资源）抽象为可治理的池，并分配份额给不同租户。
常见模式是多个 LocalQueue 指向同一个 ClusterQueue，实现“入口不同但共享全局规则”。

Workload：等待准入的资源申请单

用户提交的 Job / RayJob / PyTorchJob 等作业对象会被映射为可治理的 Workload。
Workload 记录作业的资源需求（如 GPU 数量、Pod 组、最小规模等），便于比较、排队和决策。

ResourceFlavor：资源的“口味”建模

在 GPU 场景下，“1 张 GPU”并不等价，可能有如下差异：

A100 与 H100
MIG 1g.10gb 与 7g.80gb
是否允许共享、是否开启特定模式
是否位于特定可用区/机架/网络域

ResourceFlavor 的作用是将资源差异显式化，使准入与配额可以针对不同“口味”的资源分别管理，而不是将所有 GPU 混为一谈。

Cohort / Borrowing / Preemption：公平与弹性的三件套

在实际平台中，单纯“硬配额”会导致资源浪费，单纯“先到先得”又会带来混乱。Kueue 通常结合以下三种能力：

公平性（Cohort/共享规则）：多个队列间按规则共享或竞争资源。
借用（Borrowing）：队列未用完配额时，其他队列可借用以提升利用率。
抢占（Preemption）：高优先级作业需要资源时，可回收低优先级作业已承诺资源，保障关键业务。

下图展示 Kueue 的两步调度流程和核心概念。第一步（排队与准入）：Workload 提交到 LocalQueue（团队/命名空间的入口队列），LocalQueue 指向 ClusterQueue（全局资源池与配额承诺），ResourceFlavor 对不同类型的资源（如 A100 vs H100、MIG profile 差异）进行建模。第二步（实际调度）：准入后的作业由 kube-scheduler 或 Volcano 进行实际调度。底部展示公平与弹性三件套（Cohort 队列共享、Borrowing 配额借用、Preemption 抢占机制）。Kueue 的核心价值在于将调度之前的治理产品化：先完成资源的准入与承诺，再进行实际调度。

图 1: Kueue 的核心概念：从排队到准入的两步调度

典型治理场景：Kueue 解决哪些平台问题

Kueue 关注的不是“某个作业如何跑得最快”，而是“所有作业如何有秩序地运行”。以下是典型治理场景：

多团队配额：将“应该能用多少”写进系统

团队 A：保障 20 张 GPU
团队 B：保障 10 张 GPU
平台预留：5 张 GPU 用于紧急事件或在线推理

配额显式化后，平台可以回答：

“为什么我现在排队？”（因为当前申请超出可用份额。）
“我什么时候能拿到？”（队列有明确顺序与策略，体验可预测。）
“平台是否偏心？”（可用审计和指标证明资源承诺流向。）

准入（Admission）：将“能不能跑”前置到控制面

在原生 Kubernetes 中，作业失败往往发生较晚：Pod 创建后长时间 pending，才发现资源不足或条件不满足。Kueue 的准入机制类似“入场券”：

先判断是否有足够配额/可承诺资源。
只有获得准入许可，作业才进入实际调度阶段。

这样，用户能明确了解 Pending 原因，平台也能将治理逻辑集中在控制面，减少调度失败和人工干预。

借用与回收：平衡利用率与秩序

理想的 GPU 平台既要高利用率，也要强秩序。借用机制提升利用率，抢占/回收机制保障秩序：

平时可借用闲置配额，减少资源空转。
紧急时高优先级业务可回收资源，兑现保障。

这让平台从“静态分田地”升级为“动态经济系统”，既避免长期浪费，也防止关键时刻失控。

优先级与可预测体验：制度化冲突管理

GPU 平台治理的难点在于冲突管理。Kueue 通过优先级、策略和准入规则，将冲突管理制度化：

在线推理（强时延 SLO）与离线训练（吞吐优先）
生产事故修复与常规实验
关键客户项目与内部探索

这些都能通过系统规则落地，避免平台治理沦为“谁嗓门大谁赢”。

下图展示 Kueue 的 7 大核心治理能力。Quota（配额管理）提供集群级配额定义和资源上限；Admission（准入控制）基于配额进行准入和等待队列管理；Borrowing（配额借用）允许跨队列借用闲置配额以提升利用率；Preemption（抢占机制）基于优先级抢占保证高优作业；Cohort（队列共享）支持多队列共享资源池和公平性策略；ResourceFlavor（资源建模）区分资源类型支持异构 GPU；Fair Sharing（公平分享）提供多租户资源公平分配。图中特别强调了 Kueue 的能力边界：它只负责调度前的准入与配额管理，不做实际调度，需要与 kube-scheduler 或 Volcano 协同工作形成完整的调度流程，并依赖数据平面提供资源单位和可观测信号。

图 2: Kueue 的治理能力：配额与公平性的产品化

与 Volcano 的关系：正交但可组合

Volcano 擅长批处理语义、作业级调度、gang scheduling 等，补齐原生 Kubernetes 在 AI 训练/分布式作业表达上的不足。

二者的关系可以总结为：

Volcano：负责“怎么排座位”的调度（作业级策略、批处理、并行组、调度算法）。
Kueue：负责“谁能进场、能占多少座位”的门禁与秩序（准入、配额、借用、抢占、治理）。

常见组合方式：

用 Kueue 负责准入与资源承诺（控制面治理）。
用 Volcano 或 kube-scheduler 负责已准入 Pod 的实际调度（调度执行）。

这体现了“先治理，再调度”的解耦路径。

下图展示 Kueue 与 Volcano 的两种演进路径对比。Kueue（左侧）：核心理念是两步调度（先准入、再调度），沿用原生 K8s API 与生态；优势包括与 K8s 原生深度集成、支持 Job/Set/ReplicaSet 等原生资源、配额管理更精细、云厂商路线一致；局限是不支持复杂的 Gang Scheduling、需要配合其他调度器、批处理语义不如 Volcano 丰富；适用于云原生环境和多租户平台。Volcano（右侧）：核心理念是一站式批处理调度，提供完整的队列、Gang、抢占语义；优势包括完整的批处理调度语义、支持复杂的 Gang Scheduling、Backfill 和拓扑亲和性等高级特性、AI 训练场景验证充分；局限是与原生 K8s 调度器是替代关系、API 自定义学习成本高、云厂商集成度不如 Kueue；适用于 AI 训练集群和批处理平台。底部选型建议：重视 K8s 原生集成选择 Kueue，需要完整 Gang Scheduling 选择 Volcano，也可以组合使用形成完整体系。

图 3: Kueue vs Volcano：治理调度的两种演进路径

GPU 平台落地时必须思考的三件事

资源口径：治理对象是“卡”、还是“切片”、还是“共享份额”？

Kueue 的配额需绑定明确的资源单位。GPU 单位在不同数据平面方案下会变化：

整卡：nvidia.com/gpu
MIG：按 MIG profile 形成离散资源单位
共享：如 vGPU 份额、显存份额、时间片份额等

口径不清，治理难以落地。需明确平台对外承诺的最小单位、是否可动态调整、是否允许混用，这决定配额的可理解性、可执行性和可审计性。

Flavor 设计：异构不可避免，混合会带来“隐性不公平”

当 H100 和 A10 混在同一池，“10 张 GPU 配额”对不同团队意义完全不同。ResourceFlavor 让差异显式化，使配额和公平性建立在正确维度上。

观测与计量：控制面“承诺”需对齐数据面“实际”

控制面能说明“承诺了多少”，但平台还需对齐“实际使用了多少”。稳健的闭环通常包括：

控制面（Kueue）：提供准入、配额占用、等待时长、抢占/回收等数据。
数据平面（驱动/隔离/计量）：提供实际 GPU 利用率、显存占用、带宽/干扰、真实 GPU-hours。

两者对齐后，平台才能实现配额、成本核算、容量规划和体验改进。

边界与常见陷阱：Kueue 不是“万能 GPU 管理器”

需要明确 Kueue 的边界，避免落地时产生误解：

当前版本 Kueue 不提供隔离能力，隔离需依赖 MIG、vGPU、容器/驱动栈等数据平面方案。
Kueue 不替代调度器，只负责准入与承诺，Pod 的实际调度仍依赖 kube-scheduler/Volcano 等。
Kueue 不能解决所有碎片问题，若资源单位离散（如 MIG profile），碎片需通过数据平面策略和容量工程缓解，Kueue 仅能在规则层面减少无意义占用。

常见失败模式包括：只引入 Kueue 却未明确资源单位和计量口径，导致配额看似严格但实际体验混乱；或数据平面已做切分共享，却缺乏准入与配额，最终系统被“合法但失序”的用法拖垮。

总结

Kueue 让 GPU 从“稀缺硬件”升级为“平台资源”，平台治理的核心不在于切分技术本身，而在于：

资源能否制度化分配（配额）
资源竞争是否有清晰秩序（队列/优先级/公平）
使用是否可预测、可审计（准入与统计）
利用率能否在秩序基础上优化（借用与回收）

Kueue 正是将这些能力落地到控制面的关键组件，让 GPU 资源从“抢得到”走向“分得清、用得稳、算得明”。

下一章将从“单组件”视角提升到“端到端组合”，探讨如何将数据平面（MIG/HAMi 等）与控制面（Volcano/Kueue 等）组合成可交付的参考架构，并通过实验和指标验证架构取舍。

NVIDIA GPU Operator：逐组件解析与全生命周期

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

GPU Operator 做的事可以一句话概括：把 GPU 节点的 Day-2 运维从“每台机器一遍的手工程序”变成“一个 YAML 声明的期望状态”。

Operator 究竟改变了什么

Operator 把期望的集群状态变成一个调谐循环（reconciliation loop）。平台描述策略，Operator 创建并守护组件，不必再在每台节点上手工安装驱动、设备插件、特性发现和遥测 DaemonSet。这提升了一致性，也让升级意图变得可见。

它也引入了一类新的故障：期望状态在某套版本矩阵里有效，在另一套里就是错的。调谐不能替代预检（preflight），升级仍要走金丝雀流程。

出现之前是什么样

在 GPU Operator（2020 年）之前，把一个 GPU 节点接入集群要在每台新节点上执行一套手工程序：安装匹配的内核驱动、安装并配置 Container Toolkit 与 containerd/CRI-O、手工部署设备插件 DaemonSet、手工配置 DCGM、MIG 场景还要逐卡分区；新增节点全部重来，升级驱动要排空、卸载、重装、重启。在 50 节点的集群里这是数周的苦役，而节点间驱动版本不一致会让分布式训练出现诡异的 NCCL 故障。

手工之痛的量化

没有 GPU Operator 的 GPU 集群团队，估计要把 60–80% 的 GPU 基础设施工程时间花在 Day-2 运维（驱动管理、节点维修、配置漂移），而不是工作负载优化上。

ClusterPolicy：唯一的配置点

ClusterPolicy 是 GPU Operator 安装的自定义资源定义（CRD），是配置整个 GPU 栈的唯一 YAML 文件：

# ClusterPolicy 骨架（简化）
apiVersion: nvidia.com/v1
kind: ClusterPolicy
metadata:
 name: cluster-policy
spec:
 driver:
 enabled: true
 version: '570.86.10' # 锁定驱动版本
 rdma:
 enabled: false # GPUDirect RDMA 时启用
 toolkit:
 enabled: true
 version: 'v1.17.3'
 devicePlugin:
 enabled: true
 version: 'v0.17.0'
 config:
 name: 'time-slicing-config' # 可选共享配置
 dcgmExporter:
 enabled: true
 serviceMonitor:
 enabled: true # Prometheus 抓取
 migManager:
 enabled: true
 config:
 name: 'default-mig-parted-config'
 gfd:
 enabled: true # GPU Feature Discovery
 nfd:
 enabled: true # Node Feature Discovery

八个组件的严格部署顺序

顺序	组件	为何是这个顺序
1	Node Feature Discovery（NFD）	必须先给节点打 OS、内核、PCI 设备信息标签；驱动选择依赖 OS 标签
2	NVIDIA 驱动容器	加载内核模块；必须先于其他一切能与 GPU 对话的组件
3	NVIDIA Container Toolkit	配置 containerd/CRI-O；必须先于 GPU Pod 存在
4	GPU Feature Discovery（GFD）	经 NVML 读取 GPU 属性（需驱动运行），打型号与 CUDA 能力标签
5	NVIDIA 设备插件	向 kubelet 注册 `nvidia.com/gpu`（需驱动 + 工具包）
6	DCGM + DCGM Exporter	经 NVML 采集指标，暴露 Prometheus 端点
7	MIG Manager	给 GPU 分区；在其余组件全部健康后应用
8	GPU Operator Validator	跑测试 CUDA 工作负载，端到端确认整栈可用

表 1: GPU Operator 组件部署顺序

理解这个顺序对排查启动故障必不可少：驱动容器没起来，后面全部白搭；Validator 是最后一块拼图。

组件要点

NVIDIA 驱动容器：特权 init 容器把 nvidia.ko 加载进主机内核，随后常驻防止模块卸载。节点可以带着纯净 OS 加入集群并自动获得正确驱动；支持开源内核模块（nvidia-open，Turing+ 默认，MIT 许可）。
NVIDIA Container Toolkit（托管）：自动配置各节点的 nvidia-container-runtime（原理见NVIDIA Container Toolkit），CDI 模式下还生成 CDI 规范。
NVIDIA 设备插件（托管）：暴露 nvidia.com/gpu 与 MIG 切片资源，通过 ConfigMap 配置时间切片副本与 MIG 策略，并支持 DRA 驱动模式。
DCGM + DCGM Exporter：暴露 50+ GPU 指标（9400 端口）、Xid 错误追踪与健康诊断（dcgmi diag），是可观测体系的数据源。
GFD：把 GPU 型号、显存、计算能力等打成节点标签，放置策略的 nodeSelector 用的正是这些标签，如 nvidia.com/gpu.product: NVIDIA-H100-80GB-HBM3。
NFD：探测硬件特性并打标签，同时驱动 NUMA 感知调度所需的 NodeResourceTopology 更新器（见NUMA 感知调度）。
MIG Manager：监视 MIG ConfigMap 变化，重配期间封锁/排空节点、重配每卡 MIG 实例、以新画像重启设备插件再解锁（与MIG章的运维代价分析对应）。
Validator：运行 CUDA 向量加测试，节点通过才标记验证完成，是生产负载落地前的最后一道闸。

Helm 安装与升级

# 安装（v26.3.0 为例）
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia && helm repo update

# 检查 NFD 是否已在运行（避免重复部署）
kubectl get nodes -o json | jq '.items[].metadata.labels | keys |
 any(startswith("feature.node.kubernetes.io"))'

helm install --wait --generate-name \
 -n gpu-operator --create-namespace \
 nvidia/gpu-operator \
 --version=v26.3.0

# 驱动已预装的场景（AKS/GKE/EKS 常见）
helm install --wait --generate-name \
 -n gpu-operator --create-namespace \
 nvidia/gpu-operator \
 --set driver.enabled=false

# 升级：CRD 先行（Helm 不会自动升级 CRD）
export RELEASE_TAG=v26.3.0
kubectl apply -f https://gitlab.com/nvidia/kubernetes/gpu-operator/-/raw/\
$RELEASE_TAG/deployments/gpu-operator/crds/nvidia.com_clusterpolicies_crd.yaml
helm upgrade gpu-operator-release nvidia/gpu-operator \
 -n gpu-operator --version $RELEASE_TAG --disable-openapi-validation

金丝雀升级循环与最小验证阶梯

冻结当前节点镜像与兼容性矩阵。
升级一个空的或可丢弃的 GPU 节点。
验证驱动、运行时、插件或 DRA、健康、遥测与拓扑。
运行单 GPU 冒烟测试与一个代表性应用。
若该节点类型承载此类负载，运行多 GPU 或推理扩展测试。
对比日志、指标、启动时间、吞吐与错误率。
向前推进，或排空回退；之后才扩展节点池。

# 最小验证阶梯
kubectl get nodes -l accelerator.example.com/enabled=true
kubectl get pods -n gpu-operator -o wide
kubectl get events -A --sort-by=.lastTimestamp | tail -80
kubectl run gpu-check --rm -it --restart=Never \
 --image=nvidia/cuda:12.8.1-base-ubuntu24.04 \
 --limits='nvidia.com/gpu=1' -- nvidia-smi

总结

GPU Operator 把软件栈各层与设备插件的部署收进一个控制循环，但它自动化的是“安装”，不是“决策”：版本矩阵、金丝雀与回滚仍是平台团队的责任（见安全、可靠性与生命周期）。与 Volcano/Kueue 的关系是互补而非替代：Operator 管“节点就绪”，调度器管“作业就绪”。

参考资料

NVIDIA GPU Operator 官方文档：About the NVIDIA GPU Operator。

生态放置法：把竞品与相关项目放进同一张地图

Jimmy Song — Tue, 30 Dec 2025 05:01:43 +0000

GPU 方案的争论，往往不是“谁更强”，而是“谁解决的是同一层的问题”。用分层视角，才能让比较变得专业和可复用。

很多 GPU 方案争论的根源，并不在“谁更强”，而在“谁解决的是同一层的问题”。把数据平面、控制面、平台层混在一起比较，结论往往会失真：你以为在选“调度器”，对方其实在提供“虚拟化与隔离”；你以为在选“共享方案”，对方其实在做“驱动与生命周期交付”。所以本章给出一套可复用的“生态放置法”：先放对层，再决定比较口径与可组合方式。

三层两界：GPU 生态的分层地图

在实际评估 GPU 相关项目时，建议先用分层地图明确各自职责。下面介绍三大层级及其典型问题。

数据平面：资源的呈现、隔离与观测

数据平面关注 GPU 在节点上的实际使用方式。典型问题包括：

设备发现与资源呈现：如何把 GPU 能力（整卡 / 分片 / 共享）以 Kubernetes 可理解的资源形式暴露出来（device plugin 是典型入口）。
切分与虚拟化：MIG、vGPU、时间切片等把一张卡拆成更细单位，换取更高利用率。
隔离与干扰控制：多租户/多任务并发时的性能抖动、显存争用、上下文切换开销。
观测与计量：能否把“谁用了多少、影响了谁、P99 变成什么”变成可运营指标。

你可以把数据平面理解为：把“能跑”变成“可声明共享 + 可验证干扰”。

控制面：资源供给的治理与策略

控制面不直接改变 GPU 在节点上的运行方式，它解决的是“谁先用、用多少、用多久、能不能进来”。

队列与准入：工作负载进集群前是否被准入（Admission）与分流到哪个队列（Queue）。
配额与公平性：按团队/租户/项目做 quota、fair sharing。
优先级与抢占：在线推理与离线训练如何共存，谁能抢谁。
批处理语义：gang scheduling / co-scheduling、job 级别的调度策略（如 Volcano）。

你可以把控制面理解为：把“能调度”变成“可治理的资源制度”。

平台层：能力组合与产品化体验

平台层通常不发明新的资源语义，而是把数据平面与控制面能力包装成可用体系：

驱动/运行时/插件的生命周期交付与升级（常与 Operator 形态绑定）
多集群、权限、计费、审计、资源可视化与自助申请
SRE 视角的标准化与故障处理路径

平台层的价值是：把“单点能力”变成“端到端可运营”。

下图展示了 GPU 生态系统的三层架构（数据平面、控制面、平台层）及其职责边界。数据平面负责资源的呈现、隔离与观测（如设备发现、MIG/vGPU 虚拟化、干扰控制、计量）；控制面负责资源供给的治理与策略（如队列管理、配额分配、优先级抢占、批处理语义）；平台层负责能力组合与产品化体验（如驱动生命周期交付、多集群管理、SRE 标准化）。图中明确了同层比较和跨层组合的基本规则，为后续的生态放置流程提供理论基础。

图 1: GPU 生态分层地图：三层两界

生态放置流程：四步定位项目职责

生态放置法建议按下面 4 步走，每一步都在缩小比较范围。

固定目标工作负载与 SLO

在开始比较前，需明确目标负载类型和服务级别目标（SLO）。例如：

目标：训练吞吐优先？还是推理 P99 优先？
SLO：要不要强隔离？能容忍多少抖动？失败是“降级”还是“事故”？

没有这个前提，后面所有比较都容易滑向口水战。

明确资源单位（Resource Unit）

先把方案的资源单位写出来：整卡 / MIG 分片 / vGPU / 时间切片 / “显存配额 + 计算共享”等。资源单位决定了：

调度器能“看见”的最小颗粒度
隔离强度的上限
重配置成本与运维耦合方式

例如时间切片通常更灵活，但隔离依赖实现与负载行为；它更像“共享策略”而非“硬切分”。

定位执行点（Enforcement Point）

关键问题：这个方案靠什么把规则落到现实里？

落在驱动/内核/硬件（强但重）
落在运行时与拦截层（灵活但需要工程兜底）
落在 Kubernetes 调度器/准入控制（治理强但不改变节点内争用）
落在平台编排与运维（体验强但可能依赖下层能力）

执行点决定了它属于哪一层，也决定了它能解决什么、解决不了什么。

写清责任边界（Boundary of Responsibility）

用一句话描述：我负责什么，我不负责什么。

数据平面方案通常负责：资源单位的呈现、隔离实现、节点侧的观测计量。
控制面方案通常负责：队列/配额/优先级/准入与策略落地，但不承诺节点内干扰归零。
平台层负责：交付与规模化运维，但它往往“依赖”下层，不“替代”下层。

按同层同单位比较，跨层只比接口契约

同层比较：在同一层、同一资源单位下，才比较隔离强度、性能损耗、观测计量、重配置成本等。
跨层比较：只比较接口与组合方式，比如“控制面是否能表达某种资源单位”“数据平面是否提供足够的可观测与计量信号”。

下图展示从问题识别到方案拼装的完整决策流程。第一步：识别问题域（在线推理 vs 离线训练、多租户 vs 单租户、尾延迟敏感 vs 吞吐优先）；第二步：确定优先级（隔离强度、成本目标、可观测性、兼容性）；第三步：选数据平面（MIG/vGPU/HAMi/时间片）；第四步：配控制面（Volcano/Kueue/Koordinator）。图中还展示了三种典型端到端方案（方案 A：离线训练优先用 MIG+Volcano、方案 B：在线推理优先用 HAMi+Kueue、方案 C：混合负载用 MIG+ 时间片+Volcano），以及常见错误和最佳实践，帮助快速定位项目职责。

图 2: 生态放置四步法：从问题到方案拼装

常见误判：组合≠竞品

实际评估时，容易出现以下误判：

数据平面 vs 控制面：很多不是竞品，是上下游。例如把某个共享/虚拟化方案与 Volcano 直接对比，往往是维度错位。正确口径是：数据平面提供资源单位与可测信号，控制面基于这些信号做治理。二者组合起来才构成“可运营的 GPU 体系”。
device plugin vs 调度器扩展：不要把“资源呈现”当成“调度策略”。NVIDIA 的 device plugin 解决的是“把 GPU 资源以 K8s 可理解方式暴露/分配”，本质上属于资源呈现与节点侧能力。而 scheduler-plugins、以及各类调度扩展，是在 Kubernetes 调度框架上做策略扩展。两者的边界不同：一个回答“资源是什么”，一个回答“谁拿到资源”。
平台层 vs 基础能力：不要用“产品体验”去压“机制边界”。以 GPUStack 这类项目为例，它更容易被用户感知为“平台”，因为它提供更完整的交付与可视化体验；但做生态放置时，仍应回到“资源单位/执行点/责任边界”去拆解它到底依赖了哪些数据平面与控制面能力，避免用“体验”去替代“机制评估”。

组合方式：三种典型端到端方案形态

下面介绍三种常见的端到端 GPU 方案形态，帮助理解不同场景下的组合策略。

下图详细展示方案 A（离线训练优先）、方案 B（在线推理优先）、方案 C（混合负载）的典型场景、技术选型和关键能力。方案 A 采用 MIG + Volcano 组合，提供硬件隔离和 Gang Scheduling，适合深度学习训练和批量模型训练；方案 B 采用 HAMi + Kueue 组合，提供可声明共享和配额管理，适合多租户推理服务和在线模型预测；方案 C 采用 MIG + HAMi + Volcano 混合组合，提供分池管理和优先级抢占，适合训练推理混合场景。图中还包含对比维度表（负载类型、优先级、核心挑战、隔离方式、调度器），帮助快速选择适合的方案组合。

图 3: 三种典型端到端 GPU 方案形态

形态 A：离线训练/批处理优先

控制面：队列 + 配额 + gang scheduling（如 Volcano 类）
数据平面：整卡或硬切分资源池；观测与计量用于容量规划
关键验收：吞吐、作业等待时间、抢占策略对成功率的影响

形态 B：在线推理/多租户优先

数据平面：强隔离或至少可证明的隔离；需要可观测的 P99 与干扰信号
控制面：优先级、准入与配额避免“推理被训练挤爆”
关键验收：P99、抖动半径（blast radius）、故障隔离与回滚路径

形态 C：混合负载（训练 + 推理 + 交互式开发）

先把资源池按“隔离等级/单位/成本”分层（例如强隔离池 vs 共享池）
控制面用队列与配额把团队行为制度化
平台层提供自助申请、审计与成本可视化

一页模板：快速完成生态放置

你可以用下面这张表快速完成生态放置（建议每评估一个项目就填一行）。

项目/产品：
所属层：数据平面 / 控制面 / 平台层
资源单位：整卡 / MIG / vGPU / 时间切片 / 其他
执行点：驱动/硬件｜运行时｜调度器｜准入｜平台
主要承诺：解决什么问题（用一句话写清）
不承诺：明确不解决什么（避免误用）
关键代价：性能损耗、重配置成本、侵入性、兼容性
可观测与计量：有哪些信号能支撑运营（SLO/计费/审计）
组合依赖：上游/下游分别需要什么才能闭环
典型失败模式：最容易“看起来能跑但不可运营”的点

总结

通过分层视角和生态放置法，可以有效避免 GPU 方案评估中的维度错位和无效争论。明确每一层的职责、资源单位、执行点和责任边界，有助于专业、系统地比较和组合不同项目，最终实现端到端的可运营 GPU 体系。

参考文献

Kthena：LLM 推理的 GPU 调度与控制面

Jimmy Song — Mon, 05 Jan 2026 10:21:36 +0000

推理平台的核心竞争力在于能否将模型语义、显存状态与请求路径统一纳入治理，实现可观测、可控与可演进的 GPU 调度闭环。

本章以 Kthena 为案例，重点讨论 大语言模型（LLM）在线推理如何将 GPU 治理从“资源分配”升级为“语义调度”。推理请求进入集群后，调度决策必须同时感知模型、显存（KV Cache）、阶段（Prefill/Decode）以及多租户治理策略，否则在规模化场景下，吞吐、尾延迟与成本会出现系统性失控。

推理为何放大了 GPU 治理难度

推理与训练的系统工程特性存在显著差异。训练更像“批处理吞吐问题”，而在线推理则是“请求路径上的系统工程”。推理的复杂性主要体现在以下几个方面：

KV Cache 显存占用具有强状态性与动态性。同一张卡在不同时间的可服务能力差异极大，传统负载均衡（如 Round-Robin）无法感知显存状态，导致“有卡不敢用/有卡用不了/排队抖动并存”。
Prefill 与 Decode 的资源画像差异显著。Prefill 更偏算力密集，Decode 更偏访存密集。混合运行会抹平优化空间，并放大尾延迟。
多模型、多版本、多 LoRA 适配器成为常态。请求路由与公平性、优先级、限流策略必须纳入统一治理，否则平台只能通过“一个模型一套网关/一套部署”硬拆，运维复杂度不可控。

因此，推理侧的 GPU 调度已不再是简单的“把 Pod 放到节点上”，而是将请求路由、模型生命周期、弹性伸缩与资源调度组合成一个闭环控制系统。

推理侧需要哪些“新调度语义”

为了让推理在规模化场景下可控，平台需要引入一些 Kubernetes 原生调度难以表达、但对推理至关重要的语义：

Prefill/Decode 分离（PD Disaggregation）

将 Prefill 与 Decode 拆分为独立的部署单元，是推理侧最常见的架构优化手段之一，其核心思路如下图所示：

图 1: Prefill/Decode 分离架构

目标：将不同资源画像的阶段拆开部署与独立伸缩，并通过路由保持端到端语义一致。
关键：路由必须具备“PD group aware”能力，否则分离部署会转化为新的排队与抖动。

KV Cache / Prefix Cache 感知

目标：让请求进入“最合适”的实例，而不是“下一个轮到的实例”。
关键：将显存状态纳入负载均衡与限流策略，否则吞吐与 TTFT（Time To First Token）/E2E 会在高并发时快速劣化。

多模型与 LoRA 亲和

目标：在同一平台上支持基础模型与 LoRA（Low-Rank Adaptation）适配器的热插拔、灰度发布与路由策略，降低“模型爆炸”带来的运维成本。
关键：请求分类（model name/header/URI）与后端实例状态（已加载哪些适配器）需要在路由面汇合。

拓扑与 Gang 语义进入推理

目标：在多实例并行（如 TP/PP/EP 等）或 xPyD 组合下，将一组实例作为“原子单元”部署与调度，并尽可能置于同一网络域/更优拓扑中，降低通信成本与尾延迟风险。

这些语义共同指向一个结论：推理需要自己的控制面与数据面协同。

Kthena 架构：控制面与数据面的分工

Kthena 的创新之处在于将推理平台拆分为两类核心组件，实现控制面与数据面的协作，整体架构如下图所示：

图 2: Kthena 架构：控制面与数据面

如图所示，Kthena 的创新之处在于将推理平台拆分为两类核心组件，实现控制面与数据面的协作：

Kthena Controller Manager（控制面）

负责 LLM 工作负载的声明式编排与生命周期管理，包括部署、升级、扩缩容、故障恢复等。
通过 CRD（Custom Resource Definition，自定义资源定义）将“推理特有语义”变成可治理对象，并将部分调度策略对接 Volcano 调度能力。

Kthena Router（数据面）

位于请求路径入口，根据 model name、headers、URI 等规则对请求分类，并执行可插拔的负载均衡与流量治理策略。
原生支持 PD 分离路由，并可实现 KV-cache 感知等策略，弥补通用网关在推理场景下的能力缺口。

这种分工使 Kthena 更接近一个“推理侧的控制闭环”：控制面负责“系统应该长成什么样”，数据面负责“每个请求该去哪里”。

CRD 抽象：让推理生命周期成为 Kubernetes 一等公民

Kthena 的核心思路是通过 CRD 将推理工作负载抽象为 Kubernetes 可声明对象（如 ModelServing），平台因此能够：

用声明式 API 表达推理部署形态（单体、PD 分离、并行范式等）。
用策略对象表达自动伸缩与成本约束。
用路由对象表达多模型、灰度、权重与故障转移。

从 GPU Infra 的角度看，这一步的价值在于：将推理的“业务语义”显式化，让调度与治理不再依赖脚本与人肉经验。

路由与流量治理：调度策略进入请求路径

推理与训练的最大差异之一在于：推理的调度结果必须体现在“每一次请求”的路径上。

因此，Kthena Router 的能力可以理解为“将调度策略下沉到请求级别”，具体包括：

多模型路由（兼容 OpenAI API 风格的请求形态）。
可插拔负载均衡策略（如最少请求、最小时延、KV-cache 感知等）。
PD 分离与 xPyD 组的请求分配。
金丝雀、权重、token 级限流、failover 等流量治理。

在更长周期里，推理平台的竞争力通常不来自“能不能跑起来”，而在于这些策略能否在真实业务负载下持续演进、可观测、可回滚。

生态定位：Kthena 与 Volcano / Kueue / vLLM 的关系

为避免“清单式盘点”，可用职责边界来理解这些组件的协作关系。下图从层级维度展示了 Kthena 在 GPU 推理基础设施中的位置，以及它与上下游组件的交互边界：

图 3: Kthena 生态定位

具体而言：

vLLM / SGLang / Triton：推理引擎（执行层），负责模型执行效率、KV cache 管理等内部机制。
Kthena：推理平台层（控制面 + 路由面），负责将推理引擎纳入 Kubernetes 的声明式治理，并在请求路径执行调度与流量策略。
Volcano：通用调度增强（偏批处理与成组语义），为复杂工作负载补齐 gang、queue、公平性等调度语义。
Kueue：组织治理与准入（配额、承诺、队列化），解决“谁能用多少、何时能用”的平台运营问题。

换句话说，Kthena 将推理的“在线语义”补进了 GPU 控制面地图，这是 Volcano（训练/批处理取向）与 vLLM（执行层取向）之间原本缺失的层。

可观测与验收：推理指标纳入 GPU 平台口径

推理侧建议至少将以下指标纳入统一验收口径，并与后续章节（观测与计量、验收与容量）对齐：

吞吐（req/s 或 tokens/s）
TTFT（Time To First Token）
E2E Latency（尤其是 P95/P99）
GPU 利用率与显存占用曲线（含 KV cache 占用）
丢弃率、限流命中率、重试与 failover 次数

这些指标不仅用于性能对比，更用于验证策略是否真正改善了尾延迟与成本结构。

总结

Kthena 作为 Volcano 生态中的推理平台案例，最重要的启示在于：当推理成为主流工作负载后，GPU Infra 必须具备将模型语义、显存状态与请求路径统一纳入治理的能力。否则平台会退化为“能跑但不可控”，吞吐与延迟被负载随机性主导，成本被资源空转与排队抖动吞噬。

下一章（vLLM）将从执行层解释 KV cache 如何放大共享与干扰问题；实验章节则会进一步用可复现基线验证：在缺乏语义调度的情况下，尾延迟如何被系统性放大。

组合架构：用一套拼装方式覆盖多数场景

Jimmy Song — Tue, 30 Dec 2025 05:03:04 +0000

组合架构的本质，是用“正交拼装”让资源治理与交付变得可控、可评审、可复现。

本章将系统梳理 GPU 资源平台的组合架构思路，帮助你根据实际需求灵活拼装数据平面与控制面，实现从“可用”到“高效”的演进。

定义“拼装件”：你能选的到底是什么？

在设计 GPU 资源平台时，首先要明确可选的“拼装件”有哪些。下面分别介绍数据平面和控制面的核心选项。

数据平面（决定资源单位与隔离/共享边界）

数据平面负责将 GPU 变成 Kubernetes 可消费的“资源单位”，并决定隔离强度、性能干扰与可观测性上限。

整卡（Whole GPU）：最简单、最稳定，隔离强（天然独占），但细粒度利用率有限。
MIG（Multi-Instance GPU，硬切分）：强隔离、单位离散，适合多租户与在线推理/小训练，但重配置带来运维与调度耦合。
共享/虚拟化（以 HAMi 为代表的可声明共享）：资源更细粒度、更弹性，隔离与干扰取决于实现与负载行为，对治理与观测要求更高。

经验法则：

越追求“共享与弹性”，越需要更强的控制面治理与更严格的验收指标。

越追求“强隔离与确定性”，越需要面对“资源单位离散/重配置成本/碎片化”的现实。

控制面（决定谁能用、何时用、用多少、用得是否公平可预测）

控制面负责将 GPU 资源纳入队列、配额、准入与策略治理，提供可运营秩序。

Kueue（治理/准入/配额/承诺/统计）：解决多团队多租户下的稳定秩序与可预测体验。
Volcano（批处理语义/作业调度策略）：补齐训练、分布式、Gang/Queue 等批处理表达能力，偏重调度策略与作业语义。

经验法则：

Kueue 更像资源治理框架（准入 + 配额 + 承诺 + 统计），是平台化的底座。

Volcano 更像批处理调度引擎（训练/作业语义），是训练类负载的加速器。

两者可正交组合：数据平面负责资源单位与隔离，控制面负责秩序与策略。

下图展示 GPU 平台的拼装件组成，包括数据平面和控制面的核心选项。数据平面（蓝色区域）决定资源单位与隔离边界，包含三种选项：整卡（最简单、最稳定、隔离强但细粒度利用率有限）、MIG（硬切分、强隔离、单位离散但重配置带来运维成本）、共享/虚拟化 HAMi（可声明共享、资源更细粒度但隔离与干扰取决于实现）。控制面（黄色区域）决定谁能用、何时用、用多少，包含 Kueue（资源治理框架，提供准入配额统计）和 Volcano（批处理调度引擎，补齐训练作业语义）。底部强调核心理念：用正交拼装让资源治理与交付变得可控、可评审、可复现。

图 1: GPU 平台拼装件：数据平面与控制面的正交组合

拼装原则：先定边界，再做组合

在实际架构设计中，遵循以下拼装原则有助于降低风险、提升可控性。

原则 A：先用最小可用闭环而不是最大功能集
优先保证可用、可测、可回滚、可计量，再逐步扩展共享与复杂调度。
原则 B：资源单位越细，验收越严格
整卡的失败多来自调度与容量，共享的失败多来自干扰、计量、隔离语义不一致。
原则 C：重配置是“变更”，必须被流程化
尤其是 MIG，重配置会影响可用资源形态，必须纳入变更窗口、容量预留及调度策略。
原则 D：把平台责任写进架构
明确哪些责任属于数据平面（隔离/共享/设备暴露），哪些属于控制面（准入/配额/队列/公平），哪些属于平台层（交付体验、SLO、计量与成本）。

参考架构目录：6 种组合覆盖多数场景

为方便评审，下面给出 6 套可直接落地的参考架构，从简单到复杂递进。你可以将它们作为“标准套餐”，再按组织与负载微调。

A. 单队列整卡：最小闭环（入门/小团队）
B. 多队列整卡 + Kueue：治理先行（多团队/公平性）
C. MIG 池化 + Kueue：强隔离的细粒度（在线推理/多租户）
D. HAMi 共享 + Kueue：可声明共享（混部/高利用率）
E. 训练增强：Volcano（可选）叠加：训练语义补齐（分布式/批处理）
F. 双池/双域：在线与离线分治：稳定性优先（生产平台）

你不需要一次性上全套。推荐路线：A → B（治理）→ C/D（细粒度）→ E/F（平台化）。

下图展示 6 种参考架构从简单到复杂的演进路径。A（单队列整卡）是最小闭环，适合小团队先跑稳；B（多队列整卡+Kueue）引入治理，实现多团队公平；从 B 可以演进到 C（MIG 池化+Kueue）追求强隔离，或 D（HAMi 共享+Kueue）追求高利用率；进一步可演进到 E（训练增强 Volcano 叠加）或 F（双池/双域分治）。右侧图例说明不同颜色代表复杂度等级（绿色入门、黄色中级、红色高级、蓝紫色平台级）。底部展示推荐演进路径：A → B（治理先行）→ C/D（细粒度）→ E/F（平台化）。核心思想：根据组织成熟度和负载形态逐步演进，不需要一次性上全套。

图 2: 6 种参考架构：从简单到复杂的演进路径

参考架构 A：单队列整卡（最小闭环）

本方案适用于团队规模较小、GPU 数量有限、负载以训练/推理为主但不复杂的场景，目标是“先跑稳”。

架构要素：

节点：GPU Node（整卡暴露）
调度：原生 Kubernetes Scheduler（或简单扩展）
控制：无额外治理（最多 namespace 限制）

复杂度与风险点：

复杂度低
风险包括多团队抢占、缺乏公平性、无准入与配额、平台体验不可预测、容量规划依赖人工

建议验收指标（最小集）：

可用性：单节点/单卡故障不会导致集群级连锁故障（至少能隔离影响范围）
调度：GPU 请求的 Pod 成功调度率、平均等待时间（P50/P95）
资源：GPU 利用率基线（按业务定义：训练/推理分别统计）

参考架构 B：多队列整卡 + Kueue（治理先行）

当多团队/多租户出现，需要“谁能用、能用多少”的治理时，推荐采用本方案。

架构要素：

数据平面：整卡
控制面：Kueue（Queue/Quota/Admission）
平台层：团队/项目维度的配额策略与报表

复杂度与风险点：

复杂度中等（引入治理对象与策略）
风险包括配额与优先级策略设计不当导致“看似公平、实际饥饿”，治理对象边界不清导致运维负担上升

建议验收指标：

公平性：各队列的等待时间分布与资源兑现率（承诺->实际）
可预测性：配额下的吞吐（jobs/day）与违约率（超配/抢占/回收）
可运营：资源统计可按队列/团队归因（至少月度/周度可对账）

参考架构 C：MIG 池化 + Kueue（强隔离的细粒度）

适用于多租户在线推理、希望强隔离和单位更细（如 1g/2g 等）的场景，能接受 MIG 单位离散与重配置成本。

架构要素：

节点：GPU Node（开启 MIG）
数据平面：MIG 实例作为可调度资源单位
控制面：Kueue 负责队列、准入、配额与承诺
运维：MIG Profile 作为“容量形态”，由变更流程管理

复杂度与风险点：

复杂度中高
风险包括重配置耦合调度、碎片化、运维窗口需求

建议验收指标（必须更严格）：

隔离：并发租户压测下的性能抖动（P95/P99）在可接受阈值内
形态：Profile 变更的成功率、回滚时间、对在跑作业影响面
碎片：无法调度的原因分类中，“形态不匹配”占比可度量并可优化
治理：队列维度的兑现率与超卖风险可观测

参考架构 D：HAMi 共享 + Kueue（可声明共享的高利用率）

当 GPU 需求呈现碎片化小请求、目标是显著提高利用率时，推荐采用本方案。适合具备较强 SRE/平台能力的组织。

架构要素：

节点：GPU Node
数据平面：HAMi 提供“可声明共享”的资源表达
控制面：Kueue 提供准入、配额、承诺、统计（避免共享导致的无序竞争）
平台层：SLO（延迟/吞吐/错误率）与计量（用量归因）纳入运营

复杂度与风险点：

复杂度高
风险包括干扰与噪声、语义一致性、计量与归因难题

建议验收指标（共享必备）：

干扰：并发下关键 SLO 指标（延迟/吞吐）变化曲线、抖动上界
计量：用量可归因到队列/租户（至少支持审计与对账）
超分策略：超卖比例、违约率、回收策略触发频率可观测
故障隔离：异常租户不会拖垮整机/整节点的稳定性

参考架构 E：训练增强（Volcano 叠加，按需启用）

本方案不是替代 Kueue，而是补齐训练/批处理语义。Kueue 负责治理与准入，Volcano 负责训练作业语义与调度策略。

适用场景：

分布式训练、Gang 调度、批处理队列策略需求强
需要训练作业更丰富的调度能力（如队列、优先级、抢占等语义）

架构要素：

数据平面：整卡 / MIG / HAMi（任选其一）
控制面：Kueue（准入/配额/承诺）、Volcano（训练作业语义/调度策略）
平台层：训练作业生命周期管理（模板、重试策略、产物管理）

复杂度与风险点：

复杂度中高（两个控制面组件协同）
风险包括策略重复、观测复杂

建议验收指标：

训练吞吐：jobs/day、平均排队时间、失败重试成本
Gang 成功率：分布式作业成功启动率、资源聚合耗时
公平性：队列间训练资源分配符合预期（可回放/可解释）

参考架构 F：双池/双域（在线与离线分治，稳定性优先）

适用于生产平台，在线推理与离线训练/批处理并存，在线 SLO 严格，需要隔离训练波动/抢占/噪声。

架构要素：

资源池 1（Online Pool）：偏强隔离（整卡或 MIG），严格准入与优先级
资源池 2（Offline Pool）：偏吞吐（整卡或共享），容忍更大波动
控制面：Kueue 统一治理（跨池配额/承诺/统计），训练侧可选 Volcano
平台层：统一门户与用量归因（按池/队列/项目）

复杂度与风险点：

复杂度高（资源池治理、容量规划、跨池策略）
风险包括容量割裂、策略复杂

建议验收指标：

在线 SLO：延迟 P95/P99、错误率、抖动边界
离线吞吐：训练/批处理吞吐、排队时间
跨池效率：借用比例、回收时延、在线被影响事件数

组合对照表：按“组织成熟度 × 负载形态 × 运维约束”选套餐

为帮助快速选型，下面给出常见约束下的推荐组合。

这是选型建议表：

约束/目标	首选组合	次选组合	不推荐（除非你很清楚为什么）
小团队、先跑稳	A（整卡）	B（整卡+Kueue）	直接上 D（共享）
多团队、要公平可预测	B（整卡+Kueue）	C（MIG+Kueue）	只靠 namespace 约束
在线推理、多租户、要强隔离	C（MIG+Kueue）	F（双池分治）	D（共享）作为默认
追求高利用率、碎片化请求多	D（共享+Kueue）	F（双池分治）	只上 A/B 且长期不治理
分布式训练/批处理语义强	E（Kueue+Volcano）	B/C + E	仅 A（会“能跑但难管”）

表 1: 快速选型（推荐优先级）

下面是复杂度与风险等级对照表：

架构	复杂度	主要风险	主要收益
A	低	无治理、不可预测	最快上线、最少组件
B	中	策略设计不当导致饥饿	公平与可预测、可运营
C	中高	重配置/碎片化/变更耦合	强隔离 + 更细粒度
D	高	干扰/计量/语义一致性	高利用率 + 细粒度弹性
E	中高	多控制面协同复杂	训练语义与吞吐提升
F	高	容量割裂/跨池策略复杂	在线稳定 + 离线吞吐

表 2: 复杂度与风险等级

评审模板：让方案“可评审、可实施、可验收”

为提升架构评审效率，建议使用如下模板：

必答问题（评审清单）：

资源单位是什么？（整卡 / MIG / 共享）为什么？
隔离强度目标是什么？（强隔离/中等/可接受干扰）如何验证？
谁是治理对象？（团队/项目/租户/队列）边界是否清晰？
准入与配额如何定义？资源承诺如何统计与归还？
重配置是否存在？（尤其 MIG）谁能改？何时改？如何回滚？
观测与计量口径是什么？（至少能回答“谁用了多少、影响了谁”）
故障域是什么？（单 Pod/单节点/单池/全局）应急预案是什么？

验收指标建议（三层指标）：

调度层：排队时间、调度成功率、抢占/回收事件
性能层：关键 workload 的吞吐/延迟（P50/P95/P99）、抖动上界
运营层：用量归因、兑现率、超卖违约率、成本可解释性

推荐落地路径：从“可控”走向“高效”

平台演进建议分为三个阶段：

下图展示从可控到高效的三阶段落地路径。Phase 1（建立秩序 A → B）：先用整卡跑稳，再引入 Kueue 做队列/配额/准入，目标是公平、可预测、可统计，验收标准包括多团队配额与公平性、等待时间可预测、资源使用可归因。Phase 2（引入细粒度 B → C 或 B → D）：如果优先隔离上 MIG（架构 C），如果优先利用率上 HAMi（架构 D），必须同步加强验收与观测，验收标准 C 侧重隔离强度/P95 抖动/碎片率，D 侧重干扰控制/计量归因/超卖违约率。Phase 3（平台化分治 → E/F）：训练复杂就叠加 Volcano（架构 E），在线/离线冲突强就做双池分治（架构 F），验收标准 E 侧重训练吞吐/Gang 成功率/公平性，F 侧重在线 SLO/离线吞吐/跨池效率。底部强调核心理念：每阶段都要有清晰的验收指标和回滚路径，避免技术债务累积。

图 3: 推荐落地路径：从可控到高效的三阶段演进

总结

数据平面决定你交付的资源单位与隔离上限。
控制面决定多租户下的秩序、治理与可预测体验。
组合架构不是简单堆组件，而是把边界写清、把验收做实，实现能交付、能运营、能复现的平台能力。

GPU 平台能力模型

Jimmy Song — Thu, 22 Jan 2026 04:54:52 +0000

平台能力的本质，是将复杂工程机制抽象为可交付、可验收、可组合的治理单元。

GPU 资源问题正从“单机性能优化”转向“平台治理”：共享与隔离、碎片化调度、在线推理尾延迟，以及异构与多租户带来的治理复杂度。本章提出一套可复用的 GPU 平台能力模型，用于将“机制与实现”抽象为“可交付、可验收、可演示”的能力单元，为平台选型、方案设计与能力路线提供统一语言。

本章不展开具体组件实现细节（如 MIG、HAMi、Kueue、Volcano、Kthena 的内部机制），而聚焦于平台对外交付的能力、成立前提、度量与验收方式，以及能力如何组合成场景方案。

从 Feature 列表到平台能力：为什么需要能力模型

许多 GPU 平台讨论停留在 feature 列表：支持某种切分、调度、指标面板。但在生产环境，用户更关心：

在给定预算与硬件条件下，利用率能提高到什么程度，代价是什么；
在线推理在资源紧张时，SLA 能否被严格保障；
多团队共享资源池时，是否能做到 可预测、可解释、可约束；
业务潮汐或突发时，平台是否具备 自适应弹性；
能否提供 可复现的验收方法，避免“看起来能用”的主观判断。

因此，本章采用“能力（Capability）”的表达方式，而非“功能（Feature）”。

能力（Capability） 指面向场景的交付单元，满足以下约束：

可叙述：一句话说明解决什么问题；
可成立：有明确适用前提与边界条件；
可验收：有清晰指标口径与可复现实验方法；
可组合：能与其他能力组合成更高层场景方案；
可权衡：明确收益与代价，避免隐性风险。

分层结构：L0–L3（原语 → 基础能力 → 平台能力 → 场景方案）

为避免内容“大而全”，本模型采用四层结构：

图 1: GPU 平台能力模型分层结构

{width=“2143” height=“3023”}

L0 · 资源原语（Primitives）

平台可观测、可分配、可约束的最小对象，包括：

显存：分配量、峰值、碎片与回收；
算力：SM 利用率、算力份额、调度时间片；
带宽与互联：HBM 带宽、PCIe/NVLink 拓扑与争用；
工作负载属性：推理/训练/测试、交互式/批处理、优先级与期限；
健康与热状态：温度、功耗、ECC、故障与降频。

L1 · 基础能力（Foundations）

对 L0 原语进行抽象、治理与组合的基础动作：

限额与配额（资源边界）
准入与排队（Admission/Queue）
抢占与驱逐（Preemption/Eviction）
共享与隔离等级（Isolation Profiles）
弹性调整（Resize/Scale）
性能档位（Performance Profiles）
指标采集与归因（Metering/Attribution）

L2 · 平台能力（Platform Capabilities）

面向业务场景的交付单元（可演示、可验收、可复用）。本章后半部分将对以下能力给出标准化描述：

GPU 超卖（显存超卖）
优先级抢占
自动扩缩容（显存原地扩缩容与自动扩容）
Turbo 模式（接近原生性能档位）
GPU 资源精细化管理（配额）
任务显存占用分析
一站式可观测性

L3 · 场景方案（Solutions）

多个 L2 能力按场景打包形成可交付方案，例如：

GPU 云租赁与“出租率”优化（利用率优先）
潮汐型推理平台（尾延迟与弹性优先）
多团队共享资源池（治理与公平优先）
训练/推理混部平台（隔离与可预测优先）

能力域划分：六大域（供给 / 分配 / 共享隔离 / 弹性 / QoS / 观测验收）

为让 L2 能力具备清晰层次，本章采用六个能力域组织内容。每个能力域对应平台治理闭环中的关键问题：

图 2: GPU 平台能力域划分

{ width=“2623” height=“1823” }

能力域	核心关注	关键问题
1. 供给与抽象	Supply & Abstraction	平台对外提供哪些资源形态与性能档位（profile），如 Turbo/非 Turbo、显存弹性形态等
2. 准入与分配	Admission & Allocation	谁能用、用多少、资源紧张时如何排队与抢占，确保关键任务优先
3. 共享与隔离	Sharing & Isolation	多任务共存时的干扰边界与隔离等级，决定“能不能混、混到什么程度”
4. 弹性与自适应	Elasticity & Adaptation	随业务波动动态调整资源形态与规模，避免“固定配置”导致的浪费与降级
5. 性能与 QoS	Performance & QoS	以延迟、吞吐与 SLA 为目标的性能剖面与保障机制，明确 trade-off
6. 可观测、计量与验收	Observability & Acceptance	从集群到任务的可解释性、计量口径与验收方法，形成闭环与工程事实

表 1: GPU 平台能力域划分

能力卡模板：统一写法与验收口径

为避免能力描述变成产品说明书或 feature 列表，本书对每项 L2 能力采用统一“能力卡”模板：

能力定义（一句话）：用工程语言描述要交付的能力。
适用场景与业务假设：该能力成立的前提（潮汐性、优先级划分、交互延迟约束等）。
核心价值（可量化）：收益优先用指标表达（利用率、SLA、成本、运维效率等）。
关键机制（抽象概览）：描述需要哪类机制（控制面/数据平面/观测），不展开实现细节。
验收指标（口径明确）：至少包含利用率类、性能类、稳定性类三组指标。
边界与短板：何时不适用、风险在哪里、会牺牲什么。
演示步骤（最短路径）：给出可复现实验的最小步骤与观测点。

能力矩阵总览（L2）

下表用于快速定位能力在模型中的归属与评估重点。建议实际评估时以能力卡形式展开。

平台能力	主要能力域	次要能力域
GPU 超卖	共享与隔离	弹性 / QoS
优先级抢占	准入与分配	QoS
自动扩缩容	弹性与自适应	-
Turbo 模式	供给与抽象	性能与 QoS
GPU 资源配额	准入与分配	-
任务显存占用分析	可观测、计量与验收	-
一站式可观测性	可观测、计量与验收	-

表 2: 能力矩阵总览（L2）

平台能力详解（能力卡）

GPU 超卖（显存超卖）

图 3: GPU 超卖能力架构

{ width=“2623” height=“1743” }

维度	内容
能力定义	在保证可控干扰边界的前提下，通过显存层弹性与复用机制，使单卡承载更多模型/任务，从而显著提高 GPU 利用率
适用场景	推理业务潮汐性明显（峰谷差大），或多模型碎片化部署导致利用率偏低
核心价值	利用率提升（30% → 60%）、密度提升、平台收益放大
关键机制	数据平面：显存复用与弹性策略；控制面：超卖比、优先级与资源承诺；观测：显存水位与置换事件
验收指标	利用率类：SM 利用率均值/分位数、GPU 空闲时长占比；性能类：TTFT/TPOT/ITL/ILT 的 P50/P95/P99；稳定性类：OOM/驱逐次数、置换事件频率
边界与短板	极致低延迟业务需谨慎评估；跨厂商异构需额外适配
演示步骤	单卡部署多模型实例 → 压测记录指标 → 对比无超卖与超卖配置

表 3: GPU 超卖能力卡

优先级抢占

图 4: 优先级抢占能力架构

{ width=“2443” height=“1603” }

维度	内容
能力定义	在资源紧张时，平台以确定性方式让高优先级任务获得 GPU 资源，并对低优先级任务进行降级、暂停或抢占
适用场景	任务优先级划分明确（核心推理 > 训练 > 测试），资源池存在阶段性紧张
核心价值	SLA 稳定性提升、资源利用率提升（避免为“最坏情况”长期超配）
关键机制	控制面：优先级、队列与抢占策略；数据平面：算力抑制或资源回收；观测：抢占事件与队列等待时间
验收指标	利用率类：资源紧张期间 GPU 利用率与空转占比；性能类：高优先级任务 TTFT/TPOT P95/P99；稳定性类：抢占次数、恢复成功率、队列等待时间
边界与短板	仅在“优先级明确且业务潮汐明显”场景收益最大；实时性极高任务需更严格约束
演示步骤	启动低优先级训练任务 → 启动高优先级推理服务 → 观察训练算力被抑制，推理延迟稳定

表 4: 优先级抢占能力卡

自动扩缩容（显存原地扩缩容与自动扩容）

图 5: 自动扩缩容能力架构

{ width=“2782” height=“1803” }

维度	内容
能力定义	平台可在不破坏工作负载连续性的前提下，按策略动态调整任务显存配置，并在压力变化时触发自动扩容/缩容
适用场景	业务流量波动明显（突发 QPS、潮汐规律），模型加载与上下文变化导致显存需求动态变化
核心价值	降低空闲率、提升健壮性（自动扩容避免崩溃）、运维效率提升
关键机制	控制面：扩缩容策略（阈值、步长、冷却时间）；数据平面：显存在线调整与安全回收；观测：扩缩容事件与关联分析
验收指标	利用率类：显存利用率、碎片率、空闲显存占比；性能类：扩容前后 TTFT/TPOT 变化幅度与恢复时间；稳定性类：OOM 次数、扩缩容失败率、抖动次数
边界与短板	仅基于资源指标触发可能无法贴合业务指标；步长/阈值需可配置可解释
演示步骤	启动显存配置偏小的训练任务 → 验证显存压力时任务不中断 → 对比未开启策略时的 crash 行为

表 5: 自动扩缩容能力卡

Turbo 模式（接近原生性能档位）

图 6: Turbo 模式能力架构

{ width=“2623” height=“1943” }

维度	内容
能力定义	在保持平台治理能力的同时，提供以低开销路径为目标的高性能档位，使关键工作负载接近原生性能
适用场景	对 RT/尾延迟高度敏感（广告、推荐、在线推理），可接受减少部分弹性或共享策略
核心价值	接近原生性能（TTFT/TPOT/ITL 优于普通共享路径）、性能可预测（减少抖动）
关键机制	数据平面：低开销执行路径与隔离档位；控制面：以“档位”方式约束资源供给；观测：工作负载级性能指标与对比基线
验收指标	利用率类：单卡利用率与吞吐；性能类：TTFT/TPOT/ITL 的 P50/P95/P99 对比原生/非 Turbo；稳定性类：性能抖动、异常重试/超时比例
边界与短板	缺乏工作负载级算力指标易只看到“卡级别”提升；Turbo 档位要求更强约束，可能降低共享弹性
演示步骤	两张同规格卡分别部署同一模型（一开 Turbo，一关）→ 同一基准工具压测 → 输出性能对比报告

表 6: Turbo 模式能力卡

GPU 资源精细化管理（配额）

图 7: 配额管理能力架构

{ width=“2782” height=“2043” }

维度	内容
能力定义	多租户或多团队共享 GPU 资源池时，平台以配额与限额机制实现可预测的资源边界与公平性
适用场景	多团队共享同一集群，资源争抢会导致排队/卡死/节点被挤爆
核心价值	减少争抢与雪崩风险、提高协同效率、关键任务保障
关键机制	控制面：namespace/队列/配额与准入控制；数据平面：按配额约束显存与算力份额；观测：配额用量、拒绝原因、资源公平性
验收指标	利用率类：配额内资源使用率、超额请求被拒绝比例；性能类：关键任务延迟/吞吐稳定性；稳定性类：资源争抢失败率、节点拥塞事件
边界与短板	仅支持显存与算力约束时，带宽/拓扑等维度可能出现“隐性争抢”；配额粒度与组织结构不匹配会造成低效
演示步骤	创建 namespace 配额（显存 20G、算力 100%）→ 启动工作负载 A（15G+80%）成功 → 启动工作负载 B（10G+50%）被拒绝 → 输出拒绝原因

表 7: GPU 资源精细化管理能力卡

任务显存占用分析

图 8: 任务显存占用分析能力架构

{ width=“2583” height=“1743” }

维度	内容
能力定义	平台以可解释方式拆解并可视化任务显存占用结构与动态变化，用于指导混部、超卖与弹性策略
适用场景	科学智能/多任务场景显存分布不均，推理场景显存由权重/KV Cache/上下文/模块构成
核心价值	提升资源决策准确性、排障提效（定位 OOM 时间降低）、容量规划更可靠
关键机制	观测：显存占用分解维度、时间序列与事件关联；控制面：分析结果用于策略调整；数据平面：显存占用采样与标注
验收指标	利用率类：显存峰值/均值/分位数与碎片率；性能类：不同上下文长度下 TTFT/TPOT 弹性曲线；稳定性类：OOM/重试次数、显存突刺事件频率
边界与短板	分析维度过少只能看到现象无法指导策略；异构 GPU 采样一致性与归因复杂度更高
演示步骤	部署模型服务采集显存分析数据 → 改变输入上下文长度或并发 → 观察显存结构与延迟指标联动 → 给出可行动结论

表 8: 任务显存占用分析能力卡

一站式可观测性

图 9: 一站式可观测性能力架构

{ width=“2583” height=“1883” }

维度	内容
能力定义	平台提供从集群/节点/卡到工作负载的一体化观测与归因体系，覆盖利用率、健康度、性能与成本相关指标
适用场景	GPU 资源池规模化运行，需同时服务平台运维/算法团队/硬件维护等多角色
核心价值	全链路可见（APP → GPU → Node → Cluster）、异常可定位、验收可复现
关键机制	观测：多层级指标与日志/事件关联，支持任务级归因；控制面：观测结果用于策略调整与告警；数据平面：卡级与任务级指标采集
验收指标	利用率类：集群/节点/卡/任务各层级利用率与空转占比；性能类：任务级延迟/吞吐与资源压力关联；稳定性类：温度/功耗阈值告警、ECC/硬件异常事件、故障 MTTR
边界与短板	缺少任务级归因指标会退化为“卡级面板”；指标口径不统一会导致验收争议
演示步骤	部署压力工作负载验证卡级性能指标 → 部署 A/B 两个任务错峰访问 → 调整超卖比或抢占策略观察波峰/波谷与事件对应

表 9: 一站式可观测性能力卡

常见组合：三类典型平台包（L3 示例）

以下为三类常见组合方式，帮助读者将能力从“单点”组织成“方案”：

平台类型	关键能力	核心目标
GPU 云租赁	GPU 超卖、自动扩缩容、配额、可观测性	利用率/出租率优先 - 提高密度与出租率，控制尾延迟风险
潮汐型推理平台	优先级抢占、自动扩缩容、Turbo、可观测性	SLA 与弹性优先 - 峰值保障、谷值节省，优先保障核心服务
多团队共享资源池	配额、优先级抢占、可观测性、显存占用分析	治理与公平优先 - 可预测、公平、可解释，降低组织摩擦成本

表 10: 三类典型平台包

能力成熟度：从可演示到可规模化

能力从“能跑”到“可规模化”，通常经历三个阶段：

图 10: GPU 平台能力成熟度模型

{ width=“2223” height=“1063” }

阶段	特征	局限性/要求
可演示（Demo-ready）	✓ 存在最短路径演示 ✓ 有可见的指标 ✓ 基本功能可用 ✓ 概念验证完成	• 没有稳定的指标 • 缺少生产环境保障 • 测试有限
可验收（Acceptance-ready）	✓ 稳定的指标定义 ✓ 基于分位数的分析 ✓ 可复现的基准测试 ✓ 验收标准明确	• 策略治理有限 • 缺少边界情况处理 • 需要手动扩展
可规模化（Production-ready）	✓ 策略治理 ✓ 边界保护 ✓ 告警与监控 ✓ 故障排查闭环	• 需要明确边界 • 需要定义成本与权衡 • 需要稳定的运营

表 11: 能力成熟度模型

评估平台时，建议关注是否具备可验收口径、明确边界与代价、能否形成稳定运营闭环，而非仅以“能否支持某功能”为唯一标准。

总结

本章提出的 GPU 平台能力模型，旨在帮助平台团队与业务方以统一语言梳理平台交付能力、适用前提与验收方式。通过能力分层、能力卡模板与典型组合，平台治理不再停留在 feature 罗列，而是转向可复现、可组合、可演示的工程闭环。希望本模型为 GPU 平台选型、能力规划与生产落地提供参考。

决策轴：评估任何 GPU 方案的统一维度

Jimmy Song — Tue, 30 Dec 2025 05:01:38 +0000

选型评审时，方法论比“谁更强”更重要。用一套统一决策轴，才能让每个 GPU 方案都被公平、可验证地落位。

本章将为你提供一套可复用的“决策轴矩阵”，帮助将所有 GPU 方案拉到同一坐标系下进行对比。矩阵涵盖资源单位（整卡/MIG/时间片/vGPU/Claim）、隔离强度、性能损耗与干扰、观测与计量能力、运维重配置成本、兼容性与侵入性、以及异构扩展路径。后续每个章节与实验都会回填到这张矩阵中，形成可验证的结论链。

先建立两个硬边界：为什么不先说“哪个更好”

在 Kubernetes 语境下，GPU 方案的讨论容易陷入“调度器不行 / 设备插件不行 / 某项目更强”的情绪化结论。为避免比较维度混乱，本书先明确两条边界：

原生 Kubernetes 对 GPU 的主流语义是整数型设备资源：依赖 device plugin（设备插件，Device Plugin）把设备作为扩展资源暴露给 kubelet 与调度器，用户通过 resources 请求与消耗该资源。
“共享/超卖”不是原生语义：当前看到“一张卡跑多个 Pod”，通常是数据平面或厂商栈在整数语义之上做了复用（如 time-slicing，时间片复用）。

因此，本章的核心不是给方案排座次，而是提供一套可复用的评审语言。无论是 HAMi、GPUStack、NVIDIA Operator、Kueue、Volcano 还是 DRA driver，都能按同一套轴落位。

如何使用这张“决策轴矩阵”

建议按以下三步进行评审，后续每章也会沿用这三步组织内容：

先选控制面治理形态：你是否需要队列、配额、准入、抢占、公平性与组织级治理（如 Kueue 的 Workload/ClusterQueue 语义）。
再选数据平面资源单位与兑现机制：整卡、MIG、time-slicing、vGPU，或 DRA 的 ResourceClaim/DeviceClass。
用本章决策轴做验收：将 SLO（吞吐、P99、隔离、计量、运维）映射为可测指标，并在后续实验中用同一套观测栈复现实证。

决策轴 0：先把“控制面 vs 数据平面”切开

理解控制面与数据平面的责任边界，有助于厘清方案定位：

控制面：定义秩序与治理（排队、准入、配额、公平、抢占、组织边界）。如 Kueue 通过 Workload 计算资源用量并据此决定准入/抢占，ClusterQueue 表达配额与策略。
数据平面：负责兑现（设备发现、切分与虚拟化、隔离、交付、观测与计量）。Device Plugin 是 Kubernetes 提供的标准扩展框架，DRA（动态资源分配，Dynamic Resource Allocation）进一步将“设备请求与分配”推进到更可声明的 API。

许多争论其实是将不同平面的能力混在一条轴上比，导致结论失真。

GPU 基础设施的控制面与数据平面划分及各决策轴的归属关系如下图所示：

图 1: 控制面与数据平面决策轴架构图

决策轴 1：资源单位（Resource Unit）

在调度时，最小的资源单位是什么？

整卡：nvidia.com/gpu: 1 的经典语义，简单、稳定、易治理。
MIG 实例：将单卡切成多个离散实例，每个实例作为独立设备暴露给上层，适配 Kubernetes 整数模型。
time-slicing 逻辑 GPU：同一物理 GPU 被复制成多个“可分配副本”，工作负载在时间片上交错运行，允许 oversubscription（超卖）。
vGPU：以虚拟 GPU 形态交付给容器或虚拟机（通常涉及更复杂的驱动/虚拟化栈）。MIG 也可与 vGPU 组合使用以保留隔离属性。
DRA ResourceClaim：以 claim 形式请求“带参数的设备”，由 device class 与 driver 共同完成分配与绑定。

经验法则：资源单位越“离散且标准”，越容易进入控制面治理；单位越“逻辑化”，越依赖数据平面兑现与计量闭环。

决策轴 2：隔离强度（Isolation）

隔离能力建议至少拆为三层：

故障隔离：一个工作负载出错是否影响其他工作负载。
显存与地址空间隔离：是否存在内存共享或泄漏风险。
性能隔离：共享时是否能保持可预测吞吐与尾延迟。

MIG（多实例 GPU，Multi-Instance GPU）的设计目标是“安全分区”，可将一张卡划分为多个相互隔离的 GPU 实例。相对地，time-slicing 通常不提供同等级别的内存与故障隔离，更强调时间片复用与资源利用率。

决策轴 3：干扰与尾延迟（Interference & Tail Latency）

评估共享方案时，需关注 P99 能否被承诺。

对在线推理而言，尾延迟往往是“否决轴”：只要 P99 被共享干扰放大，其他轴再优秀也难以落地。
time-slicing 机制为交错运行，本质上引入了额外的调度与争用路径，更容易显性化抖动。

后续实验将用相同压测方式与指标（吞吐 + P50/P95/P99）对比 MIG 的硬切分、非 MIG 的同卡干扰，以及共享方案的尾延迟变化。

决策轴 4：性能损耗（Overhead）

细粒度或共享方案通常会带来一定的性能开销，主要包括：

复用带来的上下文切换与调度成本（如 time-slicing）。
虚拟化层开销（如 vGPU/mediated）。
框架侵入或运行时改造导致的优化受限。

评估建议：不要用“平均吞吐”替代所有指标，至少同时关注吞吐与尾延迟（尤其在推理场景下）。

决策轴 5：控制面治理能力（Admission / Quota / Fairness / Preemption）

本轴只讨论“秩序”，不涉及“设备如何兑现”。

以 Kueue 为例：

Workload 的资源使用量由 podSets 的 request 聚合得到，用于决定准入时机。
当配额不足时，可触发抢占以容纳更高优先级 Workload，ClusterQueue 的策略决定抢占行为。

可以理解为：Kueue 解决“谁先用、谁等、谁能借用/抢占”，而不是“GPU 如何共享”。

决策轴 6：兼容性与侵入性（Compatibility & Invasiveness）

评审时需明确改动了哪些“稳定面”：

Pod spec 是否仍为标准 resources（还是需要注解、sidecar、CRD 或自定义调度器）。
是否强依赖特定厂商栈（Operator / driver / toolkit 的组合）。
是否将关键逻辑塞进节点侧黑盒（难审计、难复现）。

Device Plugin 与 DRA 均为 Kubernetes 官方扩展入口，通常在生态兼容性与长期演进上更稳。

决策轴 7：运维与重配置成本（Operational Reconfiguration）

细粒度方案往往将“策略变更”转化为“运维变更”，例如：

MIG profile 的调整通常意味着节点侧重配置与变更窗口，尤其在有工作负载时。
time-slicing 需要管理共享配置并接受隔离不足带来的风险敞口。
DRA 引入新的资源对象与 driver 责任边界，需要评估团队是否能承接其运维与故障域。

本轴决定了方案能否规模化推广，而不仅是“能不能跑 demo”。

决策轴 8：可观测与计量（Observability & Metering）

没有计量就没有治理；没有治理就难以实现多租户平台化。

建议将“可观测”拆为两层：

设备层遥测：如利用率、显存、功耗、温度、错误、NVLink 等。
归因与计费口径：按 Pod/Namespace/Queue/用户维度做 showback/chargeback。

DCGM-Exporter 是 NVIDIA 推荐的 Kubernetes 集群遥测出口之一，基于 DCGM 收集 GPU 指标，并以 /metrics 暴露给 Prometheus。

后续“观测与计量”章节会将本章要求具体化为最小指标集合、告警阈值，以及与控制面队列维度的归因拼接。

决策轴 9：失败模式与可排障性（Failure Modes & Debuggability）

同样是“Pod 起不来”，根因可能落在不同平面：

控制面：队列未准入、配额不足、抢占发生。
调度面：节点资源广告不对、约束冲突。
节点侧：device plugin/driver/toolkit 问题导致 Allocate 或运行期失败。

Device Plugin 的标准框架至少能将“设备交付链路”固定为可追踪对象；DRA 则将分配过程进一步变成可声明、可审计的资源对象。

决策轴 10：演进与异构扩展路径（Evolvability）

如果你预期未来会面对如下场景：

多厂商 GPU/NPU 并存。
更复杂的“带参数”请求。
设备共享成为常态。

那么 DRA 的价值会逐步提升：它允许通过 DeviceClass/ResourceClaim 让工作负载以更结构化方式请求设备，并由 driver 完成分配与绑定。

本书“趋势”章节会将 DRA 放到更大的叙事里，展示 GPU 设施从“设备接入”走向“资源产品化”的演进。

典型方案画像（用于快速落位，不替代你的实测）

下表为不同方案在各决策轴上的“默认画像”，便于一眼看出各自优势与短板。实际结论仍需结合后续实验验证。

下面是表格的内容说明：表格对比了不同 GPU 方案在资源单位、隔离强度、尾延迟风险、运维成本、计量难度和治理适配性等方面的典型表现。

方案	资源单位	隔离强度	尾延迟风险	运维成本	计量难度	适配治理（Kueue/队列）
整卡独占	整卡	高（天然）	低	低	中（需归因）	强（最简单）
MIG	离散实例	较高（硬切分）	较低	中 - 高（重配置）	中	强
time-slicing	逻辑副本	较低（非强隔离）	较高	中（配置管理）	高（需口径）	中（需约束与验收）
vGPU	虚拟设备	取决于实现	取决于实现	高（栈复杂）	中 - 高	中
DRA Claim	参数化请求	取决于 driver	取决于兑现	中（新对象）	中（更可审计）	强（可结构化治理）

表 1: 典型 GPU 方案决策轴对比

参考依据包括 Kubernetes 对 GPU 的 device plugin 路线、MIG 的安全分区与实例概念、time-slicing 的 oversubscription 与交错运行机制，以及 DRA 的 DeviceClass/ResourceClaim 分配语义。

可直接复用的“评审模板”：否决轴 + 加权轴

为便于实际评审，建议采用如下模板：

否决轴（Gate）

任一不满足，直接淘汰候选方案：

P99/SLO 无法承诺（在线推理必选）。
没有可用的观测与归因口径（无法治理/计费）。
运维重配置成本不可接受（无法规模化）。

加权轴（Weight）

进入候选后按场景加权：

在线推理（多租户）高权重：隔离、尾延迟、计量、运维。
离线训练（吞吐优先）高权重：治理能力、吞吐损耗、兼容性、演进路径。

本章小结：后续章节如何“回填矩阵形成证据链”

从下一章“数据平面谱系”开始，本书会按以下方式回填：

每个机制先落位到本章的轴（资源单位/隔离/尾延迟/运维/计量）。
再给出它与 Kubernetes 原生接口（device plugin / DRA）之间的关系。
最后通过实验在相同硬件（如两台 A100，其中一台启用 MIG）上做对照，形成可复现的证据链。

读完本书后，你应能做到：

看到一个新方案，能在 10 分钟内将其放到正确坐标系。
给出一个可执行的验证计划，而不是停留在“感觉更好”。

总结

本章提出了一套系统的 GPU 方案评审决策轴，帮助你在选型时有据可依。通过资源单位、隔离、性能、治理、运维、计量等多维度分析，可以科学地对比和落位任何新旧方案。至此，控制面部分形成完整闭环：从控制面地图定位问题层级，经调度问题域与工具生态，到组合架构、能力模型与本章决策轴。带着这套尺子进入工作负载实践：推理、训练与分布式框架将把这些抽象维度变成具体的资源行为与验收数字，也是对这把尺子最好的校准。