NVIDIA、連合学習フレームワーク「NVIDIA FLARE」でDocker・Kubernetes・Slurmの混在運用に対応――拠点ごとのインフラ差異を吸収する2層構成を実現

要点

• NVIDIAは2026年9月15日、連合学習フレームワーク「NVIDIA FLARE」において、Docker、Kubernetes、Slurmを横断して実行できるアーキテクチャの詳細を発表した。

• 常駐する管理プロセスと動的に起動するジョブ実行プロセスを分離する2層構造を採用し、学習実行時以外はGPUを占有しないリソース効率の高い仕組みを実現した。

• 参加拠点は自組織の環境に応じて実行基盤を選択でき、ローカルデータや認証情報、スケジューリングの主権を個別に保持したまま共同学習に参加できる。

• バージョン2.8でDockerとKubernetesに対応し、バージョン2.9でHPCや共有GPUクラスタ向けのSlurmサポートが追加された。

• 米NVIDIAは2026年9月15日、同社が主導するオープンソースの連合学習フレームワーク「NVIDIA FLARE」において、Docker、Kubernetes、Slurmという異なる計算基盤を統合的に扱える拡張アーキテクチャを発表した。複数の参加組織が異なるシステム基盤を利用している環境でも、インフラの標準化を強制することなく協調的な機械学習プロジェクトを運用可能にする。

共同学習の拡大に伴うインフラの分断とリソース管理の課題

連合学習（各拠点がローカルデータを外部に出さず、分散環境でモデルを学習してパラメータのみを統合する手法）のプロジェクトは、初期段階では単一のサーバーと数台のクライアント端末、拠点ごとの1つのデータセットといったシンプルな構成で始まることが多い。

しかし、プロジェクトの規模が拡大して参加組織が増加すると、運用の主眼はアルゴリズムの実行から共有インフラの管理へと移行する。ある参加組織は単一のDockerホスト環境を使用し、別の組織はKubernetesクラスタを運用し、研究機関ではSlurm（スーパーコンピュータ等で用いられるワークロード管理システム）でGPUジョブを管理しているといったように、拠点ごとに導入されている基盤が異なるケースが生じる。

すべての参加者に同一のインフラ導入を義務付けることは共同研究の大きな障壁となる。また、ジョブが必要とするときにのみ適切にGPUを割り当てるリソース管理や、複数の研究プロジェクトを混在させずに分離すること、各組織が自らのデータや認証情報を管理下に置き続けることなども運用の大きな課題となっていた。

管理と実行を分離する「2層アーキテクチャ」

NVIDIA FLAREは、常駐する連携管理サービスと、ジョブを実行するプロセスを明確に分離する2層アーキテクチャによってこの問題に対応している。

1層目となる親プロセス（サーバーおよびクライアント）は常時稼働し、拠点間の認証や通信、全体の調整を担当する。この親プロセス自体は学習に必要なGPUリソースを占有しないため、待機中に高価な計算資源を消費し続けることがない。

データサイエンティストが連合学習ジョブを投入すると、各拠点の親プロセスが設定された実行プラットフォームを通じて2層目のジョブワーカーを動的に起動する。ジョブ側ではGPUの数、割り当て可能なCPUユニット数、ホストメモリなどのリソース要件をプラットフォーム非依存の形式で記述する。各拠点のランチャーがその要件と現地の構成設定を照合し、それぞれの環境に応じた実行単位へと変換してワーカーを立ち上げる。ジョブワーカーは割り当てられたリソースを用いて処理を行い、結果を返却した後に自動的に終了する。

3種類の実行ランタイムと環境ごとの役割

NVIDIA FLAREでは、各拠点の運用者が自組織のインフラ環境に合わせて最適なランタイムを選択できるようになっている。

• Docker: ワークステーションや単一ホストの環境向け。動的な実行単位は「ジョブコンテナ」となり、リソース管理はローカルのDockerホストが担う。
• Kubernetes: クラウドやオンプレミスのクラスタ環境向け。動的な実行単位は「ジョブポッド」となり、Kubernetesのスケジューラがリソースを割り当てる。
• Slurm: ハイパフォーマンスコンピューティング（HPC）や共有GPUクラスタ環境向け。動的な実行単位は「バッチ割り当て」となり、Slurmのスケジューラがリソースを制御する。

「Study」による論理境界とデータ主権の維持

システム内には「Study（研究）」と呼ばれる論理的なマルチテナント境界（1つのシステム環境内で複数の利用者やプロジェクトを分離して安全に共存させる仕組み）が備わっている。

各拠点の運用者は、Studyごとに自組織のローカルデータセット、シークレット（秘密鍵や認証情報）、承認済みコンテナイメージ、スケジューリングポリシーを個別に紐付けて管理できる。これにより、単一のシステム展開の中で複数の研究を互いに干渉させることなく運用可能であり、各拠点はセキュリティやガバナンスの統制を手元に残したまま共同研究に参加できる。

バージョン2.8から2.9への機能拡張

これらの機能は段階的に実装が進められており、NVIDIA FLARE 2.8においてDockerおよびKubernetesへのデプロイ機能が導入された。さらに最新のFLARE 2.9においてSlurmのサポートが追加されたことで、一般的なコンテナ環境から大規模なHPC・共有GPUクラスタに至るまで、多様な計算基盤を組み合わせた連合学習のスケールが可能になったとしている。