各家限流维度不一样：RPM、TPM、RPD 之外还有什么

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

如果你的重试逻辑只认「RPM 和 TPM」，那它在六家平台里至少有三家会失灵。 把智谱 GLM、xAI Grok、Kimi、Gemini API、MiniMax、阶跃星辰的官方限流文档摊开对着读，会看到一件挺反直觉的事：这些平台限的东西并不是同一批。有的平台文档里通篇只讲并发请求数，压根没给按分钟计的口径；有的把每秒请求数单列成一个维度；有的除了分钟还有天，还有的除了天还有周和以小时为周期的额度窗口；还有平台专门给「请求量骤增骤减」留了一个独立错误码。更关键的是，这些维度之间是「触发任意一个就限」的关系，而不是综合评估——写代码时把它当成 AND 来理解，就会持续低估被拦的概率。下面按维度、触发关系、归属主体、计入口径四层来对照。

先把维度名词摊开

先做一件很枯燥但很有用的事：把六家官方文档里出现过的限流口径名词列一遍。

• 并发请求数：智谱、Kimi、阶跃、MiniMax 都有这个口径。智谱的定义写得最直白——「同一时刻正在处理中的请求数量」；阶跃的说法是「同一时刻在线的推理请求数量」，并且明确超过并发限制的请求会被拒绝，除非旧的推理请求处理完毕，新请求才被允许进入模型推理。
• RPS（每秒请求数）：只有 xAI 的官方限流页把它列为正式维度之一。官方的解释是，每秒上限由每分钟的请求预算换算得出，这样你就没法把一整分钟的请求额度在一秒里花光，用途是防突发。
• RPM（每分钟请求数）：Kimi、阶跃、MiniMax、Gemini 都用。
• TPM（每分钟 token 数）：同上四家都有。但同一个缩写底下的口径并不一致：Gemini 侧的材料写的是「每分钟输入 token 数」，MiniMax 官方限流页写的是「每分钟输入+输出的 token 数限制」。这层差别后面单开一节讲。
• TPD（每日 token 数）：Kimi 的错误说明里有独立一条；Gemini 侧的事实材料写明「部分模型有 TPD」。
• RPD（每日请求数）：Gemini 侧列为三个基本维度之一。
• IPM（每分钟图片数）：Gemini 侧的额外维度，仅对可生成图片的模型计。
• CONN（最大并行运行任务数）：MiniMax 在视频与音乐这类异步生成接口上用的口径，和文本模型用的 RPM/TPM 不是一回事。

只看这张名词表就能得出第一个结论：拿「RPM/TPM 两件套」去套所有平台，一定会漏。

「瞬时」口径分两派

并发数和 RPS 听起来像一回事，其实限的东西不一样，写限速器的时候必须分清。

并发数限的是在途请求数——一个请求从发出到收完最后一个 token，这段时间它一直占着一个并发位。所以流式长输出会长时间占位，短请求则很快释放。阶跃的文档把这个机制说得很清楚：超出并发上限的请求会被拒绝，要等旧请求处理完才有新位置。这意味着你要控的是「同时在飞的请求数」，正确做法是信号量或并发池，而不是按时间间隔发请求。

RPS 限的是发起速率，跟请求处理多久无关。xAI 的异步用法文档里给的示例就是用 asyncio.Semaphore 配一个 max_concurrent 参数来控制并行请求数，同时提醒不能超过控制台上显示的限流。

智谱这边值得单独说：官方那篇《速率限制》通篇讲的是并发请求数，并且明确「不同模型设有独立的并发限制」——通用模型、图像/视频生成模型、向量模型、实时音视频模型各自一套。至于按分钟计的请求数或 token 数口径，这篇官方文档里没有找到相关说明。所以如果你在智谱侧照搬别家的 RPM 节流器，很可能限错了东西：你以为在控频率，实际卡你的是同时在跑的请求数。

分钟之外，还有天、周和小时窗口

日维度是第二层，容易被忽略，因为它平时不响，一响就是一整天缓不过来。

