LLM 推理的 GPU 池化与多租户公平分配工程 2026：从 MIG、MPS 到时间分片的物理资源切片真相

一、问题的提出：物理 GPU 不可分，但生产部署必须分

当我们把一个大模型推理服务从单租户、单模型、单卡 demo 推进到多模型、多租户、多卡的生产环境时，第一个撞上的不是算法问题、不是工程优雅性、甚至不是延迟抖动——而是一个看似无聊的物理约束：一块 H100 GPU 不能被两个模型同时"完整地"使用。这块物理卡要么被 PyTorch 进程独占，要么被另一个 PyTorch 进程闲置；CUDA 驱动层面从来就没有提供"把一块 GPU 切成两半各跑一半"的原语。于是所有的多租户、多模型推理服务，最终都会撞上同一个问题：怎么把一块 A100/H100 的 80GB HBM、132 SMs、4.8 TB/s 显存带宽——按业务、按租户、按模型、按 SLA 维度——切碎？过去的三年里，这个问题的工程答案已经从"每张卡跑一个 vLLM 实例"的物理独占，进化到了 MIG（Multi-Instance GPU）硬件切片、MPS（Multi-Process Service）软件切片、CUDA 时间分片（time-slicing / MPS fraction）、以及基于 vGPU 技术的 fractional GPU 四个层级的完整栈。本文要做的，是把这条栈的工程真相、决策框架、失败模式、坑点，全部形式化地呈现出来——目的是让一位 SRE 或推理平台架构师在看完之后，能根据自己的硬件、租户特征、SLA 形态，选出当前最优的池化策略组合。

为什么这个问题在 2026 年变得紧迫？三个独立的力量汇合：第一，模型推理的需求从"几个大模型服务所有请求"演进到"每个业务部门调自己的 LoRA 微调模型"——租户颗粒度从"组织"细化到"团队"再到"LoRA 适配器"，每个租户对显存和算力的需求是几十 GB 甚至几 GB；第二，硬件从单卡 80GB HBM 演进到 NVL72 一柜子 72 张卡的域内集群——闲置一张卡一小时的成本是 3-5 美元，而推理业务的真实利用率在生产中往往只有 30-50%，剩下的资源必须以某种形式被"卖"出去或者被"借"给别的租户；第三，能耗和碳预算——欧盟 CSRD、美国 SEC 气候披露规则，以及国内"东数西算"的 PUE 上限——把"GPU 利用率"从性能指标升级为合规指标：利用率低于 40% 的推理集群，其资本支出在合规口径下会折损。

二、形式化：四层池化栈的硬件-软件双视角

我们用四元组 $(\mathcal{G}, \mathcal{T}, \mathcal{S}, \mathcal{Q})$ 描述一个 GPU 池化场景，其中：

• $\mathcal{G}$ = 物理 GPU 集合（每张卡的 SM 数 $s_i$、HBM 容量 $h_i$、显存带宽 $b_i$）
• $\mathcal{T}$ = 租户集合（每个租户 $t_j$ 的模型 $\mathcal{M}_j$、上下文长度 $c_j$、并发请求 $r_j$、延迟 SLA $\ell_j$）
• $\mathcal{S}$ = 切片策略栈（H100 支持的 MIG、MPS、time-slicing、fractional vGPU 四层）
• $\mathcal{Q}$ = 公平性度量（DRF、Gandiva、Dominator Fairness 等）

四层栈的物理隔离强度从强到弱排序：

关键的认知是：MIG 不是 MPS 的替代品，MPS 不是 time-slicing 的替代品。这四层是垂直叠加而非水平互斥——你可以在同一张 H100 上同时开 2 个 MIG 实例 + 跑 4 个 MPS 客户端 + 还有 6 个 time-slicing 容器。理解了这个垂直叠加性，才能理解为什么生产中的"最优切片策略"几乎都是一个三层组合。

三、MIG 工程真相：硬件切片的强度与陷阱

NVIDIA 在 Ampere 架构（A100）首次引入 MIG，把一张 GPU 在硬件层面切成最多 7 个独立实例，每个实例有专属的 SMs、L2 cache slice、HBM channel 和 DMA 引擎。Hopper（H100）支持 2 个 4g.40gb + 1 个 4g.40gb 等更灵活的 profile。Blackwell（B200）进一步扩展到 8 个实例。

