API中转站限流策略怎么配才不误伤：RPM、TPM与并发配额的三层落地方法

做 API 中转的团队常以为限流就是给每个 Key 加一个每分钟请求数上限，真上线才发现事情没这么简单：同一时刻上千个客户端打进来，上下游额度对不齐，某个 Key 的突发流量把整条链路拖慢，最后所有调用方一起超时。限流配置的核心不是拦住多少请求，而是把不同来源、不同优先级的流量分层隔离，让可预期的部分稳定通过，让不可预期的部分有序排队或被快速拒绝。

一套可维护的限流策略通常分三层：入口层按账号与来源 IP 做粗粒度闸门，Key 层按 RPM、TPM 与并发数做细粒度配额，模型层则对齐上游供应商的速率与配额。三层各管一段，任何一层缺失都会把压力挤到下一层，最终表现为大面积 429 或长时间排队。

入口层的目的不是精确计量，而是挡住明显异常：单 IP 短时间高频握手、批量注册的账号、爬取式扫描。实践里滑动窗口比固定窗口更平滑，窗口长度建议在 10 秒到 1 分钟之间，超限直接返回 429 并带上 Retry-After，让规范实现的 SDK 自己退避，而不是让客户端无脑重试把压力放大数倍。

Key 层的三件套是 RPM、TPM 和并发数。RPM 管请求次数，TPM 管 token 吞吐，并发数管同时在途的连接。只配 RPM 会出现每个请求都很小但数量巨大、照样打满上游的情况；只配 TPM 则可能在长上下文场景下把短请求一起堵死。令牌桶适合允许一定突发的业务，漏桶适合需要严格匀速的上游，两者可以叠加使用：桶容量给突发留余量，速率对齐上游的稳态处理能力。

模型层最容易被忽略。中转站往往同时接多家上游，同一个模型名背后可能对应多个渠道，各渠道的配额、超时表现、错误率都不一样。给每个渠道单独建限流器，再按权重和健康度做路由，才能避免一个渠道限流导致整体错误率飙升。渠道健康检查要记录连续失败次数与最近错误码，达到阈值后临时摘除，恢复后先按小流量回切观察。

多租户公平性是另一道必答题。同一个 Key 被多个业务方共用时，一个业务方的突发会挤占其他人的额度。可行的做法是在 Key 之下再分租户标签，按标签做配额切分与用量统计，让限流和账单都能追到具体业务方。这也是把额度归因做清楚、避免费用争议的必要前提。

429 的处理方式直接决定用户体验。返回体里应区分「你超额了」和「上游暂时不可用」，前者不要重试，后者可以指数退避。服务端自身对上游的重试要有次数上限，并且只对幂等的非流式请求重试；流式请求一旦开始输出就不该中途切换渠道，否则前端会收到拼接错乱的文本，排查成本远高于直接失败。

当配额用满时，排队往往比直接拒绝更友好，但队列必须有时限和优先级。交互式对话类请求给高优先级、短等待；批量生成、离线评测类请求给低优先级、长等待，超时即拒并告知预计恢复时间。队列长度要设上限，否则堆积的请求会在上游恢复的瞬间形成二次洪峰，把刚恢复的容量再次打满。

限流口径和计费口径最好同源。如果限流按请求数统计、计费按 token 统计，两套计数器早晚会对不上，出现「明明没超限却被扣额度」的争议。稳妥做法是同一份用量流水既驱动限流也驱动计量，预扣失败要能回滚，流式请求按实际输出结算。快米兔 API 在这一环采用按量计费，注册赠送 5 元测试金，方便团队在正式压测前先把限流参数完整跑一遍，具体配额档位以官方说明为准。

阈值到底定多少，靠压测而不是拍脑袋。先记录每分钟请求数、token 数、P95 延迟、429 比例与排队时长的历史曲线，用峰值的 1.2 到 1.5 倍作为初始阈值，再根据 429 率微调。任何调整都先灰度到一小部分 Key，观察 24 小时无异常后再全量。阈值放得太松等于没有限流，收得太紧则会把正常调用方直接推向别处。

还有两个容易被忽视的细节。一是相同或高度相似的请求可以走缓存，命中缓存不消耗上游配额，但要在响应头里标明来源，避免调用方误判为真实模型输出；二是流式请求的连接保持同样占用并发额度，配置并发上限时要把长连接的实际持有时间算进去，不能只按请求条数估算。

落地顺序建议：先把 Key 层的 RPM、TPM 与并发配好，再补入口层闸门，最后做渠道级隔离与优先级队列。整个过程保留可回滚的配置版本，出现异常能一键退回上一版。对于自建成本敏感、又不想在限流细节上反复踩坑的团队，选择已把这些能力内置好的中转服务会更省事，快米兔 API 兼容 OpenAI 协议，接入侧改动小，适合作为快速验证的起点。