Azure Kubernetes Service (AKS)でのマルチインスタンス GPU (MIG) パーティション分割戦略

運用環境で GPU ワークロードを実行しているチームは、多くの場合、利用率と、メモリ、スループット、レイテンシの要件とのバランスを取る必要があります。 GPU の種類には異なる容量があり、特定のワークロードでは、物理 GPU によって提供されるすべてのリソースが必要なわけではありません。 各ワークロードに GPU 全体を割り当てると、容量がアイドル状態になる可能性があります。一方、小さい GPU サイズを選択しても、ジョブの要件を満たさない可能性があります。 これらの不一致によって、需要の変化に応じて、使用可能な容量を効率的に使用することが困難になります。

マルチインスタンス GPU (MIG) は、 互換性のある NVIDIA GPU を 専用のコンピューティングリソースとメモリ リソースを持つパーティションに分割します。 AKS クラスターでは、ワークロードは Kubernetes 拡張リソースを介してこれらのパーティションを要求します。 複数のワークロードが物理 GPU を共有でき、各ワークロードで GPU 全体が必要になるのではなく、パーティション サイズが要件に一致します。

MIG では、2 つの戦略がサポートされています。 単一の戦略では、ノード プール内のすべてのパーティションが同じプロファイルを使用し、ノードは各パーティションを nvidia.com/gpuなどの標準 GPU リソースとしてアドバタイズします。 混合戦略では、ノード プールはプロファイルを組み合わせることができ、ノードは、 nvidia.com/mig-1g.5gbなどの独自のリソース名で各プロファイルをアドバタイズします。

複数のジョブで同じパーティション サイズが必要な場合は、1 つの戦略を選択します。 ワークロードに異なるサイズが必要な場合は、混合戦略を選択します。 パーティションをワークロード要件に合わせると GPU 使用率が向上しますが、適切なレイアウトは、測定されたメモリとスループットの要件によって異なります。

パーティションと Kubernetes リソースを理解する

パーティションは、GPU 内でのコンピューティングとメモリのハードウェア割り当てです。 プロファイルは、パーティションのサイズ (1g.5gbなど) を定義します。 レイアウトは、GPU 上で構成されたプロファイルのセットです。 リソース名は、ノードがスケジューリングのためにアドバタイズする Kubernetes 拡張リソースであり、ワークロードは名前とカウントでそれを要求します。 MIG では、1 つの GPU リソースに対する要求は、物理 GPU 全体ではなく 1 つのパーティションを表すことができます。 パーティション メモリは GPU モデルに依存するため、ワークロード マニフェストを記述する前にノードがアドバタイズするリソースを調べます。

単一戦略と混合戦略を比較する

次の表では、1 つの戦略と混合戦略のワークフローを比較します。

サポートされている GPU VM のサイズ

次の表に、Azure でマルチインスタンス GPU パーティション分割をサポートする VM サイズを示します。

一貫したリソース要件には単一戦略 MIG を使用する

単一の戦略は、コンピューティングとメモリの要件が似ているワークロードに適しています。 統一されたパーティションを使用すると、チームは共通の GPU リソース名を Kubernetes マニフェストに保持しながら GPU を共有できます。 この整合性により、ノード プールが一貫したワークロード クラスを処理する場合の割り当てが簡略化されます。

1 つの戦略のトレードオフは、リソース名にパーティション サイズが記述されていないということです。 プール セレクターまたはノード アフィニティを使用して、目的の容量をターゲットにします。 リソース名だけでは、MIG パーティションが別の MIG ノード プールによってアドバタイズされた完全な GPU と区別されたり、異なる単一戦略プールのパーティション サイズが区別されたりすることはありません。 配置コントロールがない場合、ポッドは、アプリケーションのサイズ設定の前提条件と一致しないデバイスを受け取る可能性があります。

ワークロードの要件が大きく異なる場合、均一なレイアウトでは、大きなパーティションが十分に使用されないままになる場合や、小さいパーティションが一部のポッドに適さない場合があります。

さまざまなリソース ニーズに対して混合戦略 MIG を使用する

混合戦略を使用すると、チームは同じ GPU に異なるパーティション サイズを割り当てることができます。 この方法は、共有プールが異なる要件を持つワークロードにサービスを提供し、すべてのポッドに同じサイズを割り当てると、容量が無駄になったり、より大きな GPU ワークロードが実行されないようにしたりする場合に役立ちます。

混合戦略では、各パーティションの種類に個別の Kubernetes リソース名があります。 ワークロード マニフェストは必要な種類を要求するため、サイズの選択はプールの均一な構成のみに依存するのではなく、明示的に行われます。 Teams は、アプリケーションのサイズ設定と展開の構成の一部として、これらの要求を維持する必要があります。

混合戦略のトレードオフは、容量の断片化です。ポッドは、他のパーティションの種類が空いている場合でも保留中のままです。 Kubernetes は、小さいパーティションを組み合わせたり、要求を満たすためにレイアウトのサイズを自動的に変更したりすることはありません。 同じレイアウトのノードを追加すると、レイアウトにない型ではなく、構成済みの型の容量が増えます。 GPU 使用率の合計だけでなく、各サイズの同時需要に関するミックスを計画します。

AKS で MIG の混合戦略を構成する方法

AKS では、混合戦略によってパーティション レイアウトとマネージド デバイス プラグインの両方が構成されます。 AKS は Kubernetes に接続するコンポーネントを処理しますが、サポートされているレイアウトを選択し、ワークロード要求のサイズを適切に設定します。 レイアウトを変更するには、代替ノード プールとワークロードの移行が必要です。

ワークロード向けの戦略を選択する

• 代表的な GPU ワークロードをベンチマークし、要件を満たすのに十分なメモリとコンピューティング容量を持つパーティションを選択します。
• 同じサイズを一貫して必要とするワークロードには、単一の戦略を使用します。 GPU リソースの同時需要に複数のサイズが含まれている場合は、混在レイアウトを使用します。
• リソースの種類別に容量を計画する。 予備の GPU メモリまたは別の種類の未使用のパーティションでは、Pod をスケジュールできることを保証しません。
• ホストの CPU とメモリの容量と GPU パーティションを確認します (MIG では、他のスケジューリング制約は削除されません)。
• パーティション分割されていない個別のプールで完全な GPU を必要とするワークロードを保持し、分散ワークロードが GPU 固有の MIG 機能に対応しているかを検証します。
• 重複するプール用のクォータとアプリケーション中断の制御を考慮して、代替プールへのワークロードの移行としてレイアウトの変更を計画します。

次のステップ

MIG の機能とワークロードの例を開始するには、選択した MIG 戦略のガイドを使用します。

• 単一戦略の MIG ノード プールを構成して、統一パーティションと共通の Kubernetes GPU リソース名を使用します。
• 混合レイアウトとプロファイル固有のワークロード要求用に、混合戦略の MIG ノード プール (プレビュー) を構成します。
• GPU ノードのオブザーバビリティのベスト プラクティスについて学ぶ