runpodctl

Runpodctl

GPU Pod、サーバーレスエンドポイント、テンプレート、ボリューム、モデルを管理します。

サーバーレス開発ワークフローでは、CLI のバージョンにかかわらず Runpod SDK を使用してください。

インストール

curl -sSL https://cli.runpod.net | bash（Linux/macOS、および WSL 経由の Windows）または brew install runpod/runpodctl/runpodctl を実行します。手動でのバイナリのインストール方法と、Windows および conda の手順は、それらで説明されている install.sh とともに、runpodctl README に記載されています。コマンドの一覧は、バイナリ（runpodctl <resource> <action> --help）または runpodctl/docs/ 配下の生成済みページで確認できます。

古い runpodctl ビルドでは、新しいフラグや動作が気付かれないまま利用できない場合があります（例：v2.4.0 より前には --model-reference が存在しません）。そのため後続処理で分かりにくいエラーが発生することがあり、Homebrew のタップも大幅に遅れている場合があります。したがって、作業を始める前に次のことを行ってください。

• 最新のビルドに更新する — runpodctl version で確認してから、runpodctl update を実行します（または最新リリースから再インストールします）。
• タスク全体を通して、最近のバージョンを1つに固定します。
• タスクの途中で古いバイナリと新しいバイナリを切り替えないでください（この切り替えは既知の失敗原因です）。
• 一度確認する — 続行する前に runpodctl version で現在のビルドを確認します。

クイックスタート

runpodctl update                    # FIRST: get on the latest build — old versions cause confusing errors
runpodctl version                   # confirm the current version before doing any work
export RUNPOD_API_KEY=your_key      # Non-interactive auth (agents) — runpodctl reads this
runpodctl doctor                    # Interactive first-time setup (API key + SSH) — for humans
runpodctl --help                    # See current top-level commands
runpodctl pod create --help         # Inspect exact current flags before creating
runpodctl gpu list                  # See available GPU types
runpodctl datacenter list           # GPU availability per data center (use to co-locate GPU + volume)
runpodctl hub search vllm           # Find a hub repo
runpodctl serverless create --hub-id <id> --name "my-vllm"  # Deploy from hub
runpodctl template search pytorch   # Find a template
runpodctl pod create --template-id runpod-torch-v280 --gpu-id "NVIDIA GeForce RTX 4090" --min-cuda-version 12.8  # Create from template
runpodctl pod list                  # List your pods

認証：エージェントは（対話形式ではなく）export RUNPOD_API_KEY=... を実行してください。runpodctl doctor は対話形式（プロンプトを表示）で、SSH キーも設定します。人が初めて実行する場合には適していますが、スクリプトからの使用には適していません。

API キー：https://console.runpod.io/user/settings

ライブヘルプを優先する

ライブの runpodctl --help の出力は、正確なフラグ、エイリアス、コマンド構文を確認する際の正式な情報です。このスキルは、ワークフロー、判断基準、安全上の注意、一般的な例の確認に使用してください。

runpodctl --help
runpodctl <resource> --help
runpodctl <resource> <action> --help

使い慣れていないコマンドを使用する前に、まずライブヘルプを確認してください。このスキルを、フラグを網羅したリファレンスとして頼らないでください。

ライブヘルプで確認できない内容： 出力形式、エラーコード、終了コードの動作です。--help に表示されるのはフラグであり、失敗時の出力は表示されません。これらについては reference/output-and-errors.md を参照してください。判断に迷った場合は、バイナリを実際に試してください。コマンドを意図的に間違えて実行し（runpodctl serverless get nope）、出力される JSON を確認します。ドキュメントはすべてスナップショットであり、このスキルも例外ではありません。目の前にあるバイナリの情報を優先してください。

出力とエラー

データは 標準出力に JSON 形式で出力されます（唯一の代替形式は --output=yaml です。テーブル形式はありません。それ以外を指定した場合は、何も通知されずに JSON が返されます）。リソースコマンドが失敗すると、標準エラー出力に単一のフラットな JSON オブジェクトが出力され、終了コードはゼロ以外になります。

{"error":"failed to get endpoint: endpoint not found","code":"not_found","status":404}

