3.2 MIG与时间切片GPU共享取舍

文档摘要

3.2 MIG 与时间切片 GPU 共享：把一块卡掰开用的取舍读者学完这一节，应该能回答：「当我的 GLM-5.2 推理流量不够塞满一整块卡时，是用 MIG 硬切，还是用时间切片软共享？」——并且知道各自的雷区在哪。第二章我们默认「一个 Pod 独占整卡」。这在显存和算力都吃紧的大模型推理里很合理，但现实往往是：大部分时候流量用不满一整块 A100，可又确实有若干个独立服务/租户要跑。整卡独占太浪费，混部又怕互相打架。这一节就来讲「把一块 GPU 掰开用」的两条主流路径，以及我为什么常建议「推理服务优先别切」。一、先问自己：你真的需要 GPU 共享吗在动手切卡之前，先诚实回答三个问题：单实例真的用不满一张卡吗？如果 GLM-5.

3.2 MIG 与时间切片 GPU 共享：把一块卡掰开用的取舍

读者学完这一节，应该能回答：「当我的 GLM-5.2 推理流量不够塞满一整块卡时，是用 MIG 硬切，还是用时间切片软共享？」——并且知道各自的雷区在哪。

第二章我们默认「一个 Pod 独占整卡」。这在显存和算力都吃紧的大模型推理里很合理，但现实往往是：大部分时候流量用不满一整块 A100，可又确实有若干个独立服务/租户要跑。 整卡独占太浪费，混部又怕互相打架。这一节就来讲「把一块 GPU 掰开用」的两条主流路径，以及我为什么常建议「推理服务优先别切」。

一、先问自己：你真的需要 GPU 共享吗

在动手切卡之前，先诚实回答三个问题：

单实例真的用不满一张卡吗？ 如果 GLM-5.2 单实例 KV Cache 已经吃满整卡（回忆 3.1 的显存公式），那共享只会让两个都饿死，正确做法是升配/加卡，不是切分。
多个负载是否需要硬隔离？ 如果是一个模型的不同副本，本就不该切分，用多副本 + Service 负载均衡即可（第二章 2.3 思路）。需要隔离的，通常是不同模型 / 不同租户 / 测试与生产混跑。
你能接受共享带来的性能抖动吗？ 时间切片会带来延迟尖刺，MIG 会牺牲峰值算力。不能接受的延迟敏感场景，宁可空着卡也别共享。

我的主张很直接：推理服务（尤其是 GLM-5.2 这种吃显存的服务）默认整卡独占；只有「明显用不满 + 需要隔离 + 能容忍抖动」三者同时满足，才考虑共享。 大多数团队过早切卡，最后都在排奇怪的延迟问题。

二、路径 A：MIG（Multi-Instance GPU）——硬件级硬切

MIG 是 NVIDIA A100 / H100 等数据中心卡的硬件能力，它把一块物理 GPU 在硬件层面切成多个「实例」，每个实例拥有独立的显存、缓存和算力切片，彼此强隔离——一个实例 OOM 不会拖垮另一个，调度器也保证算力配额。

MIG 的切片是固定的几个档位，不是任意比例。以 A100 80G 为例，常见切法：

1g.10gb：1/8 算力、10G 显存
2g.20gb：1/4 算力、20G 显存
3g.40gb：3/8 算力、40G 显存
7g.80gb：整卡

注意「g」前面的数字就是算力切片比例。下面这张图展示一块 A100 怎么被 MIG 切成多个强隔离实例：

MIG 的优点：

强隔离，故障域不扩散，适合多租户。
算力配额有保证，不会因邻居抢算力而掉速。
Kubernetes 通过 NVIDIA GPU Operator 的 MIG 策略 + device plugin 直接调度，Pod 申请 nvidia.com/mig-2g.20gb 即可。

MIG 的代价：

切片档位固定，灵活度低。想要「正好 15G」做不到，只能选最近的档。
一旦切分，整卡算力被固定摊薄。一个 3g.40gb 实例永远只有 3/8 算力——即使它空闲，那 5/8 也不会借给别的实例。对峰值吃算力的 GLM-5.2 生成阶段不友好。
切分后单实例显存上限被锁死，想临时扩 KV Cache 也扩不了。

三、路径 B：时间切片（Time-Slicing）——软件级软共享

时间切片不切硬件，而是让多个 Pod 分时复用同一块卡。实现上通常借助 NVIDIA device plugin 的 time-slicing 配置，把一个物理 GPU 暴露成多个「虚拟 GPU」，多个 Pod 轮流上卡跑。

更细一层还有 MPS（Multi-Process Service）：多个进程把 kernel 并发提交到同一个 context，减少上下文切换开销，适合「多个小负载都想低延迟」的场景。

时间切片的直观模型：

```mermaid sequenceDiagram participant A as Pod A (GLM-5.2 副本1) participant B as Pod B (小模型) participant GPU as 同一块物理 GPU A->>GPU: 时间片 t1 执行 Note over GPU: 时间切片轮转 B->>GPU: 时间片 t2 执行 A->>GPU: 时间片 t3 执行 Note over A,B: 共享显存，分时算力 ```

