GPU 共享与调度：MPS、MIG 与多租户隔离

现实问题：
□ 一张 A100 80 GB 常常只被一个服务用掉一半
□ 小模型推理（7B 以下）单卡利用率可能只有 10~30%
□ 多团队各自申请整卡 → 集群碎片化、成本高
□ 训练与推理混部时，训练间隙 GPU 空闲

共享的收益：
□ 提升利用率：多个负载填满同一张卡
□ 降低成本：小服务不必独占整卡
□ 提高弹性：按需分配算力切片
□ 支撑多租户：一个集群服务多个团队

共享的代价：
□ 隔离减弱：互相干扰（显存、算力、故障）
□ 性能不确定：共享导致延迟抖动
□ 复杂度上升：调度、配额、监控都要重做

核心权衡：
□ 隔离强度 ↑ → 利用率 ↓（MIG 最隔离也最浪费）
□ 利用率 ↑ → 隔离强度 ↓（时间片最省也最互相干扰）
→ 没有免费午餐，按场景选点

三个层次：
□ 层 1：时间片共享（Time-slicing）
  - 多个进程轮流用 GPU，显存不隔离
  - 隔离最弱，利用率最高，延迟抖动最大
  - 由 NVIDIA 驱动原生支持（默认行为）
□ 层 2：MPS（Multi-Process Service）
  - 多进程并发执行，共享 SM
  - 隔离中等，可设显存上限与算力占比
  - 需要常驻 MPS 控制进程
□ 层 3：MIG（Multi-Instance GPU）
  - 硬件级切分，SM/显存/带宽物理隔离
  - 隔离最强，但切分粒度固定、不可超卖
  - 仅 A100/H100 等高端卡支持

对照表：
维度          时间片        MPS          MIG
隔离强度      弱            中           强
显存隔离      无            软限制       硬件隔离
算力隔离      无            可限占比     硬件隔离
故障隔离      无            部分         完全
利用率        最高          高           最低
支持硬件      全部          较新卡       高端卡
配置复杂度    低            中           中高

MPS 的原理：
□ 传统多进程：各进程的 kernel 串行执行（时间片轮转）
□ MPS：多个进程的 kernel 在 SM 上并发执行
□ 用一个常驻的 MPS 控制进程（daemon）管理
□ 各客户端进程连接到控制进程 → 共享 CUDA context

# 启动 MPS 控制进程
export CUDA_MPS_PIPE_DIRECTORY=/tmp/nvidia-mps
export CUDA_MPS_LOG_DIRECTORY=/tmp/nvidia-log
nvidia-cuda-mps-control -d

# 设置默认算力占比（如 30%）
echo "set_default_active_thread_percentage 30" | nvidia-cuda-mps-control

# 显存上限（每客户端）
export CUDA_MPS_ACTIVE_THREAD_PERCENTAGE=50

# 停止
echo quit | nvidia-cuda-mps-control

MPS 的能力：
□ 并发执行：小 kernel 填满 SM 的空闲
□ 算力配额：active_thread_percentage 限制每进程的 SM 占用
□ 显存限制：可设每客户端的显存上限（软限制）
□ 提升利用率：尤其适合「多个小模型」场景

MPS 的局限：
□ 隔离是「软」的：一个进程崩溃可能拖垮控制进程
□ 显存不是硬隔离（可被绕过）
□ 不支持 MIG 的硬件级划分
□ 调试困难：错误可能跨进程传播

MIG 的原理：
□ 把一张 GPU 物理切分成多个独立实例
□ 每个实例有独立的 SM、显存、L2 缓存、带宽
□ 实例之间完全隔离（一个崩了不影响另一个）
□ 从驱动的角度，每个实例像一张独立的卡

A100 的切分档位（示例）：
□ 1g.5gb  : 1/7 算力，5 GB 显存
□ 2g.10gb : 2/7 算力，10 GB 显存
□ 3g.20gb : 3/7 算力，20 GB 显存
□ 7g.40gb : 整卡（7/7）
□ 可组合多个实例（如 2×3g + 1×1g）
□ H100 支持更多组合与更大显存

# MIG 操作
nvidia-smi mig -lgip                 # 列出可用的 GPU 实例配置
nvidia-smi mig -cgi 9,9,9 -C         # 创建 3 个实例
nvidia-smi mig -lgi                  # 列出已创建的实例
nvidia-smi -L                        # 查看 MIG 设备
# 使用：CUDA_VISIBLE_DEVICES=MIG-GPU-xxx/1/0

MIG 的优劣：
□ 优点：强隔离（显存、算力、故障）、可预测性能
□ 优点：适合多租户、生产核心服务
□ 缺点：切分粒度固定（不能超卖、不能动态调整）
□ 缺点：小切片利用率低（如 1g 只 5 GB 显存）
□ 缺点：仅高端卡支持（A100/H100/H200）

时间片共享的原理：
□ NVIDIA 驱动默认行为：多进程轮流使用 GPU
□ 每个进程获得一个时间片，交替执行
□ 显存不隔离（所有进程共享整卡显存）
□ 上下文切换有开销（尤其显存大的进程）

