pod-deploy

Pod 部署

为用户创建一个 Pod，并准确告知用户如何访问它。创建前，先确认目标数据中心确实有对应 GPU 类型的库存：创建调用会严格创建指定类型，不会回退到其他 GPU；如果无法部署该类型，则会返回 400。选择合适的镜像和工作负载所需的端口（应用界面、Jupyter、SSH），并返回可正常使用的 Runpod 代理 URL。对于训练 Pod，将网络卷与 Pod 部署在同一位置，使检查点数据在 Pod 容器磁盘之外持久保存。

创建 Pod 会产生费用。创建前说明每小时费用。诊断或恢复已存在的 Pod 是另一项工作：使用 pod-doctor。

必备能力

以下列出能力名称；此服务器上提供各项能力的工具见下方工具绑定。此技能会先查询库存，再创建 Pod，且只创建用户要求的 Pod。

• 按数据中心读取 GPU 库存；当需要 CUDA 版本下限时，同时读取有库存的 CUDA 版本：创建前确认对应类型可用（更全面的目录查询交由 discovery 处理）。
• 创建网络卷：确保训练检查点持久保存（CRUD 管理交由 lifecycle-crud 处理）。
• 创建 Pod（镜像、GPU 或 CPU、磁盘、端口、环境变量、数据中心、挂载）。
• 检查 Pod：读取其状态、开放端口以及代理地址或公共地址。
• 列出 Pod：确定“哪个 Pod”，并确认现有 Pod。
• 读取 Pod 启动日志：确认应用已在相应端口启动，再提供 URL。
• 停止 / 终止 Pod：先创建后暂停，以及按用户要求清理。

阶段 1 — 确认库存并规划 Pod

• 创建前，先读取工作负载所需 GPU 类型的可用情况。include:["AVAILABILITY"] 与 product:["POD"] 必须同时使用（库存因产品而异），这样才能查看各数据中心的库存情况；应读取目标数据中心的库存，不可想当然。如果该数据中心没有相应类型的库存，应告知用户并提供其他 GPU 类型或数据中心选项；不要创建无法部署的类型。
• 根据用途选择镜像：开发使用交互式应用镜像（例如 ComfyUI 或 PyTorch 镜像），训练使用 CUDA/PyTorch 基础镜像。镜像的 CUDA 版本必须与 GPU 类型支持的版本相匹配，并在创建时将其设为下限：gpu.minCudaVersion 应设为镜像所用的 CUDA 主版本行（CUDA 12 镜像设为 12.8；仅基于 CUDA 13 构建的镜像才设为 13.0），确保 Pod 部署到驱动支持该镜像的主机上。模板的 allowedCudaVersions 会提供初始下限；创建时显式指定 gpu 字段会替换该初始值；可用性查询中的 cudaVersions 则会说明该下限是否有库存。
• 镜像必须来自本次会话中的查询结果，而非记忆。 对于指定应用（ComfyUI、Jupyter 或特定技术栈），应从刚刚查询的模板 / Hub-repos 中确定镜像，并在选择镜像时注明来源。若目录中没有结果，也应检查账户中已运行的镜像（可在 list-pods 查询结果中看到），这同样是值得核实的会话查询来源；注明你在哪个 Pod 上看到该镜像。仅当目录中没有匹配项时，才可退而使用知名的公共镜像，并在回答中明确说明。凭记忆填写镜像标签，容易选到过期镜像，导致启动时反复崩溃。Runpod 不发布 :latest 标签，因此必须指定精确标签；GPU 工作负载优先使用 runpod/pytorch 镜像，而非 runpod/base。
• 根据工作负载确定端口：Web 界面使用应用自身的 HTTP 端口；Jupyter 使用 8888/http；直接 SSH 使用 22/tcp。SSH 还要求创建时设置 startSsh: true，并且账户中已注册密钥（先检查 get-ssh-keys）；缺少其中任一项，无论 Pod 开放了哪些端口，都无法通过 SSH 访问。只开放用户需要访问的端口。
• 说明费用。 创建前，根据目录查询结果报出 GPU 的每小时费率。Pod 处于运行状态时，无论用户是否正在使用，都会产生费用。

阶段 2 — 创建并连接

• 交互式 / 开发 Pod。 使用选定的镜像、GPU 类别、磁盘、端口和数据中心创建 Pod。Pod 进入运行状态后，检查 Pod 并读取暴露的端口和当前映射。容器初始化期间，Pod 的 runtime.ports 会保持为空，因此请轮询，直到其中填入端口信息后再提供 URL。应用镜像体积较大，拉取可能需要几分钟。启动缓慢不代表失败：切勿因为第一个 Pod 仍在拉取镜像就创建第二个 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 可能要到 RUNNING 后几分钟才会出现，并且每次停止 / 启动后都会变化；如果它尚未出现，请说明这一点。在告知用户可以访问之前，请确认应用已绑定端口（查看启动日志中的“listening on 0.0.0.0:PORT”行）。
• 创建后停止，留待以后使用。 如果用户希望创建 Pod，但暂时不运行，请先创建 Pod，确认其已进入运行状态，然后再 STOP。切勿终止 Pod：终止会删除用户想要保留的卷磁盘。停止后，请说明以下影响：计算费用停止，GPU 会被释放；停止会清空容器磁盘，但卷磁盘（默认位于 /workspace）会保留，并在 Pod 终止前按停止状态的磁盘费率计费；Pod 会留在原机器上并在该机器上恢复，因此如果此期间另一位租用者占用了该 GPU，启动请求可能会因该主机没有可用 GPU 而被拒绝，也可能恢复后不再有 GPU。网络卷上的内容不受影响。告诉用户如何恢复（启动 Pod），以及 GPU 不可用时的处理方法：等待后重试、以零 GPU 启动以访问文件，或从控制台迁移 Pod（pod-doctor 涵盖此操作）。
• 带持久检查点的训练 Pod。 写入容器磁盘的检查点会随 Pod 一起消失，因此请同时配置网络卷。请在与 Pod 相同的数据中心创建卷（参见 lifecycle-crud）；网络卷仅可挂载到 Secure Cloud Pod，因此 Pod 应创建在 Secure Cloud 中。然后创建 Pod，将该卷挂载到检查点路径（例如 /workspace 或 /checkpoints），并将 Pod 固定到该数据中心。告诉用户挂载路径，并说明写入该路径的检查点在 Pod 停止或终止后仍会保留，而容器磁盘不会保留。卷的容量应足以容纳预期的检查点总量，并留有余量。Pod 的挂载路径由你在 mounts 中设置（没有默认路径）；Serverless worker 始终会在 /runpod-volume 访问该卷。如果之后要由 serverless endpoint 读取这些检查点，其处理程序必须从 /runpod-volume 读取，而不是使用 Pod 路径。

