MIGとは？1枚のGPUを分割してLLM推論を動かす前に知ること

小さなembedding modelや分類modelへGPUを1枚ずつ割り当てると、memoryとcomputeの多くが余ることがある。反対に、一つのGPUへ複数processを載せるだけでは、memory不足や性能干渉の影響範囲が読みにくい。

NVIDIA Multi-Instance GPU、MIGは、対応GPUを複数のGPU Instanceへ分割する仕組みである。各instanceへcomputeとmemory系統の一部を割り当て、CUDA applicationから小さなGPUのように利用できる。

ただし、MIGは「GPU台数を増やす設定」ではない。LLMが必要とするweight、KV Cache、workspaceを収め、requestごとのlatencyを守れるprofileを選び、再構成時の停止まで運用へ含める必要がある。

MIGが分けるもの

MIG対応GPUでは、Streaming Multiprocessorなどのcompute resourceと、L2 cache bank、memory controller、DRAM busなどのmemory pathをinstanceへ割り当てる。NVIDIAのMIG User Guideは、各instanceがmemory systemへの分離されたpathを持ち、異なるclient間のQoSとfault isolationを提供すると説明している。

CUDA applicationからは各MIG deviceが独立したdeviceとして見える。containerやprocessへinstance単位で割り当てられるため、次のような用途に向く。

小型modelをtenantごとに分離する
embedding、reranker、分類などのserviceを分ける
開発・検証環境へ上限の明確なGPU resourceを渡す
低trafficの複数endpointを一枚へ集約する

対応GPU、driver、profile名、instance上限は製品世代で異なる。A100の古い例を、別世代のGPUへそのまま当てはめない。

profile名は容量だけを表さない

MIG profileは、割り当てるcompute slice、memory容量、利用できるengineなどの組み合わせを表す。たとえば同じmemory容量に見えても、GPU世代やprofileによってcompute量とmedia engineの有無が異なる場合がある。

LLM推論では、profileをmemory容量だけで選ばない。次を実modelで測る。

weight、KV Cache、CUDA graph、workspaceが収まるか
最大contextと同時request数でOOMにならないか
PrefillのTTFTとDecodeのITLを守れるか
memory bandwidthが律速にならないか
tokenizerやCPU処理を含むend-to-end throughput

modelが起動したことはcapacity確認にならない。最長promptと最大batchで必要なheadroomを残す。

MIG instance数とLLM replica数は同じではない

一枚を七つに分けられるGPUがあっても、七つのLLM replicaが効率的とは限らない。instanceを小さくするほど一つのrequestが使えるcomputeとmemory bandwidthは減る。

trafficが少ない小型modelでは、複数の小さなinstanceがidle時間を減らせる。一方、長文Prefillや大きなbatchでは、分割しないGPUの方がrequestをまとめて高速に処理できる場合がある。

比較するときはGPU当たりの総throughputだけでなく、TTFT、ITL、p99、OOM率、消費電力、待ちqueueを見る。小さなinstanceを増やして総throughputが上がっても、各requestのdeadlineを超えれば目的を達成していない。

MIGとtime-slicingは違う

KubernetesのGPU time-slicingは、一つのGPUを複数workloadへ時間分割して共有させる。NVIDIAの公式資料では、time-slicingにはMIGが提供するmemory isolationとfault isolationがない。

観点	MIG	time-slicing
compute	profileごとにpartition	同じGPUを時間共有
GPU memory	instanceごとに分離	process間で共有
fault isolation	hardware levelの分離を提供	MIG相当の分離なし
resource形状	定義済みprofile	replica数としてoversubscribe
対応hardware	MIG対応GPU	より広いGPUで利用可能

time-sliced resourceを二つ要求しても、compute powerが二倍保証されるわけではない。NVIDIAの資料は、一つのPodが複数のtime-sliced GPU resourceを要求しても比例したcompute量は保証されないと説明している。

tenant分離やmemory上限を重視するならMIG、軽い開発jobをより多く載せるためbest-effort共有を許容するならtime-slicingが候補になる。両者を名前だけで同じGPU共有機能として扱わない。

MPSとも役割が違う

CUDA Multi-Process Serviceは、複数CUDA processのkernel実行を一つのGPU上で効率化する仕組みである。MIGのようにmemory pathをhardware partitionへ分けるものではない。

MIG instanceの内側で複数processを動かす構成もありうるが、分離境界とscheduling境界が二重になる。まずMIG profile単位のcapacityを測り、その上でprocess共有が必要か判断する。

大きなLLMでは分割が不利になる

model weightだけで一つのMIG instanceに収まらない場合、MIGは単純な解決にならない。複数instanceを物理GPUのように束ねればよいとも限らず、P2Pやcollectiveの対応・制約はGPU世代、driver、構成で確認が必要である。

