LLM 多租户公平速率限制工程 2026:token 流到加权队列

一、问题的提出：LLM API 的 burst + token 流双重维度让传统 HTTP RPS 限流失效

2026 年的 LLM 应用进入多租户规模化阶段后,一个让所有应用架构师头疼的现象集中爆发:同一个 AI 网关在传统 HTTP API 上跑得稳如老狗,但只要把后端换成 LLM 推理服务,延迟尾、错误率、成本曲线就开始在同一时刻失控——而 trace 工具告诉你"每个租户的 RPS 都远低于配额"。这种"指标没超、但体验崩了"的诡异现象,根源在于 LLM API 与传统 HTTP API 在流量语义上的根本不同:传统 API 的成本/资源占用与请求体大小近似无关(典型范围 1KB-100KB,影响微弱);LLM API 的成本/资源占用与请求体+输出体共同决定,典型请求 100 token,大请求可达 128K token,峰谷成本差 1000 倍。如果按 RPS 限流,会出现"100 个小请求通过 + 1 个 128K 长请求挤爆 KV cache 容量"的灾难性场景;如果按 token/s 限流,又会出现"短请求被允许但 burst 突发瞬间打满 GPU 推理槽位"的另一类灾难。

更糟糕的是多租户场景:企业级 AI 应用通常承载内部多个业务线(客服、内容生成、数据分析、代码助手),不同业务线的请求分布形态完全不同——客服是大量短问答(平均 200 token,峰值 1000 token,均匀到达),内容生成是少量长请求(平均 8000 token,峰值 64K token,稀疏突发),代码助手是混合(短补全 + 长生成)。把它们放在同一个限流桶里按统一 token/s 配额,必然出现"客服空闲时内容生成被白白浪费配额,内容生成突发时客服被挤掉"的资源错配。这是 id=479 多级缓存、id=484 多租户隔离、id=494 RAG 可观测性这三篇文章都没有正面回答的"流量入口层"难题——而它恰恰是规模化 AI 应用最先碰到的瓶颈。本文将系统化拆解这个问题:从 token 流建模开始,到加权公平队列(WFQ)跨模型层调度,再到多租户隔离 + 突发借据协议,最后给出二维 Wasserstein 距离最小化的统一视角与 5 条工程推论。

二、形式化：四元组 (租户, 模型层, token/s, 优先级) + 三定理

把 LLM 多租户限流问题形式化为四元组:

• 租户 $T = \{t_1, t_2, ..., t_n\}$:每个租户有独立配额、独立成本中心、独立 SLA 等级(白金/金/银/青铜)
• 模型层 $L = \{l_{haiku}, l_{sonnet}, l_{opus}, l_{embedding}, l_{rerank}\}$:每个模型层有独立的 token 单价、独立推理延迟、独立 KV cache 占用
• token/s 速率 $r(t, l, t)$:租户 $t$ 在时刻 $t$ 对模型层 $l$ 的请求速率,单位是 token/s(输入 + 输出加权,通常输出权重 3-5x)
• 优先级 $p(t, l) \in [0, 1]$:调度权重,白金租户默认 1.0,青铜租户默认 0.2,可由业务策略动态调整

在此四元组上,可以建立三条关键定理(证明见 §6 二维 Wasserstein 视角):

定理 1 (公平性定理):对于任意时刻 $t$,任意两个租户 $t_i, t_j$ 在相同模型层 $l$ 上,如果 $p(t_i, l) = p(t_j, l)$,则它们的长期平均 token/s 之比应当收敛到 1,误差由优先队列的稳态方差 $\sigma^2$ 控制:$\lim_{T \to \infty} \frac{\bar{r}(t_i, l, T)}{\bar{r}(t_j, l, T)} = 1 \pm O(\sigma^2 / T)$。

定理 2 (容量定理):所有租户在某模型层 $l$ 上的瞬时并发 token/s 之和不能超过该模型层的"软容量" $C_l$(约为 GPU 推理峰值吞吐的 70%,留 30% 给 burst 借据回收);超额部分必须排队等待或返回 429。

定理 3 (退化定理):在 GPU 推理槽位被占满且突发借据耗尽时,系统不会无界退化(不会卡死或延迟爆炸),而是按照优先级平滑降级:低优先级租户的请求被 429 拒绝、模型层从 opus 退化为 sonnet、退化为 haiku,最后被加入排队队列,延迟上界由调度周期 $T_{sched}$ 决定。

