serverless-deploy

Serverless デプロイ

デプロイ可能なソースを取り込み、キューを使用する実用的な Serverless エンドポイントに変換します。実際のジョブを 1 件実行して動作を確認し、何が作成され、どの料金が発生するのかをユーザーに明確に伝えます。手順は常に同じです。ソースを読み取り、エンジンとハードウェアを決定し、プロビジョニングしてウォームアップし、実際のジョブを 1 件使ってスモークテストを行い、URL と curl を渡し、何に料金が発生するかを伝えます。デプロイが一時的なテストとして依頼された場合、またはユーザーからクリーンアップを求められた場合に限り、リソースを削除します。

指示を待たずに決める必要がある項目が 2 つあります。エンジンの種類（このモダリティとモデル形式に適したワーカーイメージ）と、プロビジョニング方法（重みをイメージに含める、起動時にダウンロードする、ネットワークボリュームにステージングする方法があり、コールドスタート時のコストはそれぞれ異なります）です。ハードウェアのサイズは、推測ではなくモデルの実際のメタデータに基づいて決めます。そのモダリティに適したワーカーが複数ある場合は、スモークテスト可能なデプロイに最適な、最も小さく実績のあるイメージを優先します。巨大なイメージでは、最初のジョブのコールドスタートに何分もかかることがあります。スモークテストの目的は一連の流れを証明することであり、最大限の品質を実現することではありません。ユーザーの依頼がより大規模なエンジンを示唆している場合は、そのトレードオフを伝えます。エンドポイントの作成には料金がかかります。作成前に GPU クラスの時間あたりの料金を伝え、スモークテストのジョブにも料金が発生することを忘れないでください。

Python ファーストのコーディング（プロジェクト内でエンドポイント関数を記述し、Runpod の Python 開発ループである runpod-flash を使って反復する方法）には、この MCP 専用バンドルでは対応できません。方法を即興で作り出すのではなく、その旨を伝えてください。このスキルでは、既存のソース（Hub リポジトリ、コンテナイメージ、ComfyUI ワークフロー、Hub リリース）を MCP ツール経由でエンドポイントにデプロイします。

必要な機能

機能として以下に示します。このサーバーでそれぞれの機能を提供するツールは、以下のツールバインディングに記載されています。このスキルは作成前にカタログを読み取り、ユーザーがデプロイを依頼したものだけを作成します。

• GPU カタログ、料金、リアルタイムの在庫、データセンターごとの提供状況、キャパシティのある CUDA バージョンを確認する：サイズと在庫の確認（サイズ計算は discovery に委任します）。
• リリース設定を含む Hub ワーカーカタログを参照し、ビルド済みワーカーまたはコミュニティテンプレートを探して、ハードウェアと環境変数のスキーマを読み取る。
• Hub リリースをエンドポイントとして直接デプロイする：1 回の呼び出しで完了する Hub 経由の方法。
• テンプレートを作成する（イメージ、ディスク、ポート、環境変数、レジストリ、マウント）：再利用可能なワーカープリセット。
• Serverless エンドポイントを作成する（GPU プール、ワーカーの最小数／最大数、スケーラー、データセンター、ネットワークボリューム）。
• GPU と同じデータセンターに大きな重みをステージングするためのネットワークボリュームを作成する。
• GPU を固定する／ワーカーごとの GPU 数を設定する：gpu.count とプール、および excludedTypes による選択を使用します。set-endpoint-gpus は除外リストを作成し、ほかの設定を保持します。
• エンドポイントのヘルスを読み取り、ワーカーを一覧表示する：ウォームアップと準備状態、コールドスタートかクラッシュループかを示す証拠、およびワーカーログを確認します（クラッシュループ中のコンテナでも、ステータスが RUNNING または INITIALIZING と報告されることがあります）。
• ジョブを送信して完了まで待つ：スモークテスト（run-endpoint を実行し、ジョブ ID に対して get-job-status wait:300000 を使い、終端状態になるまで待ちます。runsync-endpoint は、ウォーム状態のエンドポイントで高速なジョブを実行するときに限り使用します。結果が保持されるのは 1 分間だけです）。
• 利用可能な場合は、ワーカーのログを読み取る：モデルの読み込みやクラッシュの証拠を確認します。利用できない場合は、endpoint-health と list-endpoint-workers でワーカーのヘルス件数を確認できます。原因を絞り込めますが、それだけではクラッシュループを特定できません。
• エンドポイント、テンプレート、作成したネットワークボリュームを削除する：作成したすべてのリソースをクリーンアップします。

フェーズ 0 — ソースを特定してエンジンを選択する（指示を待たずに判断）

ユーザーから渡されたソースを読み、分類してください。エンジンファミリーはデフォルトではなく、モダリティとモデル形式から決まります。テキスト生成以外のタスクを vLLM または ComfyUI のワーカーで処理してはいけません。

