要理解 GPU 共享方案，先得搞清楚 GPU 上两种核心资源的物理特性——它们的管理方式完全不同。

1. GPU 显存和算力到底是什么

要理解 GPU 共享方案，先得搞清楚 GPU 上两种核心资源的物理特性——它们的管理方式完全不同。

1.1 显存：可分割、可隔离

GPU 显存就是一块物理内存（比如 24GB、46GB、80GB）。它的特性和电脑主内存一样：

打个比方，显存就像写字楼的办公室——物理隔墙，A 公司在 301，B 公司在 302，互不干扰。

1.2 算力（SM）：不可分割、时间共享

GPU 的计算核心叫 SM（流多处理器）。一张卡可能有 80 个 SM，但 SM 和显存有本质区别：

SM 就像写字楼的电梯——所有公司共用同一组电梯，不能说"1 号电梯只给 A 公司用"。只能控制"谁什么时候能坐电梯"。

1.3 一句话总结

2. 驱动层怎么管理这些资源

2.1 显存管理：类似 malloc

NVIDIA 驱动对显存的管理类似 C 语言的malloc——谁申请就给谁一段，全程记账。

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line初始状态: [############################################] 24GB 全空闲进程 A 调用 cuMemAlloc(2GB): [AAAA.........................................] 24GB 驱动记账: 0x0000~0x2000 → PID 1234进程 B 调用 cuMemAlloc(2GB): [AAAA][BBBB....................................] 24GB 驱动记账: 0x2000~0x4000 → PID 5678

驱动保证进程 A 不会写到进程 B 的区域。这是「硬件级隔离」，由 GPU 页表实现。

但驱动不管"你该分多少"——只要物理显存还有空位，你申请多少它给多少。如果进程 A 已经拿了 20GB，又来要 20GB，驱动也会给（只要总共不超过 24GB）。

2.2 算力管理：硬件调度器排队

SM 的管理完全不同。驱动内部有一个「硬件调度器」（GPU 芯片上的硬件单元），它负责把不同进程的 kernel 排队送到 SM 上执行：

ounter(lineounter(lineounter(line时刻 t=0ms: 进程 A 的 kernel 在 SM 0~79 上执行时刻 t=2ms: 进程 B 的 kernel 在 SM 0~79 上执行（A 让出来）时刻 t=4ms: 进程 A 的 kernel 又在 SM 0~79 上执行

驱动不记录"SM 分给了谁"，因为根本没有这种分配。所有进程共享同一组 SM，靠时间片轮转。

3. 为什么需要 GPU 共享方案

GPU 很贵。一张 L40S 46GB 大几万块，一张 A100 80GB 十几万。但大多数任务的 GPU 利用率很低——一个推理服务可能只占 4GB 显存、10% 算力，剩下 42GB 显存和 90% 算力全浪费了。GPU 共享的核心动机就是「把浪费的资源利用起来」。

具体来说，有几种典型场景：

3.1 场景一：多个任务共享一张卡（最基本的诉求）

一台服务器有 8 张卡，但有 20 个推理服务要跑。不共享的话只能跑 8 个，剩下 12 个排队。如果每个服务只需要 4GB 显存，一张 46GB 的卡完全可以放好几个。

应用层自己共享

事实上，很多推理框架本身就支持在一张卡上跑多个模型。比如 vLLM 可以通过gpu_memory_utilization参数控制每个实例占用的显存比例，在同一张卡上启动多个 vLLM 实例，各加载不同模型：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line# 实例 A：限制使用 40% 显存python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-7B --gpu-memory-utilization 0.4 --port 8000# 实例 B：限制使用 40% 显存python -m vllm.entrypoints.openai.api_server --model meta-llama/Llama-3-8B --gpu-memory-utilization 0.4 --port 8001

两个实例各占 40% 显存，加起来 80%，留 20% 给系统。这种方式确实能用，但有几个问题：

共享方案的价值

GPU 共享方案（HAMi、MIG 等）解决的是「在应用层之上提供统一的、有隔离的共享能力」：

3.2 场景二：Kubernetes 云原生调度

Kubernetes 通过 NVIDIA Device Plugin 把每张 GPU 注册成 1 个nvidia.com/gpu资源。这是整数资源，不支持小数——你不能申请 0.5 张 GPU。一张卡分配给一个Pod后，调度器不会再分给别的 Pod。

这意味着 Kubernetes 集群里 8 张卡 = 8 个资源，最多同时跑 8 个 GPU 任务。哪怕每个任务只用 2GB 显存，也得独占一整张卡。

根本原因在于：「NVIDIA 驱动只认进程，不认 Pod」。驱动不知道 Kubernetes 的存在，它只看到一台机器上有一堆进程在调用CUDA API。Kubernetes 把一张卡整块分给一个 Pod，是因为它没有手段告诉驱动"这个 Pod 只能用 2GB，那个 Pod 可以用 20GB"——驱动没有这种接口。

需求是：「让 Kubernetes 能像管理 CPU/内存一样管理 GPU——可切分、可配额、可调度」，每个 Pod 拿到独立的虚拟 GPU，互不干扰，还能用 Kubernetes 原生的扩缩容、滚动更新等能力来管理。

3.3 场景三：多租户隔离

云服务商把 GPU 算力卖给不同客户，需要保证客户 A 的任务绝对看不到客户 B 的数据，一个客户 OOM 或崩溃不能影响另一个。这要求「硬件级强隔离」，不是软限制能解决的。

3.4 场景四：超卖提高投资回报率

买了 8 张卡，但不是所有任务都同时满载。白天推理服务忙、训练任务闲；晚上反过来。如果能让推理和训练共享同一批卡，白天推理多用、晚上训练多用，就能用 8 张卡干 16 张卡的活。

这需要共享方案支持「超卖」——允许所有任务的配额之和超过物理总量，赌的是峰值不会同时到来。

4. 现有 GPU 共享方案对比

GPU 共享方案按隔离层级从低到高，可以分为四层。越靠上的层越灵活但隔离越弱，越靠下的层隔离越强但限制越多。

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line应用层 ← vLLM / TGI 等推理框架自己管 ↓用户空间拦截 ← HAMi-core（LD_PRELOAD 拦截 CUDA API） ↓驱动级 ← MPS（并发合并）、NVIDIA vGPU（驱动级虚拟化） ↓硬件级 ← MIG（芯片物理分区）

4.1 应用层：推理框架自己管

「代表方案」：vLLMgpu_memory_utilization、TGI、TensorRT-LLM 多实例

「原理」：应用自己控制显存用量。比如 vLLM 启动时设置--gpu-memory-utilization 0.4，它就尽量只占 40% 显存。

「显存隔离」：无。应用只是"尽量不超"，没有强制手段。KV cache 膨胀或 bug 导致超用，别的实例拦不住「算力隔离」：无。谁请求多谁占的 SM 多，没有限制

「优势」：零成本、不需要任何额外组件、所有 GPU 都能用「劣势」：没有隔离、没有保障、依赖应用自觉、换框架就得重新配置

4.2 用户空间拦截层：HAMi-core

「代表方案」：HAMi-core（libvgpu.so）

「原理」：通过LD_PRELOAD在程序和 NVIDIA 驱动之间插一层拦截层。所有 CUDA API 调用先经过 HAMi-core，它来决定放不放行。

「显存隔离」：拦截cuMemAlloc，分配前检查"本 Pod 加起来有没有超配额"。超了直接返回 OOM，请求到不了驱动。没超才放行给驱动正常分配。

「算力隔离」：拦截cuLaunchKernel，启动前检查令牌。令牌不够就等（nanosleep），够了才放行。后台线程通过 NVML 监控实际 SM 利用率，动态调整令牌补充速度。

「超卖」：调度器通过DeviceMemoryScaling把物理显存放大后注册（24GB × 2.0 = 48GB），允许多个 Pod 配额之和超过物理显存。赌的是峰值错开。算力超卖更安全——令牌桶自动分时共享，不会崩溃，只是变慢。

「优势」：零侵入、不挑硬件、免费、支持超卖、Kubernetes 原生集成「劣势」：软隔离（程序绕过 CUDA API 就失效）、仅限 CUDA 生态

4.3 驱动级：MPS 和 NVIDIA vGPU

这一层由 NVIDIA 驱动自己做隔离，程序绕不过去。

4.3.1 MPS（Multi-Process Service）

「原理」：多个进程的 kernel 通过 MPS 守护进程合并后一起送入 SM 执行，减少上下文切换开销。

「显存隔离」：MPS 本身不做显存隔离。多个进程共享同一显存空间，需要配合其他机制（如 cgroups 或 HAMi-core）来限制显存「算力隔离」：不限制算力比例。MPS 的价值不在于隔离，而在于「提升并发效率」——多个进程的 kernel 合并后同时在 SM 上跑，减少上下文切换开销。但一个进程的 kernel 太多，照样可以挤占其他进程的执行机会

「优势」：比时间片轮转效率高（减少上下文切换开销）、提升整体吞吐量「劣势」：没有算力比例隔离（一个进程可以吃掉大部分算力）、不做显存隔离、需要 MPS 守护进程、进程之间有数据泄露风险（共享上下文）

4.3.2 NVIDIA vGPU

「原理」：NVIDIA 企业级方案，专用驱动把一张物理卡切成多个虚拟 GPU，每个虚拟 GPU 有独立的显存空间。

「显存隔离」：驱动级硬隔离，虚拟 GPU 之间互不干扰「算力隔离」：时间片轮转，每个虚拟 GPU 按比例获得算力

「优势」：硬隔离、支持热迁移、成熟稳定「劣势」：需要付费 License、需要特定 GPU 型号（VGX 系列）、不支持超卖

4.4 硬件级：MIG

「代表方案」：MIG（Multi-Instance GPU）

「原理」：在 GPU 芯片级别把 SM 和显存切成多个物理实例，每个实例完全独立。

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(line一张 A100 80GB，开启 MIG 后可以切成： 实例 1: 14 个 SM + 10GB 显存 实例 2: 14 个 SM + 10GB 显存 实例 3: 14 个 SM + 10GB 显存 ...每个实例有独立的 SM、独立的显存、独立的 L2 缓存

「显存隔离」：物理分区，实例 1 的进程根本看不到实例 2 的显存「算力隔离」：物理分区，实例 1 的 kernel 只在实例 1 的 SM 上跑

「优势」：真正的硬隔离，安全性最高「劣势」：只支持 A100/A30/H100 等特定型号、分区是静态的（改分区需要重启 GPU）、不支持超卖、切分粒度有限

4.5 横向对比

5. 选型建议

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line你的场景是什么？│├── 多租户、需要强安全隔离│ └── MIG（有 A100/H100）或 NVIDIA vGPU（有预算）│├── 内部团队共享、互相信任、要最大化利用率│ └── HAMi-core（免费、不挑硬件、支持超卖）│├── 需要减少上下文切换开销、提升并发吞吐、不在乎算力隔离│ └── MPS（适合计算密集型多进程场景，如多个训练任务）│└── Kubernetes 云原生场景、要像管理 CPU 一样管理 GPU └── HAMi-core（唯一不需要特定硬件/驱动的方案）

5.1 HAMi-core 的定位

HAMi-core 不是最强的隔离方案（MIG 和 vGPU 更强），但它是「门槛最低的方案」：

对于"内部团队共享 GPU 集群"这种互相信任的场景，软隔离够用了。对于多租户安全隔离，才需要上 MIG 或 vGPU。

6. 总结

GPU 共享的核心挑战来自显存和 SM 的物理特性差异：

不同方案在"隔离强度"和"通用性"之间做权衡：

「没有完美方案，只有适合场景的方案。」HAMi-core 选择了"软隔离 + 高通用性 + 支持超卖"的路线，在云原生 GPU 共享场景下填补了 MIG/vGPU/MPS 都无法覆盖的空白。

❝

「补充说明」：实际生产中，这些方案并非互斥，可以组合使用。例如 HAMi + MPS 可以在保持软隔离的同时提升并发效率；MIG + HAMi 可以在 MIG 分区内再做细粒度配额控制。选型时应根据实际硬件条件、安全要求和业务特征灵活组合。