GPU 虚拟化与切片：MIG、vGPU 与时分复用的三种共享路线

问题：GPU 太贵，但利用率太低

GPU 是 AI 基础设施里最贵的资产，而它的真实利用率常常低得尴尬：推理服务在低峰期只吃 10–20% 的算力、开发者的实验卡一天空闲 20 小时、小模型的推理占着一张大卡的零头。共享 GPU 是省钱的本能，但 GPU 与 CPU 的共享有一个根本差异：GPU 显存是硬边界、算力是软共享——显存装不下就 OOM，而算力可以排队。GPU 共享的三条技术路线（MIG、vGPU、时分复用），本质上是在「隔离强度」与「共享粒度」之间做不同的取舍。

路线一：MIG——硬件级的物理切分

MIG（Multi-Instance GPU）是 NVIDIA（Ampere 及之后的数据中心卡）提供的硬件级切分：一张 GPU 在硬件层面被切成多个独立的实例——每个实例有自己的 SM（计算单元）、显存、缓存与带宽，物理隔离。A100 可切 7 份（每份 1/7 的算力与显存）、H100 类似。MIG 的特性：隔离是硬件强制的——一个实例的负载波动不会影响其他实例（性能噪声为零）、故障域隔离（一个实例出错不波及其他）；代价是粒度固定（只能按预定义的档位切，1g.5gb/2g.10gb/3g.40gb 等）、切分后不能动态调整（改档位要停服务）。适用场景：多租户的推理服务（严格的性能隔离与公平——SaaS 的多客户推理）、小模型的密度部署（一张 A100 跑七个 7B 模型的实例）。

MIG 与 Kubernetes 的结合：Device Plugin 支持 MIG 的三种策略（single 整卡、single 只出一个 MIG 实例、mixed 多实例分别分配）——K8s 篇的 Device Plugin 机制在 MIG 场景的延伸。

路线二：vGPU——虚拟化的直通与分片

vGPU（NVIDIA Virtual GPU 技术）是虚拟机路线：GPU 通过虚拟化层分配给多个虚拟机，每个 VM 看到一块「虚拟 GPU」。vGPU 的两种形态：时间片调度（多个 VM 分时使用同一块物理 GPU 的算力——算力是软共享，一个 VM 吃满会挤占别人）、以及MIG-backed vGPU（vGPU 建立在 MIG 实例上——硬件隔离 + 虚拟化的结合，兼具两者优点）。vGPU 的适用场景：VDI 与图形工作站（给虚拟机里的用户一个 GPU 桌面）、企业的 GPU 池化（GPU 放机房、员工虚拟机远程用）。与 MIG 的对比：vGPU 的时间片模式隔离弱（算力争抢的噪声存在）、但灵活（粒度更细、可动态调整）；MIG-backed 模式隔离强但继承 MIG 的固定粒度。vGPU 的许可成本：NVIDIA 的 vGPU 需要额外的许可订阅（每用户/每年）——共享的省卡钱与许可费要一起算（这是 vGPU 方案常被忽略的成本项）。

路线三：时分复用——软件层的算力调度

时分复用是最轻量的共享：不切硬件，多个进程/容器共享整卡，靠软件调度（MPS、时间片、或干脆靠 CUDA 的排队）分时使用。NVIDIA MPS（Multi-Process Service）：让多个进程的 kernel 并发执行在同一块 GPU 上（默认模式下进程的 kernel 是串行排队的，MPS 让它们真正并发）——小模型的推理叠加能提升整卡利用率。时分复用的特性：零硬件要求（任何卡都能用）、粒度最细（显存靠 CUDA 的显存分配自然共享、算力靠调度）、但隔离为零——一个进程的 OOM 会影响整卡（显存是共享的）、一个进程的负载会挤占邻居（性能噪声真实存在）。适用场景：内部的实验与开发环境（团队共享一张卡跑实验——噪声可容忍）、单租户的算力填充（同一业务的小模型堆叠）。

三条路线的对照与选型

选型的决策式：邻居的性能噪声能不能接受——不能（多租户的商业服务）→ MIG；虚拟机形态的需求（VDI、池化）→ vGPU；内部自己人共享 → 时分复用。以及一个反直觉的提醒：共享不总是省钱——共享引入的运维复杂度（调度、监控、故障排查）、性能噪声导致的超时重试、以及「为了共享而把服务堆在一起」的故障耦合，都可能吃掉省下的卡钱——共享的决策要按「利用率 × 隔离需求」算，而不是按「卡有多贵」的本能。

GPU 共享的进阶模式：推理服务的批内共享与 LLM 场景的特殊性