分岐には status やメッセージではなく、必ず code を使ってください。 status があるのは、2xx 以外のレスポンスで失敗した場合だけです。GraphQL ではリソースが見つからない場合でも、HTTP 200 と null のデータが返されるため、if status == 404 では GraphQL の not-found をすべて見逃します。

code	対応方法
network_error	バックオフを入れて再試行 —「API に接続できなかった」を意味する唯一のコードです
rate_limited server_error	バックオフを入れて再試行 — API からの 429／5xx です
usage_error cli_error bad_request not_found conflict	再試行せず、入力を修正してください
no_credentials	キーが設定されていません：export RUNPOD_API_KEY=… または runpodctl doctor
unauthorized forbidden	キーは設定されていますが、誤っている、期限切れ、またはアクセス権がありません — 再試行せず、キーの入力を再度求めないでください
その他	致命的なエラーとして扱い、error の内容をそのまま表示してください — API 独自のコードが渡される場合があります

runpodctl は内部で再試行しません。バックオフも行いません。

• not_found は、常に API にリソースがないことを意味します。ローカルパスの入力ミスではありません（その場合は cli_error です）。
• cli_error は複数の種類のエラーを含みます。 ローカル環境の問題と、コマンド自体が検証する実行時の誤り（例：--name も --fingerprint も指定せずに ssh remove-key を実行する場合）の両方です。cobra が必須とするフラグのみが usage_error です。
• usage_error = 不明なコマンド／フラグ、不正な引数、cobra が必須とするフラグの不足です。使用方法のテキストは JSON の後に出力されます。実行時エラーでは、使用方法は表示されなくなりました。
• 標準エラー出力が空でなくても、失敗とは限りません — 非推奨を示す warning: や note: の行は、成功時にも標準エラー出力に出力されます。終了コードで判定してから、標準エラー出力を解析してください。

コード付きエラー、サーバーレスの urls オブジェクト、GPU の料金情報には、いずれも runpodctl ≥ v2.8.0 が必要です。それより古いバイナリでは、code と status を含まない {"error":"…"} が出力されます。これは JSON 形式なので、switch (err.code) を使うと、明確なエラーにならず undefined になります。JSON かプレーンテキストかではなく、code が存在するかどうかを判定してください。ソースビルドやカスタムビルドでは、リリース済みのバージョンやプレースホルダーが報告される場合があるため、runpodctl version による判定は信頼できません。

project の動作はビルドによって異なります。 v3.0.1 までのリリース版では、実行時エラーが標準出力に出力され、終了コードは 0 になるため、出力を確認してください。未リリースの runpod/runpodctl#382 を含むビルドでは、サブコマンド、エイリアス、フラグを含む runpodctl project ... の呼び出しは終了コード 1 となり、標準出力は空のまま、Runpod SDK の通知が標準エラー出力に出力されます。project --help、help project、-h project、--help project のようなヘルプ形式も同じ仕様です。この通知を致命的なエラーとして扱い、内容をそのまま表示してください。再試行したり、JSON を要求したりしないでください。runpodctl version を確認してください。ただし、ソースビルドやカスタムビルドではバージョン文字列がリリース版と一致する場合があるため、コミットも確認してください。

コード一覧、プレーンテキストの例外、Runpod SDK の正確な通知内容、環境変数の一覧（RUNPOD_INVOKE_URL を含む）については、 reference/output-and-errors.md を参照してください。

判断ルール

• vLLM、ComfyUI、Whisper、Runpod が管理するリポジトリなど、よく知られたデプロイ可能なアプリやワーカーをユーザーが求めている場合は、Hub を使います。
  • ワーカーの選択： ファーストパーティ製、または広く採用され、最近リリースされたワーカーを、幅広い高可用性 GPU プールで優先します。runpodctl hub list で確認できる指標：--owner runpod-workers（ファーストパーティ）、--order-by releasedAt／updatedAt（新しさ）、--order-by deploys／stars（採用状況）。小規模なモデルに不要な、希少な大容量 GPU のティアを固定しないでください。
