RPM 和 TPM 是什么？限流额度怎么估、并发怎么配
大模型 API 的限流通常有两把尺子：RPM（每分钟请求数）和 TPM（每分钟 token 数）。短请求先撞 RPM，长请求先撞 TPM。只按 RPM 设并发的系统，一遇到长文档就会集中报错。
这篇讲怎么估自己的额度需求、并发怎么配。想量清楚自己的请求有多大，用 token 计算器。
两把尺子分别限什么
RPM 限的是次数。 不管请求大小，一分钟最多发多少个。高频短调用的场景（比如每次几百 token 的分类任务）通常先撞它。
TPM 限的是吞吐量。 一分钟内累计处理多少 token，通常输入输出合并计（也有分开计的，看厂商说明）。长文档、长上下文、长输出的场景先撞它。
两者是「与」的关系：任何一个到顶都会被拒。所以判断自己会先撞哪个，只需要算一下：
你的单请求平均 token 数 × RPM 上限，如果这个数大于 TPM 上限，那你实际受限于 TPM，RPM 那个数字是虚的——你根本发不到那么多次就先被 TPM 拦下了。
举例说明这个关系：假设某档给你 RPM 60、TPM 十万。如果你的单请求是 500 token，60 次也才三万 token，RPM 是瓶颈；如果单请求是 5000 token，只发 20 次就到十万了，TPM 才是真正的天花板。
并发数怎么算
很多人把并发数直接设成 RPM 的数值，这是不对的——并发和速率是两个概念。
粗略换算：并发数 ≈ RPM ÷ 60 × 单请求平均耗时（秒）
比如 RPM 60、单请求平均耗时 3 秒，那么稳态并发大约是 3。设成 60 的话，前几秒就把一分钟的额度打光，然后剩下的时间全在吃 429。
如果受限于 TPM，同理换算：并发数 ≈ TPM ÷ 60 ÷ 单请求平均 token × 单请求平均耗时
实际配置时在算出来的数上留两三成余量，因为耗时是波动的。
被限流之后该怎么做
第一，读响应头。 多数厂商会在 429 响应里返回建议等待时间或剩余额度。有这个信息就别自己猜，按它退避。
第二，指数退避加抖动。 固定间隔重试会让所有被拒的请求在同一时刻再次涌上去，形成同步震荡。加随机抖动能把它们打散。
第三，设最大重试次数和总超时。 无限重试会让一次故障演变成一条队列的雪崩，而且每次重试都在花钱。
第四，区分错误类型。 429（限流）和 5xx（服务端临时错误）值得重试；4xx 里的参数错误、鉴权错误重试多少次都是浪费。具体做法见站内的 API 重试与退避。
第五，做客户端限速。 与其等服务端拒绝再退避，不如自己在客户端就把速率压在额度以内。令牌桶是最常见的实现，比事后重试优雅得多，也更省钱——被拒的请求不产生有效输出，但重试是要钱的。
额度不够时的三条路
一是提额。 多数厂商支持按用量或按申请提升档位。这是最直接的，但通常需要付费历史或走商务流程，有周期。
二是降需求。 缩短输入（TPM 压力直接下降）、合并请求（多个小任务打包成一次调用，RPM 压力下降）、把不紧急的活挪到批处理接口（很多厂商的 Batch 有独立额度，不占实时额度）。
三是分散。 多家并用，把流量按权重分配。这不只是为了额度，也是可用性保险——某家出问题时不至于全线停摆。做法见多家 API 统一封装。
客户端限速怎么实现
比起被拒后再退避，主动把速率压在额度内要优雅得多。最常用的是令牌桶。
思路：维护一个桶，按固定速率往里放令牌（比如每秒放 RPM ÷ 60 个），每发一个请求消耗一个令牌；桶空了就等。桶的容量决定了能容忍多大的瞬时突发。
要点一：RPM 和 TPM 各需要一个桶。 前者按请求数消耗，后者按预估 token 数消耗。发请求前两个桶都要拿到令牌才放行。TPM 桶的消耗量需要预估——用输入 token 数加上 max_tokens 作为上界比较稳妥。
要点二：多实例要考虑全局协调。 每个进程各跑一个本地桶的话，实际总速率是进程数的倍数，照样会超。要么把额度按进程数均分（简单但浪费），要么用共享存储做分布式限速（准确但复杂）。中小规模建议先用均分，够用就别上复杂方案。
要点三：留出重试的余量。 限速阈值别设成额度的百分之百，留一点给重试和突发，通常设到八九成比较安全。
额度的三种典型分配错误
错误一：所有业务共用一把密钥。 一个跑飞的离线脚本能把线上服务的额度吃光。按业务线拆密钥是成本最低的隔离手段，顺带还能做用量归因。
错误二：按人头分配额度。 开发阶段还行，上线后完全失真——生产流量和开发者人数无关。应该按功能/接口分配，见团队 API 预算怎么排。
错误三：只按日均申请额度。 流量集中的业务，峰值可能是日均的数倍。按日均申请的档位在峰值时段会被打爆，然后退化成大量重试——体验差，钱还多花。
容量规划的两个数
做容量规划时，别只看日均，要分开算两个数：
日均决定你的预算，峰值决定你的额度档位。如果流量集中在几个小时，按日均申请的额度会在峰值时段被打爆，然后退化成大量重试——用户体验差，钱还多花。
峰值估算的实用做法：取历史流量的分钟级峰值（不是小时平均），再乘以增长系数。如果还没有线上数据，按业务场景推：面向消费者的产品通常晚间是峰值，面向企业的通常工作日上午。
把这两个数和成本一起放进月成本估算器，就能同时回答「够不够用」和「多少钱」。
三个高频问题
问：额度是按账号还是按密钥算的？ 各家不同，有的账号级共享、有的密钥级独立。这直接影响你能不能靠多发几把密钥扩容——多数情况下不能。以厂商文档为准。
问：为什么请求数明明没超，还是被限流？ 十有八九撞的是 TPM 而不是 RPM。长请求几次就能把 token 额度打满。
问：批处理占用实时额度吗？ 多数厂商的批处理有独立额度，这也是把离线任务挪过去的额外好处之一。
一句话记住
额度不是性能指标，是约束条件。规划的正确方向是从业务峰值倒推所需速率，再倒推并发与额度档位，而不是先把并发开到最大再看能跑多快。前者得到的是一个稳定可预期的系统，后者得到的是一台反复撞墙的机器——而每一次撞墙的重试，都是实打实的账单。
接着往下看
额度算清楚之后，配套要做的是并发规划与限流处理：并发数怎么从峰值倒推、压测该怎么设计，见大模型 API 的并发怎么规划；真被限流之后怎么退避、怎么给用户合理的反馈，见 API 报 429 怎么办。想把额度和成本一起排进预算表，用月成本估算器。