ソース／モダリティ	適切なエンジンファミリー	ワーカーイメージの種類
テキスト生成 LLM、safetensors の重み	vLLM または SGLang	runpod/worker-v1-vllm（または SGLang ワーカー）
テキスト生成 LLM、GGUF 量子化重み	llama.cpp / Ollama	GGUF 対応ワーカー — vLLM ではありません
画像／拡散モデルの workflow.json	ComfyUI	runpod/worker-comfyui (reference/comfyui-serverless.md)
音声テキスト変換（文字起こし）	Whisper 系モデル	音声テキスト変換ワーカー。LLM ワーカーではありません
テキスト音声変換／音声クローン	TTS モデル	TTS ワーカー
話者ダイアライゼーション	ダイアライゼーションパイプライン	Hub または公開カタログのダイアライゼーションワーカー
OCR／文書抽出	従来型 OCR エンジン	OCR ワーカー。VLM チャットワーカーではありません
テキスト埋め込み	埋め込みサーバー（例：text-embeddings-inference）	埋め込みワーカー
提供されたカスタムハンドラー	独自のイメージ	カスタムコンテナイメージ

• 形式の検出。 選択する前にリポジトリ内のファイルを確認してください。*.safetensors / *.bin → vLLM/SGLang。*.gguf → llama.cpp/Ollama ワーカー。GGUF リポジトリを worker-vllm にデプロイするのは、よくあるエンジン選択ミスです。vLLM は読み込めません。検出した形式と、それに対応するエンジンを最終メッセージに記載してください。検出も回答の一部であり、選択だけでは不十分です。
• OCR のサイズ選定。 OCR／文書抽出のスモークテスト用デプロイでは、従来型の軽量 OCR ワーカー（16–24 GB）をデフォルトとして選択してください。VLM ベースの OCR（7B 以上のパラメーター）は大規模モデルのデプロイです。大規模モデル相当のサイズ（48 GB クラス）を選ぶか、スモークテストには選ばないでください。
• コミュニティテンプレートのソース。 モダリティに Runpod 公式ワーカーがない場合は、Hub／公開カタログを検索して、そのモダリティに対応する**コミュニティ製（Runpod 以外）**テンプレートを探してください。リストに記載されたリポジトリ名と所有者を示し、記憶を頼りにリポジトリを断定してはいけません。適合するワーカーが見つかったら、デプロイして実際のジョブを 1 件実行してください。「X を見つけました」で終わらせてはいけません。また、設定上省略可能な認証情報を理由に処理を止めてはいけません（フェーズ 2 のランタイム時省略可能トークンのルールを参照）。ワーカーの設定に記載されたジョブ入力を使って機能を要求してください。カタログに適合するものが何もない場合に限り、「見つかりませんでした」と伝えて終了してください。リポジトリ名や Docker イメージを捏造してはいけません。
• カスタムイメージ。 ユーザーが独自のハンドラーイメージを提示した場合、そのイメージ自体がエンジンです。指定されたイメージをそのままデプロイし、代替品を使ってはいけません。必須の環境変数が欠けている場合は、質問せずにフェーズ 2 のモデルデフォルトのルールを適用してください。実際に確認されたワーカーの状態を報告し、ユーザーに質問を返してはいけません。デプロイ後、ワーカーの状態（list-endpoint-workers または endpoint-health）を読み取り、確認した内容を報告してください。カスタムイメージでは、ワーカーの実際のヘルス状態が成果物です。ジョブが 1 件完了しても、兄弟ワーカーがクラッシュループしていないことの証明にはなりません。そのため、クラッシュループしているカスタムイメージは失敗として報告してください。プライベートレジストリにある場合、エンドポイントにはレジストリ認証情報が必要です（作成または参照してください。lifecycle-crud を参照）。レジストリのパスワードを決して出力してはいけません。キューではなくロードバランサー（custom-HTTP、direct-routing）エンドポイントの場合、最も重要なルールは、ワーカーが PORT（デフォルトは 80）で HTTP を提供し、PORT_HEALTH（デフォルトは 80）上の HEALTH_CHECK_PATH（デフォルトは /ping）でヘルスチェックに応答することです。どちらかを満たさないとワーカーはヘルスチェックに合格せず、エンドポイントは準備完了ワーカーが 0 のまま停止しているように見えます。エンドポイントの読み取り結果には、確認対象の正確なヘルスチェック URL が返されます。エンドポイントの種類は作成後に変更できません。また、ロードバランサーエンドポイントにはキューがありません。すべてのワーカーがビジー状態の場合、リクエストは待機せず失敗するため、ピーク時に合わせて workers.max を設定してください。

フェーズ 1 — ハードウェアの規模を決める（カタログを読み、discovery を引用する）

params×精度とKV／オーバーヘッドのVRAM計算はdiscoveryに委任し、このスキルではその結果を実際のGPU選定に適用します。

