GPU仮想化と共有技術(vGPU・MIG・MPS・タイムスライシング)

1. 概要

GPU仮想化(GPU Virtualization)とは、一枚の物理GPUを複数の仮想マシン・コンテナ・プロセスが安全に分割して使えるように、あるいは逆に複数のGPUを一つの論理資源のように束ねて使えるように抽象化する技術の総称である。狭義には「一つのGPUを複数ユーザが共有(sharing)する分割」技術を指し、時間分割(temporal)・空間分割(spatial)・ハードウェア分割(hardware partition)の三つの軸で実装される。

GPU仮想化が台頭した背景は、アクセラレータ需要と資源効率の間の構造的な乖離にある。生成AI・ディープラーニング学習・推論・HPCの需要が急増するにつれ、データセンターのGPUは最も高価で最も供給がひっ迫した資源となった。NVIDIA H100一枚の導入価格は数千万ウォン台であり、電力・冷却コストまで加えれば稼働率1%がただちにコストに換算される。ところが実際の現場で単一ワークロードがGPUを100%埋めることはまれである。対話型推論サービス、ノートブックベースのデータ分析、CIパイプラインの小規模テストといったワークロードは、GPUの演算ユニット(SM)とメモリの10〜30%しか使わず残りを遊ばせることがよくある。この「高価な資源の低い稼働率」を埋めることが、GPU共有技術の一次的な存在理由である。

二つ目の背景は、マルチテナンシ(multi-tenancy)と隔離の要求である。パブリッククラウドや社内共用クラスタでは、異なるチーム・顧客が同じGPUを分け合いつつ、あるテナントの作業が他テナントのメモリをのぞいたり性能を侵食したりしてはならない。すなわち「分けて使うが互いに干渉しない」隔離が前提となる。GPU仮想化技術は、まさにこの稼働率(utilization)と隔離(isolation)という相反する二つの目標を、どの地点で妥協するかによって分かれる。隔離をほぼ放棄して稼働率だけを狙う時間分割から、MIGのようにハードウェア水準で完全に隔離しつつ分割粒度が固定される方式までが一つのスペクトラムを成す。

三つ目の背景は、CPU仮想化との非対称である。CPUは数十年にわたり仮想化が成熟し、ハイパーバイザがコア・メモリを自由に分割・オーバーコミット(overcommit)できるが、GPUは数千個のコア(SM)・専用メモリ・固有のスケジューラを持つ特殊な装置であり、汎用ハイパーバイザがそのまま扱うことはできない。そこでGPUベンダがドライバ・ファームウェア・ハードウェア層で専用の仮想化手段を提供するようになり、その成果物が以下で扱うタイムスライシング・MPS・MIG・vGPUである。

この乖離がどれほどコストに換算されるかは、簡単な算術でも明らかになる。たとえば導入・運用を合わせて年間4千万ウォンかかるGPUノードが平均稼働率20%にとどまるなら、実質的に年3千2百万ウォン相当の演算が宙に捨てられることになる。同じノードを共有技術で四つの作業に分けて平均稼働率を70%まで引き上げれば、追加ハードウェア投資なしに利用可能な演算が3.5倍に増える。数百〜数千枚規模のAIクラスタでは、この稼働率の差が数十億ウォン台の資本・運用費の差につながるため、GPU共有は単なる技術選択ではなく財務的な意思決定の性格を帯びる。

2. 共有方式の分類と全体構造

GPU共有技術を理解する最良の枠組みは「何を基準に分けるか」である。GPUの資源は大きく演算資源(SM, Streaming Multiprocessor)とメモリ資源(VRAM・メモリ帯域・L2キャッシュ)に分かれ、共有技術はこの二つを時間で交互に使わせるか、空間で割って同時に使わせるかによって分類される。下図は四つの代表技術を時間・空間・ハードウェア分割の軸上に配置した全体構造図である。