• 「アクティブなワーカー」とは、最大数ではなく最小数を意味します。 ユーザーが「アクティブなワーカー」を求めている場合、意味するのは --workers-min 1（常にワーカーを1つウォーム状態に保ち、コールドスタートをなくす）であり、--workers-max 1（上限を設定するだけ）ではありません。最小数を1にしたウォームワーカーは、開発や反復作業に最適です。
• ⚠️ 最小数を1にしたワーカーは、アイドル状態でも継続的に課金されます（ゼロまでスケールする動作が無効になります）。開発のために --workers-min 1 を設定した場合は、作業が終わったら必ず --workers-min 0 に戻すか、エンドポイントを削除してください。そうしないと、気付かないうちに料金がかさみます。
  • runpodctl ≥ v2.10.0 が必要です。 それ以前のバイナリでは、omitempty によって --workers-min 0 と --idle-timeout 0 が更新リクエストから黙って除外されていました。そのため、リセットが適用されたように見えても、エンドポイントは課金され続けていました。runpodctl version で確認してください。古いバイナリの場合は、serverless get <id> で確認し、PATCH https://api.runpod.io/v2/serverless/<id> に明示的な {"workers":{"min":0}} を指定してフォールバックしてください。
• serverless update に --gpu-id フラグはありません。既存のエンドポイントの GPU プールを変更するには、プール ID（GET /v2/catalog/gpus の pool フィールドから取得）を使い、PATCH https://api.runpod.io/v2/serverless/<id> に {"gpu":{"pools":["ADA_24"]}} を直接指定してください。excludedTypes を指定せずに pools を送信すると、すべての除外設定が解除されます。
• CPU サーバーレスエンドポイント： runpodctl serverless create --compute-type CPU を使うか、REST v2 の POST https://api.runpod.io/v2/serverless に gpu の代わりに cpu ブロックを指定して作成してください。REST v1 の POST https://rest.runpod.io/v1/endpoints に "computeType":"CPU" を絶対に送信しないでください。誤って GPU エンドポイントがプロビジョニングされることが確認されています（以下の Serverless コマンドのセクションに検証済みの証拠があります）。
• ユーザーがすでにテンプレート ID を持っている場合、再利用可能なイメージや設定のデフォルトを求めている場合、または Hub より細かな制御が必要な場合は、テンプレートを使います。
• ユーザーが特定の Docker イメージを使い、保存済みテンプレートを必要としていない場合は、--image を指定して Pod を直接作成します。
• リクエスト／レスポンス型の推論 API やスケーラブルなワーカーにはサーバーレスを、対話型の作業、ノートブック、トレーニング、デバッグ、または長時間のセッションには Pod を使います。
• 前処理、ファイル移動、軽量スクリプト、CUDA を使わない作業には CPU Pod を使います。CUDA、モデル推論、トレーニング、または GPU メモリが必要な場合は GPU Pod を使います。
• --cloud-type はデフォルトの SECURE のままにします。 Community Cloud のホストは承認済みベンダーです。Secure Cloud のホストはデータセンター品質のプロバイダーであるため、より安定した動作が見込めます。ユーザーが明示的に求めた場合にのみ --cloud-type COMMUNITY を指定してください（そこでポート 22 を公開するにはパブリック IP を持つマシンが必要ですが、CLI からは要求できません）。
• CPU Pod は、最も在庫の多い CPU の種類で 2 vCPU を割り当てられます。--name のデフォルトは、タグを除いたイメージ名です。CPU Pod にはネットワークボリューム（--network-volume-id）を指定できますが、Pod ボリュームは指定できません（--volume-in-gb は拒否されます）。GPU フラグは指定しないでください。
• すべての GPU 作成時に CUDA の下限として --min-cuda-version 12.8 を設定します。 このオプションは pod create と serverless create にあります（template create にはありません）。最新のイメージが実行に古すぎるホストで動作しないようにする唯一の方法です。この組み合わせは作成時に拒否されず、コンテナは起動時に終了するか、黙って CPU にフォールバックします。13.0 を使うのは、イメージが CUDA 13 ビルド（runpod/comfyui:cuda13.0、cu1300 クラスターの PyTorch イメージ）の場合のみです。CPU Pod、または意図的に古いイメージでは省略してください。完全なルール、allowedCudaVersions の完全一致版、および容量の確認方法については、runpod-usage gpu-selection "pin the CUDA floor" を参照してください。
• リソースが利用可能になるまで待つ場合は、ポーリングループを自作せず、--wait を使います（v2.9.0 以降）。create はリソースがスケジュール済みになるとすぐに返ります。そのため、「RUNNING」状態の Pod で SSH が拒否されたり、新しいエンドポイントが 404 を返したりすることがあります。pod create --wait はポート 22 が SSH バナーを返すまで待ちます。pod create --wait-for running（v2.15.0 以降）は SSH を必要とせず、コンテナが起動するまで待ちます。タスクに必要なのがコンテナの起動だけの場合や、SSH サーバーを起動しないイメージ（CPU Pod には Runpod 管理の SSH がないため、多くの CPU イメージが該当します）では、通常の --wait がタイムアウトまで課金された後に失敗するため、こちらを使います。独自の SSH サーバーを起動する CPU イメージなら通常の --wait でも条件を満たすため、ユーザーが SSH を必要としている場合はそちらを使い続けてください。serverless create --wait は、/health が準備完了または実行中のワーカーを報告するまで待ちます。タイムアウト時または Ctrl-C を押した場合も、リソースは残ります。その ID はエラーオブジェクトの id フィールドにあるため、値を確認してクリーンアップし、何も作成されなかったと思い込まないでください（Pod は秒単位で課金されます。稼働中のワーカーがいないエンドポイントは課金されませんが、最初のリクエストでワーカーが起動します）。
• Pod 上にサービス（Ollama、ComfyUI、開発サーバーなど）を立ち上げる場合は、可能であれば作成時に --ports と --env を宣言してください。既存の Pod では runpodctl pod update で変更できます。その後、runpod-usage スキルの Pod 開発ワークフロー（reference/pod-workflows.md）に従ってください。SSH 経由でインストールコマンドを実行し、0.0.0.0 にバインドして、プロキシ URL が応答するまでポーリングします。
• SSH には、runpodctl pod get <pod-id> または runpodctl ssh info <pod-id> を使って接続情報を取得してください。runpodctl に対話型シェル用のコマンドはありません。ssh info は接続コマンドとキーを返すだけで、接続はしません。ssh user@host "command" を使って、SSH 経由で自分でコマンドを実行してください。
• ネットワークボリュームを利用できる場所は、ロケーションによって異なります。ボリュームを接続する前にデータセンターでの利用可否を確認し、移行には send／receive または S3 互換ストレージを使ってください。
• テスト後は、有料リソースをクリーンアップしてください。検証用に作成したサーバーレスエンドポイント、Pod、一時ボリュームを削除します。
  • コスト対策： 作業が終わったら Pod を削除します（runpodctl pod remove <pod-id>）。無人で期限を設定する場合は、Pod 内から停止をスケジュールします。Runpod Pod には runpodctl と Pod にスコープされた API キーが用意されています（Manage Pods）。停止した Pod も、ディスクとボリュームの料金は発生します。
  • --stop-after／--terminate-after は一度も機能したことがありません。 v2.12.0 より前の runpodctl は pod create の両フラグを受け付けますが、バックエンドが適用しないため、Pod は期限を過ぎても実行され、課金され続けます。v2.12.0 でこれらのフラグは削除されました。runpodctl pod create --help にまだ表示される場合は、runpodctl update を実行してください。コスト対策としてこれらのフラグを提示しないでください。
  • 接続済みボリューム： ネットワークボリュームを削除するには、まずそれを使用している Pod を削除してください。

