GPU多租户共享：MIG/MPS/vGPU推理优化

可视化演示

GPU共享背景

你的餐厅越来越大，但“一口神锅”的价钱抵得上十口普通锅。更心疼的是，神锅多数时候只烧一小撮火——老板你夜里算账，发现燃气费如流水，锅却大半时间闲着。这正是 GPU 推理集群的真实写照：一块 A100 售价数万元，但在很多推理服务中利用率只有 20%-30%。为什么？因为单个模型推理任务往往只用到 GPU 的一角，却独占整卡。

多租户推理场景让问题变得更加尖锐。一个 RAG 客服系统里，有嵌入模型、重排模型、大语言模型三拨任务；训练部门要跑实验，在线推理要保延迟，离线批处理要冲吞吐。如果每个租户都买一块卡，成本爆炸；如果都挤在一块卡上，又会互相干扰。

于是，GPU 共享成为必然。通过 MIG、MPS、vGPU 三种技术，多个租户可以复用同一块 GPU，各取所需。GPU 利用率从“一人包场”的 20%，提升到“多人拼桌”的 70% 以上。共享的核心目标有三个：提升算力利用率、满足租户隔离需求、降低整体拥有成本。这就像餐厅把大厅改成卡座、包间、吧台三种形态，让每位客人都能找到合适的位子，让每一寸空间都产生营收。

MIG硬件切分

MIG（Multi-Instance GPU，多实例 GPU）像是给神锅焊上物理隔板。隔板一旦装好，左边炖汤的锅气飘不到右边炒菜的区域——每个分区拥有独立的显存带宽、SM 计算单元和 L2 缓存，硬生生把一块大 GPU 变成了多个“小 GPU”。这种硬件级隔离带来两个直接好处：租户之间的性能干扰极小，故障也不会跨区蔓延。

从技术实现上看，MIG 依赖 GPU 硬件底层的资源切片能力。以 A100 为例，它可支持最多 7 个 GPU 实例（MIG 7-way），每个实例独占一部分 SMs（流式多处理器）和显存切片。比如将一个 40GB 显存的 A100 切成 5+5+10+20 四个实例，分别服务四个不同规模的模型。每个实例在 CUDA 层面表现为独立的 CUDA 设备，应用程序完全无感。

MIG 的切分配额可用公式描述：

MIG 的短板也很明显：隔板是焊死的，一旦切好就难以动态调整。如果 7 个实例中有一个长期空闲，它的算力无法临时借给邻居。它适合租户数量稳定、隔离要求高的场景——就像餐厅的包间，隔音好、私密性强，但包间空着时不能临时拆墙并入大厅。

MPS协作共享

MPS（Multi-Process Service，多进程服务）则是另一种思路：不砌墙，让多位厨师共享同一口锅。多个进程可以同时把任务提交给 GPU，GPU 的 SM 计算单元在进程间按时间片和并发块进行调度。MPS 的核心理念是“协作式共享”——利用 GPU 强大的并行能力，让多个小任务填满原本闲置的 SM。

MPS 的关键区别在于：计算单元是共享的，但显存空间做了保护。每个进程拥有独立的地址空间，MPS 服务负责在进程间切换和管理。它的调度开销很低，因为不需要经过虚拟化层，CUDA 应用可以直接使用。这使得 MPS 特别适合大量中小型推理任务并发执行的场景，例如同时服务成百上千个在线推理请求。

MPS 的吞吐优势可以用一个简单的并发模型来理解：

MPS 的代价在于隔离性较弱：由于共享计算单元，某个租户的极端计算任务可能抢占 SM，影响邻居的延迟。显存虽然做了空间隔离，但缓存和带宽仍是共享的，存在一定程度的争抢。它就像开放式厨房的公共灶台——效率高、翻台快，但油烟和噪音难免互相影响，适合对隔离要求不苛刻、追求吞吐最大化的批处理场景。

vGPU虚拟化

vGPU 走的是“虚拟中央厨房”路线。它不修改 GPU 物理结构，而是在软件层创建一个虚拟化平台，把一块 GPU 变成多个“虚拟 GPU 设备”，分配给不同的虚拟机或容器。每个租户看到的是一块完整的虚拟 GPU，但实际上只是这块 GPU 的一部分资源，由虚拟化层（如 NVIDIA vGPU 方案中的 vGPU Manager）负责切分和调度。

