Lambda、Kubernetesサービス向けにオープンソースのRun:aiスケジューラーを導入へ

Lambdaは2026年10月13日、NVIDIAと協力し、オープンソース化されたRun:ai GPUスケジューラーをLambda Kubernetes Service（LKS）の標準的なマネージドオプションとして提供する準備を進めていると発表した。これは、マネージドコンポーネントとして提供するスケジューラー群を整備する計画の一環だ。

この計画は、2026年10月13日付のLambdaブログ記事で明らかにされた。同社は「NVIDIAがRun:aiをオープンソース化する決定を歓迎します。Lambda Kubernetes Service（LKS）で標準的な選択肢として提供できるよう、取り組んでいます」と述べた。Lambdaによると、同社は2022年から自社インフラでRun:aiをサポートしてきた。さらに、LKSを通じてRun:aiの機能をより簡単に導入・運用できるようにし、GPU容量の割り当てや共有方法をチームがより細かく管理できるようにすることを目指しているという。

NVIDIA、2025年にスケジューラーをオープンソース化

NVIDIAは、Run:aiプラットフォーム内で開発されたKubernetesネイティブのGPUスケジューリングソリューション「KAI Scheduler」を、Apache 2.0ライセンスの下で2025年4月1日にオープンソースとして公開した。NVIDIAの発表によると、このスケジューラーは引き続きNVIDIA Run:aiプラットフォームの一部としてパッケージ化され、提供される。

NVIDIAによると、このスケジューラーは公平配分値を継続的に再計算し、割り当て量と上限をリアルタイムで調整する。また、ギャングスケジューリング、GPU共有、階層型キューイングを組み合わせている。組み込みのpodgrouperは、Kubeflow、Ray、Argo、Training Operatorなどのフレームワークを使うワークロードを自動的に関連付ける。NVIDIAが説明するスケジューリングサイクルでは、まずKubernetesクラスターのスナップショットを取得し、正当割当量の適用と超過割当量の処理を通じて各キューの公平配分量を算出する。その後、割り当て、集約、回収、プリエンプションの各処理を適用し、現在の割り当てを算出結果に沿った状態にする。

Run:aiのGPU共有と割当量に基づくスケジューリング

Lambdaは、AI開発におけるGPU需要の多様さを説明している。デバッグでは1基のGPUの一部だけで足りることがある一方、評価では多数の独立したジョブを並行して実行する場合があり、分散学習では密接に接続された多数のGPUを一度に必要とすることもある。さらに、初期のアイデアから実験、そして本番運用へと進むにつれて、必要なリソースも変化する。小規模なジョブにGPUを丸ごと割り当てると、確保された容量が使われないまま研究者が待たされる。また、別のグループが予約したまま使っていないGPUのために、チームの実験が滞ることもある。

Lambdaの説明によると、Run:aiはKubernetes向けのGPUスケジューラーであり、標準のKubernetesスケジューラーにはない2つの機能を備えている。1つはGPU共有で、1基のGPU上で複数のワークロードを実行できる。もう1つは割当量に基づくスケジューリングで、各チームに確実な割り当てを保証しつつ、チーム間で未使用の容量を借りられるようにする。

NVIDIAのGPU分割に関するドキュメントによると、GPUメモリを小さな単位に分割することで、複数のワークロードで共有できる。各ワークロードについて要求されたメモリ量が適用されるため、その要求量を超えたり、別のワークロードのメモリを侵食したりすることはない。各ポッドには個別の仮想メモリアドレス空間が割り当てられ、ドキュメントではこの仕組みを「論理GPU」と呼んでいる。

ドキュメントによると、分割したGPUでは、デフォルトでNVIDIAのタイムスライシングを使ってGPU計算資源を共有する。また、マルチGPU分割では、単一ノード内の複数のGPUに同じ分割サイズを割り当てる。たとえば、8基のGPUを使い、各GPUで40GBのメモリを必要とするモデルには、各GPUのメモリ全体ではなく8×40GBを割り当てられる。その結果、そのノード上のほかのワークロードが各GPUで40GBを利用できる。GPU分割とMulti-Instance GPU（MIG）モードは、同じノードでは併用できないとドキュメントは説明している。