• モデルの実際のメタデータ（パラメーター数、精度、拡散モデルの場合はチェックポイント／LoRA／VAEのアセットサイズ）を読み取ります。設定が読み取れる場合、リポジトリ名だけをもとにサイズを決めないでください。
• 1枚のカードに固定する場合。 ユーザーがエンドポイントを特定のGPUに固定したい場合は、そのカードを含むプールを選び、プール内の他のGPUタイプをgpu.excludedTypesに列挙します（gpu.poolsにはGPUタイプIDではなくプールIDを指定し、少なくとも1つのタイプを残す必要があります）。これは作成時に指定するか、作成後にset-endpoint-gpusで設定します。読み戻し結果ではプールと除外対象が引用され、他のすべての設定が読み取り時の内容から変更されていないことも確認されます。
• VRAMが要件を満たす最小のGPUクラスを選び、GPU利用可能状況の読み取りで現在の在庫を確認します。エンドポイントで特定のデータセンターが必要な場合、product:["SERVERLESS"]とともにinclude:["AVAILABILITY"]を指定すると（この2つはセットで使用します。製品によって在庫状況は異なります）、データセンターごとの状況も確認できます。また、同じ読み取り結果のcudaVersionsには、CUDAの下限が設定されている場合に容量のあるCUDAバージョンが表示されます。その下限は作成時に固定します。イメージのCUDA系統に合わせてgpu.minCudaVersionを設定してください（CUDA 12のイメージなら12.8、CUDA 13上でビルドされたイメージの場合に限り13.0）。または、特定のバージョン一式を指定するgpu.allowedCudaVersionsを使用できます。この2つは同時に指定できず（両方送信すると400になります）、下限のバージョンはcudaVersionsに在庫がある必要があります。在庫のないGPUクラスには絶対に作成しないでください。ワーカーを取得できないスケール・トゥ・ゼロのエンドポイントは、デプロイ済みに見えても実行されません。
• 1枚のカードにモデルが収まらない場合のマルチGPU。 必要なVRAMが、在庫のある最大の単体カードのVRAMを超える場合は、GPU数／ワーカーを1より大きく設定し、ワーカー環境変数でテンソル並列処理を有効にします（例：vLLMワーカーのテンソル並列設定をGPU数と同じ値にします）。マルチGPUを選ぶことと、その理由（モデルが1枚のカードに収まらないこと）を明示し、マルチGPUワーカーの時間あたりの料金がGPU数に比例して高くなることも伝えます。確定する前に、回答で代替案の料金を比較します。在庫のある最大の単体カード（VRAM、現在の在庫、$/hr）と、選択したマルチGPU構成を引用してください。
• Hubデプロイではプールを固定します。 gpuIdsを省略したdeploy-hub-repoは、リリースのGPUプール一覧を引き継ぎます。そのため、24 GBカードで十分なタスクでも、数倍の時間あたり料金がかかる最上位のカードを意図せず取得する可能性があります。リリース設定で選定したプールが正確に固定されている場合を除き、すべてのHubデプロイで、自分のサイズ決定に基づくgpuIdsを指定してください。
• CPUサーバーレス。 create-endpointで選べるハードウェアは1つです。gpuオブジェクト（プールとGPU数）か、CPUカタログの読み取り（list-cpu-types）に基づいて選定したCPUフレーバー設定のcpu配列のどちらかを指定します。CPUワークロードではcpuを送信し、gpuは送信しないでください（CPUワークロードにGPUプールを絶対に強制しないでください）。作成前にCPUフレーバーの時間あたり料金を提示してください。
• 意図したデフォルトを設定します。 RESTで作成する場合、デフォルトではFlashBootがOFF、workers.maxが3、workers.idleTimeoutが10 s、timeoutが300 sになります。デフォルトをそのまま引き継がず、flashbootとワーカーの上下限を明示的に設定してください。アカウント内のエンドポイントにおけるworkers.maxの合計には、残高に応じて段階的に設定されるクォータ（初期値は5）があり、作成時に確認されます。そのため、2つ目のエンドポイントをデフォルトの3で作成しようとすると拒否される場合があります。
• 料金を明示します。 作成前に、カタログの読み取り結果から、選定したGPUの時間あたり料金（×GPU数）を提示してください。エンドポイントの作成とスモークテストの実行はいずれも課金されます。

フェーズ 2 — プロビジョニング

プロビジョニング方法は 2 通りあります。ソースに応じて選択してください。

