与 MIG/MPS 对比

TensorFusion 与 NVIDIA 自带的 GPU 共享机制（MIG、MPS、Time-slicing）是什么关系，什么情况下用自带机制就够了

MIG、MPS 和 Time-slicing 是 NVIDIA 驱动自带的 GPU 共享机制。它们解决的是单张 GPU 的问题，不是池化系统：每种机制只决定多个进程怎样共用一张卡，不负责集群层面的调度、配额和伸缩。TensorFusion 工作在集群这一层，底层也会用到其中一部分机制。如果每张卡按固定方式切分就能满足需求，用自带机制即可，不需要额外安装组件。

三种机制

	MIG（Multi-Instance GPU）	MPS（Multi-Process Service）	Time-slicing
共享方式	把一张 GPU 切成最多 7 个实例，每个实例有独立的显存、缓存和计算核心。	多个进程通过同一个 server 进程，同时在一张 GPU 上执行。	轮流使用：每个进程在自己的时间片内独占整张 GPU。
显存限制	由实例规格固定。	可按客户端设置上限（`CUDA_MPS_PINNED_DEVICE_MEM_LIMIT`）。	无。
算力限制	由实例规格固定。	可按客户端设置上限（`CUDA_MPS_ACTIVE_THREAD_PERCENTAGE`）。	无。多申请几个副本，并不会按比例得到更多算力。
故障隔离	有。一个实例出错不影响其他实例。	有限。各客户端的 GPU 地址空间相互独立，但某个客户端触发致命 GPU 故障时，共用这张 GPU 的所有客户端都会受影响。	无。
硬件要求	部分数据中心 GPU，从 Ampere 架构开始。	Linux 上的 NVIDIA GPU。	任意 NVIDIA GPU。
在 Kubernetes 中	device plugin 把实例暴露为 `nvidia.com/mig-1g.5gb` 这类资源。	device plugin 为每张 GPU 上报若干副本。	device plugin 为每张 GPU 上报若干副本。

一览

	TensorFusion	MIG / MPS / Time-slicing
作用范围	集群：池化、调度、配额、自动伸缩，以及每个 Pod 的限额。	单张 GPU：进程之间怎样共用。
许可	核心组件 Apache 2.0；远程 client 与 worker 不开源。	随 NVIDIA 驱动提供，无需额外授权；Kubernetes device plugin 和 GPU Operator 是开源的。
加速卡	NVIDIA，以及支持部分模式的华为昇腾、摩尔线程、阿里 PPU。	仅 NVIDIA；MIG 还要求 GPU 型号支持。
切分规格	每个 Pod 自行指定任意大小的算力（TFLOPS 或百分比）和显存。	MIG：每种 GPU 型号有一份固定的规格列表；MPS 和 Time-slicing：管理员为每张 GPU 设定副本数。
调整切分	`soft` 模式下，限额可以在工作负载运行期间调整。	MIG：重新配置 GPU；Time-slicing 和 MPS：修改 device plugin 配置。
请求与限额	分开设置，空闲算力可以借出，需要时再收回。	没有这种区分。
硬件隔离	`partitioned` 模式，分配的就是 MIG 实例。	MIG。
通过网络远程使用 GPU	支持，以 NVIDIA GPU 为主，见支持矩阵。	不支持。
超额分配	按资源池设置：算力超卖倍数，以及主机内存、磁盘计入可调度显存的比例。	Time-slicing 允许多个 Pod 不设限额地共用一张 GPU，不统计显存。
调度	自有调度器，掌握每张 GPU 剩余的 TFLOPS 和显存：紧凑装箱或负载均摊、GPU 拓扑感知、Gang 调度、命名空间配额、QoS 等级。	Kubernetes 默认调度器，只把副本或实例当作整数计数。
自动伸缩	根据用量调整 GPU 请求与限额；增减 GPU 节点。	无。
可观测性	按工作负载统计的 GPU 指标，内置告警规则。	DCGM exporter；开启 Time-slicing 后无法把指标对应到容器。

TensorFusion 怎样使用这些机制

TensorFusion 不是要取代这些机制。它的几种隔离模式有的建立在它们之上，有的与它们并列：

shared 模式不设限额，依靠 GPU 自身的时间片轮转，和 device plugin 的 Time-slicing 副本类似。区别在于调度依据是显存和算力请求，而不是固定的副本数。
partitioned 模式分配的是 MIG 实例。TensorFusion 根据请求挑选合适的规格，并记录每张 GPU 上哪些位置空闲。
soft 模式是 TensorFusion 自己的 limiter。它和 MPS 的限制一样运行在用户态，按工作负载限制算力和显存；不同的是，节点上的 hypervisor 会在运行时调整上限，突发、QoS 等级和自动伸缩都建立在这一点上。
hard 模式把 GPU 调用放到独立的 worker 进程里执行，并按固定份额限制算力。

