GPU sharing isolation decision：MIG vs time-slicing

GPU共有方式は「利用率を上げる」という単一目的で選ばず、必要なmemory/fault isolation、性能予測性、GPU機種、workload size、再構成停止許容度を入力にしてMIGとtime-slicingを使い分ける。NVIDIAのMIG User Guideは、MIGが対応GPUを複数のGPU Instanceへ分割し、各instanceへ独立したcompute/memory resourceを割り当て、memory systemの経路・L2 cache・memory controller・DRAM bus等を分離することでpredictable throughput/latencyとfault isolationを提供すると説明している。

一方、NVIDIA GPU Operator/OpenShiftのtime-slicing文書は、CUDA time-slicingで同一GPUを複数replicaとして共有できるが、MIGと異なりreplica間にmemory isolationもfault isolationもないと明記している。したがって、Kubernetes上でnvidia.com/gpu replica数が増えたことを、独立した物理GPUやMIG sliceが増えたことと解釈してはならない。

2026年10月時点のGPU Operator 26.3系では、MIG ManagerがMIG-capable GPUのprofileをNVMLから発見してnodeごとのconfigurationを生成できる。MIG geometry変更時にはGPU上でuser workloadが動作していないことが必要で、環境によってはnode rebootも必要になる。MIGは強い分離と予測性を得られる一方、運用上はprofile/geometry管理と再構成コストを持つ。

time-slicingは、短いjobやGPUを常時飽和させない同一trust-domain workloadの収容密度を上げる手段として有効である。しかしmemory/fault isolationを提供しないため、強いtenant isolationや性能SLOを必要とするworkloadに「共有GPUだが実質専有」と説明すると設計上の誤りになる。

MIGはGPUをhardware-level resource partitionへ分けるため、他instanceのmemory trafficやcompute contentionの影響を抑え、QoSとfault isolationを取りやすい。ただし利用できるGPU、profile、driver/operator versionには制約があり、profileの固定分割によってworkload sizeとslice geometryが合わない場合はfragmentationが生じる。MIGを有効化しただけでcluster全体の利用率が上がるとは限らない。

また「MIG vs time-slicing」は常に排他的二択ではない。vGPU等の別レイヤーではMIG-backed time-sliced構成も存在するため、比較時にはKubernetes device-plugin time-slicing、MIG bare-metal/container、vGPUを混同しない。

• GPU poolごとに sharing_mode=exclusive|mig|time_slicing、GPU model、driver、GPU Operator/device-plugin version、MIG capability、MIG profile、replica countをinventory化する。
• workload classに isolation_required, memory_guarantee, latency_slo, throughput_slo, gpu_memory_request, trusted_co_tenant, preemption_tolerance を持たせ、scheduler policyへ入力する。
• tenant境界またはfault containmentが必要なら、Kubernetes time-slicingだけを分離controlとして扱わない。MIGまたは別のVM/vGPU/physical isolationを評価する。
• time-slicing poolでは、replica数をcapacity multiplierとして表示する場合でも「物理memory容量がreplica数倍になった」とcapacity accountingしない。OOM、latency tail、context-switch/contentionをload testする。
• MIG poolでは、profileごとのSM/memory capacityと実workload分布を照合し、未使用sliceと「大きなjobが入らない」fragmentationを別指標で監視する。
• MIG geometry変更は通常request pathから分離し、node drain/cordon、GPU client停止、必要時reboot、configuration state readbackを含むmaintenance operationとして扱う。
• rollout前に同一workload mixでexclusive / MIG / time-slicingを比較し、GPU utilizationだけでなくp50/p95/p99 latency、throughput、OOM/fault propagation、queue wait、reconfiguration downtimeを記録する。

MIGの分離保証は対応GPUと対応構成に依存する。NVIDIAはAmpere以降の対応GPUを対象としており、すべてのGPUが同じprofileや機能を持つわけではない。GPU Operatorの具体的profile生成やMIG Manager挙動もversion/driverで変わるため、clusterのlive versionとhardwareを確認する。

time-slicingの性質も実装面で区別する。GPU Operator/device-pluginによるKubernetes time-slicingとNVIDIA vGPUのtime-sliced schedulerは同じ「時間共有」の概念を持つが、管理境界・virtualization・isolation contractは同一ではない。本記事のcontrolは共有方式の選択原則であり、vGPU licensingやhypervisor-specific保証まで一括して断定しない。

MIGは強い分離を提供するが、固定partitionが小規模・変動workloadに対して常に効率的とは限らない。time-slicingは分離が弱い一方、MIG非対応GPUでも利用でき、細粒度jobの収容率を上げられる場合がある。したがって「MIGが常に上位互換」という結論は不適切である。

MIGでは通信機能にも制約があり、NVIDIA CUDA-X Deployment documentationはMIG利用時のCUDA IPCやNVLink/NVSwitchに関する制約を示している。distributed/HPC workloadでは、単一GPU内の分離だけでなくinter-GPU communication requirementを先に確認する必要がある。

性能はmodel、batch size、kernel shape、memory bandwidth、concurrency、driver/runtimeに依存するため、一般的なMIG/time-slicing比較値を自環境のSLOへそのまま移植しない。

• 現行clusterで利用しているGPU SKUごとのMIG profileとdriver/operator compatibility。
• workload mix別のMIG fragmentationとtime-slicing contentionの実測break-even。
• GPU fault種別ごとのMIG instance境界でのcontainment範囲。
• distributed inference/trainingでMIG通信制約がend-to-end throughputへ与える影響。
• MIG-backed vGPU等を含めたvirtualization layerとの最終isolation contract。

「MIGは対応GPUをhardware-levelのGPU instanceへ分割し、compute/memory resourceの分離と予測性を得る方式である。KubernetesのCUDA time-slicingは同一GPUを時間共有して収容密度を上げるが、replica間のmemory/fault isolationを提供しない。選択は利用率だけでなく、tenant/fault isolation、性能SLO、workload size、対応GPU、MIG再構成コストを含めて決め、実workloadで検証する。」

• NVIDIA Multi-Instance GPU User Guide, Introduction / latest, accessed 2026-10-20.
• NVIDIA GPU Operator 26.3, “GPU Operator with MIG”, including MIG Manager/profile generation and reconfiguration prerequisites, accessed 2026-10-20.
• NVIDIA GPU Operator on Red Hat OpenShift, “Time-slicing NVIDIA GPUs in OpenShift”, accessed 2026-10-20.
• NVIDIA CUDA-X Deployment Documentation, “Multi-Instance GPU (MIG)”, communication/isolation limitations, accessed 2026-10-20.
• NVIDIA Virtual GPU Software Documentation 19.0, MIG-backed and time-sliced vGPU architecture, accessed 2026-10-20.