• Hub リリース。 ソースが Hub リポジトリの場合は、記載されているリリースを直接デプロイします（1 回の呼び出し）。まずリリース設定（ハードウェア要件と環境変数スキーマ）を読み、リリースが受け付ける環境変数キーだけを渡すとともに、GPU／ディスクのデフォルト値を確認します。既知の正常なビルドを再現するには、「latest」ではなく正確なリリースを指定します。
• それ以外すべて。 エンジンイメージ、ディスクサイズ、ワーカーが公開するポート、環境変数（モデル ID、エンジン設定、トークン）を指定するテンプレートを作成してから、それを参照するエンドポイントを作成します。ユーザーがウォーム状態のキャパシティを求めていない限り、スケール・トゥ・ゼロ（最小ワーカー数 0）で開始します。最小数が 0 以外の場合、ワーカーは常時稼働となり課金されます。registry.runpod.net でホストされているイメージは Hub ビルドです。deploy-hub-repo でデプロイしてください（リリースにレジストリ認証情報が含まれます）。このイメージを指定した通常のテンプレートでは、レジストリ認証エラーが繰り返し発生します。
• プロビジョニング方法とコールドスタート。 イメージへの組み込み＝コールドスタートが最速で、イメージが最大になります。起動時のダウンロード＝イメージは小さくなりますが、新しいワーカーでの初回リクエストは遅くなります。ネットワークボリューム＝GPU と同じデータセンターに重みを一度だけ配置し、すべてのワーカーにマウントします（書き込み可能なため、同時書き込みを調整してください）。新しいワーカーではダウンロードが不要になります。事前構築済みのワーカーイメージが、マウント先から重みをロードします。独自に作成したハンドラーでは、VolumeCache（Runpod Python SDK runpod>=1.12.0）でロード処理をラップして、コールドスタートごとにまず重みをローカルディスクへコピーできます。runpodctl/reference/model-caching.md を参照してください。重みが大きい（およそ 30 GB 超）場合、または複数のワーカーで共有する場合は、ネットワークボリュームを選択します。余裕を持たせつつ実際のアセットの合計サイズに合わせてボリュームの容量を決め、エンドポイントを配置するデータセンターと同じ場所に作成し（lifecycle-crud を参照）、選択した方法とコールドスタートへの影響を伝えます。
• マルチリージョン／HA（自動同期なし）。 マルチリージョンエンドポイントには、データセンターごとに 1 つのネットワークボリュームを接続します。データセンターごとのこれらのボリュームは自動同期されません。データを自分で複製します（例：ボリュームの S3 エンドポイント間で aws s3 同期を実行します）。複製しない場合、各リージョンでは古い重みや存在しない重みが使われます。
• 必須環境変数、アクセス制限のある重み、実行時に任意のトークン。 リリース／ワーカー設定（includeConfig: true）を読み、デプロイ前に、デフォルト値のない必須環境変数キーをすべて設定します（例：埋め込みワーカーのモデル ID 環境変数である MODEL_NAMES）。モデル環境変数を設定せずにデプロイすると、ワーカーは何もロードせず、すべてのジョブで 400 エラーを返します。テキスト生成ワーカー（MODEL_NAME のない vLLM イメージ）についてユーザーがモデルを指定していない場合、設定に記載されたデフォルトモデルがあればそれを選び、なければ GPU に収まる最小のインストラクトモデル（16 GB クラスなら 1～2B のインストラクトモデル）を選び、選択したモデルを伝えてデプロイします。どのモデルにするかユーザーに尋ねないでください。ダウンロード時にトークンがないと重みの取得で 403 エラーになる、アクセス制限付きの HuggingFace リポジトリでは、トークンを環境変数として渡します。ユーザーからトークンが提供されていない場合は、ダウンロードで 403 エラーになることを伝えて確認します。重みを取得できないビルドはデプロイしないでください。任意の実行時機能にのみ必要なトークンで、設定のデフォルト値が空の場合（任意機能にトークンが必要なワーカー）は、まず次の条件を確認します。ユーザーはトークンを提供しましたか（依頼文に貼り付けた、環境変数に設定した、または利用可能だと伝えた場合）？
  • トークンが提供されている → それを使うことが作業です。 作成時にワーカーの環境変数として設定します（ワーカーが定めるトークン用環境変数を使用）。設定したことを環境変数名で伝え（値は決して伝えないでください）、アクセス制限付き機能が動作することを想定します。ユーザーから渡された認証情報を設定せずにデプロイしてはいけません。
  • トークンがない → それでもデプロイします。 デプロイはトークンの提供を条件としません。任意の認証情報を理由にデプロイ全体を保留しないでください。デプロイしてジョブを実行し、エンドポイントの返答を報告してから、アクセス制限付き機能を有効にするためのトークンを案内します。 トークンの値は決して表示しないでください。環境変数として参照してください。

フェーズ 3 — ウォームアップして実際のジョブを 1 件スモークテストする

デプロイ済みと判断する前に、エンドポイントを検証してください。ユーザーにポーリングループを任せるのではなく、サーバー側で待機しながらスモークテストジョブの完了を待ってください。ツール側で待機できます。ジョブが終了状態になったら、観測した内容を報告してください。待機しても進展が見込めなくなった場合は、確認できた状態を報告してください。