NVIDIAのスケジューラーの概念に関するドキュメントによると、新しく作成されたポッドはすべてポッドグループに割り当てられる。ギャングスケジューリングでは、複数のポッドで構成されるワークロードは、すべてがスケジュールされるか、すべてが保留状態になる。ノードプールごとに、プロジェクトと部門それぞれのスケジューリングキューが作成される。正当割当量によって、中断不可のワークロードが実行できる範囲が定められ、割当量を超えたリソースは中断可能なワークロードのみが利用できる。スケジューラーは、ノードプールごとに各プロジェクトと部門の公平配分値を計算する。あるキューが公平配分を下回り、別のキューがそれを上回っている場合、バランスを取り戻すためにキュー間でリソースを移動する。この処理では、割当量を超えている中断可能なワークロードがプリエンプトされることがある。また、プロジェクト間や部門間でリソースを回収することもでき、管理者はノードプールごとに、詰め込み配置または分散配置の戦略を設定できる。

LKSのノード自動復旧

Lambdaは、共有とプリエンプションはいずれも、GPU自体が正常に動作していることを前提としているが、大規模環境ではそれが保証されないと指摘した。アクセラレーターでXIDエラーが発生したり、NVLinkやPCIeのリンクが劣化したり、メモリ行が再マッピングされたり、InfiniBandポートの速度が想定を下回ったりすることがある。スケジューラーは正常なGPUと故障しかけているGPUを見分けられないため、ジョブを停止させるノードにも引き続きジョブを送ってしまう。

Lambdaによると、自動復旧機能はすでにLKSで提供されている。同社は、こうした障害がないかすべてのノードを監視し、それぞれの状態を標準的なKubernetesノード条件として公開していると説明した。条件が発生すると、そのノードは新しい処理を受け付けないように隔離され、実行中のジョブは停止・退避される。その後、障害は自動的に修正されるか、ハードウェア修理にエスカレーションされる。ノードは再検証に合格した後にのみ、サービスに復帰する。

LambdaのマネージドKubernetesに関するドキュメントでは、このサービスを、GPUとInfiniBand（RDMA）に対応し、1-Click Cluster内の全ノードで共有できる永続ストレージを備えたKubernetes環境として説明している。NVIDIA GPU OperatorとNVIDIA Network Operatorがあらかじめインストールされており、GPU、ネットワーク、ストレージが正常に機能しているか継続的に検証するほか、ハードウェアの問題を検出して復旧する自動ノード修復も行う。

マネージドスケジューラーライブラリのロードマップ

Lambdaは、GPUスケジューリングを意図的にオープンにしているレイヤーだと説明し、LKSが次に目指すのは、同社が「AIソフトウェアライブラリ」と呼ぶものだと述べた。これは、Kubernetes、Slurm、Run:aiなどで動作するスケジューラーをマネージドコンポーネントとして提供するもので、顧客がHelmチャートから手作業で組み立てる代わりに、Lambdaが自社のハードウェア上で検証し、最新の状態に保つ。Run:aiはこのライブラリの中核的な対象であり、Lambdaは実現に向けてNVIDIAと協力していると述べた。

Lambdaによると、オープンソースでの公開によってこのアプローチが可能になる。同社は、顧客に一連の統合手順を渡すのではなく、LKS自体にRun:aiを組み込み、パッケージ化、テスト、保守を行える。Lambdaは、パッケージ化、検証、継続的な運用を自社が担う、すぐに使える統合を目指していると述べた。

独自のオープンな研究を行うLambdaは、依存するツールを調査、適応、改善できることを重視しており、NVIDIAの決定によって、その自由がオーケストレーションにも広がると説明した。