vGPU 的核心架构分为三层：底层是物理 GPU 的资源池，中间是虚拟化层（Hypervisor 或容器运行时），上层是挂载虚拟 GPU 的租户环境。虚拟化层像一个聪明的调度总管，把 GPU 的计算单元按时间片轮转、按比例配额分配给各虚拟 GPU。租户之间不仅隔离了显存和算力，还隔离了驱动和故障域——一个租户的 CUDA 驱动崩溃不会影响其他租户。

vGPU 的灵活性体现在“动态配比”上。你可以给租户 A 分配 50% 的算力和 8GB 显存，给租户 B 分配 30% 算力和 4GB 显存，甚至可以随时调整。这种配比能力用公式表示：

vGPU 的代价是性能开销。虚拟化层每次指令转发都会产生一定延迟，相比裸金属的 MIG/MPS 要高。但它带来的收益是灵活性和隔离性的平衡。在公有云和多租户平台上，vGPU 是主流选择——云厂商可以动态创建、销毁、调整 GPU 实例，租户则获得类似独立 GPU 的使用体验。它就像中央厨房的标准化档口，租户拎包入驻，平台统一管理水电燃气。

指标对比

三种方案摆在面前，如何选？需要从三个关键指标对比：切分粒度、性能开销、调度延迟。

MIG 的切分粒度最“粗”，但它提供的是硬件级隔离——一个 MIG 实例上的任务崩溃，完全不影响其他实例。MPS 的切分粒度最“细”，它可以做到 SM 级别的资源共享，让 GPU 利用率最大化。vGPU 介于两者之间，按比例切分，但灵活性最高。

性能开销方面，MIG 几乎为零，因为硬件隔断后各实例独立运行。MPS 开销很小，主要是进程切换和显存保护的额外工作。vGPU 的开销最大，虚拟化层的指令翻译和上下文切换会带来 5%-10% 的性能损失。

调度延迟的差异也很关键。MIG 实例一旦创建，调度延迟近似于裸金属。MPS 的调度器在进程间切换，延迟在微秒级。vGPU 要经过虚拟化层的软件调度，延迟略高，但在批处理场景中可接受。

回到厨房比喻：MIG 是私密包间，适合宴请贵客；MPS 是开放式灶台，适合快速翻台的快餐；vGPU 是出租档口，适合商场美食广场。没有哪个绝对最好，关键看你经营什么类型的餐厅。

选型决策

选型决策要结合具体推理服务场景。在 RAG 客服系统中，嵌入模型是高频低算力请求，重排模型是中频中算力，大语言模型是低频高算力。三者混合部署在一张 A100 上，就需要考虑隔离需求：如果客服系统有严格的响应时间要求，大模型的突发推理负载不能拖慢嵌入模型，这时 MIG 的硬件隔离是首选；如果只是离线批量处理，MPS 能把利用率推到极致。

隔离需求评估是第二步。租户之间是否有 SLA 隔离要求？是否可能出现一个租户的恶意或异常任务蚕食他人资源？如果答案是肯定的，优先 MIG 或 vGPU。如果租户都是可信的内部团队，MPS 的性价比更高。

运维复杂度也要纳入考量。MIG 配置后重启生效，调整需要重新规划；MPS 部署最简单，但需要监控各进程的资源占用；vGPU 需要维护虚拟化平台和驱动版本，运维要求最高。一个务实的策略是：核心生产环境用 MIG 保证稳定性，开发测试环境用 MPS 提升利用率，公有云或对外服务用 vGPU 提供弹性。

选型就像餐厅定位：高档会所选包间（MIG），快餐连锁选开放式厨房（MPS），美食广场招商选档口（vGPU）。你的客户是谁、卖什么菜、翻台率多少，决定了你要怎么装修厨房。

生产落地

选定方案只是开始，生产落地才是真正的考验。首先是驱动与镜像管理。MIG 需要特定驱动版本（如 CUDA 11.0+ 和对应 vGPU Manager），且不同实例要匹配不同的 CUDA 运行时。vGPU 需要宿主机安装 NVIDIA vGPU 驱动，虚拟机内安装对应 Guest 驱动。通过容器镜像统一封装 CUDA 版本和推理框架，可以大幅减少环境不一致问题。

配额监控与告警是第二步。部署 GPU 共享后，必须实时监控每个租户的显存占用、SM 利用率、显存带宽和温度。可以基于 DCGM（NVIDIA Data Center GPU Manager）采集指标，设定告警阈值——当某租户的显存逼近配额上限或 SM 利用率持续超过 90% 时触发告警。没有监控的共享，就像不看燃气表的厨房，迟早出事故。

