GPU 共享如何选：MIG、MPS 与时间切片的隔离账本

GPU 空闲并不意味着任何工作负载都适合混部。共享能提高利用率，也会改变故障、内存和性能干扰的边界。首先应该写清想隔离什么：设备内存、计算时间、故障影响，还是仅仅让调度器能够发放更多份资源声明。

三种机制别写成同一种切片

NVIDIA MIG 指南描述硬件实例的资源划分与隔离路径。MPS 官方概览还区分传统接口与显式选择的 v3 接口，当前文档包含内存和 SM 分区能力。因此不能笼统说 MPS 完全没有配额能力。MPS 以进程并发协调为基础，时间切片则是调度共享方式；它们不能直接互换，更不能只根据 Kubernetes 中的资源份数推断物理隔离。

三种机制处理的层级不同；具体可用功能受 GPU、驱动和设备插件版本限制。

先建一个约束矩阵

下面不是产品特性数据库，只演示需求筛选。若业务要求独立显存配额，就不能把“能运行多个任务”当作充分条件；真实特性必须按目标栈验证。

requirements = {"separate_memory_budget": True}
# Teaching declarations, not vendor feature discovery.
candidates = {"declared_partition": {"separate_memory_budget": True},
              "declared_time_share": {"separate_memory_budget": False}}
accepted = [name for name, caps in candidates.items()
            if all(caps.get(k) == v for k,v in requirements.items())]
print("accepted_by_declared_contract", accepted)
assert accepted == ["declared_partition"]

运行输出：

accepted_by_declared_contract ['declared_partition']

硬件实例也不是应用安全的全部边界。主机、网络、存储与管理权限仍可能共享。低优先级任务退出能否释放资源、某个租户 OOM 是否影响别人，要通过故障注入确认。

用相同负载测干扰

对每个候选机制，先单独运行，再加入一个内存带宽密集或计算密集的邻居，固定请求长度与模型 revision，比较尾延迟和失败率。不能把不同模型的结果摆在一起，声称某种机制“零干扰”。

10 月多硬件后端进展也提示可移植接口与资源语义不是一回事。应用层资源契约应明确列出后端差异。

本文只执行 CPU 需求筛选，未创建 MIG、启用 MPS 或配置设备插件。结论是先写隔离需求，再选共享机制；没有一张虚构跑分表能够替代这一步。