flowchart TB
  ROOT["GPU共有技術"]
  ROOT --> T["時間分割(Temporal)"]
  ROOT --> S["空間分割(Spatial)"]
  ROOT --> H["ハードウェア分割(Hardware)"]
  T --> TS["タイムスライシング(Time-Slicing)<br/>文脈交換で交互に実行"]
  T --> VG["vGPU(既定モード)<br/>ハイパーバイザが時間分割"]
  S --> MPS["MPS(Multi-Process Service)<br/>複数プロセスのカーネルを同時実行"]
  H --> MIG["MIG(Multi-Instance GPU)<br/>SM・メモリ・キャッシュを物理分割"]
  H --> VGM["MIG-backed vGPU<br/>ハードウェア隔離 + VM割当"]
  TS -.->|隔離弱い・稼働率高い| G1["オーバーコミット志向"]
  MIG -.->|隔離強い・粒度固定| G2["マルチテナンシ志向"]

時間分割(temporal sharing)は、一つのGPUを複数の作業が短い時間単位で交互に占有する方式である。CPUのラウンドロビンスケジューリングと原理が同じで、ある瞬間には一つの作業だけがGPUを使うが、人の目には同時に回っているように見える。切り替えのたびに文脈交換(context switch)のコストがかかり、一つの作業がGPUを握っている間ほかの作業は待機するため遅延(latency)が増える。またメモリは物理的に分けられないため、一つの作業がVRAMを過度に占有すると別の作業がOOM(Out of Memory)で失敗しうる。隔離が弱い代わりに実装が簡単でオーバーコミットが自由であり、稼働率を最優先する開発・テスト環境に適する。

空間分割(spatial sharing)は、GPUの演算ユニットを同じ時点で複数の作業が分けて使う方式である。数千個のSMが絶えず遊ぶのを防ぐため、一つの作業が一部のSMだけを使うとき残るSMを別の作業のカーネル(kernel)が埋めるようにする。代表的な実装であるMPSがここに属する。時間分割より処理量(throughput)が高いが、依然としてメモリ空間と誤りが完全に分離されるわけではない。

ハードウェア分割(hardware partition)は、GPU内部を物理的に割って、各かけらが専用SM・専用メモリ・専用メモリコントローラ・専用L2キャッシュスライスを持つようにする方式である。MIGが代表的で、分割されたインスタンスは事実上小さな独立GPUのように動作し、性能干渉(noisy neighbor)とメモリ侵犯が根本から遮断される。隔離が最も強力だが、分割境界がハードウェアで固定されるため柔軟性は落ちる。

3. 主要技術の原理とアーキテクチャ

四技術は「稼働率と隔離をどこで妥協するか」という一つの問いに、互いに異なる答えを出す。以下では隔離が弱い順から強い順へ原理を見ていく。各技術は、提供する隔離の種類(メモリ隔離・性能隔離・誤り隔離)を基準に比較するとき違いが明確になる。

A. タイムスライシング(Time-Slicing)

タイムスライシングは、GPUの内蔵スケジューラが複数のCUDA文脈(context)を時間単位で交互に実行させる、最も基本的な共有である。一つの作業のカーネル実行が終わるか、タイムスライスが満了すると、GPUはレジスタ・プログラムカウンタなどの実行状態を保存し、次の作業の状態を復元したうえで実行を続ける。この切り替えは数マイクロ秒〜数十マイクロ秒水準だが、切り替えが頻繁だと累積オーバーヘッドが大きくなる。

タイムスライシングの決定的な限界は、隔離がほとんどない点である。メモリが物理的に分離されないため二つの作業が同じVRAMプールを共有し、一つの作業のメモリ漏れや過占有が別の作業の失敗へ波及する。また一つの作業が長いカーネルを回すと、別の作業の遅延が予測不能に増える性能干渉が発生する。Kubernetesでタイムスライシングを設定すると、一つの物理GPUをたとえば4個の「複製(replica)」として広告(advertise)し4個のポッドに割り当てられるが、これはメモリが4等分されるという意味ではなく、単にスケジューリングスロットが4個だという意味である。したがってメモリ総量を超えて割り当てればそのままOOMになる。

それでもタイムスライシングが広く使われる理由は、ハードウェア制約がまったくなく(すべてのGPUで可能)設定が単純だからである。数十人が使う社内Jupyterノートブッククラスタ、GPUを断続的にしか使わないCIランナーのように「隔離より可用性とコスト」が重要な環境では、一枚のGPUを8〜16個の作業にオーバーサブスクライブ(oversubscribe)して遊休時間を埋めるほうがむしろ合理的である。

