数据平面谱系：切分、虚拟化与隔离机制大全

草稿

真正理解 GPU 共享，先要看清数据平面的“谱系”，而不是陷入口水战。

本章要解决什么

在 GPU 场景中，“共享”常常被误解为单一能力：要么能共享，要么不能共享。实际上，共享是一组数据平面机制的组合，涉及设备发现与暴露、资源单位的切分方式、隔离与 QoS（Quality of Service，服务质量）的实现位置，以及容器运行时/驱动栈的具体落地方式。

因此，本章不直接比较具体项目（如 HAMi、MIG、GPU Operator、GPUStack 等），而是先给出一张“数据平面谱系”——将所有 GPU 共享手段归类为可验证的机制集合。后续每个项目章节都只是把“它用了哪些机制、补了哪些治理能力”回填到这张谱系里，避免陷入口号之争。

数据平面与控制面的边界（先把锅分清楚）

理解数据平面与控制面的分工，是分析 GPU 共享机制的基础。

Kubernetes 的设备扩展机制（Device Plugin，设备插件）决定了一个基本事实：kubelet 的 Device Manager 负责把“可用设备”暴露为可调度资源，并在 Allocate 阶段做设备侧准备；但它并不定义“更细粒度资源单位、隔离与 QoS”应该如何实现。这使得更细粒度的共享天然倾向于下沉到数据平面实现。

在前面的 Kubernetes 资源模型一章中可以看到，Kubernetes 的语义天然更接近“整卡/离散设备”而不是“连续可分的 CPU”。

进一步，Kubernetes DRA（Dynamic Resource Allocation，动态资源分配）把“设备分配的对象”从扩展资源升级为更可表达的 DeviceClass/ResourceClaim，使“按属性筛选、按声明分配、可共享 claim”等模式更自然。但 DRA 仍然不替你解决隔离机制本身：隔离强度、资源单位、干扰与计量，依然由数据平面决定。

本书的基本坐标系如下：

  • 控制面：处理队列、配额、优先级、公平性、准入与编排策略。
  • 数据平面：处理设备发现/暴露、切分与虚拟化、隔离与 QoS、可观测与计量，以及运行时注入（mount/env/hooks/CDI 等）。
图 1: Kubernetes GPU 共享：数据平面 vs 控制面边界
图 1: Kubernetes GPU 共享：数据平面 vs 控制面边界

数据平面谱系：从"强隔离硬切分"到"软约束过量订阅"

所有“GPU 共享”机制可以粗略放在一条谱系线上：从硬切分（强隔离、单位离散）逐步走向软约束/过量订阅（灵活，但隔离依赖实现与负载行为）。

下图以谱系轴展示常见 GPU 数据平面机制的相对位置与交付层关系。

图 2: GPU 数据平面谱系
图 2: GPU 数据平面谱系

下面按照“机制原语”进行分类（不是按项目），并分别介绍其核心特征和适用场景。

独占（Baseline）：整卡分配 / Pass-through

作为所有对比的基线，Pod/容器独占一整张 GPU。这种方式的优点是性能与故障域最清晰；缺点是利用率在推理、小 batch、间歇任务上通常较低。它本质上不提供“共享”，但会作为后续实验的基线参照（吞吐、P99、显存碎片、稳定性）。

硬切分（Partition）：MIG 这类“硬件级资源单元化”

MIG（Multi-Instance GPU，多实例 GPU）的关键价值不是“能分”，而是把 GPU 的关键路径拆成多个具有更强隔离边界的硬件实例。以 NVIDIA 官方定义，MIG 让每个实例在内存系统关键路径上具备独立隔离：包括 crossbar 端口、L2 cache bank、memory controller 与 DRAM 地址总线等，从而得到更可预测的吞吐与延迟。

这类硬切分机制的典型特征包括：

  • 资源单位离散：获得的是一组固定规格的 slice/instance，而不是任意比例。
  • 隔离强度高：至少在显存带宽/缓存等关键资源上更可控。
  • 动态调整成本高：切分/重配通常需要运维动作，甚至影响同卡其他实例的生命周期与排空策略。
  • 兼容性好：对上层框架基本透明（“像一张小 GPU”）。

适用场景：多租户推理、对 P99 敏感、需要更强“性能可预测性与故障隔离”的场景。

介导虚拟化（Mediated / vGPU）：以 mdev/vGPU 为代表的“多虚拟设备”

vGPU（Virtual GPU，虚拟 GPU）以及 Linux 里的介导设备（mediated device, mdev）思路，是通过虚拟化层将一块物理 GPU 呈现为多个“虚拟 GPU 设备”。这类机制常见于虚拟机（VM, Virtual Machine）场景，也可扩展到容器，但工程复杂度显著提升。NVIDIA 官方 vGPU 文档将其定义为一种图形/计算虚拟化平台，使多台 VM 可同时访问同一块物理 GPU。

这类机制的典型特征：

  • 资源单位通常离散（按 profile/类型划分），但比 MIG 更“软件化”。
  • 隔离与 QoS 依赖实现：隔离边界通常弱于硬切分，但比纯时间片更可控（取决于实现与硬件能力）。
  • 运维与许可复杂：驱动栈、宿主/来宾驱动、虚拟化层集成、部分场景下商业许可等，会使“可部署性”成为主要约束。

适用场景：强虚拟化/VM 优先的企业环境、需要 VM 级隔离边界、或已有既定 vGPU 栈的组织。

