Compare with MIG/MPS

MIG, MPS, and time-slicing are the GPU sharing mechanisms built into NVIDIA's driver. They are mechanisms for one GPU, not a pooling system: each decides how processes share a single card, and none of them schedules, sets quotas, or scales a cluster. TensorFusion works at that cluster level and uses some of these mechanisms underneath. If a fixed way of splitting each card is enough for you, the built-in mechanisms need nothing extra to install.

The three mechanisms

At a glance

How TensorFusion uses them

TensorFusion does not replace these mechanisms. Its isolation modes sit on top of them or beside them:

• shared mode sets no limits and relies on the GPU's own time-slicing, like the device plugin's time-slicing replicas. What it adds is scheduling by VRAM and compute requests instead of a fixed replica count.
• partitioned mode allocates MIG instances. TensorFusion picks the profile that fits the request and tracks which slots on each GPU are free.
• soft mode is TensorFusion's own limiter. Like MPS limits, it runs in user space and caps compute and memory per workload. Unlike MPS limits, the node hypervisor changes the caps at runtime, which enables burst, QoS levels, and autoscaling.
• hard mode moves GPU calls into a separate worker process and caps compute with a fixed share of the GPU.

One thing does not change: only MIG gives a hardware boundary. If you need that guarantee, use MIG, either directly or through partitioned mode.

Requesting a GPU

Time-slicing with the NVIDIA GPU Operator needs a ConfigMap that fixes the number of replicas, then a normal GPU request:

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: one of the four replicas, with no memory or compute limit
resources:
  limits:
    nvidia.com/gpu: 1

MIG needs the GPU partitioned in advance, then a request for one instance type:

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

TensorFusion needs no per-GPU plan. Each Pod states what it needs:

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"

To get a MIG instance through TensorFusion, add tensor-fusion.ai/isolation: partitioned. Create a workload explains every annotation.

When to choose which

Use the built-in mechanisms on their own when:

• You need hardware isolation between tenants and the fixed MIG profiles match your workloads.
• The cluster is small and the way each GPU is split rarely changes.
• You want the fewest moving parts: the NVIDIA driver and device plugin, and nothing else.
• Workloads trust each other and only need to take turns on a GPU. Time-slicing covers that.

Choose TensorFusion when:

• Workload sizes vary and do not fit a fixed list of profiles or one replica count per GPU.
• You want GPU compute and VRAM limits per Pod, with requests lower than limits so idle capacity is used.
• You need scheduling that knows how much of each GPU is free, plus quotas, QoS levels, or gang scheduling.
• You want GPU nodes scaled with demand, or Pods on CPU nodes that use GPUs remotely.
• You run MIG already and want the instances allocated on demand instead of planned by hand.

References

Checked in October 2026:

• NVIDIA MIG User Guide: instance limits, supported GPUs, isolation.
• NVIDIA Multi-Process Service: resource limits, memory protection, error containment.
• Time-slicing GPUs in Kubernetes: configuration and limitations.