ただしオーバーサブスクライブ倍数を決めるときは、作業の同時活性比率を根拠にすべきである。16人がノートブックを開いていても、実際にセルを実行するのは平均2〜3人だけなら8倍のオーバーサブスクライブは安全だが、全員が同時に大型学習を回す瞬間には文脈交換が急増しVRAMが即座に枯渇する。したがってタイムスライシングは「ピーク同時性が低く再試行が容易な」ワークロードに限定して適用し、メモリ上限を併せて掛けることが失敗を減らす運用原則である。

B. MPS(Multi-Process Service)

MPSは、複数のプロセスがそれぞれ送ったCUDAカーネルを一つのGPU文脈の中で同時に(空間的に)実行させる共有方式である。タイムスライシングが「交互に」実行するなら、MPSは「一緒に」実行する。もともとCUDAは異なるプロセスのカーネルを同時に回せず直列化していたが、MPSはプロセスらのカーネルを一つのサーバ文脈へ合わせてSMレベルで同時実行することにより、単一プロセスではGPUを埋めきれない小さなワークロードを重ねて稼働率を引き上げる。

MPSがなぜ処理量を上げるかは、SM占有の算術で説明される。ある推論カーネルがGPUのSMを30%しか使わないなら、単独実行時に残り70%の演算ユニットはその時間の間なにもしない。同じカーネルを三つのプロセスがMPSで同時に載せると、三つのカーネルが互いに異なるSMを埋めて占有は理論上90%まで上がり、結果として同じハードウェアでほぼ三倍の要求を処理する。タイムスライシングであれば三つの作業が交互に回り各区間ごとに70%を空けたはずであり、「交互に」ではなく「一緒に」が与える違いが、まさにこの遊休SMの回収にある。

MPSの利点は、文脈交換コストがなく、小さなカーネルが残るSMを埋めて処理量が上がる点である。またVolta世代以降には、各クライアントに演算資源の比率(例:GPUの50%)を上限として指定する機能と一定水準のメモリ保護が追加された。しかし根本的にMPSは誤り隔離が弱い。一つのGPU文脈を共有するため、一つのプロセスが致命的な誤り(例:メモリアクセス違反)を起こすと、同じMPSサーバに束ねられた別のプロセスまで影響を受けうる。メモリ保護も完全なハードウェア隔離ではなくソフトウェア的な境界に近い。したがってMPSは、互いに信頼できる(同じチーム・同じ作業)多重プロセス推論サービスのように、隔離より処理量が重要な単一テナント環境で効果が大きい。たとえば遅延に敏感な小型推論モデルを複数一つのGPUに載せるとき、MPSで同時実行すれば各要求の尾部遅延(tail latency)を下げつつ全体の処理量を高められる。

C. MIG(Multi-Instance GPU)

MIGは、NVIDIA Ampere(A100・A30)世代で導入され、Hopper(H100・H200)とBlackwell(B200)世代へ受け継がれたハードウェア水準のGPU分割技術である。一枚のGPUを最大7個の独立インスタンス(GPU Instance)へ割り、各インスタンスは専用SM集合・専用VRAM・専用メモリ帯域・専用L2キャッシュスライス・専用メモリコントローラを持つ。すなわち分割線がソフトウェアスケジューラではなくシリコンに引かれるため、一つのインスタンスの作業は別インスタンスのメモリや性能に物理的に接近できない。これがMIGの提供する完全なメモリ・性能・誤り隔離の根拠である。

flowchart LR
  subgraph GPU["物理GPU (例: H100 80GB)"]
    direction TB
    subgraph I1["GI 3g.40gb"]
      SM1["SMスライス x3"]
      M1["VRAM 40GB"]
    end
    subgraph I2["GI 2g.20gb"]
      SM2["SMスライス x2"]
      M2["VRAM 20GB"]
    end
    subgraph I3["GI 1g.10gb"]
      SM3["SMスライス x1"]
      M3["VRAM 10GB"]
    end
    L2["L2キャッシュ・メモリコントローラもスライス単位で分割"]
  end
  I1 --> T1["テナントA (学習)"]
  I2 --> T2["テナントB (推論)"]
  I3 --> T3["テナントC (ノートブック)"]

