LLM 推理的 GPU 池化与多租户公平分配工程 2026
把 GPU 池化拆成 MIG、MPS、time-slicing、vGPU 四层垂直栈,用 (mathcal{G}, mathcal{T}, mathcal{S}, mathcal{Q}) 四元组和 DRF 公平性算法,讲清大模型推理服务从单卡独占到多租户切片的关键决策与失败模式。
约 26 分钟阅读7,744 字17 次阅读博主
把 GPU 池化拆成 MIG、MPS、time-slicing、vGPU 四层垂直栈,用 (mathcal{G}, mathcal{T}, mathcal{S}, mathcal{Q}) 四元组和 DRF 公平性算法,讲清大模型推理服务从单卡独占到多租户切片的关键决策与失败模式。
当我们把一个大模型推理服务从单租户、单模型、单卡 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% 的推理集群，其资本支出在合规口径下会折损。
我们用四元组 描述一个 GPU 池化场景，其中：
四层栈的物理隔离强度从强到弱排序：
| 层级 | 技术 | 隔离维度 | 隔离强度 | 切换开销 | 共享开销 | 适用场景 |
|---|---|---|---|---|---|---|
| L1 | MIG (硬件切片) | SMs + HBM + L2 | 完全独立 | ns 级 (硬件) | 几乎为 0 (硬件加速) | 大租户 (≥20GB 显存) |
| L2 | MPS (软件 SM 共享) | SMs | 进程间优先级 | μs 级 | 上下文切换开销 5-15% | 中等租户 (4-20GB) |
| L3 | Time-slicing | 整张卡时分复用 | 完全独占 (分时) | ms 级 | 推理延迟尾部延迟 +20-100ms | 偶发低频租户 |
| L4 | vGPU / fractional | 显存层虚拟化 | HBM 切片 + SMs 部分 | 取决于驱动 | 显存超额分配可配 | 显存瓶颈场景 |
关键的认知是：MIG 不是 MPS 的替代品，MPS 不是 time-slicing 的替代品。这四层是垂直叠加而非水平互斥——你可以在同一张 H100 上同时开 2 个 MIG 实例 + 跑 4 个 MPS 客户端 + 还有 6 个 time-slicing 容器。理解了这个垂直叠加性，才能理解为什么生产中的"最优切片策略"几乎都是一个三层组合。
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 典型拓扑（一个 8 卡 H100 节点的 MIG 配置）：
剩余的卡和小 profile 可以被 MPS 模式复用。
MIG 的最大陷阱：动态 MIG 重配是反模式。某些团队试图"按负载动态切 MIG profile"——白天切 4g.20gb 给大模型，夜里切 7 个 1g.10gb 给夜间任务——结果发现重配的卡顿（每次 100-300ms）、MIG 实例销毁重建的 checkpoint 重新加载时间（30-60 秒），完全抵消了负载均衡收益。结论：MIG 应该用作"租户隔离的硬件边界"，不要用作"负载均衡的弹性资源"。后者交给 MPS 或 K8s 调度层。
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 的工程真相：
CUDA_MPS_CLIENT_PRIORITY 调整cudaErrorUnknown），必须用 systemd 或 supervisord 监控并自动重启 servertensor_parallel_size > 1 时 MPS 客户端会进入 NCCL 通信瓶颈MPS 的生产陷阱：
ACTIVE_THREAD_PERCENTAGE 是软约束，CUDA driver 在 SMs 闲置时会调度超额——某个 MPS 客户端实际可能用超过配额CUDA_MPS_CAPTURE_ENABLED=1，否则会报 cudaErrorStreamCaptureUnsupportedTime-slicing（NVIDIA Container Toolkit 的 nvidia.com.gpu time-slicing annotation）是把一张物理卡按时分复用给多个容器/进程的策略。每个客户端获得"独占"的完整 GPU 一段时间（典型 10-50ms），然后切换到下一个客户端。切换是 GPU context save/restore，开销在 ms 级。
Time-slicing 的工程真相：
vGPU / fractional GPU（NVIDIA AI Enterprise 付费特性，或开源的 HAMi / Kubernetes GPU Sharing）切显存层 + 部分 SMs。HAMi 是国内开源项目（项目地址 github.com/Project-HAMi/HAMi），实现了显存层的硬隔离 + SMs 的弹性配额，在字节跳动、蚂蚁、阿里内部大规模生产部署。
vGPU 的工程真相：
nvidia-smi 的 mig 设备驱动隔离，每个 vGPU 实例有专属的显存上限四层硬件-软件切片解决了"物理资源怎么分"，但"分多少、按什么原则分"是算法层的问题。主流的公平性算法是 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 推理场景的扩展：
DRF 的工程局限：
生产中的常见 DRF 扩展：
给定一个具体的生产场景（已知 GPU 类型、租户数量、模型大小、SLA），按以下流程选切片策略：
Step 1：估算总显存需求 （每个租户模型的 HBM 占用）。
Step 2：估算 SMs 需求 （基于每个模型的 FLOPs/second）。
Step 3：分析租户 SLA 形态。
Step 4：加入公平性算法层。
典型生产配置示例（一个 8 卡 H100 节点服务 12 个租户）：
推论 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 都不能忽视的工程经济学。
nvidia-smi dmon -s u 输出，看 SMs 利用率的中位数和 P99。NCCL_IB_HCA、NCCL_SOCKET_IFNAME、NCCL_DEBUG 三个环境变量必须显式设置，否则默认走 socket 路径，延迟 +50%。本文给出的四层切片栈和决策框架，是基于当前（2026-08）的硬件（Hopper/Blackwell）和主流开源软件（vLLM 0.5+, SGLang 0.3+, HAMi 2.0+, NVIDIA MPS 16+）的状态。几个本文没展开但值得后续研究的方向：
对于做调度算法研究的同学，LLM 推理池化是一个比传统云资源调度更复杂的问题域——因为 GPU 资源不是单一标量，而是 三元组，且每个租户对三元组的需求是高度异构的。传统的 DRF 在这个场景下需要扩展——可以考虑引入模型感知的 DRF（基于模型结构估计 GPU 资源需求曲线）、在线学习的 DRF（基于历史负载预测租户 burst 模式）。
对于做硬件架构的同学，MIG 是"硬件切片的正确方向"——但当前 MIG profile 是离散的，未来是否需要连续可配的 MIG（基于 SRAM 切片的细粒度）？这是 NVIDIA、AMD、Intel、国产 GPU 厂商都在探索的方向。
一句话摘要：LLM 推理的物理 GPU 池化不是"切卡"的简单问题，而是 MIG（硬件切片）、MPS（软件 SMs 共享）、time-slicing（时分复用）、vGPU（显存切片）四层栈的垂直叠加，配合 DRF 类公平算法——选错切片策略会让 P99 延迟爆炸或利用率崩溃，选对组合可让一块 H100 服务 10+ 租户且 SLA 全部满足。
Conversation
0 条