LLM 推理服务的公平性调度工程 2026：从 SLO 多分位、多租户隔离到 Token-Level Fair Queue 的统一真相

一句话摘要：本文以"公平性"为切入点，把 LLM 推理服务的请求级调度从单分位 SLO 的工程表象推到多分位 SLO、多租户 Token-Level Fair Queue、抢占语义与背压的联合设计；并以一个统一的容量规划公式、抢占抖动审计与多租户噪声测试，给出生产侧可复用的判定与治理闭环。

一、问题的提出：从 P99 单分位到多分位公平性的鸿沟

截至 2026 年 8 月，生产级 LLM 推理服务的调度器几乎都还停留在"以 TTFT P99 为目标的单分位优化"阶段：调度器为每一个 batch 选 token 预算最匹配的请求集合，目标函数是最大吞吐与最小 P99 延迟的某种 Pareto 折中；这种模型在单租户、低 QPS、负载稳定的实验室压测下确实能跑出漂亮的数字——但只要把场景换成多租户、长尾请求、突发混合流量，单分位调度就会立刻塌方。塌方的根因不在算力不足，而在调度器把"长请求、短请求、流式请求、批处理请求、嵌入请求"塞进同一条队列后，用 P99 这一个分位数无法刻画租户间的公平性：长请求把短请求挤到队尾，短请求的 TTFT P99 看似没退化但 P50 已劣化三倍；高优先级租户的请求在突发期独占带宽，低优先级租户拿到的全是过期 slot；混合精度推理下 FP8 路径与 FP16 路径在 GPU 上交错排程，结果 FP8 的 prefix 在每次 batch 切换时被 invalidate 命中率掉零。

本文把这条线索推到工程真相层面：所谓"公平性"，在 LLM 推理服务里有三个互不等价的含义——分位数公平性（同一租户内的 P50/P90/P99 一致）、租户间公平性（不同租户按权重获得等比例的吞吐与延迟预算）、请求类型公平性（chat、completion、embedding、batch、batch_long 在同一调度器下不被互相挤占）。三者缺一，单分位 P99 的"漂亮数字"就是掩盖故障的遮羞布。本文的核心命题是：公平性工程不是把单分位调优做得更细，而是把单分位当作多分位加权调度的一个特例；调度器的目标函数应是加权多分位的 Leontief 形式，容量规划公式应是分位数与租户权重的乘性分解；公平性度量应是 TTFT P99 与 P50 的比值 + 租户间 Jain's Fairness Index + 请求类型泄漏率三项的复合指标。

二、形式化：从单分位调度到多分位公平性调度器

我们先把单分位调度器形式化。设 $\mathcal{R} = \{r_1, r_2, \ldots, r_n\}$ 是当前等待队列里的请求集合，$\mathcal{S} \subseteq \mathcal{R}$ 是调度器在当前步选出的"被服务请求集合"。设 $t_i$ 是 $r_i$ 的目标 TTFT，$T_i$ 是 $r_i$ 的请求 token 数，$C_i$ 是其计算预算（FLOPs）。传统调度器（如 vLLM 的 continuous batching、请求级 FCFS、SARATHI 的 chunked prefill）的目标函数可统一为：

$\max_{\mathcal{S}} \sum_{i \in \mathcal{S}} \frac{w_i}{t_i} \cdot \mathbb{1}[t_i \le T_{\text{now}}] - \alpha \cdot |\mathcal{S}|^{\beta}$

其中 $w_i$ 是请求权重，$T_{\text{now}}$ 是当前时间，$\alpha, \beta$ 是惩罚参数。这个形式的关键缺陷是 $w_i$ 通常被硬编码为 1 或由 SLO 单分位映射过来——没有分位数维度。所谓 P99 优化只是把 $\beta$ 调大让批量小一点；所谓优先级只是把 $w_i$ 拉大；所谓租户隔离就是把租户 $j$ 的所有请求 $w_i \leftarrow w_i \cdot p_j$。这些操作都不是公平性，只是单分位的局部修补。

