API 中转站限流策略怎么配才不误伤业务：阈值测算、分组隔离与降级顺序的实操清单

很多团队把中转站跑通之后，第一件被搁置的事就是限流。直到某个深夜，一个爬虫脚本用同一个 Key 把整月额度刷穿，紧接着所有正常用户开始收到 429，客服群里全是请求失败的截图，才意识到限流不是可选项。限流配置的目标从来不是把请求挡住，而是在资源有限的前提下，让真正有价值的请求优先通过。配得太松等于没配，配得太紧会误伤业务，这中间的度只能用数据来量。对 API 中转站来说，限流既是对上游模型额度的保护，也是对下游调用方公平性的维护。

配限流的第一步不是调参数，而是确定按什么维度计数。常见的维度包括单个 API Key、单个账号、单个模型、来源 IP、接口路径以及全局。维度选错，后面所有参数都白搭。比如只做全局 QPS 限制，一个大客户突发流量就会把中小客户的额度一起挤掉；只按 Key 限制，多注册几个账号就能绕开。比较稳妥的做法是分层，账号层管总量和计费，Key 层管细粒度并发，模型层管贵模型的使用强度，IP 层只作为异常防护的兜底。

阈值不能拍脑袋定。上线初期建议先跑一段影子模式，只记录不限流，把每个维度上的请求量、并发数、Token 消耗分布拉出来。重点看 P95 和 P99，而不是平均值，因为峰值才决定系统会不会被打穿。在 P99 的基础上留出两到三成缓冲，作为初始阈值，然后逐步收紧。这个过程中如果发现某个维度的峰值远高于其余维度，说明它已经被滥用，需要单独拆出来观察。数据驱动的阈值，比经验估算更能扛住真实流量。

限流算法决定了流量被削峰的方式。固定窗口实现简单，但在窗口切换的临界点容易出现双倍放行，对上游冲击明显。滑动窗口更平滑，实现成本略高。令牌桶允许一定程度的突发，适合交互式场景，用户连续几次重试不会被立刻拒绝。漏桶则把流量整形成恒定速率，更适合批处理任务。并发数限制是另一条线，它约束的是同时在途的请求数，和 QPS 互补。实战里往往是组合使用，QPS 令牌桶加并发上限，再叠加一个每日 Token 总量。

不同付费层级的用户必须分池。免费试用流量和付费生产流量混在一个池子里，等于让试用者决定付费用户的可用性。做法是按套餐或账号等级划分独立的配额桶，每个桶有各自的上限，池与池之间不共享余量。内部测试、灰度环境、定时任务这类流量也应该单独建池，避免它们和线上请求抢资源。分池还有一个好处，限流触发时你能立刻定位是哪一类流量越界，而不是面对一个总数无从下手。

中转站自己也受上游约束，上游返回 429 时，本地限流再精确也救不回来。这时候需要一套协同机制，对上游错误做区分，是配额耗尽、速率超限还是临时抖动，分别对应不同处理。速率类错误可以用指数退避加随机抖动重试，配额类错误则应快速失败并切换备用通道。如果配置了多个上游 Key，可以做 Key 池轮转，把压力分散开。多模型路由在这里也有价值，主模型被限时，把请求降到同能力的备用模型，比直接返回失败体验好得多。

限流触发后，请求不是只有成功和失败两种结局。合理的降级顺序是先保证在线交互类请求，把批处理、数据清洗、离线评测这类任务延后或降低优先级。可以在网关层给请求打上优先级标记，额度紧张时优先放行高优先级，低优先级进入排队队列，队列超时再返回 429。这样做的代价是低优先级任务变慢，但换来了核心业务的稳定。很多事故并不是因为总量不够，而是因为没有区分谁更重要。

限流和计费是一体两面。按量计费模式下，如果限流放行了一批已经欠费的请求，损失是实打实的。比较稳妥的做法是在请求进入时做一次额度预检查，余额不足直接拦截，请求完成后按实际消耗扣减，再释放预扣额度。对于长对话或流式输出，预扣要考虑最大可能消耗，结束时多退少补。这样既能防止余额穿仓，也不会因为提前扣费影响体验。具体扣费精度与结算周期，各平台以官方说明为准。

限流生效时返回什么，和限不限流同等重要。响应体里应该明确给出限流维度、重试建议时间和当前配额状态，客户端才能做出正确反应。一个只有 429 状态码、没有重试提示的响应，会让客户端盲目重试，把压力再放大一轮。SDK 侧要配合做指数退避和抖动，对非幂等请求还要避免重复提交。中转站如果遵循 OpenAI 兼容协议，客户端通常能直接复用现有的重试逻辑，接入成本会低不少。

限流策略上线不是终点。需要持续跟踪几个指标，限流命中率、被拦截请求的账号分布、正常业务被挡的误伤比例，以及限流前后上游错误率的变化。如果命中率长期偏低，说明策略太松；如果少量账号贡献了大部分拦截，说明有账号需要单独沟通或调整等级。调整时采用灰度，先对一部分流量生效，观察一个完整的业务周期再全量，避免一次性收紧引发大面积故障。

在 API 中转的实践里，快米兔围绕账号、Key 与模型做分层配额，按量计费的模式让限流阈值和成本直接挂钩，新用户注册送 5 元测试金，方便先跑影子流量、把真实用量分布摸清楚，再决定阈值怎么收。接入侧沿用通用的 OpenAI 兼容调用方式，现有重试与退避逻辑基本可以原样保留，减少了限流调参之外的额外工作量。具体的配额上限、并发规格和计费精度，以官方说明为准。

限流策略没有标准答案，只有适配当前流量结构的答案。先把维度定清楚，用真实数据算阈值，再选算法、分池、排降级顺序，最后补上监控与灰度，这套流程走一遍，基本能避开大部分限流事故。选服务商时，除了看模型覆盖和价格，也要看它是否提供足够细的配额配置和清晰的限流反馈，这决定了流量增长时你是从容还是被动。对多数中小团队而言，快米兔这类按量计费、配额分层清晰的中转方案，上手和后续调整都更省事一些。