前阵子帮朋友排查一个线上问题他们的 AI 应用在低峰期一切正常一到下午高峰期接口延迟从 200ms 一路涨到 3 秒以上错误率也跟着爬升。第一反应是模型服务出了问题结果上游监控显示模型侧延迟波动很小真正的瓶颈出现在应用和模型 API 之间的这一层HTTP 连接池配置错了。在一个 LLM 应用里连接池是最容易被忽视、却又最容易拖垮全局的组件。它不直接参与业务逻辑也不影响模型推理本身但一旦配置失当高并发下你的 AI 服务会“悄悄变慢”——表面看是模型响应慢实际请求大量时间都耗在“等一个可用连接”上。这篇文章从原理讲起覆盖参数选型、故障排查和工程实践把连接池这件事彻底说清楚。1. 先搞清楚LLM 应用的 HTTP 连接池到底在管什么1.1 一次 LLM 调用的完整链路假设你的后端服务收到一个用户请求需要调用某个大模型 API 生成文本。整个流程大概是这样的应用从用户请求中拼出 prompt 和各种推理参数。HTTP 客户端基于 requests、httpx 或 Go 的 net/http 组装请求。如果配置了连接池客户端先到池里找一条到目标地址的空闲连接没有才会新建。请求发出后等模型侧返回结果。可能是完整 JSON也可能是逐 token 的 SSE 流。响应结束连接归还池中供后续请求复用。连接池管的就是第 3 步和第 5 步。怎么找连接、找不到怎么办、什么时候新建、什么时候关闭空闲连接全在这里面。连接池的本质是一个“有限连接资源的复用容器”。池里存放的是已经建立好的 HTTP 连接底层是 TCP 连接、TLS 会话加上 HTTP 协议状态。对 LLM 服务来说这些连接通常要经过公网或者专线建一条新连接的开销远比很多人想象的大。1.2 连接池为什么能救命握手开销不是小数字一条新的 HTTP/1.1 连接从零开始建立要经历这些步骤DNS 解析几十毫秒很常见。TCP 三次握手消耗 1 个 RTT。TLS 握手通常再消耗 1 到 2 个 RTT。TLS 1.2 一般是 2 个 RTTTLS 1.3 是 1 个 RTT。如果走 HTTP/2还需要在 TLS 之上做一轮协商。假设你的应用和模型 API 服务之间的网络 RTT 是 20ms那么建一条新连接的纯网络开销在 60ms 以上加上 DNS 解析可能逼近 100ms。一个高并发服务每秒需要发出几百个请求如果每个请求都重新建连光握手耗时就能把网络消耗拉满。更麻烦的是TCP 和 TLS 握手本身还要消耗 CPU、内存和本地端口资源系统层面的开销很可观。连接池的价值是把建连成本从“每次请求承担”摊薄到“每个连接生命周期承担”。连接建好之后反复用这才是高并发下延迟和成本都能稳住的关键。1.3 AI 服务为什么对连接池配置格外敏感普通 Web 应用也依赖连接池但 LLM 应用的敏感度要高得多。原因有三个响应时间极长。一次模型请求可能耗时 5 到 30 秒甚至更多。连接被请求独占期间无法被复用池里的连接数必须覆盖并发请求数少一条都只能排队。流式响应非常普遍。SSE 场景下连接被占用的时间进一步拉长客户端边收边推一整段流读完才归还连接。并发突发性强。用户可能同时发起多路对话连接需求在几秒内成倍上升。按平均值设计的池子一到峰值就不够用。最迷惑人的地方在于连接池耗尽往往是渐进式的。它不会立刻报错而是表现为请求排队、等待时间拉长、偶尔超时重试。从外部看就是延迟慢慢涨上去非常像模型侧变慢。这也是标题里“悄悄变慢”的真正原因问题产生的过程不剧烈排查时很容易被误导。2. 连接池核心参数拆解配置前必须弄明白的 5 个数字2.1 最大连接数、每主机连接数、空闲连接数第一个数字是最大连接数。它决定整个连接池最多能同时持有多少条连接。设太小高并发下连接不够用请求排队设太大下游连接数过多可能被上游限流甚至被误判为异常流量。第二个数字是每主机最大连接数。如果客户端会连接多个上游服务这个参数尤其重要。Go 的 http.Transport 默认 MaxIdleConnsPerHost 只有 2很多人只把 MaxIdleConns 调大忽略了单 host 的限制结果到目标地址的连接复用率依然很低大量连接在反复重建。这里要拎清一个概念连接池里同时存在“活跃连接”和“空闲连接”。活跃连接正在处理某个请求不能被复用空闲连接才能被下一个请求取走。最大连接数控制的是池子能容纳的连接总量空闲连接数控制的则是池中最多保留多少条已建好的空闲连接。如果空闲连接上限设得很小连接刚一归还就被关闭池子的缓冲效果就打了个折扣。2.2 获取连接超时、连接超时、读取超时这三个超时是最容易混的一组。连接超时建立一条新 TCP 连接允许的最长时间。一般设 3 到 5 秒不建议超过 10 秒。获取连接超时从连接池拿到一个空闲连接的最长等待时间。很多框架默认是无限等待高并发下这是一个隐藏的灾难点。读取超时发出请求后等待对端响应数据的最大时间。LLM 场景下通常要设置得比较大尤其是流式模式第一个 token 和最后一个 token 之间可能隔很久。建议把获取连接超时控制在 5 到 10 秒。如果池子满了宁可快速失败让调用方感知也不要让大量请求在池前堆积成一个看不见的队列。这个队列一旦变深延迟会变得完全不可控。2.3 这些参数如何互相“打架”连接池参数不是独立的改一个经常会牵动另一个。如果读取超时很长比如 LLM 场景下设为 60 秒同时获取连接超时也很长慢请求会逐渐把连接池占满。新请求涌入后全部在池前排队整体延迟会累积放大。如果空闲超时设置比上游 keep-alive 时间更长上游会先关闭空闲连接客户端还不知道下一次复用打在一个死连接上就会遇到 Connection reset 或者超时。如果最大连接数乘以实例数之后太大对下游模型 API 的负载会迅速上升。比如某个推理服务的并发上限是 50你部署了 10 个实例每个实例池中 20 条连接最多会有 200 条连接同时打过去直接突破下游承受能力。所以配置连接池时不能只看单机参数要做乘法要做匹配要做整体的容量估算。2.4 LLM 场景下的参数选型思路以 Python 生态为例如果你用 httpx可以这样配置import httpx limits httpx.Limits( max_connections200, max_keepalive_connections100, keepalive_expiry120.0, ) timeout httpx.Timeout( connect5.0, read60.0, write5.0, pool5.0, ) client httpx.Client(limitslimits, timeouttimeout)如果用的是 requests通过 HTTPAdapter 配置import requests from requests.adapters import HTTPAdapter session requests.Session() adapter HTTPAdapter( pool_connections20, pool_maxsize200, max_retries2, ) session.mount(https://, adapter)注意 requests 里 pool_connections 是缓存连接数pool_maxsize 是每个 host 的最大连接数。参数名字容易误导必须结合你实际访问的 host 数量来理解。Go 一侧的参考配置transport : http.Transport{ MaxIdleConns: 200, MaxIdleConnsPerHost: 100, MaxConnsPerHost: 200, IdleConnTimeout: 90 * time.Second, DialContext: (net.Dialer{ Timeout: 5 * time.Second, }).DialContext, TLSHandshakeTimeout: 5 * time.Second, ResponseHeaderTimeout: 60 * time.Second, } client : http.Client{Transport: transport}这些数值只是参考实际要按并发模型调整。核心思路是最大连接数大于等于峰值并发请求数空闲超时小于上游 keep-alive 超时获取连接超时设置一个合理的上限让请求快速失败而不是无限堆积。3. 高并发下连接池故障的四种典型死法3.1 死法一连接池被慢请求占满新请求排队最容易踩的坑就是把池子大小按平均并发设置而 LLM 请求响应又慢几个慢请求就把池子沾满了后面的请求全部在等空闲连接。我做过一次压测max_connections10并发打到 50。每个请求平均耗时 2 秒10 条连接全被占用其余 40 个请求全部排队。时间一长等待队列越来越深实际延迟从 2 秒变成 20 秒以上而下游模型服务的性能完全正常。最终反馈到用户侧就是“AI 变慢了”但模型侧指标一点问题都没有。这种场景的典型信号是客户端日志里出现大量获取连接超时错误服务端 P99 和 P50 的差距急剧拉大下游 API 的 QPS 反而没有明显上升。3.2 死法二空闲连接被服务端断开请求打到半开连接上客户端连接池里的空闲连接超过一定时间没被使用上游网关会主动关闭。这个关闭动作客户端不会立刻感知连接池仍然把这条半开连接标记为可用。下次请求复用的时候TCP 层的行为是要么发出去的包石沉大海要么收到一个 RST。请求只能等一个超时然后报错或者触发一次重试。这类问题最难抓因为它有偶然性。只有一段较长空闲之后的第一次新请求会踩到不压测、不仔细看日志很难发现。解决方式是让客户端的空闲超时小于上游 keep-alive 的时间一般设 60 到 120 秒比较稳妥。3.3 死法三连接池太大下游被流量打挂和上面相反有些团队为了解决连接不够用的问题把连接池调得非常大动辄上千。但模型 API 服务端通常有并发限制对上游来说它看到的是全量应用实例的连接总和。单方面放大自己应用侧的连接数影响的不只是自己而是共享模型服务的所有调用方。之前帮一个团队排查时他们把连接池调到 500配合 8 个实例高峰时对模型服务建立了 2000 多条连接直接把上游网关的连接数打爆。后续只能和模型侧协调重新按并发配额换算出每个实例允许的连接上限。所以调大连接池之前先确认下游的并发配额再乘以实例数看看总量是否会超限。连接数是按需、按配额设计的资源不是越大越好。3.4 死法四重试风暴把连接池彻底压垮LLM 服务在高负载下会偶尔返回 5xx 或 429。如果应用层做了失败自动重试且大量请求在同一时刻失败、同一时刻重试重试请求会全部涌向连接池。池子本来勉强能支撑请求量瞬间翻倍甚至翻三倍连接池被击穿一批请求失败又触发下一批重试形成滚雪球式的重试风暴。应对重试风暴有三个方向。一是限制最大重试次数通常 2 到 3 次足够。二是使用指数退避加全抖动让重试请求错峰发出。三是给连接池留出余量不要在正常流量下就几乎用满。重试策略和连接池是一对互相放大的因素设计阶段就要一起考虑。3.5 故障现象速查表故障信号可能原因典型错误客户端大量获取连接超时连接池容量小于并发请求数timed out waiting for connection / pool timeoutP99 远超 P50上游指标正常连接排队、半开连接触发重试request timeout / read timeout上游连接数爆满错误率上升连接池过大或实例数过多connection refused / limit exceeded偶发 Connection reset by peer空闲超时大于上游 keep-aliveconnection resetQPS 上不去CPU 消耗高连接复用率低连接频繁重建无直接报错需观察握手频率4. 一次连接池耗尽的完整复盘4.1 背景与压测数据拿一个简化后的案例来说。某 AI 应用准备上线内部压测场景是 100 个用户同时提问模型平均生成时长 3 秒请求走流式接口返回。最初连接池配置为 max_connections50。压测结果很不理想平均首字延迟 700ms平均完整响应 6.5 秒错误率大概 3%QPS 只有 180远低于预期。模型 API 侧监控显示服务端推理耗时稳定在 3 秒左右CPU 负载也不高。也就是说问题并不在模型侧而在调用链路的中间层。4.2 定位问题的关键证据我们先把客户端连接池指标打开。当时基于 httpx自己加了一个简单的指标输出记录了池中的当前连接数、空闲连接数和等待获取连接的请求数。压测开始之后等待连接的 pending 数持续上升峰值到了 60说明大量请求在排队等连接。池中连接数长期维持在 50 的满状态几乎没有空闲连接。单次请求在排队环节平均耗时 2 秒左右甚至超过了实际推理时间。再看 TCP 层的数据抓包发现握手频率并不高说明连接大部分是复用的。根因不是连接反复创建而是连接池容量根本喂不饱并发。线上问题的判断依据很清楚下游延迟正常本地等待连接时间异常问题一定出在连接池这一层。4.3 改写配置与前后对比我们把 max_connections 调到 200每主机最大连接数同步调大读取超时保持 60 秒获取连接超时设为 10 秒空闲超时从默认的 300 秒改到 90 秒。同样的压测场景结果完全不一样首字延迟降到了 150ms 左右完整响应稳定在 3.2 到 3.5 秒。错误率降到 0.01% 以下。QPS 稳定在 500 以上。这次优化最关键的一步是把获取连接超时显式设置了上限。原来池子满的时候请求会一直等待现在等不到连接会在 10 秒内快速失败应用层可以做降级处理而不是无限堆积。快速失败加合理重试加扩容池子比让大量请求卡在等待队列里健康得多。5. 可落地的连接池工程实践5.1 配置模板与具体实现给出一张面向 LLM 场景的通用配置清单参数建议范围说明最大连接数峰值并发 × 1.2~1.5留余量但不要成倍扩大每主机最大连接数与最大连接数一致或略小单上游场景可视为相同空闲连接上限最大连接数的 50%~80%保留足够空闲连接避免反复重建空闲超时60~120 秒必须小于上游 keep-alive 超时获取连接超时5~10 秒快速失败优于无限等待连接超时3~5 秒TCP 建连阶段兜底读取超时LLM 响应 P99 30 秒流式场景要给足等待时间配置完成后强烈建议做一次压测对比。用 locust 或者直接写个简单的并发脚本分别跑默认配置和新配置记录 P50、P99 和错误率。连接池问题在低并发下基本看不出来必须拉到目标峰值并发才能暴露。5.2 全链路监控与告警阈值连接池配置对不对不能靠感觉要依赖监控。至少关注这几组指标连接池自身。当前连接数、空闲连接数、等待获取连接数、获取连接等待耗时的平均值和 P99。应用侧。请求的 P50 和 P99 延迟、错误率、超时次数。注意区分模型推理耗时和排队等待耗时。下游侧。模型 API 的响应码分布、实际推理耗时。如果下游延迟正常而应用侧延迟很高问题大概率在中间层连接池是第一个怀疑对象。告警阈值可以这样设置等待获取连接数超过池容量 50% 且持续 1 分钟获取连接等待时长 P99 超过 1 秒连接池长时间处于无空闲连接状态。这些信号都说明池子快要被占满了需要扩容或者排查慢请求来源。5.3 实操中的注意事项与避坑经验最后整理几个实际踩过的坑可以直接抄作业多实例部署时连接池容量必须做乘法。每个实例都有自己的池10 个实例每个池 200 条连接对下游就是 2000 条连接。配额和限流都要按总量算不是按单机算。流式接口的连接占用时间远长于非流式。池子容量不能参考一次性返回的并发数据。一条连接正在流式输出时不能被其它请求复用。不要在请求函数里新建 HTTP 客户端。很多 LLM SDK 的客户端设计为全局复用每次请求都 new 一个 client连接池就形同虚设了。正确做法是启动时初始化一次全局共享。严格区分读取超时和连接建立超时。LLM 场景下读取超时设置过短模型生成稍慢就会误报超时设置过长个别慢请求又会长期占用连接。建议参考模型服务的 P99 再加 30 秒作为兜底。服务启动时可以发起一次预热请求把连接先建好。避免上线瞬间所有线程同时抢建连接造成握手风暴。重试策略要配合连接池余量。不要把池子设置成刚好够用否则触发一轮重试池子就被打穿了。重试间隔用指数退避加抖动别用固定间隔。我个人做过多次 AI 应用性能排查连接池问题的出现频率远超想象。一个看起来是“模型变慢”的问题最后往往只是池子配置没跟上并发曲线。建议在系统设计阶段就把连接池当成一等公民明确画出一条容量模型峰值并发、单请求预计耗时、实例数、上游配额四个数字对起来再结合压测微调。最后再分享一个小习惯我在写连接池配置时会顺手在代码注释里记下每个参数当时的估算依据。上线三个月后再回看如果这些假设已经明显变化就需要重新压测重新调参。连接池没有一劳永逸的答案它的正确形态只属于某一个具体的并发曲线。