8月14日、Matt Saundersが「Kubeflow Expands AI Capabilities as CNCF Graduation Nears」と題した記事を公開した。KubeflowがCNCFグラデュエーション（成熟プロジェクトとしての卒業認定）に向けた審査段階を迎える中、分散AI学習とHPC（高性能計算）を単一のKubernetesクラスタ上で統合運用できる環境がいよいよ現実味を帯びてきた。今回の一連のアップデートは、その実現に向けた技術的な布石として読み解くことができる。

Kubeflow TrainerがFlux Frameworkと統合、HPC×AIが一つの環境に

今回の更新で最もエンジニアに刺さるのは、Kubeflow TrainerのFlux Framework統合だ。

KubernetesでAIトレーニングとHPCシミュレーションを同一環境で動かすことは、これまで困難だった。Kubeflow Trainerは元々、分散AIトレーニングを統一的に扱うことを目的としており、今回そこにMPIサポートを加えた上で、Flux Frameworkとの正式な統合が実現した。

コントリビューターのAndrey VelichkevichはLinkedInの投稿でこう述べている。

This is a huge step toward the adoption of HPC technologies in Cloud Native infrastructure, which is essential for modern GenAI workloads.
— Andrey Velichkevich

協調にはPMIx（Process Management Interface Exascale）が使われる。PMIxはスーパーコンピューター向けに設計されたプロセス間通信インターフェース規格であり、MPI（Message Passing Interface）ジョブのライフサイクル管理をエクサスケール規模まで対応できるよう拡張したものだ。これをKubernetesのワークロードに持ち込むことで、従来はHPCクラスタ専用とされていたエクサスケール規模のシミュレーションとAIトレーニングを、単一クラスタ上で並走させられるようになる。

このFlux統合は、後続のSDK強化やKServeのLLM対応と合わせて読むと意味がより鮮明になる。Kubeflowは「AIトレーニング専用ツール」から「AIライフサイクル全体を管理するプラットフォーム」へと軸足を移しており、HPCとの統合はその延長線上に位置づけられる。

Kale 2.0：Jupyterノートブックをそのままパイプラインに

HPCとの統合によってトレーニング基盤の幅が広がった一方、実験から本番環境への移行コストも依然として課題として残る。それに応えるのが**Kale 2.0**だ。

KaleはJupyterノートブックのセルにアノテーションを付けるだけで、**Kubeflow Pipelines（KFP）SDKのコードを一切書かずに**本番用パイプラインを生成するツールである。バージョン2.0ではKubeflow Pipelines v2アーキテクチャへの対応が完了し、データサイエンティストが実験から本番環境への移行を手動のパイプライン記述なしに行えるようになった。

機械学習の開発フローにおいて「実験はできるが本番化が重い」という課題は根深い。Kaleはその橋渡しを担うツールとして位置づけられており、インフラを意識させずにデータサイエンティストの生産性を上げるという思想は、以降のSDK強化とも一貫している。

SDK・プラットフォーム各所の強化

Kaleが実験→本番のギャップを埋めるなら、Kubeflow SDKの強化はその先のデータ処理・学習・チューニングの統合を担う。今回のアップデートでネイティブのSpark対応が追加され、インフラ設定を書かずにSpark on Kubernetesを実行できるようになった。データ処理・パイプラインオーケストレーション・分散トレーニング・ハイパーパラメータチューニングを統一されたPythonインターフェースから扱える。LLMのファインチューニング用ブループリントも内蔵されており、今後はOpenTelemetryインストルメンテーションとMLflowトラッキングの追加も予定されている。

Kubeflow Notebooks v2はアルファ版が公開済みだ。CRD（Custom Resource Definition）ドリブンの宣言的アーキテクチャに全面刷新され、JupyterLabやVS Codeといったインタラクティブな開発環境をプラットフォームチームがテンプレートで管理できるようになる。CRDとはKubernetesのリソース定義を独自拡張する仕組みで、これを活用することで開発環境の構成をコードとして宣言・バージョン管理できる。

Model Registryは「Hub」に名称変更された。Model CatalogとMCP Catalogを包含するより広いスコープを反映したものだ。OCI（Open Container Initiative）を標準ストレージとしてMCPサーバーの検索・デプロイも可能になった。

**KServe**はLLMInferenceService CRDを新設し、LLMサービングをプラットフォームのファーストクラスプリミティブとして扱えるようにした。複数ノードへの分散推論とOpenAI互換APIをサポートする。

Kubeflow Community Distribution 26.03は元記事の記載に基づくとKubernetes 1.34以降を正式サポートし、マルチテナントのデフォルト設定強化とPod Security Standards Restricted準拠を実装した。

CNCF卒業が近づく背景

こうした広範なアップデートは、Kubeflowが現在置かれている文脈を踏まえると一層意味を持つ。KubeflowはCNCFのインキュベーティングプロジェクトとして運営されてきたが、現在はグラデュエーション（成熟プロジェクトとしての卒業認定）に向けた審査段階にある。CNCFのグラデュエーション審査では、採用実績・ガバナンス・セキュリティ成熟度などが総合的に評価される。認定が確定しているわけではないが、今回のアップデート群はその審査に向けたプロジェクトとしての成熟を示すものとして位置づけられる。

Luca BertonはLinkedInで、SubaruがCNCFのケーススタディコンテストを受賞したエピソードを紹介している。SubaruはKubernetesとArgo CDを活用し、30GBを超えるAIコンテナイメージのプル時間を3時間から3分に短縮したという。本番AI基盤としてのKubernetesエコシステムの成熟を示す事例として言及されている。

コミュニティ側では8月19日にMLOpsの実世界ユースケースを紹介するバーチャルショーケースイベントも予定されている。新しいOutreachプログラムやML Experience Working Groupを通じたコントリビューター育成にも力を入れており、技術面だけでなくコミュニティの厚みを増す取り組みも並行して進んでいる。

詳細はKubeflow Expands AI Capabilities as CNCF Graduation Nearsを参照していただきたい。