多租户 LLM API 基础设施：规模化场景下的潜在故障点

大多数团队最初都使用单一的 LLM 提供商 API 密钥，并在所有业务中共享。这在起初行得通，直到某天它突然失效。也许在某个下午，数据管道中的一个批量任务耗尽了全部速率限制，导致面向用户的聊天功能陷入沉寂。或者财务部门要求你按团队细分 4 万美元的 LLM 账单，而你意识到自己根本无法回答这个问题。

在 LLM 提供商前部署生产级 API 网关可以解决这两个问题 —— 但它也会引入一类复杂性，大多数团队在遇到麻烦之前往往会低估这种复杂性。

为什么共享密钥是组织架构的单点故障

这种简陋的架构下，每个服务都使用同一个提供商 API 密钥：面向用户的产品、内部工具、批处理管道以及开发者的实验。这在概念验证阶段没有问题。但在生产规模下，它会以预见的方式失效：

• 成本不透明：你无法将支出归因到具体的团队或功能。当账单激增时，调查过程既耗时又不准确。
• 速率限制竞争：就在美东用户开启新的一天时，一个在午夜运行的批量任务可能会耗尽你的每分钟 Token 配额。
• 影响范围（Blast radius）：一个配置错误的服务如果调用了昂贵的模型，可能会耗尽所有人的月度预算。
• 审计缺失：如果不从日志中重新梳理历史记录（如果日志存在的话），你无法回答“是哪个服务发起了这次调用”。

这些问题在第一天都不是灾难性的。但到了第六个月，它们都会变成严重的运营债务。

层级隔离模型

多租户 LLM 基础设施的正确思维模型是预算和速率限制的嵌套层级，而不是 API 密钥的扁平列表。

一个设计良好的网关在四个层面组织主体：组织、团队、用户和虚拟密钥。每个层级都有自己的支出上限、速率限制和模型访问策略。约束向下传递 —— 团队的支出不能超过其父组织的允许范围，用户的支出不能超过团队预算，单个 API 密钥的支出不能超过用户的分配额度。

这很重要，因为它将“总成本是多少？”与“谁花了钱以及为什么要花钱？”这两个问题解耦。组织层级为财务部门提供了一个可追踪的单一数字。团队层级映射到你的内部成本中心。用户层级实现了开发过程中的个人问责制。虚拟密钥层级允许单个生产服务在基于 LLM 构建 SaaS 产品时，为每个客户创建限定范围的密钥。

组织划分对于 SaaS 构建者尤为重要：你的虚拟密钥变成了客户的隔离边界。当客户达到配额时，他们会收到 429 错误。当你配置新客户时，你会根据其定价层级创建一个具有相应预算的新虚拟密钥。计费逻辑和访问控制逻辑合并成了同一种机制。

Token 感知限流是必选项

借鉴自传统 API 的“每分钟请求数”限流对于 LLM 来说是错误的维度。一个带有 10k Token 上下文的 GPT-4o 调用消耗的计算资源远高于一个 50 Token 的摘要请求，但在简陋的计数方式下，两者都被计为“一个请求”。

正确的单位是 Token：以每分钟 Token 数 (TPM) 和每日 Token 数作为主要的预算维度，并将每分钟请求数 (RPM) 作为次要防护，以应对极短提示词带来的请求开销。

Token 感知限流需要预估响应到达前的 Token 数量 —— 这意味着要积极地计算输入 Token，并在响应完成后归属输出 Token。一些网关通过跟踪每个租户实际 Token 使用情况的滚动窗口来处理此问题；另一些则使用内存中的原子存储，根据实时计数器对请求进行预检。

跳过这一步的团队会面临“嘈杂邻居”问题：即使每个请求在 RPM 配额中只占一个单位，提交长上下文请求的高流量租户也可能导致整个共享部署的提供商速率限制达到饱和。

提供商故障转移：被动 vs 主动

单一提供商部署的可用性上限由该提供商决定。主要的 LLM 提供商都会经历超出你控制范围的停机、性能下降期和速率限制事件。如果你的产品依赖于单一提供商，那么该上限将直接被继承。

提供商故障转移策略分为两类。

被动故障转移监视错误信号 —— 5xx 响应、429 速率限制拒绝、超过超时阈值 —— 并将处理中的请求重新路由到备用提供商。网关会重新提交相同的请求，并将其转换为目标提供商'的 API 格式。用户会感觉到延迟略有增加，但不会遇到失败。有效的实现可以处理特定状态码的路由：429 意味着“该提供商已限流，请尝试另一个”，而 500 意味着“该提供商已宕机，使用备选链”。

主动负载分配不等待故障。它有意识地在提供商之间路由流量：将低优先级的批量工作路由到更便宜或 SLA 更低的提供商，将对延迟敏感的面向用户调用路由到测得 P95 延迟最低的首选提供商。一些团队在不同提供商之间使用加权轮询，以防范任何单一提供商的价格变动。