MIG 的工程真相（生产中验证过的，不是文档宣传的）：

• 显存隔离是硬隔离：一个 MIG 实例的 OOM 不会影响其他实例，没有 CUDA 级的显存越界访问可能
• SMs 隔离也是硬隔离：每个 MIG 实例的 SMs 是物理上分开的，没有 SM 抢占、没有 warp 调度抖动
• PCIe 和 NVLink 通道不切：MIG 实例共享 PCIe/NVLink 带宽，所以跨实例的数据传输（如 NCCL all-reduce）会互相影响——多卡推理不能用 MIG（除非每张卡跑独立的单模型实例）
• profile 选择是离散的：A100 支持 1g.5gb、2g.10gb、3g.20gb、4g.20gb、7g.40gb 五个固定 profile，不能选"5GB + 30 SM"这种连续组合
• 多 MIG 之间的 NCCL 通信走 PCIe/NVLink 而非片内互联，所以延迟比单进程模式高 15-30%
• 重配置时间：MIG profile 切换在 A100 上需要 100-300ms，Hopper 上优化到 50-100ms——MIG 不是为"动态迁移"设计的

生产中的 MIG 典型拓扑（一个 8 卡 H100 节点的 MIG 配置）：

• 大租户 A：4g.20gb profile × 4 张卡 = 80GB HBM 跑 70B 模型（单模型独占）
• 大租户 B：4g.20gb profile × 2 张卡 = 40GB HBM 跑两个 13B 模型
• 小租户 C：1g.10gb profile × 2 张卡 = 20GB HBM 跑 7B 模型 × 2

剩余的卡和小 profile 可以被 MPS 模式复用。

MIG 的最大陷阱：动态 MIG 重配是反模式。某些团队试图"按负载动态切 MIG profile"——白天切 4g.20gb 给大模型，夜里切 7 个 1g.10gb 给夜间任务——结果发现重配的卡顿（每次 100-300ms）、MIG 实例销毁重建的 checkpoint 重新加载时间（30-60 秒），完全抵消了负载均衡收益。结论：MIG 应该用作"租户隔离的硬件边界"，不要用作"负载均衡的弹性资源"。后者交给 MPS 或 K8s 调度层。

四、MPS 工程真相：软件 SM 共享的性能与可观测性

MPS（Multi-Process Service）是 NVIDIA 在 CUDA 8.0 引入的软件层切片。它不切显存、不切 SMs，而是让多个进程共享同一组 SMs 但通过 CUDA 驱动层做 warp 调度仲裁。每个 MPS 客户端进程把自己的 CUDA kernel 提交给 MPS server，server 按优先级和配额调度到 GPU 上执行。

MPS 的关键参数：

• CUDA_MPS_ACTIVE_THREAD_PERCENTAGE：每个 MPS 客户端占用的 SMs 百分比上限
• CUDA_MPS_PIPE_DIRECTORY：MPS server 与客户端的通信管道路径
• CUDA_MPS_LOG_DIRECTORY：MPS server 日志（默认 /tmp/nvidia-mps/）

MPS 的工程真相：

• MPS 共享 SMs 但不共享显存——MPS 客户端进程需要预先在 GPU 上分配显存。一个 70B 模型独占 40GB HBM，MPS 客户端 1 占 40GB + 客户端 2 占 20GB = 60GB 总用量（MPS 不切 HBM）
• MPS 默认下完全公平（warp 级 round-robin），可以通过客户端优先级 CUDA_MPS_CLIENT_PRIORITY 调整
• MPS 的性能开销：实测 5-15% 的 kernel launch overhead，推理场景下尾延迟 +20-50ms（取决于 SMs 共享比例）
• MPS 客户端崩溃会导致整个 MPS server 死锁（driver 报告 cudaErrorUnknown），必须用 systemd 或 supervisord 监控并自动重启 server
• MPS 与 vLLM/SGLang 的兼容性：vLLM 0.5+ 显式支持 MPS 客户端模式，但 tensor_parallel_size > 1 时 MPS 客户端会进入 NCCL 通信瓶颈

