💻 computer science

DriftSched: Adaptive QoS-Aware Scheduling under Runtime Token Drift for Multi-Tenant GPU Inference

本文提出了 DriftSched，一种用于多租户大语言模型（LLM）推理的 QoS 感知调度框架，该框架利用在线反馈机制来纠正运行时的 Token 估计误差，并证明了虽然自适应校准能显著提高估计准确性，但最短作业优先（SJF）调度策略在降低端到端延迟和尾部延迟方面效果最为显著。

原作者： Kathiravan Palaniappan

发布于 2026-06-03

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Kathiravan Palaniappan

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在经营一家非常受欢迎的餐厅，只有一间厨房（GPU）和一位厨师。你有三种类型的顾客：

VIP（高级会员）： 他们希望上菜快，并且愿意支付额外费用。
常客（标准会员）： 他们只想吃一顿普通的饭。
大宗采购者（批处理）： 他们订购的是巨大的餐饮托盘，并不介意等待。

问题在于？厨房会被压垮。订单不断堆积，有些人等待了很久，而有些人却很快就得到了服务。厨师需要决定下一个为谁做饭。这被称为“调度”（Scheduling）。

核心问题：猜测工作量

为了决定下一个为谁服务，调度器需要知道每个订单的工作量有多大。

是一个简单的沙拉（短任务）？
还是一个复杂的五道菜正餐（长任务）？

如果调度器猜错了，混乱就会发生。如果它认为一个巨大的餐饮订单很小，它可能会在 VIP 的快速开胃菜之前先去处理它，导致 VIP 等待时间过长。这被称为**“工作量误分类”（Workload Misclassification）**。

两种猜测方式

论文《DriftSched》测试了两种猜测订单大小的方法：

“偷懒的猜测”（空白符代理/Whitespace Proxy）： 想象一下统计订单票据上的单词数量。如果它有 10 个单词，它可能很小；如果它有 100 个单词，它就很大。这对领位员来说既快又容易，但并不准确。一个短句子可能烹饪起来很复杂，而一个长句子可能很简单。
“专家的猜测”（感知分词器的/Tokenizer-Aware）： 想象一下领位员实际上阅读了食谱，准确知道涉及多少种食材和步骤。这很准确，但领位员需要花费更多的时间和精力来计算。

解决方案：DriftSched

DriftSched 是一个管理这家餐厅的智能系统。它有一个特殊功能叫做**“自适应校准”（Adaptive Calibration，或称 EMA）**。

你可以这样理解：如果领位员使用“偷懒的猜测”，并意识到他们一致地低估了“技术报告”类餐食所需的时间，DriftSched 会从错误中学习。它会说：“啊，每次我们猜测‘技术报告’很小时，它实际消耗的时间都要长 20%。下次，我会把预估值增加 20%。”

随着时间的推移，“偷懒的猜测”会变得几乎和“专家的猜测”一样好，因为系统会根据厨房中实际发生的情况来修正自身的错误。

五种调度策略

论文测试了五种决定下一个谁用餐的规则：

FIFO（先进先出）： 就像标准的排队取号。先到先得。这很公平，但如果一个大宗采购者排在你前面且订单巨大，你会等上一辈子。
优先级（Priority）： VIP 总是跳到队伍最前面。常客和大宗采购者必须等待。这对 VIP 很好，但对其他人来说很糟糕。
加权（Weighted）： 一种折中方案。VIP 有 50% 的机会被服务，常客 30%，大宗采购者 20%。每个人都有机会，但 VIP 获得的更多。
SJF（最短作业优先）： 厨师总是挑选下一个最小、最快的订单，而不考虑是谁订的。如果一个大宗采购者有一个很小的配菜，它会在 VIP 的主菜之前被烹饪。
老化优先级（Aging Priority）： 类似于优先级调度，但如果一个大宗采购者等待时间过长，他们的票据会获得一个“印章”来提升其优先级，从而防止他们“饿死”。

他们的发现是什么？