Gemini 侧的 RPD 有个很具体的细节：配额在太平洋时间午夜重置，不是本地时间，也不是 UTC。做日报类批处理任务排期时，这个时区差足以让你的窗口整体错位。Kimi 的 TPD 触发后，官方给的处置是「次日恢复或升级套餐」——注意这句话里没有「退避重试」，因为退避在日维度上没有意义。

再往上还有更长的窗口。智谱的 GLM Coding Plan 套餐用的是积分制，官方在用量说明里给出的是每 5 小时和每周两个额度上限同时存在：5 小时积分采用动态刷新机制，额度在请求消耗 5 小时之后刷新重置；周积分则自套餐下单时起，以 7 天为一个周期刷新（口径以官方文档当前版本为准）。这是一种和 RPM 完全不同的限制形态——它限的不是速率，是一段时间内的总消耗量，而且积分怎么扣还带系数：官方给的公式是输入 token、缓存命中 token、输出 token 分别乘各自的抵扣系数再相加换算，MCP 调用则按调用次数乘 Output 抵扣系数计。官方还说明高阶模型在高峰时段按更高的系数消耗额度，周末全天按非高峰时段抵扣（具体系数与时段以官方页面为准）。需要注意的是，这里的「动态刷新」按官方原文是「额度在请求消耗 5 小时后刷新重置」，它以你实际发生消耗的时刻起算，而不是按自然时钟对齐的整点分桶——排期时别默认它每天固定在几点归零。

真正意义上按滑动窗口评估的例子在 Gemini 侧：除 RPM/TPM 之外，材料里还写了一层基于支出的速率限制，按 10 分钟滚动窗口评估，是否适用取决于结算记录与账号状态，触发时返回 429 RESOURCE_EXHAUSTED。官方给的处置有三条：等待后重试；降低高费用请求的速率，办法是用更小的上下文窗口或更短的输出；如果持续触发，就走申请提高限流的路径。把这一层和前面几层放一起看会发现，窗口长度从秒、分钟一路排到小时、天、周，每一层的应对动作都不一样——秒和分钟这两层靠限速器和退避就能扛住，小时以上的窗口一旦打满，就只能等重置或者换额度来源了。

触发关系是「或」，不是「与」

这一条几家官方文档都用明文单独强调过，所以这里也单独拎出来。

阶跃的基础概念页给了明文：「速率限制可能会在以上任何一种选项中达到，具体取决于哪种限制先被触发。」它还举了个例子——RPM 先到上限，即使 TPM 还有余量，一样会触发限速。Gemini 侧的材料同样写着「超出任何一个维度即触发限流错误，不是综合评估」。xAI 的限流页也是同一个说法：超出任一限制返回 429 Too Many Requests。

所以正确的心智模型是：每个维度都是一道独立闸门，任意一道触顶就拦，不需要几道同时超。 这条会直接影响你怎么优化。MiniMax 的官方建议就是从这个前提出来的：既然 RPM 和 TPM 是分开计的，那么当每分钟请求数已经打满、而 token 数还有余量时，可以把多个任务合并到单个请求里，从而提高 token 吞吐。反过来如果卡的是 TPM，合并请求就毫无帮助，那时要动的是上下文长度。

限流挂在哪个主体上

同样的数字，挂在不同主体上，结果完全不同。这一层直接决定了「多开几个 Key」这类做法能不能扩容。

• 按项目：Gemini 侧的材料明确写「限流按项目（project）应用，不是按 API 密钥应用」，多个 Key 并不能绕开限流。同时，层级、限流、账号上限都在结算账号级别确定，项目从一个结算账号换到另一个，层级与限流会随新结算账号变化。
• 按组织：Kimi 的错误说明里，触发并发、RPM、TPM、TPD 的四条限流全部标注为「组织级」。
• 按主账号 + 子账号合并：MiniMax 的官方说明是主账号和子账号共同享有同一套速率限制，消耗共享、统一结算——子账号只是权限隔离，不是配额隔离。
• 按账户：智谱在高峰期对超出并发上限的请求「基于账户维度」限流。
• 按团队：xAI 的限流是每个 API team 的每模型限流，层级也是团队维度的。