多卡集群调度是第三步。在 Kubernetes 集群中，GPU 共享需要结合设备插件方案。NVIDIA 官方提供 MIG 设备插件，支持将 MIG 实例暴露为可调度的资源。vGPU 方案通常由云厂商的调度器统一管理。调度策略要支持亲和性（将同一模型实例调度到同一 GPU）、反亲和性（避免高竞争租户共处一卡）以及资源预留。

展望未来，GPU 共享技术正朝着更细粒度、更动态的方向演进。MIG 正在支持动态切分；vGPU 的虚拟化层不断下沉，性能损耗逐渐降低；池化算力与 Serverless 推理结合，让租户按需取用、按量计费。不变的原则是：用最合适的隔离级别，服务最合适的负载。就像经营餐厅，无论工位怎么变，核心永远是让每一道菜（推理任务）及时上桌，让每一寸厨房（GPU）都创造价值。

AI 应用场景

Python 演示

"""MIG / MPS / vGPU 三种 GPU 共享方案的利用率模拟器。"""import random  class GPU:    def __init__(self, name, total_sm, total_mem):        self.name = name        self.total_sm = total_sm        self.total_mem = total_mem        self.used_sm = 0        self.used_mem = 0     def reset(self):        self.used_sm = 0        self.used_mem = 0     def utilization(self):        sm_ratio = self.used_sm / self.total_sm        mem_ratio = self.used_mem / self.total_mem        return 0.6 * sm_ratio + 0.4 * mem_ratio  def mig_partition(gpu, slices):    """MIG: 物理切分为多块，每块独占 SM 与显存。"""    gpu.reset()    total_sm = sum(s[0] for s in slices)    total_mem = sum(s[1] for s in slices)    assert total_sm <= gpu.total_sm and total_mem <= gpu.total_mem    gpu.used_sm = total_sm    gpu.used_mem = total_mem    return [{"sm": s, "mem": m} for s, m in slices]  def mps_schedule(gpu, tasks):    """MPS: 多进程共享 SM，显存各自保护，按需叠加。"""    gpu.reset()    for sm, mem in tasks:        gpu.used_sm += sm        gpu.used_mem += mem    return {"tasks": len(tasks), "sm_used": gpu.used_sm}  def vgpu_allocate(gpu, shares):    """vGPU: 按比例分配算力与显存，总和不超 100%。"""    gpu.reset()    sm_budget = int(gpu.total_sm * sum(s[0] for s in shares))    mem_budget = int(gpu.total_mem * sum(s[1] for s in shares))    gpu.used_sm = sm_budget    gpu.used_mem = mem_budget    return {"sm_budget": sm_budget, "mem_budget": mem_budget}  def main():    gpu = GPU("A100-40G", total_sm=108, total_mem=40)    mig_slices = [(30, 10), (30, 10), (20, 8), (20, 8)]    mig_result = mig_partition(gpu, mig_slices)    print("MIG 切分实例:", mig_result)    print("MIG 利用率:", round(gpu.utilization(), 3))     gpu.reset()    tasks = [(8, 2) for _ in range(10)]    mps_result = mps_schedule(gpu, tasks)    print("MPS 任务数:", mps_result["tasks"])    print("MPS 利用率:", round(gpu.utilization(), 3))     gpu.reset()    shares = [(0.4, 0.4), (0.3, 0.3), (0.2, 0.2)]    vgpu_result = vgpu_allocate(gpu, shares)    print("vGPU 预算:", vgpu_result)    print("vGPU 利用率:", round(gpu.utilization(), 3))  if __name__ == "__main__":    main()

1. class GPU:定义 GPU 资源模型，记录总 SM 数、总显存和当前已用量，是三种共享方案的“神锅”基础。
2. def utilization(self):按 60% SM 占用 + 40% 显存占用加权计算 GPU 综合利用率，模拟真实监控指标。
3. def mig_partition(gpu, slices):模拟 MIG 物理切分：每个切片（SM, 显存）独占资源，总和不能超限。
4. def mps_schedule(gpu, tasks):模拟 MPS 协作调度：多进程任务按需叠加到 SM 上，显存独立保护。
5. def vgpu_allocate(gpu, shares):模拟 vGPU 比例分配：按算力和显存百分比切分，适合弹性配额场景。
6. shares = [(0.4, 0.4), (0.3, 0.3), (0.2, 0.2)]vGPU 的配比表：三个租户分别占 40%、30%、20% 的算力和显存。

常见误区

面试题