多租户 LLM 推理中的调度公平性：为什么 FIFO 是错误的默认选择

你的公司运行着一个共享的 LLM 服务集群。两个租户在使用它：一个面向客户的聊天机器人，其首令牌延迟 SLO 为 500 毫秒；以及一个批量文档丰富管道，通宵处理数千个长上下文提示。某天凌晨三点，聊天机器人团队把你叫醒，因为他们的 P95 TTFT 飙升到了 12 秒。根本原因：批处理任务比预期更早启动，用预填充工作占满了 GPU 内存，而聊天机器人的短请求在一列 8,000 个令牌的提示后面等待。你的 FIFO 调度器给了它们同等的优先级。在你手动终止批处理任务之前，聊天机器人的 SLO 已经被违反了 4,000 次。

这种故障模式很常见，理论上早已被理解，但在实践中却出人意料地普遍。大多数团队部署 vLLM 或 TGI 时使用默认的 FIFO 调度器，随着时间推移添加多个工作负载，只有在发生事故时才发现优先级反转问题。

为什么 LLM 调度从根本上与众不同

来自 Web 服务调度的标准直觉并不能直接应用于 LLM 推理。在典型的 API 中，请求的执行时间大致相似——几毫秒——所以 FIFO 运行良好。LLM 推理在三个方面打破了这一假设。

输出长度在准入时是未知的。 LLM 以自回归方式生成令牌，直到决定停止。一个看起来像简单分类提示的请求可能变成 2,000 个令牌的推理链。试图估计任务持续时间的调度器（如最短作业优先策略）必须猜测或测量——在没有针对你的流量分布训练的专用模型的情况下，80% 或更高的预测误差很常见。

输入和输出令牌的成本不对称。 处理输入令牌（预填充阶段）是计算密集型的，并行进行。生成输出令牌（解码阶段）是内存密集型的且顺序进行——每个令牌都需要加载完整的模型权重矩阵。一个有 4,000 个令牌输入和 10 个令牌输出的请求与一个有 100 个令牌输入和 500 个令牌输出的请求成本差异很大，即使总令牌数看起来相似。不区分阶段而只计算令牌数的调度器会将这些视为等同，并做出糟糕的决策。

GPU 内存是约束瓶颈，而非计算时间。 飞行中请求的键值（KV）缓存消耗的 GPU HBM 与序列长度和批次大小成比例。当 KV 缓存满时，调度器必须抢占正在运行的请求——丢弃其缓存并强制从头重新开始。这不像 CPU 进程中的内存交换；它意味着要重新运行每个预填充令牌。一批大型请求不仅会延迟小型请求——它还会触发级联驱逐，在高负载下将总 GPU 工作量乘以 2-3 倍。

FIFO 如何在规模上失败

队头阻塞是最明显的故障。单个 8,000 个令牌的提示会占用预填充槽数百毫秒，在此期间，无论后面的请求多短或携带什么 SLO，它们都必须等待。这在结构上与慢查询阻塞数据库连接池相同，但风险更高：以数百毫秒衡量的 TTFT SLO 可能被单个"大象"请求违反。

护卫效应加剧了这一问题。如果你的流量组合包括大型批处理任务和小型交互式请求，批处理任务会聚集在 GPU 内存限制处，迫使调度器进行防御性抢占。在批处理任务之后到达的短请求被反复上下文切换，其 KV 缓存被驱逐和重新计算，一遍又一遍地为批处理任务的存在付出代价。

优先级反转是更微妙的版本：低优先级的批处理工作负载在高优先级的交互式请求到达之前就开始了。使用 FIFO，批处理任务会运行到完成（或直到内存强制抢占），然后才服务交互式请求，即使交互式请求有更严格的截止时间。调度器看到的是到达顺序；它看不到 SLO。

KV 缓存抖动完成了这个循环。在 FIFO 持续负载下，调度器接受请求的速度快于其完成速度。内存被填满。调度器抢占正在运行的请求为新请求腾出空间。那些被抢占的请求重新启动并再次填满内存。吞吐量崩溃，而利用率保持高位——GPU 在忙于重新计算它已经做过的工作。

令牌加权公平份额队列

Justitia 和虚拟令牌计数器（VTC）算法等系统的核心洞察——在 2024 年 OSDI 关于 LLM 服务公平性的论文中介绍——借鉴自网络公平队列：跟踪每个租户收到了多少服务，并始终调度服务最不足的租户的下一个请求。

VTC 方法为每个租户分配一个计数器，随着其请求消耗令牌而递增。调度器从计数器最小的租户中选取下一个请求。中途加入的新租户的计数器被"提升"到当前最小值，这样他们就不会因为永远看起来服务不足而立即让其他所有人挨饿。

关键细节在于如何计算令牌。简单的令牌计数（平等对待每个令牌）仍然会让拥有许多短输出请求的租户饿死拥有较少长输出请求的租户，因为解码令牌在延迟和 GPU 内存压力方面都占主导地位。更好的方法是对输出令牌赋予比输入令牌更高的权重，反映输出令牌生成实际上随时间持有 GPU 资源的事实。

Equinox 系统通过双计数器设计更进一步：一个从租户角度跟踪加权令牌消耗的用户公平计数器，以及一个从运营商角度跟踪实际 GPU 利用率的资源公平计数器。当输出令牌长度预测错误时，这两个视角就会发散——而预测经常是错误的。Equinox 添加了一个在流量模式上训练的混合专家预测器，将输出令牌预测误差从大约 80% 降至 33%，即使在请求完成之前，也能让公平计数器保持准确。

虚拟时间公平队列的理论保证很有用：对于任何两个都处于积压状态的租户，他们收到的服务差异被一个与最大请求大小成比例的常数所限制。这意味着没有租户会无限期挨饿，而且这个界限可以从你的请求大小分布中计算出来——而不仅仅是一个模糊的承诺。

SLO 分层准入控制

加载中…