各家大模型 API 的限流口径为什么不一样？并发、RPM、TPM 横评
事实依据为 2026-08-24 抓取的各厂商官方文档。文中不写任何具体的并发数、RPM、TPM 阈值，这类数值随账户等级和平台策略变动，请以官方页面和控制台为准。
同样是 429，在不同厂商意味着完全不同的事，解法也完全不同。有的家你只要把并发池调小就能解决，有的家必须先充钱升等级，有的家提个工单就能免费扩容，还有的家是平台整体过载、跟你的调用行为无关，怎么改代码都没用。
在做容量规划之前，先搞清楚一件事：对方用的是哪把尺子。
尺子有几把：从一把到四把
这是差异最大的一层。
只有并发一把尺子的。 DeepSeek 的限速文档里，限制项只有并发数，没有 RPM 也没有 TPM。它对并发的定义写得很明确：一个请求从发出后到模型响应完成之前记为一个并发，并且并发限制以账号粒度计，与 API Key 无关——多建几个 Key 分摊不了额度。在并发限度内的请求都会得到响应，超过就返回 429。
四把尺子一起卡的。 Kimi 开放平台的「充值与限速」页里同时列了并发、RPM、TPM、TPD 四个口径，并在下方逐一解释：并发是同一时间内最多处理的请求数，RPM 是一分钟内最多发起的请求数，TPM 是一分钟内最多交互的 token 数，TPD 是一天内最多交互的 token 数。**四个口径任何一个先撞上，你就被限了。**尤其 TPD 是个容易被忽略的日累计口径，白天没事、晚上突然全线报错，多半是它。
以并发为主但按模型分开算的。 智谱开放平台的速率限制文档说明，平台对不同模型设置了不同的并发上限，通用模型、图像视频生成模型、向量模型、实时音视频模型各成一类，额度互相独立。文档还专门给并发下了定义：同一时刻正在处理中的请求数量。
按主账号合并、按模型独立的。 阿里云百炼的限流文档第一句就是关键：限流按主账号维度计算，账号下所有 RAM 子账号、业务空间和 API Key 的调用量合并计算；不同模型的限流额度相互独立。它还提到部分模型采用动态限流，根据平台的月消费档位做软限流。另外有一条很实用的补充：超出限制时请求会被拒绝，通常在一分钟内自动恢复。
聚合层则是两层限制叠加。 OpenRouter 的限制文档在解释 429 时写的是：你可能被 OpenRouter 的平台限制拦住（免费模型上限、DDoS 防护），也可能是被上游供应商限流，建议用指数退避重试并在有 Retry-After 响应头时遵守它。同一份文档里还区分了 402（余额不足）和 503（没有符合你路由要求的可用供应商），这两个经常被误当成限流。
**这一层的实际后果是：**你在 A 家验证过的并发池配置，搬到 B 家可能因为撞上一把你根本没考虑过的尺子而全线报错。RPM 和 TPM 各自的含义与估算方法，站内有RPM 和 TPM 是什么一篇专门讲。
提额的门槛：四种完全不同的「货币」
想要更高的额度，各家要你付出的东西不一样，这直接决定了你的成本模型。
按累计充值金额分层。 Kimi 的规则是基于账户的累计充值金额划分用户等级，等级越高四个口径越宽。这里有两条细则值得单独记：代金券不计入累计充值总额；另外当系统检测到账户存在异常行为时会触发风控限速策略，官方明确写了这个限制一旦触发即无法解除。
按积分等级。 智谱开放平台走的是用户权益体系，通过积分提升等级来获得并发权益。积分规则在官方的用户权益页写得很细，几条容易踩的：积分来自消耗现金余额和购买资源包，官方按固定比例把花费金额兑换成积分（比例以官方权益页为准）；赠金账户的余额消耗不换算成积分；发生退款时积分会对应扣减；如果参与了折扣活动，积分按折扣前的金额计算，避免因为打折导致等级下滑；Batch 推理则按实际扣费金额计算积分。等级更新机制也不是实时的——平台在次日固定时间更新积分，并按用户最近三个月的最高积分确定本月的权益等级。
这套规则的含义是：你薅赠金跑出来的用量，一分钱也换不成并发。很多团队在试用期用赠金压测，觉得并发够用，等到正式上线切成现金付费才发现等级还是最低档。
按月消费档位软限流。 阿里云百炼对部分模型采用动态限流，按平台的月消费档位调整。这是一种「用得多自动放宽」的模式，好处是不用申请，坏处是它随你的消费波动，不是一个可以写进容量规划表的固定值。
提工单，且不加钱。 DeepSeek 的文档写的是：若有更高的并发需求，可提交账号扩容申请工单，平台会根据实际业务需求匹配合适的并发量，扩容并不增加额外的费用。这在几家里是相当特别的一条——额度和花钱脱钩。
订阅套餐另算一套。 智谱的文档区分了通用 API 用户和 GLM Coding Plan 订阅用户：后者的并发与套餐等级相关，平台会根据资源动态调整，低峰期享有更高速率，且官方明确写了套餐用户按订阅等级统一并发、暂不支持申请调整。通用 API 用户则可以走控制台的速率限制调整申请，官方给出的审核周期是若干个工作日。
所以「怎么提额」这个问题在四家是四件事：充钱、攒积分、把月消费做上去、写工单。做选型时把这一条算进去——如果你的业务是脉冲式的（平时很低、活动期暴涨），按累计消费给额度的模式会很难受，能提工单预约扩容的模式反而更合适。
429 不都是同一个意思
这是排障时最费时间的地方。同一个 HTTP 状态码，背后可能是三种完全不同的原因。
智谱的文档把这件事拆得最清楚，它给了两个不同的业务错误码：
- 一个是「触发用户速率限制」：含义是你的账户已达到速率限制，典型原因是当前模型的并发请求数已达账户上限或短时间内请求过密。官方建议的处理方式是降低并发、增加请求队列或排队机制，必要时提升账户权益等级。
- 另一个是「平台服务过载」：含义是该模型当前访问量过大。官方明确说明这类情况属于平台服务过载，与单一账户的调用行为无直接关系，可能因为某模型整体访问量激增、底层算力高负载，或平台在维护扩容。建议的处理是稍后重试、增加重试间隔、在业务允许时降级或延迟处理。
这两者的区别是决定性的：第一种你改配置或提额能解决，第二种你把并发降到 1 也一样会遇到，只能靠退避、降级和多供应商兜底。把它们混为一谈，就会出现「已经把并发调到最低了还是报错」的困惑。智谱这边的具体排查步骤，站内有GLM API 429 限流一篇。
再加上前面提到的两种情况——Kimi 的风控限速一旦触发无法解除、聚合层的 429 可能来自上游而不是平台——排障的第一步应该是判断这个 429 属于哪一类，而不是直接改重试参数。
还有一把看不见的尺子：连接保活与超时
这条不在限流文档的标题里，但它会以「超时」的形式表现出来，实际影响一样大。
DeepSeek 的文档专门讲了请求保活机制：请求发出后可能需要等待一段时间才能拿到响应，这段时间里 HTTP 连接会保持，非流式请求持续返回空行，流式请求持续返回 SSE 的 keep-alive 注释。文档提醒这些内容不影响 JSON body 的解析，但如果你是自己解析 HTTP 响应的，就必须处理这些空行或注释。同一段里还给了一条硬规则：如果超过一段时间请求仍未开始推理，服务器将关闭连接。
这意味着在高并发排队的时候，你看到的可能不是 429，而是一个连接被关掉。把它当成网络故障去重试，只会让排队更长。
撞上限流之后的解法对照
| 你遇到的情况 | 常见根因 | 该做的事 |
|---|---|---|
| 单个请求就报 429 | 账户处在最低档，额度本身很窄 | 先跑通单条，再逐步加压；确认提额走的是哪条路 |
| 并发调低仍然报错 | 可能是平台级过载而非账户限制 | 看错误码细分，走退避与降级，别继续调参数 |
| 白天正常晚上集体失败 | 撞上日累计口径 | 检查是否有 TPD 类口径，把日用量摊平 |
| 多建了几个 Key 仍然不涨 | 额度按账号或主账号合并计算 | 别指望多 Key 分摊，走正规提额流程 |
| 长请求先挂、短请求正常 | 撞的是 token 口径不是请求数口径 | 按 token 而不是按请求数做并发规划 |
| 报错但状态码不是 429 | 可能是余额不足或无可用供应商 | 先分清 402、503 与 429 的语义 |
从峰值流量倒推容量的完整方法，见大模型 API 的并发怎么规划。
容量规划的正确顺序
把上面这些合起来，规划顺序应该是这样的：
- 先确认对方用哪几把尺子。 打开目标厂商的限速页，把并发、RPM、TPM、TPD 有哪几项列出来。没列的那几项不用管，列了的每一项都要单独估。
- 确认额度的计算粒度。 是按账号、按主账号合并、按模型独立，还是按调用方标识再切一刀。这决定了你能不能靠拆 Key、拆子账号绕过去（多数情况下不能）。
- 确认提额路径和周期。 是充值即生效、积分次日更新且看三个月最高值、按月消费自动调整，还是提工单等审核。提额有周期这件事必须提前算进上线排期，不能等到压测那天才发现要等几个工作日。
- 确认错误码的细分语义。 至少要能区分「我的问题」和「平台的问题」，重试策略才有意义。
- 最后才是写代码。 并发池、队列、指数退避、降级链路，按前四步的结论来配。
各家的模型定位与价格档位对照，可以配合国产大模型 API 价格对比一起看——限流额度和价格档位往往是绑在一起的，便宜的档位通常额度也更紧。
核实边界
- 本文依据 2026-08-24 的抓取，逐字核到正文的官方页面包括：DeepSeek 的限速与隔离文档、Kimi 开放平台的充值与限速文档和常见错误码文档、智谱开放平台的速率限制文档与用户权益文档、阿里云百炼的限流文档、OpenRouter 的 Limits 文档。
- 未核到的厂商：火山方舟（豆包）官方文档站为前端渲染，本次抓取只拿到导航骨架，正文未逐字核到，未纳入本文任何一条对比；OpenAI 官方文档站本次网络不可达，本文不包含 OpenAI 的限流口径。
- 本文没有写任何具体的并发数、RPM、TPM、TPD 数值和等级门槛金额。这些数值既随账户等级变化，也随平台策略调整——Kimi 官方就在限速页面挂出了规则将要更新的公告，阿里的动态限流本身就是浮动的。所有阈值一律改写为机制描述。
- 笔者没有上述任何厂商的付费账号，也没有做过压测，全文来自官方文档阅读，不含实测数据。