dstack

dstack

概要

dstack は、フリートを介して GPU クラウド、Kubernetes、オンプレミス環境全体でワークロードをプロビジョニングし、オーケストレーションします。

このスキルを使用する場面：

• dstack 上で開発環境、タスク、サービスを実行または管理する
• *.dstack.yml 設定を作成、編集、適用する
• フリート、ボリューム、ゲートウェイを管理し、利用可能なオファーを確認する

仕組み

dstack は、次の3つの中核コンポーネントを通じて動作します。

1. dstack サーバー - ローカル、リモート、または dstack Sky（マネージド）で実行できます
2. dstack CLI - 設定を適用し、フリート、実行、ログ、イベント、ボリューム、ゲートウェイ、オファーを管理または調査します。~/.dstack/config.yml に保存されたプロジェクト設定を使用し、dstack project で管理できます
3. dstack 設定ファイル - .dstack.yml で終わる YAML ファイルです

dstack apply はプランを表示し、設定の変更を送信します。実行設定の場合、デフォルトでは実行が running に達するとアタッチします。SSH アクセスを設定し、宣言されたポートを転送して、ログをストリーミングします。-d を指定すると、送信後に終了します。

エージェントのクイックフロー（デタッチ実行）

1. プランを表示：echo "n" | dstack apply -f <config>
2. プランに問題がなく、ユーザーが確認した場合は、デタッチして適用：dstack apply -f <config> -y -d
3. 実行を確認：dstack run get <run-name> --json
4. ポート付きの開発環境またはタスクが実行中の場合は、アタッチして IDE リンク／ポート／SSH エイリアスを表示します（エージェントはバックグラウンドでアタッチを実行します）。リンクを開くよう依頼します
5. サンドボックス内でのアタッチに失敗した場合は、権限の昇格を要求します。承認されない場合は、ローカルで dstack attach を実行して出力を共有するようユーザーに依頼します

重大：存在しない dstack CLI コマンドや YAML 構文を絶対に提案しないでください。

• ここに記載されている、または --help で確認した CLI コマンドと YAML 構文のみを使用してください
• コマンドやその構文が不明な場合は、リンクを確認するか、--help を使用してください

次のことは絶対に行わないでください：

• ここに記載されていない、または --help に表示されていない CLI フラグを作り出す
• YAML のプロパティ名を推測する。設定リファレンスのリンクで確認してください
• 自動化された環境で、-d を付けずに実行に対して dstack apply を実行する（無期限にブロックされます）
• 根本的なエラーに対処せず、失敗したコマンドを再試行する
• 表形式の CLI 出力を要約したり、再フォーマットしたりする。そのまま表示してください
• -y フラグが使用できる場合に echo "y" | を使用する
• エラーがないか出力を確認せずに、コマンドが成功したと判断する

エージェント実行ガイドライン

出力の正確性

• CLI 出力を絶対に再フォーマット、要約、言い換えしないでください。 表、ステータス出力、エラーメッセージは、返されたとおりに表示してください。
• コマンドの結果を表示する場合は、書式を保つためにコードブロックを使用してください。
• 出力が長さによって切り詰められた場合は、その旨を明確に示してください（例：「出力は切り詰められています。完全な出力には X 件のエントリがあります。」）。

実行前の確認

• CLI フラグや YAML プロパティに不明な点がある場合は、まず dstack <command> --help を実行してください。
• フラグを推測したり、作り出したりしないでください。確認用コマンドの例：

  dstack --help                               # List all commands
  dstack apply -h <configuration type>        # Flags for apply per configuration type (dev-environment, task, service, fleet, etc)
  dstack fleet --help                         # Fleet subcommands
  dstack ps --help                            # Flags for ps
  

• コマンドやフラグがドキュメントに記載されていない場合、それは存在しません。

コマンドの実行時間と確認への対応

フォアグラウンドで無期限にストリーミングするコマンド：

