背景：GPU 资源利用率的工程困境

2026年，H100/H200/B100 等高端 GPU 单卡售价仍在 10 万+ 人民币区间，GPU 集群的资源利用率直接决定推理服务的 TCO（总体拥有成本）。然而，LLM 推理服务的资源利用模式极为不均匀：- 峰谷差异：白天流量是夜间 5-10 倍- 模型尺寸差异：7B 模型只需 16GB，70B 模型需要 140GB± 请求并发差异：单卡承载 1-N 个并发请求时，SM 利用率差异巨大GPU 共享是解决这一困境的核心技术路线。目前主流方案有三种：MIG（Multi-Instance GPU）、vGPU（Virtual GPU） 和 MPS（Multi-Process Service），本文对三者在 LLM 推理场景下进行深度工程对比。—## 一、三种技术原理速览### 1.1 MIG（Multi-Instance GPU）NVIDIA Ampere 架构引入，将一块物理 GPU 硬件隔离为多个独立 GPU 实例。H100 80GB 最多可切分为 7 个 MIG 实例。textH100 80GB MIG 分区示例：┌─────────────────────────────────────┐│ H100 80GB SXM5 ││ ┌──────┐ ┌──────┐ ┌──────┐ ││ │3g.40g│ │2g.20g│ │1g.10g│ ... ││ │ │ │ │ │ │ ││ └──────┘ └──────┘ └──────┘ ││ 独立SM 独立内存 独立内存控制器 │└─────────────────────────────────────┘特点：- 硬件级隔离，实例间零干扰- 内存带宽和 SM 按比例分配- 需要重启才能动态调整分区（H100 开始支持部分热调整）### 1.2 vGPU（Virtual GPU）NVIDIA 软件虚拟化方案，支持多个 VM 共享一块物理 GPU，通过时分复用（Time-slicing）实现。textvGPU 架构： VM1 VM2 VM3 VM4 ↓ ↓ ↓ ↓┌─────────────────────────┐│ NVIDIA vGPU Manager ││ (时分调度 / 空间复用) │└────────────┬────────────┘ ↓ 物理 GPU特点：- 支持虚拟化环境（VMware、KVM）- 通过授权许可收费（License 费用不低）- 时分复用存在调度延迟抖动### 1.3 MPS（Multi-Process Service）CUDA MPS 允许多个 CUDA 进程共享同一个 GPU 上下文，实现空间复用（Space Multiplexing）。textMPS 架构： 进程A 进程B 进程C ↓ ↓ ↓┌─────────────────────────┐│ CUDA MPS Server ││ (统一 GPU 上下文管理) │└────────────┬────────────┘ ↓ 物理 GPU（SM 空间复用）特点：- 无需授权费，开源免费- 多进程真正并行执行（不是时分）- 隔离性弱：一个进程 OOM 可能影响其他进程—## 二、LLM 推理场景的核心差异### 2.1 内存隔离性对比text场景：同一张 H100 80GB 部署两个模型（Qwen-7B + Qwen-14B）MIG 方案： 实例1（3g.40g）: Qwen-7B → 独立 40GB，内存保护100% 实例2（3g.40g）: Qwen-14B → 独立 40GB，内存保护100% ✅ 一个模型 OOM 不影响另一个MPS 方案： 进程1: Qwen-7B → 使用约 16GB 进程2: Qwen-14B → 使用约 28GB 共享 80GB 显存空间 ⚠️ 进程1 内存泄漏可能导致进程2 OOMvGPU 方案： VM1: vGPU 40GB → Qwen-7B VM2: vGPU 40GB → Qwen-14B ✅ VM 级别隔离，但需要 License### 2.2 吞吐量对比（实测估算）以 Qwen-7B-Instruct 为例，输入512 token，输出256 token，并发16请求：| 方案 | 吞吐量(tokens/s) | P99延迟(ms) | SM利用率 | 备注 ||------|----------------|-------------|---------|------|| 单卡独占 | 12,800 | 680 | 68% | 基准 || MIG 1g.10g | 2,100 | 920 | 95% | SM减少，利用率高 || MIG 2g.20g | 4,800 | 750 | 89% | 推荐7B模型分区 || MPS (2进程) | 11,200 | 820 | 91% | 吞吐接近独占 || vGPU (时分) | 8,900 | 1,240 | 72% | 调度开销显著 |### 2.3 动态性与灵活性bash# MIG 配置示例（需要 root 权限）# 查看当前 MIG 状态nvidia-smi mig -lgip# 在 H100 上创建 MIG 实例nvidia-smi mig -cgi 3g.40gb,3g.40gb -C# 查看创建结果nvidia-smi mig -lgi# 输出示例：# +-------------------------------------------------------+# | GPU instances: |# | GPU Name Profile Instance Placement |# | 0 MIG 3g.40gb * 1 0:3 |# | 0 MIG 3g.40gb * 2 4:7 |# +-------------------------------------------------------+``````bash# MPS 启动示例export CUDA_VISIBLE_DEVICES=0export CUDA_MPS_PIPE_DIRECTORY=/tmp/nvidia-mpsexport CUDA_MPS_LOG_DIRECTORY=/tmp/nvidia-log# 启动 MPS 控制守护进程nvidia-cuda-mps-control -d# 验证 MPS 状态echo "get_server_list" | nvidia-cuda-mps-control# 配置并发线程限制（防止某进程占用过多SM）echo "set_default_active_thread_percentage 50" | nvidia-cuda-mps-control—## 三、生产环境部署方案设计### 3.1 基于 Kubernetes 的 MIG 调度yaml# 使用 NVIDIA GPU Operator 进行 MIG 分区管理apiVersion: v1kind: ConfigMapmetadata: name: mig-strategy-config namespace: gpu-operatordata: config.yaml: | version: v1 mig-configs: all-3g.40gb: - devices: [0, 1, 2, 3] mig-enabled: true mig-devices: "3g.40gb": 2 # 每卡切2个实例---apiVersion: apps/v1kind: Deploymentmetadata: name: qwen-7b-inferencespec: replicas: 4 template: spec: containers: - name: vllm image: vllm/vllm-openai:latest resources: limits: nvidia.com/mig-3g.40gb: "1" # 申请一个 MIG 实例 env: - name: VLLM_MODEL value: "Qwen/Qwen2.5-7B-Instruct"### 3.2 MPS + vLLM 高密度部署python# 启动脚本：在同一张 GPU 上部署两个 vLLM 服务（MPS 模式）import subprocessimport osdef launch_vllm_with_mps( model: str, port: int, gpu_id: int, sm_percentage: int, # 分配的 SM 百分比 gpu_memory_fraction: float,): """在 MPS 模式下启动 vLLM 推理服务""" env = os.environ.copy() env["CUDA_VISIBLE_DEVICES"] = str(gpu_id) env["CUDA_MPS_ACTIVE_THREAD_PERCENTAGE"] = str(sm_percentage) cmd = [ "python", "-m", "vllm.entrypoints.openai.api_server", "--model", model, "--port", str(port), "--gpu-memory-utilization", str(gpu_memory_fraction), "--max-model-len", "4096", "--tensor-parallel-size", "1", ] return subprocess.Popen(cmd, env=env)# 在单张 H100 上部署两个服务p1 = launch_vllm_with_mps( model="Qwen/Qwen2.5-7B-Instruct", port=8000, gpu_id=0, sm_percentage=50, gpu_memory_fraction=0.45,)p2 = launch_vllm_with_mps( model="Qwen/Qwen2.5-14B-Instruct", port=8001, gpu_id=0, sm_percentage=50, gpu_memory_fraction=0.50,)### 3.3 动态负载均衡python# 根据实时负载动态调整 MPS 线程百分比class DynamicMPSController: def __init__(self, gpu_id: int): self.gpu_id = gpu_id self.mps_pipe = f"/tmp/nvidia-mps-{gpu_id}" def set_thread_percentage(self, service_name: str, percentage: int): cmd = f"set_active_thread_percentage {service_name} {percentage}" result = subprocess.run( ["nvidia-cuda-mps-control"], input=cmd, capture_output=True, text=True ) return result.returncode == 0 def rebalance(self, service_loads: dict[str, float]): """根据负载比例重新分配 SM 资源""" total_load = sum(service_loads.values()) if total_load == 0: return for service, load in service_loads.items(): percentage = max(10, int((load / total_load) * 100)) self.set_thread_percentage(service, percentage)—## 四、选型决策矩阵| 维度 | MIG | vGPU | MPS ||------|-----|------|-----|| 隔离级别 | 硬件级（最强） | VM 级（强） | 进程级（弱） || 吞吐损耗 | 10-20%（SM分区） | 20-30%（调度开销） | <5%（近乎无损） || 部署复杂度 | 中 | 高（需License+virt层） | 低 || 成本 | GPU 硬件成本 | GPU+License 费用 | GPU 硬件成本 || 动态调整 | 有限（需重启） | 支持 | 实时可调 || 适合模型规模 | 7B-40B 小中型 | 全尺寸 | 全尺寸（推荐<70B）|| 故障隔离 | 最佳 | 良好 | 较差 |### 选型建议text✅ 优先 MIG 的场景： - 多租户 SaaS，严格隔离 - 监管合规要求（金融、医疗） - 7B-34B 模型混部✅ 优先 MPS 的场景： - 单一可信环境（内部平台） - 最大化吞吐量（成本优先） - 同一模型多副本热备✅ 优先 vGPU 的场景： - 已有 VMware/KVM 虚拟化底座 - 需要跨物理机迁移 GPU 实例 - 企业级 SLA 要求—## 总结2026年 LLM 推理的 GPU 共享选型没有银弹：MIG 提供最强隔离但灵活性受限；MPS 提供最高吞吐但隔离性差；vGPU 平衡两者但引入额外成本。推荐策略是MIG + MPS 双轨制：对外多租户服务采用 MIG 保障隔离，内部高负载批推理采用 MPS 最大化 GPU 利用率。结合 Kubernetes GPU Operator 实现自动化调度，是 2026 年 LLM 推理基础设施的工程最优解。