限流才是看不见的那半张账单
选模型时大家盯着单价，但真正让人卡住的常常是另一件事：便宜的那家抢不到、买了套餐几轮对话就打满、免费额度看着大却被每分钟请求数锁死。这些都不出现在价目表上，却实实在在决定你能不能用。
麻烦在于各家的限流根本没法直接比，计量单位都不一样。这篇不给「谁家限制最松」的排名，因为那种排名在口径不统一的前提下是假的。讲的是怎么看懂各家在说什么，以及几个被广泛误解的点。
第一件事：各家量的东西不是同一个
同样叫「限流」，各家的计量维度差别很大。
| 计量方式 | 含义 | 谁在用 |
|---|---|---|
| RPM / TPM / RPD | 每分钟请求数 / 每分钟 token 数 / 每天请求数，三条线任一超了都拦 | Gemini、OpenAI 等海外 API |
| 并发数 | 同时在途的请求数上限，与请求频率无关 | DeepSeek 官方 API |
| 时间窗口配额 | 如「每 5 小时可用量」「每周限额」，用完等重置 | 各家 Coding Plan、订阅制 |
| 相对倍数 | 如「1x / 4x / 20x 额度」「Pro 的 5 倍用量」，无绝对值 | Kimi、Claude、ChatGPT 等订阅 |
并发数和 RPM 是两回事，混淆了会选错
DeepSeek 官方文档给的是并发限制：V4 Pro 500、V4 Flash 2500。它对这个数字的定义写得很清楚：「一个请求从发出到模型响应完成，算作一个并发连接。」
这跟 RPM 的约束方式完全不同。如果你的请求平均耗时 10 秒，500 并发理论上能撑到每分钟 3000 次请求；但如果你跑的是长文本任务、单次要 60 秒，同样 500 并发每分钟只能完成 500 次。并发限制惩罚的是慢请求，RPM 限制惩罚的是高频请求，你的负载形态决定哪个先卡住你。
Gemini 那边则是三条线并行：RPM、TPM、RPD 任意一条超了都会返回 429，官方原文是「即使你没超 TPM，只要 RPM 超了照样报错」。做长文本的容易先撞 TPM，做高频小请求的容易先撞 RPM。
一个被广泛误解的点：多开 API key 绕不过去
社区里常见的做法是申请多个 API key 来「分摊」限流。至少在 DeepSeek 这里这样做没有用，官方写得很直接：「并发限制按账户计算，与使用哪个 API Key 无关。」
Gemini 的口径类似，官方明示限流「按项目计算，不是按 API key」。所以真正的解法是走官方扩容通道。DeepSeek 明确说扩容不额外收费，可以按实际业务需求申请。
顺带一提，Gemini 还有一层基于消费额的分层：账户累计消费达到相应门槛后才升到下一档限流。也就是说新账号的限流紧不是故障，是设计。具体门槛以官方限流文档当时公布的为准。
订阅制的限流最不透明，而这正是投诉集中的地方
按量 API 至少会给出 RPM 或并发这样的绝对数字，订阅制普遍只给相对倍数：Kimi 的 Code 额度分 1x / 4x / 20x / 60x，Claude 的 Max 档写「Pro 的 5 倍 / 20 倍用量」，ChatGPT Pro 写「约 5 倍 / 20 倍 Plus 配额」。相对于什么，那个基准是多少，都没有公开数字。
结果就是买之前算不出来。中文社区今年反复出现同一类反馈：某家 Coding Plan 的低价档「随便问几个问题就打满」，某个 9.9 元体验套餐「一轮完整提问消耗 20% 额度」，某家高价档「一轮对话没结束就限额」。这些都是用户买了之后才知道的。
已经有人为此走了消费者投诉渠道，理由是额度不透明侵犯知情权。抛开结果不论，这件事说明一个问题：当限额只能靠买了之后实测才知道，定价信息其实是不完整的。
免费额度的真实约束往往不是额度
免费档最常见的误解是只看总量。实际上多数免费方案是「双重限流」：每分钟请求数 + 每日请求数同时约束，总量再大也架不住每分钟只能发几次。
还有一层是条款约束。有些消费级订阅的服务条款并不覆盖自动化基准测试、批量脚本、共享账号这类用法——技术上跑得通，条款上不允许，账号有可能因此受限。这条在学术和评测场景里尤其容易踩。
所以该怎么做
限流这件事没法一劳永逸地查一张表解决，因为各家口径不同、还会随时调整。几条实操建议：
- 先弄清自己的负载形态：高频小请求看 RPM，长文本看 TPM 或并发数，两者的瓶颈完全不同。
- 上线前用真实负载压一遍，别信标称值。特别是订阅制，只给相对倍数的那种，唯一可靠的方式就是实测。
- 别靠多开 key 绕限流，主流厂商都是按账户或按项目计算。要更高配额就走官方扩容，DeepSeek 这类明确说扩容不加钱。
- 把 429 的重试逻辑当基础设施做，指数退避加抖动。限流不是异常，是常态。
- 评估「便宜」的时候，把抢不到、要排队、要降级重试的成本算进去。标称单价低但每天只能跑三分之一的量，实际单位成本并不低。
为什么本站没做一张「各家限流对照表」
我们认真评估过做这个页面，最后放弃了，原因值得说清楚。
第一，数据源一半抓不到：OpenAI 的限流文档反爬，Anthropic 的文档对部分地区不可访问，各家页面结构还都是客户端渲染的。做出来只能靠人工维护。
第二，口径不统一，硬拼成一张表就要替厂商做归一化：把并发数和 RPM 换算成同一个单位，而这个换算依据是我们自己发明的，不是厂商的官方说法。那就违背了本站只记录可核实事实的原则。
第三也是最实际的：一个需要人工维护的表格必然会过期。本站已经吃过这个亏，价格数据能每天自动核对所以是可靠的，靠人工抄的那些最后都停更了。与其做一张几个月后就不准的表，不如写清楚判断方法。
常见问题
429 报错了，是我请求太快还是额度用完了？
都有可能，得看具体维度。Gemini 的 RPM、TPM、RPD 三条线任意一条超了都返回 429；DeepSeek 那边是并发数超了排队。先看错误响应里的具体说明，再对照你的负载形态判断是频率问题还是总量问题。
多申请几个 API key 能提高配额吗？
主流厂商都不行。DeepSeek 官方明示并发限制按账户计算、与用哪个 key 无关；Gemini 的限流按项目计算而非按 key。要更高配额走官方扩容申请，DeepSeek 明确说扩容不额外收费。
并发数 500 相当于每分钟多少请求？
取决于单次请求耗时，没有固定换算。请求平均 10 秒完成，500 并发理论上支持每分钟约 3000 次；单次要 60 秒的话每分钟只能完成 500 次。并发限制对慢请求更不友好。
订阅套餐的额度怎么算清楚？
算不清楚，因为主流订阅只公布相对倍数（1x/5x/20x）而不公布绝对值。唯一可靠的办法是先买最低档实测一段时间，再决定要不要升。这也是中文社区对订阅限额透明度投诉集中的原因。
为什么新账号的限流特别紧？
这是设计不是故障。Gemini 有基于累计消费额的分层机制，达到相应门槛才升到下一档限流。多数厂商都有类似的信用积累逻辑，新账号先给保守配额，具体门槛看官方文档。
文中价格与价格表同源、每日核对。选型前去看一眼最新价。
打开价格表 →