🕒 异步与同步任务最佳实践

AILB 底层接入了各类不同的模型生态：从极其快速的大语言模型（LLM），到耗时极高的多模态生成模型（长时视频、音乐编曲等）。 为了让所有的模型均能以近似 OpenAI /v1/chat/completions 的标准体系被调用，AILB 内置了一套强大的任务轮询状态机系统。

依据不同业务需求，我们将请求风格分成了 异步派发 和 同步等待 两种形式，请根据你的接入环境灵活选取。

1. 默认行为：高速回执与异步派发

默认情况下，对于所有已知的高延迟模型（例如 doubao-seedance-2-0, suno-v3.5, midjourney 等），系统在收到您的请求时，不会一直阻塞到任务生成彻底完毕。

相反，HTTP 网关将会立刻发挥性能优势返回一个标准的格式化响应：

{
  "id": "chatcmpl-aigc-task-xxxx",
  "object": "chat.completion",
  "created": 1740992345,
  "model": "v-model-name",
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "任务已提交。请带上原请求参数并使用相同的模型，发送至同步等待接口轮询，或在任务后台查看。"
      },
      "finish_reason": "stop"
    }
  ],
  "task_id": "YOUR-REAL-TASK-ID-XXXXX" 
}

当你收到这串回执时，底层算力集群便已经开始排队生成内容了。

怎么拿着 task_id 获取结果？

随后，开发者应当在自己的代码逻辑中每隔数秒（通常推荐 5~10 秒），单独访问全局通用端点 /v1/tasks/status ，使用 GET 并附加上述的 task_id 查询生成状态与下载链接。

(详细的查询代码用例可参考 Seedance 视频实操手册页面 中的第 2、3 步)

2. 特殊场景：强行阻塞同步等待

如果你使用的客户端（如某些第三方 OpenAI ChatGPT 客户端套壳软件）完全不支持异步解析机制，只能像对话一样死死等待，你也可以使用一些方式触发兼容层同步等待机制。

这种机制可以让 AILB 服务端替你进行死循环轮询查询（网关本身会在内部挂起请求的长连接，直到拿到结果切断连接并全量返回结果）。

触发条件与风险

通常只有你别无选择，且你的 Nginx 或客户端配置了极为漫长的 proxy_read_timeout (例如 >3600 秒) 容忍额度时才去触发它。它的存在如下致命缺陷：

• 客户端有极大概率在 60 秒后直接 TimeOut 发起 TCP 断开，而你的账号资源实际上已经被系统预扣费（服务端模型仍在后台努力生成中）。如果是这样，不仅用户体验崩坏，还成了断头请求。
• 长期大规模同时存在的 Socket 长时间挂载极其消耗负载均衡转发及代理面板资源。

3. 结论

• 如果你是 自建业务后端：强烈建议永远使用默认的异步获取 task_id ，并通过主动探查的方式拉取结果。这能保证你的主线程永不被长连接拥堵，永不会因为 HTTP 异常中断导致资产“盲损”。
• 如果你是 直接采用别人的客户端：事先一定要确认客户端支持至少 5 到 10 分钟以上的等待超时策略。

注：即使因系统侧网络问题导致任务未能生成，由于独特的预扣缓冲逻辑，消耗额度都会完整进行自动退回并进行退款纠偏。