GPU 资源治理为什么难
GPU 资源治理的难点并非算力本身，而在于多维资源属性与平台治理之间的天然张力。理解这些根因，是实现高效共享与隔离的前提。
本章将从资源属性出发，系统解释 GPU 为什么天然不能“像 CPU 一样好调度”：显存成为第一约束、拓扑影响真实吞吐、共享带来不可预测干扰，尤其是在推理场景下，P99 尾延迟问题尤为突出。我们将通过一组典型事故模式建立直觉，并明确本书后续章节要解决的核心矛盾：如何把共享从“能跑”升级为“可声明、可治理、可验收”。
GPU 之难，不在“算力不够”，而在“资源形态不服从平台治理”
在 Kubernetes 平台中，CPU 和内存之所以易于调度，本质在于它们更接近“可拆分、可抢占、可度量、可隔离”的理想资源形态：
- CPU 时间片天然可复用；
- 内存可通过 cgroup 做硬约束，且 OOM（Out Of Memory，内存溢出）是清晰的失效方式；
- 资源消耗与 QoS（Quality of Service，服务质量）问题在平台侧有成熟的治理语义（requests/limits、优先级、抢占、配额）。
相比之下，GPU 的核心挑战在于同时具备 强状态（stateful）、强耦合（coupled）、强多维（multi-dimensional） 三个特征，导致平台难以仅靠“声明式配额”获得确定性治理结果。 下图展示了 GPU 资源治理的三个核心维度及其带来的后果：
GPU 是多维资源：显存、算力、带宽、缓存、拓扑缺一不可
GPU 的可用性并非单一标量。实际场景中，你会遇到如下典型问题：
显存先耗尽：尤其在大语言模型（LLM）推理的 KV cache（键值缓存）场景下，显存会随请求数与上下文长度动态增长。显存不仅要“够用”，还要“连续可复用”。例如，vLLM 的 PagedAttention 机制正是为了解决 KV cache 的浪费与碎片化问题，通过类似“分页”的方式降低碎片与冗余。相关论文报告显示，在相同延迟水平下可显著提升吞吐（如相较 FasterTransformer/Orca 可提升 2–4 倍）。(见 Efficient Memory Management for Large Language Model Serving with PagedAttention)
算力并不等价于性能：即使分配了相同的 TFLOPS（万亿次浮点运算每秒），在不同并发、不同 kernel 组合、不同 stream 行为下，实际性能可能完全不同。
拓扑决定上限：从单机 PCIe/NVLink 到多机网络（以及 NUMA, Non-Uniform Memory Access，非一致性内存访问亲和性），都会让“同样的 GPU 数量”对应完全不同的有效吞吐。
因此，GPU 资源治理不能简单地将其视为“一个整数”，而必须明确治理目标与资源单位。 以下是 GPU 多维资源属性与它们在共享时带来的核心问题：
GPU 共享的核心矛盾：利用率 vs 隔离性 vs 可预测性
在实际集群中，GPU 共享带来的挑战主要体现在利用率、隔离性和可预测性三者之间的权衡。
“共享能跑”不等于“共享可控”
许多集群采用“整卡独占”作为默认做法：每个 Pod 申请 nvidia.com/gpu: 1，调度器仅做整数匹配，设备插件负责分配设备给容器。(见 Kubernetes Device Plugin 文档)
这种方式实现简单，但会造成显著资源碎片：大量推理、小模型或轻量任务无法充分利用整卡，却被迫独占。
因此，业界自然追求 GPU 共享。但一旦共享发生，随之而来的问题包括：
- 干扰（interference）：多个工作负载在同一 GPU 上争抢 SM（Streaming Multiprocessor）、显存带宽、缓存，性能波动呈现“非线性”，尤其体现在尾延迟（P99）。
- 可预测性缺失：难以保证“某租户获得 30% GPU 就一定能达到 X QPS / Y P99”。
- 计量困难：CPU 可用 cgroup + 时间计量，GPU 的“算力占用”缺乏同等简单且一致的度量方式，尤其跨框架、跨运行时。
两条典型路径：强隔离的空间切分 vs 协作式共享
针对 GPU 共享，业界主要有两条典型技术路径：
MIG（Multi-Instance GPU，空间切分，强隔离）
- 在 A100 等支持 MIG 的 GPU 上，可将一个物理 GPU 切分为多个彼此隔离的实例，每个实例拥有专属的计算与内存资源，并在系统视角表现为独立 GPU 设备。官方文档强调其“专用 compute 与 memory”，最多可切分为多个实例以供不同应用同时使用。(见 NVIDIA MIG User Guide)
- 代价在于资源单位离散、重配置有运维成本，并且平台调度与设备形态耦合更紧。
MPS（Multi-Process Service，协作式共享，降低上下文成本）
- NVIDIA MPS 允许多个进程共享 CUDA 上下文与调度资源，从而提升并发与利用率，并减少上下文切换成本。(见 NVIDIA Multi-Process Service)
- 但 MPS 并非强隔离方案，更像“协作并发加速器”，对多租户 QoS、强隔离与严格配额的支撑有限。
本书后续将以这两条路径为“数据平面谱系”的关键锚点，进一步探讨更细粒度、更平台化的共享方式（如 HAMi 方向）。 下表总结了三种典型方案的权衡关系，帮助你理解为什么没有"完美方案"，只有适合特定场景的选择：
Kubernetes 语义层面的限制：调度器看不到“GPU 的真实形态”
Kubernetes 的 device plugin 框架，旨在“将设备作为资源广告出来，并让 kubelet 能分配设备给容器”。这是扩展硬件资源的标准机制，但其资源表达天然偏向“可分配的离散资源”。
这带来如下直接后果：
- 资源单位倾向于整数：最典型如
nvidia.com/gpu: 1；即便引入 MIG，通常也表现为不同 profile 的离散资源（如nvidia.com/mig-*）。 - 调度阶段缺少连续约束：调度器难以基于“显存剩余”“带宽压力”“推理 KV cache 形态”等连续变量做全局决策。
- QoS 难以端到端闭环：即使多个 Pod 被调度到同一张卡，平台仍缺乏标准化机制来保证它们的性能边界与相互影响上限。
因此，真正的平台化 GPU 管理通常需要将能力拆解为两部分：
- 控制面（Control Plane）：决定谁能用、何时用、用多少，包括排队、配额、优先级、公平性、准入等。
- 数据平面（Data Plane）：负责如何切分、隔离、计量与兑现，包括虚拟化/切分、隔离、资源分配与观测。
这正是本书结构设计的出发点。下图展示了平台化 GPU 管理的整体架构，其中控制面与数据平面通过闭环反馈协同工作：
一组“事故模式”帮助你快速识别问题本质
在真实集群中，以下事故模式频繁出现（它们往往不是偶发 bug，而是机制边界被触发）：
- 平均值很好，P99 崩溃：共享引入争用，尾延迟放大，尤其在推理服务并发上升时。
- 显存看似够，但还是 OOM：KV cache 动态增长与碎片化导致“不可用的剩余”。
- 同配额不同性能：所谓“30% GPU”在不同 workload 组合下对应完全不同的真实吞吐。
- 调度成功≠可用：Pod 虽然调度成功，但实际吞吐低到不可接受，最终只能人工迁移或隔离。
- 运维重配置触发连锁反应：如 MIG profile 调整导致设备集合变化，需要平台具备更强的“资源形态变更”承受能力。
这些现象将贯穿你对 MIG、HAMi、Volcano、Kueue 以及 vLLM/PyTorch 行为的理解。
以下是这些常见事故模式的详细分类，每一种都代表了平台治理的某个薄弱环节：
总结
GPU 资源治理的真正目标，不是“把 GPU 塞满”，而是实现可治理性：
- 让共享成为一种可声明、可审计、可验收的能力；
- 让隔离与利用率在可比较的决策轴上权衡；
- 让控制面与数据平面协同，形成端到端闭环（准入/配额 → 分配/隔离 → 观测/计量 → 验收/迭代）。
下一章将介绍这套闭环的总框架：GPU 资源控制面地图，并以此作为后续所有项目与实验的统一归类方式。