サーバーレスの前提（ルールではなく、コンテキストです）

• ゼロスケール課金： サーバーレスエンドポイントは --workers-min 0（デフォルト）でゼロまでスケールします。アイドル中の GPU 課金はなく、リクエスト秒ごとの課金のみです。リクエスト／レスポンス API に適したコスト設定です。
• イメージ不良の兆候： デプロイ済みのワーカーが ready になっているのに、ジョブが IN_QUEUE のままで inProgress: 0 の場合、イメージに問題があるか、ディスパッチが正しく行われていません。待ち続けるのではなく、別のワーカーに切り替えてください。
• 診断方法： runpodctl serverless health <endpoint-id>（v2.9.0+）でワーカー数とジョブ数を確認し、続いて runpodctl serverless logs <endpoint-id>（v2.10.0+）でワーカーが実際に出力した内容を確認します。curl を手作業で組み立てる必要はありません。system の「start container」行が繰り返され、container の出力がない場合、コンテナはハンドラーの実行前に終了しています。

コマンド

以下は基本的なコマンドです。フラグについてはバイナリに問い合わせてください。runpodctl <resource> <action> --help の内容は、常に最新です。reference/command-reference.md には、--help では分からない情報が記載されています。フラグが正常に機能したときの意味、信頼するべきフィールド、失敗時の状態などです。

