pod-deploy

Pod のデプロイ

ユーザーが依頼した Pod を 1 つプロビジョニングし、アクセス方法を正確に伝えます。作成する前に、配置先のデータセンターに GPU クラスの在庫が実際にあることを確認します。作成呼び出しでは指定した種類の GPU がそのまま配置され、別の GPU にフォールバックすることはありません。その種類を配置できない場合は 400 が返されます。適切なイメージと、ワークロードに必要なポート（アプリの UI、Jupyter、SSH）を選び、機能する形式の Runpod プロキシ URL を返します。トレーニング用 Pod では、チェックポイントが Pod のコンテナディスクの寿命を超えて保持されるよう、ネットワークボリュームを同じ場所に配置します。

Pod の作成には料金が発生します。作成前に時間あたりの料金を伝えてください。すでに存在する Pod の診断や復旧は別の作業で、pod-doctor が担当します。

必要な機能

機能として列挙しています。このサーバーで各機能を提供するツールは、以下のツールバインディングに記載されています。このスキルは作成前に在庫を確認し、ユーザーが依頼した Pod だけを作成します。

• データセンターごとの GPU 在庫と、CUDA の下限が重要な場合に容量のある CUDA バージョンを読み取る：作成前にクラスが利用可能であることを確認します（詳細なカタログの読み取りは discovery に委任します）。
• ネットワークボリュームを作成する：トレーニングのチェックポイントを永続化します（CRUD の適切な管理は lifecycle-crud に委任します）。
• Pod を作成する（イメージ、GPU または CPU、ディスク、ポート、環境変数、データセンター、マウント）。
• Pod を調べる：ステータス、公開ポート、プロキシ／パブリックアドレスを読み取ります。
• Pod を一覧表示する：「どの Pod か」を特定し、すでに存在するものを確認します。
• Pod の起動ログを読み取る：URL を伝える前に、指定ポートでアプリが起動したことを確認します。
• Pod を停止／終了する：作成後に一時停止する場合や、ユーザーから依頼された場合にクリーンアップします。

フェーズ 1 — 在庫を確認し、Pod の構成を決める

• 作成前に、ワークロードに必要なクラスの GPU の利用状況を読み取ります。include:["AVAILABILITY"] と product:["POD"] を組み合わせると（この 2 つはセットで使い、在庫状況はプロダクトごとに異なります）、データセンターごとの状況を確認できます。これにより、配置先のデータセンターを推測ではなく、読み取った情報に基づいて決められます。その場所にクラスの在庫がなければ、その旨を伝えて別のクラスまたはデータセンターを提案します。利用できないクラスには作成しないでください。
• 用途に合ったイメージを選びます。開発には対話型アプリ（ComfyUI や PyTorch のイメージなど）、トレーニングには CUDA／PyTorch のベースイメージを使います。イメージの CUDA を GPU クラスの対応状況に合わせ、作成時に下限として固定します。gpu.minCudaVersion はイメージの CUDA の世代に設定してください（CUDA 12 のイメージなら 12.8、CUDA 13 上に構築されたイメージの場合に限り 13.0）。これにより、イメージに対応したドライバーを持つホストに Pod が配置されます。テンプレートの allowedCudaVersions が下限の初期値になります。作成時に gpu フィールドを明示すると、その初期値は置き換えられます。在庫状況の読み取り結果にある cudaVersions で、その下限の在庫があるかを確認できます。
• イメージは記憶ではなく、このセッションで読み取った情報から選びます。 名前の指定されたアプリ（ComfyUI、Jupyter、特定のスタックなど）では、直前に読み取ったテンプレートまたは Hub リポジトリからイメージを特定し、選択時にその出典を示します。アカウントですでに実行中のイメージ（list-pods の読み取りで確認できるもの）も、カタログに候補がない場合に調べる価値のある、セッション内で読み取った出典です。そのイメージが実行されている Pod を示してください。カタログに候補がない場合に限り、広く知られた公開イメージを代わりに使用できます。その場合は、回答でその旨を明示します。記憶を頼りにイメージタグを指定すると、古いイメージを選んで起動時にクラッシュループに陥るおそれがあります。Runpod では :latest タグを公開していないため、正確なタグを指定してください。GPU を使う場合は、runpod/base より runpod/pytorch イメージを優先します。
• ワークロードに応じてポートを決めます。Web UI にはアプリ独自の HTTP ポート、Jupyter には 8888/http、直接 SSH 接続には 22/tcp を使います。SSH には作成時の startSsh: true と、アカウントに登録済みのキーも必要です（先に get-ssh-keys で確認します）。両方が揃っていない場合、どのポートを指定しても Pod に SSH 接続できません。ユーザーがアクセスするために必要なものだけを公開します。
• 料金を伝えます。 作成前に、カタログの読み取り結果に基づいて GPU の時間あたりの料金を提示してください。実行中の Pod は、ユーザーが使っていなくても料金が発生します。

