Each language version is independently generated for its own context, not a direct translation.

这篇论文主要解决了一个在大模型（AI）时代非常棘手的问题：当很多人同时想用同一个 AI 模型时，怎么公平、高效地分配资源，既不让重要的人等太久，又不浪费算力？

为了让你轻松理解，我们可以把整个系统想象成一家繁忙的“智能餐厅”。

1. 现状：传统的“点餐”方式有多糟糕？

想象一下，这家餐厅（AI 平台）里有很多顾客（租户），他们都想让厨师（GPU 显卡）做一道复杂的菜（生成 AI 回答）。

旧方法 A：包间制（专用端点）
以前，餐厅给每个 VIP 客户单独开一个包间，里面配一个专属厨师。
- 缺点：如果这个 VIP 客户今天没来，那个厨师就在那儿干坐着，资源被浪费了。而且如果来了很多临时客，没包间的人只能被拒之门外。
旧方法 B：数人头制（传统限速）
餐厅门口贴个牌子：“每分钟只允许进 10 个人”。
- 缺点：这太粗糙了！不管你是来点一杯水（简单的短问题），还是来吃满汉全席（超长的复杂推理），都算作"1 个人”。
- 后果：一个吃满汉全席的人占用了厨师 1 个小时，结果导致后面 10 个只喝水的人都被堵在门口。餐厅明明有空闲的桌子（算力），却因为规则死板而无法利用。

2. 新方案：Token Pools（令牌池）—— 用“食材”来衡量

这篇论文提出了一种叫**"Token Pools"（令牌池）**的新管理方式。

核心比喻：把“算力”变成了“食材配额”

在这个新餐厅里，不再按“人数”或“包间”收费，而是按**“食材消耗量”**来管理。

Token（令牌）：就像餐厅里的**“食材单位”**。
- 你问一个问题，AI 回答得越长，消耗的“食材”（Token）就越多。
- 有些问题需要厨师记很多笔记（KV 缓存），这就像占用了更多的**“冰箱空间”**。
- 有些问题需要厨师同时处理很多道菜（并发），这就像占用了更多的**“灶台”**。

令牌池（Token Pool） 就是餐厅的中央食材库。它不再看有多少人排队，而是看：

你的**“食材消耗速度”**（每秒能出多少菜）。
你的**“冰箱占用量”**（需要记多少笔记）。
你的**“灶台占用数”**（同时能做几道菜）。

3. 三大创新机制

A. 会员等级制（服务等级 Service Classes）

餐厅把顾客分成了不同的等级，就像航空公司的座位：

头等舱（Dedicated/Guaranteed）：无论多忙，他们的菜必须做，而且速度有保证。哪怕餐厅爆满，也不会被赶走。
经济舱（Elastic）：平时有保证，但如果餐厅太忙，可以暂时少给点菜，等忙完了再补上（这叫“欠债机制”）。
站票/特价票（Spot/Preemptible）：只有当餐厅有空位时才给做。一旦有人要坐头等舱或经济舱，这些人的菜立刻停止制作，把资源让出来。

B. 智能门童（Admission Control）

在顾客点菜（发送请求）之前，门口的智能门童会先算一笔账：

“这位顾客想点的菜，需要消耗多少食材？”
“现在的食材池里还有余量吗？”
“这位顾客是 VIP 还是站票？”

如果资源不够，门童会直接拒绝那些“站票”或“低优先级”的顾客（返回一个“请稍后再试”的提示），而不是让他们挤进厨房把厨师累死。

结果：VIP 顾客永远不需要排队，他们的菜永远在 1.2 秒内端上桌；而低优先级的顾客虽然被拒了，但保护了整体系统的稳定。

C. 记账本与“欠债”机制（Debt Mechanism）

这是最聪明的地方。

如果一位“经济舱”顾客因为餐厅太忙，连续被少给了菜（资源被压缩），餐厅的记账本上就会给他记一笔**“欠债”**。
当餐厅稍微空闲一点，或者有新资源进来时，系统会优先给这位“欠债”的顾客补菜，甚至多给一点，直到把债还清。
效果：这保证了即使大家都有不同需求，长期来看，每个人得到的服务是公平的。不会有人一直倒霉，也不会有人一直占便宜。

4. 实验结果：真的有用吗？

作者在实验室里模拟了两种情况：

