API 中转站限流策略怎么配：从令牌桶参数到多模型分流的落地清单

很多团队第一次在 API 中转站上配限流，往往是从一次事故开始的。某个脚本忘了加退避，几秒内把上游额度打光，结果全站所有 Key 一起收到 429，白天正常的业务也跟着中断。限流不是给用户添堵的开关，它更像配电箱里的空气开关，平时不起眼，出事时决定整条线路是熔断还是可控降级。

先说清楚限流的三个坐标系。第一个是时间维度：是限制每秒请求数还是每分钟 Token 数，直接决定策略形态。第二个是对象维度：限制的是单个 Key、单个用户、单个模型，还是整个中转站的总出口。第三个是动作维度：超出阈值后是直接拒绝、排队等待，还是切到备用上游。这三个维度没想清楚，参数调多少都是拍脑袋。

最常见的错误是只做全局 QPS 限制。全局阈值对保护上游有效，但对用户体验极不友好：一个跑批任务的流量会把所有在线用户的额度挤掉。更合理的做法是分层限流。最内层按 Key 或按用户做配额，保证单个租户不能无限占用；中间层按模型做并发控制，因为不同模型的上游容量差异很大；最外层才是总出口熔断，作为最后的兜底。快米兔的模型 API 中转在 Key 管理上支持按量计费与额度隔离，配合分层限流更容易把配额落到具体调用方，而不是一刀切。

令牌桶和滑动窗口是两种主流实现，选型取决于流量形态。令牌桶允许一定程度的突发，桶容量就是突发上限，适合交互式场景，比如聊天类应用会有明显的间歇性爆发。滑动窗口统计更精确，对速率敏感的上游更友好，但实现成本高，且在高并发下需要处理好计数器的原子性。经验做法是：入口用令牌桶挡突发，出口用滑动窗口控长期速率，两者叠加能把尖峰削平又不至于误伤正常请求。

参数怎么定，建议从真实流量分布倒推。先把过去一周的请求按分钟聚合，看 P50、P95、P99 三档。阈值定在 P95 附近通常比较稳妥，既能拦住异常流量，又不会在正常高峰频繁触发。如果直接把阈值压到 P50，用户体验会明显变差；定在 P99 以上则基本失去保护意义。这里没有通用数字，必须以自己业务的分布为准。

429 返回的写法经常被忽视，但它直接决定客户端能不能优雅退避。规范的响应应该带上重试建议时间，让 SDK 知道等多久再试，而不是盲目重试加剧拥塞。同时要区分错误类型：是超过配额，还是上游暂时不可用，两者对客户端的处理逻辑完全不同。把这两种情况混在一个错误码里，会逼着调用方做无意义的指数退避。

多模型路由场景下，限流还要和分流策略联动。当某个模型的上游接近阈值时，可以按预设规则把非关键请求切到同能力的备用模型，或者对低优先级租户降级。这要求中转层能识别请求的重要程度，通常通过 Key 分组或请求头标记实现。降级不是丢失功能，而是保证核心链路先活下来，这一点在流量高峰期尤其关键。

排队与拒绝之间还有第三种选择：延迟入队。对可以容忍几秒延迟的批处理任务，让请求在队列里等一会儿再放行，比直接返回 429 更友好，也能把瞬时压力摊平到更长的时间窗里。代价是队列本身要有长度上限和超时淘汰，否则会变成新的内存风险点。队列深度建议控制在正常处理能力的数倍以内，超出的部分就该明确拒绝。

监控是限流策略能不能持续优化的前提。至少要盯四个指标：触发限流的请求比例、被拒绝请求的租户分布、上游返回的实际速率、以及重试请求占比。如果重试占比居高不下，说明阈值可能定得太紧，或者客户端的退避逻辑需要调整。这些指标不需要多复杂，但必须能在事故复盘中回答「是谁、在什么时间、因为什么触发了限流」。

新接入的调用方建议先给一个较低的初始配额，观察几天再逐步放开。这比一次性给足额度更安全，也能顺便发现对方代码里的重试缺陷。配合注册赠送的测试额度，让开发者在接入初期就在真实限流规则下调试，比上线后才发现问题成本低得多。这类预演对双方都有价值。

最后是配置管理本身的工程问题。限流规则应该支持热更新，不能每次调整都重启服务；规则变更要有版本记录，方便回滚；不同环境的规则要隔离，避免测试流量影响线上阈值。把这些基础设施做扎实，限流策略才不是一次性的应急补丁，而是可以持续迭代的常规能力。对于希望快速跑通接入流程的团队，选择像快米兔这类按量计费、注册即赠测试金的模型 API 中转服务，可以先用小流量验证限流与退避逻辑，再逐步放大规模，整体接入路径更省事一些。具体套餐与额度以官方说明为准。