时间切片的优点：

灵活，不锁定档位，按需挂多个 Pod。
显存是共享池（除非配合 MPS 限制），某个 Pod 空闲时，别的 Pod 能用到更多显存——比 MIG 更「弹性」。
配置简单，改 device plugin 的 config 即可，不用重启机器切 MIG 档位。

时间切片的代价（也是主要雷区）：

无算力隔离：A 在跑重负载时，B 的延迟会明显上升，出现尖刺。延迟敏感的服务慎用。
显存是共享的：两个 Pod 一起涨显存，OOM 会一起死，故障域扩大。
调度上容易「超卖」——你以为挂了 4 个 Pod 都能跑，结果峰值同时涨显存直接炸卡。

四、MIG vs 时间切片：一张表说清怎么选

维度	MIG 硬件切分	时间切片软共享
隔离强度	强（硬件级）	弱（共享显存）
算力保证	有固定配额	无，分时争抢
显存弹性	固定锁死	共享池，弹性但易 OOM
配置复杂度	高（切档位、重启）	低（改 config）
适合场景	多租户强隔离、SLA 要求	开发测试混部、弹性闲时
对 GLM-5.2 推理	仅适合显存需求小的实例档	不推荐主推理，易抖动

我的结论：生产推理（尤其是 GLM-5.2 这种显存 + 算力双高）默认整卡独占；要隔离优先 MIG；时间切片只留给测试 / 低风险混部。 别用时间切片跑核心推理链路，那是延迟事故的温床。

五、在 vLLM + Kubernetes 里怎么落地

无论 MIG 还是时间切片，落到 K8s 都是「Pod 申请 GPU 资源」这件事，但细节有别。

MIG 落地：

在节点用 nvidia-smi mig 或 GPU Operator 的 MIG 策略创建实例档位。
device plugin 把 nvidia.com/mig-3g.40gb 这类资源暴露给调度器。
Pod 的 resources.limits 写对应的 MIG 资源名，而非 nvidia.com/gpu。
vLLM 的 --tensor-parallel-size 设为 1（MIG 实例内无法再跨实例并行），--gpu-memory-utilization 按该实例显存档位（如 40G）重新换算。

时间切片落地：

修改 NVIDIA device plugin 的 config，设置某卡的 time-slicing.replicas（如 4）。
多个 Pod 都申请 nvidia.com/gpu，调度器把它们挤到同一张卡分时跑。
务必配 resource quota / 限制副本数，防止超卖炸卡。

下面这张图对比两种路径在 K8s 调度里的资源形态：

```mermaid flowchart LR subgraph MIG方式 P1[Pod A 申请 mig-2g.20gb] --> N1[节点 MIG 实例 2g.20gb] P2[Pod B 申请 mig-3g.40gb] --> N2[节点 MIG 实例 3g.40gb] end subgraph 时间切片方式 Q1[Pod C 申请 nvidia.com/gpu] --> G[同一物理卡分时] Q2[Pod D 申请 nvidia.com/gpu] --> G end ```

六、三个 90% 的人会踩的坑

坑：用时间切片跑 GLM-5.2 主链路，然后投诉「为什么晚上延迟飘」。
晚上流量叠加，多 Pod 抢同一卡，时间片轮转导致生成延迟尖刺。主推理请整卡独占或 MIG。
坑：MIG 切太碎，单实例显存不够 GLM-5.2 起服务。
选 MIG 档位前，先用 3.1 的显存公式算清「GLM-5.2 权重 + 最少 KV」要多少 G，再选档。别选 1g.10gb 然后惊奇为什么起不来。
坑：MIG 实例空闲算力被浪费，却误以为「卡还有余量」。
MIG 的算力是钉死在实例上的，实例空着，那部分算力谁也用不上。这不是 bug，是设计。规划容量时要按「已分配实例数 × 单实例算力」算总账。

八、实战推演：三个具体决策的取舍

把前面的原则落到三个你一定会遇到的真实决策上。

决策 1：一块 A100 要同时跑 GLM-5.2 推理 + 一个轻量 embedding 模型，怎么分？

embedding 模型显存小、算力轻、延迟不敏感。正确做法不是时间切片硬挤，而是用 MIG 把卡切成 3g.40gb（给 GLM-5.2）+ 剩余给 embedding 实例，强隔离保证推理不被 embedding 拖。若 embedding 显存需求极小（如 < 10G），也可切 1g.10gb 给它，主推理占 7g.80gb 满血跑。

决策 2：开发环境 8 个人共用 2 块卡做 GLM-5.2 调试，怎么配？

调试流量低、容忍抖动、要弹性。这里时间切片最合适：每块卡 time-slicing.replicas=4，8 个人每人一个 Pod 分时跑，显存共享池弹性利用，配置还简单。千万别上 MIG——8 个固定小档位既浪费又不够灵活。