• 送信したら、サーバー側で待機します。短い間隔でポーリングを繰り返してはいけません。 run-endpoint で小さなジョブを1つだけ送信し（そのモダリティで実際に使える最小の入力を使用）、get-job-status の wait: 300000 で完了を待ちます。これはサーバー側での最大待機時間です。初回のコールドジョブは runsync の待機時間を超え、その結果は1分間しか保持されないため、runsync-endpoint はウォーム状態のエンドポイントで、処理の速いジョブに使用します。目的は、エンドポイントの存在だけでなく、実際のアセット一式でワーカーが起動し、適切な形式の出力を返すことを確認することです。
• 初回のジョブでは、1〜5分以上のコールドスタートを想定してください。 新しいワーカーはイメージを取得し、モデルを読み込みます。これは正常であり、失敗ではありません。ジョブが待機時間を超えた場合は、wait: 300000 を指定した get-job-status で待機を続けます（サーバー側で1回待機します。短い間隔で再ポーリングしてはいけません）。すでに取得したジョブ ID をポーリングしてください。ジョブを再送信してはいけません。新しいジョブが開始されます。待機の合間に list-endpoint-workers を確認します。unhealthy のワーカー、準備完了のワーカーがいるのにキューに残っているジョブ、または容量がゼロの場合は、待機をやめてログを確認してください（後述）。スモークテストのジョブでは、サーバー側での待機は最大3回です。 同じジョブ ID に対し、wait: 300000 を指定した get-job-status の呼び出しは最大3回までです。3回目の待機後は、確認できた内容を報告として提示します。4回目の待機や短い間隔でのポーリングは行いません。3回の待機を超えても完了しないジョブは、待ち続けずにその状態を報告します。待機を続けても有益な情報が得られなくなったら、ワーカーの状態を根拠として状態を報告してください。エンドポイントは正しく作成され、ジョブは送信されたものの、ワーカーは準備完了にならなかったこと、そしてワーカーの状態に何が示されているかを伝えます。確認できた内容に基づくこの報告で十分です。際限なく処理を続ける必要はありません。
• 常に確認できる読み取り結果、つまり endpoint-health、list-endpoint-workers、および IN_QUEUE のときに get-job-status が付加する workerHealth ブロックを使って、停止したジョブを診断してください。 初回ジョブでワーカーが initializing の場合、コールドスタートがまだ進行中の可能性があります。その場合は待機を続けますが、次の待機の前にワーカーログ（source=system）を確認してください。イメージの取得失敗や CUDA の不整合でコンテナーがクラッシュループしている場合でも、ジョブが IN_QUEUE のまま、状態が INITIALIZING または RUNNING と表示されることがあります。ワーカーが unhealthy の場合、またはログにハンドラーの出力がなくコンテナーの起動が繰り返されている場合は、クラッシュループです（ウォームアップが遅いのではなく、実際のワーカー障害です）。待ち続けず、ワーカーイメージまたは GPU プールを切り替えてください。total: 0 の状態が数分以上続く場合、または throttled が 0 を超えている場合は、選択したプールやデータセンターに容量がありません。選択範囲を広げてください。IN_QUEUE から一度も抜けていないジョブは、解析されていません。ペイロードはどのワーカーにも読み取られていないため、キューで停止しているという根拠だけから入力形式に問題があると推測してはいけません。正直な報告は、ワーカーの状態を引用したうえで、キューまたはコールドスタートの事実を伝えることです。同じ方針は、キューの停止に関するあらゆる異常にも当てはまります。自分の読み取り結果と矛盾する、または読み取り結果に示されていない原因を「確定的」として提示してはいけません。キューに残っているジョブの横に準備完了のワーカーがあり、処理中のものがない場合は、イメージの不具合が考えられます。その場合は、ステータスだけでなくログを根拠に伝えてください。ワーカーを確保できるよう、供給の少ない大容量 VRAM のクラス（例：48 GB のカード）より、広く利用できる GPU プールを優先してください。
• 利用できるツールを使ってください。 MCP のみを使うセッションでは、ワーカーの入力スキーマを調べたり README を読んだりするために、利用できないウェブ取得ツール、シェル、ブラウザーを使おうとしてはいけません。利用できないツールは呼び出せず、ジョブが未完了のままデプロイが停止してしまいます。入力形式は includeConfig: true を指定した list-hub-repos と、エンドポイントから返されるエラーを使って確認し、ペイロードを修正して再実行してください。同様に stream-worker-logs が利用できない場合は、endpoint-health ／ list-endpoint-workers を使って診断してください。利用できるかわからないツールに、ジョブが未完了のまま依存することのないようにしてください。
• FAILED で終わったジョブについては、結果に示される決定的な詳細（ファイルの欠落、アクセス制限による 403、OOM、形式違いによる読み込みエラー）を、推測ではなく、結果に書かれたとおりに報告してください。OOM の場合、GPU は実際のメモリ使用パターンに対して小さすぎます。1段階上のクラスにしてください。GGUF リポジトリで形式違いによる読み込みエラーが発生した場合、エンジンが間違っています（フェーズ 0）。ペイロードに対する 400 エラーは入力形式が間違っていることを示します。リリース設定を確認して修正し、諦めずに再実行してください。

