AI時代のSlurm対Kubernetes

オリジナル記事「Slurm vs. Kubernetes in the Age of AI」

AIワークロードには、SlurmとKubernetesのどちらのスケジューラを使うべきか。これは、双方から熱烈な議論が交わされるテーマだ。どちらのスケジューラにも長所があり、常に正しいという唯一の正解は存在しない。しかし、SlurmとKubernetesはAIのあらゆる段階で同等の性能を発揮するわけではなく、誤った選択はAIの導入に大きな影響を及ぼす可能性がある。Slinkyという新しいプロジェクトが、その状況を変えるかもしれない。

Slurm（Simple Linux Utility for Resource Managementの略）は、HPCリソースを管理し、ユーザにスーパーコンピュータへのアクセスを許可する手段として、2002年にローレンス・リバモア研究所から登場した。このソフトウェアは、HPCジョブのキューを管理し、ノード、CPU、メモリ、GPUなどの要求された計算リソースを特定の期間、それらのジョブに割り当て、通常はMPIを使用して計算ノード上で実行することで機能する。また、監視機能も提供している。
現在、SlurmはHPCコミュニティで最も普及しているスケジューリングソフトウェアであり、Top500リストに掲載されているスーパーコンピュータの約60%で使用されている。Intersect360 Researchの2024年のデータによると、スーパーコンピュータ市場全体で20%のシェアを占めており、学術分野では圧倒的な地位を築いている。このオープンソース技術は、主にSchedMDという企業によって管理されてきたが、同社は2025年末にエヌビディアに買収された。

Kubernetesもワークロードマネージャーだが、その仕組みは異なる。このソフトウェア（しばしばK8sと略される）は、アプリケーションのデプロイ、保守、スケーリングに使用される一連のコア構成要素を定義することで機能する。ユーザはプロセッサやメモリの数や種類に応じて、どのようなクラスタを構築したいかをK8sに指定すると、ワークロードマネージャーが自動的に環境を構築・維持する。

Kubernetesは、多くの現代的なコンピューティング技術と同様に、2014年にGoogleから誕生した。Googleは、自社の膨大なサーバ群を管理する手段としてKubernetesを社内で開発し、PageRank、MapReduce、Bigtable、Android、TensorFlow、そして大規模言語モデルをもたらしたTransformersなど、他の多くの技術と同様に、継続的な開発を促進するためにK8sをオープンソースコミュニティに寄贈した。

派閥間の深い亀裂を露呈

「Slurm対Kubernetesという議論は、技術コミュニティ内に根深く存在する派閥間の亀裂を露呈している」と、Red Hatのディスティンギッシュド・エンジニア兼CTOオフィス担当副社長であるスティーブン・ワット氏は述べた。

「それは技術的な側面もあれば、文化的な側面もある。かなり興味深いことだと思う」と、ワットはSlurm対Kubernetesの対立について語った。「我々はどちらかといえば実用的な見方をしている。」

レッドハットはKubernetesのエンタープライズ向けディストリビューションを販売しているが、だからといってあらゆる状況でKubernetesを推奨しているわけではない。状況によってはK8sが最適だが、一方でSlurmにはKubernetesでは到底及ばない機能がある。

「アプリケーションの稼働を保証する標準的な運用チームを相手にする場合……それはかなり単純な話だ。彼らには当社のエンタープライズKubernetesディストリビューション、つまりOpenShiftがあるからだ」と、ワット氏は最近のHPCwireとのインタビューで語った。

「別のグループ、私が『PyTorchグループ』と呼ぶようなグループを相手にする場合……それは主に研究に焦点を当てたコミュニティであり、研究機関やFrontierモデルプロバイダが参加している」と彼は続けた。「そして、そうしたチームは通常、数十年にわたりSlurmを運用してきた研究用ITインフラによって支えられているのだ。」

Slurm：スケーラビリティ、バッチ処理、トレーニングに強み

両陣営は、これら2つのワークロードスケジューラの動作について、大きく異なる認識を持っている。研究やHPCコミュニティがSlurmを好むのは、使い慣れているうえに「ただ動く」からだ。大規模なスーパーコンピュータ上で多数のバッチ処理を効率的にスケジューリングする必要があるなら、Slurmに勝るものはないとワット氏は述べた。

「Slurmはただ動く、という認識がある。そして、それは事実だ」とワット氏は述べた。「モデル事前学習を行うなら、Kubernetesではなく[Slurm]の使用を推奨する。Slurmは3万ノードまで拡張可能だ。Kubernetesは約5,000ノードが限界だ。したがって、事前学習にKubernetesを使用する人もいるが、Slurmの方がはるかに使いやすいためだ。」