MIGの分割単位は、プロファイル(profile)という固定された組み合わせとして提供される。H100 80GBを例に取ると、1g.10gb(最も小さいかけら、最大7個)から2g.20gb、3g.40gb、7g.80gb(GPU全体)まで定められた大きさだけを選べ、かけらの大きさは「コンピュートスライス数(g)」と「メモリ容量(gb)」の組み合わせで表記される。プロファイル名と可能な組み合わせはSKUごとに異なり、たとえばH100 94GB製品は1g.12gb・7g.94gbのようにメモリ表記が変わる。このように粒度がハードウェアで固定されているため「メモリ7.5GBのインスタンス」のような任意の大きさは作れず、分割構成を変えるには当該GPUの作業をすべて空けて再構成しなければならない制約がある。

MIGはマルチテナンシクラウドの中核手段である。たとえばH100一枚を1g.10gb7個に割れば、小規模な推論・実験ワークロード7個を互いに完全に隔離したまま載せられ、一つのテナントの暴走が別のテナントに影響しない。クラウド事業者が「GPUの1/7」を商品として販売したり、社内でチーム別にGPUのかけらを割り当てる課金・クォータ体系を立てられたりするのも、このハードウェア隔離のおかげである。

MIGのもう一つの強みは、性能の予測可能性(predictability)である。分割されたインスタンスは専用のメモリ帯域とキャッシュを持つため、隣のインスタンスが何をしようと自分の取り分の性能が一定に保証される。これはSLAを約束しなければならない推論サービスで特に重要で、タイムスライシング・MPSでは隣の作業の負荷により遅延が揺れるが、MIGでは尾部遅延の分散が小さく課金・SLA設計が単純になる。逆に分割粒度が固定のため「かけら一つが余るのにそれより大きい作業が待機する」断片化(fragmentation)が生じうるため、プロファイル構成をワークロード分布に合わせて事前に設計する容量計画が必要である。

D. vGPU(仮想GPU)

vGPUは、ハイパーバイザ層で物理GPUを複数の仮想マシン(VM)に分け与える技術で、VMベースの仮想化環境(VMware vSphere、KVM、Citrixなど)やVDI(仮想デスクトップ)・クラウドIaaSで主に使われる。各VMにはvGPUドライバが入り、物理GPUにはハイパーバイザと協力するマネージャが載ってVMらのGPU要求を仲裁する。既定のvGPUは時間分割でVMらにGPUを交互に配分するが、各VMに割り当てられるフレームバッファ(VRAM)の大きさをプロファイルで固定してメモリ面の分離は保証する。vGPUはライセンスが必要な商用ソフトウェアスタックである点が、先の三技術と区別される。

注目すべきは、vGPUとMIGを結合したMIG-backed vGPUである。この構成ではMIGでハードウェア分割したインスタンスを各VMにvGPUとして割り当てるため、時間分割vGPUが与えられない演算性能のハードウェア隔離までVM単位で得る。すなわち「VM仮想化の運用の便 + MIGの強い隔離」を同時に取る方式であり、金融・公共のようにテナント間隔離要件が厳格な仮想化クラウドで好まれる。

4. 技術の比較と選択基準

四技術の違いは結局、どの隔離をハードウェアで保証するか、その代わり柔軟性・汎用性をどれだけ放棄するかに帰着する。下表は比較の補助であり、「なぜそのような違いが生じるか」は前節の原理で理解すべきである。

区分	タイムスライシング	MPS	MIG	vGPU(既定)
分割軸	時間	空間	ハードウェア	時間(+MIG結合可)
メモリ隔離	なし	弱い(SW)	強い(HW)	あり(プロファイル)
性能隔離	なし	部分	強い(HW)	弱い
誤り隔離	なし	弱い	強い	VM単位
分割粒度	自由(スロット数)	自由	固定(プロファイル)	固定(プロファイル)
ハードウェア要件	すべてのGPU	大半のGPU	A100〜B200など	対応GPU+ライセンス
代表用途	開発・テストのオーバーコミット	単一テナント推論	マルチテナンシ課金	VDI・VMクラウド