• dstack attach
• run に対する -d なしの dstack apply
• dstack ps -w

エージェントは処理をブロックしないようにしてください。-d、タイムアウト、またはバックグラウンドでの attach を使用します。attach が必要な場合は、デフォルトでバックグラウンド（nohup ...）で実行します。ただし、ライブのフォアグラウンドセッションを求められない限り、ユーザーには単に「attach」と説明してください。

特定の run をプログラムで待つ場合は、 dstack run get <run-name> --json を使用し、トップレベルの status を読み取ります。run のステータスは pending、submitted、provisioning、running、terminating、 terminated、failed、done です。最後の 3 つは終了状態です。次のアクションに必要な状態、または終了状態に達したら、待機を終了してください。 人が読める形式の dstack ps の出力を解析したり grep したりしないでください。ステータス列には no offers のようなジョブメッセージが表示される場合があります。

その他すべてのコマンド： タイムアウトは 10～60 秒にしてください。ほとんどのコマンドはこの範囲内に完了します。待機中は出力を監視してください。エラー、警告、または対応が必要なプロンプトが含まれている場合があります。

確認への対応：

• dstack apply、dstack stop、dstack fleet delete では確認が必要です
• ユーザーがすでに承認している場合は、-y フラグを使用して自動確認します
• dstack stop では、対話型プロンプトを避けるため、ユーザーの確認後は必ず -y を使用します
• dstack apply のプランを実行せずにプレビューするには echo "n" | を使用します（echo "y" | は避け、-y を優先します）

ベストプラクティス：

• 例外を除き、dstack apply にパラメーターを渡すより、設定ファイルを変更することを優先します
• ユーザーが削除または停止の操作を確認した場合は、確認プロンプトをスキップするために -y フラグを使用します

デタッチされた run のその後（-d の後）

-d を付けて run（開発環境、タスク、サービス）を送信した後は、まず送信に失敗していないか確認します。apply の出力にエラー（検証エラー、利用可能なオファーがない場合など）が表示された場合は、そこで処理を止めてエラーを提示してください。

run が送信されている場合は、dstack run get <run-name> --json で状態を確認し、関連する次の手順をユーザーに案内します。 次のアクションを促す必要がある場合は、dstack で行う手順とコマンドを明確に伝えてください（曖昧な質問は避けてください）。ユーザーには、アクションを「バックグラウンドでの attach」ではなく「attach」と伝えます。

• ステータスを監視する： 現在のステータスを報告し、監視を続けるか確認します。監視する場合は、次のアクションに必要な状態、または終了状態に達するまで、10～20 秒ごとに dstack run get <run-name> --json をポーリングします。
• 実行中に attach する： エージェントの場合、セッションがブロックされないよう、デフォルトでバックグラウンドで attach を実行します。IDE リンク／SSH エイリアスの取得や、ポートフォワーディングの有効化に使用します。ユーザーには、アクションを単に「attach」と伝えてください。
• ポートを使用する開発環境またはタスク： running になったら、attach して IDE リンク／ポートフォワーディング／SSH エイリアスを表示し、その後 IDE リンクを開くかユーザーに確認します。明示的な承認なしにリンクを開かないでください。
• サービス： サービスのエンドポイントを使用することを優先します。ポートフォワーディングまたはログの全件再生をユーザーが明示的に必要としている場合に限り、attach してください。
• ポートを使用しないタスク： 進捗の確認には dstack logs をデフォルトで使用します。ログの全件再生が必要な場合に限り、attach してください。

アタッチの動作（ブロッキングとノンブロッキング）

dstack attach は中断されるまで実行され、ターミナルをブロックします。**エージェントは無期限のブロッキングを避ける必要があります。**短時間のアタッチが必要な場合は、タイムアウトを設定して初期出力（IDE のリンク、SSH エイリアス）を取得してから、デタッチしてください。

