GPTs 应用高峰期频繁返回 429，API 通道扩容该按并发请求数还是 Token 吞吐量来算？

GPTs 应用在高峰期返回 429 时，扩容必须同时按「请求并发数（RPS）」和「Token 吞吐量（TPM）」两条线计算，只扩其中一条通常会在另一条上卡住；如果并发只来自少量固定用户、总量远低于通道速率限制，那么不必做池化，改超时设置即可。这个判断的前提是：限流发生在通道侧，而不是你自己服务端的线程池或连接池先耗尽。 并发要先拆成三种，否则容量永远算不准。第一种是请求并发，即每秒发起多少次调用；第二种是 Token 吞吐，即这些请求携带的上下文体量，长对话和长系统提示词会让 TPM 先于 RPS 触顶；第三种是流式连接数，GPTs 这类应用多用 SSE 流式返回，一个未结束的流就占一条长连接。三者对应的扩容手段完全不同，混在一个指标里看，就会出现「机器加了、报错没少」的情况。 定位瓶颈的顺序比扩容动作更重要。先在低峰期对单条通道做阶梯压测，记录错误率从 0 开始上升的拐点、P95 首 token 延迟和 429 占比，这组数字是单通道的可用基线；再对照应用侧的同时在线请求数、HTTP 客户端连接池占用和网关排队长度。如果应用侧连接池先满，问题在客户端复用；如果 429 先出现而本地连接池空闲，问题在通道限流。 应用侧的扩容第一件事是把 HTTP 客户端做成全局复用。每个请求新建客户端、每次调用重新建 TLS 连接，会把大量时间耗在握手和连接数堆积上，表现出的现象很像通道不够用，实际是本地连接管理失控。做法是使用带 keep-alive 的连接池、按通道数量设定最大连接数和空闲回收时间，并给流式请求单独分配连接配额，避免长连接把短请求的连接槽位占满。 通道侧的扩容核心是池化，而不是无限加账号。把多条通道组织成池，按加权轮询或最少连接数分发，权重依据各通道实测的 TPM 上限和当前 P95 延迟动态调整；同时给每条通道配健康探测、熔断和半开恢复，某条通道连续 429 或超时就自动摘除，恢复后先放小流量试探。多轮对话还需要会话粘性，同一会话尽量落在同一通道上，否则上下文漂移会带来重复计算。 流式返回是扩容中最容易被低估的一段。SSE 长连接会长时间占用服务端工作线程和网关 upstream 连接，反向代理若开启响应缓冲，还会让首 token 延迟被人为拉长。处理方式是关闭该路径的 proxy buffering、设置明确的读超时和空闲回收时间、限制单实例的最大并发流数，并在网关层做排队而不是直接拒绝，让超出容量的请求等待而不是立即失败。 排队与背压要有优先级，否则扩容只是把雪崩推迟几秒。在线交互请求和批量任务共用一条通道时，批量任务很容易把令牌桶打空，因此应把流量分成两到三个优先级队列，交互请求优先取令牌，批量任务在低峰期或剩余配额内运行。同时给每个请求设总超时预算，把预算拆到排队、连接、首 token 和流式输出各阶段，任一阶段超预算就快速失败，而不是让请求一直挂着吃掉连接。 重试策略直接决定扩容是否被自己抵消。只对 429 和 5xx 重试，使用指数退避加随机抖动，限制最大重试次数，并让重试计入总超时预算；对流式请求，输出已经开始后中途断开不宜盲目重试，否则会同时产生重复输出和双倍 Token 消耗。另一个常见放大器是并发重试：上游一抖动，所有客户端同一秒重发，等于把瞬时并发翻倍，抖动就是用来打散这个峰值的。 在加通道之前，先做降载往往比扩容便宜得多。可用的手段包括：对重复或高度相似的提示词做结果缓存，提高命中率；利用前缀缓存把固定的系统提示词和长上下文前置，减少重复计费；压缩对话历史，只保留必要轮次；按任务难度做模型分级路由，把简单意图交给小模型兜底。缓存命中率每提高一档，实际需要的通道数就下降一档，这个杠杆比单纯增加通道更值得优先做。 容量规划要给出可执行的触发线，而不是凭感觉加通道。以压测得到的单通道基線为底，按预计峰值 RPS × 平均上下文体量估算 TPM 需求，取两条线中更紧的那条决定通道数，再留出两到三成余量应对突发；把 P95 首 token 延迟、429 占比和流式连接占用率设为监控告警项，任一指标持续越过阈值就触发扩容评审。扩容后要用同一套压测脚本复测，确认瓶颈已转移而不是被掩盖。 扩容的成本结构由四部分组成：通道数 × 单价、网关与队列等中间件、连接与缓存的服务器资源、以及运维人力。前三项随流量线性增长，第四项随通道数量非线性增长，所以通道池不是越多越好，通道过多会让健康检查、权重调优和故障定位的成本快速上升，通常控制在个位数到十余条之间更容易维护。 扩容还要划清合规与稳定性边界。多通道池化必须遵守各服务商的账号与速率条款，不能通过拆分账号规避限流；涉及用户数据的提示词要评估留存与传输范围，日志里对敏感字段做脱敏，保留可追溯的调用记录。做不到这些条件时，正确做法是限制入口流量、做排队降级，而不是继续加通道。 总结成一条可执行顺序：先降载（缓存、压缩、分级路由），再修应用侧连接复用与超时，然后做通道池化与熔断，最后才是增加通道数量。跳过前三步直接加通道，通常只能把 429 变成更贵的 429；而前三步做到位后，很多所谓的高并发场景其实并不需要真正扩容。