[Paper] L4：通过基于长度感知的调度实现低延迟和负载均衡的 LLM 服务

Source: arXiv - 2512.19179v1

概览

本文介绍了 L4，一种全新的运行时系统，通过感知请求长度，显著加速在 GPU 上服务大型语言模型（LLMs）。由于现代 LLM 能处理 100 k+ 令牌的上下文窗口，在同一 GPU 批次中混合短查询和长查询会浪费计算资源并增加延迟。L4 通过动态将请求路由到针对特定长度优化的实例，将异构工作负载转化为平滑的流水线。

关键贡献

• 长度感知调度：一种新颖的调度器，按传入请求的 token 长度对推理实例进行分组，降低每个实例的异质性。
• 动态规划分区：一种高效算法，确定长度专用阶段的最佳数量，以最大化整体 QoE（延迟 + 吞吐量）。
• 运行时范围细化与去中心化再平衡：持续调整长度边界以及跨组和组内的负载分配，无需中心瓶颈。
• 全面评估：相较于现有最佳多实例调度器，展示了最高 降低 67 % 的端到端延迟、降低 69 % 的尾部延迟，以及 提升 2.89× 的吞吐量。

方法论

1. 实例分组 – L4 启动多个相同的 GPU 实例来运行同一 LLM。每个实例被分配一个 长度区间（例如，0‑2 k 令牌，2‑8 k 令牌，…）。
2. 动态划分 – 使用轻量级的动态规划（DP）求解器，L4 定期根据当前请求分布以及在延迟和吞吐量之间平衡的 QoE 目标，重新计算最优的长度区间集合。
3. 流水线流动 – 当请求到达时，首先放入长度区间最匹配其令牌数的组中。如果请求增长（例如因后续交互），它可以被 提升 到后面的阶段，在组之间形成自然的流水线。
4. 负载均衡 – 在每个组内部，去中心化的均衡器监控 GPU 利用率并在实例之间迁移请求，以避免热点。跨组之间，L4 调整长度边界，使每个组的负载保持均衡。
5. 实现方式 – 基于标准推理引擎（例如 vLLM）构建，L4 只添加了一层薄薄的调度层，核心模型执行保持不变。

结果与发现

• 长度异质性是主要瓶颈，当上下文窗口超过约 32 k 令牌时。
• 动态分区自适应工作负载变化（例如，长文档突然激增），在几秒内完成，保持 QoE 稳定。
• 去中心化再平衡消除单点故障，并可扩展至数十个 GPU 实例而几乎没有额外开销。

Practical Implications

• 降低运营成本 – 更高的 GPU 利用率意味着可以使用更少的 GPU 来满足相同的 SLA，直接削减云费用。
• 提升用户体验 – 更快的响应时间，尤其是对长上下文查询（代码生成、文档摘要），能够提升感知质量。
• 简化容量规划 – 运营者可以依赖 L4 的自调节能力来处理混合工作负载，无需手动为“短查询”和“长查询”分别配置集群。
• 即插即用的集成 – 由于 L4 位于现有推理服务器之上，团队可以在最小代码改动的情况下采用它，保留已有的模型流水线和监控工具。
• 开启新服务 – 以前因延迟而被回避的应用（例如实时法律文档分析、拥有 100 k token 上下文的多轮对话）现在变得可行。

限制与未来工作

• 假设模型权重是静态的 – L4 仍未处理即时模型更新（例如 LoRA 微调），这些更新可能会改变每个 token 的计算成本。
• 仅限 GPU – 当前设计面向同构 GPU 集群；扩展到异构加速器（TPU、CPU）留待以后。
• 调度开销 – 虽然轻量，但 DP 求解器和范围细化会增加少量固定延迟；未来工作可以探索完全异步或基于学习的调度器。
• 安全性与隔离 – 多租户场景可能需要额外的沙箱机制以防止跨请求干扰，而 L4 并未开箱即用地解决此问题。

结论：L4 表明，一个适度的、感知长度的调度层能够为 LLM 服务释放显著的性能提升，使大上下文应用对开发者和企业而言更加经济且响应更快。

作者

• Yitao Yuan
• Chenqi Zhao
• Bohan Zhao
• Zane Cao
• Yongchao He
• Wenfei Wu

论文信息

• arXiv ID: 2512.19179v1
• 分类: cs.DC
• 发布时间: 2025年12月22日
• PDF: 下载 PDF