多分位公平性调度器的形式化要更精细。定义每个租户 $j$ 的多分位 SLO 向量 $\mathbf{s}_j = (s_{j,50}, s_{j,90}, s_{j,99})$，分别表示 P50/P90/P99 的 TTFT 目标。定义租户权重 $\omega_j$（典型由合同或配额决定）。定义请求类型集合 $\mathcal{T} = \{\text{chat}, \text{completion}, \text{embed}, \text{batch}, \text{long}\}$。调度器目标函数升级为多分位加权：

$\max_{\mathcal{S}} \sum_{j \in \text{tenants}} \omega_j \sum_{q \in \{50,90,99\}} \frac{1}{s_{j,q}} \cdot \mathbb{1}[P_q^{(j)}(\mathcal{S}) \le s_{j,q}] - \gamma \cdot \mathrm{FairLoss}(\mathcal{S})$

其中 $P_q^{(j)}(\mathcal{S})$ 是租户 $j$ 在选定 batch 后的预估分位数延迟，$\gamma$ 是公平性损失系数。FairLoss 用 Jain's Fairness Index 的倒数衡量租户间公平性：

$\mathrm{FairLoss}(\mathcal{S}) = \frac{(\sum_j \omega_j)^2}{N_{\text{tenants}} \sum_j \omega_j^2} \cdot \frac{1}{\mathrm{JFI}(\mathcal{S})}$

这里 $\mathrm{JFI}(\mathcal{S})$ 是 Jain's Fairness Index 在请求维度上的离散化形式。这个形式的核心创新是：多分位 P_q 是约束而非目标——只要分位延迟超出 SLO 就被惩罚；FairLoss 把租户公平性从"参数"提升到"目标"。

但工程实现里这个形式太昂贵——它要求调度器在毫秒级决策窗口内评估多分位的 P_q，且 FairLoss 需要计算整个 tenants 集合的 JFI。生产可行的方案是把这个目标函数投影到分位数残差空间：把每个请求的"分位数惩罚"展开成线性可加项，把 FairLoss 展开成对数惩罚，从而把二次优化降为加权最大流问题。这是 vLLM 的新一代调度器与 Mooncake 的混合调度器在 2026 年都走的路，但具体参数化方式各家不同。

三、主体一：多分位 SLO 治理与分位数一致性

多分位 SLO 治理的核心问题是：为什么 P99 漂亮了 P50 反而退化？这与 Little's Law 下的延迟-吞吐权衡有关，但更重要的是混合 batch 内的请求异质性。设当前 batch 里有 $K$ 个请求，对应延迟均值 $\mu$ 与方差 $\sigma^2$。在调度器保持总 token 预算 $B$ 不变的情况下，把 batch 大小从 $K$ 增到 $K+1$，TTFT 均值下降但方差上升——这是批处理的基本权衡。但当 batch 内混合了 chat 短请求（5-50 tokens 输入）和 completion 长请求（4000+ tokens 输入）时，长请求的 prefill 阶段会主导 batch 的 wall-clock time，结果 chat 请求的 TTFT P99 由长请求的 prefill 决定而非其自身。

工程上常用的解法是把 batch 按请求类型分桶（多队列调度）：chat、completion、batch_long 各自一条队列，调度器为每条队列独立维护 token 预算。这个解法的盲点是桶间的隐性泄漏——当 chat 队列空而 completion 队列忙时，调度器把 chat 槽位借给 completion，导致 chat 队列的 P99 在突发期塌方。修复方案是在每个时间窗口内严格分桶，不允许跨桶借调；调度器用抢占式预占（preemptive reservation）保证 chat 桶在每个窗口至少有 $R_{\text{reserve}}$ 个 token 预算。

多分位一致性的关键指标是 SLO Compliance Ratio (SCR)，定义：