注：dstack attach は SSH エイリアス情報を ~/.dstack/ssh/config に書き込み（また、~/.ssh/config を更新する場合があります）、ssh <run name>、IDE 接続、ポートフォワーディング、リアルタイムログ（dstack attach --logs）を利用できるようにします。サンドボックスからこれらの場所に書き込めない場合、エイリアスは作成されません。

権限に関するガードレール： サンドボックスの権限が原因で dstack attach が失敗した場合は、サンドボックス外で実行するための権限昇格をリクエストしてください。昇格が承認されない場合、またはアタッチが引き続き失敗する場合は、ユーザーにローカルで dstack attach を実行し、IDE のリンク／SSH エイリアスの出力を共有するよう依頼してください。

バックグラウンドでのアタッチ（エージェントではデフォルトでノンブロッキング）：

nohup dstack attach <run name> --logs > /tmp/<run name>.attach.log 2>&1 & echo $! > /tmp/<run name>.attach.pid

その後、出力を読み取ります：

tail -n 50 /tmp/<run name>.attach.log

求められた場合にのみ、ライブ出力の追跡を提案します：

tail -f /tmp/<run name>.attach.log

バックグラウンドでのアタッチを停止します（推奨）：

kill "$(cat /tmp/<run name>.attach.pid)"

PID ファイルが見つからない場合は、特定のプロセスに一致させる方法に切り替えてください（すべてのアタッチを終了しないようにします）：

pkill -f "dstack attach <run name>"

これが役立つ理由： エージェントが引き続き使用可能な状態で、アタッチセッション（ポートフォワーディングを含む）を維持できます。IDE のリンクと SSH の手順はログファイルに表示されます。それらをユーザーに提示し、明示的な承認を得た後にのみ、リンクを開くかどうか確認してください（macOS では open "<link>"、Linux では xdg-open "<link>"）。

サンドボックスでのバックグラウンドアタッチが失敗した場合（~/.dstack または ~/.ssh への書き込み権限がない場合や、タイムアウトした場合）は、サンドボックス外でアタッチを実行するための権限昇格をリクエストしてください。承認されない場合は、ユーザーにローカルでアタッチを実行し、IDE のリンク／SSH エイリアスを共有するよう依頼してください。

ユーザーリクエストの解釈

「何かを実行する」： ユーザーからワークロード（開発環境、タスク、サービス）の実行を依頼された場合は、適切な設定で dstack apply を使用してください。注：dstack run でサポートされているのは、実行の詳細を取得するための dstack run get --json のみです。ワークロードを開始することはできません。

開発環境への「接続」または「開く」： 開発環境がすでに実行中の場合は、dstack attach <run name> --logs を使用して IDE の URL（cursor://、vscode:// など）と SSH エイリアスを提示してください（エージェントはデフォルトでバックグラウンド実行します）。サンドボックス内でのアタッチが失敗した場合は、権限昇格をリクエストするか、ユーザーにローカルでアタッチを実行してリンクを共有するよう依頼してください。

マルチノードタスクとマルチレプリカサービス

マルチノードタスク（### 2. Tasks を参照）またはマルチレプリカサービス（### 3. Services を参照）を使用しない限り、タスクとサービスはどちらも単一ノードで実行されます。そのため、dstack logs <run name>、dstack attach <run name>、ssh <run name> はデフォルトで最初のレプリカ／ジョブを対象とします。

• マルチノードタスクでは、各ノードが独自のジョブを実行し、ノードグループ間で順に 0 から番号が付けられます。dstack logs <run name> --job 1 または dstack attach <run name> --job 1 でノードを指定します。
• マルチレプリカサービスでは、レプリカグループ間で順に 0 から番号が付けられます。dstack logs <run name> --replica 1 または dstack attach <run name> --replica 1 でレプリカを指定します。
• 0 以外の --job または --replica を指定してアタッチすると、SSH エイリアス ssh <run name>-<job num>-<replica num> が作成されます。

設定タイプ