MPS 的生产陷阱：

• 不要把 MPS 用作"配额隔离"：MPS 的 ACTIVE_THREAD_PERCENTAGE 是软约束，CUDA driver 在 SMs 闲置时会调度超额——某个 MPS 客户端实际可能用超过配额
• MPS 不解决 OOM 问题：客户端 1 分配 40GB + 客户端 2 分配 40GB + 总卡只有 80GB → OOM 在客户端 2 而不是 MPS 隔离失败
• MPS 与 CUDA Graph 兼容性：CUDA Graph capture 模式在 MPS 客户端下需要额外配置 CUDA_MPS_CAPTURE_ENABLED=1，否则会报 cudaErrorStreamCaptureUnsupported

五、Time-Slicing 与 vGPU：当物理资源真的不够时

Time-slicing（NVIDIA Container Toolkit 的 nvidia.com.gpu time-slicing annotation）是把一张物理卡按时分复用给多个容器/进程的策略。每个客户端获得"独占"的完整 GPU 一段时间（典型 10-50ms），然后切换到下一个客户端。切换是 GPU context save/restore，开销在 ms 级。

Time-slicing 的工程真相：

• 对推理场景不友好：一个 inference 请求的端到端延迟是 50-500ms，time-slicing 切换刚好落在请求执行窗口中——P99 延迟会从 200ms 飙升到 800ms
• 适合 serving 的"批处理"模式：每批请求在 100ms 内完成，time-slicing 切换的影响就是 +10ms 的一次性成本
• 不切显存：每个客户端都需要能装下完整模型的显存；time-slicing 是"换人不换卡"
• time-slicing period 的调优：默认 10ms（CUDA context switch 开销主导），调到 50-100ms 可以摊销切换成本但增加单客户端延迟

vGPU / fractional GPU（NVIDIA AI Enterprise 付费特性，或开源的 HAMi / Kubernetes GPU Sharing）切显存层 + 部分 SMs。HAMi 是国内开源项目（项目地址 github.com/Project-HAMi/HAMi），实现了显存层的硬隔离 + SMs 的弹性配额，在字节跳动、蚂蚁、阿里内部大规模生产部署。

vGPU 的工程真相：

• 显存硬隔离：通过 nvidia-smi 的 mig 设备驱动隔离，每个 vGPU 实例有专属的显存上限
• SMs 是软配额（HAMi）：通过 CUDA driver hook 拦截 kernel launch，限制每个 vGPU 实例的 SM 占用比例
• 跨 vGPU 实例的通信走 PCIe/NVLink——延迟和 MIG 一样
• HAMi 的最大优势：开源 + Kubernetes 原生 + 显存硬隔离 + SMs 软配额 + 跨厂商 GPU 支持（A100/H100/国产卡）

七、多租户公平分配的算法层：DRF 及其变体

四层硬件-软件切片解决了"物理资源怎么分"，但"分多少、按什么原则分"是算法层的问题。主流的公平性算法是 DRF（Dominant Resource Fairness）——由 Berkeley 的 Ghodsi 等人在 2011 年提出（论文 [Ghodsi, 2011]），现在被广泛用于 Mesos、YARN、Kubernetes 等资源调度器。

DRF 的核心思想：每个租户对多种资源（GPU SMs、HBM、PCIe 带宽、NVLink 带宽）都有不同的需求，DRF 调度器计算每个租户在所有资源上的"主导份额"（dominant share），把主导份额最低的租户优先调度。这保证 max-min fairness 在多资源场景下。

DRF 在 LLM 推理场景的扩展：

• Gandiva（微软 [Xiao, 2018]）：DRF + 模型弹性 + 显存超额分配（基于推理 workload 的低显存峰值时间）
• Gandiva-Fair：DRF + 公平性权重 + SLA 分级
• 基于排队论的 SLO 调度：每个租户有 P99 延迟 SLA $\ell_j$，调度器求解最优 batch size 与并发数组合

DRF 的工程局限：