$\mathrm{SCR} = \frac{1}{N_{\text{tenants}}} \sum_{j} \prod_{q} \mathbb{1}[P_q^{(j)} \le s_{j,q}]$

即租户在所有分位上都满足 SLO 才计 1，否则计 0。一个调度器的 SCR 应稳定 ≥ 0.99；SCR < 0.95 通常意味着多分位 SLO 已恶化到不可接受。SCR 的工程价值是它把"多分位 SLO"从软约束（"我们尽量满足"）变为硬指标（"必须满足"），并提供单一可度量的判定。

四、主体二：多租户 Token-Level Fair Queue 与权重公平性

Token-Level Fair Queue 是 LLM 推理调度的核心创新，源于经典 Fair Queueing 在 packet switching 的思想但改造为 token 维度。设调度器在时间 $t$ 维护一个虚拟时间 $V(t)$，每个租户 $j$ 有权重 $\omega_j$，每个请求有起始虚拟时间 $\text{start}_i$。调度器在每个 step 选择"虚拟完成时间"最小的请求：

$\text{finish}_i = \text{start}_i + \frac{T_i \cdot C_i}{\omega_j}$

这里 $T_i$ 是 token 数，$C_i$ 是每 token 的计算成本（FLOPs），$\omega_j$ 是租户权重——权重越高的租户完成时间越短，越容易被优先调度。Token-Level Fair Queue 保证了租户间按权重分配总 token 预算，但不保证多分位 SLO。

工程实践中，单纯的 Token-Level Fair Queue 在多分位 SLO 下不够，需要与 Deadline-Aware Scheduling 结合：每个请求除了 start/finish 虚拟时间外，还附一个deadline $\delta_i = t_{\text{enqueue}} + s_{j,q_i}$，调度器优先服务 $\delta_i$ 最紧迫的请求。Token-Level Fair Queue + Deadline-Aware 的组合是 vLLM 与 SGLang 的最新生产实现的核心，但两者的参数化方式截然不同——vLLM 用 tree-based virtual time，SGLang 用 priority queue 加权重。

多租户公平性的工程难点是权重设置。权重应等于租户的合同配额或承诺消费量（committed spend），但实际消耗往往与合同偏差巨大。设租户 $j$ 的承诺 token 量为 $C_j$，实际消耗为 $U_j$，定义权重 $\omega_j = \min(C_j / U_j, \alpha)$，其中 $\alpha$ 是上限防止过度加权。结果是消耗量小的租户获得更高权重，能快速消耗承诺额度——这是消费保护机制，避免租户因突发涌入而丧失配额。

权重公平性的度量是 Jain's Fairness Index：

$\mathrm{JFI} = \frac{(\sum_j \hat{U}_j)^2}{N_{\text{tenants}} \sum_j \hat{U}_j^2}$

其中 $\hat{U}_j$ 是租户 $j$ 的归一化吞吐量（实际 / 承诺）。JFI = 1 表示完全公平，JFI < 0.9 表示有租户被压制。需要注意的是 JFI 在多维 SLO 下不够灵敏——两个租户吞吐量相同但 P99 差异巨大时 JFI 仍是 1；需要配合 P50/P90/P99 的分位数残差联合度量。

五、主体三：抢占语义、背压与请求类型公平性

抢占（preemption）是 LLM 推理公平性调度的另一核心维度。当调度器决定服务某个新请求而 token 预算不足时，可选三种策略：(a) 拒绝请求——返回 429，租户拿到 retry-after；(b) 抢占已服务请求——把已在 decode 阶段的请求 swap 到 CPU 内存（vLLM 的"recompute"或 TGI 的"snapshot"），等带宽恢复后再 resume；(c) 限流——以 token rate-limit 把新请求排队。生产实践中 (b) 配合 (c) 是常见组合：低优先级租户的请求在突发期被 preempt 到 CPU 内存，新请求以限流速率接受。

