API 中转站限流策略配置实操：令牌桶、并发闸门与按 Key 配额的组合打法

很多团队第一次给中转站做压测，都会遇到同一个现象：上游模型服务一切正常，网关 CPU 也没打满，但下游调用方开始大面积超时，几分钟后又自己恢复。翻日志才发现，问题不在模型，而在限流没配好——要么完全没限，要么只在上游做了一层粗暴的并发限制，导致某一个 Key 把整个账号的额度吃光。

限流策略的本质，是在「让请求尽量通过」和「保住整体可用性」之间找平衡。中转站面对的不是单一调用方，而是多个业务方、多个 Key、多套模型混跑。如果只按总并发卡一个阈值，那么一个跑批脚本就能把在线客服的实时请求挤掉。所以第一步要做的不是调参数，而是分层。

常见的分层方案是三档：入口层、路由层、租户层。入口层按来源 IP 或网关实例做粗粒度保护，主要拦住突发洪峰和异常扫描；路由层按模型维度限流，因为不同模型的配额、价格和响应时间差异很大；租户层按 Key 或账号维度做配额，这是最需要精细设计的一层，直接决定谁能用多少。

落地上最常用的两种算法是令牌桶和滑动窗口。令牌桶允许一定程度的突发，桶容量决定瞬时高峰能放多少，补充速率决定长期平均吞吐，适合对话类这种「平时不高、偶尔一阵猛」的流量。滑动窗口统计更贴近真实速率，超限更少，但实现成本略高，适合批量推理、定时任务这类稳定但持续的调用。两者不是二选一，很多中转站是入口用令牌桶、配额用滑动窗口。

限流维度也要同时考虑请求数和 Token 数。只按每分钟请求数限流，会漏掉长上下文请求这个隐形大户：一条十万 Token 的请求，占的算力和额度远超几百条短请求。比较稳妥的做法是两把尺子同时量，请求数超额直接拒绝，Token 数超额则做排队或降级，避免出现「请求不多但账单爆掉」的情况。

超限之后的行为比阈值本身更容易被忽略。直接返回错误是最省事的做法，但对调用方体验很差。更常见的处理是分级响应：轻微超限先做短时间排队，队列满了再拒绝；如果配置了多模型路由，可以在主模型限流时切到同能力的备用模型，把请求放过去。这套降级逻辑要在网关侧配置，而不是让业务方自己重试。

多模型路由和限流天然是一对。中转站通常同时接入多个上游，路由策略既影响成本也影响稳定性。把限流和路由联动起来，可以做按优先级分流：核心业务走低延迟通道，非核心的批处理任务在高峰期自动后移。关键在于路由规则和限流规则要放在同一套配置里维护，否则两边阈值不一致，很容易出现「路由以为能走、限流直接拦掉」的空转。

Key 管理是限流的另一半。一个账号下往往有多个 Key，分给不同的项目或环境。如果不做 Key 级配额，就等于把整个账号的额度交给最不守规矩的调用方。实操上建议每个 Key 单独设置每分钟请求数、每日 Token 上限和并发数，并且保留单独开关，出问题时能只停某个 Key，而不是全账号拉闸。

监控和告警决定了限流是「配完就忘」还是「持续可调」。至少要看的指标包括：各层限流触发次数、排队时长、被拒绝请求占比、按 Key 的 Token 消耗曲线、以及各上游模型的错误率和延迟。触发次数突然上涨，往往意味着某个业务在放大流量；被拒绝占比长期高于一个百分点，就说明阈值偏紧，需要重新评估。

快米兔 API 在这类场景下提供的思路比较贴合中小团队。它按 OpenAI 兼容协议接入，已有代码基本只需改 base_url 和 Key，注册送 5 元测试金、按量计费，不设月付套餐，做限流策略验证时不用先买大套餐，压测成本可控。多模型路由和 Key 管理可以在一处配置，用起来比较省事。具体配额上限和限流面板能力以官方说明为准。

配置顺序上有个比较稳的做法：先把 Key 级配额配好，再把路由层的模型限流打开，最后压入口层。因为 Key 级最容易定位问题，入口层最粗也最容易被误伤。参数调整建议小步走，每次只改一个维度，观察一到两个业务周期再动下一个，避免多个变量同时变化导致无法归因。

还有一个细节是限流的单位统一。中转站里请求速率、并发数、Token 速率往往用不同单位表达，有人按秒算、有人按分钟算，配置时容易差一个数量级。落地前把单位在文档里写清楚，并在灰度环境用真实流量校验一遍，比事后拍脑袋调参可靠得多。

总的来说，限流不是一道简单的开关，而是一套和路由、计费、监控绑在一起的运行策略。分层限流保证公平，算法选择匹配流量形态，Token 与请求数双维度防止账单失控，超限降级和告警让系统在压力下有退路。把这些串起来之后，中转站的稳定性问题通常会从「偶发雪崩」变成「可预测的容量规划」，这也是按量计费模式下更值得投入的一块基础工作。