AI网关限流不能只按请求数：Token级配额怎么设计

很多团队最早接入 AI API 时，会沿用传统 Web API 的限流方式：每分钟多少次请求、每个 IP 多少并发、每个用户多少 QPS。这个思路能挡住一部分滥用，但放到大模型调用里，很快就不够用了。

原因很简单：两个请求的成本可能完全不同。一个 200 token 的分类请求和一个 80K 上下文的文档分析请求，在网关里都算一次请求，但对上游额度、账单和延迟的压力不是一个量级。

为什么只看请求数会失真

AI 调用至少要同时看三类指标：

• RPM：每分钟请求数，用来控制入口频率
• TPM：每分钟 token 数，用来控制真实计算负载
• 预算额度：按团队、项目、key 或环境限制总消耗

如果只设置 RPM，高 token 请求仍然可能把账单打爆；如果只设置 TPM，小请求风暴又可能把队列挤满。所以更成熟的 AI 网关会把请求频率和 token 额度叠在一起看。

Token级配额应该按谁来分

常见的分配维度有四个：

1. 用户维度：防止单个账号异常消耗
2. 团队维度：让业务线对自己的使用负责
3. 项目维度：区分生产、测试、实验流量
4. 模型维度：高价模型和低价模型不能共享一套阈值

例如，测试环境可以给较低的 TPM 和月预算，生产客服摘要可以给稳定的中等额度，而高价推理模型只开放给少数任务。

突发流量要有缓冲，也要有刹车

AI 调用经常出现短时间突发：批量生成、脚本循环、任务队列重放、Agent 失控调用工具。网关如果完全不允许突发，会影响正常业务；如果完全放开，又容易出现账单事故。

更稳的做法是配置短窗口和长窗口：短窗口允许轻微突发，长窗口限制总体消耗。超过阈值后不要只有 429，还应该给出明确原因，比如 team_budget_exceeded、token_quota_exceeded 或 model_not_allowed。

成本告警比事后账单更重要

限流不是为了省一点边角钱，而是为了让成本可预测。团队应该至少设置三档告警：

• 达到 50% 预算时提醒负责人
• 达到 80% 预算时限制非生产流量
• 达到 100% 预算时冻结低优先级 key

如果这些策略散落在各个应用里，会很难统一执行。像 https://top-api.cc 这样的统一 AI 中转入口，更适合把 token 统计、模型分层、预算阈值和告警规则放在同一层处理。

设计配额时不要忘记业务优先级

不是所有请求都应该公平排队。生产告警摘要、客户工单分类、内部实验脚本，优先级应该不同。限流策略最好支持按业务标签分层：关键任务可以保留额度，实验任务可以在高峰期自动降级。

结语

AI 网关的限流不能停留在“每分钟多少次”。真正有效的策略，是把 RPM、TPM、预算、模型价格和业务优先级放在一起设计。这样既能保护上游额度，也能防止团队在月底才发现成本失控。