フェーズ 2 — 作成して接続する

• 対話型／開発 Pod。 選択したイメージ、GPU クラス、ディスク、ポート、データセンターを指定して Pod を作成します。実行状態になったら Pod を確認し、公開ポートと現在のマッピングを読み取ります。コンテナの初期化中は Pod の runtime.ports が空のままなので、値が入るまでポーリングしてから URL を返します。アプリのイメージは大きく、プルに数分かかる場合があります。起動が遅くても、失敗とは限りません。最初の Pod がまだプル中だからといって、2 つ目の Pod を作成してはいけません。Pod ID が存在したらすぐに、プロキシ URL の形式（https://<podId>-<port>.proxy.runpod.net）を伝えます。ツールで待機できる時間内にアプリがバインドされない場合は、確認できた状況の報告（Pod ID、状態、最後のログ行）と推奨される次の手順を伝えます。監視を続けることを申し出てもかまいません。HTTP ポートにアクセスする URL は、プロキシ URL https://<podId>-<port>.proxy.runpod.net です。SSH の場合は、Pod の ssh ブロックを返します。ssh.direct（22/tcp が必要。scp と rsync を含む完全な SSH 接続）か、パブリック IP のないマシンでは ssh.proxy（対話型シェルのみ）を使います。ssh.direct は RUNNING になってから数分後に表示される場合があり、停止／開始のたびに変わるため、表示されていない場合はその旨を伝えます。ユーザーにアクセス可能だと伝える前に、起動ログの「listening on 0.0.0.0:PORT」という行を確認し、アプリがバインドされたことを確かめます。
• 作成してから停止し、後で使う。 ユーザーが Pod を作成しても、まだ実行状態にしたくない場合は、Pod を作成し、実行状態になったことを確認してから STOP します。終了してはいけません。終了すると、ユーザーが保持したいボリュームディスクが削除されます。停止後は、次の影響を伝えます。コンピューティング料金は発生しなくなり、GPU は解放されます。停止するとコンテナディスクは消去されますが、ボリュームディスク（デフォルトでは /workspace）は残り、Pod が終了するまで停止中のディスク料金が発生します。Pod はそのマシンに残ってそこで再開します。そのため、再開までに別の利用者がその GPU を使い始めた場合、そのホストに空き GPU がないため開始を拒否されることや、GPU なしで再開されることがあります。ネットワークボリューム上のデータには影響しません。Pod を再開する方法（Pod を開始する）と、GPU が使えなくなった場合の対処方法（待って再試行する、GPU を 0 にしてファイルにアクセスする、またはコンソールから Pod を移行する。移行については pod-doctor を参照）を伝えます。
• チェックポイントを永続化するトレーニング Pod。 コンテナディスクに書き込んだチェックポイントは Pod とともに消えるため、ネットワークボリュームを併用します。Pod を配置するデータセンターと同じデータセンターにボリュームを作成します（lifecycle-crud を参照してください。ネットワークボリュームをアタッチできるのは Secure Cloud Pod のみなので、Pod も Secure Cloud に配置します）。次に、そのボリュームをチェックポイント用パス（例：/workspace または /checkpoints）にマウントして Pod を作成し、Pod の配置先をそのデータセンターに固定します。マウントパスを伝え、そこに保存したチェックポイントは Pod の停止後も終了後も残りますが、コンテナディスク上のデータは残らないことを伝えます。余裕を持たせて、想定されるチェックポイントの合計量に合わせてボリュームサイズを設定します。Pod では、マウントパスは mounts で設定したパスです（デフォルトなし）。Serverless ワーカーからは、常に /runpod-volume にボリュームが見えます。これらのチェックポイントを後でサーバーレスエンドポイントから読み取る場合、ハンドラーは Pod 側のパスではなく /runpod-volume から読み取る必要があります。