有一点不变：只有 MIG 提供硬件级边界。需要这种保证时请使用 MIG，可以直接用，也可以通过 partitioned 模式用。

申请 GPU 的写法

用 NVIDIA GPU Operator 开启 Time-slicing，需要先用 ConfigMap 定好副本数，再按普通方式申请 GPU：

apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
  namespace: gpu-operator
data:
  any: |-
    version: v1
    flags:
      migStrategy: none
    sharing:
      timeSlicing:
        resources:
          - name: nvidia.com/gpu
            replicas: 4
---
# Pod：占用 4 个副本中的 1 个，没有显存和算力限制
resources:
  limits:
    nvidia.com/gpu: 1

MIG 需要事先把 GPU 分好区，再申请某一种规格的实例：

resources:
  limits:
    nvidia.com/mig-1g.5gb: 1

TensorFusion 不需要为每张 GPU 事先做规划，每个 Pod 写明自己要多少：

metadata:
  labels:
    tensor-fusion.ai/enabled: "true"
  annotations:
    tensor-fusion.ai/tflops-request: "10"
    tensor-fusion.ai/tflops-limit: "20"
    tensor-fusion.ai/vram-request: "4Gi"
    tensor-fusion.ai/vram-limit: "4Gi"

想通过 TensorFusion 拿到 MIG 实例，加上 tensor-fusion.ai/isolation: partitioned。全部注解的说明见创建工作负载。

怎么选

以下情况单用自带机制就够了：

租户之间需要硬件隔离，并且固定的 MIG 规格正好适合你的工作负载。
集群规模小，每张 GPU 的切分方式很少变动。
希望组件越少越好：只有 NVIDIA 驱动和 device plugin。
工作负载彼此信任，只需要轮流使用 GPU，Time-slicing 就能满足。

以下情况选 TensorFusion：

工作负载大小不一，套不进固定的规格列表，也没法给每张 GPU 定一个统一的副本数。
希望按 Pod 限制 GPU 算力和显存，并且请求可以低于限额，把空闲算力用起来。
需要调度器清楚每张 GPU 还剩多少资源，还需要配额、QoS 等级或 Gang 调度。
希望 GPU 节点随需求伸缩，或者让 CPU 节点上的 Pod 远程使用 GPU。
已经在用 MIG，希望实例按需分配，而不是人工规划。

参考资料

核对时间为 2026 年 10 月：

NVIDIA MIG User Guide：实例数量上限、支持的 GPU、隔离性。
NVIDIA Multi-Process Service：资源限制、内存保护、错误隔离范围。
Time-slicing GPUs in Kubernetes：配置方式与限制。

三种机制

	MIG（Multi-Instance GPU）	MPS（Multi-Process Service）	Time-slicing
共享方式	把一张 GPU 切成最多 7 个实例，每个实例有独立的显存、缓存和计算核心。	多个进程通过同一个 server 进程，同时在一张 GPU 上执行。	轮流使用：每个进程在自己的时间片内独占整张 GPU。
显存限制	由实例规格固定。	可按客户端设置上限（`CUDA_MPS_PINNED_DEVICE_MEM_LIMIT`）。	无。
算力限制	由实例规格固定。	可按客户端设置上限（`CUDA_MPS_ACTIVE_THREAD_PERCENTAGE`）。	无。多申请几个副本，并不会按比例得到更多算力。
故障隔离	有。一个实例出错不影响其他实例。	有限。各客户端的 GPU 地址空间相互独立，但某个客户端触发致命 GPU 故障时，共用这张 GPU 的所有客户端都会受影响。	无。
硬件要求	部分数据中心 GPU，从 Ampere 架构开始。	Linux 上的 NVIDIA GPU。	任意 NVIDIA GPU。
在 Kubernetes 中	device plugin 把实例暴露为 `nvidia.com/mig-1g.5gb` 这类资源。	device plugin 为每张 GPU 上报若干副本。	device plugin 为每张 GPU 上报若干副本。

一览

	TensorFusion	MIG / MPS / Time-slicing