1. 准确性很重要，但策略更重要
使用“专家猜测”（分词器）比“偷懒的猜测”（空白符）更好。然而，你用来选择下一个顾客的规则（调度策略）对等待时间的影响远大于你对订单大小猜测的准确程度。

2. SJF 是速度之王
SJF（最短作业优先） 规则是最快的。它比标准的 FIFO 队列减少了约 42% 的平均等待时间。为什么？因为通过优先处理所有微小的、快速的订单，厨房可以保持忙碌且高效，从而减少人们被困在一个巨大的订单之后的等待情况。

3. 优先级是 VIP 之王
如果你关心VIP的满意度，优先级调度（Priority Scheduling） 是最好的。VIP 的等待时间仅约为 77 秒，而大宗采购者的等待时间约为 427 秒。相比之下，SJF 并不关心你是谁，它只关心你的订单有多小。事实上，在 SJF 下，大宗采购者有时会比 VIP 更快得到服务，因为他们的订单碰巧比较小。

4. “偷懒的猜测”是可以修复的
系统的自我修正功能（EMA）效果很好。当使用不准确的“偷懒的猜测”时，系统学会了随着时间推移调整其预估值，将误差减少了约 40%。然而，如果你已经在使用“专家猜测”，自我修正的效果就不大了，因为猜测本身已经很准确了。

总结

如果你想要整体服务最快： 使用 SJF（最短作业优先）。它能最快清空队列。
如果你想保护最重要的客户： 使用 优先级调度（Priority Scheduling）。它保证 VIP 首先得到服务，即使这会让其他人等待更久。
不要过度担心完美的猜测： 即使你对订单完成所需的时间只是一个粗略的估计，你选择的调度规则（SJF 还是优先级）对于最终的等待时间影响要大得多。但是，如果你能够准确预测（使用分词器），系统运行会更加顺畅。

简而言之：如何排列顾客的顺序，比你对他们订单大小的预估有多完美更重要。

技术摘要：DriftSched

问题陈述
大语言模型（LLM）的快速普及加剧了对 AI 数据中心内高效多租户 GPU 调度系统的需求。虽然现代推理运行时（如 vLLM）通过连续批处理和内存管理优化了吞吐量，但准确估计异构推理请求的运行成本仍然是一个重大挑战。现有的调度方法通常依赖于静态 Token 限制、用户指定的输出约束或预定义的负载假设。这些静态方法无法捕捉到现实世界 LLM 负载的动态行为，在实际应用中，由于提示词复杂度、响应特征和模型行为的影响，观察到的输出长度经常偏离预期值。

论文将这一差异识别为运行时 Token 漂移（runtime token drift）。这种现象引入了估计误差，并将其传播到调度决策中，导致负载分类错误、队列失衡、尾部延迟增加、租户资源分配不公以及在 GPU 争用情况下的服务质量（QoS）下降。传统的调度算法（如 FIFO、SJF）是为执行成本可预测的系统设计的，在处理依赖于 KV 缓存增长和批处理动态等动态因素的多租户 LLM 环境时显得力不从心。

方法论与系统架构
为了应对这些挑战，作者提出了 DriftSched，这是一个针对 NVIDIA L4 GPU 上多租户 LLM 推理的自适应 QoS 感知调度框架。该系统架构集成了负载分类、Token 预算估计、租户感知队列管理以及基于运行时的反馈驱动漂移补偿机制。

