异步任务队列与状态解耦架构

异步任务队列与状态解耦架构 (Asynchronous Task Queue & Decoupled State Architecture，如 Celery, Temporal, BullMQ + Redis/Kafka) 是多模态生成（文生图 Stable Diffusion、文生视频 Sora/Wan2.1、3D 生成）等重算力长耗时（单次生成耗时从 2 秒到数分钟）服务不可或缺的工业级后端架构；与经典同步 HTTP 阻塞请求不同，该架构将客户端请求与 GPU 繁重推理完全解耦：1) 提交阶段：API 网关接收用户 Prompt 后，生成全局唯一 `task_id`，将任务推入高可用持久化队列（带优先级权重，如付费 VIP 用户高优通道），并立即向客户端返回 HTTP 202 Accepted 及 `task_id`；2) 异步消费阶段：GPU Worker 节点以 Pull 模式从队列拉取任务，执行多步扩散生成，并将渲染图片/视频上传至对象存储 (S3/OSS)；3) 状态通知阶段：客户端通过 WebSocket / SSE 双向长连接实时接收生成进度百分比与预览图，或通过长轮询接口拉取最终 CDN 结果 URL。

Midjourney / 剪映 AI 绘画与视频生成、Runway / Luma 文生视频服务、海量图片批量超分渲染。

扩散模型与视频生成耗时极长，若采用同步 HTTP 请求会导致网关 HTTP 连接大量超时断开、底层 GPU 重复计算浪费、突发流量直接冲垮服务；异步解耦架构消除了超时断连，实现了万级长任务的高可用排队调度与削峰填谷。

详细画出客户端、API 网关、Redis/Kafka 任务队列、GPU Worker 集群与 S3 对象存储之间的异步任务流转时序图？

优先级队列 (Priority Queue) 设计：如何为付费订阅会员 (VIP Tier) 提供排队插队与专属 GPU 算力池保障？

任务超时与 Worker 崩溃自愈：如何通过心跳租约 (Heartbeat Lease / Dead Letter Queue) 自动重新分发死掉的 GPU 任务？

实时进度回传机制：GPU Worker 在执行 30 步去噪过程中，如何低开销地通过 Redis Pub/Sub 与 WebSocket 向前端推送进度百分比与 Latent 临时预览图？

用户主动取消长任务 (Task Cancellation)：当用户关闭窗口或点击取消时，如何通过广播信号及时通知 GPU 停止昂贵的后续步数计算？