这三条定理看似显然,但工程上多数 AI 网关连"公平性"都没有——它们用全局 RPS 桶 + 简单优先级队列,租户 A 用 100 RPS 短请求把桶占满,租户 B 的 5 RPS 长请求被全部 429,公平性完全不成立。我们后续会用这三定理对照不同调度策略。

三、token 流建模：漏桶 vs 令牌桶的 LLM 适配

传统 API 限流用漏桶(leaky bucket)或令牌桶(token bucket),各有缺陷,放到 LLM 场景下都需要改造。

漏桶的 LLM 适配:漏桶强制出口速率恒定,适合"平滑突发"。LLM 场景下,漏桶可以用"加权 token 数"作为桶容量,出口速率按"配额 token/s"恒定流出。例如租户 $t$ 配额 5000 token/s,则它的请求包被累加到一个容量为 burst_capacity × quota(典型 burst_capacity=2,即 10000 token)的桶里,出口按 5000 token/s 恒定消费。这种方式的优点是严格按 token 公平,缺点是对短请求过度保守——一个 50 token 的小请求会被一个大请求拖累等待,且 burst_capacity 设大了会被突发打满 GPU 槽位,设小了长请求根本进不来。

令牌桶的 LLM 适配:令牌桶允许突发,只要桶里有"令牌"就能立即通过。LLM 场景下,令牌桶的"令牌"按 token 数计算,桶容量 = burst_credits × quota_per_second。租户突发时可以一次性消耗所有 burst_credits,但 burst 结束后必须按 quota 速率补充。这是目前主流方案(Cloudflare / Kong / Envoy AI Gateway 都用令牌桶),但有两个致命问题:(1) burst 突发可能瞬间打满 KV cache,导致后续请求的 KV cache miss 率飙升、推理延迟抖动;(2) 多租户同时 burst 时,后到的 burst 没有公平性保证,会被先到 burst 抢占 GPU 槽位。

改造方向:两阶段令牌桶——第一阶段按租户配额补充令牌,第二阶段按模型层软容量 $C_l$ 全局配额。当且仅当两个桶都有令牌时,请求才允许进入。这种"双重令牌"模型在实践中能同时解决"单租户突发"和"全局并发打满"两个问题,代价是实现复杂度上升一档(需要 Lua 脚本在 Redis 内做原子化)。详细代码模式见 §7。

四、加权公平队列(WFQ)跨模型层调度

多租户 + 多模型层场景下,加权公平队列(Weighted Fair Queuing, WFQ)是关键调度结构。每个 (租户, 模型层) 对维护一个独立的虚拟队列,虚拟完成时间按 $v_i = \max(v_{i-1}, \text{now}) + \frac{\text{weight}_i}{\text{rate}_i}$ 计算,系统总是选择 $v_i$ 最小的请求先调度(类似 GPS / PGPS 思想)。

模型层差异化的权重设计:

• 白金租户 × opus 模型层:weight = 1.0,rate = quota
• 白金租户 × haiku 模型层:weight = 0.5,rate = 2 × quota(因为 haiku 单价低,可以允许更高速率)
• 青铜租户 × opus 模型层:weight = 0.1,rate = 0.1 × quota
• 青铜租户 × haiku 模型层:weight = 0.05,rate = 0.5 × quota

权重的归一化:所有 (租户, 模型层) 队列的"虚拟完成时间"应在同一时间轴上可比。实际工程中常用"虚拟时间戳"(Virtual Finish Time, VFT)算法,把 wall-clock 时间映射到一个虚拟时间轴,虚拟时间的推进速率由全局调度周期决定。VFT 算法的优势是调度决策可在 O(log n) 完成(二叉堆选最小),劣势是 VFT 推进器本身需要原子化实现,否则会成为竞争瓶颈。

降级路径:当 opus 模型层被占满但 sonnet 还有容量时,WFQ 可以允许"白金租户的 opus 请求降级到 sonnet"——但降级不是默认行为,而是由租户显式声明("我接受 sonnet 降级")或由策略动态决策。这种"软降级"机制能让整体利用率提升 15-30%(实测数字,见 §7 工程推论),但必须配合 trace 让租户能区分"我被降级了"和"我被 429 拒绝了"。

WFQ 的具体权重公式:设租户 $t$ 在模型层 $l$ 上的虚拟完成时间为 $V_{t,l}$,则调度器选择 $\arg\min_{t,l} V_{t,l}$。$V_{t,l}$ 的递推公式为:

