本文定位：面向负责AI算力平台、K8s集群资源池和多租户GPU环境的团队，重点讨论共享方案选择口径，不替代具体设备、驱动和插件版本的实施手册。
K8s GPU共享的核心问题不是“能不能把一张卡分出去”，而是共享以后任务是否可预测、租户是否隔离、显存是否可控、调度是否还能解释。MIG、时间片和MPS都可能提升资源利用，但它们解决的问题并不相同。
K8s中GPU共享先看选择结论
如果只需要一个快速判断，可以先把负载分成三类：稳定规格的生产推理、短时弹性的开发测试、以及对显存和性能抖动敏感的训练任务。共享方案的优先级会随任务类型变化。
选择路径可以先按三步判断：
- 先看隔离要求：租户之间不能互相影响、需要稳定显存边界时，优先评估MIG。
- 再看负载形态：大量短任务、Notebook、轻量推理或低峰复用场景，可以评估时间片共享。
- 最后看运维能力：如果监控、配额、队列和故障定位还不成熟，不宜一次性把共享范围放到所有GPU节点。
图1：先按隔离强度、负载稳定性和显存边界选择GPU共享方案
这里容易出现一个误区：把所有共享方式都理解成“把GPU切小”。在K8s里，资源上报、Pod请求、节点标签、调度策略和运行时隔离共同决定最终效果。MIG更像把硬件能力切成可声明的实例，时间片更像让多个工作负载在同一张卡上轮流使用。
MIG、时间片和MPS分别解决什么问题
MIG、时间片和MPS的出发点不同。选型时不要只看“能让几个Pod用一张卡”，而要看是否需要硬件级隔离、是否允许性能波动、是否能接受应用侧适配成本。
| 方案 | 更适合解决的问题 | 主要优势 | 主要限制 |
|---|---|---|---|
| MIG | 固定规格GPU实例、租户隔离、稳定推理服务 | 隔离边界清晰，资源规格更可控 | 依赖硬件能力，实例规格不够灵活 |
| 时间片共享 | 开发测试、轻量推理、低负载复用 | 接入相对灵活，适合提升低峰利用率 | 性能抖动更明显，显存边界需要额外治理 |
| MPS | 多进程并发执行、细粒度GPU利用 | 有机会降低单任务独占造成的空闲 | 应用行为和运行时约束更复杂 |
选择标准要回到业务SLO
表格不能直接替代决策。生产推理服务如果有明确延迟目标，时间片共享带来的排队和上下文切换可能让尾延迟不稳定；而开发测试场景如果把每个Notebook都绑定整卡，资源浪费又会非常明显。
在平台层面，MIG与时间片最终都要通过 GPU调度 回到资源发现、节点选择、Pod资源请求和调度结果解释。只在运行时层面打开共享能力，却没有配套调度和观测，后续问题会集中暴露在“任务为什么排不到合适GPU”和“同一节点为什么突然变慢”。
哪些场景优先选择MIG
MIG更适合对隔离、可预测性和规格稳定性要求较高的场景。比如多租户推理服务、部门级资源池、长期运行的在线任务，平台团队通常更关心每个租户获得的显存、计算单元和故障影响范围是否清楚。
优先考虑MIG的典型信号包括：
- 租户边界明确：不同团队或业务线不能互相抢占显存。
- 负载规格稳定：模型大小、batch策略和服务副本数变化不频繁。
- 服务质量敏感：推理延迟、失败率和重启恢复需要稳定观察。
- 容量规划清晰：平台能提前定义常用GPU实例规格，并接受实例粒度带来的碎片。
MIG的代价是灵活性下降。实例规格一旦固定，任务如果刚好比某个实例略大，就可能无法使用剩余资源；如果规格设计过多，平台维护复杂度也会上升。因此MIG不是“永远更稳”的答案，而是适合把稳定性和隔离放在优先级前面的场景。
图2：MIG更强调硬隔离，时间片更强调资源利用率和弹性
哪些场景适合时间片共享
时间片共享更适合弹性、短时、低负载或可接受波动的任务。它常见于开发测试、实验环境、轻量推理、教学平台和低峰资源复用。此类场景的主要矛盾不是稳定隔离，而是整卡独占导致大量空闲。
时间片共享上线前要先确认：
- 任务是否能接受吞吐或延迟波动。
- 显存是否有明确限制或告警策略。
- 单个任务异常是否会影响同卡其他任务。
- 是否能按命名空间、队列或租户限制共享比例。
- 监控能否区分GPU利用率、显存使用、队列等待和任务失败原因。
时间片共享尤其需要避免“看起来利用率提高，实际体验下降”。如果平台只统计GPU忙碌程度，却不观察任务等待时间、推理尾延迟和失败重试，资源复用可能掩盖了用户侧的性能抖动。
生产落地GPU共享要检查哪些治理边界
共享方案进入生产前，平台团队需要把技术开关变成可运营能力。也就是说，不能只让Pod可以申请共享GPU，还要能解释资源归属、故障影响、计量口径和回收策略。
| 治理边界 | 需要回答的问题 | 常见风险 |
|---|---|---|
| 显存边界 | 单个任务最多能使用多少显存 | 显存争抢导致同卡任务连带失败 |
| 性能边界 | 共享后延迟和吞吐如何观察 | 平均利用率好看，但尾延迟变差 |
| 租户边界 | 谁可以使用共享GPU，谁只能独占 | 高优先级任务被低优先级实验挤占 |
| 计量边界 | 共享实例如何计费或分摊成本 | 费用归属不清，团队不愿迁移 |
| 故障边界 | 单个Pod异常如何隔离和恢复 | 驱动、运行时或显存问题扩大影响 |
共享策略要与配额和队列联动
GPU共享一旦进入多租户环境，就会影响队列、公平性和资源预留。平台不应只看单节点利用率，还要把共享实例纳入 算力调度 的队列、配额和优先级治理中，避免某类低优先级任务长期占用可用于生产服务的资源。
图3：生产环境需要同时检查显存、性能抖动、监控和租户边界
上线前至少检查：
- 资源声明：Pod请求的GPU规格是否能被调度器和运行时一致理解。
- 节点分组：MIG节点、时间片节点和独占节点是否通过标签或池化策略区分。
- 监控指标：是否能看到GPU利用率、显存、任务等待、失败重试和节点异常。
- 灰度范围：是否先在开发测试或低风险推理场景验证，再扩大到核心业务。
- 回退策略：共享策略异常时，是否能快速回到独占卡或固定实例模式。
小结
K8s GPU共享的选择不是MIG与时间片二选一，而是把隔离强度、负载稳定性、显存边界和平台治理能力排出优先级。MIG适合规格稳定、隔离要求高的生产场景；时间片适合弹性、短时、可接受波动的复用场景；MPS则需要结合应用并发模型谨慎评估。
更稳妥的落地方式是分层推进：先划分独占、MIG和时间片资源池，再用配额、队列、监控和故障回退保护生产任务。只有共享能力能被调度、观测和运营解释，GPU利用率提升才不会变成新的稳定性风险。
FAQ
K8s GPU共享一定要优先选MIG吗？
不一定。MIG适合隔离和可预测性优先的场景，例如多租户生产推理或固定规格服务。如果任务是开发测试、短时实验或可接受波动的轻量推理，时间片共享可能更灵活。选择时应先看业务SLO、显存边界和租户影响范围，而不是只看共享数量。
时间片GPU共享会不会影响推理延迟？
有可能。时间片让多个任务轮流使用同一张GPU，吞吐、排队和上下文切换都会影响体验。对于延迟敏感服务，建议先在低风险流量中观察尾延迟、失败率和重试次数，再决定是否扩大共享范围。
MIG和时间片可以在同一个K8s集群里同时使用吗？
可以按资源池或节点池区分，但不建议混在没有治理边界的同一类节点里。平台应通过节点标签、资源类、配额和调度策略说明哪些任务使用MIG，哪些任务使用时间片，避免用户申请资源时无法理解实际隔离效果。
K8s GPU共享上线前最容易漏掉什么？
最容易漏掉的是显存和故障边界。很多团队只关注GPU利用率，却没有把显存上限、异常任务隔离、节点驱动问题和租户级告警纳入检查。上线前应同时验证监控、限额、回退和用户说明文档。
