1. 从一条报错说起：限流到底在限制什么

第一次在控制台看到You've reached our limits of messages这行红字的时候，我正带着一个小团队做一个对话类应用的联调。前一秒还在正常返回，后一秒整条链路直接卡死，前端转圈，后端日志里全是 429。当时第一反应是"账号被封了？"，排查了半小时才发现，是短时间内并发请求打得太密，触发了服务端的速率限制。

这个报错本质上不是"你错了"，而是"你太快了"。大模型推理服务背后是昂贵的算力资源，服务方必须通过限流来保证所有调用方都能拿到相对公平的响应时间。理解这一点很关键：限流不是惩罚，是资源调度的一种手段。你把它当成"系统在保护自己"，心态就对了，处理思路也会完全不同。

这篇内容我想聊的是：当你调用对话类大模型接口、频繁撞上这条限流报错时，怎么从"被动挨打"变成"主动设计"。适合谁看？正在做 AI 应用后端、写过调用封装、被 429 折磨过的开发者；也适合刚接触 API 调用、想搞清楚限流底层逻辑的新手。我会把限流的几种常见维度、退避重试的实现、令牌桶的落地代码、以及我踩过的坑都摊开讲，尽量让你看完就能直接改自己项目里的那层调用封装。

先说结论：处理限流的核心不是"重试"两个字，而是在客户端主动做流量整形，让请求在发出之前就已经是"服务端愿意接受的样子"。重试只是兜底，不是主力。很多人一上来就写个while(true) { try; catch; sleep }，结果越重试越糟，把配额耗得更快，还拖垮了自己的线程池。下面我们一层层拆。

2. 限流机制的几种常见维度与背后逻辑

2.1 请求频率、并发数与令牌配额的三角关系

服务端的限流通常不是单一维度，而是几个维度叠加。我观察下来，最常见的三类是：单位时间请求数（RPM/TPM）、并发连接数、令牌（token）消耗配额。这三者像三个不同的闸门，任何一个超了都会给你返回限流错误，但报错文案可能长得一模一样，这就给排查带来了麻烦。

• RPM（每分钟请求数）：最直观，一分钟内你发了多少个请求。适合按"次数"计费的场景。
• TPM（每分钟令牌数）：按输入+输出的 token 总量算。长文本场景下，这个往往比 RPM 先撞墙。你发 10 个请求，每个塞 8000 token 的上下文，RPM 才 10，但 TPM 已经 8 万了。
• 并发数：同一时刻正在处理中的请求数量。流式输出场景下，一个请求可能挂几十秒，并发很容易堆高。

为什么服务方要这么设计？因为推理是"显存换时间"的买卖。一个请求占着显存不放，别的请求就得排队。RPM 控制的是"入场券发放速度"，TPM 控制的是"每个入场者占用的场地大小"，并发控制的是"场内同时容纳的人数"。三者配合，才能让 GPU 利用率维持在一个既不空闲也不雪崩的区间。

提示：不要只盯着 RPM 调参。我见过一个项目把 RPM 压到很低还是频繁报错，最后发现是单次请求的上下文太长，TPM 早就爆了。排查限流问题，先把这三个维度都算一遍。

2.2 为什么"重试"是最容易写错的一环

新手处理限流的本能反应是"失败了就再试一次"。这个思路方向没错，但细节全是坑。最典型的错误是固定间隔重试：sleep(1)然后重发。问题在于，如果服务端是按秒级窗口限流，你所有客户端都在同一秒醒来重发，瞬间又形成一次小高峰，这叫"重试风暴"，比不重试还糟。

第二个错误是无上限重试。请求一直失败，代码一直循环，线程被占死，上游超时，整个服务雪崩。第三个错误是不区分错误类型。限流（429）该退避重试，但参数错误（400）、鉴权失败（401）你重试一万次也没用，纯属浪费配额。