Pods

runpodctl pod list                                   # running pods (+ --all / --status / --since / --created-after)
runpodctl pod get <pod-id>                           # details incl. SSH info + runtimeStatus
runpodctl pod create --template-id <id> --gpu-id "NVIDIA GeForce RTX 4090" --min-cuda-version 12.8   # from template
runpodctl pod create --image <img> --gpu-id "NVIDIA GeForce RTX 4090" --min-cuda-version 12.8        # from image
runpodctl pod create --compute-type cpu --image ubuntu:22.04                 # CPU pod (2 vCPUs; name defaults to the image)
runpodctl pod create --image <img> --gpu-id <id> --wait                      # block until ssh answers, then print the pod (v2.9.0+)
runpodctl pod create --compute-type cpu --image ubuntu:22.04 --wait-for running  # block until the container is up; no sshd needed (v2.15.0+)
runpodctl pod {start|stop|restart|update|delete} <pod-id>                    # lifecycle (delete aliases: rm/remove; no reset in v3)
runpodctl pod logs <pod-id>                          # recent container+system logs, json lines (v2.10.0+)
runpodctl pod logs <pod-id> --follow                 # keep streaming, reconnects on its own
runpodctl pod logs <pod-id> --since 30m --source system   # platform view: image pull / create / start

runpodctl v3.0.0 で pod reset は削除されました。再起動が必要な場合に限り、pod restart を使用してください。

デプロイの停滞は --source system に表示されます（v2.10.0+）。プルの進行状況が繰り返し表示される場合や、create container が start に到達しない場合です。ワークロード自体の出力には --source container を使用してください。各行は 1 つの {source,line,ts} オブジェクトなので、そのまま jq にパイプできます。

Pod が使用可能かどうかは desiredStatus ではなく runtimeStatus を確認してください（v2.9.0+）。イメージのプル中でも、desiredStatus: RUNNING と表示されます。各フィールドの意味、理由を示すトークン、および 2 つの注意点（--status でフィルターされるのは desiredStatus のみ、unknown は Pod の停止ではなく検索の失敗を示します）→ reference/command-reference.md。

Hub

既存の Runpod Hub のリスティングを参照・検索します。実行レーンはルーターの機能マトリックスを使って選択してください。

プロジェクトの Hub リスティングファイルを作成する場合は、 runpod-build-template を使用してください。

runpodctl hub search vllm                            # find a repo (+ hub list [--type/--category/--order-by/--owner])
runpodctl hub get <listing-id|owner/name>            # repo details

Serverless（エイリアス：sls）

runpodctl serverless list | get <endpoint-id> | delete <endpoint-id>
runpodctl serverless create --name "x" --template-id <id> --min-cuda-version 12.8   # from template
runpodctl serverless create --name "x" --hub-id <listing-id>    # from hub (+ --env KEY=VAL to override defaults)
runpodctl serverless create --hub-id <id> --gpu-id "NVIDIA GeForce RTX 4090" \
  --model-reference https://huggingface.co/<org>/<model>:main   # attach & host-cache a HF model (GPU only)
runpodctl serverless update <endpoint-id> --workers-max 5
runpodctl serverless create --template-id <id> --workers-min 1 --wait          # block until a worker is ready (v2.9.0+)