决策 3：生产要接两个外部租户的 GLM-5.2 推理，SLA 不同，怎么隔离？

租户间强隔离 + SLA 要求 = MIG。按两租户各自的 3.1 显存公式选档位，各自独占实例，互不影响。时间切片在这里是事故源头，绝对不用。

下面这张图把三个决策对应到路径：

```mermaid flowchart LR D1[推理+embedding并存] --> MIG1[MIG 硬隔离] D2[开发共用调试] --> TS[时间切片弹性] D3[多租户SLA隔离] --> MIG2[MIG 强隔离] D4[核心推理主链路] --> FULL[整卡独占] ```

九、和第一章、第二章的连接

第一章 1.2 讲推理框架选型，这里决定了「能不能用 vLLM 的 PagedAttention / 量化」影响显存账；
第二章 2.1 的 PVC/本地盘决定了权重加载快慢，间接影响冷启动后 KV 预算的可用窗口；
第二章 2.2 的 Deployment 参数里，resources.limits 的 GPU 申请方式，正是本节 MIG / 时间切片落地的最末端——你在 2.2 写的 nvidia.com/gpu: 1，换成 MIG 就是 nvidia.com/mig-3g.40gb: 1。

所以「GPU 共享」不是孤立一章，它直接改写你第二章 Deployment 的资源声明。改共享策略前，务必回头同步 2.2 的 limits 写法。

十、监控与告警：共享方案上线后盯什么

共享 GPU 最怕「看不见」。无论 MIG 还是时间切片，上线后这几条必须进监控：

MIG 场景： 每个 MIG 实例的显存占用、算力利用率、实例健康状态。重点盯「实例空闲但邻居爆满」——这说明档位切错了，容量规划失真。
时间切片场景： 同卡多个 Pod 的总显存、P99 延迟抖动幅度。一旦出现「某 Pod 延迟随邻居负载同步起伏」，就是分时争抢的典型信号，该考虑迁走或改 MIG。
通用： nvidia.com/gpu 申请数 vs 物理卡数，防止 device plugin 配置错误导致的静默超卖。

我的经验：时间切片上线的第一周，每天看一次 P99 延迟分布，确认抖动在可接受区间；MIG 上线则重点看各实例显存是否「切太大导致浪费」或「切太小导致起不来」。监控不到位就上共享，等于蒙眼开车。

十一、容量规划清单

核心推理实例：整卡独占，tensor-parallel-size 按卡数设。
多租户强隔离：MIG，档位用显存公式反推。
测试 / 闲时混部：时间切片，但限定 replicas 总数 + 配 ResourceQuota。
永远先算「单实例最少显存」，再决定切不切、怎么切。
监控上盯 nvidia.com/gpu 用量、MIG 实例健康、以及共享场景下的 P99 延迟抖动。

十二、改共享策略的运维代价：别只看技术，看排期

最后说一个容易被忽略的隐性成本：切换共享策略不是改个 YAML 就完事。

切 MIG 档位，往往要在节点上 nvidia-smi mig -cgi ... 重新创建实例，期间该节点 GPU 上的 Pod 必须驱逐，等于一次节点维护窗口。在生产集群里，这意味着要申请变更、挑低峰、走审批。
切 时间切片，改的是 device plugin 的 config（通常以 ConfigMap + 滚动重启 device plugin DaemonSet 生效），相对轻量，但同样可能瞬间让该节点的 GPU 资源视图变化，已在跑的 Pod 不受影响，新调度会按新 replicas 走。

所以决策时要把「将来会不会改」也算进去：如果你预判 3 个月内租户会扩，MIG 档位选太死后面迁移成本高；时间切片则灵活得多。我的做法是用 MIG 给「稳定、长生命周期」的隔离负载，用时间切片给「还在试、会变」的负载，让运维代价和负载稳定性匹配。

十三、一页纸速记（给赶时间的读者）

主推理链路：整卡独占，别切。
要强隔离多租户：上 MIG，档位先用 3.1 显存公式反推。
测试 / 闲时弹性混部：时间切片，但限 replicas + ResourceQuota。
MIG 算力钉死、显存锁死；时间切片弹性但无隔离、有抖动。
切 MIG 要节点维护窗口，切时间切片只是改 device plugin config。
改共享策略前，回头同步第二章 2.2 的 resources.limits 写法。

把这几条贴在工位上，90% 的 GPU 共享选型争论都能当场拍板。

小结

把一块卡掰开用，本质是「隔离 vs 弹性」的权衡：MIG 用固定档位换强隔离和算力保证，时间切片用共享池换弹性却牺牲隔离、引入抖动。对 GLM-5.2 这类吃显存又吃算力的推理，我的建议是「主链路整卡独占，隔离需求上 MIG，时间切片只用在测试和闲时」。这一节和 3.1 的显存公式合起来，就是你做 GPU 容量决策的全部依据。

下一章我们进入实战案例：怎么用压测摸清这块卡的真相、怎么做灰度、怎么把推理服务真正生产化。