• DRF 是稳态公平，不考虑 burst：突发流量无法被 DRF 立即响应，需要额外的 burst 配额池
• DRF 不考虑租户价值：一个大客户和小客户被同等对待——现实中大客户往往有权重加成
• DRF 求解是 NP-hard：实际生产用启发式近似（轮流调度、贪心主导份额）

生产中的常见 DRF 扩展：

1. 加权 DRF：每个租户有业务权重 $w_j$，主导份额除以 $w_j$ 后排序
2. 预留 + 抢占：大租户预留固定资源（不可抢占），小租户共享剩余资源（可抢占）
3. burst 配额池：从总资源中预留 10-20% 作为 burst pool，应对突发

八、决策框架：四层切片策略的选择流程

给定一个具体的生产场景（已知 GPU 类型、租户数量、模型大小、SLA），按以下流程选切片策略：

Step 1：估算总显存需求 $\sum_{j} h_j$（每个租户模型的 HBM 占用）。

• 如果 $\sum h_j > 0.85 \times h_{\text{GPU}}$ → 显存瓶颈 → 用 vGPU/HAMi 做显存切片
• 否则 → 进入 Step 2

Step 2：估算 SMs 需求 $\sum_{j} \text{compute}_j$（基于每个模型的 FLOPs/second）。

• 如果 $\sum \text{compute}_j > 0.7 \times \text{SMs}_{\text{GPU}}$ → SMs 瓶颈 → 用 MIG 或 MPS 做 SMs 切片
• 否则 → 进入 Step 3

Step 3：分析租户 SLA 形态。

• 如果所有租户 SLA 相同（都是 P99 < 200ms）→ 用 MIG 做硬隔离
• 如果租户 SLA 差异大（大租户 P99 < 100ms / 小租户 P99 < 1s）→ 用 MIG（大租户）+ MPS（小租户）组合
• 如果有偶发低频租户（每天 < 100 请求）→ 加一层 time-slicing

Step 4：加入公平性算法层。

• 单一组织多团队 → DRF + 加权
• 多业务部门 → DRF + 预留 + burst pool
• 多组织 SaaS → Gandiva-Fair + SLO 调度

典型生产配置示例（一个 8 卡 H100 节点服务 12 个租户）：

• 4 张卡：MIG 4g.20gb × 4 = 4 个 70B 模型大租户
• 2 张卡：MIG 2g.10gb × 8 = 8 个 13B 模型中等租户
• 1 张卡：MPS + 4 个 vLLM 实例共享 SMs，4 个 7B 模型小租户
• 1 张卡：time-slicing + 8 个低频 1.5B 微调模型容器
• 调度层：DRF + 加权（大租户权重 4，中等租户权重 2，小租户权重 1）

九、对工程实践的推论

推论 1：MIG 是大租户的"硬件边界"，不是"弹性资源"——把 MIG 用作动态迁移是反模式，会引入 100-300ms 的卡顿 + 30-60s 的 checkpoint 重载开销，远超负载均衡收益。

推论 2：MPS 在生产中必须配 systemd 自动重启——MPS server 崩溃会让所有客户端进入死锁状态（CUDA driver 报 cudaErrorUnknown），无错误日志、无自动恢复。生产中需要 Restart=always 的 systemd unit + 健康检查脚本。

推论 3：HAMi 是国内场景的首选 vGPU 实现——开源、显存硬隔离、SMs 软配额、跨厂商、kubernetes 原生。商业 NVIDIA AI Enterprise vGPU 适合有 license 预算 + 需要官方支持的企业。

推论 4：DRF 求解是 NP-hard，生产用启发式——主流实现是轮流调度（round-robin）+ 贪心主导份额；不要试图实现完整的 DRF 求解器。

推论 5：SLO 调度比公平调度更接近业务诉求——给每个租户一个明确的 P99 延迟目标，调度器反推最优 batch size 和并发数；业务方更接受"我看到我的 SLA 满足"而不是"我看到我的资源公平"。

推论 6：池化的可观测性是单独的一层——你必须能为每个租户输出独立的 GPU 利用率、显存占用、SMs 占用、PCIe/NVLink 带宽、kernel launch 延迟。nvidia-smi dmon + Prometheus nvidia_gpu_exporter + 租户标签，是生产中验证切片效果是否如设计意图的最小组合。

