8月27日、Hrittik Royが「Building an AI factory on Kubernetes」と題した記事を公開した。この記事では、複数チームが同一のGPUフリートを安全に共有するための「AIファクトリー」をKubernetes上で構築するアーキテクチャについて詳しく紹介されている。
「誰がGPUを使っているか」を制御する問題
LLMブームでGPUは企業の最大の資本支出になった。しかし問題は性能より稼働率だ。
従来のデバイスプラグインモデルでは、ポッドがnvidia.com/gpu: 1を要求すると、使用率が10%であっても物理GPUを1枚まるごとピン留めする。これでは高価なアクセラレータが大半の時間アイドルになる。かといって複数チームを同一クラスタに載せると、ファインチューニング・推論・評価の各チームが互いのリソースを踏み荒らす。
NVIDIAは「AIファクトリー」を「データ準備からトレーニング、ファインチューニング、大規模推論まで、AIライフサイクル全体のインフラ」と定義している。エンタープライズの文脈に置き換えると、1つのフリート、複数チーム、異なるクォータ・ポリシー・トラスト境界を同時に成立させる問題だ。
SemiAnalysisのClusterMAX（※編集部の考察：元記事にClusterMAXへの外部リンクは存在しない）がGPUクラウドを評価する際、生スループットより「テナントごとの分離の強度」「テナントごとのKubernetesクラスタ」「DPUベースの分離」を重視することがその証左でもある。
GPU割り当て層：経済性を決めるレイヤー
本記事で最も実践的な議論はGPUの分割と分離の使い分けだ。
Figure 1. 物理GPU丸ごと割り当てと、パーティション分割の比較
**Dynamic Resource Allocation（DRA）**は、スケジューラがアクセラレータをメモリ・トポロジーといった属性を持つリッチなデバイスとして扱えるようにする機能だ。ただしDRA自体がGPUを分割するわけではなく、密度の向上はデバイス層の実装に依存する。
ソフトウェアによるGPU分割の実装として紹介されているのが**HAMi**（CNCFインキュベーティングプロジェクト）だ。ポッドごとにメモリと計算量の上限をソフトウェアで強制し、1枚のGPUカード上で複数ポッドをガードレール付きで動作させる。複数ベンダーのアクセラレータに対応している点も特徴だ。
一方、コンフィデンシャルコンピューティングを視野に入れるオペレーターは別の判断をする。NVIDIAのMIG（Multi-Instance GPU）はメモリとフォルトをハードウェアで分離するが、敵対的テナント間の境界としての利用は議論があり、保守的なデフォルトは「テナントごとにGPU丸ごと1枚」になる。つまりこの層には2つの役割がある：
- テナント分離：物理GPUを丸ごと割り当て
- 密度向上：単一トラストドメイン内でのパーティション分割
スケジューリングは別レイヤーで担う。KAI SchedulerとVolcanoがギャングスケジューリングとトポロジーアウェアな配置を処理し、Kueueがキューイング・アドミッション・クォータを担当する。
スタック全体像：16層の構成要素
記事はAIファクトリーを以下の16層に分解して解説している。各層は独立した関心事を持ち、特定のコンポーネントで実装される。全体像を把握したうえで後述の各層解説を読むと理解が深まる。
| 層 | 役割 | 主要コンポーネント |
|---|---|---|
| ハードウェアライフサイクル | ベアメタルのプロビジョニング | Metal3/Ironic、Tinkerbell |
| クラスタライフサイクル | クラスタ作成・GitOps | Cluster API、Argo CD/Flux |
| ノードインベントリ | GPU・NIC・MIG・トポロジーのラベリング | Node Feature Discovery、GPU Operator |
| テナント分離 | 同一ハードウェア上でのチーム分離 | vCluster |
| GPU割り当て | アクセラレータのスケジューリング | DRA、MIG、HAMi、KAI Scheduler、Kueue |
| 推論・サービング | APIとしてのモデル提供 | vLLM、KServe、llm-d |
| バッチ・HPC | SLURMワークロード実行 | Slinky（SLURM on Kubernetes） |
| VM | テナント向け仮想マシン | KubeVirt |
| ゲートウェイ・オートスケーリング | ルーティングとスケーリング | Gateway API、LiteLLM、KEDA |
| ネットワーク | GPU間データ転送・テナント分離 | Cilium、Multus、SR-IOV、RDMA |
| ストレージ・データ | データセット・チェックポイント永続化 | CSI、Rook/Ceph |
| オブザーバビリティ | 稼働率・ログ・トレース | Prometheus、OpenTelemetry、DCGMエクスポーター |
| ID・ポリシー | 認証認可・クォータ | Keycloak、Kyverno/OPA |
| シークレット・セキュリティ | 秘密管理・ランタイム | OpenBao、Falco、Trivy |
| 信頼性・修復 | ノード障害の検出と回復 | DCGM health checks、Node Problem Detector |
| セルフサービス・課金 | テナントのプロビジョニングと課金 | OpenCost、DCGM GPU秒 |
テナント分離：コントロールプレーンとデータプレーン
テナント分離には2つの半面がある。
コントロールプレーン側は「テナントクラスタパターン」で解決する。各チームに仮想コントロールプレーン（独自のCRD・アドミッションWebhook・RBAC付きの完全なKubernetes APIサーバー）を与え、他テナントから完全に見えない状態にする。vClusterがこのパターンの実装例として挙げられており、通常のkubectl・Helm・Argo CDがそのまま使えるため、プロプライエタリな拡張なしに動作する点が強調されている。
Figure 2. 1つの基盤クラスタ上のテナントクラスタ群が、プールされたGPUフリートを共有する
実運用では2段階構成が一般的だ。高トラストまたはエンタープライズテナントには専用クラスタ（場合によっては専用ハードウェア）を提供し、コスト重視の小規模テナントにはプール容量上のテナントクラスタを割り当てる。同一のコントロールプレーンが両者を管理する。
推論サービングとSLURMワークロード
推論層では、vLLMを推論エンジンとして、KServe（CNCFインキュベーティングプロジェクト）がオートスケーリングと標準エンドポイントでラップする構成が紹介されている。NVIDIA Dynamoとllm-dは大規模デプロイ向けの分解型推論（disaggregated inference）を担う。フロントにはLiteLLMがOpenAI互換ゲートウェイとして機能し、多数の専門モデルを単一APIに統一する。
トレーニングチームはSLURMに慣れていることが多く、SchedMDのSlinkyでSLURMをKubernetes上で動かすパターンが定着しつつある。SLURMデーモンをCRDとして表現し、GPU OperatorおよびDRAとトポロジーアウェアなスケジューリングを統合する。GPUDirect RDMAでフルNCCL帯域を確保し、プロローグ・エピローグのヘルスチェックも組み込まれている。
フリート規模での信頼性
フリート規模ではGPUの障害は日常的に発生する。ECCエラー、バス落ち、NVLinkやサーマル障害が代表例だ。DCGMのアクティブ・パッシブ監視でデグラデーションを検出し、Node Problem Detectorがハードウェアシグナルをノード状態に変換、修復ループが疑わしいノードを新規ワークロード受け入れ前にcordon・drainする。ClusterMAXのような評価システムが「ピークスループットより信頼性」を重視するのはこの理由による。
詳細はBuilding an AI factory on Kubernetesを参照していただきたい。