结论很实际：开子账号、多建 Key，在这几家平台都不能用来扩容限流。真要扩，走的是各家自己的提额路径——智谱的通用 API 用户在控制台提交速率限制调整申请（需要填模型、期望并发量、业务场景），而 GLM Coding Plan 用户按订阅套餐等级统一并发，官方写明暂不支持申请调整；阶跃与 MiniMax 都是联系官方邮箱申请；xAI 除了随累计消费自动升层，也可以在控制台提交提额申请，企业容量走销售。

哪些 token 算进 TPM

TPM 的预算特别容易估偏，因为「哪些 token 算数」各家口径不同，而且和计费口径不一定一致。

xAI 的限流页把这一格写得最细：计入该模型 TPM 的包括提示词 token（文本、图像、音频）、补全 token、推理模型的 reasoning token，以及缓存命中的提示词 token——官方特别注明，缓存命中的 token 虽然按更低的费率计费，但仍然计入 TPM。这一条对做长上下文 + 高缓存命中的应用是个直接打击：你以为缓存把成本压下来了，限流那一侧并没有跟着松。

更值得注意的是，另外两家在「输入还是输入加输出」这件事上给了方向相反的口径，而且都是明文：MiniMax 的官方限流页在资源详情一节里把 TPM 定义为「每分钟输入+输出的 token 数限制」，输出也计入；Gemini 侧的材料把三个基本维度中的 TPM 写成「每分钟输入 token 数」，字面上只框住了输入。这一正一反的差别会直接改变你的预算算法：按 MiniMax 的口径，一次长输出请求真正占掉的额度要把响应也算进去，只按提示词长度做预扣就会算少；按 Gemini 材料的字面口径，控制输入侧的上下文长度就已经覆盖了这个维度的主要变量。至于响应写完之前平台是怎么记账的，官方文档里没有找到相关说明，所以预扣时按整请求的输入加输出上限来留余量最保险。

剩下两家的定义则偏笼统。阶跃只说 TPM 衡量的是一分钟内可传输的 token 数量，Token 通常指请求以及响应中的数据单位——按字面读是包含响应的，但官方没有像 MiniMax 那样用加号写死；Kimi 的定义是一分钟内最多和平台交互的 token 数，同样没有拆开说明。至于缓存命中 token、推理 token 在这两家是否单独计入 TPM，官方文档里没有找到明确说明。工程上稳妥的做法是按最保守的那一版口径去做预算，也就是默认输出 token、推理 token、缓存命中 token 都占额度，而不是默认它们不算。

订阅套餐是另一套规则，两家给了相反的答案

按量付费和订阅套餐的限流规则往往不共享，而智谱和阶跃在这件事上的选择正好相反，很值得对照着看。

阶跃的 Step Plan 在官方 FAQ 里被明确问到「会受到充值阶梯限速（RPM / TPM）的约束吗」，回答是不会：Step Plan 不适用开放平台按累计充值金额划分的阶梯限速，用量由所订阅档位的月度 Credit 额度管理。官方特性里还写着「月内任意时段消耗，不受时段或请求频次限制」。也就是说订阅之后，速率维度被整个拿掉了，只剩月度总量这一个闸门。

智谱的 GLM Coding Plan 是另一条路：并发限制不但存在，而且与套餐等级相关，官方给的基本原则是 Max > Pro > Lite，还会由平台根据资源动态调整、低峰期享有更高并发。再叠加前面说的 5 小时与每周双积分窗口，订阅用户实际同时受两类闸门约束。想细看这套积分规则怎么算，可以读 GLM Coding Plan 用量规则。

选型时这个差别很实在：如果你的负载是脉冲式的（比如一天里集中几个小时跑批），阶跃这种「只限总量不限时段」的形态更友好；如果是长期稳定的低速调用，双窗口形态并不构成困扰。

长得像限流、其实不是限流的几种 429