故障转移的延迟考量非常微妙。“如果主提供商在两秒内没有响应，就在备用提供商上触发相同的请求”听起来很直接。但如果你在尝试故障转移之前等待了足足两秒，那么在失败情况下，总请求延迟将变为四到六秒。对于对话式界面，这是显而易见的。关注感知延迟的团队会将对冲超时（hedge timeout）设置在用户有意识感觉到等待的临界点以下 —— 对于流式界面，通常低于 800 毫秒。

多租户部署中的 Prompt 缓存问题

Prompt 缓存——即服务商缓存长共享前缀的 KV 状态并在请求间重用——对于具有重复系统提示词或文档上下文的工作负载，可以将成本降低 70-90%。但在多租户部署中，它带来了一个未被充分重视的隔离风险。

当多个租户在启用前缀缓存的情况下共享同一个模型部署时，恰好共享前缀的请求可能会在缓存中发生碰撞。在实践中，这通常意味着对共享系统提示词进行良性的去重。但在底层，共享的 KV 缓存会产生计时侧信道：攻击性租户可以通过观察缓存命中的延迟变化，来推断其他租户最近输入了什么内容，即使无法看到实际内容。

实际的缓解措施是租户级缓存命名空间隔离（将租户 ID 哈希到缓存键中，使不同租户获得独立的缓存桶）或请求级缓存加盐。权衡之处在于跨租户的缓存重用率会降低——如果租户 A 和租户 B 恰好使用了相同的系统提示词，租户级命名空间将阻止它们共享同一个缓存命中。对于大多数工作负载来说，安全态势的提升值得牺牲这些效率。

如果你构建在具有不透明缓存的托管服务商（如 Anthropic、OpenAI）之上，你依赖的是服务商自身的隔离保证。如果你运行的是自托管推理（如 vLLM、TGI），你则需要完全承担这个问题。

将成本归因作为一等公民功能

将每个 LLM 调用通过中心化网关路由的意义在于，你可以获得单一的结构化遥测流。每个请求至少应标记：租户/团队 ID、模型名称、输入 Token 数、输出 Token 数以及衍生出的预估成本。

衍生成本非常重要。服务商会调整价格。一个存储原始 Token 计数的网关可以在任何定价方案下追溯性地重新计算成本。而一个仅存储美元金额的网关，在你下次重新谈判合同或更换服务商时，得到的数据就会出错。

在组织层面，这些数据应该流入你的内部成本管理系统，而不仅仅是一个平台团队每月查看一次的仪表盘。运行费用分摊（chargeback）的财务团队需要一种程序化的方式来按账期拉取每个团队的支出。产品团队需要了解每个功能的成本可见性，以判断新的 AI 功能在经济上是否可行。中心化网关正是这些数据的源头。

规模化过程中出现的隐藏复杂性

为少数几个团队运行网关是比较简单的。复杂性主要积累在两个地方。

分布式限流执行是第一个。如果你的网关以单实例运行，限流是非常简单的——每个租户一个内存计数器即可。一旦你为了冗余或吞吐量运行多个网关实例，这些计数器就需要同步。常见的解决方案是使用共享 Redis 存储计数器状态，并进行原子自增操作。隐藏的代价是：每个请求现在都需要一次到 Redis 的网络往返，增加了几毫秒的开销。在高负载下，Redis 会成为瓶颈和新的故障域。

跨服务商的 Schema 标准化是第二个。OpenAI、Anthropic、Google、Mistral 和 Cohere 的请求/响应结构各不相同，Token 计数行为不同，且暴露的功能集也不同。一个在内部将所有这些抽象为统一 API 的网关，必须维护针对每个服务商的转换逻辑。当服务商更新其 API 时（这种情况发生的频率比大多数团队预期的要高），该服务商的网关功能就会中断，直到转换层完成更新。自行构建网关的团队往往低估了紧跟服务商 API 变化的维护负担。

这两个复杂性是成熟团队倾向于采用维护良好的开源网关（截至 2026 年，LiteLLM 是部署最广泛的）或商业网关，而不是从零开始构建的主要原因。单是服务商兼容性的覆盖范围就足以成为一项兼职工作。

根据你的实际风险状况匹配网关深度

并非每个团队都需要完整的堆栈。一个有用的启发式方法：

如果你只有一个产品团队在使用单一服务商，那么租户级隔离还为时过早。正确的做法是为所有请求标记元数据，并记录到成本归因仪表盘。

如果你有多个拥有独立预算的团队，那么带有层级支出上限的虚拟密钥隔离是最小可行方案。预算超限应该拦截请求，而不仅仅是发送警报。

如果你正在构建一个 LLM 调用按客户计费的 SaaS 产品，那么从一开始就将虚拟密钥视为客户范围的凭据。在没有考虑到租户隔离的网关中后期补丁，要比从头设计难得多。

如果你每天运行超过 1000 万个 Token，并且对可用性有合同承诺，那么具备健康感知路由的服务商故障转移将成为基础设施的刚需，而不再是可有可无的选项。

所有这些的核心原则是：网关的工作是让 LLM 层对堆栈的其余部分保持透明。服务中断停留在网关层。成本数据在无需工程干预的情况下流向财务。新服务商被添加到抽象层之后，无需更改应用程序代码。这才是值得构建的运营成果。