API 中转站限流配置实操：四层阈值划分、令牌桶参数与 429 退避重试怎么落地

很多团队把限流当成上线前最后一个开关，结果流量一上来不是被上游掐断，就是自己把自己拦死。API 中转站的特殊之处在于，它同时面对两拨人：上游是各家模型供应商给出的 RPM、TPM 与并发上限，下游是内部多个业务共用同一套中转入口。任意一侧的额度被吃满，表现都是 429，但原因完全不同，排查方向也完全不同。所以限流策略的第一件事不是把数字调小，而是先把量算清楚、把层分清楚。

分层是限流配置的地基。实践里通常至少分四层：平台总配额、账号级配额、Key 级配额，以及模型或渠道级配额。平台总配额守住上游给出的额度，账号级用于区分业务线，Key 级用来隔离到具体应用，模型级则解决同一个 Key 混用多个模型时的互相挤占。四层阈值应当逐层收紧，外层是总和、内层是分项，任何一层先触发都要给出明确的拒绝原因，让调用方一眼看出是哪个维度被拦截。

算法选型没有绝对优劣，关键看流量形态。固定窗口实现简单，但在窗口交界处容易出现双倍突发；滑动窗口统计更平滑，代价是需要更多计数资源；令牌桶允许一定突发，适合交互式问答这类偶尔有波峰的调用；漏桶输出恒定，更适合批处理与离线任务。中转站常见的做法是入口用令牌桶承接突发，出口再按上游要求用滑动窗口做平滑，两层各司其职。

参数上最容易踩的坑是只看 RPM。真正把请求打挂的往往是并发数：一个请求平均耗时八秒，哪怕 RPM 只有六十，同时在跑的连接也可能接近八个，遇到长上下文或推理类模型时耗时更长，并发会迅速堆积。配置时应当把 RPM、TPM、最大并发三个维度同时设阈值，并且对输入与输出 token 分别计量，因为不少上游只对输出侧单独限速或单独计费，只按总量算会低估风险。

流式响应会让计量变得复杂。请求发出时只知道输入长度，输出长度要等流结束才确定，如果等结算后再扣额度，短暂的高并发就可能突破上限。稳妥做法是预估最大输出长度先做预扣，流结束后再按实际用量回补差额，同时对超长输出设置硬上限。这样限流判断始终基于已承诺的额度，而不是事后统计出来的数字，闸门也能卡在真正需要卡的地方。

中转站还要区分限流到底来自哪里。上游返回的 429 通常带有限速头或特定错误码，本地拦截则会在网关层直接拒绝。两者虽然都返回 429，但语义不同：前者应当触发渠道降级或切到备用供应商，后者应当直接告诉调用方稍后再试。给两类事件打上不同标签，是多模型路由能否自动切换的前提，否则很容易出现本地已经拒绝、系统却还在向上游重试的无效消耗。

重试设计是限流策略里最容易被忽略的一环。客户端 SDK 往往自带重试，网关层如果再叠加一层重试，等于把一次失败放大成多次请求，反而加剧限流。建议明确重试责任的归属：网关只对幂等的、明确可重试的错误做一次快速切换，其余交给调用方处理。退避要带随机抖动，避免所有客户端在同一时刻集体重试，形成新的波峰把刚恢复的渠道再次打满。

阈值定得准不准，最终靠观测说话。需要盯的指标包括各层限流的命中次数、被拒绝请求按 Key 的分布、请求排队时长、上游返回 429 的比例，以及成功率随并发上升的变化曲线。如果某个 Key 长期吃满而其他 Key 空闲，说明配额划分不合理；如果上游 429 比例居高不下，说明本地阈值比上游实际额度还宽松，等于把压力全交给了供应商。

调参顺序建议先观测后拦截。新接入一个模型或渠道时，先以只记录不拒绝的方式跑一到两周，拿到真实的峰值 RPM、TPM 与并发分布，再把阈值设在峰值的八成左右留出余量。上线后按小流量灰度逐步收紧，每次只改一个维度，观察 429 与延迟的变化，避免多个参数同时调整导致问题无法归因。这一步慢一点，后面线上排障会快很多。

选平台时，限流策略能不能落地，很大程度上取决于接入方式是否够透明。快米兔的模型 API 中转兼容 OpenAI 协议，接入时通常只需替换 base URL 与 Key，原有 SDK 与重试逻辑基本不用动；注册赠送 5 元测试金，按量计费，适合先用真实流量压测出自己业务的峰值曲线，再回头决定各层阈值。多模型路由的存在也让渠道降级更容易配置，遇到某个上游限流时可切换到备用渠道，而不是把失败直接抛给调用方。

限流配置本质上是一次容量规划，不是把参数填进配置文件的机械动作。把分层、算法、计量、降级与观测串成一条链，先算清楚自己能承受多少、上游能给多少，再决定在哪里拦、拦多少、拦了之后怎么办，中转站的稳定性才有可预期的基础。至于具体平台的默认阈值与可调范围，以官方说明为准，压测时按真实业务流量校准即可。