AI 长任务先领任务号，Runpod 可以稍后查询状态和结果

一次推理需要几十秒甚至更久，网页不一定适合一直等同一条HTTP请求结束。Runpod Serverless 的队列端点提供另一种交接：先提交任务、拿到job ID，再凭它查询状态和结果。

这篇面向正在部署长耗时AI功能的开发者。它讲的是队列端点；Runpod另有直接分配流量的负载均衡端点，接口路径与等待方式不同。

先收任务，再等worker处理

官方请求说明将 /runsync 与 /run 分开。前者让客户端等待完整结果，后者提交后台任务，之后经 /status 查询。请求都用 input 包住具体参数，参数含义由自己的worker定义。

worker的handler从job中取出input，运行代码再返回结果。服务总览说明，没有可用worker时任务会排队；需要新worker时，还会经历启动容器、加载模型等冷启动。

任务号因此不仅是一个显示用编号。应用应把它与用户输入和业务记录关联，后面才能显示排队、运行、失败或完成，也能在页面刷新后继续找回同一项任务。

三种时间，不能都叫“超时”

文档分别定义ttl、executionTimeout和结果保留。ttl从提交起计，包含排队和执行；executionTimeout只限制worker真正处理任务的时间。排队很久，会吃掉总生命周期的一部分。

完成后还有另一段结果留存：异步/run结果保留30分钟，/runsync通常保留1分钟。它们不是模型生成文件的永久存储。

如果产品要给用户长期下载产物，应用需要及时取回，再写入自己的存储。即使设置较长任务ttl，也不能由此推断完成结果就会一直可取。任务生命周期与成果保存，应分别设计。

重复提交，可能变成另一项付费任务

官方提醒，网络超时或服务错误后重新提交/run，原请求可能已经入队，因而产生重复job。拿到任务号后，应跟踪它的状态；已失败或执行超时的任务则有对应retry操作。

状态查询也不宜用紧密循环猛刷。文档给出随等待增长查询间隔的例子，并提供webhook通知与增量stream入口。选择哪种方式，取决于产品需要完成通知还是持续显示中间结果。

Runpod是商业托管服务。worker在冷启动和空闲等待时也可能计费，缩到零与保持可用worker有不同取舍。这个接口最有用的成果，是把漫长等待变成一项能追踪的工作：提交有身份，状态能接续，完成结果也有明确的取回与保存路径。