dstack は、実行設定（開発環境、タスク、サービス）とインフラストラクチャ設定（フリート、ボリューム、ゲートウェイ）をサポートしています。設定ファイルには <name>.dstack.yml または単に .dstack.yml という名前を付けられます。

共通パラメーター： すべての実行設定（開発環境、タスク、サービス）は、以下を含む多くのパラメーターをサポートしています。

• Git 統合： リポジトリを自動的にクローンする（repo）、または既存のリポジトリをマウントする（repos）
• ファイルのアップロード： ローカルファイルをアップロードする（files。例についてはコンセプトのドキュメントを参照）
• Docker のサポート： カスタム Docker イメージを使用する（image）。コンテナ内から Docker を使用する場合は docker: true を指定する（VM ベースのバックエンドのみ）
• 環境： 環境変数を設定する（env）。多くの場合、.envrc を使用します。シークレットもサポートされていますが、あまり一般的ではありません。
• ストレージ： 永続的なネットワークボリューム（volumes）を使用し、ディスクサイズを指定する
• リソース： GPU、CPU、メモリ、ディスクの要件を定義する

ベストプラクティス：

• 管理を容易にするため、設定には name プロパティを指定することを推奨します
• 設定で認証情報（API キー、トークン）が必要な場合は、env セクションには環境変数名のみ（例：- HF_TOKEN）を記載し、値は記載しないでください。実際の値は設定と同じ場所にある .envrc ファイルに保存し、source .envrc && dstack apply で適用することを推奨します。
• 実行設定では、python と image は相互に排他的です。image が設定されている場合、python は設定しないでください。
• commands の項目は && で結合され、1 つのシェル行として実行されます。そのため、ヒアドキュメントなどの複数行シェルは、1 つの項目（| ブロック）内に記述してください。項目の末尾にあるヒアドキュメントは、その後のすべての項目を取り込み、実行せずに実行を 0 で終了します。項目の末尾にある # comment も同様に、行の残りをコメントアウトします。

files と repos の使用方針

実行環境内でローカルファイルまたはリポジトリ内のファイルを使用する意図がある場合に限り、files と repos を使用してください。

• ユーザーが実行環境内でプロジェクトのコード、データ、設定を使用するよう求めている場合は、適切に files または repos を追加します。
• ファイルまたはリポジトリをマウントする必要があるかまったく不明な場合は、明確に確認する質問を 1 つするか、マウントしない設定を既定とします。

files のガイダンス：

• ローカルのプロジェクトファイルには、相対パスを使用できます。相対パスの使用を推奨します。
• 相対パスの files は、実行環境の working_dir（既定値またはユーザー指定の値）の下に配置されます。

repos とイメージ／作業ディレクトリに関するガイダンス：

• 既定以外の Docker イメージを使用する場合、repos には明示的な絶対マウント先（例：.:/dstack/run）を指定することを推奨します。
• リポジトリのマウント先を明示的に設定する場合は、working_dir にも同じパスを設定してください。
• 理由：カスタムイメージでは既定の作業ディレクトリが異なる場合や、空でない場合があり、空でないパスへのリポジトリのマウントに失敗することがあります。
• dstack の既定イメージでは、既定の working_dir はすでに /dstack/run です。

1. 開発環境

用途： IDE 統合（VS Code、Cursor など）を利用した対話型開発。

type: dev-environment
name: cursor

python: "3.12"
ide: vscode

resources:
  gpu: 80GB

コンセプトのドキュメント | 設定リファレンス

2. タスク

用途： バッチジョブ、トレーニング実行、ファインチューニング、ウェブアプリケーションなど、実行可能なあらゆるワークロード。

主な機能： 分散トレーニング（マルチノード）とウェブアプリ向けのポートフォワーディング。

type: task
name: train

python: "3.12"
env:
  - HUGGING_FACE_HUB_TOKEN
