决策轴：评估任何 GPU 方案的统一维度
选型评审时，方法论比“谁更强”更重要。用一套统一决策轴，才能让每个 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：资源单位（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 | 取决于兑现 | 中（新对象） | 中（更可审计） | 强（可结构化治理） |
参考依据包括 Kubernetes 对 GPU 的 device plugin 路线、MIG 的安全分区与实例概念、time-slicing 的 oversubscription 与交错运行机制，以及 DRA 的 DeviceClass/ResourceClaim 分配语义。
可直接复用的“评审模板”：否决轴 + 加权轴
为便于实际评审，建议采用如下模板：
否决轴（Gate）
任一不满足，直接淘汰候选方案：
- P99/SLO 无法承诺（在线推理必选）。
- 没有可用的观测与归因口径（无法治理/计费）。
- 运维重配置成本不可接受（无法规模化）。
加权轴（Weight）
进入候选后按场景加权：
- 在线推理（多租户）高权重：隔离、尾延迟、计量、运维。
- 离线训练（吞吐优先）高权重：治理能力、吞吐损耗、兼容性、演进路径。
本章小结：后续章节如何“回填矩阵形成证据链”
从下一章“数据平面谱系”开始，本书会按以下方式回填：
- 每个机制先落位到本章的轴（资源单位/隔离/尾延迟/运维/计量）。
- 再给出它与 Kubernetes 原生接口（device plugin / DRA）之间的关系。
- 最后通过实验在相同硬件（如两台 A100，其中一台启用 MIG）上做对照，形成可复现的证据链。
读完本书后，你应能做到：
- 看到一个新方案，能在 10 分钟内将其放到正确坐标系。
- 给出一个可执行的验证计划，而不是停留在“感觉更好”。
总结
本章提出了一套系统的 GPU 方案评审决策轴，帮助你在选型时有据可依。通过资源单位、隔离、性能、治理、运维、计量等多维度分析，可以科学地对比和落位任何新旧方案。后续章节将以本章为基础，逐步回填实验数据，形成完整的证据链，助力你做出更理性的技术决策。
参考文献
- Device Plugins - kubernetes.io
- Time-Slicing GPUs in Kubernetes — NVIDIA GPU Operator - docs.nvidia.com
- Workload | Kueue - Kubernetes - kueue.sigs.k8s.io
- NVIDIA Multi-Instance GPU User Guide - docs.nvidia.com
- Schedule GPUs - kubernetes.io
- Introduction — NVIDIA Multi-Instance GPU User Guide - docs.nvidia.com
- Dynamic Resource Allocation - kubernetes.io
- Cluster Queue | Kueue - Kubernetes - kueue.sigs.k8s.io
- DCGM-Exporter - docs.nvidia.com