DriftSched：面向多租户GPU推理的运行时Token漂移自适应QoS调度

DriftSched：自适应QoS调度方案，应对多租户GPU推理的运行时Token漂移

日前，一份名为《DriftSched: Adaptive QoS-Aware Scheduling under Runtime Token Drift for Multi-Te》的研究论文在arXiv平台（编号2606.02982v1）公开。该论文的核心，是提出了一种名为DriftSched的调度机制，专门解决多租户环境下大语言模型（LLM）推理服务的排队难题——也就是当前AI行业里，GPU闲不下来的那个真实痛点，不是吗？

大模型推理量暴涨，老调度策略有点跟不上了

随着LLM推理服务的快速增长，高效利用多租户GPU的需求越来越高。现在的推理运行时（比如vLLM），用了连续批处理和优化内存管理来提升吞吐量，效果确实不错。但问题来了：要准确估算每个推理请求的运行成本，真挺难的。实际跑起来，模型输出Token（你可以理解成推理出来的字或词）的长度，往往和开始调度时估算的不一样，这就造成了“运行时Token漂移”。说白了，你原以为是个短问题，结果模型输出了长篇大论，调度队列立刻被搅乱——排队失衡、负载分类出错，这事儿就麻烦了。

DriftSched怎么破局？

DriftSched的名字已经点明了玩法：自适应、看运行时、面向服务质量（QoS）。它不指望事前估算准不准，而是在请求运行的过程中实时捕捉Token的实际生成速度与长度。一旦发现实际负载和预期不符，立马调整资源分配和优先级。这里有几个关键点：一是它做到了run-time级别的自适应，不是静态切分；二是它把QoS（服务质量）目标直接写在调度逻辑里，优先保证高优请求不超时。算是一套挺灵活的“动态排班表”机制。

这套方案带来啥改变？

• 队列平衡了——避免因为一两个长文本请求堵死整条流水线。
• GPU利用率更稳——不再因为错估负载而让算力空转或超载。
• 服务更可靠——多租户场景下，每个用户的推理体验不会因为邻居任务而忽快忽慢。

为什么说它挺有针对性？

现在很多大模型服务商都在搞多租户共享GPU，既要保吞吐，又要保延时。要么排队算法太死板，要么资源隔离开销太大。DriftSched这个思路，等于在运行时给调度上了一把自适应锁，光靠事前估算那一套是走不下去的。你是做AI推理平台的同学，看一眼就知道，这才是真正能落地的优化手段！