よくある誤解は「共有すれば必ず全体の処理量が上がる」という期待である。実際にはワークロードがすでにGPUを十分に飽和させているなら、共有は切り替え・競合のオーバーヘッドだけを追加しかえって遅くなる。共有が得を生む前提は、各作業がGPUを埋めきれずSM・メモリに余裕を残す点であり、この余裕がなければ分割ではなく専用割当が正解である。したがって共有導入前には、代表ワークロードの実際のSM占有率とVRAM使用量をプロファイリングし、共有の余地があるかをまず確認すべきである。

この表から読むべき核心は、縦に「隔離が強くなるほど粒度・汎用性が落ちる」という相反である。タイムスライシングはどのGPUでも自由に割るが隔離が皆無で、MIGは隔離が完璧だがプロファイルという固定の枠と特定世代ハードウェアを要求する。したがって選択は「自分のワークロードが信頼境界を共有するか、しないか」から出発する。同じチームの信頼できる作業ならタイムスライシング・MPSで稼働率を極大化するほうがよく、異なる顧客・チームが混ざるマルチテナンシならMIG(またはMIG-backed vGPU)でハードウェア隔離を確保すべきである。

実務ではこれらを階層的に組み合わせることもある。たとえばH100をMIGで3g.40gb2個 + 1g.10gb1個に割ったのち、そのうち推論用のMIGインスタンスの上に再びMPSを載せて小型モデルを複数、空間分割で回す具合である。こうすると外の境界はハードウェアで強く隔離しつつ、信頼可能な内部ワークロードどうしでは稼働率を再び引き上げる「隔離と効率の二段構成」が可能になる。実際にある推論プラットフォームで、単一GPU占有方式に比べてMIG+MPSの組み合わせでGPU稼働率を数倍引き上げたという報告があるほど、組み合わせ設計はコスト削減の核心的な梃子である。

5. 深化:Kubernetes統合とDRAへの転換

GPU共有が実際に運用される現場は大半がKubernetesである。伝統的にKubernetesはデバイスプラグイン(Device Plugin)モデルでGPUを扱ってきた。ノードのNVIDIAデバイスプラグインがnvidia.com/gpuのような拡張資源を広告すると、スケジューラがポッドの資源要求に従いGPUを丸ごと配分する方式である。ここにタイムスライシング設定を加えれば一つのGPUを複数の複製スロットとして広告でき、MIGはsingle(すべてのインスタンスが同一プロファイル)・mixed(異なるプロファイルを混合)戦略で露出できる。しかしデバイスプラグインモデルはGPUを「丸ごと単位」で扱うよう設計され、共有・ワークロード別の詳細設定・トポロジ要求・能力制約をネイティブに表現できない限界が顕著だった。

この限界を越えるために登場したのがDRA(Dynamic Resource Allocation, 動的資源割当)である。DRAは、ワークロードがResourceClaimで「どの能力の資源がどれだけ必要か」を宣言すると、ドライバがその要求に合わせてGPUを動的に割当・構成するモデルで、デバイスプラグインの後続アーキテクチャとして位置づけられている。関連API(resource.k8s.io/v1)はKubernetes 1.34で正式(GA)となり、NVIDIAのDRAドライバはこの枠の上でタイムスライシング・MPSのような共有方式を宣言的に構成できるようにする(一部機能はまだアルファ段階の機能ゲートで提供)。ただし一つのクラスタでDRAスタックと既存のデバイスプラグインスタックを同時には使えないため、運用者は二つのうち一つを選ばねばならない。

最新動向のもう一つの軸は、仮想メモリのオーバーサブスクリプションとKVキャッシュ共有である。大規模言語モデルの推論ではモデル重みとKVキャッシュがVRAMを侵食するため、統合メモリ(Unified Memory)・CUDA仮想メモリ管理(VMM)APIを活用してGPUメモリをオーバーコミットしたり、複数の推論要求がKVキャッシュのページを共有したりするソフトウェア層(例:ページ単位のアテンションキャッシュ管理)が急速に発展している。すなわちハードウェア分割(MIG)中心の「静的隔離」と、ソフトウェア中心の「動的共有・オーバーコミット」が双方向でともに成熟しつつあり、DRAはこの二つを宣言的インターフェースで統合しようとする試みと見ることができる。

