当你的 AI 应用从内部测试走到百万用户或者你的智能客服得同时应付上千条咨询一个很残酷的现实就会摆在你面前大模型 API 的调用早就不是简单的“发请求-收结果”了而是一场跟延迟、限流、超时和成本的多维度博弈。这篇文章不扯抽象架构也不替任何平台站台纯粹从开发者的实际工程角度给出一套能直接复现的调优思路——从客户端代码到底层网关从限流算法到缓存决策帮你在大模型 API 高并发场景下把稳定性和响应速度的底线守住了。核心矛盾用户感受 vs 平台限制先想想这个问题你的系统同时发出 50 个请求用户能忍受的最长等待时间是多久不同场景下的容忍度差别其实挺大的实时对话型比如 AI 客服、聊天机器人关键看首 token 到达时间TTFT。用户希望 1 秒内就看到第一个字在闪超过 3 秒基本就流失了。批量推理型比如文档摘要、代码审查更关注总生成时间TPSP95 延迟在 10 秒以内还算能接受。流式输出型比如代码补全、实时翻译TTFT 和令牌到达的稳定性都很重要中途卡顿特别破坏体验。而大模型 API 服务商普遍会设速率限制常见的单位有 RPM每分钟请求数和 TPM每分钟令牌数。举个例子OpenAI 的 GPT-4o 在 Tier 1 账户下通常只有 500 RPM 和 30,000 TPM 的配额。一旦超了限流值你就会收到 429请求过多或 503服务不可用错误。所以高并发的本质就是在平台限制和用户期望之间找平衡——盲目增加并发只会让限流触发得更频繁最后整体吞吐量反而下降了。客户端调优别搞暴力并发很多新手写代码就像这样for 循环里挨个发请求或者用线程池不加限制地怼上去。这在低 QPS 时还行一旦负载上来系统很快就不行了。正确的做法是在客户端造一个“智能水管”控制水流的速度、方向和应急泄洪。连接池与复用减少握手开销每次 HTTP 请求建立 TCP 连接需要 1-2 次 RTT往返时延再加上 TLS 握手耗时可能到 100-300 毫秒。高并发下这个开销会被放大很多。解决办法就是使用连接池来复用连接。拿 Python 的aiohttp来说importaiohttp connectoraiohttp.TCPConnector(limit50,# 总连接数上限limit_per_host20,# 每台主机的连接数上限ttl_dns_cache300,# DNS 缓存 5 分钟force_closeFalse,# 保持连接复用)limit设成你期望的最大并发数就好一般别超过 100不然可能触发服务端连接限制。keepalive设置默认 30 秒能确保连接不会被过早回收。Java 里可以用HttpClient的连接池配置HttpClientclientHttpClient.newBuilder().connectionPool(newFixedConnectionPool(50,Duration.ofSeconds(30))).connectTimeout(Duration.ofSeconds(5)).build();Go 语言的话通过http.Transport的MaxIdleConns和IdleConnTimeout字段来控制。限流算法实战令牌桶 滑动窗口客户端限流是为了防止自己被平台封杀这就像个护身符。推荐用令牌桶算法以固定速率往桶里放令牌每次请求消耗一个桶满了就丢掉多余的。importtimeimportasynciofromcollectionsimportdequeclassTokenBucket:def__init__(self,rate:float,capacity:int):self.raterate# 每秒放入的令牌数self.capacitycapacity# 桶容量self.tokenscapacity self.last_timetime.monotonic()asyncdefacquire(self):whileTrue:nowtime.monotonic()elapsednow-self.last_time self.tokensmin(self.capacity,self.tokenselapsed*self.rate)self.last_timenowifself.tokens1:self.tokens-1returnawaitasyncio.sleep(0.1)# 轮询间隔那怎么把 RPM 转成令牌桶参数呢比如说平台限制 500 RPM那rate 500/60 ≈ 8.33令牌/秒要是允许突发可以把capacity设为rate * 2。对于 TPM 限制得先估算每个请求平均消耗多少 Token可以通过响应头x-ratelimit-remaining-tokens动态调整或者更简单点把 TPM 除以平均每请求的 Token 数得到一个等效的 RPM 上限。滑动窗口适合更精细的时段控制但实现起来稍微复杂一些。大多数场景下令牌桶已经够用了。重试与熔断指数退避加抖动遇到 429 或 503 时直接重试只会让情况更糟。标准做法是指数退避再加上随机抖动。importrandomimportasyncioasyncdefretry_with_backoff(coro_factory,max_retries3,base_delay1.0):forattemptinrange(max_retries):try:returnawaitcoro_factory()except(aiohttp.ClientResponseError,aiohttp.ServerTimeoutError)ase:ife.status429ore.status503:ifattemptmax_retries-1:raisedelaybase_delay*(2**attempt)random.uniform(0,0.5)awaitasyncio.sleep(delay)else:raise如果平台返回了Retry-After响应头那就优先用这个值作为延迟不用管指数退避了。熔断器Circuit Breaker当错误率达到某个阈值比如 10 秒窗口内 50% 的请求都失败自动熔断返回降级结果或者报错防止连锁故障。不同 API 的错误码处理有点区别OpenAI 返回 429 并且带Retry-AfterClaude API 可能返回 529负载过高或 503。聚合平台比如兼容接入的服务通常会透传原始错误码但有些平台会统一包成 500。流式响应优化背压与分块高并发下流式请求SSE有两个问题一是客户端处理速度跟不上接收速度导致内存越堆越多二是网络抖动导致流中断。背压Backpressure用异步迭代器每次只处理下一个数据块不缓存整个流。asyncdefconsume_stream(response):asyncforchunkinresponse.content.iter_chunks():# 处理 chunk千万别在循环里做耗时操作process_chunk(chunk[0])awaitasyncio.sleep(0)# 让出事件循环防止阻塞超时控制给流式请求分别设连接超时、读取超时和空闲超时。避免因为网络问题导致连接一直挂在那。timeoutaiohttp.ClientTimeout(total60,# 整个请求最大时长connect5,sock_read10,# 两个数据块之间的最大间隔)另外流式请求更容易触发平台限流因为每个令牌都会消耗配额。建议在客户端对单个流内部的 Token 生成速率也做个粗略监控要是发现速率持续低于某个阈值主动重连或者降级。服务端/网关层架构中转与聚合的工程实现如果你的应用需要给多个下游用户提供 API 聚合能力比如做个兼容接入的网关或者需要跨多个模型、平台来分发请求那服务端架构的稳定性设计比客户端调优还要重要。负载均衡策略大模型 API 跟传统 Web 服务不一样模型请求的延迟差异很大从 500ms 到 30s 不等而且每个请求消耗的 Token 也不一样。所以最少连接策略比轮询要好因为它会把新请求分配给当前负载最轻的后端。一致性哈希适合需要缓存路由的场景比如同一用户的请求固定到同一节点。关键要注意后端如果出现慢请求比如一个超长的生成任务会长时间占用连接导致其他请求排队。解决办法是设置超时熔断如果某个后端的 P95 延迟超过阈值就主动把它降权或者隔离掉。缓存层设计哪些请求真的可以缓存大模型 API 最大的特点就是非确定性同样的 prompt每次输出都可能不一样。但下面这些场景缓存命中率还不错Embedding 查询相同文本映射到相同向量缓存能命中 80% 以上。格式化输出要求输出固定 JSON 结构的请求只要 prompt 一致结果通常也一致。知识库问答当上下文是预先定义好的片段时可以用语义近似缓存比如向量数据库检索。不过要注意缓存会带来“过时”的风险。实际中建议设一个较短的 TTL5-30 秒或者让用户手动刷新。对于实时性要求高的对话不推荐用缓存。多模型路由与故障转移当单个 API 后端不可用或者被限流时自动切换到备用模型或备用平台。健康检查应该基于真实请求而不是简单的心跳发一个小 prompt比如“11”检测响应质量和延迟。降级预案举个例子主线路GPT-4o → 限流时降级到 GPT-4o-mini后备Claude 3.5 Sonnet → 再失败就用通义千问最后兜底返回缓存结果或者友好的错误提示实现时要注意不同模型的 Token 计价差异很大建议在路由策略里加上成本权重避免自动降级导致预算超支。资源隔离与配额管理如果你的服务同时服务多个客户就需要做租户隔离。最简单的方案是按 API Key 划分每个 Key 限制并发数和速率。底层实现可以用 Redis 的原子计数器加上滑动窗口或者直接集成熟网关比如 Kong、APISIX的限流插件。选型决策指南基于你的并发场景不同规模的业务需要完全不同的解决方案。下面是一些基于常见场景的保守建议具体性能数值会因平台、模型版本和网络环境而有差异请以实际测试为准低并发 10 QPS方案直接接入官方 API 客户端限流。成本最低不需要中间层。注意就算 QPS 不高有些任务比如长文档总结的 Token 消耗可能很大还是得算算 TPM 有没有超限。推荐用 Python 或 Node.js 写个轻量脚本配合前面说的令牌桶和重试机制。中等并发10-100 QPS方案官方 API 聚合平台/兼容接入服务。聚合平台通常能提供更高的默认速率限制比如把多个底层账户的配额合并还支持多线路自动切换。但得权衡聚合平台可能会引入额外延迟中转节点而且有些平台对模型版本的支持不如官方及时。企业用户的话可以关注聚合平台是否提供子账号管理、用量审计、发票这些企业功能。如果不确定先申请个试用账号拿真实负载包含流式请求做 24 小时压力测试记录 P95 延迟和错误率。高并发 100 QPS方案私有化部署开源模型 自建网关。当 100 QPS 全部用 GPT-4o 时月 Token 成本可能高达几十万美元而且官方也很难保证 SLA。这时候私有化部署一个顶级的开源模型比如 DeepSeek-V2、Qwen2.5-72B反而是经济又可控的选择。自建网关负责负载均衡、缓存、限流、故障转移这些职责。技术栈推荐用 Go 或 Rust 写高性能代理层后端连接多副本的模型推理服务。注意私有部署需要自己维护硬件比如多卡 GPU 服务器、做模型量化INT8 或 FP16来降低延迟还要设计弹性扩缩容的机制。写在最后大模型 API 的高并发调优没有银弹。这篇文章给的代码和策略是基于通用经验的最佳实践但每个平台的具体限制、每个模型的特性都不一样。建议在开发阶段就设计好可观测性比如把每个请求的延迟、Error Code、Token 消耗都记录到日志里然后用真实的业务流量反复压测。稳定性的提升不是一次性的而是一个持续迭代的过程。