正确的做法是指数退避 + 随机抖动 + 最大次数上限。指数退避让重试间隔逐次拉长（1s、2s、4s、8s...），随机抖动（jitter）打散多个客户端的重试时间点，避免同步。最大次数兜底，防止无限循环。这个组合是业界处理瞬时故障的标准姿势，不是玄学。

2.3 客户端限流与服务端限流的分工

很多人以为限流是服务端的事，客户端只能被动接受。其实成熟的调用方都会在客户端做一层主动限流，也就是"流量整形"。逻辑很简单：我知道服务端大概给我多少配额，那我在发请求之前就先自己卡一道，保证发出去的速率不超过这个值。这样服务端根本不会触发限流，你也就不会看到那条报错。

这就像去热门餐厅吃饭，服务端是门口的发号员，客户端限流是你自己心里有数"这家店一小时就放 60 桌"，那你就不用每隔 10 秒去问一次"有位置了吗"，而是掐着点去。主动限流的好处是：请求成功率接近 100%，延迟可预测，不会因为重试把整体耗时拉长。代价是你需要维护一个本地计数器，稍微复杂一点，但绝对值得。

3. 核心实现：令牌桶与指数退避的落地

3.1 令牌桶算法为什么适合这个场景

限流算法有好几种：固定窗口、滑动窗口、漏桶、令牌桶。我最终选令牌桶，原因是它允许"突发"。固定窗口的问题是窗口边界处会有双倍流量（比如 59 秒发满，01 秒又发满），滑动窗口实现复杂，漏桶则严格匀速、不允许突发。

令牌桶的模型是：桶里最多存 N 个令牌，系统以固定速率往桶里加令牌，每个请求消耗一个令牌，桶空了就等待。它的妙处在于——平时攒下的令牌可以在需要时一次性用掉，应对短时突发；但长期平均速率又被严格限制在加令牌的速度上。对话类应用经常有"用户连续追问"的突发场景，令牌桶刚好匹配。

下面是我项目里用的一个简化实现，纯 Python，不依赖第三方库，方便你直接抄：

import time import threading class TokenBucket: def __init__(self, rate: float, capacity: int): # rate: 每秒补充的令牌数 # capacity: 桶容量，即允许的最大突发量 self.rate = rate self.capacity = capacity self.tokens = capacity self.last_refill = time.monotonic() self.lock = threading.Lock() def _refill(self): now = time.monotonic() elapsed = now - self.last_refill # 按流逝时间补充令牌，不超过容量 self.tokens = min(self.capacity, self.tokens + elapsed * self.rate) self.last_refill = now def acquire(self, tokens: int = 1, timeout: float = None) -> bool: deadline = None if timeout is None else time.monotonic() + timeout while True: with self.lock: self._refill() if self.tokens >= tokens: self.tokens -= tokens return True # 计算还差多少令牌、需要等多久 need = tokens - self.tokens wait = need / self.rate if deadline is not None and time.monotonic() + wait > deadline: return False time.sleep(wait)

这段代码有几个设计点值得说。rate和capacity的取值不是拍脑袋的：假设服务端给你 60 RPM，那rate = 1（每秒 1 个），capacity我一般设成rate * 5到rate * 10，也就是允许 5 到 10 秒的突发量。设太大，突发时容易撞服务端上限；设太小，正常波动都会被卡。time.monotonic()而不是time.time()，是因为前者不受系统时钟调整影响，避免时间回拨导致令牌计算错乱。加锁是因为多线程环境下tokens是共享状态，不加锁会出现竞态。

3.2 指数退避重试的完整封装

令牌桶管的是"发之前"，退避重试管的是"发之后失败了怎么办"。两者配合才是完整方案。下面是我封装的一个调用函数，把限流、重试、错误分类都揉进去了：