フェーズ 3 — 引き継ぎ

• 引き継ぎは FINAL メッセージ内に単独で記載します（ルーターの契約）。Pod ID、実行している正確なイメージと、そのイメージの取得元であるテンプレート／Hub の読み取り結果、根拠となった在庫情報とともにGPUクラス（在庫確認の読み取り結果を引用してください：「RTX 3090 — EU-RO-1 で N 枚利用可能」）、到達可能なURL（そのまま記載。HTTPの場合は完全なプロキシURL、SSHの場合は ssh 接続文字列。「上記のリンク」とは書かず、到達可能なURLではないブートログ内部の 0.0.0.0:<port> アドレスも記載しません）、プロキシURLはデフォルトで公開されており認証がないこと（背後に機密情報がある場合は、個別に認証が必要であること）の注記、ボリュームをアタッチした場合はマウントパス、Pod の状態、および現在発生している時間単位の料金を記載します。停止中の Pod については、状態とともに必ず課金への影響を記載します。GPU の課金は終了していますが、Pod を終了するまでボリュームディスクには停止中の料金がかかり、ネットワークボリュームには Pod の状態にかかわらず作成から削除まで料金がかかります。
• クリーンアップ。 デフォルトでは、ユーザーが依頼した Pod は保持し、何に料金がかかっているかと停止方法を伝えます（停止するとボリュームディスクは保持され、停止中の料金がかかります。終了するとボリュームディスクは削除されます。ネットワークボリュームはどちらの場合も残り、削除するまで料金がかかります）。ユーザーが一時的なテストとして依頼した場合、またはクリーンアップを求めた場合に限り、リソースを削除します（その作業専用に作成したボリュームも削除し、読み取り結果で確認します）。実行後に削除するトライアルとして Pod を依頼された場合は、自身による読み取り結果を根拠とします。Pod が RUNNING でポートがマッピングされていること、そしてブートログにアプリのリッスン開始行があることの両方を確認したら、同じターン内に Pod を終了し、読み取り結果で削除済みであることを確認して、確認できた根拠を報告します。ユーザーがURLを試すのを待ったままターンを終えてはいけません。

厳守事項

• 作成前に在庫を確認します。在庫がないGPUクラスには決して作成しません。
• Pod を作成する前、およびネットワークボリュームを作成する前に、時間単位の料金を提示します。
• ユーザーが依頼した Pod だけを作成します。ユーザーが指定していない Pod（またはボリューム）を停止、終了、変更してはいけません。
• Pod が完全に実行状態になり、アプリがポートにバインドするまで、プロキシURLを引き渡してはいけません。runtime.ports が空の場合は、まだ初期化中であり、故障ではありません。
• トレーニングの場合、チェックポイントはコンテナディスクではなくネットワークボリュームに保存する必要があります。そうしないと、停止または終了時に失われます。
• ワークロードに必要なポートだけを公開します。ユーザーが求めていない SSH（22/tcp、startSsh）や追加ポートを開いてはいけません。
• 作成呼び出しだけを根拠に、Pod に到達可能だと断言してはいけません。先に状態を読み取って確認します。

