RunPod 视频生成生产化：幂等、超时、持久化与重试设计
从一次成功的 GPU Demo 到可靠的视频生成服务，需要任务协议、幂等键、分层超时、持久化输出和可观测性。本文给出完整工程清单。
3 分钟阅读
把视频模型放进容器并成功返回一次结果，只能证明 Demo 可运行。生产系统还要面对 10 分钟任务、客户端断线、重复提交、Worker 被回收、模型冷启动和大文件保存。真正的难点，是让每个任务最终只有一个可信结果。
RunPod Serverless 提供按秒计费和自动扩缩，但平台不会替应用决定幂等语义、超时边界和输出保留策略。结合本站已有的冷启动与 GPU 成本分析，本文把重点放在长耗时视频生成怎样从“能跑”走向“可恢复”。
先把同步请求改成任务协议
视频生成不适合让浏览器一直等待同一个 HTTP 连接。更稳妥的接口是：创建任务后立即返回 job ID，Worker 异步处理，客户端查询状态或接收回调。任务状态至少包含 queued、running、succeeded、failed 和 canceled，并明确每个状态是否还能重试。
POST /jobs -> 202 { "job_id": "..." }
GET /jobs/{id} -> status, progress, output, error
POST /jobs/{id}/cancel -> cancellation_requested
幂等键比“重试三次”更重要
网络超时不代表 GPU 没有开始工作。如果客户端直接重发，可能得到两个昂贵任务。创建请求应携带由用户、业务对象和输入版本组成的幂等键；服务端在数据库中为它建立唯一约束。相同键再次到达时返回原 job，而不是再排队一次。
- 输入文件先计算内容哈希，避免同名不同内容；
- 模型、LoRA、参数和随机种子进入任务版本；
- 只有明确的瞬时错误才自动重试；
- 输出写入完成后再原子地把任务标记为 succeeded；
- 账单和配额以逻辑任务计数，而不是以 Worker 尝试次数计数。
把存储分成三层
容器镜像保存稳定依赖；网络卷适合模型缓存和需要跨 Worker 复用的中间资产；最终视频应进入对象存储或另一个明确持久层。RunPod 文档指出，网络卷可以把数据与具体物理机器解耦。反过来说，只写容器本地路径，就应假设 Worker 回收后文件会消失。
| 数据 | 建议位置 | 失效策略 |
|---|---|---|
| 代码与固定依赖 | 版本化镜像 | 随发布替换 |
| 模型权重与共享缓存 | 镜像层或网络卷 | 按模型版本更新 |
| 单次中间帧 | 临时盘或网络卷 | 任务完成后清理 |
| 最终视频与元数据 | 对象存储/持久卷 | 按产品保留期 |
超时必须分层
不要只设置一个 15 分钟总超时。下载输入、加载模型、推理、编码和上传分别计时，才能知道失败发生在哪里。客户端等待超时不应取消后端任务；任务执行超时则应尝试终止子进程、保存诊断信息并释放显存。取消请求也需要状态机，避免文件刚上传完却被标成 canceled。
冷启动优化的顺序
- 先测量镜像拉取、容器启动、模型加载各自耗时。
- 删除运行时不用的编译工具和重复模型。
- 把高频权重放在可复用层，验证版本与校验和。
- 为延迟敏感端点保留最少活跃 Worker，但计算空闲成本。
- 不要用无限增大镜像掩盖缺少缓存策略的问题。
最低限度的可观测性
每个 job 记录排队时间、冷/热启动、模型版本、GPU 类型、各阶段耗时、峰值显存、重试原因、输出大小和最终状态。业务看板要区分逻辑成功率与 Worker 尝试成功率。若一次任务重试两次后成功，用户体验是成功，但基础设施已经暴露出成本和稳定性问题。
生产化的验收不是“今天生成出一条视频”，而是同一输入重复提交不会重复扣费、Worker 中断后任务可恢复、输出可以追溯到模型版本，并且失败时知道该重试还是终止。初次了解平台的读者可先看RunPod GPU 云平台指南。