mcpField
T
together-gpu-clusters

together-gpu-clusters

github.com/togethercomputerクラウド・DevOps3984 回インストール2 週間前に更新
リポジトリ

together-gpu-clusters について

together-gpu-clusters は、クラスター基盤を制御する必要がある場合に、Together AI GPU クラスターを計画・運用するスキルです。容量、オーケストレーション、ストレージ、認証情報、スケーリング、ノードの状態を扱います。

主な機能

  1. 01GPU クラスターの作成と管理
  2. 02オンデマンドまたは予約容量の選択
  3. 03Kubernetes または Slurm の選択
  4. 04共有ストレージと認証情報の管理
  5. 05クラスターの拡縮とノード状態の確認

活用シーン

  1. 01分散トレーニングの実行
  2. 02マルチノード推論の運用
  3. 03HPC または Slurm ワークロードの実行
  4. 04カスタム Kubernetes ジョブのデプロイ

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/togethercomputer/skills --skill together-gpu-clusters

インストール後、Claude Code で/together-gpu-clustersを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
api-reference.md
cli.md
cluster-management.md
pricing-and-discovery.md
scripts/
manage_cluster.py
manage_cluster.ts
manage_storage.py

詳細

Together GPU クラスター

概要

ユーザーがマネージド推論製品ではなく、インフラストラクチャを制御する必要がある場合は、Together AI GPU クラスターを使用します。

一般的な用途：

  • 分散トレーニング
  • マルチノード推論
  • HPC または Slurm ワークロード
  • カスタム Kubernetes ジョブ
  • 接続された共有ストレージとクラスターのライフサイクル管理

このスキルが適している場合

  • クラスターをプロビジョニングし、継続的に管理する
  • オンデマンド容量と予約容量を選択する
  • オーケストレーションレイヤーとして Kubernetes または Slurm を選択する
  • 共有ボリュームと認証情報を管理する
  • ノードのヘルス状態をスケールアップ、スケールダウン、またはトラブルシューティングする

別のスキルに引き継ぐ場合

  • マネージド単一モデルホスティングには together-dedicated-model-inference を使用します
  • クラスター全体を所有せずにコンテナ化された推論を行う場合は together-dedicated-containers を使用します
  • 短時間のリモート Python 実行には together-sandboxes を使用します
  • 生のクラスター操作ではなく、マネージドトレーニングジョブには together-fine-tuning を使用します

クイックルーティング

ワークフロー

  1. ワークロードで本当にクラスター単位の制御が必要かどうかを判断します。
  2. 実行時間とベースラインの使用率に基づいて、オンデマンドと予約のいずれかの課金方式を選択します。
  3. オーケストレーション要件とチームのツールに基づいて、Kubernetes と Slurm のいずれかを選択します。
  4. リージョン、GPU タイプ、ドライバーバージョン、共有ストレージのプランを選択します。
  5. まずプロビジョニングを行い、その後、アクセス認証情報、ワークロードのデプロイ、スケーリング、ヘルスチェックを設定します。

重要なルール

  • Python スクリプトには Together v2 SDK（together>=2.0.0）が必要です。ユーザーが古いバージョンを使用している場合は、まずアップグレードする必要があります：uv pip install --upgrade "together>=2.0.0"。
  • ユーザーが生のインフラを直接制御する必要があると明示していない限り、マネージド製品を優先してください。
  • ストレージのライフサイクルとクラスターのライフサイクルは別々に扱ってください。ボリュームはクラスターより長く存続することがあります。
  • 新しい共有ストレージを使ってクラスターを作成する場合は、ボリュームを別途作成して volume_id でアタッチするよりも、インラインの shared_volume を優先してください。別途作成したボリュームは、クラスターとは異なるデータセンターパーティションに配置されることがあり、その場合、ボリュームが利用可能と表示されていても「データセンターに存在しない」というエラーが発生します。
  • GPU の在庫切れ（409「在庫切れ」）はよく発生します。必ず最初に list_regions() を呼び出し、複数のリージョンを試せるよう準備してください。
  • リージョンのレスポンスに記載されるのは、サポートされる構成であり、価格や在庫の保証ではありません。レスポンスの順序やハードウェアの世代から、最安の GPU を推測してはいけません。GPU クラスターの料金表を開き、数値のオンデマンド料金を比較してください。
  • GPU クラスターには最低 8 GPU が必要です。1 時間あたりの見積もりでは、表示されている GPU 1 基・1 時間あたりの料金に、少なくとも 8 を掛けてください。
  • ON_DEMAND には 1 時間の期間を指定するフラグがありません。1 時間の利用を計画する場合は、--duration-days を省略し、許可を得た場合にのみクラスターを作成して、想定した利用時間の終了後に削除してください。ユーザーがプロビジョニングせずにコマンドを求めている場合は、コマンドを表示するだけにし、実行しないでください。
  • API では、結合された driver_version 文字列に加え、cuda_version と nvidia_driver_version を個別のフィールドとして指定する必要があります。Python SDK では extra_body 経由で渡してください。
  • 認証情報の取得はプロビジョニングの一部です。ユーザーがすぐにワークロードを実行する必要がある場合は、クラスターを作成しただけで終わらせないでください。
  • Slurm と Kubernetes では運用パターンが大きく異なります。独自に対応を進める前に、クラスター管理のリファレンスを読んでください。
  • クラスター操作を繰り返す場合は、リクエストの形式を一から組み立て直すのではなく、スクリプトを使い始めてください。
  • Slurm の起動スクリプト（ワーカー／ログインの init、ワーカー／コントローラーの prolog と epilog、追加の slurm.conf）は Slinky v1.0 専用です。ワーカーの prolog または epilog がゼロ以外のコードで終了すると、ノードはドレイン状態になります。また、prolog／epilog 内で Slurm コマンド（squeue、scontrol、sacctmgr）を呼び出すと、スケジューラーがデッドロックすることがあります。

リソース一覧

公式ドキュメント

コメント

Markdown 対応