フェーズ 4 — 引き継ぎ

• 引き継ぎでは、ユーザーが前の内容に戻って確認する必要のない、完全な最終サマリーを提示します。サマリーには、エンドポイント ID、ワーカーのイメージまたは Hub リポジトリ（および、どの読み取り結果に基づくか）、GPU プールとその時間単価、スモークジョブの ID と、証拠（出力参照、引用したエラー、または根拠を示したタイムアウト報告）を添えた最終結果、同期 URL と非同期 URL、エンドポイントを保持したか（現在課金対象となっているもの）削除したか（読み戻しで確認済み）、そして $RUNPOD_API_KEY を参照する、すぐに実行できる curl を含めます（実際のキーを記載してはいけません）。サイズ計算、形式の調査結果、キャッシュや配置に関する事実も含めます。
• クリーンアップ。 デフォルトでは、ユーザーが依頼したものを保持します。現在課金対象となっているもの（エンドポイント、最小ワーカー、ネットワークボリュームがあればそのすべて）と、後で削除する方法を正確に伝えます。ユーザーが一時的なテストとして依頼した場合、またはクリーンアップを求めた場合に限り、エンドポイント、テンプレート、ネットワークボリュームを削除します。それぞれの削除は読み戻しで確認します。

厳守事項

• ユーザーが指定したソースだけをデプロイします。依頼されていないエンドポイントは作成せず、別のエンドポイント、テンプレート、ボリュームに手を加えたり、削除したりしないでください。
• デフォルトではなく、モダリティとモデル形式からエンジンを選びます。GGUF リポジトリは vLLM ジョブではありません。文字起こし／TTS／OCR／埋め込みはチャットワーカージョブではありません。
• 課金対象のエンドポイントを作成する前に、GPU の時間あたりの料金を伝えます。スモークジョブにも課金されることを忘れないでください。
• モデル URL、コミュニティテンプレートリポジトリ、Docker イメージを捏造しないでください。ユーザーから提供された情報とカタログからソースを特定できない場合は、一度だけ確認するか、「見つかりませんでした」と伝えて終了します。
• デプロイ完了と伝える前に、実際のジョブを1つ実行してエンドポイントを検証します。ID が返されたというだけでは、エンドポイントが稼働している証拠にはなりません。
• サーバー側で待機し、スモークジョブが終端状態になるまで実行します（run-endpoint の後、ジョブ ID を指定して get-job-status wait:300000 を実行します）。初回ジョブのコールドスタートには1～5分以上かかることを想定してください。ツールで待機できるのに、ユーザーにポーリングループを実行させてはいけません。待機を続けても新たな情報が得られなくなった場合は、確認できた結果（ワーカーの状態、ジョブのステータス）を報告して終了します。それで回答は完了です。待機中に何も伝えずに止めてはいけません。
• 許可されたツールを使います。ワーカーのスキーマを調べるために、使えないウェブ取得ツールやシェルツールが必要になるような進め方はしないでください。list-hub-repos includeConfig とエンドポイント自身のエラーから入力形式を特定し、その場でペイロードを修正します。
• 必須の環境変数キー（設定上のデフォルトがないもの）はすべてデプロイ時に設定します。埋め込みワーカーに MODEL_NAMES を設定しないとモデルが読み込まれず、すべてのジョブが失敗します。任意機能のトークン（ワーカーのドキュメントに記載されたトークン環境変数で、デフォルト値が空のものなど）について、ユーザーが提供した場合は作成時に設定します（渡された認証情報を無視してはいけません）。提供されていない場合もデプロイして実行し、結果を報告したうえで、機能を有効にするために必要なトークンを伝えます。
• ウォーム容量を求められない限り、スケール・トゥ・ゼロで開始します。ワーカーの最小数を黙って0以外に設定してはいけません。これは24時間課金されます。
• 大きなモデルのサイズは、単なる合計値ではなく、計算過程を示します。パラメーター数とその参照元、選択した精度でのパラメーターあたりのバイト数、重みの合計、KV キャッシュ／オーバーヘッドの見積もり、そしてそれらを踏まえた GPU の選定を提示します。
• ユーザーが具体的な動作設定（ウォーム／最小ワーカー数、アイドルタイムアウト、FlashBoot、GPU の固定）を求めた場合は、作成／更新後にエンドポイントを読み戻し、その設定が正確に反映されたことを確認します。書き込み結果を読み戻さなければ、書き込みは未検証です。書き込み呼び出し自体の応答は読み戻しではありません。REST PATCH は疎形式で、省略したフィールドは変更されません。ただし GPU の選択は例外です。gpu.excludedTypes を指定せずに gpu.pools を送ると除外設定が消去されるため、両方を送ります。また、GPU を固定した後はスケーリング設定も確認します。読み戻した結果を最終回答に含めます。
• 新しいエンドポイントをデプロイする場合、コールドスタート対策には4つの手段があります。既存のエンドポイントについては endpoint-ops に進み、ここでは何も変更しません。料金上のトレードオフとともに、4つすべてを説明します。FlashBoot（ワーカーの起動を高速化し、常時稼働コストはかかりませんが、ベストエフォートです）、最小／ウォームワーカー数（コールドスタートはなくなりますが、そのワーカーは継続課金されるため、料金情報を確認し、月額を $/hr × 730 で提示します）、アイドルタイムアウト（時間を長くすると、リクエストの間もワーカーがウォーム状態に保たれるためコールドスタートが減りますが、アイドル中の課金秒数は増えます）、モデルキャッシュ（モデルファイルをネットワークボリューム、Runpod のモデルリポジトリ（runpodctl model add を使用）、またはイメージ内に配置します。大きなモデルでは、コールドスタート時間の大部分は起動ではなくロードが占めます）（エンドポイントのモデル参照はコンソールまたは runpodctl で設定します。この手順はユーザーに案内します）。そのうえで、常時料金が発生しない手段（FlashBoot を有効にし、アイドルタイムアウトを長くする）を適用してエンドポイントを作成し、設定を読み戻して、残る選択肢であるウォームワーカーとその月額料金を伝えます。最小ワーカー数は、ユーザーが求めた場合、または料金に同意した場合にのみ設定します。何を選ぶべきかという質問に対し、何も作成せず選択肢だけを提示しても、セットアップ依頼への回答にはなりません。
• 重みが大きすぎてイメージに含められない場合は、ネットワークボリュームに配置します。対象 GPU があるデータセンターにネットワークボリュームを作成し、エンドポイントに接続して、ワーカーのモデルパス環境変数をボリュームのマウント先に設定します。最小ワーカー数は0のままにし、エンドポイントとボリュームを読み戻して接続を確認します。ユーザーがモデルの提供ではなくストレージのセットアップを求めている場合は、それらの読み戻しが証拠になります。大きなモデルのジョブには費用とダウンロード時間がかかるため、実行はユーザーから依頼されるまで待ちます。最初のワーカーがダウンロードした重みがキャッシュになります。ユーザーが依頼していないステージングポッドは作成せず、最初のリクエスト前にキャッシュをウォームアップしたい場合の選択肢として案内します。構築したアーキテクチャについて、次の2点を曖昧にせず伝えます。最初のワーカーが重みを一度だけボリュームにダウンロードし、以降のコールドスタートでは再ダウンロードせずにキャッシュをマウントします。ボリュームは GPU と同じデータセンターに置かなければマウントできません。ワーカーが既成イメージではなくユーザー独自のハンドラーコードの場合は、モデルキャッシュをコンテナーディスク上に保持し、モデルパスをマウント先に向ける代わりにロードを VolumeCache でラップします（runpodctl/reference/model-caching.md）。このボリュームの CRUD 運用は lifecycle-crud の担当範囲であり、ここではサービング側の接続設定を行います。
• HF／Civitai／レジストリのトークンをそのまま出力してはいけません。環境変数として言及します。
• スモークテストが失敗した場合はログを読み、その内容を引用します。確認せずに再試行したり、読んでいない原因を断定したりしてはいけません。
• 終端状態のジョブにある output／error フィールドは、ワーカーレベルの証拠です。失敗（アクセス制限付きモデルによる拒否、ロードエラーなど）を説明する際は、内容をそのまま引用します。終端状態のジョブ結果を持っているのに、証拠を引用できないとユーザーに伝えてはいけません。ログストリームツールがないことを理由に、ジョブ自体が返した証拠を省略してはいけません。アクセス制限のある機能を持つワーカーで COMPLETED ジョブの output が空または欠落していること自体も、引用可能な証拠です。その事実を報告し、設定上の事実（ワーカーのドキュメントに記載されたトークン環境変数が設定されていないこと）と併記し、ゲートの存在を明示します。