エラー処理

• 作成時に配置または在庫エラーで 400 が返る → 読み取りから作成までの間に、そのデータセンターで該当クラスの在庫がなくなっています。その旨を伝え、同じクラスを再試行するのではなく、別のクラスまたはデータセンターを提案します。同じ 400（「no instances available」）は無効な GPU タイプ ID に対しても返されます。在庫切れと判断する前に、カタログの読み取り結果で ID を確認してください。
• Pod が running になっても runtime.ports が空のまま → まだ初期化中です。URLを引き渡す前に、get-pod をポーリングして値が入るまで待ちます。これは通常の Runpod API の動作であり、障害ではありません。
• 作成直後にプロキシURLが 502 を返す → 内部のアプリがまだポートにバインドしていないか、0.0.0.0 ではなく 127.0.0.1 にバインドしています。Pod が故障していると判断する前にブートログを読み取り、確認します（詳しい診断には pod-doctor を使用します）。
• create-network-volume が拒否される → エラーを読み取ります。データセンターでネットワークストレージを提供していない（データセンターの読み取り結果で networkVolumeTypes が空）、サイズが 10～4096 GB の範囲外、またはアカウント残高不足の可能性があります。正確な理由をユーザーに伝え、そこで終了します。
• 作成呼び出しが失敗する → 報告して終了します。やみくもに再試行したり、2つ目の Pod を作成したりしてはいけません。
• Pod は実行中だが、数分経ってもアプリがイメージを取得中、または起動中 → 数 GB のイメージでは正常な動作です。代わりの Pod を作成したり、際限なく待ち続けたりする理由にはなりません。上記の待機時間に上限を設けた引き継ぎ手順に従います。

レポートテンプレート — Pod の引き渡し

適切な Pod の引き渡しでは、今回のターンで読み取った内容を使い、まず次の4行を示します。Pod（ID、状態、実行中の時間単価）、イメージ（どのテンプレートか、Hub または Pod のどちらから読み取ったか）、GPU クラスと可用性の読み取りで確認した在庫数、プロキシ形式の到達可能な URL（または SSH の場合は ssh 接続文字列）です。その後、ボリュームを接続している場合はマウントパスを示し、Pod の現在の状態による課金への影響を説明します。

ツールの対応関係

機能	ツール
データセンターごとの GPU 在庫	list-gpu-types / get-gpu-type（include:["AVAILABILITY"]、product:["POD"]）
GPU タイプごとの、容量のある CUDA バージョン	同じ読み取り（cudaVersions）；ホスト CUDA バージョン全体のマトリックス表示には get-capacity
データセンター	list-data-centers、get-data-center
ネットワークボリュームの作成	create-network-volume
Pod の作成	create-pod
Pod の確認	get-pod
Pod の一覧表示	list-pods
Pod の起動ログの読み取り	stream-pod-logs
Pod の停止（ボリュームディスクは保持）	pod-action（{"action":"stop"}）
停止した Pod の再開	pod-action（{"action":"start"}）
Pod の終了	delete-pod
アカウントの SSH キー	get-ssh-keys / update-ssh-keys

ここに記載されたツールがセッションのツール一覧にない場合は、その旨を伝え、結果を捏造するのではなく、最も近い読み取りツールを使用してください。

契約

複数のジャーニーに共通する回答契約（読み取りから得た確定的な事実、曖昧さを避けて確定すること、変更操作はこの会話で作成したものに限定すること、独立した最終メッセージ、失敗を正直に伝えること、許可されたツールのみを使うこと）は、runpod-mcp スキルで定義されており、このジャーニーのすべての返信に適用されます。この会話で runpod-mcp スキルがまだ読み込まれていない場合は、次のツール呼び出しの前に読み込んでください。変更してよいリソース、依頼を実行してよい条件、ユーザーの判断を待って停止する条件に関するルールは、ここでは繰り返しません。