开始
限流说明
请求过于密集时会返回 429。本站和模型服务商都会限制请求频率,额度随线路和负载变化。本页说明怎么用退避重试、并发控制、平滑流量和多把 Key 避免与应对限流。
请求太密集时会返回 429。限流可能来自两处:本站对账户和 Key 的保护性限制,以及模型服务商对每条线路的速率限制。具体额度会随线路和负载调整,本页不列固定数字,只讲怎么设计调用方式,让业务在限流时也能平稳运行。
限流从哪里来
| 来源 | 表现 |
|---|---|
| 本站的保护性限制 | 单个账户或 Key 在短时间内请求过多时返回 429 |
| 模型服务商的限制 | 每条线路都有自己的速率和并发上限,超出后返回 429 |
| 高峰期繁忙 | 模型服务负载高时可能返回 429 或 503 |
不同分组走不同线路,所以同一个模型换个分组,限流情况也可能不同。
遇到 429 怎么办
- 退避重试:等待一段时间再试,每次等待翻倍并加随机抖动,最多重试几次。响应带
Retry-After时按它等待。代码示例见错误码与重试。 - 不要立刻无限重试。连续重试只会让请求更密集,限流持续得更久。
- 重试几次仍然失败,就把任务放回队列稍后处理,或者切到备用 Key。
控制并发
批量任务最容易触发限流。给客户端设一个并发上限,同一时刻只有固定数量的请求在跑,其余排队:
import asyncio
import os
from openai import AsyncOpenAI
client = AsyncOpenAI(base_url="https://open.tutujin.com/v1", api_key=os.environ["TUTUJIN_API_KEY"], max_retries=4)
limit = asyncio.Semaphore(8) # 同时在跑的请求数,按自己的业务调整
async def summarize(text):
async with limit:
resp = await client.chat.completions.create(
model="deepseek-v4.1-flash",
messages=[{"role": "user", "content": f"用一句话总结:{text}"}],
)
return resp.choices[0].message.content
async def main(texts):
return await asyncio.gather(*(summarize(t) for t in texts))import OpenAI from 'openai'
const client = new OpenAI({ baseURL: 'https://open.tutujin.com/v1', apiKey: process.env.TUTUJIN_API_KEY, maxRetries: 4 })
// 用固定数量的 worker 处理队列,limit 就是并发上限
async function mapWithConcurrency(items, limit, fn) {
const results = new Array(items.length)
let next = 0
async function worker() {
while (next < items.length) {
const i = next++
results[i] = await fn(items[i])
}
}
await Promise.all(Array.from({ length: limit }, worker))
return results
}
const summaries = await mapWithConcurrency(texts, 8, async (text) => {
const resp = await client.chat.completions.create({
model: 'deepseek-v4.1-flash',
messages: [{ role: 'user', content: `用一句话总结:${text}` }],
})
return resp.choices[0].message.content
})并发上限先从小值开始,观察 429 出现的频率再逐步调高。
让流量更平滑
- 批量任务匀速提交,不要一次性把几万条请求同时发出去。
- 不着急的离线任务放到业务低峰时段跑。
- 给关键请求和后台任务分开排队,后台任务被限流时不影响用户实时请求。
减少请求次数
- 向量化时一次传一组文本:
/v1/embeddings的input可以是字符串数组,一个请求处理多条。 - 对相同的输入缓存结果,比如常见问题的回答、固定文档的向量。
- 用一个请求完成能合并的步骤,比如让模型一次输出多个字段的 JSON,而不是每个字段问一次。
分散到多把 Key 和多个分组
- 不同业务用不同的 Key,后台批量任务的 Key 和在线业务的 Key 分开,互不抢额度。
- 准备一把其他分组的备用 Key,主 Key 持续返回 429 或 5xx 时切换过去。分组说明见选择分组。
需要更高的并发
如果业务长期需要更高的请求量,加客服微信 JsnonoChat,说明使用的模型、分组和预计的请求规模,我们评估后答复。
没找到答案?加客服微信 JsnonoChat,发送报错信息里的 request id,我们帮你排查。