作用范围	集群：池化、调度、配额、自动伸缩，以及每个 Pod 的限额。	单张 GPU：进程之间怎样共用。
许可	核心组件 Apache 2.0；远程 client 与 worker 不开源。	随 NVIDIA 驱动提供，无需额外授权；Kubernetes device plugin 和 GPU Operator 是开源的。
加速卡	NVIDIA，以及支持部分模式的华为昇腾、摩尔线程、阿里 PPU。	仅 NVIDIA；MIG 还要求 GPU 型号支持。
切分规格	每个 Pod 自行指定任意大小的算力（TFLOPS 或百分比）和显存。	MIG：每种 GPU 型号有一份固定的规格列表；MPS 和 Time-slicing：管理员为每张 GPU 设定副本数。
调整切分	`soft` 模式下，限额可以在工作负载运行期间调整。	MIG：重新配置 GPU；Time-slicing 和 MPS：修改 device plugin 配置。
请求与限额	分开设置，空闲算力可以借出，需要时再收回。	没有这种区分。
硬件隔离	`partitioned` 模式，分配的就是 MIG 实例。	MIG。
通过网络远程使用 GPU	支持，以 NVIDIA GPU 为主，见支持矩阵。	不支持。
超额分配	按资源池设置：算力超卖倍数，以及主机内存、磁盘计入可调度显存的比例。	Time-slicing 允许多个 Pod 不设限额地共用一张 GPU，不统计显存。
调度	自有调度器，掌握每张 GPU 剩余的 TFLOPS 和显存：紧凑装箱或负载均摊、GPU 拓扑感知、Gang 调度、命名空间配额、QoS 等级。	Kubernetes 默认调度器，只把副本或实例当作整数计数。
自动伸缩	根据用量调整 GPU 请求与限额；增减 GPU 节点。	无。
可观测性	按工作负载统计的 GPU 指标，内置告警规则。	DCGM exporter；开启 Time-slicing 后无法把指标对应到容器。

TensorFusion 怎样使用这些机制

TensorFusion 不是要取代这些机制。它的几种隔离模式有的建立在它们之上，有的与它们并列：

shared 模式不设限额，依靠 GPU 自身的时间片轮转，和 device plugin 的 Time-slicing 副本类似。区别在于调度依据是显存和算力请求，而不是固定的副本数。
partitioned 模式分配的是 MIG 实例。TensorFusion 根据请求挑选合适的规格，并记录每张 GPU 上哪些位置空闲。
soft 模式是 TensorFusion 自己的 limiter。它和 MPS 的限制一样运行在用户态，按工作负载限制算力和显存；不同的是，节点上的 hypervisor 会在运行时调整上限，突发、QoS 等级和自动伸缩都建立在这一点上。
hard 模式把 GPU 调用放到独立的 worker 进程里执行，并按固定份额限制算力。

有一点不变：只有 MIG 提供硬件级边界。需要这种保证时请使用 MIG，可以直接用，也可以通过 partitioned 模式用。

申请 GPU 的写法

用 NVIDIA GPU Operator 开启 Time-slicing，需要先用 ConfigMap 定好副本数，再按普通方式申请 GPU：

apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
  namespace: gpu-operator
data:
  any: |-
    version: v1
    flags:
      migStrategy: none
    sharing:
      timeSlicing:
        resources:
          - name: nvidia.com/gpu
            replicas: 4
---
# Pod：占用 4 个副本中的 1 个，没有显存和算力限制
resources:
  limits:
    nvidia.com/gpu: 1

MIG 需要事先把 GPU 分好区，再申请某一种规格的实例：

resources:
  limits:
    nvidia.com/mig-1g.5gb: 1

TensorFusion 不需要为每张 GPU 事先做规划，每个 Pod 写明自己要多少：

metadata:
  labels:
    tensor-fusion.ai/enabled: "true"
  annotations:
    tensor-fusion.ai/tflops-request: "10"
    tensor-fusion.ai/tflops-limit: "20"
    tensor-fusion.ai/vram-request: "4Gi"
    tensor-fusion.ai/vram-limit: "4Gi"

想通过 TensorFusion 拿到 MIG 实例，加上 tensor-fusion.ai/isolation: partitioned。全部注解的说明见创建工作负载。

怎么选

以下情况单用自带机制就够了：

租户之间需要硬件隔离，并且固定的 MIG 规格正好适合你的工作负载。
集群规模小，每张 GPU 的切分方式很少变动。
希望组件越少越好：只有 NVIDIA 驱动和 device plugin。
工作负载彼此信任，只需要轮流使用 GPU，Time-slicing 就能满足。

以下情况选 TensorFusion：

工作负载大小不一，套不进固定的规格列表，也没法给每张 GPU 定一个统一的副本数。
希望按 Pod 限制 GPU 算力和显存，并且请求可以低于限额，把空闲算力用起来。
需要调度器清楚每张 GPU 还剩多少资源，还需要配额、QoS 等级或 Gang 调度。
希望 GPU 节点随需求伸缩，或者让 CPU 节点上的 Pod 远程使用 GPU。
已经在用 MIG，希望实例按需分配，而不是人工规划。

参考资料

核对时间为 2026 年 10 月：

NVIDIA MIG User Guide：实例数量上限、支持的 GPU、隔离性。
NVIDIA Multi-Process Service：资源限制、内存保护、错误隔离范围。
Time-slicing GPUs in Kubernetes：配置方式与限制。

三种机制

一览

TensorFusion 怎样使用这些机制

申请 GPU 的写法

怎么选

参考资料

目录

与 MIG/MPS 对比

三种机制

一览

TensorFusion 怎样使用这些机制

申请 GPU 的写法

怎么选

参考资料

目录