GPU 共享（正文三路线）在 LLM 推理场景有一个特殊的进阶模式：推理引擎的「批内共享」——vLLM 类引擎天然是「多请求共享一张卡」的架构（continuous batching 的批内共享，本库 vLLM 篇）——多个用户的请求在同一时刻进入同一个 batch，共享 GPU 的算力。批内共享与 MIG 的对比：批内共享的利用率极高（引擎的动态 batch 填满 GPU——无预留的浪费）、隔离为零（batch 内的请求互相影响——长请求拖慢同批），MIG 的利用率较低（预留的固定资源可能闲置）、隔离最强。LLM 场景的批内共享特别有效的理由：LLM 的推理是「内存带宽受限」而非算力受限（decode 阶段）——batch 增大几乎不增加单请求的延迟（decode 的带宽有余量）——LLM 是最适合批内共享的负载。工程上的组合：批内共享做「同业务的并发」+ MIG 做「多业务的隔离」——一层引擎内共享、一层硬件间隔离——两层组合覆盖从单业务到多租户的全谱系。时分复用（MPS）在 LLM 场景的位置：MPS 的 kernel 并发对 LLM 的收益有限（LLM 的 decode 是带宽瓶颈而非算力瓶颈——并发 kernel 抢带宽反而互拖）——MPS 更适合计算密集的小模型（视觉、embedding），不适合 LLM 的 decode——共享技术的选型还要匹配负载的特性。

GPU 共享的监控与治理：共享环境的可观测

GPU 共享环境的监控与治理（正文监控的展开）——共享让可观测变得更关键。共享环境的监控维度。维度一：按实例/租户的用量——MIG 实例的利用率（DCGM 的 per-instance 指标）、vGPU 的用量（许可与用量面板）、MPS 的进程级用量（谁在用 GPU、用了多少——共享环境的责任归属）。维度二：噪声的检测——邻居效应的量化：共享环境的延迟抖动与独占环境的对比（噪声的测量——本库压测篇的对比实验）、降频与热节流的共享放大（一张卡的热影响同卡的邻居）。维度三：公平性的审计——多租户共享下的用量公平（配额的执行与实际用量的对齐——本库多租户篇的公平监控）。治理的策略：共享环境的配额与限额（显存的硬限、算力的软限——防失控）、优先级的仲裁（资源紧张时谁让路——共享环境的调度纪律）、以及「共享的自查」：定期评估「共享的实际利用率 vs 独占的理论利用率」——共享的收益要用数据持续验证（利用率没上去的共享是纯增复杂度）。治理的收束：GPU 共享让「一台设备的运维」变成「一个资源池的运维」——监控的粒度、公平的机制、噪声的治理，是共享环境的运维三件套；共享不是配置一次就完事，是需要持续运营的资源体系。

GPU 共享的决策案例：三种场景的路线选择

用三个真实场景（脱敏）演示 GPU 共享的决策过程。场景一：SaaS 推理服务商——多个企业客户共享推理服务、SLA 要求严格的性能隔离。分析：噪声不可接受（客户 SLA）→ MIG 是唯一选项（硬件隔离）。场景二：企业内部 AI 平台——内部团队共享一张 A100 做实验。分析：噪声可容忍（内部自己人）→ 时分复用（MPS）是性价比之王（零成本共享）。场景三：GPU 桌面虚拟化——给远程员工配 GPU 工作站。分析：需要 VM 形态 → vGPU 的主场（MIG-backed vGPU 兼具隔离）。三个场景的决策链：隔离需求（硬/软/无）→ 硬件兼容（MIG 卡/任意卡）→ 成本（vGPU 的许可费）。以及一个反直觉的收尾：很多团队过度追求 GPU 共享，忽略了「利用率提升」的另一半——如果推理服务的 batch 策略没调好，共享一张卡的利用率可能还不如独占两张卡各自跑 batch——共享的前提是「单卡的利用率已经被榨干」，否则先优化 batch 再谈共享。

GPU 共享的监控实现

GPU 共享的监控实现：DCGM 与 Prometheus 的组合是 GPU 监控的事实标准。DCGM 的能力：NVIDIA 数据中心 GPU 监控框架——GPU 的利用率、显存、温度、功耗、ECC 错误的全量指标（本库 GPU 故障篇的巡检数据源）、MIG 实例级的指标（每个 MIG 实例的独立监控——共享环境的 per-instance 观测）。Prometheus 的采集：dcgm-exporter 把 DCGM 指标导出为 Prometheus 格式，Grafana 的可视化面板（GPU 的实时监控仪表盘：集群级的 GPU 热力图、利用率的分布）。共享环境的专项监控：按实例/租户的用量归因（每个 MIG 实例/每个进程的 GPU 占用——DCGM 的 XID 与进程指标）、噪声的量化（共享环境的延迟抖动对比独占——P99 的对比是噪声的度量）。监控的组合收束：DCGM（数据源）+ Prometheus（采集存储）+ Grafana（可视化）等于 GPU 可观测的黄金三件套——共享环境的每一层都要有指标覆盖，否则共享就是盲飞。

小结

GPU 共享的三条路线：MIG 硬件切分（零噪声、固定粒度，多租户推理的首选）、vGPU 虚拟化（VM 形态、许可成本、VDI 与池化的主场）、时分复用（零门槛零隔离，内部实验与算力填充）。选型的核心问题是「邻居噪声能不能接受」——共享 GPU 的本质交易，是用隔离性换利用率；隔离性值多少钱，决定走哪条路线。