API 配额怎么规划：按峰值还是按均值
数据截至 2026-07，价格与限额以各官网为准。
配额规划从来不是”按峰值还是按均值”的单选题——钱按均值估，速率按峰值留，这是两条互不通约的线。把它们混在一张表里算，结果一定是预算看着够用、真到流量涌上来还是被挡在门外。
一个很常见的误解是：把平台上那个”额度”理解成一个总量池子，觉得只要余额充足，请求想怎么发就怎么发。实际上绝大多数 LLM 平台都同时在两个维度上限制你：一个是你账户里还剩多少钱，另一个是单位时间内允许你通过多少次请求、多少 token。前者耗尽表现为扣款失败，后者触顶表现为 HTTP 429。余额还剩很多但请求被限流，这在生产环境里是天天发生的事。
先把两种配额分开写在两张纸上
第一种是金额配额：你充了多少、还剩多少、每天在以什么速度往下掉。它是累积量，跟时间粒度无关，本质上就是月度成本预算。
第二种是速率配额：每分钟能发多少请求、每分钟能吃进多少输入 token、能吐出多少输出 token。它是流量的瞬时上限，跟你余额多少基本没关系。
这两件事的规划方法是相反的。金额配额如果按峰值去准备，你会长期把大笔现金压在一个用不完的余额里；速率配额如果按均值去准备，你会在每天流量最集中的那几分钟里被反复挡回来，而且那几分钟通常正好是你最不希望出问题的时候。
以 OpenRouter 这类预充值 credits 的平台为例，它的两条线是可以直接看见的。金额侧是充值余额按实际消耗扣减，官方文档明确说明不在模型调用价上加价，模型的每百万 token 单价就是提供方官网上的价格；速率侧则是另一套规则，比如免费模型档，官方页面写明未购买过 credits 的账户是每天 50 次、每分钟 20 次，账户历史充值达到 10 美元后每天放宽到 1000 次，但每分钟 20 次这条限制仍然在。注意最后半句：日配额翻了很多倍，分钟级的闸门却没动。这就是”钱多不等于能发得快”最直白的例子。
金额那条线：按均值估，但要认得住月内的形状
金额预算按均值估是合理的，因为跨天的高低会互相抵消。可操作的做法是这样几步：
先取一段真实运行数据，比如最近 30 天，算出每天的实际消耗，不要用”预计每天多少次请求 × 单价”这种纸面推算——纸面推算几乎总是偏低，因为它漏掉了重试、失败后的补偿调用、以及超出预期的上下文长度。
然后看这 30 天的分布形状。如果是内部工具，工作日和周末通常差得很明显，用工作日的均值乘以当月工作日天数会比整月均值靠谱。如果是面向用户的产品，要留意有没有明确的月内周期，比如月初结算、月末冲量。
再叠加增长趋势。用户量在涨的话，下个月的预算不能等于上个月的实际消耗，需要按最近几周的环比斜率外推一段。
最后才是留余量。金额侧的余量不需要很大，因为它可以随时补，真正需要谨慎的是充值本身带的摩擦。OpenRouter 的信用卡充值官方 FAQ 写的是 5.5% 手续费、最低 0.80 美元，加密货币充值 5% 且无最低限制。最低收费这一条决定了小额高频充值很不划算；同时官方 FAQ 也保留了”购买后满一年未使用可能清零”的权利，这又决定了一次性充太多同样有代价。这两条一夹，充值节奏就有了一个合理区间——按月或按季度的消耗量充，而不是按天充，也不是把一年的量一次压进去。这部分的细账在 OpenRouter 额度怎么管才不超支 里拆得更细，这里不重复。
速率那条线：必须按峰值留，而且峰值不是日均除出来的
速率配额规划里最致命的一个动作，是拿”每天 100 万次请求”除以 86400 秒得到”每秒 11.6 次”，然后按这个数去申请配额。真实流量从来不是均匀铺开的。
更接近现实的做法是直接去看分钟级的分布：
第一，用最忙那一分钟，而不是平均那一分钟。 把历史请求日志按分钟聚合，排序后取靠上的分位数（比如 P95、P99），而不是取平均。对大多数有人参与的业务，最忙一分钟和平均一分钟的差距通常很显著，具体倍数要以你自己的日志为准。
第二，把重试算进峰值里。 限流触发后如果你的客户端自动重试，重试请求本身也会占用速率配额。一次限流引发一轮重试、重试又撞上限流，这种自我放大是线上事故里非常典型的一类。规划峰值时要把重试系数算进去，同时在客户端加指数退避和抖动，别让所有失败请求在同一秒集体回头。
第三，分开算输入和输出。 很多平台的速率限制不只看请求数，还分别限制每分钟的输入 token 和输出 token。一个平均输入 3000 token 的场景和一个平均输入 30000 token 的场景，即便请求数完全一样，对配额的压力也完全不同。如果你的业务里有长文档分析这类重输入的路径，它会先撞到 token 维度的墙，而不是请求数的墙。
第四，把批量任务和在线请求分开。 夜间跑的批量处理、定时的数据清洗，这类任务和用户实时请求共用同一把 key 时，会在你毫无预期的时刻把速率配额吃满。可行的做法是给它们单独的 key、单独的并发上限，甚至错开时段跑。
输入贵还是输出贵，会改变你的峰值预算
规划峰值时容易忽略一点：输入和输出的单价通常是不对称的，而且输出往往贵得多。
从 OpenRouter 官方模型页可以看到几个代表性数字（截至 2026-07）：GPT-5.5 是每百万 token 输入 5 美元、输出 30 美元；Claude Opus 4.7 是输入 5 美元、输出 25 美元；Gemini 2.5 Pro 是输入 1.25 美元、输出 10 美元。三个模型的共同点是输出单价明显高于输入单价。
这意味着什么？意味着如果你的峰值场景恰好是”输出很长”的那一类——比如批量生成文案、长篇代码补全、大段翻译——那么峰值时段的每分钟成本会比你按输入量线性外推出来的高不少。反过来，如果峰值场景是”输入很长、输出很短”的检索式问答或分类任务，成本曲线会平缓很多。
所以峰值预算不能只算”峰值请求数 × 平均单次成本”。更稳妥的做法是把业务路径分类，对每一类分别估计典型的输入 token 和输出 token 数，再乘以对应模型的两个单价，最后按各路径在峰值时段的占比加权。这个表算一次能用很久，比拍一个总数靠谱得多。至于怎么把 token 消耗量测准，可以参考 token 统计怎么做 里的记账方法。
余量应该留在哪一层
留余量不是简单地”多申请一点”，而是要想清楚超限之后发生什么。
一种思路是留在平台侧：申请更高的速率档位，让墙本身更远。这条路最直接，但受制于平台的分级规则，很多平台的档位是按历史用量自动升的，短期内你想快也快不了。
另一种是留在架构侧：准备一条降级路径。OpenRouter 官方 FAQ 描述了它自身的自动 fallback 机制——某个提供商报错或不可用时会自动切到下一个可用提供商，官方称这个过程对用户是透明的，并且对失败请求不计费（官方称之为 Zero Completion Insurance，只按成功请求计费）。这类平台侧的容错能降低单个提供商抖动的影响，但它解决的是”提供商挂了”，不解决”你自己的速率配额用完了”。后者需要你在应用层准备方案，比如把非实时的请求转进队列削峰、把峰值时段的部分流量切到更便宜也更容易拿到配额的模型。多模型降级的具体写法在 多模型 fallback 怎么设计 里有展开。
还有一种余量是留在业务侧：允许一部分请求慢一点。不是所有场景都需要秒级响应，能接受几分钟延迟的任务放进异步队列，峰值曲线会立刻被削平一大截，这往往比争取更高配额来得更快也更省。
至于免费档能不能扛生产流量，看限速数字就有答案了。每分钟 20 次这个量级，做原型验证、跑个人小工具是够的，扛真实用户流量则明显不够。有第三方转述提到官方不建议把免费档用于生产环境，这句话没有在官方原文里逐字核到，但从限速数字本身也能推出同样的结论。免费档的适用边界在 OpenRouter 免费模型怎么用 里讲得更具体。
一份可以直接照做的规划顺序
- 先分别列出金额预算和速率需求两张表，不要合并。
- 金额表按最近 30 天实际消耗的均值起步，叠加工作日/周末形状和增长斜率，余量不必大。
- 速率表按分钟级 P95 或 P99 起步，乘上重试系数，请求数和 token 数分开列。
- 把业务路径分类，每类估输入/输出 token，按峰值占比加权算峰值时段的每分钟成本。
- 给批量任务单独的 key 和单独的并发上限，尽量错峰。
- 在客户端实现指数退避加抖动，读取 429 响应里平台给出的等待提示，不要固定间隔硬重试。
- 准备一条降级路径，并且在非峰值时段就演练一次，别等真出问题才第一次跑。
- 把充值节奏定成按月或按季度，避开小额高频带来的最低手续费损耗，也避开一次充太多的到期风险。
说说这套方法的局限
这套方法有几个地方是它解决不了的，得说清楚。
一是历史数据不够时它会失灵。全新上线的功能没有分钟级日志可看，只能先给一个保守的上限并把监控做密，跑两周再回来重估。
二是各平台的配额规则本身在变。同一家平台不同页面的表述都可能对不上——OpenRouter 关于 BYOK 平台费的规则，FAQ 页是按请求次数口径描述、Pricing 页是按金额口径描述，两者不完全一致，具体以官网当前页面为准。规划容量模型时，凡是拿不准的口径就别写进模型里，宁可留出更大余量，也不要让一个未经确认的数字支撑整套预算。
三是准入前提。OpenRouter 是境外托管的服务，官网和 API 端点都在海外，其底层依赖的多家海外厂商对中国大陆有地区限制（例如 Anthropic 官方受支持地区列表不含中国大陆），具体以各自官网的地区政策页为准。本文不提供也不背书任何第三方中转渠道，这类服务的合规性与稳定性风险需要使用者自行判断。如果项目要在国内长期稳定运行，这一层前提比配额算得准不准更靠前。
小结
金额配额按均值规划，速率配额按峰值规划，两者不要互相替代。峰值的估法是看分钟级的高分位数，不是拿日总量去除以时间。输入和输出单价不对称，峰值成本要按业务路径分类加权算，不能靠总量线性外推。余量可以留在平台档位、架构降级、业务异步化三个层面，通常后两个比前一个更快见效。最后，任何数字都会变，把口径来源记清楚，比记住数字本身更有用。