import random import time def call_with_retry(func, max_retries=5, base_delay=1.0, max_delay=32.0): for attempt in range(max_retries + 1): try: return func() except RateLimitError as e: if attempt == max_retries: raise # 指数退避 + 全抖动 delay = min(max_delay, base_delay * (2 ** attempt)) delay = random.uniform(0, delay) # 如果服务端返回了 Retry-After，优先用它 retry_after = getattr(e, "retry_after", None) if retry_after: delay = max(delay, float(retry_after)) time.sleep(delay) except (AuthError, BadRequestError): # 这类错误重试无意义，直接抛 raise

这里的关键是错误分类。RateLimitError才走退避，鉴权和参数错误直接抛。base_delay我一般设 1 秒，max_delay设 32 秒，max_retries设 5 次——5 次退避下来总等待时间大约 1+2+4+8+16=31 秒（加抖动后更分散），足够扛过大多数瞬时限流。如果 5 次还不行，说明配额是真的用完了，再重试也是徒劳，不如快速失败让上游感知。

random.uniform(0, delay)是全抖动策略，比"固定抖动"（delay 的某个比例）更能打散重试时间。多个客户端同时失败时，全抖动能让它们的重试时间点均匀分布在区间内，避免再次撞车。这个细节很多教程不讲，但实测下来对降低二次限流率有明显帮助。

3.3 把 Retry-After 响应头用起来

服务端返回 429 时，通常会带一个Retry-After头，告诉你"多少秒后再来"。这个信息比你自己猜的退避时间准得多，一定要用。我上面的代码里retry_after就是读这个值，并且用max(delay, retry_after)取较大者——因为服务端说等 10 秒，你等 2 秒去撞，纯属浪费。

有些实现会忽略这个头，直接用自己的退避曲线，结果就是明明服务端让你等 30 秒，你 4 秒就重试，又被拒，来回折腾。养成读响应头的习惯，能省很多事。如果响应头没给，再退回自己的退避逻辑。

4. 实操过程：从裸调用到稳定封装的改造记录

4.1 改造前的裸调用长什么样

改造前的代码大概是这样，相信很多人眼熟：

def ask(prompt): resp = client.chat(prompt) return resp.text

简单直接，但没有任何防护。上线第一天，用户量一上来，日志里 429 刷屏，前端体验极差。我当时的排查记录是这样的：先看错误率曲线，发现集中在整点后的前两分钟——因为有个定时任务在整点批量触发。再看单次请求的 token 量，发现有些用户粘贴了超长文档，单请求 token 是普通请求的几十倍。两个问题叠加，RPM 和 TPM 同时爆。

4.2 分三步改造：限流、重试、降级

改造我分了三步走，每步都能独立上线验证，避免一次性改太多出问题。

第一步，加客户端令牌桶。根据服务端给的配额，算出rate和capacity，在调用入口处acquire()。这一步上线后，429 错误率直接降了八成。因为大部分请求在客户端就被"排队"了，根本没打到服务端。

第二步，加退避重试。针对剩下那两成漏网的（比如配额临时被其他系统占用），用指数退避兜底。这一步让请求成功率从 92% 提到了 99% 以上。

第三步，加降级策略。对于重试 5 次仍失败的请求，不再死磕，而是返回一个"当前繁忙，请稍后再试"的友好提示，同时把请求丢进一个延迟队列，过几分钟再异步处理。这一步是为了保护用户体验——宁可告诉用户"稍等"，也不要让页面一直转圈。

三步下来，整体成功率稳定在 99.5% 以上，P99 延迟从不可控变成了可预测。这里有个经验：改造要能灰度。我第一步只对 10% 的流量开启令牌桶，观察一天没问题再全量，避免算法参数设错导致大面积阻塞。

4.3 参数怎么定：一个可复现的计算过程

参数不是拍脑袋，我拿实际数据算一遍给你看。假设服务端配额是 60 RPM、40000 TPM，你的应用平均每个请求消耗 500 token（输入 300 + 输出 200）。

先算 RPM 约束：60 请求/分钟 = 1 请求/秒，所以rate_rpm = 1。 再算 TPM 约束：40000 token/分钟 ÷ 500 token/请求 = 80 请求/分钟，比 RPM 宽松，所以 RPM 是瓶颈。 最终rate = 1（取两者较小值对应的速率），capacity = 5（允许 5 秒突发）。