エラー処理

• スモークジョブがメッセージに gated / 403 を含む FAILED を返す → アセットにはアクセス制限があり、トークンが指定されていません。その旨を伝えてトークンを求めてください。自動で再作成しないでください。
• スモークジョブが out of memory を含む FAILED を返す → GPU が実際のパターンに対して小さすぎます。1 段階上の GPU クラスに移行し、新しい時間単位の料金を伝えてください。1 段階上げても失敗が続く場合は、ワーカーの選択自体を再検討してください。タスクに対して大きすぎるエンジンファミリー（従来型の OCR ワーカーで十分なのに 7B VLM を使う場合など）は、GPU を大きくしたり待ち時間を延ばしたりするのではなく、その場でワーカーイメージを切り替えて解決します。
• 保留時間を過ぎてもジョブが IN_QUEUE / IN_PROGRESS のまま → 通常はコールドスタートです。そのジョブ ID に対して get-job-status wait:300000 でブロックを続け、その後、終了状態の結果または根拠のある状態を報告してください。生のポーリングループをユーザーに渡すのではなく、サーバー側で保留してください。
• スモークジョブが 400 / ペイロード形式エラーを返す → 入力が誤っているか、必須のモデル環境変数が設定されていません。リリース設定を読み直し、不足している環境変数を設定するか、ワーカーの設定に記載された形式にペイロードを修正して再実行してください。そこで止めてユーザーに尋ねないでください。
• トークンでアクセス制限されている機能を持つワーカーで、ジョブがほぼ即座に終了し、出力が空または劣化している → 最初に疑うべきはペイロードではなくアクセス制限です。仮説を立てる前に、ジョブの output / error フィールドをそのまま読み、テンプレート／エンドポイントでトークン環境変数が設定されていたかを確認してください。質問を先送りせず、すでに得られている根拠（ジョブの結果と設定の読み取りで確認できます）に基づいて回答してください。
• Create が 409（名前の衝突）を返す → 新しい短いサフィックスを追加して 1 回再試行してください。それでも衝突する場合は、その旨を伝えて終了してください。
• GGUF リポジトリを vLLM ワーカーで読み込めない → これはエンジンの選択ミスであり、在庫やサイズの問題ではありません。GGUF 対応ワーカーで再プロビジョニングしてください。
• Hub／コミュニティカタログで該当モダリティが見つからない → 「カタログで見つかりませんでした」と報告して終了してください。リポジトリを捏造しないでください。
• 削除が本文なしで 204 を返す → これはエラーではなく成功です。読み戻して確認してください。