エンドポイントとともに呼び出し用 URL が返されます。 create／get／list／update には urls オブジェクト（run、runsync、health）が含まれるため、新しく作成したエンドポイントは、再度検索することなく呼び出せます。自分で URL を組み立てず、返された URL を参照してください。これらの URL は RUNPOD_INVOKE_URL（デフォルトは https://api.runpod.ai/v2）を基に生成されますが、RUNPOD_API_URL／RUNPOD_GRAPHQL_URL を変更しても変わりません。reference/output-and-errors.md を参照してください。

ワーカーログの読み取り（v2.10.0+）も標準機能です。そのため、ワーカーの出力を確認するために MCP レーンを使ったり、SSE 読み取りを手作業で組み立てたりする必要はなくなりました。

runpodctl serverless logs <endpoint-id>                       # every worker's recent logs, json lines
runpodctl serverless logs <endpoint-id> --worker <worker-id>  # just one worker
runpodctl serverless logs <endpoint-id> --follow              # picks up workers that scale up mid-follow
runpodctl serverless logs <endpoint-id> --since 1h --source system   # why a worker will not start

ログはエンドポイントではなくワーカーに属します。そのため、--worker を指定しない場合は、すべてのログが一度に読み取られ、各行に workerId が付与されます。クラッシュループの兆候： system の「start container」行が繰り返され、container の出力がない場合、コンテナはハンドラーの実行前に終了しています。この場合、容量に問題がなくてもジョブはキューに滞留します。

エンドポイントの呼び出し（v2.9.0+）は標準コマンドで実行できるため、エージェントが curl リクエストを手作業で組み立てたり、ベアラートークンを管理したりする必要はありません。

runpodctl serverless run <endpoint-id> --input '{"prompt":"hello"}'   # submit and wait for the result
runpodctl serverless run <endpoint-id> --input-file payload.json      # same, payload from a file ("-" = stdin)
runpodctl serverless run <endpoint-id> --input '{}' --wait 15m        # longer budget (default 5m)
runpodctl serverless run <endpoint-id> --input '{}' --no-wait         # submit, print the queued job, exit 0
runpodctl serverless status <endpoint-id> <job-id>                    # check a job submitted earlier
runpodctl serverless health <endpoint-id>                             # worker + job counts

• ハンドラーに渡すペイロードだけを指定してください。 CLI が自動的に {"input": <your json>} でラップするため、curl のエンベロープ全体を貼り付けると二重にラップされます。
• timeout は CLI が待機を打ち切ったことを意味し、エンドポイントの障害を意味するものではありません。 メッセージに serverless status コマンドが示されている場合、ジョブはサーバー側でまだ実行中です。再度呼び出すとジョブがもう 1 つ作成されるため、再呼び出しせず、ポーリングしてください。

ペイロードのルール、標準出力と標準エラー出力の分離、終了コード、/runsync が使用されない理由については、reference/command-reference.md を参照してください。 Hub から作成： --hub-id は Hub の一覧を解決し、ビルドイメージと設定（GPU ID、コンテナディスク、環境変数）を抽出して、インラインテンプレートを作成し、デプロイします。SERVERLESS と POD の両方の一覧タイプに対応しています。Hub の設定にある GPU ID と環境変数のデフォルト値は自動的に含まれます。--gpu-id と --env で上書きできます。

CPU サーバーレスエンドポイント（常時／禁止のルールについては上記の「Decision Rules」を参照）：runpodctl serverless create --compute-type CPU で作成します（必要に応じて --instance-id を指定します。例：cpu3g-4-16）。REST v1 を使用してはいけない理由を示す検証済みの証拠：2026-07-14 に、"computeType":"CPU" を指定した POST https://rest.runpod.io/v1/endpoints は、GPU エンドポイント（gpuCount:1、cpuFlavorIds:null）を何も通知せずに返しました。一方、runpodctl --compute-type CPU は computeType:"CPU" と instanceIds:["cpu3g-4-16"] を正しく返しました。REST v2（POST https://api.runpod.io/v2/serverless）では、gpu の代わりに cpu ブロックを使って CPU エンドポイントを表します。別個の ランタイム／呼び出し API https://api.runpod.ai/v2/<endpoint-id>/…（health/run/runsync/openai）は別の v2 で、問題なく動作します。ここでの v1 と v2 の注意点は、制御／管理 REST にのみ当てはまります。