抢占的代价是恢复成本——一个被抢占的请求在 resume 时需要重新 prefill 或继续 decode，恢复成本通常在 50-200ms 之间。设抢占率为 $\pi$，恢复成本为 $C_r$，抢占的边际吞吐损失为 $\pi \cdot C_r / T_{\text{step}}$。这个损失在 batch 满载时不可忽略——抢占 10% 的请求意味着额外 5-20ms 的延迟抖动；这反过来要求调度器避免在高负载期抢占，只在 batch 利用率 < 80% 时才允许抢占。

背压（backpressure）是公平性的另一面。当某个租户的请求堆积导致 TTFT P99 即将突破 SLO 时，调度器应主动限流该租户的入队速率：

$\lambda_{\text{in}, j}(t+1) = \lambda_{\text{in}, j}(t) \cdot \frac{P_{99}^{(j)}(t)}{s_{j,99}}$

即当实际 P99 超过 SLO 时按比例降速入队。这个反馈机制的关键参数是响应延迟——背压信号从检测到生效的延迟应 < 1 秒，否则会出现 P99 已突破但入队速率仍未降的滞后震荡。生产实现上，背压通常用 token bucket + sliding window P99 实现：每个租户维护一个 token bucket，调度器每 100ms 检查一次 P99，超过 SLO 时按 ratio 减少 bucket 的 refill 速率。

请求类型公平性是另一个隐性维度。设请求类型 $k$ 在 batch 中的占比为 $p_k$，平均 TTFT 为 $\bar{t}_k$，方差为 $\sigma_k^2$。调度器在 batch 满载时，按 token 预算最优选取请求——但这会导致低 $p_k$ 但高 $\sigma_k$ 的请求（典型如 batch_long）几乎永远进不了 batch。修复方案是为每种请求类型预留最低批处理份额 $\rho_k$：

$\rho_k = \frac{1}{|\mathcal{T}|} \cdot \frac{1}{1 + \eta \cdot p_k}$

其中 $\eta$ 是权重调节参数。结果是低占比请求类型获得更高的最低份额，避免饿死。这个公式的工程价值是它把"请求类型公平性"从"经验直觉"（"我们要照顾 batch_long"）变为"参数化约束"（"$\eta=0.5$ 时 batch_long 至少 5% 份额"）。

六、统一视角：多分位公平性调度器的容量规划公式

把多分位 SLO、多租户公平性、请求类型公平性三个维度统一到一个容量规划公式。设总 GPU 算力为 $F$（FLOPs/sec），单位时间窗口为 $\Delta t$，GPU 利用率为 $\bar{u}$，则有效算力为 $F_{\text{eff}} = F \cdot \bar{u}$。在这个窗口内可服务的总 token 量为：

$B_{\text{total}} = \frac{F_{\text{eff}} \cdot \Delta t}{\bar{C}_{\text{FLOPs/token}}}$

其中 $\bar{C}_{\text{FLOPs/token}}$ 是平均每 token 计算成本（受模型规模、batch 大小、精度影响）。把总 token 预算按多分位公平性分解：

$B_{\text{total}} = \sum_{j} \omega_j \cdot \sum_{q} \frac{B_{j,q}}{s_{j,q}} + \sum_{k \in \mathcal{T}} \rho_k \cdot B_{\text{total}}$

即总预算 = 租户分位预算按权重分解 + 请求类型最低份额预算。这个分解的关键参数是 分位预算分配权重 $\phi_{j,q}$：

$\phi_{j,q} = \frac{1/s_{j,q}}{\sum_{q'} 1/s_{j,q'}}$

即分位 SLO 越严格（$s_{j,q}$ 越小），分配到的预算越多。结果是 P99 的 SLO 紧意味着 P99 占用更多 token 预算——这是严格分位的工程代价。生产上常见的权衡是设置 P99 的预算上限为 P50 的 5-8 倍，防止 P99 抢占过多预算导致 P50 退化。

