Together AI、生産向けGPUクラスターを強化

ここ数週間で、Together GPU Clusters に一連の変更を加えてきました。その目的は、大規模なトレーニングや推論運用における現実的な課題への対応です。ハードウェアの故障、スケジューラーのメモリリーク、そして単一の管理者用 Kubeconfig ワークフローでは対応しきれなくなるチームの成長など、現場で直面する問題が背景にあります。

今回の変更は、大きく 2 つのテーマに整理できます。1 つ目はプラットフォームの健全性です。パッシブな健康診断、ノードの自動修復、そして Slinky 1.0 の導入により、実際にジョブを停止させるような障害モードを検知し、復旧する仕組みを整えました。

2 つ目は運用上のコントロールです。新しいクラスタ詳細ビュー、外部 OIDC 連携、起動スクリプト、そして受入テストのオプトアウト機能など、組織が成長してもクラスタを円滑に運営するために必要な可視性、アクセス権限、カスタマイズ機能を強化しました。

発生した障害を即座に検知・修復する

大規模なクラスタで数日かかるトレーニングジョブを実行した経験があれば、そのパターンはご存知でしょう。GPU が PCIe バスから外れる、Xid エラーによってノードが回転リストから除外される、サーマルスロットリングによりジョブのスループットが静かに制限され、損失曲線が平坦化するまで気づかないといったケースです。

これらはスケールした環境における定常的な障害モードです。重要なのは、いかに早く検知し、いかにきれいに復旧できるかという点にあります。

すでにアクティブヘルスチェックについては紹介済みです。これは、既知の正常状態を基準にハードウェアを実際に動作させてテストする合成検査のことです。この手法は、ノードのプロビジョニング時やアイドル状態にあるノードにおいて特に有効です。

そこで私たちは、パッシブヘルスチェックも構築しました。これはアラートと同様に動作し、クラスター内のすべてのノードで常時実行されます。実際のワークロードやログ、メトリクスを監視することで、問題が発生した瞬間に検出します。

現在の対応範囲には、バスからの GPU 接続断、サーマルスロットリング（熱による性能低下）、Xid エラー、障害発生時の Slurm ノードの停止、そして拡大し続けるハードウェアおよびソフトウェアの故障シグナルが含まれています。これらのチェックは、実行中のジョブへのオーバーヘッドをほぼゼロに抑えながら、ライブのワークロードを観察します。

ヘルスチェックの詳細については こちら をご覧ください。

図：ノードの修復推奨とクラスタの修復履歴を表示する「Repair」タブ

検知機能だけでは単なるダッシュボードに過ぎません。そこで、受動的なチェックと自動ノード修復を組み合わせました。

モニタリングシステムがノードレベルの問題を検出すると、推奨される対応策を生成し、オペレーターが確認できる形で表示します。故障のシグネチャに基づき、自動的に以下の 4 つの修復アクションが割り当てられます。

• Reboot（再起動）: ローカルデータを保持したままローカルで再起動します。一時的な問題に対するデフォルトの対応です。
• Reprovision（再プロビジョニング）: クリーンなイメージからノードを再構築し、ローカルデータをクリアします。
• Failover（フェイルオーバー）: ワークロードを新しいベアメタルノードへ移行し、ローカルデータをクリアします。
• Remove（削除）: ノードをプールから引き抜き、RMA（返品・修理）処理を行います。

私たちは「人間の手を加えた自動化」を信じています。トレーニングのチェックポイントや推論用のレプリカはあまりにも貴重で、自動的な排水処理に任せるにはリスクが大きすぎます。「ヒューマン・イン・ザ・ループ」アプローチを採用することで、常にあなたがコントロールを握り続けます。システムが検知して推奨し、あなたが承認する。Together がその後の優雅な回復処理を担当します。これは、知性と安全性の完璧なバランスです。

特定の故障モードについては、すでに完全自動的なノード修復オプションの開発を進めていますが、当面は生産環境でのワークロードを中断させないことを最優先しています。ノードの自動修復の詳細はこちらをご覧ください here。

その結果、サポートチケットに費やしていた数時間が、製品内のワークフローで数分に短縮されました。検知から解決まで、以前よりもはるかに早くプールに戻ることができます。