HadoopやSparkといった分散技術で経験を積んだワット氏は、eBayが機械学習モデルを更新するために、毎晩12時間にわたるトレーニング実行を管理するためにSlurmを使用していたことを振り返る。モデルの更新は、オンラインオークションサイトの取引処理を改善するものだった。

「Slurmはその用途には非常に優れている」とワット氏は述べた。「しかし、それは『誰かが1時間360秒、常にこのシステムに依存している』という状況とは異なる。もしシステムがダウンすれば、事業継続性の問題が生じ、収益の損失につながる。そこでKubernetesが100％、あるいは99.9％の稼働率を保証する。それが推論処理における違いだ。」

Kubernetes：稼働時間、リアルタイム処理、推論に強み

Slurmにはスケーラビリティと簡潔さという利点がある一方、Kubernetesには稼働時間の保証という点で優位性があり、これはAI推論のようなリアルタイムワークロードにとって極めて重要だ。

ワット氏は、Kubernetesの方がはるかに複雑であることを認めている。特に、K8sレイヤーを通じてパフォーマンスの問題を追跡しようとする場合はなおさらだ（それができるなら幸運だ）。しかし、GoogleがKubernetesを設計・構築した方法により、クラスタ障害発生時の回復力を確保するために本来必要となる管理上の複雑さの多くを、このソフトウェアは排除している。

「Kubernetesは、一時的なサービスのために特別に設計されたものだ。平均故障間隔など存在しない」とワットは述べた。「[ノードが]ダウンしても、エンドユーザーに気付かれることなくそれを処理するシステムがある。その仕組みは、Kubernetesがインバウンドリクエスト用のシンプルなプロキシを持ち、複数の異なるサーバ上で同じアプリケーションを実行しているという点にある。したがって、1つが失われても、単に別のサーバへラウンドロビン方式でルーティングするだけだ。」

Slurmにはこの組み込みのシンプルさには及ばないため、ワット氏もAI推論のようなユーザー向けのワークロードにはSlurmの使用を推奨していない。モデルトレーニングのようなバッチワークロードでダウンタイムが発生した場合、顧客はチェックポイント機能を使って作業を復旧できるが、エンドユーザには影響が及ばない。AI推論のようなリアルタイムでユーザー向けのアプリケーションにおいて、Slurmで99.999%の可用性を実現しようとすれば、非常に困難だろう。

「問題は、[Slurm下のノードが]ダウンした場合、Kubernetesほど洗練されたフェイルオーバー機構がSlurmには備わっていないことだ」とワット氏は述べた。「そのため、それを実現しようとすると、Slurm環境周りで不自然なことをすることになる。適切なツールを使っていれば、システムを稼働させ続けるために、まるでルーブ・ゴールドバーグ・マシンのような複雑な仕組みを構築する必要はないはずだ。」

Slinky：両者の長所を兼ね備えたソリューションか？

HPCおよびAIコミュニティの一部では、KubernetesとSlurmを併用する方法を模索している。Slurmの下でKubernetesを実行することについての議論もあるが、ほとんどの議論は逆の方向、つまりKubernetesの下でSlurmを実行すること（これによりSlurmはホストの可用性の恩恵を受けられる）に向けられている。

SchedMDは、Kubernetes内でSlurmを実行することを目指す「Slinky」というプロジェクトを開発した。このプロジェクトにより、Slurmコンポーネントをコンテナイメージとしてパッケージ化できるほか、Slurmコンポーネントのデプロイ、スケーリング、ライフサイクル管理を処理するKubernetesオペレーターも提供される。

エヌビディアのエンジニアたちは先月、ブログ記事でSlinkyについて論じた。テストの結果、エヌビディアのエンジニアたちは、Slinkyが最大8,000個のGPUを搭載したクラスタ上で、AIトレーニングと推論の両方のワークロードを実行し、その実力を証明したと述べている。彼らは、ベンチマークテストの結果、Slinky環境は「コンテナ化されていないSlurmデプロイメントと同等のパフォーマンスを発揮し、Slinkyが動作するKubernetesレイヤーからの測定可能な影響は見られない」と述べている。

Red Hatの関係者もSlinkyに関心を示している。現在はGitHub上の単なるオープンソースプロジェクトに過ぎないが、商業的な関心が続けば、将来的には商用サポートが提供される可能性も出てくるだろう。