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

pod-doctor

你需要供应用户请求的Pod，并明确返回其访问方式。在创建任何资源前，需确认目标数据中心内对应GPU型号有真实库存：创建调用会精确部署请求的型号，绝不会降级到其他GPU，若该型号无法部署则返回400错误。你需要选择合适的镜像和工作负载所需的端口（应用UI、Jupyter、SSH），并返回可用格式的Runpod代理URL。对于训练用Pod，需协同部署网络卷，确保checkpoint不会随Pod的容器磁盘一同销毁。

创建Pod会产生费用。在创建前需说明小时成本。诊断或恢复已存在的Pod属于另一项功能：由

pod-doctor

负责。

Required capabilities

所需能力

Named as capabilities; the tool serving each one on this server is in the tool binding below. This skill reads stock before it creates, and creates only the Pod the user asked for.

Read GPU stock per data center, with the CUDA versions that have capacity when a CUDA floor matters: confirm the class is available before creating (delegate the fuller catalog read to
```
discovery
```
).
Create a network volume: checkpoint durability for training (delegate the CRUD hygiene to
```
lifecycle-crud
```
).
Create a Pod (image, GPU or CPU, disk, ports, env, data center, mounts).
Inspect a Pod: read back its status, exposed ports, and the proxy/public address.
List Pods: resolve "which Pod" and confirm what already exists.
Read a Pod's boot logs: confirm the app came up on the port before handing back a URL.
Stop / terminate a Pod: create-then-pause, and cleanup when the user asks for it.

以下为各项能力名称；本服务器上对应每项能力的工具见下方的工具绑定表。本技能会在创建前查询库存，且仅创建用户请求的Pod。

按数据中心查询GPU库存，若有CUDA最低版本要求则同时返回有容量的CUDA版本：创建前确认型号可用（完整的目录查询委托给
```
discovery
```
）。
创建网络卷：保障训练场景下checkpoint的持久性（CRUD操作的规范处理委托给
```
lifecycle-crud
```
）。
创建Pod（镜像、GPU或CPU、磁盘、端口、环境变量、数据中心、挂载）。
查看Pod：读取其状态、暴露的端口以及代理/公网地址。
列出Pod：明确“哪个Pod”并确认已存在的资源。
读取Pod启动日志：在返回URL前确认应用已在对应端口启动。
停止/终止Pod：支持创建后暂停，以及用户请求时的清理操作。

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"]
```
需搭配使用（两者必须同时指定，且库存因产品类型而异），可获取各数据中心的库存情况，因此部署的目标数据中心是通过查询确认的，而非假设的。如果该型号在目标数据中心无库存，需明确告知并提供其他型号或数据中心的选项；不得在无可用库存的型号下创建Pod。
根据用途选择镜像：开发场景选用交互式应用镜像（如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/pytorch
```
镜像，而非
```
runpod/base
```
。
根据工作负载确定端口：Web UI使用应用自身的HTTP端口，Jupyter使用
```
8888/http
```
，直接SSH使用
```
22/tcp
```
。SSH功能还需要在创建时设置
```
startSsh: true
```
，且账户中已注册SSH密钥（需先通过
```
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 (
```
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
```
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进入运行状态后，查看并读取其暴露的端口和实时映射关系。容器初始化期间，Pod的
```
runtime.ports
```
会保持为空，因此需轮询直到该字段填充完成后再返回URL。应用镜像通常较大，拉取可能需要数分钟。启动慢并非故障：绝不能因为第一个Pod还在拉取镜像就创建第二个。一旦Pod ID生成，即可告知用户代理URL的格式（
```
https://<podId>-<port>.proxy.runpod.net
```
）。如果在工具支持的最长等待时间后应用仍未绑定端口，需提供有依据的状态报告（Pod ID、状态、最后一行日志）和建议的下一步操作；可以提出继续监控。HTTP端口的可访问形式是代理URL
```
https://<podId>-<port>.proxy.runpod.net
```
。对于SSH，返回Pod的
```
ssh
```
配置块：
```
ssh.direct
```
（需要
```
22/tcp
```
端口；支持完整SSH功能，包括scp和rsync），如果机器没有公网IP则返回
```
ssh.proxy
```
（仅支持交互式shell）。
```
ssh.direct
```
可能在Pod进入RUNNING状态数分钟后才会出现，且每次停止/启动都会变化，因此如果暂未出现需说明情况。在告知用户Pod可访问前，需确认应用已绑定端口（读取启动日志中是否有“listening on 0.0.0.0:PORT”行）。
创建后停止供后续使用。 当用户需要创建Pod但暂不运行时，先创建Pod，确认其进入运行状态后再停止。绝不要终止（terminate）：终止会删除用户需要保留的卷磁盘。停止后需说明影响：计算费用停止，GPU被释放；停止会清除容器磁盘，但卷磁盘（默认是
```
/workspace
```
）会保留，并按停止磁盘费率计费，直到Pod被终止；Pod会留在原机器上并在该机器上恢复，因此如果期间有其他租户占用了该GPU，启动可能会因主机上无可用GPU而被拒绝，或者启动后没有GPU；网络卷上的所有内容都不受影响。告知用户如何恢复（启动Pod），以及如果GPU不可用该怎么办：等待并重试、以0个GPU启动以访问文件，或者从控制台迁移Pod（
```
pod-doctor
```
负责该操作）。
带持久化checkpoint的训练Pod。 写入容器磁盘的checkpoint会随Pod一同销毁，因此需要协同部署网络卷。在Pod部署的同一数据中心创建卷（参见
```
lifecycle-crud
```
；网络卷仅能挂载到Secure Cloud Pod上，因此Pod需部署到Secure Cloud）。然后创建Pod，将该卷挂载到checkpoint路径（如
```
/workspace
```
或
```
/checkpoints
```
），并将Pod固定到该数据中心。告知用户挂载路径，以及存储在该路径下的checkpoint在Pod停止或终止后仍会保留，而容器磁盘则不会。根据预期的checkpoint总大小预留空间来设置卷容量。在Pod上，挂载路径是你在
```
mounts
```
中设置的路径（无默认值）；而Serverless worker始终会在
```
/runpod-volume
```
路径下看到该卷。如果这些checkpoint后续会被Serverless端点读取，则其处理程序必须在
```
/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.