时间片的特点：
□ 优点：零配置、支持所有 GPU、利用率高
□ 缺点：显存不隔离（一个进程 OOM 可能影响其他）
□ 缺点：延迟抖动大（上下文切换 + 排队）
□ 缺点：无算力配额（谁抢到谁用）

抢占式与弹性复用：
□ 训练任务被高优先级推理任务抢占
□ 检查点保存 → 让出 GPU → 恢复后继续
□ 适合「训练用空闲算力、推理优先」的混部
□ 实现：调度器 + 检查点机制 + 优先级队列

时间片适用场景：
□ 开发/测试环境（容忍抖动）
□ 非延迟敏感的批处理
□ 突发负载的弹性复用
□ 不适合：延迟敏感的生产服务

三个隔离维度：
□ 显存隔离：A 租户的显存不被 B 挤占
  - MIG：硬件隔离（最强）
  - MPS：软限制（可设上限，可绕过）
  - 时间片：无隔离
□ 算力隔离：A 租户不抢光 B 的 SM
  - MIG：硬件隔离（按切片）
  - MPS：active_thread_percentage 配额
  - 时间片：无配额
□ 故障隔离：A 的进程崩溃不拖垮 B
  - MIG：完全隔离
  - MPS：部分（崩溃可能传播）
  - 时间片：弱（OOM 影响全局）

隔离能力对照：
维度        时间片    MPS      MIG
显存        无        软       硬
算力        无        配额     硬
故障        弱        部分     完全
性能可预测  差        中       好

多租户的额外考量：
□ 数据安全：不同租户的模型/数据不能互相访问
□ 配额管理：每租户的算力/显存配额
□ 计量计费：按使用量计费需要精确计量
□ 噪声邻居：一个租户的负载影响其他租户性能

K8s GPU 调度的层次：
□ 设备插件（Device Plugin）：nvidia-device-plugin 暴露 GPU 资源
□ 资源请求：nvidia.com/gpu: 1（默认整卡）
□ 共享扩展：
  - 时间片：配置 device plugin 的 sharing 策略
  - MPS：共享模式配置
  - MIG：暴露 MIG 实例为独立资源

# 时间片共享的 device plugin 配置（示意）
# 一个 GPU 被 4 个 Pod 共享
apiVersion: v1
kind: ConfigMap
metadata:
  name: nvidia-device-plugin-config
data:
  config: |
    version: v1
    sharing:
      timeSlicing:
        resources:
          - name: nvidia.com/gpu
            replicas: 4        # 一个物理卡切成 4 个逻辑卡

MIG 在 K8s 上的调度：
□ 预先创建 MIG 实例（mig-parted 或手动）
□ device plugin 把每个 MIG 实例暴露为独立资源
□ Pod 请求 mig-3g.20gb 等具体档位
□ 调度器按实例粒度分配 → 强隔离

调度框架与生态：
□ Volcano / Kueue：批调度与队列管理
□ 优先级与抢占：高优先级任务抢占低优先级
□ 拓扑感知：把 Pod 调度到有 MIG 实例的节点
□ GPU 亲和：同节点多卡通信优化

选型决策树：
□ 延迟敏感的生产服务 + 硬件支持 MIG → MIG
□ 多个小模型共享一卡 + 可容忍软隔离 → MPS
□ 开发测试/批处理/突发负载 → 时间片
□ 训练与推理混部 → 抢占式 + 检查点
□ 强隔离 + 高利用率不可兼得 → 按负载分层

分层共享策略（推荐）：
□ 核心服务：MIG 强隔离，保证性能可预测
□ 次要服务：MPS 软隔离 + 算力配额
□ 弹性/批处理：时间片共享，吃满空闲
□ 混部：训练用空闲，推理优先

容量与配额：
□ 按租户设配额（显存 + 算力）
□ 监控每租户的实际用量
□ 超卖要谨慎（MPS/时间片可超卖，MIG 不可）
□ 预留 buffer 应对突发

可观测性：
□ 每 GPU / 每 MIG 实例的利用率
□ 每租户的显存与算力占用
□ 延迟抖动（共享的直接代价）
□ 抢占事件与频率

高频踩坑：
□ 以为时间片有显存隔离 → 一个进程 OOM 拖垮其他
□ MPS 控制进程崩溃 → 所有客户端挂掉
□ MIG 切片太小 → 大模型放不下（显存不够）
□ 共享后延迟抖动大 → 违反 SLA（未做隔离）
□ 超卖过度 → 争抢导致性能雪崩
□ device plugin 未配 sharing → 一卡只能一个 Pod
□ MIG 实例创建后忘记销毁 → 资源泄漏
□ 混部未设优先级 → 训练任务饿死推理
□ 计量不准 → 多租户计费纠纷

排查清单：
□ nvidia-smi：查看每进程/每实例的占用
□ 延迟分布（P50/P99）：抖动是否来自共享
□ 上下文切换频率：时间片开销
□ MPS 日志：客户端连接与配额是否生效
□ MIG 实例列表：是否有泄漏
□ 配额执行情况：是否有租户超额