「AIファクトリー」とは、単一のモデルや1つのKubernetesクラスターではなく、ファインチューニング、推論の実行、評価など、異なる目的で同時に利用するチーム向けの共有GPU（Graphics Processing Unit）群である。CNCFのブログに掲載された記事は、エンタープライズにおける本当の課題は、もはやモデルのトレーニングだけではなく、GPUの利用率を高く保ち、コストを測定可能にしながら、各チームに同じハードウェアへの安全で隔離されたアクセスを与えることだと述べている。
この記事を執筆したのは、CNCF Ambassadorであり、vClusterのPlatform AdvocateでもあるHrittik Royである。記事では、Kubernetes上にこの環境を構築する方法を実践的に読み解いている。中心的な考えは、Kubernetesがコンテナ、RBAC、自動スケーリング、ポリシーの成熟した基盤を提供する一方で、アクセラレーターと同一ノード上のテナント間の分離を扱うには、追加のエコシステムが必要だったというものだ。
ボトルネックは推論速度だけでなく利用率である
GPUユニットはAI基盤における最大の資本支出である。そのため、利用率は、単一の実行で最高速度を記録することよりも重要な経済指標になる。記事は、主に2つの問題を示している。リソース割り当てモデルと、分離モデルである。
従来のdevice pluginモデルでは、ワークロードが例えばnvidia.com/gpu: 1を要求すると、実際には10％しか使用していなくても、GPUユニット全体を予約する。一方、Kubernetes 1.34で一般利用可能になったDynamic Resource Allocation（DRA）では、スケジューラーがアクセラレーターを、特性、メモリ、トポロジーを持つデバイスとして扱える。ただし、GPUユニットを自動的に分割して割り当てるわけではない。密度を実現するのはデバイスレイヤーであり、例えばHAMiがある。HAMiはCNCFのIncubating段階にあるプロジェクトで、コンテナレベルでメモリとコンピュートにソフトウェア上の制限を設け、複数のアクセラレーターベンダーをサポートしている。
一方、チームごとに専用ハードウェアを割り当てると強力な分離を実現できるが、容量の大部分が未使用のままになる可能性がある。そのため記事は、信頼境界が厳格な場合にはGPUユニット全体を割り当て、単一の信頼領域内ではユニットを分割して密度を高めるという区別を示している。NVIDIA MIGはハードウェアレベルでメモリと障害の分離を提供するが、敵対的なテナント間の隔壁として使用することについては依然として議論があると記事は指摘している。そのため、信頼度が低い場合には、GPU全体の割り当てが保守的な選択肢となる。
ベアメタルからワークロードまで、ファクトリーを構成するレイヤー
システムは、未加工のハードウェアのプロビジョニングから始まる。ノードを検出し、GPUユニット、ECCメモリの状態、ネットワークカードの識別情報を検査した後、GPUドライバー、CUDAライブラリ、NCCLを含むオペレーティングシステムイメージをインストールする。その後、適切なBIOS設定を適用し、負荷テストとNCCLテストを実施して、GPUユニットが帯域幅を最大限に活用して接続されていることを確認する。結果は、NetBoxのような信頼できる情報源に記録する。このサイクルは、ベンダー固有のハードウェアマネージャー、またはIronicと組み合わせたMetal3やvMetalなどのオープンソースツールによって構築できる。
割り当て後は、KAI SchedulerやVolcanoなどのツールが、トポロジーを考慮したギャングスケジューリングを担い、Kueueが待機、受け入れ、クォータを管理する。ワークロードレイヤーでは、推論エンジンにvLLM、標準的なエンドポイントの提供と自動スケーリングにKServeを使用できるほか、より大規模な環境では、分離推論のためにNVIDIA Dynamoやllm-dを利用できる。Gateway APIがルーティングを提供し、LiteLLMがOpenAI API互換のゲートウェイを追加する。
このプラットフォームはコンテナに限定されない。記事は、トレーニング環境でSchedMDのSlinkyを介してSlurmを使用できると説明している。SlinkyはSlurmのサービスを専用リソースとして表現し、GPU OperatorおよびDRAと統合する。また、KubeVirtによって仮想マシンをKubernetesワークロードとして実行することもでき、仮想マシンとコンテナを同じフリートから、統一された権限とクォータで管理できる。
分離は単なる名前空間ではない
記事は分離の問題を2つのレベルに分けている。コントロールプレーンのレベルでは、tenant clusterパターンにより、各チームにAPIサーバー、専用リソース、独立したアドミッションルール、RBACを備えた仮想Kubernetesインターフェースを提供し、それを単一の基盤クラスター上のワークロードとして実行する。vClusterはその一例であり、独自拡張なしにkubectl、Helm、Argo CDなどの使い慣れたツールを使用できる。
一方、データプレーンのレベルでは、ネットワーク、ストレージ、クォータ、実行環境の分離が必要になる。CNIとポリシーにはCilium、高速パスにはMultusとSR-IOVを使用でき、ノード間のGPUトラフィック転送にはInfiniBandまたはRoCEv2を利用できる。また、VXLANとEVPNによる分離VPCや、InfiniBandのパーティションキーも使用される。一方、NVIDIA BlueFieldやAMD PensandoなどのDPUは、分離と暗号化の一部の機能をホストCPUから切り離す。記事は、真のクラウド基準とは、必要に応じてハードウェアによって強制される分離であり、名前空間だけに依存することではないと強調している。
フリートをクラウドサービスに変えるものは何か？
編集部による考察：この提案の実用的な価値は、議論を「どのモデルが速いか」から、基盤そのものをどのように運用するかという問題へ移す点にある。GPUユニットを集めただけでは、プラットフォームはクラウドサービスにならない。テナントがAPI、Terraform、またはGitOpsを通じてクラスターを作成・削除でき、リソースがFluxやArgo CDによって管理される宣言的な形式で定義され、OIDCのアイデンティティとRBACの権限が備わって初めて、クラウドサービスになる。
サービスには、理解しやすい計測と課金も必要である。記事は、DCGMのデータを使用してGPU秒数を計算し、それをOpenCostを通じてテナントに配分することを提案している。監視と信頼性も、運用上の付属品ではなく製品の一部である。DCGMが劣化を監視し、Node Problem Detectorが障害シグナルをノードの状態に変換する。その一方で、処理サイクルは疑わしいノードを隔離して排出し、新しいワークロードがスケジュールされる前に空にする。セキュリティレイヤーには、OIDC経由のKeycloak、External Secrets Operatorと組み合わせたOpenBao、制御のためのKyvernoまたはOPA、実行時およびサプライチェーンのセキュリティのためのFalcoとTrivyなどのツールが含まれる。
最も難しい試験は、デモから大規模な本番環境へ移行することである。分割された1つのGPU上で2つのチームと2つのモデルを実行する例だけでは、数百のノードと複数のデータセンターで設計が妥当であることを証明できない。記事は、Kubernetes 1.35とともに発表されたNVIDIA AI Cluster RuntimeやKubernetes AI Conformanceプログラムなどの検証ツールの役割に言及する一方、爆発半径、テナント間の分離限界、NVIDIA DSX OSのバンドルとオープンソースレイヤーの組み合わせのどちらを選ぶかについて、運用上の未解決の問題を残している。
結論として、「AIファクトリー」の成功は、ハードウェアのトポロジーを考慮しながら、密度、分離、課金を組み合わせられるかにかかっている。つまり、NVLinkまたはNVSwitchに対するGPUユニットの位置、InfiniBandまたはRoCEへの接続、NUMAノード上のGPU、NIC、CPUの配置である。これらの情報なしにワークロードをスケジューリングすると、ソフトウェアレベルではプラットフォームが正常に見えていても、最も遅いリンクによって集合通信の処理が遅くなる可能性がある。