国产大模型限流政策对比：RPM / TPM / 并发数详解
凌晨两点被叫起来查线上问题，日志里刷了一整屏 429 Too Many Requests，业务方在群里问”是不是模型挂了”——这大概是接国产大模型 API 最容易踩的一个坑。模型本身没挂，只是你的调用节奏撞上了厂商的限流策略。RPM（每分钟请求数）、TPM（每分钟 token 数）、并发数这三个维度不摸清楚，压测阶段看着好好的接口，一到大促或者活动放量就集体报错，排查半天才发现是限流在作怪。这篇把这几个维度掰开揉碎讲清楚，顺带给几套能直接抄的工程方案。
核心限流维度说明
| 维度 | 含义 | 超出后行为 |
|---|---|---|
| RPM（Requests Per Minute） | 每分钟最大请求次数 | 返回 429 Too Many Requests |
| TPM（Tokens Per Minute） | 每分钟最大 token 消耗量 | 返回 429（token 维度限速） |
| 并发数（Concurrent Requests） | 同时处于处理中的请求数 | 超出时新请求直接拒绝或排队 |
| 每日上限（Daily Quota） | 每天累计用量上限（部分平台） | 达到后当天不可再调用 |
这四个维度不是并列生效的，而是”任意一个先触底就先报错”。这里有个新手最容易翻车的认知误区：以为只要请求次数没超 RPM 就不会被限流，结果一个长文档解析任务直接把 TPM 打满，返回的照样是 429，错误信息却和触发 RPM 时长得一模一样，很难从报错本身区分是哪个维度超限——这也是很多团队排查半天无果的根源。稳妥的做法是接口返回头里如果带了 x-ratelimit-remaining-requests 和 x-ratelimit-remaining-tokens（不同厂商字段名不同，具体以官方文档为准），一定要在日志里打出来，出问题时一眼就能看出是哪个维度先见底的，而不是靠猜。
限流的底层实现，大部分厂商用的是令牌桶或滑动窗口算法，而不是简单的”每分钟计数器清零”。这意味着如果你在第 59 秒突然发一波请求，第 61 秒又发一波，即使两分钟内总量没超，也可能因为瞬时突发（burst）超过桶的容量而被拒。所以”平均值不超限”不等于”不会被限流”，真正决定你会不会被 429 的是请求节奏是否平滑，这也是后面讲的令牌桶限速方案要解决的核心问题。
六大厂商限流概况
截至 2026-06，以官方文档为准；实际限额因账号等级（免费/付费/企业）差异显著。
| 厂商 | 免费档 RPM | 付费档 RPM | 并发数参考 | 提升方式 |
|---|---|---|---|---|
| DeepSeek | 约 60 | 按充值等级提升 | 数十路 | 联系商务申请配额提升 |
| 通义千问 | 约 120 | 1000+ | 视模型而定 | 阿里云工单申请 |
| 智谱 GLM（Flash 免费） | 约 60 | 1000+ | 10~20 路 | 升级付费后自动提升 |
| Kimi | 约 20 | 200+ | 10~50 路 | 账户充值后自动提升 |
| 文心一言 | 约 60 | 1000+ | 视模型而定 | 千帆控制台申请 |
| 豆包 | 约 60 | 500+ | 视模型而定 | 火山引擎工单 |
免费档的这些数字看着不低，但真到了生产环境几乎都不够用，原因是免费档往往还叠加了”每日总量”这道隐藏门槛。比如某些平台免费档 RPM 看着有 60，实际当天调用量到了几千次就直接触发日配额封顶，报错文案和 RPM 超限的 429 长得一样，你以为是并发没控好，实际上是日总量见底了，得等到第二天零点才恢复。排查这类问题的思路很简单：把每次 429 的响应体完整打出来（不要只打状态码），大部分厂商会在 message 字段里区分”requests per minute”和”requests per day”，字面意思差一个词但处理方式天差地别——前者退避几秒重试就行，后者退避多久都没用，只能切备用模型。
另外免费档和付费档之间不是平滑过渡的，很多厂商是”阶梯式跳变”：账号里只要有过一次成功充值（哪怕充 1 块钱），限额可能直接从 60 RPM 跳到 1000+ RPM，而不是按充值金额线性增长。如果你的项目预算有限但对稳定性要求高，比起纠结免费额度怎么省着用，不如先小额充值把账号等级跳过去，性价比通常更高。
应对限流的四种工程方案
① 指数退避重试
遇到 429 时不要立即重试，按 1s → 2s → 4s → 8s 指数退避，最多重试 3~5 次：
import time
import openai
def chat_with_retry(client, model, messages, max_retries=5):
for attempt in range(max_retries):
try:
return client.chat.completions.create(model=model, messages=messages)
except openai.RateLimitError:
if attempt == max_retries - 1:
raise
wait = 2 ** attempt
print(f"限流，{wait}s 后重试...")
time.sleep(wait)
这段代码能用，但直接抄到生产环境会有个隐患：如果同时有 100 个请求都被限流，它们的 2 ** attempt 算出来是完全相同的等待时间，等待结束后又会同时发起重试，相当于把拥堵原样后移了一个时间片，没解决根本问题，业内管这个现象叫”重试风暴”。真正的做法是在退避时间上加一点随机抖动（jitter），比如 wait = 2 ** attempt + random.uniform(0, 1)，把同时失败的请求错开到不同的时间点重试。另外重试次数不是越多越好——如果连续 5 次都是 429，大概率不是瞬时抖动，而是配额真的见底了，这时候应该走后面第③种方案切模型，而不是傻等重试，白白拉长用户等待时间。
② 令牌桶/滑动窗口限速 在客户端侧主动控速，保持低于厂商上限：
import asyncio
sem = asyncio.Semaphore(10) # 最大并发 10
async def safe_request(client, **kwargs):
async with sem:
return await client.chat.completions.create(**kwargs)
这里的 Semaphore(10) 数字不是拍脑袋定的，得实打实压测出来。做法是从小往大加压：先设成 5，跑一段时间观察有没有 429；没有就加到 10、20，直到刚好开始偶发限流为止，然后回退 20%~30% 作为线上安全值，留出给厂商侧限流窗口抖动的余量。要注意 Semaphore 控制的只是并发数，不代表 TPM 就稳了——如果每个请求的输入都是几千 token 的长文档，哪怕并发只有 10，TPM 照样可能被打爆，这种场景需要在信号量之外再加一层基于 token 消耗量的滑动窗口计数器，每次请求前累加预估 token 数，超过阈值就排队等待，而不是只卡并发数量。
③ 多模型路由降级 将请求按优先级路由到多个厂商，主链路满载时自动切到备用模型：
主链路：DeepSeek-V3（低价）
↓ 429 / 超时
备链路：通义千问 Qwen-Plus
↓ 仍然失败
降级响应：返回缓存结果或提示稍后重试
这套降级链路落地时最容易被忽略的是”回切”逻辑：很多团队只写了往下降级的路径，主链路恢复正常之后却没有自动切回去，结果流量一直挂在成本更高的备链路上，月底账单异常了才发现问题。建议加一个简单的健康检查：每隔固定时间（比如 30 秒）用一个轻量请求探测主链路是否恢复，恢复后再把新流量切回去，已经在处理中的请求不用打断。另外选备链路时优先挑和主链路输出风格接近的模型，否则用户能感知到”这次回答风格突然变了”，尤其是在客服、写作助手这类对语气敏感的场景。
④ 请求队列 + 批处理 非实时任务用 Batch API 异步处理，彻底绕开并发限制，成本同步降低 50%。参考 Batch API 详解。
这一条对”非实时”三个字要较真：批处理的代价是延迟从秒级变成分钟甚至小时级，所以只适合本来就不追求即时响应的场景——比如夜间批量生成商品文案、离线跑历史数据的情感分析、周期性生成报表摘要。反过来，如果业务方要求”用户提交后几秒内看到结果”，硬塞进批处理队列只会引发新的投诉，这类场景该走的是前面①②③的组合拳，而不是批处理。判断标准很简单：先问一句”这个任务几分钟内出结果和几小时内出结果，对业务有区别吗？“没区别就上批处理，有区别就老老实实做限流和降级。
常见问题
RPM 和 TPM 哪个更容易触发限制？ 取决于业务场景。短 Prompt 高频调用容易触发 RPM；长文档、大上下文任务（RAG、合同解析）更容易触发 TPM。实际生产中建议同时监控两个维度。
触发限流后多久恢复？ 大多数平台以「分钟」为窗口，即等待 60 秒内请求计数清零后即恢复。部分平台有每日上限（特别是免费档），需等次日刷新。
企业账号的限制比个人高多少？ 通常高出 5~10 倍，部分厂商可定制专属配额（需签合同）。如果评估阶段就面临瓶颈，建议提前联系商务走企业通道。
怎么自己压测出真实的限流上限，而不是照抄文档数字？ 官方文档给的往往是”标称值”，实际执行中会有波动，稳妥的做法是自己跑一次阶梯压测：写个脚本按固定并发（比如 5、10、20、40）依次发起请求，每个梯度跑 2~3 分钟，记录首次出现 429 的并发数和时间点。注意压测时间点要覆盖业务高峰和低谷各跑一次——不少厂商的限流阈值不是固定死的，会根据平台整体负载动态调整，白天高峰期的实际上限可能比凌晨低不少，只压测一次凌晨的数据会让你对线上容量产生错误的乐观预期。
能不能靠多开几个账号来绕开限流做”账号池”？ 技术上可行，但要先看清楚账号池这件事本身的代价和风险，而不是当成免费的扩容捷径。多账号意味着要维护多套密钥轮换逻辑，增加故障点；更重要的是不少厂商服务条款里明确禁止单一实体注册多个账号规避限流，一旦被识别出批量小号大概率被封禁，反而影响到主账号。合规稳妥的路径还是通过企业实名认证走正规的配额提升申请，账号池更适合作为过渡期的临时缓冲手段，而不是长期架构方案。
落地自检清单
方案抄完不代表就万事大吉，上线前建议对着这几条过一遍：
- 日志里是否打印了限流响应头：
x-ratelimit-remaining-*之类的字段没记录下来，出问题时就只能靠猜，务必确认接入日志能看到这些信息。 - 重试是否带了随机抖动：纯指数退避没有 jitter，大流量场景下会引发重试风暴，一定要加。
- 是否区分了”分钟级限流”和”日配额耗尽”：这两种 429 处理方式完全不同，混在一起处理会导致不必要的长时间重试。
- 信号量并发数是否压测过，还是拍脑袋写的：没实测过的并发上限，大促当天大概率会翻车。
- 降级链路是否有自动回切：只做了降级没做回切，会悄悄推高长期成本。
这几条做扎实了，接口在流量波动时表现会稳很多。如果你还在多个厂商之间反复比价、纠结怎么选主备链路，可以去 国产模型专题 看看更系统的对比，或者去 等候名单 留个联系方式，后面接入层功能上线第一时间通知你。
相关阅读：国产大模型 API 全景指南 · 国产模型免费额度盘点 · 接口并发控制最佳实践
分类导航：国产模型专题
实用工具：价格对比表