[论文] OServe：通过时空工作负载编排加速 LLM 服务

Source: arXiv - 2602.12151v1

概述

本文介绍了 OServe，一种针对大语言模型（LLMs）的全新服务系统，能够动态适应真实工作负载中空间（不同请求规模和内存占用）和时间（随时间变化的请求组合）异质性。通过编排异构的模型副本并实时切换，OServe 能够将吞吐量提升至现有静态服务堆栈的 2×，同时保持延迟的可预测性。

关键贡献

• 工作负载感知调度器，根据当前请求分布选择异构模型部署的最佳组合（例如，不同的量化级别、分片策略）。
• 自适应部署切换机制，在预测的工作负载模式变化时迁移或重新配置模型副本，且不会产生长时间停机。
• 全面评估在生产级别的追踪数据上显示，相比 vLLM 和 TGI 等最先进的服务框架，平均提升 1.5 倍（最高可达 2 倍）。
• 开源原型，可与流行的推理运行时（TensorRT‑LLM、PyTorch Serve）集成，并可直接嵌入现有推理流水线。

方法论

1. 表征异构性 – 作者首先对一系列 LLM 部署（全精度、8 位、4 位、张量并行 vs 流水线并行）进行画像，以构建 资源‑性能 查找表（GPU 内存 ↔ 延迟 ↔ 吞吐量）。
2. 实时工作负载监控 – 一个轻量级收集器每秒聚合统计信息：请求长度、标记数以及内存压力。
3. 调度算法 – 利用查找表和实时指标，混合整数线性规划（通过快速启发式算法求解）决定在每个 GPU 节点上运行每种部署类型的副本数量。目标在 吞吐量最大化 与 延迟 SLA 合规 之间取得平衡。
4. 预测切换 – 短期时间序列模型（类似 ARIMA）预测工作负载变化。当预测的变化超过置信阈值时，OServe 会触发 部署迁移：在后台启动新的组合，用少量请求进行预热，然后优雅地清空旧副本。
5. 评估设置 – 实验使用来自云端聊天机器人服务的真实请求轨迹（约 10 k 请求/小时，包含短提示和长完成的混合），在 4 节点 GPU 集群（每节点 8 × A100）上进行。基线包括静态同构部署和流行的 vLLM 调度器。

Results & Findings

• 调度器始终会为高吞吐量的短提示选择低精度（4 位）副本，并为长上下文生成选择全精度分片。
• 自适应切换降低了“冷启动”惩罚：在工作负载转变后，OServe 能在约 30 秒内达到新的最佳配置，而静态基线则会出现持续的延迟峰值。
• 能耗下降约 12 %，因为系统可以在不需要时退役高内存副本。

实际影响

• 云服务提供商的成本节约 – 通过在同一 GPU 队列上承载更多请求，运营商可以推迟硬件升级或降低抢占式实例的支出。
• 基于 SLA 的 SaaS 产品 – 聊天机器人和代码助手服务即使在流量激增期间（例如产品发布）也能保证更严格的延迟界限。
• 开发者灵活性 – 团队可以只暴露一个推理端点，OServe 在后台静默切换量化层级或分片策略，从而无需维护多个部署流水线。
• 边缘与设备端场景 – 同样的原理可应用于异构边缘加速器（CPU、NPU、GPU），这些设备的内存限制差异巨大。

限制与未来工作

• 模型粒度 – OServe 目前假设一组固定的预编译部署变体；扩展到任意即时量化将提升灵活性。
• 预测准确性 – 工作负载预测组件在日周期模式下表现良好，但在突发激增（例如闪电式人群）时可能滞后。更鲁棒的在线学习模型是一个有前景的方向。
• 多租户隔离 – 本文聚焦单租户工作负载；在多个客户之间处理安全性和公平性需要额外的调度约束。
• 硬件多样性 – 实验仅限于同质的 A100 集群；在混合代 GPU 或新兴加速器（如 Habana、AWS Trainium）上的评估留待后续研究。

作者

• Youhe Jiang
• Fangcheng Fu
• Taiyi Wang
• Guoliang He
• Eiko Yoneki

论文信息

• arXiv ID: 2602.12151v1
• 分类: cs.DC
• 发表时间: 2026年2月12日
• PDF: 下载 PDF