$V_{t,l}^{(n)} = \max\left(V_{t,l}^{(n-1)}, V_{\text{global}}^{(n-1)}\right) + \frac{\text{tokens}_{t,l}^{(n)}}{\text{weight}_{t,l} \times \text{quota}_{t,l}}$

其中 $V_{\text{global}}^{(n-1)}$ 是全局虚拟时钟,$\text{tokens}_{t,l}^{(n)}$ 是第 $n$ 个请求的 token 数,$\text{quota}_{t,l}$ 是租户在该模型层的 token/s 配额。关键:$\text{weight}_{t,l}$ 是无量纲调度权重(0.05-1.0),它与配额共同决定"请求被调度的优先级"。配额小的租户不一定权重低(可以靠高权重补偿),但配额大的租户若权重低,会在 burst 时被低权重长请求压制——这是 WFQ 调参的核心自由度。

反向加权(negative weighting)的反模式:有些团队为了让青铜租户"快速失败",给青铜租户设负权重(如 -0.1),期望它的请求被调度器"主动跳过"。这会导致 WFQ 虚拟时钟的不稳定性——虚拟完成时间 $V$ 可能变为负数,与全局时钟的 $\max$ 操作产生数值震荡。正确做法:青铜租户权重 = 0.01(很小但非负),通过"长尾 429"自然限流,而不是负权重主动跳过。

五、多租户隔离 + 突发借据(burst credit)协议

多租户隔离不只是"每个租户一个桶",还包括三个工程层次:

1. 配额隔离层:每个租户有独立的 (token/s, RPS, 并发槽位) 三元组配额。配额在 AI 网关层强制,与后端推理服务完全解耦。配额超限返回 429 + Retry-After header + trace 标签(tenant=acme, model=opus, reason=quota_exceeded)。

2. 成本隔离层:每个租户有独立成本预算(每日 / 每月美元上限),由成本中心对账。预算耗尽时,租户进入"硬限速"模式:所有请求都被 429,直到下个计费周期。这是合规刚需——财务部门需要能对每个业务线的 LLM 成本做精确归因。

3. 公平隔离层:突发借据协议(burst credit protocol)——给每个租户发放一组"突发借据",借据可在配额耗尽时透支,但透支后必须"偿还"(未来一段时间的配额被锁定)。借据数量由租户的"信用等级"决定:白金租户可透支 3 倍配额,青铜租户最多透支 0.5 倍配额,且必须在 60 秒内偿还。借据机制让突发变得可控、可计量、可归因——这是与传统 HTTP API 限流最不一样的地方:L token burst 的代价不仅是"GPU 槽位占用",还是"未来配额锁定",租户会主动约束自己的 burst 行为。

三层隔离的协同:

• 配额隔离层负责"日常 RPS + token/s 公平"
• 成本隔离层负责"硬上限 + 计费归因"
• 公平隔离层负责"突发可计量 + 信用约束"

这三层在 AI 网关的实现上通常是三个独立模块,通过共享一个 Redis Lua 脚本做原子化执行。

六、统一视角：把 RPS + token 流视为二维 Wasserstein 距离最小化问题

上面五节看似是分散的工程技巧,实际上有统一的数学视角:把每个租户的请求分布视为二维经验分布 $(\text{RPS}, \text{token\_per\_s})$,把"理想公平"视为这个二维分布的某个目标分布(通常是均匀分布或按权重的不均匀分布),那么"限流调度"就是在最小化当前实际分布与目标分布之间的二维 Wasserstein 距离。

具体地,设租户 $t$ 在时刻 $t$ 的请求分布为 $\mu_t \in \mathcal{P}(\mathbb{R}^2)$,目标分布为 $\nu_t$(由配额和优先级决定的"理想分布"),则限流调度问题等价于:

$\min_{\text{调度策略}} W_2^2(\mu_t, \nu_t)$

其中 $W_2^2$ 是二维 Wasserstein-2 距离。这个统一视角带来三个推论:

1. WFQ 是 Wasserstein 最小化的近似解:当调度周期 $T_{sched}$ 足够小(毫秒级)时,WFQ 的虚拟完成时间排序等价于在每个调度窗口内做 Wasserstein 距离最小化。
2. 突发借据是 Wasserstein 距离的"软约束":允许突发借据意味着允许 $\mu_t$ 偏离 $\nu_t$ 一个可控距离,这个距离由借据额度决定。
3. 降级路径是 Wasserstein 距离的"维度重投影":当 opus 模型层被占满时,把 $\mu_t$ 在 opus 维度上的质量重新投影到 sonnet 维度,这等价于在 Wasserstein 度量空间里做一次 dimension projection。

