Java大模型资源调度实战：从线程池到连接池的全面优化

今年上半年我帮一个做企业级SaaS的团队做架构评审他们刚上线一个AI功能用户在后台输入一段产品描述系统调用大模型生成营销文案。我看了眼核心代码心里一沉——一个PostMapping接口方法里new了一个OkHttpClient直接POST到大模型API把返回的String塞进ResponseEntity就完事了。当时我就说这个功能上线后两周内必出事故。果然某个工作日下午调用量一上来Tomcat默认200个线程全部hang住连登录、查询订单这些普通接口也跟着超时数据库连接池被打满整个系统雪崩。这个场景在今年的Java后端团队里其实非常普遍。很多人以为Java接入大模型就是加一个HTTP客户端调接口的事。但实际上企业里的“大模型开发”尤其是Java技术栈绝大多数功夫不在写提示词而在做资源调度。大模型服务和传统数据库、普通第三方API有个本质区别它不是“快去快回”的下游服务而是一个高延迟、长连接、强算力依赖的昂贵资源。一次推理动辄几秒到几十秒吞吐低、成本高、还经常超时。于是核心问题就变成了在Java服务里如何高效调度这些大模型资源让它不拖垮应用、不烧光预算、还能扛住生产流量。这篇文章我就从线程模型、网关路由、连接池、异步化、限流熔断、Token成本到可观测性完整梳理一遍Java企业级AI开发里大模型资源调度这套东西。每个环节我都会结合自己的踩坑经历来写尽量说人话。1. Java接入大模型的第一道坎传统请求-响应模型碰上长耗时推理1.1 线程池是怎么被打满的绝大多数Java后端服务用的是Tomcat、Undertow这类Servlet容器默认线程池在200左右。传统接口的逻辑是进来一个请求占用一个线程等业务处理完毕、响应返回线程才释放。普通CRUD接口一个请求占线程的时间大概在20到100毫秒。但大模型调用不一样一次生成往往要5到30秒。也就是说同一个线程处理AI请求的时间是普通接口的100到600倍。200个线程看着不少但在AI场景下大约20到30个并发推理请求就能把线程池吃干净。线程池耗尽之后Tomcat会把新请求扔进队列队列满了就开始拒绝连接。最可怕的是此时所有正常接口都在排队等线程用户点什么都转圈最终数据库连接池也跟着被耗尽——因为你等不到线程去执行SQL连接全被占着不放。1.2 超时参数直接决定事故半径很多团队的代码里只设置了连接超时读取超时和写入超时完全是默认值有些HTTP客户端默认根本没上限。大模型这种慢服务如果没有readTimeout兜底服务端一旦异常挂起客户端请求会一直吊着不释放。等到线程池被这些“僵尸请求”填满事故半径瞬间从单个AI接口扩大到整个应用。反过来超时设得太短也会出问题。流式生成的时候两个token之间的间隔可能超过几秒如果读超时设置成5秒模型输出稍微停顿一下客户端就直接给你报超时。这种问题排查起来极其迷惑看日志发现请求明明发出去了服务端也显示成功但客户端就是报SocketTimeoutException。所以大模型场景的超时要按“首字节时间”和“总耗时”分开设计。1.3 回压机制是资源调度的起点说白了大模型服务是一个全局共享的稀缺资源任何一个没有节制的热点接口都能把整个系统的资源拖垮。要解决这个问题不能指望每个开发都自觉必须在架构层面引入回压机制——要么在网关层限制并发要么在线程池层面做隔离要么在客户端层面做信号量控制。这块后面会详细展开这里先建立一个认知大模型资源调度本质上是给这种慢速、昂贵、不稳定的下游服务设计一套“交通管制系统”。2. 模型网关层把大模型当成可路由的后端服务来调度2.1 API直连为什么不可持续最开始团队都是图省事直接在业务代码里写死大模型API地址和密钥。这样做的后果很直接密钥散落在各个微服务里泄露风险极高换一次密钥要改十几个项目重新发版。切换模型要用改代码的方式实现。比如今天用GPT-4o明天想换成自研的Qwen2.5不改代码根本切不了。没有任何统一的调用审计出了问题不知道是谁在什么时候调用了哪个模型。无法在中间层做配额管理、成本统计和灰度验证。所以企业级接入第一步就是把“直连”改成“走网关”。大模型在网关后面对Java服务来说就是一个普通后端服务可以做路由、限流、熔断、审计。2.2 路由策略模型不是越多越好而是要对症下药模型网关的核心价值是把“调哪个模型”这个决策从业务代码中剥离出来。业务方不用关心底层用的是什么模型只需要表达自己的需求等级。我在实际项目里的做法是按业务场景给请求打标签然后路由到不同模型池业务场景推荐模型路由优先级超时控制实时客服对话主力大模型P0首字1.5s总时长30s文章摘要/分类轻量模型7B级别P1首字3s总时长60s离线批量分析开源模型本地部署P2首字10s总时长300s数据脱敏/改写规则小模型P0首字0.5s总时长5s网关层的职责就是根据标签做路由、转发、记录耗时。如果P0模型超时或返回5xx立即降级到备选模型这个逻辑对上游业务完全透明。2.3 网关实现选型从“自己写Filter”到“接入现成网关”自研成本不高核心就是一个基于Spring Cloud Gateway或Servlet Filter的转发层把/v1/chat/completions之类的请求透传到真正的模型服务商中间插入路由和鉴权逻辑。如果想省事直接用开源方案做二次开发也行。关键是网关层要保留详细的调用日志包括请求体大小、Token数、模型名、耗时、错误码。这套数据后面做成本核算和性能分析全都要用没有网关层收集数据后面的“资源调度优化”全都无从谈起。提示网关层一定要做“模型不可用时的快速失败”不要让请求在大模型侧排队超过10秒。宁可快速降级也不要让用户长时间无响应。3. Java客户端侧连接池、超时与流式响应的工程化细节3.1 HTTP客户端选型RestTemplate可以退休了Java侧调大模型无非就是调HTTP接口。选型上我走过弯路简单分享一下结论RestTemplate同步阻塞线程模型老对连接池控制弱不建议在大模型场景使用。OkHttp连接池调度灵活支持HTTP/2多路复用流式处理和超时控制都细是目前比较稳妥的选择。Java 11 HttpClient内置不需要额外依赖HTTP/2和流式都支持但配置项不如OkHttp丰富。WebClient响应式适合与WebFlux搭配如果团队没有响应式编程经验学习成本会高一些。我的建议是传统Spring MVC项目直接用OkHttp响应式项目用WebClient不要混用。3.2 连接池参数不能套用普通HTTP服务的经验普通HTTP服务连接建立后基本都是毫秒级交互连接复用率高。但大模型推理是“慢交互”一个连接可能被占住几十秒客户端的连接池配置如果还是默认值很容易出现“连接等待”导致的高延迟。以OkHttp为例默认每个路由最大5个连接大模型场景肯定不够。我一般至少调到20到50同时把connectionPool的存活时间调长一些避免连接频繁被回收重建。还要注意连接池不是越大越好连接数超过模型服务端能承受的并发上限反而会触发服务端的限流。核心参数建议参数推荐值说明maxRequests100全局并发请求上限maxRequestsPerHost20-50单路由并发上限connectionPool.maxIdleCount50空闲连接保留数量connectionPool.keepAliveDuration5分钟空闲存活时间readTimeout按场景流式接头长1分钟读取超时connectTimeout3秒建立连接超时callTimeout按场景总耗时上限单次调用总超时3.3 流式响应是必选项不是可选项大模型生成内容如果等全部生成完再返回用户要盯着转圈看上十秒。流式输出则不同后端接收到第一个token就立即转发给前端用户1秒内就能看到文字在跳动体验完全不一样。Java侧实现流式响应简单粗暴的方案是SseEmitter配OkHttp的EventSource。当大模型返回SSE事件流时消息中间再转发给前端的SseEmitter缓冲区客户端断开时记得取消上游调用否则后台线程会一直挂着浪费资源。SseEmitter emitter new SseEmitter(60_000L); emitter.onCompletion(() - call.cancel()); emitter.onTimeout(() - call.cancel()); Request request new Request.Builder() .url(modelUrl) .post(body) .header(Authorization, Bearer apiKey) .build(); call client.newCall(request); call.enqueue(new Callback() { Override public void onResponse(Call call, Response response) { try (ResponseBody body response.body()) { // parse line by line BufferedReader reader new BufferedReader(body.charStream()); String line; while ((line reader.readLine()) ! null) { if (line.startsWith(data:)) { String data line.substring(5).trim(); if ([DONE].equals(data)) break; emitter.send(data); } } emitter.complete(); } catch (IOException e) { emitter.completeWithError(e); } } Override public void onFailure(Call call, IOException e) { emitter.completeWithError(e); } });这里有个细节服务端必须定期发送心跳或者利用注释行维持连接否则代理层可能因为长时间无数据杀掉连接。客户端读超时也要比普通场景放宽。4. 并发调度模型从同步阻塞到异步流水线4.1 同步阻塞调用的成本算账很多团队第一版用的是同步调用代码好写但代价很大。一次大模型输出30秒对应一个Tomcat线程被占用30秒。假设一天1万次AI调用平均一次10秒那么线程被占用的总时间大约是10万秒。如果线程池只有200个线程算下来平均每秒需要处理约1.2个请求但高峰期并发远超这个数线程池瞬间被击穿。解决办法不是盲目加服务器而是改变占用方式**调用线程不再傻等大模型返回而是把IO等待交给事件回调线程立刻释放去处理其他请求。**这就是异步化的本质。4.2 从SseEmitter到WebFlux什么时候上响应式如果项目已经用了SseEmitter加OkHttp异步回调其实已经解决了一部分问题同步Servlet线程在调用大模型期间不再被占用了。因为SseEmitter本质上已经打破了“一个请求一个线程”的模型。但更彻底的做法是用WebFlux的Flux做全链路响应式。Flux的好处是天然支持背压机制——当下游消费速度跟不上时上游不会无限发数据。但WebFlux的代价是团队需要适应响应式编程范式排错难度也会上升。我个人的建议是大多数团队先用好SseEmitter就够了不要在项目初期就上全响应式。等连接池、限流、熔断都做扎实了再考虑是否迁移到WebFlux。步子迈太大容易摔。4.3 虚拟线程Java团队的红利JDK 21的虚拟线程对Java团队接入大模型来说是个重大利好。它允许你用同步阻塞的写法享受接近异步的性能。普通线程池被占满的问题虚拟线程基本不存在——它可以创建几十万个轻量级线程阻塞IO时自动释放载体线程。我在一个内部工具项目里验证过把ExecutorService换成Executors.newVirtualThreadPerTaskExecutor()同步调用大模型的代码几乎不用改QPS支撑能力提升了10倍以上。当然虚拟线程也不是万能的如果代码里有synchronized或原生方法可能会把载体线程钉住导致性能回退。这块还是需要压测验证。4.4 任务队列与优先级给不同业务分配“车道”另一个容易忽略的调度点是不同业务的并发优先级。比如用户实时对话的延迟敏感批量数据分析任务则不那么着急。如果不做隔离一个批量任务就能把连接池占满实时对话全部超时。我的做法是定义独立线程池或Semaphore隔离不同业务类型。比如实时对话用50个许可批量任务用10个许可互不影响。再配合队列批量任务排队执行实时任务优先通过。这种资源池隔离的思路跟数据库连接池的原理一模一样。5. 限流、熔断与降级生产环境的“安全阀门”5.1 为什么必须在应用侧做限流大模型服务商一般会按QPS或TPM每分钟Token数配额限流。很多团队依赖服务商限流结果就是你的应用毫无节制地打满配额然后在边缘被反复429。429之后如果代码里还有重试逻辑等于自己把自己打死——重试风暴直接放大到模型服务端被服务商封禁几分钟都是轻的。应用侧限流是第一道防线而且是本地瞬时限流不是远程配额。具体可以用Guava的RateLimiter或Bucket4j做令牌桶也可以自己实现一个滑动窗口计数器。核心目标是保证单客户端的请求速率长期稳定在配额之下留出安全余量。// 简单并发控制信号量限流 Semaphore modelSemaphore new Semaphore(20, true); public CompletableFutureString callModel(String prompt) { if (!modelSemaphore.tryAcquire(2, TimeUnit.SECONDS)) { return CompletableFuture.completedFuture(系统繁忙请稍后再试); } return CompletableFuture.supplyAsync(() - { try { return doCallModel(prompt); } finally { modelSemaphore.release(); } }); }5.2 信号量比QPS限流更好用QPS限流关注的是“每秒多少次”但大模型场景真正要保护的是“同时在途的请求数”。一次请求耗时10秒每秒放行1个请求实际同时在途的可能有10个。如果只看QPS很容低估资源占用。所以除了令牌桶还要用Semaphore控制并发在途数。我给模型客户端设置过20个Semaphore许可超过20个并发直接走降级而不是排队等待。为什么不做排队等待因为大模型请求本身就慢排队超过几秒用户的体感已经很差不如直接给一个降级结果保住用户体验的底线。5.3 熔断触发条件与恢复策略熔断器的核心是当错误率达到阈值或耗时超过阈值时快速失败一段时间让下游喘息。用Resilience4j配置的话我的经验值是failureRateThreshold50 slowCallRateThreshold80 slowCallDurationThreshold10s minimumNumberOfCalls10 waitDurationInOpenState10s permittedNumberOfCallsInHalfOpenState5意思是接口在最近10次调用中如果有5次失败或8次慢调用就打开熔断器。熔断期间请求直接快速失败10秒后进入半开状态放5个探活请求如果成功就关闭熔断器否则继续开路。这套逻辑对模型波动特别有用因为大模型服务偶尔会抽风整体恢复很快不需要动系统。5.4 降级兜底不能没有备用方案模型调用失败甚至熔断时要有一个降级方案。我的经验是准备三层第一层本地规则引擎。比如关键词抽取、模板填充虽然不如大模型聪明但稳定可靠。第二层轻量模型。用更小更快的模型做兜底牺牲一点质量保住可用性。第三层预设文案。给用户一个合理的“系统繁忙”或通用回答绝不能让用户看到异常堆栈。注意降级不是让开发偷懒而是为了保证核心链路不挂。降级方案要提前设计、提前测试不要临时写。6. Token成本调度另一种形态的资源分配6.1 Token就是企业的“算力货币”大模型按Token计费看起来一次生成几千Token没多少钱但乘以每天几十万次调用成本就非常可观。我见过一个团队上线AI功能一个月账单出来直接傻眼成本比云服务器还高一个数量级。所以企业Java开发里必须把Token当成一种“资源”来调度像管数据库连接池一样管Token配额。核心要做两件事计量和控制。计量就是记录每次调用的输入Token、输出Token按业务线聚合。控制则是在网关层限制每个业务的每日Token预算超过就拒绝或降级。6.2 用模型分级降低总成本不是所有请求都需要用最强模型。简单任务交给小模型复杂推理才动用大模型这个策略叫“模型分级”。比如用户输入一句“帮我分类这段文本”完全可以用7B量级的开源模型在线服务成本只有大模型的十分之一。而“帮我写一份商业计划书”这种任务再路由到旗舰模型。更进一步可以在网关层前置一个轻量分类模型判断请求复杂度自动分配模型。这样业务方不需要关心成本只需要表达意图。这个设计对控制成本帮助极大。6.3 Prompt层面的资源控制除了模型侧成本Java代码里对Prompt做资源管理也很有效。最常见的手段限制max_tokens防止模型无限生成。控制历史消息窗口只保留最近几轮对话避免输入Token爆炸。多轮对话的输入Token是成倍增长的一个不设上限的会话聊到20轮以后输入可能就是几万Token。根据场景调整temperature也能影响Token消耗节奏。// 控制输入成本的滑动窗口示例 int maxHistoryMessages 6; ListMessage history getRecentMessages(conversationId, maxHistoryMessages);6.4 把“模型算力”当资源池管理这是一个更抽象但也更本质的视角模型资源池类似数据库连接池。有总量配额、有分配策略、有闲置释放、有超卖限制。某个业务线申请了100万Token/天的配额就用独立计数器跟踪用完就降级。某个模型服务端出现故障资源池自动摘除该故障实例把流量切到健康实例。把成本当资源管起来之后你会发现整个系统的行为变得可预期既不会突然欠费也不会因为某个业务线滥用把整月预算烧光。7. 可观测性调度过程看不到等于没做7.1 核心指标四件套够用了可观测性不是让你把日志打满而是围绕资源调度真正关心的指标来监控。我建议从四个维度入手并发在途数当前有多少请求正在等待大模型响应超过阈值就要告警。等待与耗时分布请求在连接池等了多久、模型生成用了多久、总耗时的P95/P99是多少。模型错误码分布429、500、超时分别占多少占比异常时立刻介入。Token消耗量按模型、按业务线、按时间维度聚合用于成本核算。配合Grafana面板这些指标可以每天固定时间看一眼。很多大模型的异常在P95延迟上会比错误率更早暴露所以延迟监控尤其重要。7.2 链路追踪一次AI调用跨过的每一个节点一次AI对话请求路径往往不止一个服务前端网关到Java应用Java应用再调模型网关模型网关转给模型服务商。任何一个环节慢都会表现为用户侧超时。没有链路追踪出了问题你得一顿瞎猜。用Micrometer Tracing加TraceId把一次调用的完整链路串起来能清楚看到时间消耗在哪个节点。我处理过一个事例用户反馈AI回复特别慢链路追踪一看Java应用只用了100毫秒但模型网关排队等了15秒——原来是一个P2批量任务把模型服务连接池占满了P0的实时对话只能等。这个定位过程前后不超过5分钟。7.3 可观测性反哺调度参数调优有一次线上P95延迟飙升指标面板显示“连接池等待时间”占比特别高。顺着排查发现模型服务端的HTTP keep-alive配置是60秒而OkHttp连接池的keepAliveDuration设成了5分钟导致有一半的连接被服务端提前关闭客户端每次请求都要重新建立连接握手白白增加延迟。把keepAliveDuration调到45秒P95延迟立刻下降了40%。这种问题如果没有连接池维度的监控数据根本无从下手。所以可观测性不只是出问题之后用的它是持续调优资源调度参数的基础设施。写在最后的一些体会这几年做Java后端我越来越觉得过去跟数据库连接池、线程池、缓存打过交道的那些经验在大模型时代非但没有过时反而变得更重要了。大模型资源调度说白了就是把“数据库连接池管理”这套思维搬到“模型服务调用”上只是模型更慢、更贵、更不稳定调度策略要求的颗粒度更细。最后分享两个小建议。第一做AI功能之前先把模型网关层建起来再谈写提示词。网关层是一切的底座不管后面换模型、做成本控制还是加审计都靠它。第二上线前一定要压测大模型接口像压测数据库一样认真压不要觉得模型是第三方提供服务就一定可靠。真实的并发、超时、限流只有压测才能暴露出来。如果你正在Java项目里接入大模型希望这篇能帮你少走一些弯路。模型会变框架会换但资源调度的基本功永远是那几板斧——连接池、超时、限流、熔断、降级、监控。把这套东西做扎实了任何大模型在你手里都是可控的。