时间片（Time-Slicing）：在同一物理 GPU 上交错运行多个工作负载

时间片共享的核心是过量订阅（oversubscription）：多个 Pod/容器被调度到同一张 GPU 上，由驱动/插件在执行层面交错运行。NVIDIA GPU Operator 明确提供了 time-slicing 的配置路径，本质是通过设备插件的扩展能力实现“共享访问”。

需要特别强调，时间片与 MIG 的差异非常明显。部分平台文档也指出，MIG 提供内存与故障隔离，而时间片并不具备同等强度的隔离，更多是为了提升利用率，适配轻量推理/预处理等场景。

这类机制的典型特征：

  • 资源单位“看起来可分”（可以声明更多份额），但隔离往往较弱。
  • 性能与尾延迟不确定：尤其在显存压力、kernel launch 冲突、PCIe 抖动等情况下，P99 往往是首要风险点。
  • 动态灵活：适合快速提高利用率，但需要强观测与强准入策略来收敛风险。

适用场景：轻量推理、容忍干扰、以利用率为先且有完善观测/限流/准入的场景。

进程级协作共享：CUDA MPS 这类“协作式多进程并发”

MPS（Multi-Process Service，多进程服务）是 NVIDIA 提供的一种 CUDA API 兼容实现，通过客户端 - 服务端架构让多个进程更高效地共享 GPU 的执行资源。该机制常用于 HPC（High Performance Computing，高性能计算）/MPI 等场景，以利用 Hyper-Q 能力。

这类机制的典型特征：

  • 更像“并发执行效率优化”而非“资源治理”：改善多进程并发的利用方式，但并不天然提供“多租户隔离语义”。
  • 适配负载类型：对某些 workload 显著收益，但对推理/多租户治理不一定直接等价。
  • 工程落点微妙：经常出现在数据平面方案的“内部实现”中，而不是用户显式选择的产品特性。

适用场景：协作式多进程计算、HPC/训练类并发模式；在平台侧更常作为内部优化手段。

容器设备暴露与注入机制：CDI 让“怎么把设备交付给容器”更标准化

无论你使用 MIG、vGPU 还是时间片，最终都要回答一个问题：设备如何以一致、可审计、可组合的方式注入到容器运行时。NVIDIA Container Toolkit 已支持生成 CDI（Container Device Interface，容器设备接口）规范，用于标准化“容器如何使用设备”的描述。

这不是隔离机制本身，但它影响方案的可落地性：

  • 能否把设备注入从“运行时魔法参数”变成“声明式、可审计、可复制的交付单元”。
  • 能否在多种运行时/编排方式中复用同一套设备交付逻辑。

五维对比基线：把概念争论变成可回填的矩阵

为了便于后续章节统一对比，下面给出一张五维对比表，涵盖主流机制的资源单位、隔离强度、性能损耗、动态调整成本和兼容性等维度。

表格用于对比各类 GPU 共享机制的核心特征：

机制类型资源单位隔离强度性能损耗/干扰动态调整成本兼容性/落地复杂度
独占（整卡）整卡最高最稳定低最简单
硬切分（MIG）离散实例高（硬件路径隔离）较稳定中 - 高较好
vGPU/mdev离散 profile/虚拟设备中 - 高（依实现）中（依实现）中高（栈复杂）
时间片份额/过量订阅（时间片）低 - 中干扰显著（看负载）低中（需策略兜底）
MPS非显式单位低（偏效率优化）依负载而定低中（对模型/作业形态敏感）
CDI（交付层）设备交付单元不定义隔离不直接影响低降低集成碎片
表 1: GPU 共享机制五维对比基线

组合规律：端到端方案通常是“控制面治理 + 数据面机制 + 观测计量”

理解数据平面谱系后，端到端方案的组合就会更清晰：

  1. 先确定资源单位：整卡 / MIG / vGPU / 时间片份额。
  2. 再补齐治理能力：队列、配额、公平性、准入、优先级（控制面）。
  3. 最后用观测与计量闭环：否则“共享”只是在赌负载行为（后续《观测与计量》《验收与容量》会详细展开）。

本章小结与下一步阅读建议

通过本章梳理，你可以更系统地理解 GPU 共享的底层机制和工程落点：

  • 如果你追求“可声明、可治理、可验收”的共享，第一步不是选项目，而是先落到谱系上，明确你要的隔离强度与资源单位。
  • MIG 与时间片不是同一类问题的不同实现：它们的隔离语义与风险曲线完全不同。
  • Kubernetes 的设备扩展能力（Device Plugin / DRA）解决“如何让调度器看到设备”，但不替你解决“如何切分与隔离”。
  • 如果你发现团队在争论“谁更强”，建议把争论强制落到上面的五维矩阵里：只讨论机制与可验证指标，不讨论口号。

下一章将从谱系切入“硬切分”的代表机制——MIG，并用实验验证隔离与干扰的边界条件。

总结

本章从数据平面谱系的角度，系统梳理了 GPU 共享机制的多样性与复杂性。通过对比不同机制的特征与适用场景，为后续章节深入探讨具体机制奠定了基础。理解这些基础知识后，读者可以更有针对性地选择和优化适合自己需求的 GPU 共享方案。

参考文献

创建于 2025/12/30 更新于 2025/12/30 3762 字 阅读约 8 分钟