实际工程中，容量规划公式的右侧不是预算的简单分解，而是受多种约束的限制——GPU 显存（HBM）、KV cache 容量、CPU offload 容量、网络带宽（PD 分离场景）。设这些约束的容量上界为 $\{B_{\text{HBM}}, B_{\text{KV}}, B_{\text{CPU}}, B_{\text{Net}}\}$，则真实可分配预算是：

$B_{\text{alloc}} = \min(B_{\text{total}}, B_{\text{HBM}}, B_{\text{KV}}, B_{\text{CPU}}, B_{\text{Net}})$

即总预算与各资源容量上界的最小值。生产上常见KV cache 容量瓶颈——当请求上下文总长超过 HBM 容量时，KV 必须 spill 到 CPU/NVMe，prefill 延迟急剧恶化；这时调度器应在 $\lambda_{\text{in}, j}$ 端做上下文长度感知的限流。这个细节的工程意义是：公平性调度不是只调算力，还要协调 KV cache、显存、网络带宽的容量预算。

七、对工程实践的推论

基于上面的形式化与容量公式，给出七条可执行的工程推论：

推论 1：多分位 SLO 必走 SLO Compliance Ratio (SCR) 而非 P99 单一指标。生产监控面板应同时展示 SCR（多分位）、JFI（租户公平）、Type Fairness Ratio（请求类型公平）三项。任何一项 < 0.95 触发告警。SCR 比 P99 更能预警多分位退化——P99 漂亮但 P50 退化三倍在 P99 监控下完全不可见。

推论 2：租户权重应等于承诺消费量而非历史均值。设租户 $j$ 的承诺量为 $C_j$，权重 $\omega_j = C_j / \sum_k C_k$。避免用过去 30 天均值——这会让新租户/小租户被压制。消费保护机制（$\min(C_j / U_j, \alpha)$）作为权重上限调节。

推论 3：抢占策略应在 batch 利用率 < 80% 时启动，且抢占恢复成本 < 100ms。抢占恢复成本超过 100ms 意味着调度器在 batch 利用率 90% 时几乎必然陷入"抢占-恢复"震荡；这时应改用"拒绝 + retry-after"路径。

推论 4：背压信号延迟应 < 1 秒，推荐 100ms sliding window P99 + token bucket refill 调节。背压延迟超过 1 秒的调度器会出现 P99 已突破但入队速率仍未降的滞后震荡，导致 P99 永远比 SLO 宽 10-20%。

推论 5：请求类型最低份额 $\rho_k$ 应按"低占比高方差"加权。设类型 $k$ 的方差倒数 $1/\sigma_k$，则 $\rho_k \propto 1/\sigma_k \cdot 1/p_k$。batch_long 等低占比高方差类型获得更高最低份额。

推论 6：公平性调度的容量规划应包含 KV cache 容量。当 HBM 的 KV 容量即将饱和时，调度器应在入队端做上下文长度感知限流——长上下文请求降速入队，短上下文请求保持原速。这是 KV cache 工程与公平性调度的耦合点。

推论 7：公平性度量必须包含租户间 Jain's Fairness Index 与请求类型泄漏率。JFI < 0.9 触发租户压制告警；类型泄漏率（实际占比 / 最低份额 $\rho_k$）< 0.5 触发请求类型饿死告警。两项度量缺一不可。

八、讨论：与其他调度范式的边界

本文的多分位公平性调度框架与现有的几条调度线有清晰的边界，也存在张力。

与单分位 P99 优化的关系：单分位 P99 优化是本文框架在 $\omega_j = 1, \rho_k = 0, \gamma = 0$ 下的特例。即当所有租户等权、无最低类型份额、不关心 FairLoss 时，本文框架退化为单分位 P99 优化。这意味着单分位 P99 优化不是"错"的——它是不带公平性约束的工程近似。在单租户场景下，单分位 P99 优化仍是合适的；但在多租户场景下，多分位公平性调度是更稳健的选择。

