大模型异步任务架构：Java 后端别把长推理塞进同步接口 企业系统接入大模型后，最常见的架构错误之一，是把长推理任务直接塞进同步 HTTP 接口。用户点一下按钮，后端调用模型，线程一直等，网关也等，连接池也等。小流量时看不出问题，流量一上来，Tomcat 线程、数据库连接、模型网关配额会一起紧张。 长推理、批量总结、复杂 RAG、文档分析这类任务，更适合异步化。Java 后端要做的不是把超时时间调大，而是把任务生命周期设计清楚。 一、同步接口只负责提交任务 flowchart TD A[Client] --> B[Submit API] B --> C[Task Table] B --> D[Message Queue] D --> E[Worker Service] E --> F[Model Gateway] E --> G[Result Store] A --> H[Query API] H --> C H --> G 提交接口应该快速返回 taskId，后续由查询接口、WebSocket 或回调通知拿结果。这样用户体验更可控，服务端资源也不会被长连接拖住。 二、任务状态要可恢复 异步任务最怕状态混乱。至少要有 pending、running、succeeded、failed、cancelled、expired 这些状态，并记录模型版本、输入摘要、重试次数和错误码。 CREATE TABLE ai_task ( task_id VARCHAR(64) PRIMARY KEY, user_id VARCHAR(64) NOT NULL, status VARCHAR(32) NOT NULL, model_route VARCHAR(64), retry_count INT DEFAULT 0, error_code VARCHAR(64), result_uri TEXT, created_at TIMESTAMP, updated_at TIMESTAMP ); 状态机要由后端控制，不要让 worker 随便改字符串。可以用枚举和状态迁移表约束，避免 failed 任务又被写成 running。 三、Worker 要有并发和超时边界 模型调用不是普通 RPC，耗时和失败率都更不可控。Worker 需要限制并发、单任务超时、队列积压和重试策略。 ThreadPoolExecutor executor = new ThreadPoolExecutor( 8, 16, 60, TimeUnit.SECONDS, new ArrayBlockingQueue<>(500), new ThreadPoolExecutor.CallerRunsPolicy() ); 线程池只是局部控制，还要结合消息队列消费速率和模型网关限流。否则 worker 扩容后，真正被打爆的是下游模型服务。 四、结果要支持幂等写入 异步任务天然会重试。网络超时不代表模型没有完成，worker 崩溃也可能发生在结果写入之后。结果存储要用 taskId 做幂等键，避免重复生成、重复扣费或重复通知。 public void saveResult(String taskId, AiResult result) { int updated = resultRepository.insertIfAbsent(taskId, result); if (updated == 0) { log.info("result already exists, taskId={}", taskId); } } 幂等不是锦上添花，是异步系统的基本礼貌。没有幂等，重试机制越努力，事故越努力。 任务优先级和配额管理也需要提前设计。不同业务类型的异步任务，优先级应该不同。客服相关的工单摘要应该优先于批量数据统计；用户触发的单次分析应该优先于定时任务。可以在任务表中增加priority字段，worker根据优先级拉取任务。同时，要为每个租户或用户设置并发和每日配额，防止单个客户提交大量任务拖垮整个系统。 监控方面，除了基本的任务状态统计，还应该关注任务从提交到完成的端到端延迟、各状态停留时间、worker池负载、模型调用失败率和重试次数。这些数据能帮助你发现瓶颈：是提交太多、队列太长、worker不够，还是模型供应商不稳定。异步任务的用户体验很大程度上取决于"多久能拿到结果"，没有监控就无法优化这个体验。 在实际部署中，还需要考虑 Worker 的弹性伸缩策略。与普通 HTTP 服务的 CPU/内存型 HPA 不同，AI 推理的 Worker 瓶颈通常在等待模型响应（I/O 等待），而非 CPU。如果仅基于 CPU 使用率配置 HPA，当 Worker 都在阻塞等待模型响应时，CPU 使用率可能很低，K8s 不会触发扩容。我们改用"队列积压长度"作为扩容指标——当待处理任务数超过 Worker 数 × 2 时触发扩容，确保任务等待时间不超过 30 秒。配合 Keda（Kubernetes Event-driven Autoscaling），可以将 Kafka 消费延迟直接作为 HPA 的指标源，实现更精准的扩缩容决策。 五、总结 大模型长推理任务不要塞进同步接口。Java 后端应采用提交任务、队列消费、Worker 调用模型、结果存储、状态查询的异步架构。 把任务状态、并发边界、超时重试和幂等写入设计清楚，才能让 AI 能力稳定进入企业系统，而不是把普通接口拖成阻塞现场。