Together Slurm-on-K8s 2.0：Kubernetes 上で動くスラムの未来

Kubernetes 上で Slurm を動かす際、常時クラッシュするデーモンやゾンビプロセス、スケジューラのズレといった問題と戦い続ける必要はありません。私たちは、オープンソースプロジェクト「Slinky」をフォークして基盤とし、Slurm-on-Kubernetes のスタックをゼロから再構築しました。これにより、「障害発生時にスケーリング」という頭痛の種は過去のものになります。

アップグレードされたスタックがクラスターにもたらす主な改善点は以下の通りです。

自己修復機能を持つワーカーデーモン: 一時的な障害は避けられませんが、それでノード全体をダウンさせる必要はありません。新しいスタックではワーカーを監視し、位置を維持したまま自動で再起動します。これにより、長時間実行されるトレーニングジョブも堅牢に動作します。

ゾンビプロセスの解消: PID テーブルを埋め尽くして新規ジョブをブロックする孤立したプロセス（ゾンビ）に悩まされる時代は終わりました。スタックが自動的にこれらのプロセスを回収するため、ノードは常にクリーンな状態で作業準備が整います。

堅牢なジョブ管理記録: 従来、sacct の履歴は一時的なストレージ上に保存されていたため、ポッドの再起動で会計データベース全体が消去されるリスクがありました。現在は、永続ボリューム（PVC）に裏打ちされた耐久性のあるストレージへ移行しました。これにより、再起動や再スケジュールを行ってもデータが失われることはありません。クラスターのライフサイクルを通じて、請求書の照合や事後のジョブ分析も確実に維持されます。

信頼性の高いプロセスクリーンアップ:

ジョブ終了時に、デーモン化された子プロセスが Slurm の管理範囲から漏れ出し、実行され続けることがありました。これにより、GPU メモリや /dev/shm セグメントが次のジョブ開始まで数日間にわたって占有される事態も発生していました。

新しいスタックでは、カーネルレベルでジョブの子プロセスをすべて追跡し、ジョブ終了時に確実に全プロセスをクリーンアップします。これにより、ノード上の次回のジョブは常にクリーンな状態から開始されます。

再スケジューリング後の正確な GPU 状態:

Pod の再スケジューリング後、Slurm が認識する GPU の情報が現実とズレてしまう問題がありました。以前のインスタンスからの古くなった GPU 識別子が実際のハードウェアと一致せず、影響を受けた GPU が気づかれずにスケジューリング対象から除外されるケースが起きていたのです。

新しいスタックでは、ノード起動時に Slurm の GPU 認識情報を再構築します。これにより、利用可能な GPU のリストは常にノード内の実際のハードウェアと一致するようになります。

信頼性の向上に加え、新しいスタックではクラスター内の Grafana ダッシュボードで DCGM メトリクスを直接取得できます。これにより、クラスターごとの GPU 利用率を細かく可視化できる機能が標準で提供されます。

新たにプロビジョニングされる Slurm クラスターはすべて、デフォルトで最新のスタック上で動作します。既存のマネージド Slurm クラスターをご利用中の場合は、メンテナンスウィンドウを利用して無償で在席移行が可能です。スケジュール調整についてはアカウントチームまでお問い合わせください。

Slurm-on-K8s GPU Clusters に関する詳細はこちら here。

オペレーション制御

信頼性は重要な要素の一つですが、それだけでは不十分です。チーム間でのクラスター規模が拡大するにつれ、アクセス権限の管理、可視性の確保、カスタマイズの柔軟性といった課題が、オペレーション上の新たな問題として浮上します。

より多くのユーザーが異なる権限レベルで利用できるようになる一方で、オペレーターは各ノードに SSH でログインしなくても、クラスター内で何が起きているかを把握できる必要があります。また、ワークフローのカスタマイズを求められる際にも、あらゆる変更がサポートチケット化されるような非効率なプロセスを避けたいものです。

ここでは、ユーザーの最も重要なニーズに対応できるよう、新たに実装した機能をご紹介します。

新しいクラスター詳細ビュー

オペレーターが実際にクラスターについて抱く 3 つの核心的な問いに答えるべく、クラスターの概要ページをゼロから再構築しました。

