正如我们在讨论API 密钥池化的挑战时所提到的，构建 AI 网关作为用户与上游大模型之间的主要接口时，请求路由只是一半工作。更难的部分是设计产品级的预算系统。
如果配额系统设计不当，一次请求并发突增就可能绕过限制，透支上游 API 账户，并导致所有客户大面积遭遇 429 Too Many Requests 故障。
在本文中，我们将介绍分布式 AI 配额引擎的架构蓝图。
架构拆分：执行与真相
构建 AI 网关时最常见的一个错误，就是把代理本身当作事实源。
生产架构必须将请求执行与预算事实分开。网关可以解析 headers、管理流式 Server-Sent Events (SSE)、处理 timeouts。但一个专门的预算模块（或微服务）必须拥有用户预算、计数器和开支的权威视图。
需求侧与供给侧限制
生产环境的 AI 网关运作像一个双边市场。一个请求只有在通过等式两边的检查后才算有效。
1. 需求侧限制（用户）
这是对发起请求实体的约束。
- 身份： 是谁？（通过 Virtual Key 映射）
- 允许的模型： 可以用
gpt-4o，还是只能用gpt-3.5-turbo？ - 最大开支： 这个团队是否已超过每月 500 美元的限额？
- 速率限制： 是否超过了分配的 50 Requests Per Minute (RPM)？
2. 供给侧限制（提供商）
这是你实际的上游基础设施的约束。
- Provider Keys： 有哪些 OpenAI/Anthropic 密钥可用？
- 容量：
sk-key-1是否还有足够的 Tokens Per Minute (TPM) 来完成这个 prompt？ - 冷却： 这个特定密钥是否正被提供商的
429锁定？
Virtual Key 就是预算边界
Virtual Key 不仅仅是一个身份验证令牌；它就是基本的预算边界。
在多租户系统中，Virtual Key 同时代表身份、模型访问和开支归属。这正说明了为什么不能在多个节点间同步 Virtual Key 状态的架构（比如我们之前分析过的 Bifrost 开源部署）是有缺陷的。如果 Virtual Key 状态不是全局一致的，你的预算边界在负载下根本就不存在。
预算模块的请求流程
要安全地协调这些约束，你的预算模块必须执行一个特定的操作序列：
- 解析 Virtual Key： 识别用户、团队或客户策略。
- 检查模型访问： 确保请求的模型对这个 Virtual Key 是允许的。
- 检查需求侧配额： 查询 Redis/Postgres，确保用户有足够的 RPM/TPM 和资金预算。
- 候选选择： 向路由层询问可用的 Provider Key。
- 检查供给侧配额： 确保选定的 Provider Key 有容量。
- 预留配额： 在转发请求之前，原子地预留估算的成本。
- 执行： 把请求代理到 LLM 提供商。
- 结算： 从提供商的响应 headers 计算实际使用的 token，并更新最终成本。
- 持久化： 把持久的开支账本写入 Postgres。
为什么预留要在并发下进行
第 6 步（预留）是整个系统的关键。
假设用户 X 的预算还剩 1.00 美元。他启动一个脚本，向网关同时发出 100 个请求。
如果你的网关用的是"只读"预算检查，这 100 个请求会在同一毫秒查询数据库。这 100 个请求都看到"剩余 1.00 美元"，都允许请求继续。几秒后 LLM 返回，成本结算完毕，用户 X 已经消耗了 10.00 美元的算力，把硬性限额超出了 10 倍。
iWarning+
要避免这种情况，系统需要原子预留。当一个请求到达时，网关必须立刻从 Redis 中的热计数器里扣减请求的估算成本（比如 input_tokens + max_tokens）。
如果预留把预算推到零以下，请求就被阻止。一旦请求完成，网关把未使用的 token 退还到 Redis 计数器。通过在 Redis 内部原子地执行预算检查和扣减，你完全消除了竞态条件。
硬性限制、软上限与结算
执行这些限制需要根据指标采用不同的策略：
- 硬性 RPM（Requests Per Minute）： 这个直接。你在路由前原子地递增一个 Redis 计数器。如果超过限额，就阻止。
- 接近硬性的 TPM（Tokens Per Minute）： 你必须在路由前预留估算的 token。因为 LLM 输出 token 不可预测，你用
max_tokens参数作为最坏情况的预留。 - 软预算（总开支）： Vercel 的 AI 网关文档明确把 API 密钥预算描述为在请求开始时检查的软上限。你允许"越线请求"（把用户从 49.95 美元推到 50.10 美元的那个）完成，但在结算阶段立即阻止所有未来的请求。
Redis 和 Postgres 的角色
一个健壮的预算模块把职责分配到临时和持久的数据存储之间。
Redis 负责热路径：
- 实时的 RPM/TPM token 桶。
- 在途请求的原子预留。
- 最大并行请求数的计数器。
- 短期的提供商冷却锁。
Postgres 负责持久路径：
- Virtual Key、用户和团队的权威列表。
- 预算定义和计费策略。
- 不可变的开支账本和对账记录。
最终结论
生产环境的 AI 网关本质上是一个双边分布式配额引擎。Virtual Key 代表你需求侧的身份和预算执行，而 Provider Key 代表你的上游容量。
通过使用分离持久状态和临时状态的工具，比如 LiteLLM，通过 Redis 协调实时预留，通过 Postgres 记录持久开支，你可以扩展你的 AI 基础设施来处理高并发，而不至于透支 API 账户。任何无法在节点间同步这种状态的网关架构，就像我们在 LiteLLM 与 Bifrost 的对比中看到的，对生产环境来说都是不安全的。
