当你第一次把大语言模型 (LLMs) 集成进产品时，一切都能跑。你发一个 prompt，拿到一个回复。但随着用户基数增长，你会撞上一堵硬墙：提供商速率限制。
无论是 OpenAI 严格的每分钟 Token 数 (TPM) 限制，还是 Anthropic 的每分钟请求数 (RPM) 约束，单个 API 密钥很快会成为瓶颈。直观的解决办法是把多个 API 密钥池化到同一个模型上，人为地扩大你的总速率限制容量。
不过，管理一个提供商 API 密钥池会带来架构上的转变。我们来探讨一下为什么简单的反向代理不够，如何真正实现 API 密钥池化，以及安全地做这件事所需的通用架构。
催化剂：撞上速率限制墙
大多数主要的 LLM 提供商都执行双重速率限制：
- RPM（每分钟请求数）： 限制并发连接的绝对数量。
- TPM（每分钟 Token 数）： 限制实际算力吞吐（通常是输入和输出 token 的混合）。
如果你有一个快速增长的 AI 应用，撞上 1M TPM 限制很容易。几个重度用户处理大文档就能在几秒内耗尽你的配额，让你的其他用户盯着 429 Too Many Requests 错误。
解决这个问题的逻辑步骤是准备多个 API 密钥（或多个云部署，比如几个 Azure OpenAI 端点），在它们之间负载均衡流量。一个密钥给你 1M TPM，五个密钥就给你 5M TPM。
天真的方案：为什么简单的负载均衡器会失败
你的第一直觉可能是把 Nginx、HAProxy 或一个基础的 AWS ALB 放在请求前面，在你的 API 密钥池上配置一个简单的轮询路由策略。
这在生产环境里会失败。
iWarning+
标准反向代理追踪的是请求，不是token。
传统 Web 流量的请求资源开销相对均匀，而 LLM 请求各不相同。请求 A 可能问一个简单的问题，消耗 50 个 token。请求 B 可能传入一个巨大的 PDF，消耗 10 万个 token。
如果一个天真的轮询均衡器按数量均匀分发这些请求，它会不均匀地耗尽底层密钥的 token 配额。一个 API 密钥可能瞬间就达到它的 TPM 限制，而另一个却完全闲置。要正确地路由流量，负载均衡器需要理解 payload 大小，估算 token 数量，并维护每个提供商密钥还剩多少容量的状态。
怎么做：三层 AI 架构
要真正搭出这个，你必须放弃单一"智能代理"的想法。生产环境的 LLM 基础设施把职责分到三个不同的层。
1. 控制面（事实源）
这一层拥有全局状态。它存储你的虚拟密钥（用户身份）、用户预算、提供商 API 密钥，以及实时的 RPM/TPM 计数器。它通常由 Postgres（用于持久的计费/密钥）和 Redis（用于快速的令牌桶）支撑。
2. 路由引擎（决策者）
这一层决定请求去哪里。它检查控制面，看哪些提供商密钥还有剩余容量，评估回退逻辑，选择最优的上游提供商（比如选择 OpenAI 密钥 #3，因为它有最多的可用 TPM）。
3. 网关（执行层）
这是"哑"数据平面。它接收 payload，附上路由器选择的物理 API 密钥，把请求转发给 LLM，把 Server-Sent Events (SSE) 流式传回客户端，并向控制面回传使用日志。
实现分布式速率限制
当你运行多个网关节点时，如何真正防止重叠请求冲破限制？你必须通过 Redis 的悲观锁来把配额检查外部化。
当一个请求到达时，控制面拦截它，估算 token 成本，并在把请求转发给网关之前从一个全局 Redis 计数器里扣掉这部分成本。如果 Redis 计数器归零，请求立即被阻止。
因为 Redis 原子地处理命令，你有 1 个还是 100 个网关节点同时处理请求都不重要。两个并发请求不可能掏空同一个 1.00 美元的预算。控制面保证配额永远不被突破。
下一步：选择你的实现
你可以完全从头搭建这个三层系统，但大多数团队会采用实现了这个模式部分（或全部）的开源 AI 网关。
不过，不是所有网关都用同一种方式处理全局状态。在后续文章里，我们会深入这种架构需求如何影响你的选择：
- LiteLLM： 把控制面（通过 Redis）和路由器/网关打包在一起，让它开箱即有能力做分布式的开源速率限制。
- Bifrost： 充当快速的路由器/网关，但按节点追踪状态。要在不购买企业集群的情况下安全扩展它，你必须自己搭建并外接一个控制面。
要更深入地了解需求侧限制与供给侧限制背后的理论，请查看我们的AI 网关预算架构蓝图。