ツールの対応付け

機能	ツール
GPU カタログ＋価格＋在庫	list-gpu-types / get-gpu-type（include:["AVAILABILITY"]、product:["SERVERLESS"]）
データセンターごとの GPU 可用性	同じ読み取り（dataCenters[]）；list-data-centers（include:["GPU_AVAILABILITY"]）
GPU タイプごとの、容量のある CUDA バージョン	同じ読み取り（cudaVersions）；マトリックス表示には get-capacity
データセンター	list-data-centers、get-data-center
Hub／コミュニティカタログの閲覧	list-hub-repos（includeConfig:true）
Hub リリースの直接デプロイ	deploy-hub-repo
Hub リリースの固定／履歴の読み取り	list-endpoint-releases
テンプレートの作成	create-template
エンドポイントの作成	create-endpoint
ネットワークボリュームの作成	create-network-volume
マルチ GPU／特定の 1 枚のカードへの固定	set-endpoint-gpus（gpuCount、pools、除外設定）；または gpu.pools と gpu.excludedTypes を併せて指定した update-endpoint
エンドポイントの健全性／ウォームアップ	endpoint-health
ワーカーの一覧表示（ワーカーごとの詳細）	list-endpoint-workers
スモークテスト（終了状態になるまでブロック）	run-endpoint、続けて get-job-status（wait:300000）；ウォーム状態のエンドポイントでジョブが速い場合は runsync-endpoint
ワーカーのログの読み取り	stream-worker-logs（コンテナーのライフサイクルには source=system）
レジストリ認証情報（プライベートイメージ）	create-registry、get-registry
エンドポイント／テンプレートの確認	get-endpoint、get-template
クリーンアップ	delete-endpoint、delete-template、delete-network-volume

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

レポートテンプレート — デプロイの概要

適切なデプロイ概要では、ユーザーに次の内容を伝えます。選択したワーカー／エンジンとその理由、エンドポイント名と ID、読み取ったカタログに記載されている GPU プールとその時間単価、スモークジョブの証拠（ジョブが返した出力を引用または参照）、現在のワーカーの状態、エンドポイントを稼働させ続けた場合のコスト（スケール・トゥ・ゼロまたは $/hr）、および後から削除する方法です。ジョブが最終状態に至る前に待機が終了した場合は、証拠の代わりに、ジョブ ID、送信したペイロード、確認されたワーカーの状態、推奨される次のステップを示します。

契約

全ジャーニーに共通する回答契約（読み取りから確定した事実を示すこと、曖昧な言い方をせず変更を確定すること、変更の対象はこの会話で作成したものに限ること、単独で完結する最終メッセージ、失敗を正直に伝えること、許可されたツールのみを使うこと）は、runpod-mcp スキルで定義されており、このジャーニーのすべての返信に適用されます。この会話で runpod-mcp スキルが読み込まれていない場合は、次にツールを呼び出す前に、今すぐ読み込んでください。変更可能なリソース、リクエストが実行可能となる条件、ユーザーへの確認を求めて停止するタイミングに関するルールは、ここでは繰り返しません。