GPU共有
GPU共有モードにより、物理GPUを複数のコンテナで共有し、GPU利用率を最適化できます。以下のGPU共有戦略がサポートされています：
マルチインスタンスGPU
GPUタイムシェアリング
NVIDIA MPS
一般
GPUは分割され、複数のコンテナ間で共有される
各コンテナは時間スライスでGPUを使用する
コンテナはGPUを並列に使用する
隔離
GPUは最大7つのインスタンスに分割可能であり、各インスタンスは専用の演算能力、メモリ、帯域幅を持つ。各パーティションは互いに完全に分離されている。
各コンテナは、GPU上で実行されるプロセス間でコンテキストスイッチングを実行することで、基盤となる物理GPUの全容量にアクセスします。ただし、タイムシェアリングは共有ジョブ間のメモリ制限を強制せず、共有アクセスのための高速なコンテキストスイッチングはオーバーヘッドを引き起こす可能性があります。
NVIDIA MPSはリソース分離機能が限定的ですが、GPUの種類や最大共有ユニット数など他の側面で柔軟性を高めており、リソース割り当てを簡素化します。
マルチインスタンスGPU
GPUタイムシェアリング
NVIDIA MPS
これらのワークロードに適しています
特定の耐障害性とQoSを必要とする並列実行ワークロードに推奨されます。例えば、AI推論ワークロードを実行する場合、マルチインスタンスGPUにより複数の推論クエリを同時に実行でき、互いの処理速度を低下させることなく迅速な応答を実現します。
アイドル期間を伴うバースト型およびインタラクティブなワークロードに推奨されます。これらのワークロードは、完全に専用化されたGPUではコスト効率が良くありません。タイムシェアリングを利用することで、アクティブなフェーズ中にワークロードがGPUに迅速にアクセスできます。GPUタイムシェアリングは、完全な分離や継続的なGPUアクセスが必ずしも必要でないシナリオ（例：複数のユーザーがワークロードをテストまたはプロトタイプする場合）において、高価なGPUのアイドル状態を回避するのに最適です。タイムシェアリングを利用するワークロードは、一定のパフォーマンスとレイテンシのトレードオフを許容する必要があります。
アイドル期間を伴うバースト型およびインタラクティブなワークロードに推奨されます。これらのワークロードは、完全に専用化されたGPUではコスト効率が良くありません。タイムシェアリングを利用することで、アクティブなフェーズ中にワークロードがGPUに迅速にアクセスできます。GPUタイムシェアリングは、完全な分離や継続的なGPUアクセスが必ずしも必要でないシナリオ（例：複数のユーザーがワークロードをテストまたはプロトタイプする場合）において、高価なGPUのアイドル状態を回避するのに最適です。タイムシェアリングを利用するワークロードは、一定のパフォーマンスとレイテンシのトレードオフを許容する必要があります。
マルチインスタンスGPU（MIG）
マルチインスタンスGPUは、GPUを最大7つの独立した部分に分割できる機能です。これらのGPU部分はMIGインスタンスと呼ばれ、演算能力、帯域幅、メモリの面で互いに完全に分離されています。
FPTは以下のMIGプロファイルをサポートしています：
GPU H100 SXM
1
all-1g.10gb
単数
7
1g.10gb
2
all-1g.20gb
単数
4
1g.20gb
3
all-2g.20gb
単数
3
2g.20gb
4
all-3g.40gb
単数
2
3g.40gb
5
all-4g.40gb
単数
1
4g.40gb
6
all-7g.80gb
単数
1
7g.80gb
7
all-balanced
混合
2 1 1
1g.10gb 2g.20gb 3g.40gb
8
none (no label)
なし
0
0 (Entire)
GPU H200 SXM
1
all-1g.18gb
単数
7
1g.18gb
2
all-1g.35gb
単数
4
1g.35gb
3
all-2g.25gb
単数
3
2g.25gb
4
all-3g.71gb
単数
2
3g.71gb
5
all-4g.71gb
単数
1
4g.71gb
6
all-7g.141gb
単数
1
7g.141gb
7
all-balanced
混合
2 1 1
1g.18gb 2g.35gb 3g.71gb
8
none (no label)
なし
0
0 (Entire)
GPU A100
1
all-1g.10gb
単数
7
1g.10gb
2
all-1g.20gb
単数
4
4g.20gb
3
all-2g.20gb
単数
3
2g.20gb
4
all-3g.40gb
単数
2
3g.40gb
5
all-4g.40gb
単数
1
4g.40gb
6
all-balanced
混合
2 1 1
1g.10gb 2g.20gb 3g.40gb
7
none with operator
なし
0
0 (Entire GPU)
8
none
なし
0
0
例: 単一戦略構成「all-1g.40gb」を選択した場合、ワーカー上のA100 GPUカードは4つのMIGデバイスに分割され、各デバイスのGPUリソースは物理GPUの1/4、GPU RAMは10GBとなります。
注記
MIG構成はワーカーにインストールされた全カードに適用されます。
同一クラスター内のワーカーグループにおけるMIG戦略は同一タイプ（単一/混合/なし）である必要があります。
「none with Operator」戦略の場合、ポッドはGPU全体のリソースを含む1つのGPUデバイスを使用できます。
「none」戦略の場合、GPUは既にマシンに接続されており、ユーザーは希望する構成に応じてGPU OperatorまたはGPUデバイスプラグインをデプロイできます。この戦略を実装する前に、GPU共有の基本を十分に理解しておくことをお勧めします！
MIG設定
GPUワーカーグループ作成時、インターフェース上でMIG共有モードプロファイルを選択すると、GPU Kubernetesサービスが自動的に設定を行います：
注記
「MIG single」タイプのプロファイルを選択した場合、後続のワーカーグループは「MIG single」タイプのプロファイルに属する共有モードのみを選択できます。「MIG mixed」、「None」、「None with Operator」プロファイルについても同様です。
「None」共有モードは、Kubernetes GPUクラスターの完全な制御権をユーザーに委ねることに相当します。必要に応じて共有モードを実行するには、GPUオペレーターまたはNvidiaデバイスプラグインを手動でインストールできます。
「オペレーター付きなし」共有モードは、当社がGPUオペレーターを管理する状態に相当します。ただし、1つのGPUは同時に最大1つのコンテナにしか割り当てられません。
MIGの確認：ポータルシステムがクラスターの成功を報告した後、次のコマンドでGPUノードのGPUリソースを確認できます：
kubectl describe nodes
出力:
現時点では、ポッドに対して最大4つのnvidia.com/gpuリソースをリクエストできます。各nvidia.com/gpuリソースは、元の物理GPUの演算能力とメモリの1/4に相当します。
ノードが2つのGPUを使用している場合、8つのnvidia.com/gpuリソースが表示されます。
さらに、MIGをタイムスライシング（既にサポート済み）やMPS（未サポート）などの他のGPU共有戦略と組み合わせることで、GPU利用率を最大化できます。
マルチプロセスサービス (MPS)
MPSはNVIDIA GPUの機能であり、複数のコンテナが同一の物理GPUを共有することを可能にします。
GPUリソースの割り当てにおいてMPSはMIGよりも優れており、最大48個のコンテナがGPUを同時に使用できます。
MPSはCUDAのNVIDIA Multi-Process Service機能に基づき、単一GPU上で複数のCUDAアプリケーションを同時に実行可能にします。
MPSではGPUのレプリカ数を事前定義できます。この値はGPUにアクセス・使用可能なコンテナの最大数を示します。
さらに、コンテナ内で以下の環境変数を設定することで、各コンテナのGPUリソースを制限できます：
CUDA_MPS_ACTIVE_THREAD_PERCENTAGE CUDA_MPS_PINNED_DEVICE_MEM_LIMIT
MPSの動作原理の詳細については、以下をご参照ください：https://docs.nvidia.com/deploy/mps/
MPS構成
以下の図に示すように、ワーカーグループ初期化時にGPUを使用するようGPUワーカーグループを設定できます：
この構成では、GPUは48のパーツに「分割」され、各パーツは元の物理GPUの演算能力とメモリの1/48を保有します。
MPSの確認: GPUノードのMPS構成は次のコマンドで確認できます:
kubectl describe nodes $NODE_NAME
出力:
現時点では、ポッドに対して最大48個のnvidia.com/gpuリソースを要求できます。各nvidia.com/gpuリソースは、元の物理GPUの演算能力とメモリ容量の1/48に相当します。
ノードが2つのGPUを使用している場合、96個のnvidia.com/gpuリソースが表示されます。
注記
コンテナが要求するnvidia.com/gpuリソースは1でなければなりません。
クライアントの最大数は48、最小数は2です。物理GPUリソースは最大クライアント数に均等に分配されます。
MPS共有モードでエラーが発生しないよう、1つのコンテナは1プロセスを実行します。
ワークロードデプロイメントマニフェストファイルに「hostIPC:true」設定が必要です。
MPSにはエラー封じ込めとワークロード分離に関する制限があります。ご利用前に調査・ご検討ください。
タイムスライシング
タイムスライシングは基本的なGPU共有機能であり、各プロセス/コンテナがGPUを均等な時間だけ使用します。
タイムスライシングはCPUのコンテキストスイッチング機構を通じてGPU共有を実現し、各プロセス/コンテナはGPUが別のプロセスで使用される際に自身のコンテキストを保存します。
タイムスライシングはMPSのような並列GPU共有をサポートしません。
Kubernetes GPUサービスにおけるタイムスライシングの設定
タイムスライシングはネイティブGPU共有機能であり、すべてのMIG共有モード（MIG混合プロファイルを除く）および「None with Operator」モードで有効化可能です。
GPUワーカーグループ作成時、タイムスライシングとMIGの併用、またはMIGモード有効時のGPU上でのタイムスライシング使用を選択できます。設定は当社が代行します：
タイムスライシングの確認: GPUノードのタイムスライシング設定は次のコマンドで確認できます:
kubectl describe nodes $NODE_NAME
出力:
現時点では、ポッドに対して最大48個のnvidia.com/gpuリソースをリクエストできます。ただし、MPSとは異なり、各ポッドが消費できるリソース量に制限がないため、メモリオーバーフローが発生する可能性があります。
MIGモードを使用する場合、nvidia.com/gpuリソースの数は、MIGインスタンスの数 × 定義したタイムスライシングクライアントの最大数に等しくなります。例：MIGモード2x2g.12gbを使用し、タイムスライシングクライアント数を48に設定した場合、96個のnvidia.com/gpuリソースが表示されます。
注意事項
コンテナリクエストにおけるnvidia.com/gpuリソースは1以上で指定可能です。ただし、1を超えるnvidia.com/gpuリソースをリクエストしても、コンテナが追加リソースを利用できるわけではありません。
タイムスライシング使用時、コンテナの演算リソースとメモリリソースの使用に制限はありません。
クライアントの最大数は48、最小数は2です。
コンテナは1プロセスを実行します。
GPU操作の中断を引き起こすOOMを回避するため、必要なGPUコンテナリソース量を明確に定義してください。
Last updated