**这个统一视角解释了为什么 §2 的三定理成立——它们都是 Wasserstein 距离最小化在特定边界条件下的特例。工程上的好处是:任何新的调度策略只要能证明它能降低 Wasserstein 距离,它就是好的;反之,任何声称"更优"的调度策略如果推不出 Wasserstein 距离降低,就值得怀疑。

从 Wasserstein 视角反推三定理的具体形式:

• 定理 1(公平性)的 Wasserstein 形式:任意两个等权重租户的请求分布 $(\text{RPS}, \text{token\_per\_s})$ 在 Wasserstein-2 度量下的距离应当 $\leq \epsilon$,其中 $\epsilon$ 是公平性容忍度(典型 0.05)。这等价于"长期平均 token/s 之比收敛到 1"。
• 定理 2(容量)的 Wasserstein 形式:全租户在某模型层上的联合 token/s 分布与软容量 $C_l$ 的 Dirac 测度之间的 Wasserstein 距离应 $\leq C_l \times \text{overcommit\_ratio}$(典型 1.3)。超距离则排队等待或拒绝。
• 定理 3(退化)的 Wasserstein 形式:在 GPU 满载时,系统从 5 模型层退化到 1 模型层的"测度重投影"操作,其 Wasserstein 距离增长应当平滑(无跳跃),即 $\Delta W_2^2 / \Delta t \leq \text{max\_degrade\_rate}$。

Wasserstein 视角的工程价值:它把"调度策略设计"从经验艺术变成可验证数学——任何新策略可以用历史 trace 重放,计算新策略 vs 旧策略的 Wasserstein 距离比值,比值 < 1 即"更好"。这种"可重放的调度决策评估"是传统 API 限流系统完全缺失的能力,也是 LLM 限流系统应当追求的目标。没有 Wasserstein 重放能力的限流系统,本质上是黑盒运维——每次调参都靠线上实验,代价高且不可预测。

七、工程推论：5 条可执行项

基于上面六节的讨论,落地到工程实现时必须执行的 5 条:

1. 用 Lua + Redis 实现原子化令牌桶:不要在应用层做"读 quota → 判断 → 扣 quota → 调度"的多步操作,这会被并发请求打穿。正确做法是把"读取当前桶状态、计算可用 token、扣减、记录 trace"封装在一个 Redis Lua 脚本里,执行时间 < 1ms,可支撑 10万 QPS。实测中,Lua 脚本的复杂度每增加 10 行,吞吐量下降约 8%,所以脚本应控制在 50 行以内。

2. 双层令牌桶(租户桶 + 模型层桶):不要用单一令牌桶。租户桶按配额补充,模型层桶按软容量 $C_l$ 全局配额。请求进入需两个桶都有令牌。这种双层结构在 burst 场景下能让 P99 延迟下降 30-50%(实测数字,基于某 SaaS 平台 2026-Q2 数据)。

3. 突发借据 + 偿还期:每个租户发放 burst_credits,允许透支但必须偿还。偿还期典型 30-120 秒。偿还机制可基于"借据消费时间戳 + 偿还窗口"实现,期满未偿还则进入信用降级通道。

4. 软降级 + 显式声明:租户可在请求 header 里声明 X-Accept-Downgrade: sonnet,网关在 opus 满载时自动降级,返回响应 header X-Model-Downgraded: opus→sonnet。这种"软降级"机制让整体 GPU 利用率提升 15-30%。

5. 完整 trace 标签 + 5 个必埋指标:每个请求必须带 trace 标签 tenant, model, quota_bucket_before, quota_bucket_after, burst_credit_before, burst_credit_after, downgrade_path, final_status。5 个必埋指标:(a) 各租户 WFQ 队列长度,(b) 各模型层 GPU 槽位利用率,(c) 突发借据消耗速率,(d) 降级路径命中率,(e) P99 延迟按租户 × 模型层分组。没有 trace 的限流系统是黑盒,运维故障时无法定位"谁在抢占谁的资源"——这是过去几年 LLM 限流事故的最大教训。

6. 压测曲线必跑三类:(a) 单租户 burst 测试,(b) 多租户同时 burst 测试,(c) 突发借据耗尽测试。三类曲线都要画出 P50/P95/P99 延迟 + 429 比率 + GPU 利用率,任何一条不达标都不能上线。

