DOCAI · 概念 · L3
吞吐量和限流是什么关系
一句话定义
吞吐量是实际处理速度，限流是服务允许的上限；RPM 管请求条数，TPM 管 token 总量。
专业更新 2026-11-13核验 2026-11-13 · docai 编辑部
两个配额，管的是不同东西
多数 API 同时限两个维度：
| 配额 | 含义 | 卡住时的表现 |
|---|---|---|
| RPM（每分钟请求数） | 一分钟能发多少条 | 请求被拒，返回限流错误 |
| TPM（每分钟 token 数） | 一分钟能吞吐多少 token | 短请求没事，长请求集中时被拒 |
TPM 是更容易被忽略的那个：一次带 5 万字资料的请求，可能一条就吃掉大半配额。 这也是「明明 RPM 没超，却一直 429」的常见原因。
吞吐 ≠ 延迟
- 延迟：一条请求从发出到拿到首字/全部结果要多久。
- 吞吐：一段时间内能完成多少条。
两者可以独立变化：加并发能提高吞吐，但延迟可能变差；用更快的模型能降延迟， 但价格和配额另算。
做容量规划时先问：峰值时每分钟要发多少条、每条平均多少 token。 两个数相乘，才能对上 TPM。
提高吞吐的四种办法
- 降低单条 token：裁剪上下文、用缓存命中、把长材料换成检索结果。
- 把离线任务挪走：用批量接口，不占实时配额。
- 加并发 + 退避重试：并发不是越高越好，要配合指数退避，否则重试风暴会吃掉配额。
- 申请提额或买专用吞吐：部分云厂商提供预留吞吐，价格更高但稳定。
顺序建议从上往下：前两条是省钱的办法，后两条是花钱的办法。
常见误解
- 「限流是服务器坏了」：429 是配额机制在工作，不是故障。
- 「并发越高吞吐越高」：超过配额后，多出来的并发只会变成失败和重试。
- 「TPM 按请求数折算」：不是，长请求和短请求占的 token 差很多。