为什么 LLM 应用需要异步设计
LLM 调用的延迟特性决定了同步模式在生产环境中的局限性。旗舰档模型处理复杂任务时,响应时间可能在数十秒甚至分钟级别;批量处理场景下,串行等待会让用户体验急剧下降。更重要的是,HTTP 连接超时、网关限制、客户端等待容忍度都对长时间同步调用构成约束。
异步设计的核心价值在于解耦请求提交与结果获取。用户提交任务后立即得到任务 ID,系统在后台完成处理,用户通过轮询、WebSocket 或回调获取结果。这种模式不仅改善交互体验,还为任务调度、失败重试、资源控制提供了架构空间。
任务队列的选型与实现
任务队列是异步架构的基础设施。轻量级场景下,Redis + Bull(Node.js)或 Celery(Python)足以覆盖需求;需要持久化保证和复杂调度时,RabbitMQ 或 Kafka 是更稳健的选择。
关键设计点包括:
优先级队列:区分交互式任务(用户实时等待)与批量任务(可延迟处理)。假设一个文档分析系统,用户上传单个文件期待 30 秒内看到摘要,而夜间批量处理 1000 份历史文档可以排在低优先级队列慢慢消化。
并发控制:LLM API 通常有 RPM(每分钟请求数)和 TPM(每分钟 token 数)双重限制。Worker 数量需要根据配额动态调整,避免触发 429 错误。可以用令牌桶或滑动窗口算法在应用层实现限流,而不是被动等待 API 拒绝。
任务状态管理:至少需要 pending、processing、completed、failed 四个状态。用 Redis Hash 或数据库记录任务元数据,包括提交时间、开始时间、重试次数、错误信息。这些数据既是用户查询的依据,也是监控告警的来源。
流式响应的异步处理
流式输出(Server-Sent Events)改善了长文本生成的体验,但引入了新的复杂度。后端需要维护长连接,前端需要处理部分内容的渲染和错误恢复。
一种实用的混合方案是:同步返回流式响应用于交互场景,同时异步落库完整结果。具体来说,用户发起请求时,后端开启 SSE 连接并创建异步任务;Worker 消费任务时调用 LLM 流式 API,将 chunk 既推送到 SSE 通道,也拼接到数据库。这样即使用户中途断开连接,完整结果仍会保存,可以稍后重新获取。
需要注意的是,流式传输的错误处理不能依赖 HTTP 状态码——连接已经建立,后续错误只能通过特殊 event 类型或 JSON 字段传递。客户端必须解析每个 chunk,识别 error 类型并中止渲染。
批量调用的优化策略
批量场景的核心矛盾是吞吐量与成本的平衡。逐条调用虽然简单,但无法利用批量折扣(部分厂商提供 Batch API)和并发优化。
分批聚合:假设需要为 5000 条商品生成描述,可以按 50 条一批分组,每批内并发调用(受限于 RPM 配额),批间串行。这样既避免单次任务过大导致超时,也能通过并发提升整体速度。
幂等性设计:批量任务可能因部分失败需要重跑。给每条子任务生成唯一 ID(如 {batch_id}-{item_index}),结果表以此为主键。重试时跳过已完成的子任务,只处理失败或未开始的部分。注意这里的花括号是伪代码示意,实际代码中需要用具体变量替换。
结果聚合:所有子任务完成后触发回调或更新批量任务状态。可以用 Redis 计数器实现:初始化为子任务总数,每个 Worker 完成后 DECR,减到 0 时触发最终通知。
错误重试与降级
LLM API 的失败模式多样:网络抖动、速率限制、模型过载、输入违规。重试策略需要区分可恢复错误(429、503)和永久错误(400、内容过滤)。
指数退避:对于 429 和 5xx 错误,采用指数退避重试,初始延迟 1 秒,每次翻倍,最多重试 5 次。部分 API 返回 Retry-After 头,应优先遵循。
降级方案:当旗舰档模型持续失败时,自动切换到中间档甚至轻量档。虽然输出质量下降,但总比完全无响应好。在任务元数据中记录实际使用的模型档位,便于后续分析和人工复核。
死信队列:超过最大重试次数的任务进入死信队列,避免无限循环消耗资源。定期人工检查死信队列,识别系统性问题(如 prompt 格式错误)并修复。
异步架构的复杂度换来了可靠性和可扩展性。如果你的团队正在构建 LLM 应用,需要在任务队列、流式处理或批量优化方面的架构咨询,欢迎联系 Taylent Labs,我们可以帮助设计适合你业务场景的技术方案。