Tensor Parallelismを使う大きなmodelでは、分割前のGPUやNVLink domainを占有した方が自然な場合が多い。MIGは主に、一枚では大きすぎるGPUを小型workloadへ適切に配分する選択肢として考える。

一方、embedding model、reranker、guardrail、音声・画像の前処理など、LLM周辺の小型serviceには適合しやすい。大model本体と周辺serviceを同じfailure domainへ詰め込みすぎない点には注意する。

Kubernetesではresource名とstrategyを理解する

NVIDIA GPU OperatorはMIG Managerを使い、node labelの変更に応じてMIG modeとgeometryを構成する。MIG strategyにはsingleとmixedがある。

single: node上のGPUを同じMIG方針で扱いやすい
mixed: 複数profileやMIG有効・無効の混在を扱う

実際にPodが要求するresource名はstrategyとprofileによって変わる。schedulerが「GPU 1個」としか理解していない構成では、full GPUと小さなMIG instanceを取り違える危険がある。

node label、advertiseされたextended resource、profile名をinventoryへ残す。autoscalerもinstance数だけでなく、各profileで起動可能なmodelと同時request数を理解する必要がある。

MIG geometryの変更は無停止ではない

GPU OperatorのMIG Managerはgeometry変更時にGPUを使うoperator Podを停止し、構成を適用して再起動する。環境によってはMIG modeの変更にnode rebootが必要になる。

そのため、trafficが流れているnodeのlabelを気軽に変更しない。基本手順は次の通りである。

対象nodeへの新規配置を止める
serving requestを別replicaへ逃がす
GPU workloadをdrainする
希望するgeometryへ変更する
device plugin、監視、resource advertiseを確認する
canary modelを起動してmemoryとlatencyを測る
少量trafficから復帰する

profile変更を日中のautoscaling手段として使うより、需要のまとまりに合わせたnode poolを事前に用意する方が扱いやすい場合が多い。

fragmentationはGPU memory以外にもある

MIGでは定義済みprofileをGPU上へ配置する。空きmemory量の合計が足りているように見えても、希望profileを追加できない場合がある。profileの組み合わせとplacement制約があるためである。

scheduler側でも、使いにくい小さなinstanceだけが残るresource fragmentationが起きる。たとえば大profile待ちのjobがあるのに、小profileへ分割したnodeしか残っていれば起動できない。

利用率だけでなく、profile別のpending Pod、空きinstanceの形、再構成回数を監視する。需要分布に合わないgeometryは、空きcapacityがあるのにqueueが増える状態を作る。

healthとfailure domainを追跡する

MIG instanceは分離を提供するが、同じphysical GPU、board、power、PCIe pathを共有する。physical GPUの重大障害は複数instanceへ影響しうる。

監視ではMIG device UUIDだけでなく、親GPU UUID、node、PCI bus IDを関連付ける。instance単位のOOMと、親GPUのXid・ECC・温度異常を区別する。

DCGMや監視stackがMIG modeでどの単位のmetricを出すかも確認する。time-slicingではcontainerへのmetric関連付けに制約があるため、MIGと同じdashboard前提にしない。

監視するmetric

profile別の割当数、空き数、pending Pod数
親GPUとMIG deviceのUUID mapping
instance別のmemory使用量、SM利用率、throughput
model別のTTFT、ITL、error率、OOM率
profile別の最大context、同時request数
親GPUのECC、Xid、temperature、power、clock
geometry変更の回数、所要時間、失敗率
node cordonからservice復帰までの時間
full GPU、MIG、time-slicingの費用とSLO比較

負荷試験

最長promptと最大batchでmemory headroomを確認する
instanceごとに同じmodelを動かし性能差を見る
隣接instanceへ高負荷をかけ、latency干渉を測る
一つのinstanceでOOMを起こし、他instanceへの影響を確認する
親GPU障害を想定し、全instanceの退避を確認する
geometry変更前のdrainと変更後のresource再認識を確認する
canary失敗時にnodeがtrafficへ戻らないことを確認する
同じworkloadをfull GPU、MIG、time-slicingで比較する
mixed strategyで正しいresource名を要求できるか確認する
profile別のqueueを使い、capacity不足時の拒否・待機を確認する

小さく分ける前にworkloadの形を測る

MIGは、対応GPUのcomputeとmemory系統を定義済みprofileへ分け、複数workloadへ分離されたresourceを渡す仕組みである。単なるtime-slicingよりmemoryとfaultの分離が強い一方、自由な容量分割ではなく、geometry変更にはdrainや再起動が伴う場合がある。

LLM推論では、weightが収まるだけでprofileを選ばない。KV Cache、最大context、batch、TTFT、ITLを含めて測り、親GPUのfailure domainも残す。MIGが効くのは、GPUを小さくできるからではなく、workloadの形に合った分離単位を作れる場合である。