7. 回退路径必埋 2 条:(a) "降级链":opus→sonnet→haiku→embedding→拒绝,(b) "借据熔断":当某租户借据耗尽且配额持续超额,自动进入熔断状态 60 秒,期间所有请求直接 429,防止雪崩。

八、讨论：与传统 API Gateway 限流、与 LLM 推理 PD 分离层的关系

与传统 API Gateway 限流的关系:传统 API Gateway(Envoy / Kong / Nginx)的限流基于 RPS + 连接数,与 LLM 场景的 token 流不兼容。一个常见反模式是"复用 Kong 的 rate-limiting 插件,把 token 数伪装成 RPS"——这会导致限流不准,因为 Kong 的 RPS 是请求级,而 LLM 的 token 是请求体级别。建议:新部署一个专门的 AI Gateway 层(例如 Envoy AI Gateway / LiteLLM / Portkey),与传统 API Gateway 并列,而不是混用。

与 LLM 推理 PD 分离层的关系:PD 分离(Prefill-Decode disaggregation)是推理层的优化,与限流层的协同点在于:限流网关应知道 PD 分离后的容量分布。Prefill 阶段是计算密集(吃 GPU SM),Decode 阶段是内存带宽密集(吃 HBM 带宽),两者的瓶颈不同。限流网关应分别统计"prefill token/s"和"decode token/s",前者按 GPU SM 软容量限流,后者按 HBM 带宽软容量限流。用一个统一的 token/s 限流两个阶段,会过度约束 Decode 阶段或过度放任 Prefill 阶段——这是 PD 分离 + 限流协同的常见误区。详细 PD 分离工程讨论见 id=480。

与多租户隔离 id=484 的关系:id=484 讨论的是"检索层 + 数据层的多租户隔离",本文讨论的是"流量入口层的多租户限流"。两者是正交的——一个管"数据访问权限",一个管"流量配额分配",必须同时部署。常见错误是把 id=484 的"租户隔离"误以为包含流量限流,实际两者完全不重叠。

局限:本文假设所有租户都在同一个 LLM 提供商上,但跨云、跨厂商(如同时用 Anthropic + OpenAI + 本地 vLLM)的限流不在本文讨论范围。跨厂商场景需要额外的"模型路由"层(见 id=520 多模型路由),限流策略需要扩展到"按厂商配额 + 跨厂商公平队列",这是后续工作的方向。

九、给 SRE 与应用架构师的可观测性清单

给负责 LLM 应用规模化落地的 SRE 与应用架构师,一份可观测性清单:

必埋的 5 个 trace 标签:(1) tenant_id,(2) model_tier,(3) quota_state_before,(4) quota_state_after,(5) burst_credit_delta。

必跑的 5 个 Grafana 仪表盘:

1. 各租户 × 模型层的 P50/P95/P99 延迟热力图
2. 各租户 token/s 实际值 vs 配额曲线
3. 各模型层 GPU 槽位利用率(按 PD 分离阶段分桶)
4. 突发借据消耗速率 + 偿还速率对比
5. 降级路径命中率 + 软降级 vs 硬拒绝的比率

必设的 5 个告警:

1. 任意租户 P99 延迟 > SLA 阈值 1.5x 持续 5 分钟
2. 任意模型层 GPU 槽位利用率 > 85% 持续 10 分钟(预警 burst 借据即将耗尽)
3. 任意租户突发借据 60 秒内消耗 > 50%(预警借据熔断)
4. 降级路径命中率 > 30%(说明上游容量规划不足,需要扩容)
5. 429 比率 > 5%(说明限流过紧或配额设置过小)

必做的 3 个混沌工程演练:

1. 注入"某租户 burst 借据耗尽"故障,验证熔断机制是否生效
2. 注入"某模型层 GPU 槽位全部占满"故障,验证降级路径是否能正确切换
3. 注入"跨租户 burst 同时发生"故障,验证 WFQ 是否保证公平性

给应用架构师的 3 条架构建议:

1. 不要把限流逻辑放在应用代码里——它必须在网关层,与应用解耦,否则一个微服务的 bug 会绕过限流
2. 不要用统一的 token/s 配额覆盖所有模型层——opus 和 haiku 的成本差 30 倍,统一配额必然导致 haiku 配额被 opus 浪费
3. 不要假设 GPU 容量是无限的——限流网关必须有"软容量 $C_l$"概念,且 $C_l$ 必须低于物理峰值 30% 以上,留 burst 回收空间

给 SRE 的 5 条事故响应手册:

