Beyond Prediction: Tail-Aware Scheduling for LLM Inference
本文介绍了一种分布感知、无需预测的调度框架，该框架通过软优先级提升和缓存感知抢占技术，显著降低了 LLM 推理中的尾部延迟和首字时间，即使在突发到达和 GPU 显存压力等挑战性条件下，其表现也优于传统的基于预测的策略。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一个繁忙的餐厅厨房，厨师（即 GPU）正在为顾客（即 AI 请求）烹饪美食。有些订单很简单：“只要一杯水”（短聊天消息）。有些则很复杂：“设计一部包含详细情节的 50 页小说”（长推理任务）。
问题在于，厨房经理在订单完成之前，并不知道每份订单究竟要花多久才能做完。一个“杯水”可能会变成“十道菜的品鉴盛宴”，如果顾客不断要求增加内容的话。
旧方法：预测未来
目前的厨房经理试图通过猜测每份订单需要多长时间来提高效率。他们使用一种叫做“最短作业优先”（Shortest Job First, SJF）的策略。
- 逻辑： “我觉得这个订单很快就能完成，所以先做它，把它从桌上撤下来。”
- 缺陷： 如果经理猜错了（在处理复杂的 AI 任务时经常发生），快速订单就会被延迟，而那个原本应该是“短任务”的长任务却会永远霸占着炉灶。
- 结果： 平均等待时间看起来还可以，但最坏情况下的等待时间（尾部延迟）却非常糟糕。有些顾客等待了数小时，而有些顾客只需几秒钟就能享受到服务。这对用户体验非常不利。
新方法：“加速”系统 (UNIBOOST)
这篇论文的作者提出了一种新的经理，他不再进行猜测，而是开始观察。他们将该系统称为 UNIBOOST。
以下是它的工作原理，使用了简单的类比：
1. “软加速”（无需水晶球）
新经理不再试图预测未来，而是给每个订单一个随时间平滑变化的“优先级分数”。
- 类比： 想象有一队人在排队等候游乐设施。新经理不会问：“你要去多远的地方？”相反，他们会说：“你在排队的时间越长，你的票就会获得一点‘加速’的优先级。”
- 作用： 短订单因为先到达而能被快速处理。但如果一个长订单已经等待了一段时间，它会获得一个温柔的推动，从而避免被源源不断的、新的短订单堵在后面。这防止了那些“长尾”顾客等待过久。
2. “记忆卫士”（不要浪费锅具）
在 AI 中，烹饪一份美食需要大量的内存（KV Cache）。如果你在烹饪过程中途停止去切换到另一个任务，你就必须扔掉刚刚准备好的食材并重新开始。这样做既昂贵又缓慢。
- 类比： 想象一位厨师正在烤一个巨大的蛋糕。如果经理大喊：“停！先去做个曲奇饼干！”那么厨师就必须把蛋糕糊从锅里刮出来，洗干净锅，然后再开始做曲奇。如果之后要切回做蛋糕，他们又得再次清洗锅具。
- 解决方案： 新经理使用了一个“记忆卫士”。他们会说：“一旦你开始烤蛋糕，在考虑切换任务之前，你必须至少烤完其中的‘一角’。”这防止了厨房频繁切换任务并浪费时间清洗锅具。
3. “自适应恒温器”
厨房的环境在变化。有时是大量小订单的爆发；有时是几个巨大的订单。
- 类比： 经理拥有一个智能恒温器，观察人们实际等待了多久。如果队伍变得太长，经理会自动调整“加速”设置，以更积极的方式去帮助那些等待时间最长的人。它是实时学习的，不需要水晶球。
结果
论文使用真实世界的数据（如编程任务和聊天对话）将这种新系统与旧的“猜测型”系统进行了对比测试。
- 旧系统： 当工作负载变得异常剧烈（突发性）时，“猜测型”系统失效了。最坏情况下的等待时间（P99）变得极大。
- 新系统 (UNIBOOST)： 它不仅改善了平均等待时间，还大幅降低了最坏的等待时间。
- 与最好的“完美预测”系统相比，它将最坏情况下的等待时间（P99）降低了 35% 到 50%。
- 它使首个 Token 出现时间（TTFT）快了 34% 到 47%。
核心结论
这篇论文认为，试图预测 AI 任务需要多长时间是脆弱且经常出错的。相反，一个能够根据任务等待时间做出反应，同时小心不要因为频繁切换任务而浪费内存的系统，能为每个人创造更加公平且快速的体验。其核心在于管理好排队的流动，而不是去猜测终点。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。