• 健全性は保たれているか？
• 現在どのように利用されているか？
• 直近でどのような変化があったか？

新しいビューでは、ノードの状態が一目で把握できるようになりました。状態は「正常（healthy）」「起動中（booting）」「不具合あり（unhealthy）」「待機中（pending）」「一時停止中（paused）」のいずれかで表示されます。

また、すべての GPU ノードにおけるリアルタイムの利用状況も確認可能です。利用効率、メモリ使用量、ネットワーク帯域幅などのメトリクスが表示され、より詳細な分析が必要な場合は Grafana へのドリルダウンもサポートしています。

このページには、クラスター全体のノード状態遷移を示すイベントタイムラインに加え、クラスターの構成情報も一元化して表示されます。リージョン、GPU タイプ、ドライバーバージョン、ネットワーク設定、OS イメージ、課金レートなどがすべてここに集約されています。

概要ページの隣には、3 つの新しいタブが追加されました。

ノード管理画面では、利用状況データやヘルスシグナルを詳細にリスト表示・グリッド表示できます。また、修復処理や健康状態チェックの実行、SSH コマンドの発行といったノード操作も可能です。

ヘルスチェック機能を使えば、アクティブおよびパッシブなチェックイベントの履歴タイムラインを確認できます。同様に、修復機能でもノード修復アクションの履歴を閲覧可能にしています。これらは「先週このクラスターで実際に何が起きたのか」というインシデント後の振り返り質問に対応するためのもので、以前は Slack のスレッドで行っていた作業を置き換えるものです。

Kubernetes RBAC 用の外部 OIDC の導入

現在、チームが Kubernetes API にアクセスしている場合、管理者用 kubeconfig を共有しているケースが多いでしょう。これはオペレーターが一人だけなら機能しますが、人数が増えるとすぐに破綻します。各ユーザーごとの監査証跡の確保、権限の即時剥奪、最小権限の原則に基づくアクセス制御、そして新規参入者や退社者の管理をスムーズに行うための明確な道筋が必要です。

この課題を解決するため、Kubernetes RBAC（ロールベースアクセス制御）の外部 OIDC（OpenID Connect）サポートを追加しました。これにより、既存のアイデンティティプロバイダー（IdP）——Google、Okta、Auth0、Microsoft Entra ID、あるいは他の OIDC 対応プロバイダーなど——に対してクラスター認証を構成できるようになります。

各チームメンバーは各自の ID を持つ kubectl を実行し、API サーバーがそのトークンを IdP で検証します。その後、ClusterRoleBindings や RoleBindings を通じて、標準的な Kubernetes RBAC がユーザーの権限を制御します。これにより、ユーザーごとのアクセス管理、IdP 経由での即時権限剥奪、個人単位で紐づく監査ログ、そして最小限の権限（least-privilege）を実現する標準的な RBAC を利用可能になります。

意味のある規模でアクセス管理を行うチームにとって、これは大きな前進です。管理者用の kubeconfig は緊急時のみ使用する「非常用ツール」として位置づけられます。新規参入者や退社者の管理は、本来あるべき場所である IdP で一元処理されます。また、クラスター上で誰が何を行ったかという監査ログも、セキュリティチームがすでに信頼しているシステムから取得できます。

外部 OIDC の設定は、クラスターの作成時に完了させる必要があります。Auth0、Okta、Google 向けのプロバイダー固有の注意点を含む完全な手順については、OIDC セットアップガイドをご覧ください。Slurm および Kubernetes クラスター向けに Together OIDC をサポートする機能も近日公開予定です。

クラスターのカスタマイズ用起動スクリプト

本番環境のクラスターでは、基本イメージに含まれていない設定が必要になるケースがほとんどです。社内パッケージの導入やスクラッチ領域の準備、監視エージェントの設置、ジョブ完了時の Slack 通知などです。

これまで顧客は、手動で各ノードに SSH 接続して作業を行っていたか、サポートチケットを提出して対応を待つかのどちらかでした。スタートアップスクリプトを導入すれば、こうした設定をクラスター構成の一部としてセルフサービス化できます。

スタートアップスクリプトを使えば、特定のライフサイクルイベントで実行されるシェルスクリプトを通じて、Slurm のワーカーノード、ログインノード、コントローラーをカスタマイズできます：

