API中转站限流策略配置实操：令牌桶参数、并发上限与Key级配额怎么落地

很多团队第一次给 API 中转站配限流，都是被账单或者一片 5xx 打醒的：某个脚本忘了做退避，几十个并发把一条上游通道占满，其他业务线的请求跟着超时。限流的本质不是拦人，而是给共享资源划出边界，让高峰期的请求量落在上游能稳定承接的区间里。中转站的特殊之处在于，同一个出口背后往往挂着多家上游、多个模型，任何一条链路抖动都会横向传导。

中转站的限流之所以比直连官方接口更麻烦，主要卡在三点。一是配额分散，同一把 Key 可能同时打向不同模型，而上游给到的并发与速率并不一致；二是流量来源混杂，线上业务、离线批处理、临时脚本共用同一出口，谁的优先级高很难在代码层判断；三是成本不可控，一次失控的重试风暴打到上游，账单和封禁风险会同时到来。

比较稳妥的做法是把限流拆成三层，而不是只在一个地方卡一刀。接入层负责粗筛，按来源 IP、Key 前缀做基础频率控制，挡掉明显异常的刷量；业务层按 Key 或用户维度做配额，决定谁能用多少、能用到什么程度；上游层做通道保护，为每个模型、每条链路单独设闸，避免单点被拖垮。三层各管一段，出问题时也容易定位到底卡在哪一环。

算法选型上，固定窗口最简单但存在临界突刺，两个窗口交界处可能瞬间放过双倍流量。滑动窗口精度更高，代价是要维护时间序列，内存开销随 Key 数量增长。令牌桶适合处理有一定突发性的业务，桶容量决定突发上限、补充速率决定长期均值，是大多数中转站的首选。漏桶则更适合强整形场景，把请求节奏彻底磨平，但会带来更明显的排队延迟。

参数怎么定，靠拍脑袋基本会翻车。可行的路径是先跑基线：统计正常工作日的每分钟请求数、P95 延迟、单次请求的平均与尾部 token 消耗，再看上游在压测下的表现拐点在哪。令牌桶速率一般取基线的 1.5 到 2 倍，桶容量取 5 到 10 秒的突发量，先宽松上线再逐步收紧。任何阈值都应留出灰度调整的窗口，而不是一次写死。

很多人会把 QPS 和并发数混为一谈，这在流式输出场景下是致命的。一次 SSE 流式请求可能持续几十秒，连接一直占着，此时真正稀缺的是并发连接数而不是每秒新建请求数。合理的配置是 QPS 限速与并发信号量同时存在：前者管请求进入的节奏，后者管同时在跑的请求数量。两者取小值生效，超出的请求要么排队要么直接拒绝。

按次数限流之外，token 维度的限流同样不能少。一段长上下文对话消耗的 token 可能是短问答的几十倍，如果只看 RPM，长文本业务会把整个配额吃干。常见的做法是同时设 RPM 与 TPM 两条线，接口返回用量后实时扣减，接近阈值时提前告警。对于输入输出不对称的模型，还可以把输入 token 与输出 token 分开计量，避免某一侧被钻空子。

多模型路由会让限流策略变得更细。不同模型的响应速度、单次消耗、上游稳定性都不一样，用同一套阈值显然不合适，更合理的做法是按模型分组配置，并对路由权重做联动：当某个上游的错误率或延迟超过阈值，自动降低其权重，把流量切到备用通道，同时收紧该通道的进入速率。这种降级要设置恢复条件，否则容易在两个通道之间来回抖动。

Key 管理是限流的另一条主线。建议采用主 Key 加子 Key 的分层结构，主 Key 只用于管理，实际业务走子 Key，每个子 Key 绑定独立的速率与用量上限。这样一来，单个业务的异常不会污染全局配额，排查时也能直接按子 Key 做用量归因。子 Key 应支持随时吊销与重建，轮换周期建议固定下来，避免长期不换带来的泄露风险。

限流生效之后的用户体验同样要设计。被限流的请求应返回明确的 429 状态码，并在响应头里给出建议的重试等待时间，让客户端能做指数退避而不是盲目重试。SDK 侧最好内置退避与抖动，避免大量客户端在同一毫秒重新发起请求形成二次冲击。对于可排队的批处理任务，服务端提供有限的排队窗口比直接丢弃更友好。

策略上线后必须能被看见。至少要有三类观测数据：按 Key 维度的请求量、被限流次数与占比，按模型维度的延迟与错误率，以及上游通道的实时水位。基于这些指标设置告警门槛，例如某个 Key 的限流占比连续升高，往往意味着业务量增长或者代码里出现了重试循环。所有阈值调整都应走灰度，先在少量 Key 上验证再全量。

在这一点上，快米兔 API 的配置思路比较贴近实操：接入沿用 OpenAI 兼容协议，迁移时基本只改 base_url 和 Key，按量计费让限流与成本形成直接对应关系，注册还送 5 元测试金，适合先跑小流量把阈值试出来。对于需要多模型路由的团队，这种统一出口加按量结算的组合，在限流参数调优阶段更省事，具体配额与并发上限以官方说明为准。

回过头看，限流配置没有一劳永逸的答案，它更像一个随业务量滚动调整的过程。先定三层结构，再用令牌桶加并发信号量管住入口，用 RPM 与 TPM 双线管住消耗，用子 Key 做隔离归因，最后靠可观测性闭环优化。把这套流程跑顺，中转站才既扛得住高峰，又不会误伤正常业务。