AI 应用的多租户架构与配额系统工程 2026
把 LLM 多租户配额形式化为四维约束 (R/T/C/K),用 DRF 公平调度 + token bucket / sliding window 双层限流 + reasoning token 差异化计费,把租户 SLA 从承诺变成可观测可审计的工程系统。
约 19 分钟阅读5,419 字7 次阅读博主
把 LLM 多租户配额形式化为四维约束 (R/T/C/K),用 DRF 公平调度 + token bucket / sliding window 双层限流 + reasoning token 差异化计费,把租户 SLA 从承诺变成可观测可审计的工程系统。
多租户 LLM 应用的配额系统，本质是在成本、公平、抢占三个互斥目标之间寻找工程妥协——用四维约束 + DRF 公平 + 实时计量回写，把租户 SLA 从承诺变成可观测可审计的工程系统。
把一个大模型应用开放给多个企业客户使用，看起来只是一个"加一层认证"的工程小事，但当第一个企业客户的月账单从预估的 800 美元跳到真实出账的 7400 美元时，工程师才意识到：LLM 时代的"多租户"和传统 SaaS 的多租户是两个完全不同的物种。传统 SaaS 的多租户隔离围绕数据库行级权限、CPU 配额、网络带宽展开；LLM 多租户隔离围绕"token 不可分割"+"推理算力非弹性"+"成本与延迟强耦合"三个新维度展开——而这三个维度互相拉扯，无法同时最优。
第一个张力来自 成本失控。同一个 API key 后面可能挂着一个 10 人小团队和一个 200 人客服中心，两个团队共享 100 万 token/天的配额预算，但客服中心 80% 的请求发生在 09:00-11:00 的早高峰，剩下的配额留给小团队"半夜写文档"几乎没用；如果按"先到先得"调度，小团队几乎永远拿不到 token；如果按"平均分摊"，客服高峰时段又会出现严重排队。第二个张力来自 公平抢占：当一个高优先级付费租户的请求和一个免费试用租户的请求同时到达网关，限流器该拒绝谁？按"价格歧视"固然能优化营收，但企业级 SLA 合同往往要求"99% 请求不被拒绝"，价格歧视并不能解决突发性抢占问题。第三个张力来自 配额审计：当一个企业租户的合同承诺是"月均成本不超过 5000 美元、突发允许 1.5× 但不超过 7500 美元"，平台如何在月底出账时证明这个数字？没有"逐请求 token 级成本 + 公平性度量 + 时间窗聚合"的三件套，账单向客户解释时只能"差不多"。
这三个张力的形式化本质可以用一句话概括：多租户 LLM 应用需要同时满足成本有界性（cost boundedness）、公平抢占性（fair preemption）、配额可审计性（quota auditability）这三个互斥目标。本文将围绕这三个目标的工程实现展开：从形式化建模到限流算法，从调度器架构到成本计量回写，从可观测性到案例研究，最后给出 9 条可执行上线清单。
在进入工程实现之前，先把"配额"这个口语化的词形式化为可计算的数学对象。一个完整的 LLM 多租户配额系统需要维护四个独立维度的约束，记为 四元组：
其中 是每分钟请求数（requests per minute）， 是每分钟 token 数（tokens per minute，区分 prompt 和 completion）， 是并发槽位数（concurrent slots）， 是单窗口成本上限（cost ceiling，单位美元/小时或美元/天）。这四个维度互相不正交：一个 8000 token 的长上下文请求在并发维度只占 1 槽，但在 token 维度却吃掉了 8000/60000 ≈ 13% 的分钟配额；如果同时来 8 个这样的请求，concurrent 没超但 TPM 已爆。
四个维度的形式化之后，下一步是定义"公平性"。在多租户场景里，最常用的两个公平理论是 max-min fairness 和 weighted max-min fairness（DRF, Dominant Resource Fairness）。Max-min fairness 保证"任何租户的配额提升都不能以牺牲另一个配额更低的租户为代价"，但它假设所有租户的需求同构——这对 LLM 场景不成立，因为有的租户是高频短问（chatbot），有的是低频长推理（code generation）。DRF 由 Ghodsi 等人在 2011 年提出（参考文献 [1]），核心思想是：每个租户在所有资源维度上有一个"主导份额"（dominant share），调度器保证所有租户的主导份额相等。在 LLM 多租户场景下，租户 在维度 上的份额是 ，主导份额是 ，DRF 调度器保证 。这个形式化在 LLM 场景的妙处在于：它把"长上下文租户"和"高频短问租户"的资源结构差异自动吸收，不需要手动给每类租户配不同的权重——但代价是需要在网关层实时计算每个租户的主导份额，开销不可忽略。
第三个形式化对象是 SLA 的反向约束：传统 SLA 写成"99% 请求延迟 < 2 秒"，但 LLM 场景下"延迟"由租户的 TPM 配额决定——配额给得越少，排队越长，延迟越高。因此 SLO 反向约束 应该写成 "在租户 的 TPM 配额 下，期望尾延迟 "——配额系统需要回答"如果我给租户 5 万 TPM，期望 P99 延迟是多少？"这个反问题，这要求调度器内置一个轻量的排队论模型（M/G/c 队列的 Kingman 近似）。
配额系统最容易被低估的环节是 租户识别——准确地说，是从一次 HTTP 请求里反推"这个请求属于哪个租户、用的是什么计费方案、应该走哪条限流路径"的语义链。这条语义链的工程形态在生产环境往往是 API Key → JWT claim → tenant_id → plan_id → quota_policy_id 的五跳映射，每一跳都可能出错。
第一跳是 API Key 验证：当请求到达网关时，网关从 Authorization: Bearer sk-xxx 头里抽取 key，去 key 存储里查出对应的 tenant_id。这一步的工程难点是 key 的旋转：长期 key 被泄露的风险高，平台通常支持"主 key + 多 sub-key"模式，让企业管理员可以给不同部门发独立 sub-key、随时吊销单个 sub-key 但保留主 key。生产实践是 key 存储用 Redis 集群 + 主从同步，吊销延迟 < 5 秒。
第二跳是 JWT claim 解析：当请求不是 API Key 形态而是 OAuth/JWT 形态（比如企业 SSO 集成），网关需要从 JWT 的 sub、tenant、org 等自定义 claim 里提取租户信息。这里有个工程陷阱：JWT 的 sub 通常是用户级 ID，不是租户级 ID——必须用 JWT 的 tenant 或 org claim 区分；如果 JWT 里没有这两个 claim，平台默认按"个人开发者"处理，配额走最低档 plan。
第三跳是 tenant_id 到 plan_id 的映射：一个企业租户可能购买多个 plan（比如基础 plan 给全员 + Pro plan 给研发组），网关需要从请求 URL 路径或 header 里判断"这个请求属于该租户的哪个 plan"。常见做法是在请求 URL 里带 ?plan=pro 或自定义 header X-Plan-Id。
第四跳是 plan_id 到 quota_policy_id：每个 plan 对应一个 quota policy 对象，包含上文的 四元组 + 公平权重 + 突发容忍度。policy 对象通常是 JSON 形态，存在 Postgres 表 quota_policies 里，由运营后台 CRUD。
第五跳是 quota_policy_id 到实际限流配置：网关加载 policy 对象，把四元组翻译成 token bucket 的 refill rate + burst capacity + concurrent semaphore 的 permit 数。这一步是工程实现的关键，下面第四章展开。
租户识别还有一个微妙问题：多租户 vs 单租户多用户的语义边界。本文用"租户（tenant）= 计费主体"，"用户（user）= 终端使用者"。一个企业租户内部可能有几千个用户，但所有用户的 token 用量合并到租户配额下——这叫"池化（pooling）"。有的企业合同要求"每个用户独立配额、不能池化"——这叫"隔离（isolation）"。平台需要支持这两种模式，配置在 plan 的 quota_mode: "pooled" | "isolated" 字段里。池化和隔离对配额系统的工程影响是结构性的：池化只需要维护一个租户级计数器，隔离需要为每个 (tenant, user) 对维护一个独立计数器，存储开销是 。
限流（rate limiting）是配额系统的执行层，但 LLM 场景下的限流比传统 HTTP 限流复杂得多，原因有三：(1) token 维度不可分割，一个请求可能吃 100 token 也可能吃 8000 token；(2) 请求突发性更强，客服中心在早高峰的瞬间并发可能是平峰的 10-50 倍；(3) 推理延迟高（首 token 200ms-2s），滑动窗口的窗口长度必须比传统 HTTP 长一个数量级。
最常用的三个原语是 token bucket（令牌桶）、sliding window（滑动窗口）、leaky bucket（漏桶）。三者各有适用场景：
Token bucket 的核心是一个容量为 的桶，每 秒注入一个令牌，请求到达时如果桶里有令牌就放行并扣 1 个，否则拒绝。它的优点是允许突发（burst）——只要桶里有令牌，瞬时并发可以超过平均速率的 2-3 倍，这对 LLM 用户体验很关键（用户不会均匀发问，往往一波密集一波沉寂）。缺点是无法表达"过去 N 分钟平均"语义——一个桶满的租户可以在 1 秒内发完所有配额，剩下的 59 秒空跑。
Sliding window 把时间切成 个长度为 的小窗口，每个小窗口独立计数，请求到来时检查"过去 时间内的总数是否超限"。它的优点是严格限制过去窗口的平均值，缺点是窗口边界处的二倍超额：一个租户可以在窗口 1 的最后一秒和窗口 2 的第一秒各发满配额，瞬时 2 秒发完 配额。生产实践是用 sliding window log + 滑动窗口计数器 混合：前 N 秒的精确日志 + 当前窗口的累加器，复杂度 ，但内存开销线性增长。
Leaky bucket 把请求看成水滴，桶以恒定速率漏水，请求到达时如果桶满了就拒绝。它的优点是输出严格平滑（对后端 LLM 服务的压力恒定），缺点是不允许任何突发——这在 LLM 场景下用户体验差，因为用户的真实交互模式是突发的。
LLM 场景下的工程实践是 token bucket 做主限流 + sliding window 做审计：token bucket 负责"实时是否能放行"，sliding window 负责"过去一分钟 TPM 是否超限"。两者的协同点是：token bucket 检查 两个维度，sliding window 检查 两个维度，请求同时通过两个检查才能进入推理队列。这种双层结构在 LangChain 的 langchain-core/rate_limiters.py 和 LiteLLM 的 litellm/router_utils.py 里都有实现（参考文献 [2][3]）。
更进一步的生产实践是 自适应限流——根据实时排队长度和推理服务的 GPU 利用率动态调整限流参数。简单做法是用 指数移动平均（EMA） 平滑最近 100 个请求的实际 token 用量，把"用户声明需要 1000 token 但实际用了 3000 token"的情况自动收紧配额：，其中 是实际均值。更复杂的做法是引入 排队论 M/G/c 模型的 Kingman 近似：
其中 是服务利用率， 是服务台数（GPU 数）， 和 分别是到达间隔和服务时间的变异系数（CV）。Kingman 公式告诉我们：当 接近 1 时， 急剧上升——这是限流系统的"甜蜜点"，把利用率控制在 0.7-0.85 区间是工程最优。
限流算法决定"单个请求能否放行"，但配额调度器决定"整个请求流的形态"——是统一网关集中决策，还是 LangChain middleware 分散决策，还是 Envoy/Istio sidecar 在代理层决策。三种架构各有取舍，下面分别分析。
架构 A：统一 API Gateway 集中调度。这是 OpenAI 官方 API、Anthropic API、Google Vertex AI 采用的主流架构。所有请求先打到网关层（往往是一个全球部署的 L7 代理集群），网关集中维护所有租户的 quota policy、token bucket 状态、cost 计数；网关后才是 LLM 推理集群（往往跨多个区域的 GPU 池）。优点是 全局一致性——一个租户在全球任何区域发请求，配额都共享同一个计数器，避免"东京区配满了但弗吉尼亚区还有配额"的撕裂。缺点是 网关成为单点——所有请求都要过网关一次，网关延迟直接影响端到端延迟；而且网关的状态存储（Redis 集群）规模庞大，运营成本高。OpenAI 的网关据公开工程博客描述用自研的 "Quota-as-a-Service" 系统支撑每秒百万级请求（参考文献 [4]）。
架构 B：LangChain Middleware 分散调度。在应用代码层嵌入 LangChain 的 middleware chain，每个 middleware 可以决定"是否拦截当前请求"、"是否降级到备用模型"、"是否注入 prompt 重写"。优点是 业务灵活——应用可以针对自己的业务场景自定义限流逻辑，比如"VIP 用户始终优先"、"免费用户周末双倍配额"。缺点是 全局视角缺失——一个应用的多个实例各自维护限流状态，跨实例共享需要外部存储（Redis），延迟和一致性成本都增加。LangChain 1.0 在 langchain-core/rate_limiters.py 里提供了 InMemoryRateLimiter 和 BaseRateLimiter 抽象接口，但跨实例共享留给用户实现（参考文献 [2]）。
架构 C：Envoy/Istio Sidecar 代理层调度。在每个应用 Pod 里注入一个 Envoy sidecar，sidecar 从集中配额服务（往往是一个独立的 gRPC 服务）拉取 quota policy，对进出 Pod 的所有 LLM 请求做统一限流。优点是 与语言无关——任何语言的应用都可以用 sidecar 模式获得配额能力，不需要修改业务代码；而且 sidecar 在 L7 代理层做限流，可以无侵入地支持任何 LLM SDK（OpenAI / Anthropic / Cohere）。缺点是 运维复杂——sidecar 注入需要 Istio 或 Linkerd 这类服务网格，每个 Pod 多一个容器，资源开销 50-100MB 内存 + 5-10% CPU。生产实践是用 eBPF + cilium 替代 Envoy sidecar，把限流逻辑下沉到内核态，进一步降低开销。
三种架构的选型没有绝对优劣，但有一个经验法则：请求量 < 100 RPS 的中小应用，架构 B（LangChain middleware）性价比最高；请求量 100-10000 RPS 的中等应用，架构 A（统一网关）是工业标准；请求量 > 10000 RPS 的大型应用，架构 C（sidecar）+ 架构 A（全局网关）的组合是必然选择。本文将在第八章用 Cursor、Notion AI、Replit 三家公司的公开工程实践验证这个经验法则。
配额系统的另一个核心职责是 成本计量——把每个请求消耗的 token 转换为美元数字，让运营能月底出账单。看起来简单，但工程实现里有三个深坑。
第一个深坑是 function calling 的隐藏 token 开销。OpenAI 的 function calling 模式下，每次请求的 token 不仅包含用户输入 + 模型输出 + 系统 prompt，还包含 function schema 描述（往往 200-500 token）+ 函数调用的 JSON 参数（往往 100-300 token）+ tool result 回传（往往 50-200 token）。这意味着一个看起来"用户输入 100 token"的简单请求，实际总 token 可能 800-1500。生产实践是用 tiktoken 库精确计算每段文本的 token，而不是依赖 API 返回的 usage.total_tokens——后者只在请求完成时才返回，无法做实时成本告警（参考文献 [5]）。
第二个深坑是 reasoning token 与 thinking token 的差异化计费。OpenAI o1 / o3 系列和 Anthropic Claude 3.7 Sonnet 的 "extended thinking" 模式引入了 reasoning token（也叫 thinking token）——这些 token 用户看不到、模型用做内部推理，但计费权重是普通 output token 的 3-5 倍。Anthropic 的官方定价表显示 Claude 3.7 Sonnet 的 thinking token 单价是 15/M tokens 的 4 倍。配额系统必须区分 prompt / completion / reasoning 三类 token，分别记账。LiteLLM 的 completion_cost() 函数在 v1.50+ 开始支持 reasoning token 的差异化计费（参考文献 [3]）。
第三个深坑是 跨模型路由与成本归一化。当应用同时使用 OpenAI GPT-4o、Anthropic Claude 3.5 Sonnet、Google Gemini 1.5 Pro 三个模型时（典型的模型路由架构），每个模型的定价不同：GPT-4o input 10/M；Claude 3.5 Sonnet input 15/M；Gemini 1.5 Pro input 5/M。如果平台只按"总 token 数"对客户计费，会出现"用 Gemini 的客户付同样 token 价但成本低"的毛利率压缩；如果按"模型 × token 单价"分别计费，账单的复杂度飙升——客户希望看到一个统一的"等效 GPT-4o token"指标。生产实践是引入 等效 token 概念：定义 1 GPT-4o-completion-token = 1 等效 token，1 Claude-completion-token = 1.5 等效 token（因为 Claude 更贵），1 Gemini-completion-token = 0.5 等效 token。客户看到的是"等效 token 用量 × 单价"，平台内部仍按真实模型成本核算毛利率。
成本回写到账单的工程链路是：每个 LLM 请求 → 网关拦截 response.usage → 累加到租户级 counter（Redis HINCRBY）→ 每小时一次 batch job 把 counter 持久化到 Postgres usage_records 表 → 月底 SQL 聚合 + 出账 PDF。Redis counter 的工程要点是 TTL 设置：一个租户的 usage counter 应该在窗口结束后过期（比如月度窗口的 counter 在下月第一天清零），避免 Redis 内存无限增长。
传统可观测性三大支柱（metrics / logs / traces）在 LLM 多租户场景下需要扩展一个租户专属维度——每一个 metric、log、trace 都必须带上 tenant_id 标签，否则多租户的运营洞察无从谈起。本文提出四个租户专属可观测性维度：
维度 1：per-tenant 实时 token 用量仪表盘。运营 dashboard 上有一个面板，按租户展示过去 1 小时 / 24 小时 / 7 天的 prompt token / completion token / reasoning token / cost 四条曲线。当一个租户的 cost 曲线斜率突然变陡（从 30/h），dashboard 触发告警，运营人工介入排查。Helicone、Langfuse、Portkey 三个开源 / 商业产品都提供这个维度的 dashboard（参考文献 [6][7][8]）。
维度 2：per-tenant 公平性度量。传统 SaaS 用 Gini 系数衡量资源分配的公平性，LLM 多租户场景同样适用。具体做法是每小时计算一次 per-tenant token 实际使用 / 配额的比值，用 Gini 系数衡量这个比值在所有租户间的分布均匀程度。如果 Gini > 0.3，说明租户间严重不均衡——某些租户配额富余浪费，另一些租户配额紧张被限流。运营可以基于 Gini 系数做 配额再平衡（quota rebalancing）：把低利用率租户的配额部分回收，重新分配给高利用率租户。这是 DRF 公平理论的工程实现。
维度 3：per-tenant SLA 反向追踪。每个租户的 SLO（比如 "P99 延迟 < 2s, 月度成本误差 < 10%"）都应该有一个反向追踪链路——当某个月某租户的 SLO 失败时，能精确指出"失败发生在哪个时间窗、哪个模型、哪个 prompt 类型"。这要求 trace 系统在每条 LLM 调用 trace 上带 tenant_id + plan_id + quota_decision（accepted / rate_limited / budget_exceeded）三个关键标签。OpenTelemetry 的 LLM semantic conventions（2024 年定稿）已经把 gen_ai.* 一系列标签标准化，平台只需要在 trace SDK 里透传这些标签（参考文献 [9]）。
维度 4：per-tenant 配额决策审计日志。每次配额决策（接受 / 限流 / 降级 / 路由到备用模型）都应该写入一条审计日志，字段包括 timestamp、tenant_id、decision_reason、token_usage_actual、token_usage_declared、quota_policy_snapshot_id。月底客户审计时，可以导出该租户的决策日志，让客户验证"我的请求是不是被公平调度"。这个维度的工程成本不高但客户信任度提升巨大——一个能导出审计日志的平台和一个只能给"差不多"账单的对比，赢率显著不同。
四个维度共同回答了第二章提出的三个互斥目标：维度 1 解决成本可控性、维度 2 解决公平性、维度 3+4 解决可审计性。这三个目标不再互斥，而是被可观测性系统同时承载。
本章用三家公司的公开工程实践（Cursor 2024-2025 工程博客、Notion AI 工程团队分享、Replit 多租户架构演讲）对比多租户 LLM 应用的三种典型策略。
Cursor：架构 A（统一网关）+ 架构 B（IDE 端 middleware）混合。Cursor 的产品形态是 IDE 插件，每个用户的代码补全请求通过 Cursor Cloud 中转再到 LLM API。根据 Cursor 2024 年的工程分享（参考文献 [10]），他们采用了 统一网关集中配额 + IDE 端本地缓存 的混合架构：所有用户的配额状态集中在云端 Redis 集群，避免多实例不一致；但高频重复的代码补全请求（"光标后第 N 个字符补全"）在 IDE 端本地缓存，避免无谓的配额消耗。这种混合架构的优点是 延迟低（IDE 端缓存命中 < 10ms 响应）+ 全局一致（缓存 miss 的请求走云端配额）。缺点是 缓存一致性复杂——同一个 prompt 在不同用户 IDE 上的缓存不能共享，因为代码上下文敏感。
Notion AI：架构 A（统一网关）+ 自研 quota rebalancing。Notion AI 是嵌入 Notion 文档的 AI 助手，所有请求走 Notion 自研的统一网关。根据 Notion 2024 年工程博客（参考文献 [11]），他们的差异化点是 quota rebalancing 自动化：Notion AI 的定价是 per-seat 订阅（每个 workspace 用户每月 30 的 token，一个轻度用户只用 10 等效 token，但实际高活跃用户可能用 0.30，需要在 ToS 里写清楚。
Replit：架构 C（sidecar）+ 模型路由。Replit 的产品形态是云端 IDE + AI 编程助手，每个用户的代码运行在自己独立的 container 里。根据 Replit 2025 年的多租户架构演讲（参考文献 [12]），他们用 Envoy sidecar + 自研模型路由器 架构，每个 container 注入一个 Envoy sidecar，sidecar 从集中的配额服务拉 quota policy，同时根据 prompt 类型路由到不同模型（代码补全走 Codestral、对话走 Claude、文档生成走 Gemini）。这种架构的优点是 隔离强——每个 container 的配额严格独立，不存在"高负载用户拖累低负载用户"的问题；而且模型路由在 sidecar 层透明完成，应用代码不需要感知多模型。缺点是 运维复杂 + 资源开销——每个 container 多一个 sidecar，整体资源开销 10-15%。
三家公司的策略对比印证了第五章的结论：Cursor 是中小规模混合、Notion AI 是中等规模统一网关、Replit 是大规模 sidecar + 网关组合。没有"最优"架构，只有"最匹配业务规模"的架构——这是多租户 LLM 应用架构选型的最重要工程经验。
把上文九个章节的工程经验浓缩为 9 条上线前必看清单：
tenants 表注释里；多租户 vs 单租户多用户的边界要画清楚（参考第三章）。这 9 条清单覆盖了本文 90% 的工程要点。任何一条没做到，都意味着上线后大概率要返工——多租户 LLM 应用的返工成本是初版设计成本的 3-5 倍，因为要重新发版网关、重新发版计费、重新发版审计日志。
Conversation
0 条