但如果你的应用是长文本场景，平均每请求 3000 token，那 TPM 约束变成 40000 ÷ 3000 ≈ 13 请求/分钟，远小于 60，这时瓶颈是 TPM，rate应该按 13/60 ≈ 0.22 来设。所以参数必须结合你自己的平均 token 消耗来算，不能照抄别人的配置。我建议上线前先跑一周的监控，统计出真实的平均 token 和请求分布，再定参数。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

下面这张表是我和团队踩坑后整理的，遇到限流问题先对着查一遍，能省不少时间：

5.2 多实例部署下的配额共享陷阱

这个坑我印象最深。单机部署时令牌桶工作得很好，一上多实例，问题来了：每个实例各自维护一个令牌桶，3 个实例就是 3 倍的实际速率，服务端配额瞬间被打爆。因为令牌桶是进程内状态，实例之间不共享。

解决办法有两个方向。一是集中式限流：把令牌桶状态放到一个共享存储里（比如用 Redis 的原子操作做计数器），所有实例统一扣减。二是配额均分：如果服务端给 60 RPM，3 个实例就每个分 20 RPM，各自本地限流。前者精确但多一次网络往返，后者简单但实例数变化时要重新分配。我项目里用的是均分方案，因为实例数相对固定，均分的误差可以接受，而且省掉了每次请求都访问共享存储的开销。

注意：均分方案要留余量。3 个实例各分 20，实际可能因为负载不均某个实例先打满，所以我会把每实例配额设成理论值的 80%，留 20% 缓冲。

5.3 流式输出场景的特殊处理

流式（streaming）场景下，限流的处理不太一样。普通请求是"发出去-等结果"，流式是"发出去-持续收数据"，一个请求可能占用连接几十秒。这时候并发数比 RPM 更容易成为瓶颈。

我的处理是：对并发流数量单独设一个信号量，比如最多同时 10 个流，超出的排队。同时，流式请求的 token 消耗是逐步产生的，TPM 统计要按"预估总量"来算，不能等流结束才计。另外，流式请求一旦开始就很难中途重试（用户已经看到部分输出了），所以重试逻辑要放在"建立连接"阶段，连接建立成功后的中断只能靠前端提示重连。

5.4 几个容易被忽略的细节

第一个细节：退避期间不要占着线程。如果你的重试是在同步代码里sleep，那这个线程就被白白占用了。高并发下线程池很快耗尽。更好的做法是把重试任务丢进延迟队列，或者用异步框架的await asyncio.sleep()，让出执行权。

第二个细节：监控要能看到限流率。我见过团队只监控"请求成功率"，结果限流被重试掩盖了，直到配额彻底用完才发现。单独打一个"限流触发次数"的指标，能让你提前感知配额压力。

第三个细节：别把重试日志刷爆。每次重试都打一条 error 日志，限流高峰时日志量能把你磁盘写满。重试日志用 warn 级别，并且做采样，比如每 100 次记一次。

6. 我个人的几点实操体会

做这类调用封装，最大的感受是：限流处理的好坏，七分靠设计，三分靠调参。设计对了，参数微调就能稳定；设计错了，参数怎么调都是打补丁。令牌桶 + 指数退避 + 错误分类这个组合，我用了好几个项目，基本没出过大问题。

还有一个体会是，不要迷信"无限重试"。很多教程教你重试到成功为止，但真实系统里，配额是真会用完的，无限重试只会让故障扩散。快速失败 + 友好降级，往往比死磕更专业。用户能接受"稍后再试"，但接受不了页面卡死。

最后分享一个小技巧：把限流参数做成可热更新的配置，而不是写死在代码里。服务端配额调整、业务流量变化都是常态，能不改代码就调参数，运维成本会低很多。我项目里是放在配置中心，改完几十秒生效，配合监控看曲线，调参效率高不少。