Together AI、生産向けGPUクラスターを強化
Together AI は、生産環境向け GPU クラスターの信頼性と制御機能を強化する新機能を発表し、大規模モデルの安定運用を支援します。
キーポイント
生産環境向けの信頼性向上
大規模な GPU クラスターにおける障害発生時の自動復旧や、ジョブの継続性を確保する機能を実装し、サービス停止リスクを低減します。
運用制御機能の強化
開発者がリソース割り当てやスケーリングをより細かく制御できるツールを提供し、コスト効率とパフォーマンスの最適化を可能にします。
LLM 学習・推論への対応
大規模言語モデル（LLM）のトレーニングや高負荷な推論タスクにおいて、安定した計算リソース供給を実現するための基盤整備を進めています。
重要な引用
Reliability and control for production GPU clusters
Together AI announced new features to improve reliability and control for production GPU clusters.
影響分析・編集コメントを表示
影響分析
この発表は、AI モデルの開発・運用が実験段階から本格的な生産環境へ移行する中で、インフラの安定性と管理性の重要性が高まっていることを示しています。Together AI が提供する制御機能は、企業ユーザーが大規模 GPU クラスターを安全かつ効率的に活用するための基盤となり、LLM 開発のスピードと信頼性を向上させる可能性があります。
編集コメント
大規模モデルの開発現場では、インフラの安定性がプロジェクトの成否を分ける重要な要素となっています。Together AI の今回の機能強化は、単なる性能向上ではなく、実運用におけるリスク管理とコスト最適化に焦点を当てた現実的な進化と言えます。
ここ数週間で、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 のスレッドで行っていた作業を置き換えるものです。
*Fig: クラスターの概要ページ。全体の健康状態と利用状況を確認できます*
*Fig: ノード詳細ページ。個々のノードの情報と操作が可能です*
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）
フィードバックはこちらからご提供ください。
カスタマーオフィスアワーの予約はこちらから。
ドキュメントはこちらをご覧ください。
原文を表示
We’ve spent the last several weeks shipping a set of changes to Together GPU Clusters aimed at the operational reality of running training and inference at scale: hardware fails, schedulers leak, and teams outgrow the single-admin-kubeconfig workflow they started with. This post walks through what we shipped, why we built it the way we did, and what it means for the workloads you’re running on Together today.
The changes group into two themes. The first is platform health: passive health checks, auto node repair, and Slinky 1.0, focused on catching and recovering from the failure modes that actually take down jobs. The second is operational control: a new cluster details view, external OIDC, startup scripts, and an acceptance-test opt-out, focused on giving your team the visibility, access, and customization hooks needed to run clusters as your organization grows.
Catching and fixing failures as they happen
If you’ve run a multi-day training job on a large cluster, you know the pattern. A GPU falls off the PCIe bus. An Xid error takes a node out of rotation. Thermal throttling silently caps a job’s throughput and you don’t notice until the loss curve flattens.
These are steady-state failure modes at scale. What matters is how quickly you catch them and how cleanly you recover.
We already ran active health checks, synthetic tests that exercise the hardware against a known-good baseline. Active checks are useful at provisioning time and on idle nodes. Passive checks extend that coverage to failures that appear while real workloads are running.
So we built passive health checks, which work like alerts and run continuously across every node in your cluster, observing real workloads, logs, and metrics to surface degradation as it happens. The coverage list today includes GPUs falling off the bus, thermal throttling, Xid errors, Slurm node drains on failure, and an expanding set of hardware and software failure signals.
The checks observe live workloads with near-zero overhead on running jobs. Learn more about health checks here.
Detection on its own is just a dashboard, so we paired passive checks with auto node repair. When our monitoring system detects a node-level issue, it generates a recommended remediation and surfaces it for an operator to review. There are four repair actions, mapped automatically based on the failure signature:
- Reboot: In-place restart that preserves local data. The default for transient issues
- Reprovision: Rebuilds the node from a clean image and clears local data
- Failover: Moves the workload to a fresh bare-metal node and clears local data
- Remove: Pulls the node out of the pool and sends it to RMA
We believe in automation with a human touch: Your training checkpoints and inference replicas are too valuable to risk on automated drains. Our 'human-in-the-loop' approach keeps you in control — the system detects and recommends, you approve, and Together handles the graceful recovery. It’s the perfect balance of intelligence and safety. We’re already building fully automated node-repair options for specific failure modes, but for now, we prioritize keeping your production workloads uninterrupted. Learn more about node auto repair here.
The result? You’ve traded hours of support tickets for minutes of in-product workflow. From detection to resolution, you’re back in the pool faster than ever.
Together Slurm-on-K8s 2.0: The future of Slurm on Kubernetes
Running Slurm on Kubernetes shouldn't feel like a constant battle against crashing daemons, zombie processes, or scheduler drift. We’ve rebuilt our Slurm-on-Kubernetes stack from the ground up, based on our fork of OSS project Slinky, to make those 'scale-at-failure' headaches a thing of the past.
Here’s what our upgraded stack brings to your cluster:
Self-healing worker daemons: Transient failures are inevitable, but they shouldn't take down your node. Our new stack supervises workers, auto-restarting them in place so long training runs stay resilient.
No more zombie processes: Forget the days of orphaned processes clogging your PID tables and blocking new jobs. Our stack automatically reaps orphans, ensuring your nodes stay clean and ready for work, every single time.
Durable job accounting: sacct history used to live on ephemeral storage, which meant a pod restart could wipe your entire accounting database. We've moved accounting to durable, PVC-backed storage, so restarts and reschedules no longer touch your data. Billing reconciliation and post-hoc job analysis stay intact across the lifecycle of the cluster.
Reliable process cleanup: When jobs ended, daemonized child processes used to slip out from under Slurm's view and stay running — holding GPU memory and /dev/shm segments hostage between runs, sometimes for days until someone cleaned them up by hand. The new stack tracks every descendant of a job at the kernel level and cleans them all up reliably at job end. The next job on the node starts on a clean machine every time.
Accurate GPU state after reschedules: After a pod reschedules, Slurm's view of which GPUs existed used to drift from reality — stale GPU identifiers from the previous incarnation would mismatch the real hardware, and affected GPUs would silently drop out of the schedulable pool. The new stack rebuilds Slurm's GPU view fresh on every node start, so the schedulable pool always matches the hardware actually in the node.
Beyond reliability, our new stack exposes DCGM metrics in your cluster's Grafana dashboards, so you get fine-grained per-cluster GPU utilization visibility out of the box.
All newly provisioned Slurm clusters run on the latest stack by default. If you're on an existing managed Slurm cluster, we can migrate you in place at no cost via. a maintenance window — contact your account team to schedule. Learn more about Slurm-on-K8s GPU Clusters here.
Operational control
Reliability is half the picture. As clusters grow across teams, access, visibility, and customization become operational problems in their own right. More people need access, with different permissions. Operators need to know what’s happening on the cluster without SSHing into nodes. Workflows need customization without turning every change into a support ticket. Below are the latest features that we built to enable our users to adapt to their most critical needs.
A new cluster details view
We rebuilt the cluster overview page around the three questions operators actually ask about a cluster:
- Is it healthy?
- Is it being used?
- What's happened to it recently?
The new view surfaces node health at a glance: healthy, booting, unhealthy, pending, and paused. It also shows live usage metrics across all GPU nodes, including utilization, memory, and network bandwidth, with drill-down to Grafana for deeper analysis. The same page includes an event timeline showing node state transitions across the cluster and the cluster’s full configuration in one place: region, GPU type, driver version, networking, OS image, and billing rate.
Three new tabs sit alongside the overview:
- Nodes to give a detailed list and grid view with utilization data, health signal, and node operations like repair/run health-check and ssh commands.
- Health checks give you the historical timeline of active and passive check events for the cluster.
- Repair gives you the same historical view for node repair actions. Both exist for the incident retro question, “what actually happened on this cluster last week?”, and they replace what used to be a Slack thread with us.
External OIDC for Kubernetes RBAC
If your team accesses the Kubernetes API today, you’re probably sharing the admin kubeconfig. That works for one operator and breaks down quickly past that. Teams need per-user audit trails, per-user revocation, least-privilege access, and a cleaner path for joiners and leavers.
We’ve added External OIDC support for K8s RBAC to solve for this. You can now configure a cluster to authenticate against your existing identity provider (IdP), including Google, Okta, Auth0, Microsoft Entra ID, or another OIDC-compatible provider. Each team member runs kubectl with their own identity, the API server validates their token against your IdP, and standard Kubernetes RBAC controls what they can do via ClusterRoleBindings and RoleBindings. You get per-user Kubernetes access, revocation through your IdP, audit trails tied to individual users, and standard Kubernetes RBAC for least-privilege access.
For teams managing access at any meaningful scale, this is a significant unlock. The admin kubeconfig becomes a break-glass tool. Joiners and leavers are handled in your IdP, where they should be. And the audit trail of who did what on the cluster comes from a system your security team already trusts.
External OIDC must be configured at cluster creation time. See the OIDC setup guide for the full flow, including provider-specific notes for Auth0, Okta, and Google. Together OIDC support for Slurm and Kubernetes clusters is coming soon.
Startup scripts for cluster customization
Most production clusters need some kind of setup that isn’t in the base image: internal packages, scratch space prep, monitoring agents, Slack notifications when a job finishes. We were watching customers SSH into every node to do this by hand, or file support tickets and wait on us. Startup scripts move that setup into cluster configuration as a self-serve capability.
Startup scripts let you customize Slurm worker nodes, login nodes, and the controller via shell scripts that fire at specific lifecycle events:
- At node boot: install packages, configure tooling, run any setup that needs to happen before the node accepts work
- At job start: stage data, prepare scratch space, configure the per-job environment
- At job end: clean up scratch files and stray processes, send Slack notifications, kick off downstream pipelines
Scripts are configured in the Together Cloud console and can be applied to new clusters at creation time with no rebuild required. The result: The customizations you’d otherwise file a ticket for, or run by hand, are now declared once and applied automatically across the cluster. We even validate the scripts for errors so you do not face silent failures later. Learn more about how to set up startup scripts based on customizationshere.
Acceptance testing, opt-in for larger and longer-running clusters
At Together AI, we serve both large-scale production training/inference workloads as well as short burst experimentation or single-node research clusters. For these smaller or short-lived clusters, we skip the acceptance test battery by default, which validates GPU health, networking, and storage, and go straight to availability. For most clusters, faster time-to-availability is the better default: less waiting and faster time to value, especially given we constantly run health checks on idle nodes in our fleet.
For larger clusters or long-running training jobs, the calculus flips. Catching a bad node at provisioning time is much cheaper than catching it on epoch 47, and the cost of validation is small relative to the lifetime of the cluster. For these cases, we recommend enabling acceptance testing at cluster creation.
This is a deliberate tradeoff, and we surface it in the UI: acceptance tests are disabled by default for faster provisioning; for multi-GPU training or long-running production clusters, we recommend enabling it at cluster creation time.
What changes operationally
Taken together, these changes give operators a shorter path from “something is wrong” to “the cluster is usable again,” with health signals, repair actions, access controls, and cluster history in the product.
Researchers and ML engineers get greater reliability and resilience for their jobs from hardware faults and clearer signals when something degrades. Platform teams get a better control surface for access, repair, customization, and incident review. Operators get durable accounting data, per-cluster GPU utilization metrics, and a cluster view that answers the basic questions first: is it healthy, is it being used, and what happened recently?
What’s next
The themes you’ll continue to see from us: more failure modes covered by passive health checks, more remediation actions safe to automate end-to-end, deeper observability into what’s actually happening on your nodes, and continued investment in the Slurm and Kubernetes stacks that most large training jobs depend on.
If you’re running training or inference workloads on Together GPU Clusters and any of this is relevant to what you’re hitting, get in touch. We’re the team that built it, and we’d like to hear what’s working and what still needs to be easier.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み