• ノード起動時：パッケージのインストールやツールの設定、ノードが作業を受け付ける前に行うべきセットアップを実行
• ジョブ開始時：データのステージング、スクラッチ領域の準備、ジョブごとの環境構成
• ジョブ終了時：スクラッチファイルや残留プロセスのクリーンアップ、Slack への通知送信、下流パイプラインの起動

スクリプトは Together Cloud コンソールで設定でき、新しいクラスター作成時に適用可能です。再構築の必要はありません。その結果、これまでサポートチケットとして提出するか手動で行っていたカスタマイズを、一度定義するだけでクラスター全体に自動適用できるようになります。また、スクリプトにはエラー検証機能も備わっており、後で気づかないうちに失敗する事態を防ぎます。

カスタマイズに応じたスタートアップスクリプトの設定方法については、こちらをご覧ください。

「Slurm 起動スクリプト」：コンソールでの起動スクリプト設定大規模・長時間稼働クラスター向けのオプトイン型受入テスト

Together AI では、大規模な本番環境でのトレーニングや推論ワークロードだけでなく、短期間の実験用や単一ノードの研究用クラスターも提供しています。小規模または短寿命のクラスターについては、デフォルトで GPU の健全性、ネットワーク、ストレージを検証する受入テスト（アセプタンス・テスト）をスキップし、すぐに利用可能な状態にします。多くのケースでは、素早く利用可能になることが最善のデフォルトです。待機時間を減らし、価値を提供するまでの時間を短縮できます。さらに、当社のファリット内にあるアイドル状態のノードに対して常時ヘルスチェックを実行しているため、このアプローチは特に有効です。

一方、大規模クラスターや長時間稼働するトレーニングジョブの場合は判断が逆転します。プロビジョニング段階で不良ノートを検出することは、47 番目のエポック（学習サイクル）になってから発見するよりもはるかに安価です。また、検証にかかるコストも、クラスターの全体的な稼働期間に比べればごくわずかなものです。こうしたケースでは、クラスター作成時に受入テストを有効化することを推奨します。

これは意図的なトレードオフであり、UI 上でその旨を明確に示しています。素早いプロビジョニングのためにデフォルトでは受入テストは無効になっていますが、マルチ GPU トレーニングや長時間稼働する本番クラスターを利用する場合は、作成時に有効化することを推奨します。

運用面での主な変更点

これらの改善により、オペレーターは「何か問題が発生した」状態から「クラスタが再利用可能になる」までの時間を大幅に短縮できます。製品には、ヘルスシグナルの監視、修復アクションの実行、アクセス制御、そしてクラスタの履歴管理といった機能が統合されています。

研究者や ML エンジニアにとっては、ハードウェア障害に対する信頼性と回復力が向上し、パフォーマンス低下時の兆候も明確になります。プラットフォームチームは、アクセス管理、修復作業、カスタマイズ、インシデントレビューを統括するための制御面が強化されます。オペレーターには、永続的な課金データやクラスタごとの GPU 利用率メトリクスが提供され、さらに「健全か」「使用中か」「直近で何があったか」といった基本質問に即座に答えられるクラスタビューも用意されています。

これからの展望

今後とも、私たちは以下のテーマに取り組んでいきます。パッシブヘルスチェックでカバーする障害モードの拡大、エンドツーエンドで安全に自動化できる修復アクションの増加、ノード上で実際に何が起こっているかを深掘りできる観測性の強化です。また、大規模なトレーニングジョブが依存している Slurm と Kubernetes の両スタックへの投資も継続していきます。

Together GPU Clusters でトレーニングや推論ワークロードを実行中で、今回の内容が現状の課題に関連する場合は、ぜひご連絡ください。私たちは開発チームそのものですので、うまくいっている点や、さらに改善すべき点について率直な声を聞きたいと考えています。

Together GPU クラスターの新機能：本番環境向けに信頼性と制御性を強化（続編 12/12）

フィードバックはこちらからご提供ください。

フィードバックを送る

カスタマーオフィスアワーの予約はこちらから。

予約する

ドキュメントはこちらをご覧ください。

ドキュメントを読む