#MIG Resources

Multi-Instance GPU (MIG) partitions a MIG-capable GPU, such as the NVIDIA A100, A30, or H100, into several isolated GPU instances. Each instance has dedicated compute and memory, so workloads that do not saturate a full GPU can run in parallel on one card.

MIG is an optional capability in this release. The MIG geometry manager (mig-manager) is off by default, its image is not included in the product package, and MIG has not been validated end-to-end on MIG-capable hardware for this release. Enabling MIG requires MIG-capable hardware and a user-supplied mig-manager image.

#Prerequisites

• A MIG-capable GPU (see NVIDIA Supported GPUs).
• The mig-manager image available in your cluster registry. It is not in the product package; mirror it from nvcr.io (see below).

#Provide the mig-manager image

The mig-manager component uses an NVIDIA image that this product does not redistribute. Mirror it from nvcr.io to your private registry, then point the ClusterPolicy at it:

docker pull  nvcr.io/nvidia/cloud-native/k8s-mig-manager:<version>
docker tag   nvcr.io/nvidia/cloud-native/k8s-mig-manager:<version> <private-registry>/nvidia/cloud-native/k8s-mig-manager:<version>
docker push  <private-registry>/nvidia/cloud-native/k8s-mig-manager:<version>

In the ClusterPolicy, enable the component and set its repository to the mirrored location:

migManager:
  enabled: true
  repository: <private-registry>/nvidia/cloud-native
  image: k8s-mig-manager
  version: <version>   # must match the mirrored tag exactly
mig:
  strategy: single

Keep the mirrored tag identical to the source. This image is provided by NVIDIA; mirroring and using it is subject to NVIDIA's terms.

#MIG strategies

The mig.strategy field in the ClusterPolicy controls how MIG devices are advertised to Kubernetes.

#none

Alauda GPU Management makes no distinction between GPUs with MIG enabled or not. All GPUs are enumerated as nvidia.com/gpu, the same as a non-MIG node. Use this when MIG is not in use.

#single

MIG devices are advertised as nvidia.com/gpu, keeping the workload experience unchanged, but the resource now maps to the MIG instances available on the node rather than to full GPUs. All MIG instances on the node must be of the same profile. A node with seven 1g.5gb instances reports seven nvidia.com/gpu.

#mixed

Each MIG profile is advertised as its own fully qualified resource, of the form nvidia.com/mig-<slice_count>g.<memory_size>gb (for example nvidia.com/mig-1g.5gb, nvidia.com/mig-2g.10gb). Use this when a node hosts MIG instances of different sizes.

#How this differs from setting MIG on the command line

Setting MIG geometry directly on the node with nvidia-smi mig is an imperative, one-time operation: you manually ensure the GPU is idle, create the instances, and reconfigure the device plugin, and the configuration is not reconciled if it drifts.

The mig-manager component is declarative: you set the target profile in the ClusterPolicy (or a node label), and the manager drains the node's GPU workloads, applies the geometry, and keeps it reconciled. GPU Feature Discovery then advertises the MIG instances according to the strategy. The manager wraps the same underlying partitioning tool but adds the node-drain and reconcile lifecycle.

#Request a MIG instance

Once MIG is configured, request the advertised resource as a limit, the same way as a whole GPU:

resources:
  limits:
    nvidia.com/gpu: 1          # single strategy
    # or, mixed strategy:
    # nvidia.com/mig-1g.5gb: 1

Confirm the advertised MIG resources from node allocatable resources before requesting them:

kubectl get node ${nodeName} -o jsonpath='{.status.allocatable}'