commands:
  - uv pip install -r requirements.txt
  - uv run python train.py
ports:
  - 8501  # Optional: expose ports for web apps

resources:
  gpu: A100:40GB:2

ポートフォワーディング： ports を指定すると、接続中は dstack apply によってポートが localhost に転送されます。再接続してポートフォワーディングを復元するには、dstack attach <run name> を使用します。実行名は SSH エイリアス（例：ssh <run name>）となり、直接アクセスできます。

マルチノードタスク： 複数のノードでタスクを実行するには nodes を設定します。または groups を使って、それぞれ独自の nodes 数、resources、commands、ports を持つノードグループを定義します（groups とトップレベルの nodes は相互に排他的です）。ノード間通信をサポートするフリートが必要です（フリートの placement: cluster を参照）。

コンセプトのドキュメント | 設定リファレンス

3. サービス

用途： モデルやウェブアプリケーションを本番環境のエンドポイントとしてデプロイします。

主な機能： OpenAI 互換のモデルサービング、自動スケーリング（RPS／キュー）、HTTPS 対応のカスタムゲートウェイ。

type: service
name: llama31

python: "3.12"
env:
  - HF_TOKEN
commands:
  - uv pip install vllm
  - uv run vllm serve meta-llama/Meta-Llama-3.1-8B-Instruct
port: 8000
model: meta-llama/Meta-Llama-3.1-8B-Instruct

resources:
  gpu: 80GB
  disk: 200GB

サービスエンドポイント：

• ゲートウェイなし：<server URL>/proxy/services/<project name>/<run name>/
• ゲートウェイあり：https://<run name>.<gateway domain>/
• 認証：auth が false でない限り、サービスリクエストに Authorization: Bearer <user token> を含めます。
• モデルエンドポイント：model が設定されている場合、dstack run get <run name> --json の service.model.base_url からモデルエンドポイントを取得できます。OpenAI 互換モデル（別の形式が設定されていない場合のデフォルト）では、これは service.url + /v1 になります。
• 例（ゲートウェイあり）：

  curl -sS -X POST "https://<run name>.<gateway domain>/v1/chat/completions" \
    -H "Authorization: Bearer <user token>" \
    -H "Content-Type: application/json" \
    -d '{"model":"<model name>","messages":[{"role":"user","content":"Hello"}],"max_tokens":64}'
  

マルチレプリカサービス： 複数のレプリカを実行するには replicas を設定します。または groups を使用して、それぞれ独自の replicas 数、resources、commands を持つレプリカグループを定義します（groups とトップレベルの replicas は同時に使用できません）。レプリカがインターコネクト（例：PD ディスアグリゲーション）を必要とする場合、サービスは placement: cluster のあるフリートで実行する必要があります。

概念ドキュメント | 設定リファレンス

4. フリート

用途： ワークロード用のインフラストラクチャを事前にプロビジョニングし、オンプレミスの GPU サーバーを管理し、自動スケーリングするインスタンスプールを作成します。

type: fleet
name: my-fleet
nodes: 0..2

resources:
  gpu: 24GB..
  disk: 200GB

spot_policy: auto # other values: spot, on-demand
idle_duration: 5m

オンデマンドプロビジョニング： nodes が範囲（例：0..2）の場合、dstack はテンプレートを作成し、最小数と最大数の範囲内でオンデマンドにインスタンスをプロビジョニングします。アイドル状態のインスタンスを終了するには idle_duration を使用します。

分散ワークロード： ノード間ネットワークを必要とするマルチノードタスク向けのフリートには placement: cluster を使用します。

SSH フリート（オンプレミスまたは事前プロビジョニング済み）：

type: fleet
name: on-prem-fleet

ssh_config:
  user: ubuntu
  identity_file: ~/.ssh/id_rsa
  hosts:
    - 192.168.1.10
    - 192.168.1.11

概念ドキュメント | 設定リファレンス

5. ボリューム