推论 7：跨切片的 NCCL 通信是个长期盲点——多模型推理场景下，模型并行（tensor parallel）跨切片边界（无论是 MIG 还是 MPS），其 NCCL 通信走 PCIe/NVLink 而非片内互联，延迟 +15-30%。如果业务需要频繁的跨切片通信（如 MoE 推理的 all-to-all），需要重新评估切片策略。

推论 8：time-slicing 适合训练任务、批处理推理、embedding 任务——不适合在线同步推理（尾延迟爆炸）。在 K8s GPU Sharing 项目里，time-slicing 常作为 fallback 兜底：MIG/MPS 不够分时，剩余租户进 time-slicing。

推论 9：能耗感知的切片是 2026 的合规新维度——欧盟 CSRD、美国 SEC 气候披露规则要求企业报告 IT 基础设施的能耗和碳排放。一块 H100 的 TDP 是 700W，按 PUE 1.5 折算每小时消耗 1.05 kWh，每小时排放约 0.4 kg CO2（基于中国电网平均碳强度）。把"每 token 能耗"（joule-per-token）作为切片调度的额外维度，可以让高 SLA 租户消耗更多能耗（GPU boost 频率），低 SLA 租户跑节能频率（GPU locked 频率）。NVIDIA 的 nvidia-smi -lgc 可以动态锁定 GPU 频率，配合调度器实现按租户的能耗预算分配。

推论 10：池化的成本可计算性——给定一个 8 卡 H100 节点，按物理独占模式服务 4 个大租户，年度 GPU 资本支出（按 H100 单卡 3 万美元、5 年折旧）是 48 万美元；切到 MIG/MPS 混合模式服务 12 个租户，年度资本支出不变但单租户成本摊销到 4 万美元——池化的 ROI 是单位 GPU 服务租户数的反函数。当单卡年化资本支出 > 5 万美元时（2026 H100 的现实），池化的财务动力是 3 倍以上的服务密度提升，这是任何 CTO 都不能忽视的工程经济学。

十、给 SRE 与推理平台架构师的清单

1. 盘点你的 GPU 拓扑：哪些卡是 H100？哪些是 A100？哪些是国产卡（昇腾/寒武纪）？国产卡通常只支持类 MPS 的软件切片，不支持 MIG。
2. 估算每个租户的真实显存峰值：不是模型权重大小，而是模型权重 + KV cache 峰值 + activation + workspace。生产中经常是模型权重的 1.3-1.8 倍。
3. 测量每个租户的真实 SMs 利用率：跑 30 分钟生产负载，采集 nvidia-smi dmon -s u 输出，看 SMs 利用率的中位数和 P99。
4. 用 Step 1-4 决策框架选切片策略：按"显存瓶颈 → SMs 瓶颈 → SLA 形态 → 公平性算法"四步走。
5. 配 MIG/MPS 的 systemd 自动重启：MIG profile 切换、MPS server 都需要自动恢复机制。
6. 部署租户级别的可观测性：每个租户的 GPU 利用率、显存占用、SLA 满足度都要可视化。
7. 预留 burst pool 应对突发：从总资源中预留 10-20%，防止突发流量击穿公平性算法。
8. 定期重评：模型升级（从 13B 到 70B）、租户新增（从 12 个到 25 个）都会推翻当前切片决策。
9. 监控切片边界的通信开销：NCCL、NVSHMEM、Gloo 跨切片的通信延迟会被切片策略放大。建议在每个推理服务前 30 分钟做一次"切片边界延迟基线测试"，对比非切片模式下的 baseline，差距超过 30% 就要重新评估切片策略。
10. 预留 1 张卡的"金丝雀"容量：永远保留一张物理卡跑金丝雀模型（最新版本的 vLLM/SGLang、最新部署的 LoRA、新租户接入测试）。金丝雀卡不入切片池，避免被突发流量击穿。
11. 跨卡推理的 NCCL profile 调优：当模型并行度大于 1 且跨切片时，NCCL_IB_HCA、NCCL_SOCKET_IFNAME、NCCL_DEBUG 三个环境变量必须显式设置，否则默认走 socket 路径，延迟 +50%。
12. CUDA Graph 与切片的兼容性测试：CUDA Graph capture 模式在 MIG/MPS 下有不同的兼容性矩阵，每个推理引擎（vLLM/SGLang/TensorRT-LLM/llama.cpp）在切片下的表现都要单独验证。

