- Increase GPU utilization for compatible workloads.
- Give more teams access to limited GPU capacity.
- Support development, experimentation, and bursty workloads efficiently.
gpufleetContact →GPU TIME-SLICING
Share GPU capacity. Keep work moving.
gpufleet configures GPU time-slicing for Kubernetes teams that need several workloads to share available GPU capacity.
Talk to gpufleet →WHY IT MATTERS IN KUBERNETES
Share GPU access across workloads that do not need a full device.
Development, testing, and bursty inference jobs often do not need a GPU all the time. Time-slicing lets Kubernetes expose shared GPU access to more than one workload, helping teams avoid reserving an entire device for intermittent work.
- Set sharing policies that match workload priority and demand.
- Use resource limits and monitoring to prevent noisy-neighbor issues.
- Choose MIG when hardware-level isolation is required instead.
CHOOSING THE RIGHT MODEL
When does time-slicing beat MIG?
Time-slicing lets multiple Kubernetes workloads take turns using the same physical GPU. Each pod is scheduled with a GPU resource, but the workloads share the device's compute and memory rather than receiving hardware-isolated partitions. It works best when access matters more than performance guarantees.
SHARING COMPARISON
Time-slicing, MIG, or a full GPU?
The right choice depends on isolation requirements, available hardware, and whether workloads need guaranteed capacity.
| Decision factor | |||
|---|---|---|---|
| Isolation | Memory and compute are not hardware-isolated | Hardware-isolated memory and compute slices | The entire device belongs to one workload |
| Hardware support | Broad supportNVIDIA GPUs supported by the device plugin | MIG hardware onlyA100, H100, H200, and other MIG-capable models | Broad supportAny Kubernetes-supported NVIDIA GPU |
| Setup complexity | Configure replicas and scheduling policy | Profile planning and GPU reconfiguration; reboot may be required | Standard device-plugin allocation |
| Best-fit workload | Dev and testCI, notebooks, experiments, and bursty jobs | Production sharingPredictable inference and isolated multi-tenant services | Dedicated performanceTraining, large models, and latency-sensitive workloads |
UTILIZATION EXAMPLE
Stop reserving four GPUs for four mostly idle pods.
4 dev/test pods
Each pod reserves an entire GPU while using less than 20% of its assigned device, leaving most capacity stranded.
4 shared replicas
Four cooperative dev/test pods share access to one physical GPU, freeing three GPUs for other work.
Illustrative allocation scenario. Time-slicing does not reserve a fixed compute or memory fraction for each replica, so results depend on workload concurrency and behavior.
DEVICE PLUGIN CONFIGURATION
Expose shared GPU replicas to Kubernetes.
We configure the NVIDIA Kubernetes device plugin, apply the policy to selected nodes, verify advertised capacity, and monitor shared workloads for contention.
Sanitized device-plugin ConfigMapREDACTED
apiVersion: v1
kind: ConfigMap
metadata:
name: nvidia-device-plugin-config
namespace: gpu-operator
data:
config.yaml: |
version: v1
flags:
migStrategy: none
sharing:
timeSlicing:
renameByDefault: false
failRequestsGreaterThanOne: true
resources:
- name: nvidia.com/gpu
replicas: 4
# Node selector / cluster identifiers redactedCONTACT
Build a GPU platform that works for your workloads.
We help you select, configure, and operate the Kubernetes GPU capabilities your team needs.
Talk to gpufleet →