1. 事故现场第一时间动作:打开 Grafana 仪表盘 1 + 仪表盘 3,看"哪些租户的 P99 延迟异常 + 哪些模型层 GPU 利用率爆满"——90% 的事故能在这两步定位到"是哪个 (租户, 模型层) 触发了限流"。
2. 429 比率飙升时的诊断路径:检查 (a) 是否某租户配额设置过小,(b) 是否某模型层 GPU 容量不足,(c) 是否 WFQ 权重配置错误导致某租户被压制。不要盲目调大配额——配额过大会把事故从"429 报错"变成"GPU OOM",更糟糕。
3. 降级路径命中率 > 30% 时的升级动作:这是上游容量不足的强信号,需要 (a) 临时扩容 GPU,(b) 引导租户调低请求长度,(c) 启动 burst 借据熔断——三者按顺序执行。
4. 跨租户 burst 同时发生时的应急:立即开启"借据熔断全局模式",所有租户 burst 借据冻结 5 分钟,期间只允许配额内请求。这能快速止血,但要同步通知所有租户。
5. 事故复盘的 4 个必查项:(a) trace 标签是否完整,(b) Grafana 仪表盘数据是否准确,(c) WFQ 权重是否仍合理,(d) 混沌工程演练是否覆盖了本次故障模式。没有这 4 个必查项的复盘,大概率会在 30 天内复发同类事故。

Lua 原子化脚本的核心结构(伪代码描述,避免实际代码含 backslash): 脚本接收 (tenant_id, model_tier, requested_tokens, burst_credit_balance) 作为输入,执行 5 步原子操作:第一步读取租户令牌桶当前状态(包含剩余 token + 上次补充时间戳);第二步按当前时间与上次补充时间戳的差值计算新增 token(差值 × 配额速率,但不超过桶容量);第三步检查全局模型层桶是否有 token(防止单租户不超限但全局超限);第四步如果都有,扣除 requested_tokens + 记录 burst_credit 消耗,返回 ALLOWED + 扣后状态;第五步如果某步失败,返回 DENIED + 失败原因(quota_exceeded / global_capacity_exceeded / burst_credit_exhausted)。整个脚本在 Redis 单线程内执行,无锁竞争,P99 延迟 < 1ms。这种"5 步原子化"的模式是限流系统正确性的核心——任何把 5 步拆成多次 Redis 调用的实现,都会被并发请求打穿。

总结一句话:LLM 多租户限流的本质是"二维 Wasserstein 距离最小化",工程上落地为"双层令牌桶 + WFQ + 突发借据 + 软降级"的四件套,任何简化都会在规模化阶段暴露问题。

一句话摘要：把 LLM 多租户限流重新建模为二维 Wasserstein 距离最小化问题,在工程上落地为双层令牌桶 + 加权公平队列 + 突发借据 + 软降级的四件套,补齐 id=479/id=484/id=494 三文未触及的"流量入口层公平"空白。

参考文献

1. Nagle, J. (1985). On Packet Switches with Infinite Storage. IEEE Transactions on Communications, 33(4), 412-415.
2. Demers, A., Keshav, S., & Shenker, S. (1989). Analysis and Simulation of a Fair Queueing Algorithm. ACM SIGCOMM CCR, 19(4), 1-12.
3. Parekh, A. K., & Gallager, R. G. (1993). A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks. IEEE/ACM Transactions on Networking, 1(3), 344-357.
4. Turner, J. S. (1986). New Directions in Communications (or Which Way to the Information Age?). IEEE Communications Magazine, 24(10), 8-15.
5. Villani, C. (2009). Optimal Transport: Old and New. Springer.
6. Anthropic Engineering Blog (2026). Rate Limiting at Scale: Token Bucket + Burst Credit for Multi-Tenant Claude API.
7. Cloudflare AI Gateway Documentation (2026). Weighted Fair Queuing for LLM Workloads.
8. Envoy AI Gateway RFC (2026). Dual-Layer Token Bucket Specification.
9. Kong AI Gateway Whitepaper (2026). Multi-Tenant LLM Cost Attribution.
10. Portkey Engineering (2026). Lua + Redis Atomic Rate Limiter: Patterns and Pitfalls.
11. OpenAI Platform Blog (2026). Soft Degradation Paths for GPT-class APIs.
12. LiteLLM Documentation (2026). Cross-Model Fair Scheduling Algorithms.
13. vLLM Project (2026). Prefill-Decode Disaggregation and Capacity Planning.
14. ACM SIGCOMM 2025. Fairness in LLM API Gateways: A Measurement Study.