runpod-pod-deploy

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pod deploy

Pod 部署

You provision one Pod the user asked for and hand back exactly how to reach it. Before creating anything you confirm the GPU class has real stock in the data center you place into: the create call places exactly the type you ask for, never falls back to another GPU, and answers 400 when that type cannot be placed. You pick a sensible image and the ports the workload needs (an app UI, Jupyter, SSH), and you return the Runpod proxy URL in its working form. For a training Pod you co-locate a network volume so checkpoints outlive the Pod's container disk.

Creating a Pod is billable. State the hourly cost before you create it. Diagnosing or recovering a Pod that already exists is a different job: that is

runpod-pod-doctor

你部署用户所要求的 Pod，并准确返回其访问方式。创建任何资源之前，先确认目标数据中心中确有用户所需 GPU 规格的库存：create 调用只会部署所请求的类型，绝不回退到其他 GPU；若无法部署该类型，则返回 400。你需选择合适的镜像和工作负载所需的端口（应用 UI、Jupyter、SSH），并返回可直接使用的 Runpod proxy URL。对于训练 Pod，应将 network volume 与 Pod 放在同一位置，使 checkpoint 的保存周期长于 Pod 容器磁盘。

创建 Pod 会产生费用。创建前必须说明每小时费用。诊断或恢复已有 Pod 属于另一项工作：对应

runpod-pod-doctor

。

Tool binding

工具绑定

This skill reads stock before it creates, and creates only the Pod the user asked for. If a tool named here is missing from the session's tool list, say so and use the nearest read instead of inventing a result.