加えてvGPU層では、課金・ライセンスモデルとモード選択(演算中心のvCS、ワークステーション用のvWSなど)が運用設計の変数として入ってくる。共有技術を評価するときは、純粋な性能・隔離特性だけでなくライセンスコスト、対応ハードウェア世代、ハイパーバイザ・Kubernetes統合の成熟度まで併せて秤にかけてこそ、総所有コスト(TCO)の観点の最適解に到達できる。

6. 考慮事項および示唆点

適用戦略(ワークロード性格による分岐):GPU共有設計の出発点は「信頼境界」である。同じチームの信頼できるバッチ(batch)・開発ワークロードはタイムスライシング・MPSで稼働率を極大化し、外部顧客・他組織が混ざるマルチテナンシはMIGでハードウェア隔離を確保すべきである。遅延に敏感なリアルタイム推論は性能干渉が致命的なため、タイムスライシングを避けMIG専用インスタンスやMPSの上限設定を使うのが安全である。一つの技術を全社標準とするより、ワークロード類型別に共有ポリシーを差等適用することがコスト・安定性いずれにも有利である。実務ではノードプールを「MIG隔離プール / タイムスライシング共有プール / 専用プール」に分離し、ネームスペース・ラベルでワークロードを適切なプールへルーティングする方式が運用を単純にする。
トレードオフ(隔離対稼働率対柔軟性):三つの目標は同時に極大化できない。MIGは隔離を買うがプロファイル固定と再構成コスト(作業をすべて空けねばならない)という柔軟性の損失を払い、タイムスライシングは柔軟性と稼働率を得る代わりに隔離を放棄する。組織は「隔離失敗時の被害規模(データ流出・SLA違反)」と「稼働率1ポイントのコスト価値」を定量化し、どの地点で妥協するかを明示的に定めねばならない。とりわけ稼働率だけを追って過度にオーバーコミットすると、OOM・尾部遅延の急増でかえって有効処理量が落ちる逆説に注意すべきである。
観測と運用(共有環境の可視性):共有が増えるほど「どの作業がどのかけらでどれだけ使うか」が見えなければ、ボトルネック・干渉の原因を見つけにくい。GPU稼働率(SM占有率)・VRAM使用量・メモリ帯域・インスタンス別電力などをDCGMのような手段でかけら単位に収集し、マルチテナンシではテナント別クォータ・課金と結びつけるべきである。単純な「GPU使用率90%」はSMが実際に働いているのか、メモリだけを占有しているのかを区別できないため、共有環境のKPIはより細分化されねばならない。
展望と連携技術:共有技術はKubernetes DRA、CUDA仮想メモリ管理、推論サーバのKVキャッシュ共有、そしてGPU相互接続(NVLink・NVSwitch)・CXLのようなメモリ拡張技術とかみ合って進化する。今後は静的ハードウェア分割と動的ソフトウェアオーバーコミットが宣言的インターフェース(DRA)の下へ収束しつつ、「要求した能力どおり自動で分割・回収される」弾力的なGPUプールが普遍化する見通しである。技術士の観点では、特定ベンダ技術に従属するより、隔離・稼働率・課金・観測を網羅するGPU資源管理ガバナンスを設計することが核心的な力量となる。

参考資料

NVIDIA, "Multi-Instance GPU (MIG) User Guide — Supported MIG Profiles." https://docs.nvidia.com/datacenter/tesla/mig-user-guide/
NVIDIA, "Multi-Process Service (MPS)." https://docs.nvidia.com/deploy/mps/
NVIDIA, "Virtual GPU Software Documentation." https://docs.nvidia.com/vgpu/
Kubernetes, "Dynamic Resource Allocation." https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/
NVIDIA, "DRA Driver for NVIDIA GPUs." https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/dra-intro-install.html

一言まとめ: GPU仮想化は、高価なGPUの低い稼働率とマルチテナンシ隔離という相反する目標を、時間分割(タイムスライシング)・空間分割(MPS)・ハードウェア分割(MIG)・VM分割(vGPU)で妥協する技術スペクトラムであり、隔離が強いほど粒度・柔軟性を失うトレードオフを持ち、Kubernetes DRA・CUDA仮想メモリで静的隔離と動的共有が宣言的に収束する方向へ進化する。