モデルキャッシュ（--model-reference）： 完全な URL に ref を付けて指定し、Hugging Face モデルをエンドポイントにアタッチします。例：https://huggingface.co/Qwen/Qwen2.5-0.5B-Instruct:main。Runpod はホスト側の標準 HF キャッシュディレクトリ（/runpod-volume/huggingface-cache/hub/）にモデルをキャッシュするため、ワーカーはモデルを直接ロードできます。イメージへの組み込みも、ボリュームも不要です。繰り返し利用でき、--template-id／--hub-id に対応しています。GPU のみ、runpodctl v2.4.0 以降で利用できます。仕組みと、イメージへの組み込み／ネットワークボリューム／Model Repository との比較について詳しくは、reference/model-caching.md を参照してください。エンドツーエンドの実例：ゴールデンパス 20 — モデルキャッシュエンドポイント。

マルチリージョン／高可用性（--network-volume-ids）： 複数のネットワークボリューム（データセンターごとに 1 つ）をアタッチし、ワーカーが 1 つの DC に固定されず、複数の DC に分散するようにします。
runpodctl serverless create --template-id <t> --network-volume-ids <v1>,<v2> --data-center-ids <dc1>,<dc2> …
runpodctl ≥ v2.4.0 が必要です（旧バージョンは複数ボリュームのアタッチに対応していません）。runpodctl version で確認してください。Homebrew tap の更新が遅れることがあるため、GitHub releases のバイナリを推奨します。ボリューム間でデータは自動的に同期されません。ゴールデンパス 10 — マルチリージョン HA サーバーレスを参照してください。

サーバーレスの正確なフラグについては、runpodctl serverless <action> --help を実行してください。

serverless update --model-reference は、サーバーで解決された modelReferences を JSON／YAML の出力に含めます。--clear-models は modelReferences: [] を返します。その他の更新ではモデル参照を取得しません。モデル参照を確認するには、serverless model-status <id> を使用してください。

テンプレート（別名：tpl）

runpodctl template search <q>                        # find (+ template list [--type official/community/user, --all, --limit])
runpodctl template get <template-id>                 # details (README, env, ports)
runpodctl template create --name "x" --image "img" [--serverless]
runpodctl template delete <template-id>

ネットワークボリューム（別名：nv）

runpodctl network-volume list                         # List all volumes
runpodctl network-volume get <volume-id>              # Get volume details
runpodctl network-volume create --name "x" --size 100 --data-center-id "US-GA-1"  # Create volume
runpodctl network-volume update <volume-id> --name "new"  # Update volume
runpodctl network-volume delete <volume-id>           # Delete volume

ネットワークボリュームの正確なフラグについては、runpodctl network-volume <action> --help を実行してください。

ストレージ階層のフラグはありません。 create はデータセンターのデフォルト階層をプロビジョニングします。--type はありません。High-Performance ボリュームを使うには、コンソール（⚡ のデータセンターにある切り替えスイッチ）を使うか、v2 の REST 呼び出し（"type":"HIGH_PERFORMANCE" を指定した POST https://v2-rest.runpod.io/v2/network-volumes）を直接実行してください。または、volumeType（STANDARD | HIGH_PERFORMANCE）を受け取る MCP の create-network-volume ツールを使用してください。作成後に階層を変更することはできません。起動方法の詳細：ゴールデンパス 21。

モデル（モデルリポジトリ）

runpodctl model は Runpod Model Repository を管理します。これは、独自のモデルアーティファクトを保存するための、マネージド型のバージョン管理ストレージです（一度アップロードすればワーカーに配布されます。ネットワークボリュームのようにデータセンターに固定されません）。概要、メリットと使い方、イメージに組み込まれたモデルからの移行、モデルリポジトリとボリュームの比較については、reference/model-caching.md を参照してください。

runpodctl model list                                  # List your models
runpodctl model list --all                            # List all models (not just yours)
runpodctl model list --name "llama"                   # Filter by name
runpodctl model list --provider "meta"                # Filter by provider
runpodctl model add --name "my-model" --model-path ./model   # Upload a local model dir (multipart)
runpodctl model remove --name "my-model" --owner <owner>     # Remove a model