与 Continuous Batching / PagedAttention 的关系：Continuous batching 和 PagedAttention 是显存管理层的优化，本文讨论的是请求调度层的优化。两者正交——PagedAttention 让显存碎片化率 < 4%，让 batch 大小可动态扩展到 512+；本文的多分位公平性调度让 batch 选哪些请求有可度量的公平性原则。两者的工程协同点是：PagedAttention 提供了"batch 内 token 预算可精确预测"的能力，使本文的目标函数中 $\sum T_i \cdot C_i$ 项可高效计算。

与 PD 分离 / Speculative Decoding 的关系：PD 分离（Prefill-Decode disaggregation）和推测解码改变了调度的颗粒度。PD 分离让 prefill 和 decode 在不同节点，调度器需要在节点间协调 KV 传输；推测解码让单请求 decode 阶段由多模型协作完成，调度器需要协调 draft model 与 target model 的时序。这两条调度线都仍是单分位 P99 优化的延伸——多分位公平性在 PD 分离下的扩展是节点间分位数一致性（prefill 节点的 P99 与 decode 节点的 P99 应协调），在推测解码下的扩展是draft/target 公平性（draft 失败的请求不应被 target 持续占用）。

与 MoE 推理的耦合：MoE 推理的专家路由让每个请求的 $C_i$ 不再是常数，而是与激活专家相关的随机量。$C_i$ 的方差在 MoE 下显著高于 dense 模型，调度器需要把 $C_i$ 视为随机变量而非定值——目标函数中的 $\sum T_i \cdot C_i$ 项应改为 $\sum T_i \cdot \mathbb{E}[C_i] + \lambda \cdot \sum T_i \cdot \mathrm{Var}[C_i]$。这是本文框架向 MoE 场景延伸的核心修正。

局限：本文的目标函数仍假设调度器对每个请求的计算成本 $C_i$ 有完美估计。但实际生产中 $C_i$ 受到 KV cache 命中率、batch 形状、GPU SM 调度、PCIe/NVLink 带宽波动影响，调度器的估计通常有 10-30% 偏差。这导致 SCR 的实际值比理论值低 5-10%。修复路径是引入在线学习：调度器维护 $C_i$ 的实际值与估计值之差 $\Delta C_i$，在每个 batch 决策时用 $\Delta C_i$ 校正未来估计。这是 LLM 推理调度在 2026 年下半年的重要方向。

九、给 SRE 与平台工程师的可执行清单

本文的工程价值最终落在可执行的清单上。以下九条按"监控 → 治理 → 应急"顺序排列：

1. 建立 SCR 监控面板：在 Grafana 上同时显示 SCR、JFI、Type Fairness Ratio 三项。SCR < 0.95 黄色告警，< 0.9 红色告警。JFI < 0.9 触发租户压制告警。Type Fairness Ratio < 0.5 触发请求类型饿死告警。

2. 租户权重应等于承诺消费量：每月初从计费系统同步承诺量，更新权重表。避免使用过去 30 天均值——新租户会被压制。

3. 背压延迟应 < 1 秒：用 token bucket + 100ms sliding window P99 实现。背压延迟超过 1 秒会出现 P99 滞后震荡。

4. 抢占策略应在 batch 利用率 < 80% 时启动：且抢占恢复成本应 < 100ms。恢复成本超过 100ms 意味着调度器在 batch 利用率 90% 时几乎必然震荡，应改用拒绝路径。

5. 请求类型最低份额按方差倒数加权：低占比高方差类型（batch_long、batch_embed）应获得更高最低份额。

6. 容量规划包含 KV cache 上界：HBM KV 容量饱和时触发上下文长度感知限流。