交付结果需放在你的最终消息中，且可独立阅读（路由契约要求）。内容需包含：Pod ID、运行的精确镜像及其来源（哪个模板/Hub查询结果）、GPU型号以及对应的库存依据（引用可用性查询结果：“RTX 3090 — EU-RO-1 中有 N 台可用”）、可直接访问的URL原文（HTTP的完整代理URL、SSH的连接字符串；绝不能说“上面的链接”，也不能用启动日志里的内部地址
```
0.0.0.0:<port>
```
，该地址无法直接访问），并注明代理URL默认是公开且无身份验证的（其后的任何敏感内容都需要自行配置认证）；如果挂载了卷，需说明挂载路径；以及Pod的当前状态和当前运行的小时成本。对于已停止的Pod，需始终在状态中说明计费影响：GPU计费已停止，卷磁盘按停止费率计费直到Pod被终止，而网络卷从创建起就计费，直到被删除，与Pod状态无关。
清理。 默认情况下保留用户请求的Pod，并告知用户哪些资源在计费以及如何停止（停止会保留卷磁盘，并按停止费率计费；终止会删除卷磁盘；网络卷在两种情况下都会保留，直到被删除才会停止计费）。仅当用户将本次操作定义为一次性测试或要求清理时，才拆除资源（并删除仅为本次操作创建的卷），且需通过回读确认。如果用户将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。
创建任何Pod前，以及创建网络卷前，都需说明小时成本。
仅创建用户请求的Pod。绝不能停止、终止或修改用户未指定的Pod（或卷）。
在Pod完全运行且应用已绑定端口前，不得返回代理URL。
```
runtime.ports
```
为空表示仍在初始化，而非故障。
训练场景下，checkpoint必须存储在网络卷上，而非容器磁盘；否则停止/终止Pod会导致数据丢失。
仅开放工作负载所需的端口。不得开放用户未请求的SSH（
```
22/tcp
```
、
```
startSsh
```
）或额外端口。
绝不能仅根据创建调用就声称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
```
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.

创建返回
```
400
```
且提示部署或库存错误 → 在查询和创建的间隔期内，该数据中心的对应型号已售罄；需告知用户并提供其他型号或数据中心的选项，而非重试同一选项。同样的400错误（“无可用实例”）也可能是因为GPU类型ID无效；在判定为库存不足前，需对照目录查询结果检查ID是否有效。
Pod进入运行状态但
```
runtime.ports
```
仍为空 → 仍在初始化；需轮询
```
get-pod
```
直到该字段填充完成后再返回URL。这是Runpod API的正常行为，并非故障。
创建后代理URL立即返回502 → 内部应用尚未绑定端口，或者绑定到了
```
127.0.0.1
```
而非
```
0.0.0.0
```
；在判定Pod故障前，需读取启动日志确认（深度诊断由
```
pod-doctor
```
负责）。
```
create-network-volume
```
被拒绝 → 读取错误信息：可能是该数据中心不提供网络存储（数据中心查询结果中
```
networkVolumeTypes
```
为空）、大小超出10–4096 GB范围，或者账户余额不足；告知用户确切原因并停止操作。
创建调用失败 → 报告错误并停止；不要盲目重试，也不要创建第二个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、状态、运行时小时费率）；镜像信息（来自哪个模板、Hub或Pod查询）；GPU型号以及可用性查询中的库存数量；以及代理格式的可访问URL（或SSH的连接字符串）。之后是挂载路径（如果挂载了卷），以及Pod当前状态对应的计费影响。

Tool binding

工具绑定

Capability	Tool
GPU stock per data center	`list-gpu-types` / `get-gpu-type` ( `include:["AVAILABILITY"]` , `product:["POD"]` )
CUDA versions with capacity, per GPU type	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	`create-network-volume`
Create a Pod	`create-pod`
Inspect a Pod	`get-pod`
List Pods	`list-pods`
Read Pod boot logs	`stream-pod-logs`
Stop a Pod (keep the volume disk)	`pod-action` ( `{"action":"stop"}` )
Resume a stopped Pod	`pod-action` ( `{"action":"start"}` )
Terminate a Pod	`delete-pod`
Account SSH keys	`get-ssh-keys` / `update-ssh-keys`

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.

能力	工具
各数据中心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`

如果会话的工具列表中缺少此处命名的工具，需说明情况，并使用最接近的查询工具，不得编造结果。

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

技能中，适用于本旅程的所有回复。如果本次会话尚未加载

runpod-mcp

技能，请在下次工具调用前加载：其中关于可修改哪些资源、何时可执行请求、何时需停止等待用户的规则，此处不再赘述。