自适应 Token 估计： 与静态方法不同，DriftSched 通过结合负载分类、租户感知安全因子和提示词复杂度，在 GPU 执行前估计推理成本。至关重要的是，它采用了一个通过执行反馈不断更新的自适应偏差因子（ $B_{runtime}$ ）。估计的输出 Token 数计算公式为：
$T_{estimated\_output} = T_{base} \times B_{runtime} \times S_{tenant} \times F_{input}$
其中， $B_{runtime}$ 是通过观察到的输出长度与基准估计值的比例学习得出的。
负载分类与队列管理： 推理请求被分为语义类别（short_qa、summary、technical、report），并根据估计的 Token 预算映射到运行时调度类（short、medium、long）。请求被分配到通过 Redis 管理的租户特定队列（Premium、Standard、Batch）中。
调度策略： 该框架评估了五种调度策略：先进先出（FIFO）、优先级调度（Priority Scheduling）、加权调度（Weighted Scheduling）、最短作业优先（SJF）以及老化优先级调度（Aging Priority Scheduling）。
反馈循环： 系统分为两个阶段运行：校准阶段（前 1,000 个请求）用于收集运行时反馈并使偏差因子收敛；压力评估阶段（剩余 2,000 个请求）中，调度器利用已学习的偏差值进行调度，同时进行在线自适应。自适应更新规则使用指数移动平均（EMA），根据估计 Token 数与观察到的 Token 数之间的偏差来精炼偏差因子。

核心贡献

自适应漂移感知架构： 一种新颖的调度框架，将负载估计视为一个运行时 Token 漂移补偿问题，通过动态更新偏差因子，使预测结果与观察到的行为保持一致。
运行时 Token 漂移补偿机制： 一种反馈驱动的方法，通过持续比较估计的 Token 预算与实际输出长度，减少估计误差，从而提高准入时调度的准确性。
可复现的基准测试框架： 一个使用 vLLM 在 NVIDIA L4 GPU 上进行的全面评估设置，模拟了具有不同提示词复杂度和到达率的异构多租户流量，以评估公平性、延迟和吞吐量。

实验结果
实验在 NVIDIA L4 GPU 上使用 3,000 个推理请求，涵盖三个租户层级和四种语义负载类型进行。

Token 漂移的存在性： 研究证实了不同负载类别中存在可测量的运行时 Token 漂移。静态 Token 预算估计始终高估了实际的生成行为。
估计准确度： 与静态基准相比，自适应反馈机制在所有评估的调度策略中，将负载估计误差平均降低了 38.8% (MAE) 和 40.5% (RMSE)。
延迟性能： 在各种调度策略中，最短作业优先 (SJF) 取得了最佳的整体性能。相对于 FIFO，SJF 将中位数（P50）端到端延迟降低了约 42%，并将 P99 延迟降低了约 16%。这种改进归功于对较短负载的优先处理以及减少了队列占用。
权衡关系： 虽然 SJF 优化了全局延迟，但租户感知调度器（Priority、Weighted、Aging）为 Premium 租户提供了更强的 QoS 区分度。例如，优先级调度将 Premium 租户的延迟降低到了约 77 秒，但使 Batch 租户的延迟增加到了约 427 秒。
GPU 利用率： 分析显示，在所有调度策略下，GPU 执行延迟和内存利用率保持相对稳定。这表明性能差异源于队列管理和负载排序，而非 GPU 执行效率的变化。

意义与主张
论文声称，运行时 Token 漂移是多租户 LLM 服务系统中一个可测量且具有实际意义的现象。DriftSched 的主要意义在于，它证明了自适应反馈驱动的估计可以显著提高在 GPU 争用情况下的负载特征刻画能力和调度有效性。

作者断言，他们的研究结果为企业级 AI 服务平台提供了实用的见解，强调了准确的运行时负载估计对于未来自适应推理运行时至关重要。这项工作通过引入自适应负载估计作为额外的调度信号，对现有架构（如 Orca、Sarathi、vLLM）进行了补充。研究结论指出，虽然工作量感知调度（如 SJF）能显著降低尾部延迟，但它在租户层级的公平性方面存在权衡，这表明未来的系统必须在全局效率与服务水平保证（SLG）之间取得平衡。论文也谦虚地指出，其评估是在单个 GPU 平台和模型上进行的，未来的工作将探索多 GPU 场景和基于强化学习的调度。

核心问题：猜测工作量

两种猜测方式

解决方案：DriftSched

五种调度策略

他们的发现是什么？

总结

类似论文