RunPod Spot实例：非实时推理任务的容错配置

GPU服务器租用来跑非实时推理时，把创建 Pod 请求中的 interruptible 设为 true，其默认值是 false，即可请求 Spot 实例；RunPod 的创建 Pod API 文档说明，这类实例成本较低，但可随时停止以释放资源。容错应放在应用侧：任务状态、最近一个完整检查点和输出位置由外部队列与持久卷保存，重试时按同一任务标识恢复。

先判断非实时任务能否重跑

先把任务分成允许中断、可以重复执行的批处理，再决定是否使用 Spot。部署前应确认：

• 输入数据已有稳定来源，不会因 Pod 停止而丢失。
• 同一任务重复执行不会造成重复写入或不可接受的副作用。
• 模型框架支持检查点，任务能够从最近一个完整检查点继续。
• 业务可以等待新的 GPU 资源，而不是必须在固定时间内返回结果。

任一条件不满足，都不适合把任务放入可随时停止的实例。检查点命令和参数随模型框架而异，应按项目官方文档确认，不要套用未经核实的启动参数。

GPU服务器租用前：划定持久化边界

先确定中断后需要保留什么。RunPod 的存储选项文档说明，container disk 是临时存储，Pod 停止时会被清空；volume disk 中的 /workspace 可以跨停止和重启保留数据，但终止 Pod 时会删除；network volume 则独立于 Pod，删除 Pod 后仍可保留数据。关键检查点还应导出到外部备份，避免把任何一种卷当作唯一副本。

若选择 network volume，应先在控制台选择数据中心并填写名称和大小。RunPod 的 Network volumes 文档说明，它用于 Pod 时仅在 Secure Cloud 可用，必须在创建 Pod 时挂载，不能事后分离，并会替换 /workspace 中的 volume disk。多个 worker 同时写入同一个 network volume 可能造成数据损坏，因此应用需要采用单写者或锁机制。

Spot 实例：在创建请求中开启 interruptible

使用 API 创建时，RunPod 的 Manage Pods 文档给出的请求入口和鉴权头如下：

curl --request POST \
  --url https://rest.runpod.io/v1/pods \
  --header 'Authorization: Bearer RUNPOD_API_KEY'

这段命令只展示已确认的 endpoint 和 header，并不是可以直接提交的完整创建命令。提交前需要按照当前 API schema 补齐必填请求体字段，并把下面的配置片段合并进去：

{
  "interruptible": true
}

需要 network volume 时，先完成存储创建，并确保它在 Pod 创建过程中挂载。实例启动后只执行幂等恢复流程：读取外部队列、定位最近一个完整检查点、继续未完成部分，不应假定中断前的进程仍然存在。

非实时推理的容错配置

外部任务队列至少应保存四项内容：稳定任务标识、输入数据位置、最近完整检查点位置，以及输出位置和执行状态。Pod 本身只负责执行当前任务，不承担唯一的任务记录。

每个 worker 应按固定顺序工作：领取同一任务、检查是否已经成功、读取完整检查点、继续剩余计算、写入新的完整检查点，最后保存输出并把任务标记为成功。检查点应带完成标记，避免实例中断时读取到只写入一部分的文件。

重试前先核对成功标记、输出和检查点。只有这些内容尚未形成有效终态、任务无法继续且失败原因允许重试时，才把任务放回队列。到达你设定的重试上限后，应转入人工处理队列；每次重试继续使用原任务标识，防止生成多份相互冲突的结果。

验证实例中断后的恢复闭环

选择一个不代表生产数据的代表性任务，按以下顺序验收：

1. 提交任务并等待队列记录任务标识、完整检查点和预期输出位置。
2. 检查点生成后停止 Pod，观察 container disk 中的临时文件是否消失，而持久卷中的检查点是否仍在。
3. 尝试重启 Pod；如果暂时没有 GPU，不要把任务直接判为业务失败，让它继续留在可重试队列。
4. 取得计算资源后，确认 worker 读取同一任务的最近完整检查点，继续执行并最终保存输出。

这一步专门检查临时数据边界：RunPod 的维护、停机与数据安全说明指出，仅保存在 container storage 的数据会因中断、重启、停止或终止而丢失。验收通过的标准不是 Pod 再次显示运行，而是任务成功恢复、输出完整，并且队列只在结果持久化后记录成功。

常见出错点

重启后显示没有 GPU

停止 Pod 会释放那块具体 GPU，其他用户可能随后租用它，因此重启时可能找不到 GPU。RunPod 的 Zero GPU Pods 文档记录了这一情况。处理时保留任务的可重试状态，等待资源可用，不要假设原 Pod 一定会自动迁移到另一台机器。

Pod 已停止，但任务并未完成

不要把“Pod 已停止”当作“推理已成功”。停止或终止前，应同时确认队列终态、完整检查点和最终输出都已持久化；缺少任何一项，都应保留任务标识并按既定策略恢复。

本文步骤仅依据正文所链接的官方文档整理，未运行或测量任何配置，使用前请按当前版本复核。

资料来源

• RunPod 创建 Pod REST API 参考
• RunPod 管理 Pods
• RunPod 存储选项
• RunPod Network volumes
• RunPod 维护、停机与数据安全
• RunPod 重启时出现零 GPU