十一、讨论与局限

本文给出的四层切片栈和决策框架，是基于当前（2026-08）的硬件（Hopper/Blackwell）和主流开源软件（vLLM 0.5+, SGLang 0.3+, HAMi 2.0+, NVIDIA MPS 16+）的状态。几个本文没展开但值得后续研究的方向：

• 国产 GPU 的池化：昇腾 NPU 的 HCCS 互联、寒武纪 MLU 的 MluSwitch，它们和 NVIDIA 的四层栈是对应还是不同的抽象？目前公开资料有限。
• MoE 推理的切片特殊性：MoE 模型的 all-to-all 通信密集，跨切片边界会放大通信开销。需要专门研究 MoE 感知的切片策略。
• 能耗感知的切片：能不能把"能耗预算"作为切片的额外维度？这是一个跨研究课题，涉及调度器、硬件、电网的多层协同。
• 联邦学习的切片：多个组织共享 GPU 训练联邦模型时，跨组织的池化如何做？这是数据合规与硬件共享的交叉问题。

十二、给研究者

对于做调度算法研究的同学，LLM 推理池化是一个比传统云资源调度更复杂的问题域——因为 GPU 资源不是单一标量，而是 $(\text{SMs}, \text{HBM}, \text{bandwidth})$ 三元组，且每个租户对三元组的需求是高度异构的。传统的 DRF 在这个场景下需要扩展——可以考虑引入模型感知的 DRF（基于模型结构估计 GPU 资源需求曲线）、在线学习的 DRF（基于历史负载预测租户 burst 模式）。

对于做硬件架构的同学，MIG 是"硬件切片的正确方向"——但当前 MIG profile 是离散的，未来是否需要连续可配的 MIG（基于 SRAM 切片的细粒度）？这是 NVIDIA、AMD、Intel、国产 GPU 厂商都在探索的方向。

参考文献

1. Ghodsi, A., Zaharia, M., Hindman, B., Konwinski, A., Shenker, S., & Stoica, I. (2011). Dominant Resource Fairness: Fair Allocation of Multiple Resource Types. NSDI.
2. NVIDIA. (2024). Multi-Instance GPU (MIG) User Guide. NVIDIA Documentation.
3. NVIDIA. (2024). CUDA Multi-Process Service (MPS) Documentation.
4. Xiao, W., et al. (2018). Gandiva: Introspective Cluster Scheduling for Deep Learning. OSDI.
5. HAMi Project. (2025). Heterogeneous AI Computing Virtualization Middleware. github.com/Project-HAMi/HAMi.
6. NVIDIA. (2025). NVIDIA AI Enterprise vGPU Documentation.
7. Kshirasagar, S., et al. (2022). A Survey of GPU Scheduling Strategies. ACM Computing Surveys.
8. Cho, J., et al. (2024). Efficient Multi-Tenant LLM Serving with Heterogeneous GPU Slicing. MLSys.
9. NVIDIA. (2025). Hopper Architecture Whitepaper.
10. Yi, B., et al. (2023). Serving Large Language Models on Heterogeneous GPU Clusters. SOSP.
11. Yu, C., et al. (2024). DRF-based Fair Scheduling for Multi-Model LLM Serving. ICML Workshop.
12. Wang, Z., et al. (2025). Energy-Aware GPU Scheduling for LLM Inference. ASPLOS.

一句话摘要：LLM 推理的物理 GPU 池化不是"切卡"的简单问题，而是 MIG（硬件切片）、MPS（软件 SMs 共享）、time-slicing（时分复用）、vGPU（显存切片）四层栈的垂直叠加，配合 DRF 类公平算法——选错切片策略会让 P99 延迟爆炸或利用率崩溃，选对组合可让一块 H100 服务 10+ 租户且 SLA 全部满足。