model add は、アップロードセッション、バージョン管理、メタデータ、プライベートソースの認証情報に対応しています。詳しくは runpodctl model add --help の最新情報を参照してください。

情報と SSH

runpodctl user                                       # account info + balance (alias: me)
runpodctl gpu list                                   # available GPUs + $/hr + per-DC stock (+ --include-unavailable)
runpodctl datacenter list                            # datacenters (alias: dc)
runpodctl ssh info <pod-id>                          # SSH connection details (command + key; NOT an interactive session)

gpu list には料金と配置データが含まれます。securePricePerHr／communityPricePerHr（そのクラウドで該当の GPU を提供していない場合は明示的に null）と、dataCenterAvailability[] の内訳です。特定の DC で作成をスケジュールする必要がある場合は、トップレベルの stockStatus（DC 全体で最も良い状態のみを示します）だけでなく、内訳を確認してください。また、デフォルトの一覧では在庫のない GPU が非表示になり、希望する DC にのみ在庫がある GPU が表示されないことがあるため、--include-unavailable を指定してください。料金は Pod のオンデマンド料金 です。データ形式、在庫値の表記、"none" とキー省略のセンチネルについては、reference/output-and-errors.md を参照してください。

ssh info は接続情報を返すもので、セッションを開始するものではありません。対話型 SSH を利用できない場合は、ssh user@host "command" を実行してください。レジストリ認証、billing の履歴、SSH キー管理（ssh add-key／remove-key）については、reference/command-reference.md を参照してください。ssh info は、出力を使って接続する OpenSSH クライアントにホストキーの検証を任せます。ホストキーのピン留めは、非推奨の exec python（v2.15.0 以降）とレガシーの project SSH（v2.15.0 から v3.0.1 まで）に適用されます。v2.14.0 以前では、これらの経路でホストキーのチェックが無効になっています。バージョンごとの適用範囲と、ssh forget にオペレーターの承認が必要な理由については、reference/command-reference.md を参照してください。

ファイル転送

runpodctl send <path>                                # prints a one-time code, then blocks until the receiver connects
runpodctl receive <code>                             # positional code (no --code flag)

暗号化・差分転送・圧縮に対応しています。事前に tar でアーカイブしないでください。重要な注意点： send の標準出力の最初の行（コード）を、ストリーム出力中に取得してください（バックグラウンド実行＋tee）。send を実行するたびに新しいコードが発行され、両側で終了コード 0 が必要です。エージェントの一連の操作（ssh で Pod にプッシュし、receive で受信）については、reference/command-reference.md を参照してください。

ユーティリティ

runpodctl doctor                                      # Diagnose and fix CLI issues
runpodctl update                                      # Update CLI
runpodctl version                                     # Show version
runpodctl completion                                  # Auto-detect shell and install completion

URL

Pod の URL

Pod で公開されているポートにアクセスします。

https://<pod-id>-<port>.proxy.runpod.net

例：https://abc123xyz-8888.proxy.runpod.net

Serverless の URL

runpodctl serverless run|status|health（上記）を優先してください。同じ API を使用し、認証、検証、上限付きポーリングを処理します。ストリーミング、OpenAI 互換ルート、ユーザー向けのコピー＆ペースト用 curl など、コマンドでカバーされない用途では、生の URL を使用してください。

https://api.runpod.ai/v2/<endpoint-id>/run        # Async request
https://api.runpod.ai/v2/<endpoint-id>/runsync    # Sync request
https://api.runpod.ai/v2/<endpoint-id>/health     # Health check
https://api.runpod.ai/v2/<endpoint-id>/status/<job-id>  # Job status

serverless create／get／list／update は、すでに urls オブジェクト内に run／runsync／health を返します。デフォルト以外の RUNPOD_INVOKE_URL によってベース URL が変わるため、手動で組み立てるより、これらを優先してください。手動で組み立てる必要があるのは status/<job-id> だけです。

ソースとドキュメント

• CLI のソース：https://github.com/runpod/runpodctl
• リリース（バイナリ）：https://github.com/runpod/runpodctl/releases
• ドキュメント：https://docs.runpod.io/runpodctl/overview