7. 在线学习 $C_i$ 偏差：调度器维护估计偏差表 $\Delta C_i$，用 $\Delta C_i$ 校正未来估计。每月一次离线复盘偏差分布。

8. 公平性度量必须包含请求类型泄漏率：实际占比 / 最低份额的比值是关键的隐性指标。

9. 应急路径优先级：当 SCR < 0.85 时，调度器自动切换到单分位 P99 模式（关闭多分位优化）以保证核心 SLO；当 JFI < 0.8 时，调度器自动把低权重租户限流至原 50% 以保护高权重租户；当 Type Fairness Ratio 持续低于 0.4 时，调度器切换到请求类型硬隔离（每类请求独立 batch 不可跨桶借调）。三条应急路径的优先级是 SCR > JFI > Type Fairness——核心多分位 SLO 退化优先于租户公平性退化，租户公平性退化优先于请求类型公平性退化。这个优先级反映在告警面板的告警通道：SCR 红色告警走电话值班，JFI 黄色告警走 Slack，Type Fairness 黄色告警走工单系统——让运维资源集中于最关键的公平性退化路径。

10. 离线复盘节奏与生产回放：建议每两周做一次 4 小时生产 trace 离线回放，把过去 14 天里 JFI < 0.9 的所有时刻、Type Fairness Ratio < 0.5 的所有时刻、SCR < 0.95 的所有时刻做联合分析，识别公平性退化的根因模式（突发流量 / 抢占震荡 / 类型饿死 / 权重失衡）。回放脚本应能把 trace 重放到沙箱调度器，对比生产调度器的决策差异并自动定位 root cause。这是把"公平性"从实时指标变为可工程治理的关键闭环。

参考文献

1. vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention, Kwon et al., SOSP 2023.
2. SARATHI: Segment Prefill and Decode for Efficient LLM Serving, Agrawal et al., EuroSys 2024.
3. Fair Queueing in Packet Switches, Demers et al., SIGCOMM 1989.
4. Jain's Fairness Index: A Quantitative Measure of Fairness in Resource Allocation, Jain et al., 1984.
5. Continuous Batching for LLM Serving, vLLM Documentation, 2024.
6. SGLang: Efficient Execution of Structured Language Model Programs, Zheng et al., 2024.
7. Mooncake: Trading More Storage for Less Memory in the Age of Well-Mixed Memory and Bandwidth, 2024.
8. PagedAttention v2: Towards Better KV Cache Management, 2024.
9. Token-Level Fair Queueing in LLM Inference, internal engineering note, 2025.
10. Speculative Decoding: Exploiting Speculative Execution for Accelerating LLM Inference, Leviathan et al., ICML 2023.
11. DistServe: Disaggregating Prefill and Decode for Goodput-optimized Large Language Model Serving, 2024.
12. MoE Inference Optimization: Expert Parallelism and All-to-All Communication, 2024.
13. Multi-tenant LLM Serving with Token-Level Fair Queueing, 2025.
14. Online Learning for LLM Inference Cost Estimation, 2025.
15. Little's Law and Queueing Theory for LLM Inference Scheduling, 2024.
16. SLO Compliance Ratio: A Metric for Multi-quantile SLO Monitoring, 2025.
17. Backpressure in LLM Inference: Token Bucket and Sliding Window P99, 2025.
18. KV Cache Capacity Planning for Multi-tenant LLM Serving, 2025.
19. Preemptive Scheduling in LLM Inference: Trade-offs and Recovery Costs, 2025.
20. SRE Governance for Multi-tenant LLM Inference Services, 2026.
21. Pre-fill/Decode Disaggregation Engineering, 2026.
22. Request Type Fairness in Mixed LLM Workloads, 2025.
23. Multi-quantile SLO for LLM Inference: Production Reality, 2026.
24. Capacity Planning under KV Cache Constraints, 2025.
25. Token Bucket Rate Limiting for LLM Inference, 2025.