Azure App Service中LLM长时任务规避504网关超时方案咨询

问题背景 #

我在Azure App Service上部署了FastAPI应用，流程为：用户上传大型投标/RFP文档 → Azure Document Intelligence提取文本 → 拆分为约10000 tokens的片段 → 串行调用GPT-4o处理片段 → 聚合输出得到约16000 tokens的最终响应。

当前问题：完整处理耗时偶尔超过240秒，客户端收到Azure App Service返回的504 Gateway Timeout。

约束条件：

• 必须基于Azure App Service部署
• 固定使用GPT-4o模型
• 存在大提示词与大输出场景
• 当前实现以串行为主
• 需同步处理请求，API必须等待最终LLM响应后返回

咨询问题与解答 #

1. Azure App Service中处理长时LLM工作负载的推荐架构模式 #

优先采用异步任务队列+轮询/回调模式：

• 前端上传文档后，App Service的API立即返回唯一任务ID，客户端通过轮询该ID获取处理状态与最终结果
• 将文档分片、LLM处理、结果聚合等核心长时逻辑剥离到后台任务，用Azure Service Bus作为任务队列，Azure Functions或WebJobs作为任务执行载体
• App Service仅负责请求接收、任务触发、状态查询，避免长时间占用请求连接触发超时

2. 将LLM处理迁移至后台任务是否为首选方案 #

是首选方案，核心原因：

• Azure App Service的请求超时上限为900秒，即便调整配置仍无法覆盖超长时间的LLM处理场景，后台任务可彻底规避网关超时问题
• 后台任务可独立弹性扩容，比如Azure Functions能根据任务量自动调整执行资源，比单独扩容App Service更高效、成本更低
• 便于实现任务重试、失败告警、断点续传等容错机制，比App Service内串行处理的可靠性更高

3. 流式响应能否避免网关超时，还是后端请求仍需在App Service时限内完成 #

流式响应仅能缓解部分场景，无法彻底解决：

• 流式响应的逻辑是分块返回LLM输出，只要后端能在App Service超时时间内返回第一块数据，后续流传输不会触发超时
• 但如果文档提取、分片等前置步骤已超过240秒，依然会触发504错误
• 此外，若你的场景需要聚合完整输出后才能使用，流式响应会增加前端处理复杂度，实际价值有限

4. 使用GPT-4o处理大型文档时，降低端到端延迟的最佳实践 #

• 并行处理分片：将文档分片后，用异步并发或多线程方式调用GPT-4o，替代串行处理，可大幅压缩处理时间（比如10个分片串行需10分钟，并行仅需1-2分钟）
• 优化分片策略：不要机械按token数拆分，尽量按文档逻辑章节拆分，减少后续聚合的复杂度，同时避免跨章节的上下文断裂
• 复用中间结果：缓存提取后的文档文本、分片处理结果等，若同一文档重复处理或多个文档含通用内容，可直接复用缓存，减少重复计算
• 调整LLM参数：适当降低温度参数（如0.1-0.3），减少LLM的冗余思考时间；若输出长度允许，可限制max_tokens（你的场景需16000输出，此条可忽略）

5. 是否有开发者针对类似RFP/投标文档生成工作流实现异步任务处理 #

有大量成熟落地实践：

• 多数企业采用Azure Service Bus + Azure Functions组合，将文档上传、文本提取、LLM处理、结果拆分为独立任务节点，通过队列串联执行
• 部分开发者使用Azure Durable Functions编排整个工作流，它能自动处理任务依赖、重试、状态跟踪，适合这种多步骤的长时工作流
• 结合Azure Storage存储中间结果（如提取后的文本、分片处理输出），方便故障恢复与结果聚合

内容的提问来源于stack exchange，提问作者B.Nikhil Kumar