大模型API限流对比要看哪些规则和配额
限流对比先分清限制维度
大模型API限流对比的核心不是比谁的数字大，而是看限制落在哪个维度上。
常见的有三种：每分钟请求数（RPM）、每分钟token数（TPM）和并发连接数。
有的平台只公布RPM，但实际先卡住你的是TPM；
有的平台RPM宽松，却在并发上收紧。
只看一个数字，很容易在业务高峰期才发现请求被拒。
判断条件很简单：如果你的请求短而多，RPM是瓶颈；
如果单次输入长或输出长，TPM往往先到顶；
如果同时发起大量流式请求，并发限制和排队策略更关键。 对比前先统计自己业务的平均输入token、输出token、峰值请求数和峰值持续时间，再去看各家限制能否覆盖。
对比时容易忽略的四个差异
第一是配额周期。
多数平台按分钟滚动或按分钟窗口重置，但重置方式会影响突发流量的表现，有的允许短时间内打满，有的平滑削峰。
第二是超限返回方式，通常是HTTP 429，但响应头里是否带剩余配额、重置时间、建议重试间隔，各家不一致，这直接决定客户端退避策略怎么写。
第三是限流粒度。
限制可能按账号、按API Key、按模型分别计算，同一账号下多个Key共享还是独立配额，需要看文档或实测确认。
第四是模型差异，同一平台不同模型的TPM可能不同，拿旗舰模型的额度去推断轻量模型不成立。
对比时建议做一张表，列为：限制维度、数值、计算粒度、重置周期、超限状态码、是否返回重试提示。
空着的格子就是需要实测或查文档的部分，不要用推测填满。
用同一脚本测出真实限流行为
准备一个能发请求的脚本，固定模型、输入长度和并发数，只改变请求速率，观察从正常到429的临界点。
下面是一个最小验证思路，用curl看响应头和状态码，不依赖特定SDK：
for i in $(seq 1 30); do
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"你的模型名","messages":[{"role":"user","content":"测试"}],"max_tokens":16}' \
https://你的接口地址/v1/chat/completions
done把返回的429数量、首次出现的位置和响应头里的配额字段记下来。
再用更长输入重复一次，对比TPM是否更早触发。
测试时控制变量：同一网络、同一时间段、同一参数，避免把网络波动误判为限流。
客户端该怎么配合限流规则
限流对比的结论最终要落到代码里。
如果平台返回重置时间，退避就按它来；
如果没有，就用指数退避加随机抖动，并设置最大重试次数，避免重试风暴把配额打得更空。
流式请求被限流时，要区分是连接建立阶段被拒还是传输中中断，前者可直接重试，后者要检查已输出内容是否可续。
实际部署中，建议在网关或应用层做令牌桶限速，把并发控制在配额以内，并记录每次429的时间、模型和请求特征。
这样对比不同平台时，你拿到的是自己业务下的真实触发点，而不是文档上的理论值。
结论怎么用
限流对比适合回答“我的调用结构会不会被卡住”，不适合直接推出“哪家更好”。
短请求密集型业务重点看RPM和并发，长文本业务重点看TPM和输入输出是否分别计费，对稳定性要求高的业务还要看超限后的返回是否可预期。
把这几项按同一条件测一遍，再结合成本一起判断，结论才站得住。