用途： データセット、モデルチェックポイント、トレーニング成果物の永続ストレージです。

type: volume
name: my-volume

backend: aws
region: us-east-1

resources:
  disk: 500GB

インスタンスボリューム（ローカル、一時的、多くの場合は任意）：

type: dev-environment
# ... other config
volumes:
  - instance_path: /dstack-cache/pip
    path: /root/.cache/pip
    optional: true
  - instance_path: /dstack-cache/huggingface
    path: /root/.cache/huggingface
    optional: true

ボリュームのマウント： 開発環境、タスク、サービスでは volumes を使用します。ネットワークボリュームは独立して保持されますが、インスタンスボリュームはインスタンスのライフサイクルにひも付きます。

概念ドキュメント | 設定リファレンス

6. ゲートウェイ

用途： 基本的なサービスエンドポイントでは、ゲートウェイは任意です。サービスで自動スケーリングまたはレート制限を使用する場合、カスタムドメインで HTTPS が必要な場合、WebSocket が必要な場合、またはサーバープロキシのパスプレフィックスに対応できない場合は必須です。

type: gateway
name: my-gateway

backend: aws
region: us-east-1
domain: example.com

概念ドキュメント | 設定リファレンス

必須の CLI コマンド

設定を適用する

重要な動作：

• dstack apply は推定コストを含むプランを表示し、確認を求めることがあります
• アタッチモード（デフォルト）では、ターミナルがブロックされ、出力が表示されます
• デタッチモード（-d）では、送信後にアタッチせず終了します

実行設定（開発環境、タスク、サービス）を適用するワークフロー：

1. プランを表示：

   echo "n" | dstack apply -f config.dstack.yml
   

   オファーの表とコスト見積もりを含む出力全体を表示します。要約や再フォーマットはしないでください。

2. ユーザーの確認を待ちます。 次の場合は続行しないでください：

   • 出力に「No offers found」または同様のエラーが表示されている
   • 出力に検証エラーが表示されている
   • ユーザーが明示的に確認していない

3. 実行（ユーザーの確認後のみ）：

   dstack apply -f config.dstack.yml -y -d
   

4. 適用状況を確認：

   dstack run get <run-name> --json
   

インフラストラクチャ（フリート、ボリューム、ゲートウェイ）のワークフロー：

1. プランを表示：

   echo "n" | dstack apply -f infra.dstack.yml
   

   出力全体を表示します。要約や再フォーマットはしないでください。

2. ユーザーの確認を待ちます。

3. 実行：

   dstack apply -f infra.dstack.yml -y
   

4. 確認： それぞれ dstack fleet、dstack volume、または dstack gateway を使用します。

フリート管理

# Create/update fleet
dstack apply -f fleet.dstack.yml

# List fleets
dstack fleet

# Get fleet details
dstack fleet get my-fleet

# Get fleet details as JSON (for troubleshooting)
dstack fleet get my-fleet --json

# Delete entire fleet (use -y when user already confirmed)
dstack fleet delete my-fleet -y

# Delete specific instance from fleet (use -y when user already confirmed)
dstack fleet delete my-fleet -i <instance num> -y

ホストの GPU ドライバー： NVIDIA、AMD、Tenstorrent の場合、VM ベースのバックエンドと SSH フリートは、ホストの GPU ドライバーのバージョンを instances[].gpu_driver.version で報告します。インスタンスが idle または busy になると、dstack fleet get my-fleet --json で確認できます。ホストのドライバーがワークロードと互換性があるか不明な場合に役立ちます。

実行を監視する

# List all runs
dstack ps

# Verbose output with full details
dstack ps -v

# JSON output (for troubleshooting/scripting)
dstack ps --json

# Get specific run details as JSON
dstack run get my-run-name --json

実行に接続する

# Attach and replay logs from start (preferred, unless asked otherwise)
dstack attach my-run-name --logs

# Attach without replaying logs (restores port forwarding + SSH only)
dstack attach my-run-name