大忙人挤兑小忙人：
- 没有新系统时：一群“站票”顾客疯狂点菜，把厨房堵死，结果连“头等舱”的 VIP 都等了 19 秒以上才吃到菜。
- 有了新系统：门童直接拦住了多余的“站票”顾客。VIP 的等待时间依然控制在 1.2 秒以内，厨房忙而不乱。
资源短缺时的公平分配：
- 当餐厅突然少了一半的厨师（模拟故障），系统自动根据“谁更急”和“谁之前被亏待了”来分配剩下的资源。
- 一个需要快速回复的“代码助手”（高优先级）和一个人工整理数据的“慢任务”（低优先级）同时存在时，系统会优先保“代码助手”，但会让“慢任务”在后续慢慢补回来，最终大家都能吃到饭。

总结

这篇论文的核心思想就是：别再用老式的“数人头”或“包间”来管理 AI 了。

我们要用**“食材（Token）”来精确衡量 AI 的消耗，建立一个智能的“食材池”。通过分级服务**（保护 VIP）和记账欠债（公平补偿），让 AI 平台在人多拥挤的时候，既能保证重要任务不卡顿，又能让普通任务在空闲时“插队”吃饱，实现真正的物尽其用和公平高效。

这就好比把原本混乱的菜市场，变成了一个拥有智能调度系统的现代化中央厨房。

Each language version is independently generated for its own context, not a direct translation.

论文技术总结：多租户 AI 推理平台中的令牌管理 (Token Management in Multi-Tenant AI Inference Platforms)

1. 研究背景与问题 (Problem)

随着大语言模型（LLM）在企业计算中的普及，多租户 AI 推理平台面临着资源利用与服务等级协议（SLA）保障之间的核心矛盾。现有的基础设施在应对变动的需求时存在显著缺陷：

专用端点（Dedicated Endpoints）的局限性：为每个租户或模型分配专用 GPU 实例虽然隔离性好，但会导致模型空闲时资源被“搁置”（stranded capacity），造成严重的资源浪费，尤其是对于长尾模型。
传统速率限制（Rate Limits）的不足：现有的速率限制通常基于“每分钟令牌数”等简单指标，忽略了推理请求的异构成本。两个请求可能消耗相同的令牌数，但在 GPU 时间、KV 缓存（Key-Value Cache）占用和并发度上存在数量级的差异。
缺乏工作守恒（Work-Conservation）：传统方法无法在低优先级任务空闲时让高优先级任务借用资源，也无法有效应对突发流量（如长上下文导致的 KV 缓存耗尽、推理模型导致的输出长度激增等）。
调度粒度不匹配：现有的 Kubernetes 调度器基于 Pod 或容器粒度，而推理资源的竞争发生在**请求（Request）**粒度。当低优先级请求先到达并占用 GPU 时，高优先级请求可能因无法抢占而遭受延迟。

核心问题：如何在多租户环境下，基于推理原生单位（如令牌吞吐量、KV 缓存、并发度）进行细粒度的资源分配和优先级控制，同时保持底层推理运行时（如 vLLM）和集群调度器的不变性？

2. 方法论 (Methodology)

作者提出了一种名为**“令牌池”（Token Pools）**的控制平面抽象，将推理容量转化为显式的权益（Entitlements），并在 API 网关层实施基于优先级的准入控制。

2.1 资源模型：推理原生单位

令牌池将 GPU 容量分解为三个可调度资源：

令牌吞吐量 ( $\lambda$ )：每秒生成的令牌数，直接决定 GPU 时间消耗。
KV 缓存容量 ( $\chi$ )：注意力状态所需的内存（字节），对于长上下文模型是主要瓶颈。
并发度 ( $r$ )：同时驻留在解码 GPU 上的活跃序列数，决定了批处理大小和解码槽的竞争。

2.2 服务等级与权益 (Service Classes & Entitlements)

系统定义了五种服务等级，决定了资源争用时的保护顺序：

专用 (Dedicated) / 保证 (Guaranteed)：拥有预留基线，永不缩减，保证成本或性能。
弹性 (Elastic)：拥有时间平均的基线保证。允许在资源富余时突发（Burst），但在资源紧张时会被缩减，并积累“服务债务”（Service Debt）以在未来获得补偿。
现货 (Spot)：无基线保证，仅消耗剩余容量，资源紧张时最先被限流。
可抢占 (Preemptible)：可被完全驱逐。

2.3 优先级与债务机制 (Priority & Debt Mechanism)

系统通过一个综合权重公式 $w_e$ 来决定请求的准入和调度顺序：
$w_e = w_{\kappa_e} \cdot (1 + \alpha_{slo} \cdot \ell^*_e)^{-1} \cdot (1 + \alpha_{burst} \cdot b_e)^{-1} \cdot (1 + \alpha_{debt} \cdot d_e)$