最后一节讲排查。收到 429 就无脑退避重试，在好几家平台上都会白白浪费时间，因为同一个状态码底下塞了不同性质的错误。

• 平台侧过载：智谱的错误码 1305 是「平台服务过载」，官方明确说明这属于平台级保护机制，与单一账户的调用行为无直接关系，处置是稍后重试、增加重试间隔。Kimi 的 engine_overloaded_error 说得更狠——该错误由服务端容量导致，充值或提升 Tier 不能直接消除，要按 Retry-After 提示等待并降低并发。
• 余额或额度不足：Kimi 的 exceeded_current_quota_error 覆盖了账户欠费停用与 token 额度不足两种情况，退避多少次都没用。MiniMax 的余额不足是独立错误码，和限流码分开。
• 日配额耗尽 vs 分钟级限流：Gemini 侧把这两件事拆成了两个不同的错误码，一个是分钟/秒级的速率超限（退避重试有效），一个是每日配额超限（只能等重置或提额）。这一层区分站内单独写过，见 Gemini 的两种 429。
• 风控限速：Kimi 的官方页面写着，当系统检测到账户存在异常行为时会触发风控限速策略，该限制一旦触发即无法解除。智谱那边也有对应表述：违反使用规范可能触发风控，被限流甚至冻结，命中风控策略后可在控制台查看提示并发起申诉。这类限制不属于容量问题，重试逻辑救不了。
• 爬坡过快：MiniMax 有一个很少见的独立错误码，含义是「请求频率增长超限」，官方给的处置是避免请求骤增骤减。这说明被限的不只是绝对速率，还有速率的变化率。它和另一个含义为「请求频率超限」的错误码是分开的两条，前者对应的是升速姿势不对，后者才是绝对量超了——排查时先看拿到的是哪一个，再决定是整体降速还是把并发爬坡改平缓。同一张错误码表里，「连接数限制」也是独立的一条，官方给的处置是联系平台，不是自己退避重试。

落到代码里怎么办

把上面几层归拢成一份可执行的做法：

第一步，先分类再决定动作。收到限流响应时不要只看 HTTP 状态码，一定要读错误体里的类型字段或业务错误码，区分出「速率维度触顶」「日/周配额耗尽」「服务端过载」「余额不足」「风控」五类。只有第一类和第三类适合指数退避，第二类要等窗口重置，后两类必须直接停下来报警。站内的 429 通用处理 讲的是这套骨架，本文补的是各平台的具体形态差异。

第二步，按维度选限速器。卡并发就用信号量或并发池，卡 RPM/RPS 就用令牌桶，卡 TPM 要在发送前估算本次请求的 token 数并从预算里扣，卡日/周额度则要在应用层记账。智谱官方的建议也是这个方向：使用请求队列或并发池，避免瞬时洪峰式请求，同时避免固定间隔的高频重试。

第三步，把非实时流量挪走。这是所有平台都认的降压手段。智谱明确建议非实时场景走批处理或异步请求来降低并发压力；xAI 的批量接口文档里写得更直接——批量请求不计入速率限制，代价是要接受异步取回结果的形态。Gemini 侧的批量限流也完全独立于非批量调用，但它另有一组约束要管：并发作业数、输入文件大小、文件存储总量、每模型排队 token 数。

最后一个提醒，也是官方自己说的：Gemini 的文档里有一句免责原话，大意是指定的速率限制无法保证、实际容量可能有所变化；Kimi 写的是当集群负载达到容量上限时可能采取临时的限流措施，阶跃的措辞则是当资源达到容量上限时可能采取临时的限流措施、对各类限速进行调整——两家指向的是同一件事：控制台上那个数字并不是平台对你的承诺。所以把限流当成一个会浮动的软约束来设计，而不是一条你可以精确贴着跑的硬线——留出余量、把失败当常态处理，比把控制台上那个数字抄进配置文件要靠谱得多。想看单个平台的响应头字段与具体排查动作，可以从 API 限流 RPM 与 TPM 机制 这篇通用机制往下走。