ログを表示する

# Stream logs (tail mode)
dstack logs my-run-name

# Debug mode (includes additional runner logs)
dstack logs my-run-name -d

# Fetch logs from specific replica (multi-node runs)
dstack logs my-run-name --replica 1

# Fetch logs from specific job
dstack logs my-run-name --job 0

実行を停止する

# Stop specific run (use -y after user confirms)
dstack stop my-run-name -y

# Abort (force stop)
dstack stop my-run-name --abort

オファーを一覧表示する

オファーは、リソース要件に一致する利用可能なインスタンス構成を表します。--fleet を省略すると、dstack offer は設定済みのすべてのバックエンドを確認します。オファーを一覧表示してもキャパシティは作成されません。実行を送信するには、一致するインスタンスをプロビジョニングまたは再利用できるフリートが少なくとも 1 つ必要です。特定のフリートで利用可能なオファーを確認するには、--fleet を使用します。

# Filter by specific backend
dstack offer --backend aws

# Filter by GPU type
dstack offer --gpu A100

# Filter by GPU memory
dstack offer --gpu 24GB..80GB

# Combine filters
dstack offer --backend aws --gpu A100:80GB

# Limit to a specific fleet
dstack offer --fleet my-fleet

# Combine offers from multiple fleets
dstack offer --fleet my-fleet --fleet other-fleet

# JSON output (for troubleshooting/scripting)
dstack offer --json

--fleet を 1 つ指定すると、dstack offer はそのフリートで利用可能なオファーを表示します。--fleet を複数指定すると、選択したフリートで利用可能なオファーをまとめて表示します。同一のバックエンドオファーは 1 回だけ表示されますが、一致する既存のインスタンスは個別に表示されます。

オファーの最大数： デフォルトでは、dstack offer は先頭から N 件のオファーを返します（出力には合計数も含まれます）。上限を増やすには、--max-offers N を使用します。

グループ化： すべてのオファーを集計して出力する場合は、--max-offers ではなく --group-by gpu を指定してください。その他にサポートされているフィールドは backend、region、count です。region には backend が必要です。

トラブルシューティング

dstack のワークロードやインフラストラクチャに関する問題を診断する場合：

1. 詳細を確認するには JSON 出力を使用します：

   dstack fleet get my-fleet --json
   dstack run get my-run --json
   dstack ps -n 10 --json
   dstack offer --json
   

2. 実行の詳細なステータスを確認します：

   dstack ps -v
   

3. デバッグ出力でログを調べます：

   dstack logs my-run -d
   

4. ログを再生しながら接続します：

   dstack attach my-run --logs
   

よくある問題：

• オファーがない： dstack offer を確認します。実行を送信する場合は、一致するインスタンスをプロビジョニングまたは再利用できるフリートが少なくとも 1 つあることを確認します
• フリートがない： フリートが少なくとも 1 つ作成されていることを確認します
• 設定エラー： YAML の構文を検証し、具体的なエラーがないか dstack apply の出力を確認します
• プロビジョニングのタイムアウト： dstack run get <run-name> --json で実行を調べます。スポットとオンデマンドのどちらを使用するか検討します
• 接続の問題： サーバーのステータスを確認し、認証を確認して、バックエンドへのネットワークアクセスが可能であることを確認します

エラーが発生した場合：

1. 完全なエラーメッセージを変更せずに表示します
2. エラーに対処せずに同じコマンドを再試行しないでください
3. 対処方法については、トラブルシューティングガイドを参照してください

追加リソース

主要なドキュメント：

• 概要
• インストール
• クイックスタート

その他の概念：

• シークレット
• プロジェクト
• メトリクス
• イベント

ガイド：

• CLI と API
• サーバーのデプロイ

アクセラレーター別の例：

• AMD
• Google TPU
• Tenstorrent

ドキュメント全文： https://dstack.ai/llms-full.txt