阶段 3 — 交接

• 交接内容放在你的最终消息中，并且必须独立完整（路由器约定）。其中应包含 Pod ID、其运行的确切镜像，以及它来自哪个模板 / Hub 读取结果；GPU 类别及支持该选择的库存证据（引用库存查询结果：“RTX 3090 — N available in EU-RO-1”）；可访问的 URL（逐字提供：HTTP 使用完整代理 URL，SSH 使用 ssh 连接字符串；绝不能说“上面的链接”，也绝不能使用启动日志中的内部 0.0.0.0:<port> 地址，因为它不是可访问的 URL），并注明代理 URL 默认公开且无需身份验证（其后任何敏感内容都需要单独设置身份验证）；如果挂载了卷，则提供挂载路径；以及 Pod 当前的状态和正在产生的每小时费用。对于已停止的 Pod，必须在状态说明中注明计费影响：GPU 计费已结束，卷磁盘会按停止状态费率继续计费，直到 Pod 被终止；网络卷从创建时起开始计费，无论 Pod 状态如何，都会持续计费，直到卷被删除。
• 清理。 默认保留用户要求的 Pod，并告知用户哪些项目正在计费以及如何停止计费（停止 Pod 会保留卷磁盘，并按停止状态费率计费；终止 Pod 会删除卷磁盘；网络卷无论 Pod 如何处置都会保留，并持续计费，直到被删除）。只有在用户明确表示这是一次性测试，或要求清理时，才拆除资源（并删除仅为本次练习创建的任何卷），且需通过回读确认。如果用户表示 Pod 是试用性质，运行后就要移除，则应以你自己的读取结果作为证明：Pod 处于 RUNNING 状态且端口已映射，并且启动日志中有应用正在监听的行。两项条件都满足后，应在同一轮中终止 Pod，通过读取确认 Pod 已不存在，并报告你看到的证明。不要结束本轮并等待用户尝试 URL。

硬性规则

• 创建前确认库存。绝不能在没有可用库存的 GPU 类别中创建。
• 创建任何 Pod 之前，以及创建网络卷之前，先说明每小时费用。
• 只创建用户要求的 Pod。绝不能停止、终止或修改用户未指定的 Pod（或卷）。
• Pod 完全运行且应用已绑定端口之前，绝不能提供代理 URL。runtime.ports 为空表示仍在初始化，并非故障。
• 对于训练，检查点必须写入网络卷，而不是容器磁盘；否则停止或终止 Pod 会导致检查点丢失。
• 只开放工作负载需要的端口。不要开放 SSH（22/tcp、startSsh）或用户未要求的其他端口。
• 不能仅凭创建调用就声称 Pod 可访问；必须先读取其状态。

错误处理

• 创建返回 400，并提示放置或库存错误 → 从读取库存到创建之间，该数据中心的此类别库存已耗尽；告知用户并提供其他类别或数据中心选项，不要重试相同的类别。同样的 400（“no instances available”）也可能表示 GPU 类型 ID 无效；在认定为库存耗尽前，先根据目录读取结果核对 ID。
• Pod 已进入运行状态，但 runtime.ports 仍为空 → Pod 仍在初始化；继续轮询 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，也不能无期限等待；按照上文规定的有限等待交接流程处理。

报告模板 — Pod 交接

良好的 Pod 交接应以四行内容开头，每行都根据本轮读取的结果填写：Pod（ID、状态、运行时的每小时费率）；镜像（使用的模板，以及它来自 Hub 还是 Pod 的读取结果）；GPU 类型，以及从可用性读取结果中获取的库存数量；以及可访问的 URL（采用代理形式），或 SSH 的 ssh 连接字符串。然后写明已挂载卷时的挂载路径，以及 Pod 当前状态对计费的影响。

工具绑定

能力	工具
每个数据中心的 GPU 库存	list-gpu-types / get-gpu-type（include:["AVAILABILITY"]、product:["POD"]）
各 GPU 类型可用的 CUDA 版本及容量	同一读取（cudaVersions）；使用 get-capacity 查看涵盖各主机 CUDA 版本的矩阵
数据中心	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 技能，请在下次调用工具前立即加载：其中关于可修改资源、何时可以执行请求以及何时应暂停并等待用户的规则，此处不再重复。