服务类权重 ( $w_{\kappa_e}$ )：基础优先级（如 Dedicated 为 1000，Spot 为 1）。
SLO 紧迫度：SLO 目标越严格（延迟要求越高），优先级越高。
突发强度 ( $b_e$ )：持续超过基线的消费会降低优先级。
服务债务 ( $d_e$ )：基于指数加权移动平均（EWMA）计算。如果租户在资源紧张时获得的资源少于基线，债务增加，从而提高其未来的优先级，实现公平共享（Fair-Share）收敛。

2.4 系统架构

虚拟节点 (Virtual Nodes)：利用 Kubernetes 的扩展资源（Extended Resources），将令牌池的容量（令牌/秒、KV 缓存大小）映射为虚拟节点。
准入控制 (Admission Control)：位于 API 网关层。在请求到达推理运行时之前，系统检查租户的权益状态、并发限制、令牌预算以及当前池的优先级阈值。
动态调整：如果池资源不足，低优先级请求会被拒绝（返回 HTTP 429），而高优先级请求继续执行。底层推理引擎（如 vLLM）无需修改。

3. 主要贡献 (Key Contributions)

形式化定义：提出了“令牌池”作为推理原生的可调度资源抽象，将容量分解为吞吐量、KV 缓存和并发度，并引入了结合服务类、SLO、突发历史和债务的优先级机制。
系统架构创新：设计了一种基于 Kubernetes 虚拟节点和自定义资源（CRD）的架构，利用现有的 Kubernetes 调度器进行令牌容量的准入控制，无需修改底层推理运行时。
实验验证：
- 跨类保护：在过载情况下，保证类工作负载的 P99 延迟保持在 1.2 秒以内，而基准系统（无准入控制）延迟飙升至 19 秒以上。
- 公平共享：在容量稀缺时，基于债务机制实现了具有不同 SLO 要求的弹性工作负载之间的公平收敛，防止了低优先级任务的饥饿。

4. 实验结果 (Results)

作者在单节点 Kubernetes 集群（使用 vLLM 后端）上进行了两项实验：

实验一：跨类保护 (Cross-Class Protection)
- 场景：模拟突发流量导致 38% 的过载。
- 结果：引入令牌池后，保证类（Guaranteed）工作负载的 P99 首令牌时间（TTFT）始终低于 1.2 秒。多余的 Spot 流量被直接拒绝（HTTP 429），队列保持为空。相比之下，无准入控制的基准系统队列堆积，所有工作负载的延迟均恶化至 19 秒以上。
- 结论：API 边界的准入控制有效防止了队列堆积对高优先级任务的级联影响。
实验二：SLO 感知的公平共享 (SLO-Aware Fair Share)
- 场景：模拟节点故障导致容量减半，三个弹性工作负载（不同 SLO 要求）竞争剩余资源。
- 结果：
  - 优先级区分：SLO 要求严格（500ms）的 Copilot 任务获得了优先准入，而 SLO 宽松（30s）的合成数据任务（Synth）被大量限流。
  - 债务机制生效：Synth 任务因被限流积累了大量债务，其优先级权重随时间上升（从 20.3 升至 83.2），逐渐获得更多资源份额，避免了饥饿。
  - 恢复：当容量恢复时，债务迅速衰减，系统回归基于 SLO 的基准优先级。
- 结论：债务机制成功实现了动态公平，既尊重了 SLO 差异，又保证了长期公平性。

5. 意义与价值 (Significance)

填补了控制平面与执行平面的鸿沟：传统方案要么在 GPU 调度层（太晚，无法优雅降级），要么在应用层（太粗，无法感知推理成本）。令牌池在 API 网关层实现了细粒度、推理原生的资源管理。
无需修改底层基础设施：该方案作为控制平面层叠加在现有的 vLLM、TensorRT-LLM 和 Kubernetes 之上，使得企业可以低成本地部署多租户 AI 服务，无需重构推理引擎。
解决“噪声邻居”问题：通过服务等级和债务机制，有效隔离了不同租户间的资源干扰，确保关键业务（如生产推理）不受低优先级批处理任务的影响。
提升资源利用率：通过允许低优先级任务在资源富余时突发，并在紧张时让出资源，实现了比静态配额更高的整体资源利用率。

综上所述，该论文提出了一套成熟、可落地的多租户 AI 推理资源管理方案，通过“令牌池”抽象和债务驱动的公平机制，成功平衡了资源利用率与服务等级保障。

Token Management in Multi-Tenant AI Inference Platforms