Capability	Tool
GPU stock per data center: confirm the class is available before creating (the fuller catalog read is `runpod-discovery` 's)	`list-gpu-types` / `get-gpu-type` ( `include:["AVAILABILITY"]` , `product:["POD"]` )
CUDA versions with capacity, per GPU type, when a CUDA floor matters	the same read ( `cudaVersions` ); `get-capacity` for the matrix view across host CUDA versions
Data centers	`list-data-centers` , `get-data-center`
Create a network volume: checkpoint durability for training (the CRUD hygiene is `runpod-lifecycle-crud` 's)	`create-network-volume`
Create a Pod (image, GPU or CPU, disk, ports, env, data center, mounts)	`create-pod`
Inspect a Pod: status, exposed ports, the proxy/public address	`get-pod`
List Pods: resolve "which Pod" and confirm what already exists	`list-pods`
Read Pod boot logs: confirm the app came up on the port before handing back a URL	`stream-pod-logs`
Stop a Pod (keep the volume disk): create-then-pause	`pod-action` ( `{"action":"stop"}` )
Resume a stopped Pod	`pod-action` ( `{"action":"start"}` )
Terminate a Pod: cleanup when the user asks for it	`delete-pod`
Account SSH keys	`get-ssh-keys` / `update-ssh-keys`

此 skill 会在创建前读取库存，并且只创建用户所要求的 Pod。如果此处指定的工具未出现在会话的工具列表中，应明确说明，并改用最接近的读取操作，而不是虚构结果。

能力	工具
各数据中心的 GPU 库存：创建前确认该规格可用（更完整的目录读取由 `runpod-discovery` 提供）	`list-gpu-types` / `get-gpu-type` （ `include:["AVAILABILITY"]` ， `product:["POD"]` ）
各 GPU 规格下有容量的 CUDA 版本（当需要设置 CUDA 下限时）	同一次读取（ `cudaVersions` ）； `get-capacity` 可查看各主机 CUDA 版本的矩阵视图
数据中心	`list-data-centers` 、 `get-data-center`
创建 network volume：为训练提供持久化 checkpoint（CRUD 管理规范见 `runpod-lifecycle-crud` ）	`create-network-volume`
创建 Pod（镜像、GPU 或 CPU、磁盘、端口、环境变量、数据中心、挂载）	`create-pod`
检查 Pod：状态、已开放端口、proxy/公共地址	`get-pod`
列出 Pod：确定是哪个 Pod，并确认已存在哪些资源	`list-pods`
读取 Pod 启动日志：在交付 URL 前确认应用已监听端口	`stream-pod-logs`
停止 Pod（保留 volume disk）：先创建再暂停	`pod-action` （ `{"action":"stop"}` ）
恢复已停止的 Pod	`pod-action` （ `{"action":"start"}` ）
终止 Pod：用户要求清理时执行	`delete-pod`
账户 SSH 密钥	`get-ssh-keys` / `update-ssh-keys`

Phase 1 — confirm stock and shape the Pod

阶段 1 — 确认库存并确定 Pod 配置

Read GPU availability for the class the workload needs before creating.
```
include:["AVAILABILITY"]
```
together with
```
product:["POD"]
```
(the two go together, and stock differs by product) carries the per-data-center picture, so the data center you place into is read, not assumed. If the class has no stock there, say so and offer another class or data center; do not create into an unavailable class.
Pick the image for the use: an interactive app (e.g. a ComfyUI or PyTorch image) for dev, a CUDA/PyTorch base for training. Match the image's CUDA to what the GPU class supports, and pin it as a floor on the create:
```
gpu.minCudaVersion
```
at the image's CUDA line (12.8 for a CUDA 12 image; 13.0 only for an image built on CUDA 13), so the Pod lands on a host whose driver supports the image. A template's
```
allowedCudaVersions
```
seeds the floor; an explicit
```
gpu
```
field on the create replaces the seed, and the availability read's
```
cudaVersions
```
says whether that floor has stock.
The image comes from this session's reads, not memory. For a named app (ComfyUI, Jupyter, a specific stack), resolve the image from the templates / Hub-repos read you just made and cite that source when you pick it. An image already running on the account (visible in a
```
list-pods
```
read) is also a session-read source worth checking when the catalog comes up empty; cite the pod you saw it on. Only when the catalog has no match may you fall back to a well-known public image, and then say so explicitly in the answer. A from-memory image tag is how you get a stale image that crash-loops on boot. Runpod publishes no
```
:latest
```
tags, so pin an exact tag; for GPU work prefer the
```
runpod/pytorch
```
images over
```
runpod/base
```
.
Decide the ports from the workload: the app's own port over HTTP for a web UI,
```
8888/http
```
for Jupyter,
```
22/tcp
```
for direct SSH. SSH also needs
```
startSsh: true
```
at create and a key registered on the account (check
```
get-ssh-keys
```
first); without both the Pod has no SSH access whatever its ports. Only expose what the user needs to reach.
State the cost. Quote the GPU's hourly rate from the catalog read before creating. A running Pod bills whether or not the user is using it.

在创建前，读取工作负载所需 GPU 规格的可用性。
```
include:["AVAILABILITY"]
```
必须与
```
product:["POD"]
```
一起使用（两者缺一不可，而且库存会因 product 而异），这样才能获得各数据中心的情况；因此，部署所在数据中心必须经过读取确认，不能凭假设决定。如果该数据中心没有此规格的库存，应说明情况，并提供其他 GPU 规格或数据中心；不要向不可用规格部署。
根据用途选择镜像：开发用途使用交互式应用镜像（例如 ComfyUI 或 PyTorch 镜像），训练用途使用 CUDA/PyTorch 基础镜像。使镜像的 CUDA 与 GPU 规格支持的版本相匹配，并在 create 时将其固定为下限：按镜像的 CUDA 版本设置
```
gpu.minCudaVersion
```
（CUDA 12 镜像为 12.8；仅基于 CUDA 13 构建的镜像为 13.0），从而确保 Pod 落在驱动程序支持该镜像的主机上。模板的
```
allowedCudaVersions
```
会提供初始下限；create 中显式指定的
```
gpu
```
字段会替换该初始值，而可用性读取中的
```
cudaVersions
```
会说明该下限是否有库存。
镜像来自本次会话的读取结果，而不是凭记忆。 对于指定的应用（ComfyUI、Jupyter、某个特定技术栈），应从刚刚完成的 templates / Hub-repos 读取结果中解析镜像，并在选择时注明来源。账户中已在运行的镜像（在
```
list-pods
```
读取结果中可见）也是值得检查的会话读取来源，尤其是在目录为空时；应注明你是在哪个 Pod 上看到它的。只有当目录中没有匹配项时，才可以回退到广为人知的公共镜像，并必须在回答中明确说明。凭记忆使用镜像 tag 会导致镜像版本过旧，并在启动时陷入 crash-loop。Runpod 不发布
```
:latest
```
tag，因此应固定精确 tag；对于 GPU 工作，优先使用
```
runpod/pytorch
```
镜像，而不是
```
runpod/base
```
。
根据工作负载决定端口：Web UI 使用应用自身通过 HTTP 提供的端口，Jupyter 使用
```
8888/http
```
，直接 SSH 使用
```
22/tcp
```
。SSH 还要求在 create 时设置
```
startSsh: true
```
，并在账户中注册密钥（先检查
```
get-ssh-keys
```
）；缺少任意一项，即使开放了相应端口，Pod 仍无法通过 SSH 访问。仅开放用户实际需要访问的端口。
说明费用。 创建前引用目录读取结果中的 GPU 每小时费率。Pod 无论用户是否正在使用都会计费。

Phase 2 — create and connect

阶段 2 — 创建并连接

Interactive / dev Pod. Create the Pod with the chosen image, GPU class, disk, ports, and data center. After it reaches running, inspect it and read back the exposed ports and the live mappings. The Pod's
```
runtime.ports
```
stay empty while the container initializes, so poll until they are populated before handing back a URL. App images are large and can take minutes to pull. A slow boot is NOT a failure: never create a second Pod because the first is still pulling. State the proxy URL form (
```
https://<podId>-<port>.proxy.runpod.net
```
) as soon as the Pod id exists. If the app has not bound after the waits your tools can hold, deliver the evidenced status report (pod id, state, last log line) and the recommended next step; offering to keep watching is fine. The reachable form for an HTTP port is the proxy URL
```
https://<podId>-<port>.proxy.runpod.net
```
. For SSH, hand back the Pod's
```
ssh
```
block:
```
ssh.direct
```
(needs
```
22/tcp
```
; full SSH including scp and rsync) or, on a machine with no public IP,
```
ssh.proxy
```
(interactive shell only).
```
ssh.direct
```
can appear minutes after RUNNING and changes on every stop/start, so say so when it is missing. Confirm the app bound (read the boot log for the "listening on 0.0.0.0:PORT" line) before telling the user it is reachable.
Create then stop for later. When the user wants the Pod created but not running yet, create it, confirm it reached running, then STOP it. Never terminate: terminate deletes the volume disk the user wants to keep. After the stop, state the consequences: compute billing ends and the GPU is released; the stop clears the container disk, while the volume disk (
```
/workspace
```
by default) survives and bills at the stopped-disk rate until the Pod is terminated; the Pod stays on its machine and resumes there, so if another renter takes that GPU in the meantime a start can be refused for lack of a free GPU on that host, or come back without one; anything on a network volume is unaffected. Tell the user how to resume (start the Pod) and what to do if the GPU is gone: wait and retry, start with zero GPUs to reach the files, or migrate the Pod from the console (
```
runpod-pod-doctor
```
covers that).
Training Pod with durable checkpoints. Checkpoints written to container disk die with the Pod, so co-locate a network volume. Create the volume in the same data center you will place the Pod (see
```
runpod-lifecycle-crud
```
; network volumes attach to Secure Cloud Pods only, so the Pod goes to Secure Cloud). Then create the Pod with that volume mounted at a checkpoint path (e.g.
```
/workspace
```
or
```
/checkpoints
```
) and pin the Pod to that data center. Tell the user the mount path and that checkpoints there survive the Pod being stopped or terminated, while container disk does not. Size the volume to the expected checkpoint total with headroom. On a Pod the mount path is the one you set in
```
mounts
```
(no default); a Serverless worker always sees the volume at
```
/runpod-volume
```
. If these checkpoints will later be read by a serverless endpoint, its handler must read them at
```
/runpod-volume
```
, not the pod path.

交互式/开发 Pod。 使用选定的镜像、GPU 规格、磁盘、端口和数据中心创建 Pod。Pod 达到 running 后，检查它并回读已开放的端口和实时映射。容器初始化期间，Pod 的
```
runtime.ports
```
会保持为空，因此应持续轮询，直到其有值，再交付 URL。应用镜像体积较大，拉取可能需要数分钟。启动缓慢不是故障：绝不能因为第一个 Pod 仍在拉取就创建第二个。Pod id 一旦生成，即可说明 proxy URL 的形式（
```
https://<podId>-<port>.proxy.runpod.net
```
）。如果经过工具可承受的等待时间后，应用仍未绑定端口，应提供有读取证据支持的状态报告（Pod id、状态、最后一行日志）以及建议的下一步；也可以提出继续监控。HTTP 端口的可访问形式是 proxy URL：
```
https://<podId>-<port>.proxy.runpod.net
```
。对于 SSH，应返回 Pod 的
```
ssh
```
配置块：
```
ssh.direct
```
（需要
```
22/tcp
```
；支持包括 scp 和 rsync 在内的完整 SSH），或者在用户机器没有公共 IP 时使用
```
ssh.proxy
```
（仅限交互式 shell）。
```
ssh.direct
```
可能在 RUNNING 数分钟后才出现，并且每次停止/启动后都会变化，因此当它缺失时应向用户说明。确认应用已绑定（在启动日志中查找“listening on 0.0.0.0:PORT”这一行）后，再告知用户 Pod 可以访问。
先创建再停止，留待以后使用。 当用户希望先创建 Pod、暂不运行时，先创建，确认其已达到 running，然后停止它。绝不能终止：终止会删除用户希望保留的 volume disk。停止后应说明其影响：计算计费结束，GPU 被释放；停止会清除容器磁盘，而 volume disk（默认位于
```
/workspace
```
）会保留，并按停止状态下的磁盘费率计费，直至 Pod 被终止；Pod 会留在其所在机器上并原地恢复，因此如果在此期间另一租户占用了该 GPU，启动时可能因主机没有空闲 GPU 而被拒绝，也可能在没有 GPU 的情况下返回；network volume 上的任何内容均不受影响。告知用户如何恢复（启动 Pod），以及 GPU 不在时该怎么办：等待后重试、以零 GPU 启动以访问文件，或从控制台迁移 Pod（
```
runpod-pod-doctor
```
负责此场景）。
带持久化 checkpoint 的训练 Pod。 写入容器磁盘的 checkpoint 会随 Pod 消失，因此应将 network volume 与 Pod 放在同一位置。在计划部署 Pod 的同一数据中心创建 volume（见
```
runpod-lifecycle-crud
```
；network volume 只能挂载到 Secure Cloud Pods，因此 Pod 必须部署到 Secure Cloud）。然后创建 Pod，将该 volume 挂载到 checkpoint 路径（例如
```
/workspace
```
或
```
/checkpoints
```
），并将 Pod 固定到该数据中心。告知用户挂载路径，并说明其中的 checkpoint 会在 Pod 停止或终止后继续存在，而容器磁盘上的内容不会。volume 容量应按预期 checkpoint 总量并预留余量进行配置。在 Pod 上，挂载路径就是
```
mounts
```
中设置的路径（没有默认值）；Serverless worker 始终在
```
/runpod-volume
```
看到该 volume。如果这些 checkpoint 后续将由 Serverless endpoint 读取，其 handler 必须从
```
/runpod-volume
```
读取，而不能使用 Pod 路径。

Phase 3 — hand back

阶段 3 — 交付

The hand-back lives in your FINAL message and stands alone (router contract). It carries the Pod id, the exact image it runs and which template/Hub read it came from, the GPU class WITH the stock evidence that justified it (quote the availability read: "RTX 3090 — N available in EU-RO-1"), the reachable URL(s) verbatim (the full proxy URL for HTTP, the
```
ssh
```
connect string for SSH; never "the link above", and never the boot log's internal
```
0.0.0.0:<port>
```
address, which is not a reachable URL) with the note that a proxy URL is public and unauthenticated by default (anything sensitive behind it needs its own authentication), the mount path if a volume was attached, and the Pod's state with the hourly cost that is now running. For a stopped Pod, always include the billing consequence with the state: GPU billing ended, the volume disk bills at the stopped rate until the Pod is terminated, and a network volume bills from creation until it is deleted whatever the Pod does.
Cleanup. The default is to keep the Pod the user asked for and tell them what is billing and how to stop it (stop keeps the volume disk and bills it at the stopped rate; terminate deletes the volume disk; a network volume survives either and bills until it is deleted). Tear down (and delete any volume created only for the exercise) only when the user framed the journey as a throwaway test or asks for cleanup, confirming by a read-back. When the user framed the Pod as a trial to be removed once it runs, the proof is your own reads: the Pod RUNNING with its port mapped, and the app's listening line in the boot log. Once you have both, terminate the Pod in the same turn, confirm by a read that it is gone, and report the proof you saw. Do not end the turn waiting for the user to try the URL.

交付信息应位于你的 FINAL 消息中，并能脱离上下文独立阅读（router contract）。其中应包含 Pod id、其运行的确切镜像及镜像来自哪个 template/Hub read、GPU 规格以及证明选择合理的库存证据（引用 availability read：“RTX 3090 — EU-RO-1 中有 N 个可用”）、原样提供的可访问 URL（HTTP 使用完整 proxy URL，SSH 使用
```
ssh
```
连接字符串；绝不能写“见上方链接”，也绝不能提供启动日志中的内部地址
```
0.0.0.0:<port>
```
，因为它不是可访问 URL），并说明 proxy URL 默认公开且无认证（其后承载的任何敏感内容都需要自己的认证机制）。还应提供挂载路径（如果挂载了 volume）、Pod 状态，以及当前运行所产生的小时费用。对于已停止的 Pod，始终应随状态说明计费影响：GPU 计费已结束，volume disk 按停止状态下的费率计费直至 Pod 被终止，而 network volume 从创建开始一直计费，直至被删除，与 Pod 状态无关。
清理。 默认保留用户要求的 Pod，并告知用户当前什么资源正在计费以及如何停止它（停止会保留 volume disk，并按停止状态下的费率对其计费；终止会删除 volume disk；network volume 在这两种情况下都会保留，并持续计费直至被删除）。只有当用户明确表示这是一次性测试或要求清理时，才拆除资源（并删除仅为此测试创建的 volume），且需通过回读确认。当用户将 Pod 定义为运行成功后即移除的试用资源时，证据应来自你自己的读取：Pod 状态为 RUNNING、端口已映射，并且启动日志中有应用监听行。获得这两项证据后，在同一轮中终止 Pod，再通过读取确认它已消失，并报告你看到的证据。不要结束本轮并等待用户试用 URL。

Hard rules

硬性规则

Confirm stock before creating. Never create into a GPU class with no availability.
State the hourly cost before creating any Pod, and before creating a network volume.
Create only the Pod the user asked for. Never stop, terminate, or modify a Pod (or volume) the user did not name.
Do not hand back a proxy URL until the Pod is fully running and the app has bound to the port. Empty
```
runtime.ports
```
mean it is still initializing, not broken.
For training, checkpoints must land on a network volume, not container disk; otherwise a stop/terminate loses them.
Expose only the ports the workload needs. Do not open SSH (
```
22/tcp
```
,
```
startSsh
```
) or extra ports the user did not ask for.
Never claim a Pod is reachable on the create call alone; read back its state first.

创建前确认库存。绝不能向没有可用库存的 GPU 规格部署。
创建任何 Pod 前说明每小时费用，创建 network volume 前也必须说明费用。
只创建用户所要求的 Pod。绝不能停止、终止或修改用户未指定的 Pod（或 volume）。
在 Pod 完全运行且应用已绑定端口之前，不要交付 proxy URL。
```
runtime.ports
```
为空表示仍在初始化，而不是发生故障。
对于训练，checkpoint 必须存放在 network volume 上，而不是容器磁盘；否则停止或终止会丢失 checkpoint。
仅开放工作负载所需的端口。不要开放用户未要求的 SSH（
```
22/tcp
```
、
```
startSsh
```
）或其他端口。
绝不能仅凭 create 调用就声称 Pod 可以访问；必须先回读其状态。

Error handling

错误处理

Create returns
```
400
```
with a placement or stock error → the class ran out in that data center between the read and the create; surface it and offer another class or data center rather than retrying the same one. The same 400 ("no instances available") also answers an invalid GPU type id; check the id against the catalog read before calling it a stock-out.
The Pod reaches running but
```
runtime.ports
```
is still empty → it is still initializing; poll
```
get-pod
```
until it is populated before handing back a URL. This is normal Runpod API behavior, not a failure.
The proxy URL 502s right after create → the app inside has not bound to the port yet, or bound to
```
127.0.0.1
```
instead of
```
0.0.0.0
```
; read the boot log to confirm before declaring the Pod broken (deeper diagnosis is
```
runpod-pod-doctor
```
).
```
create-network-volume
```
is refused → read the error: the data center may not offer network storage (an empty
```
networkVolumeTypes
```
on the data-center read), the size may be outside 10–4096 GB, or the account balance may be too low; tell the user the exact reason and stop.
A create call fails → report it and stop; do not retry blindly or create a second Pod.
The Pod is running but the app is still pulling/booting after minutes → that is normal for multi-GB images, not grounds for a replacement Pod or an open-ended wait; follow the bounded-wait hand-back above.

create 返回带有调度或库存错误的
```
400
```
→ 该规格在读取与 create 之间售罄；应如实说明，并提供其他规格或数据中心，而不是重试同一个。如果出现相同的
```
400
```
（
```
no instances available
```
），也可能是 GPU type id 无效；在将其判定为库存不足之前，应对照目录读取结果检查该 id。
Pod 已达到 running，但
```
runtime.ports
```
仍为空 → 它仍在初始化；持续轮询
```
get-pod
```
，直到端口映射有值后再交付 URL。这是 Runpod API 的正常行为，不是故障。
create 后 proxy URL 立即返回 502 → 容器内的应用尚未绑定端口，或绑定到了
```
127.0.0.1
```
而不是
```
0.0.0.0
```
；在宣布 Pod 故障前，应读取启动日志确认（更深入的诊断由
```
runpod-pod-doctor
```
负责）。
```
create-network-volume
```
被拒绝 → 读取错误：数据中心可能不提供 network storage（数据中心读取结果中的
```
networkVolumeTypes
```
为空）、大小可能不在 10–4096 GB 范围内，或账户余额可能不足；应告知用户确切原因并停止。
create 调用失败 → 报告错误并停止；不要盲目重试，也不要创建第二个 Pod。
Pod 正在运行，但应用在数分钟后仍在拉取或启动 → 对于数 GB 的镜像，这是正常现象，不能以此为理由替换 Pod，也不能无限期等待；应遵循上述有界等待后的交付流程。

Report template — pod hand-back

报告模板 — Pod 交付

A good pod hand-back leads with four lines, each filled from a read made this turn: the Pod (id, state, hourly rate while running); the image (which template, Hub or pod read it came from); the GPU class with the stock figure from the availability read; and the reachable URL in its proxy form (or the

ssh

connect string for SSH). Then the mount path if a volume was attached, and the billing consequence of the Pod's current state.

一份好的 Pod 交付结果应以四行开头，每行都根据本轮执行的读取结果填写：Pod（id、状态、运行时的每小时费率）；镜像（来源于是哪个 template、Hub 或 pod read）；GPU 规格及 availability read 中的库存数；以及采用 proxy 形式的可访问 URL（或用于 SSH 的

ssh

连接字符串）。然后给出挂载路径（如果挂载了 volume），以及 Pod 当前状态对应的计费影响。

Contract

契约

The cross-journey answer contract (definite facts from reads, commit-don't-hedge, mutations bind to this conversation's creations, a standalone final message, honest failure, granted tools only) is defined in the

runpod-mcp

skill and applies to every reply from this journey. If the

runpod-mcp

skill has not been loaded in this conversation, load it now, before the next tool call: its rules on which resources you may change, when a request is the go, and when to stop for the user are not repeated here.

跨流程回答契约（基于读取结果的确定事实、明确执行而不含糊其辞、将变更操作绑定到本次对话中创建的资源、最终消息可独立阅读、如实报告失败、仅使用已授予的工具）由

runpod-mcp

skill 定义，并适用于本流程的每次回复。如果本次对话尚未加载

runpod-mcp

skill，请在下一次工具调用前立即加载：其中关于可以修改哪些资源、何时应将请求视为执行授权，以及何时应停止并等待用户的规定，不在此重复。