大模型 API 限流与重试最佳实践

在使用大模型 API 时,最常见也最头疼的问题莫过于“429 Too Many Requests”。无论是每分钟请求数(RPM)还是每秒令牌数(TPM)耗尽,如果没有合理的限流应对策略,你的应用就会在关键时刻掉链子。本文将拆解 API 限流背后的逻辑,并结合代码示例,分享一套生产可用的重试最佳实践。

## 理解限流:它为什么要拒绝你

API 限流是服务端为了保护基础设施、实现公平调度而设置的流量控制机制。常见的限流维度包括:

- **每分钟请求数(RPM)**:例如 500 次请求/分钟 - **每分钟令牌数(TPM)**:例如 100 万 tokens/分钟 - **并发连接数**:限制同时打开的 WebSocket 或 SSE 通道

当客户端超过阈值时,服务端会返回 `429` 状态码,并在响应头中带上 `Retry-After`(秒数)或 `X-RateLimit-Reset` 等提示。合理的客户端必须尊重这些信号,而不是无脑重试。

## 重试策略:别让重试变成“惊群”

### 1. 指数退避 + 随机抖动

最简单的重试是固定间隔,但这会加剧冲突。推荐使用“指数退避 + 随机抖动”:

``` backoff_time = min(base_delay * (2 ** attempt), max_delay) jitter = random.uniform(0, backoff_time * 0.5) sleep_time = backoff_time + jitter ```

这种组合让重试在时间上分散,避免多个客户端同时发起请求造成二次过载。

### 2. 尊重 `Retry-After` 头

如果响应里带有 `Retry-After`,应优先使用该值,它是服务端最准确的恢复指示。代码中可以这样处理:

```python def get_retry_after(response): retry_after = response.headers.get('Retry-After') if retry_after: try: return int(retry_after) except ValueError: pass return None ```

### 3. 使用成熟的退避库

手动实现退避逻辑容易出错,推荐 Python 的 `tenacity` 或 `backoff` 库。以下是基于 `backoff` 的健壮示例:

```python import backoff import requests import random

@backoff.on_exception( backoff.expo, # 指数退避 requests.exceptions.HTTPError, max_tries=5, # 最多重试5次 max_time=120, # 总重试时间不超过120秒 giveup=lambda e: e.response.status_code != 429 # 只在429时重试 ) def call_llm(url, payload, api_key): headers = {"Authorization": f"Bearer {api_key}"} response = requests.post(url, json=payload, headers=headers) if response.status_code == 429: # 如果存在 Retry-After,将其作为退避的“特殊”处理 # 这里简单抛出,让 backoff 自动等待 raise requests.exceptions.HTTPError(response=response) response.raise_for_status() return response.json() ```

`backoff.expo` 默认的退避因子是 2,并自动加入随机抖动,无需自己计算。若需要完全遵循服务端的 `Retry-After`,可以自定义 `factor` 或结合 `wait_gen`。

### 4. 客户端侧预限流

除了被动重试,还应在客户端实现速率控制。可以使用令牌桶(Token Bucket)或信号量,预先限制发出的请求速率,从源头减少 429 的发生。

### 5. 熔断与降级

当重试次数过多或时间内一直命中 429,应该触发熔断,暂停请求并快速失败,返回缓存数据或备用回复,避免雪崩。可以加入 gRPC 拦截器或 API 网关层统一处理。

## 一次配置,多模型无忧

虽然我们可以花大量时间针对每个模型 API 调优重试策略,但如果你同时接入了 DeepSeek、Qwen、Claude、Gemini 等多种模型,维护各自的限流逻辑会让代码变得臃肿。此时一个统一的中转站能极大减轻负担。

**TokenPocket API 中转站** (https://tokenpocket.site) 正是为此而生。它支持 DeepSeek、Qwen、Claude、Gemini 等主流模型的统一调用,全系按量计费,无需规划复杂的各厂商限流规则,新用户注册即送免费额度。你只需一个 token,一个 endpoint,就能用完全相同的调用风格访问所有模型,内部已优化好重试与容错,把你的精力留给业务创新。

Read more

Claude API 接入教程:编程与写作中的实战技巧

Claude API 在编程辅助、写作润色和内容生成场景中表现稳定。本文将用最小可用代码带你完成接入,并分享几个实战技巧。 ## 准备工作:获取 Key 与环境配置 调用 Claude API 需要 API Key。为了便于国内开发者使用,你可以直接从官方申请,也可以通过支持多模型的 API 中转站获取统一 Key。本文以 Python 的 `requests` 库为例,只需要安装: ```bash pip install requests ``` ## 基础调用:发送第一条消息 Claude 使用 `/v1/messages` 接口,核心参数包括 `model`、`max_tokens` 和 `messages`。下面是一个最小可运行示例: ```python import requests API_

By 罗本

ETH vs TRON 转账手续费对比:每年能省多少钱?

很多人在转账 USDT 时,习惯使用以太坊网络,却忽略了手续费这笔“隐形支出”。单看一笔似乎不多,但日积月累,尤其是在高频转账场景下,差距会非常大。今天我们就用 ETH 和 TRON 两个网络,算一笔明白账。 ## 一、单笔手续费差距有多大? 以太坊网络转账 USDT 需要使用 ETH 作为 Gas 费。Gas 费会随网络拥堵程度波动,普通时段一笔 ERC20 USDT 转账大约需要 3~8 美元,高峰期甚至可能超过 10~20 美元。 波场网络转账 USDT 或 USDD 则采用资源模型,主要消耗“能量”和“带宽”,通常用 TRX 来支付或质押获取资源。

By 罗本

AI API 按量计费 vs 包月套餐怎么选

很多开发者在接入大模型 API 时,第一个纠结的问题就是:到底选按量计费还是包月套餐?这并没有绝对答案,关键要看你的调用量是否稳定、可预测。简单结论是:开发测试、流量波动大、或刚上线的产品,优先选按量计费;生产环境流量稳定且量级较大时,再考虑包月套餐。 **先看你的调用曲线** 按量计费的核心优势是“用多少付多少”。假设你的应用每天只有几百次请求,或者某些时段会突然出现峰值,按量计费不会让你为闲置额度买单。包月套餐则适合那些请求量非常稳定、且每月至少消耗固定 token 量的团队。 我们可以用一段简单代码估算单次请求成本: ```python def estimate_cost(tokens_in, tokens_out, price_in, price_out): # 价格单位:美元 / 1M tokens return (tokens_in / 1_000_000) * price_in

By 罗本

自由职业者收款指南:用 USDT 波场网络零费用结算

自由职业者做跨境业务,最头疼的不是找客户,而是收款。传统银行电汇慢、手续费高,PayPal 又有提现损耗和风控问题。越来越多自由职业者开始用 USDT 稳定币结算,其中波场网络 USDT 因为速度快、地址简单、生态成熟,成了很多人的首选。今天就用一篇通俗指南,讲清楚如何用波场网络实现 USDT/USDD 零费用收款。 ## 为什么自由职业者适合用 USDT 结算 USDT 锚定美元,价格稳定,客户容易接受。自由职业者收款最怕两件事:一是币价波动吃掉利润,二是到账慢影响现金流。USDT 能解决波动问题,而波场网络转账通常几秒钟到几分钟就能完成,比传统跨境汇款快得多。 另外,波场网络地址是 T 开头的一串字符,比以太坊地址更短,复制时不容易出错。对于需要频繁向不同客户发收款地址的自由职业者来说,这一点很实用。 ## USDT 和 USDD 怎么选 USDT 是最通用的稳定币,几乎所有交易所和钱包都支持,

By 罗本