02-黄炜喆-xLLM在复杂业务场景下的统一调度优化实践.pdf

1、演讲嘉宾：黄炜喆xLLM在复杂业务场景下的统一调度优化实践京东xLLM团队:面向国产芯片的LLM推理引擎 Github全面开源：https:/ 技术报告：https:/arxiv.org/abs/2510.14686 国产芯片支持情况：昇腾：性能对比vllm-ascend、MindIE提升 1.7X-2.2X 已支持昇腾、寒武纪、摩尔线程、天数智芯等国产芯片 国产模型支持情况：智谱GLM：默认使用xLLM作为国产化芯片推理引擎，性能优于硅基流动提供的闭源推理引擎 支持DeepSeek系列、Qwen系列、GLM系列、Kimi系列等数十种大模型、多模态大模型、文生图、文生视频、生成式推荐等各类模型

2、 开源推广：开源6个月（Github star 1.2k），已覆盖包括大型国企、运营商、智算中心、医院、高校、政府等xLLM服务-引擎解耦框架Feature0 1背景介绍0 2技术落地挑战0 3解决方案0 4结果展示0 5总结与未来展望0 1背景介绍场景1:多优先级和SLO共存的复杂场景不同业务线请求拥有各自的SLO时延要求(首字时延TTFT SLO、字间时延TPOT SLO)请求附带差异化的业务优先级（如VIP客户、核心业务链路），通常来说满足高优请求的时延会带来更大的价值收益不同优先级请求一天的Workload Trace但现有框架没有同时兼顾请求SLO和优先级流量波动，优先级占比波动低优

3、尖峰流量远多于高优高优峰流量远多于低优多优先级 共置 vs.分离左图：共置 vs 分离（按照平均负载）右图：分离情况下不同优先级请求的时延情况直接的想法是为不同优先级请求分配独立的计算集群来满足时延静态划分资源：难以适应不同优先级请求波动的负载，容易造成资源空闲浪费动态运行时调整：带来运行时的实例宕机和不稳定Proposal：不同优先级请求共享资源以最大化利用率，并通过调度来协调按照优先级划分资源时低优请求SLO满足率严重不足，高优请求资源浪费多优先级场景：问题形式化如何根据请求的!(#$!,#$!)和优先级权重%(!)设计更加合适的per-request 收益函数(|!,%(!)?相比强NP

4、-hard的带有释放时间和任务价值的单机调度问题1|r_j,d_j|w_jU_j更为复杂设=1,表示一个有限的优先级级别集合。每个请求 被分配一个优先级类别()。设:!为优先级权重映射，并定义#(%):=()为请求 的优先级权重（可选地有 (）。若请求 达到其SLO相关的延迟目标，则系统获得收益()。目标是最大化已服务请求集合 上的总收益：max =4%+()目标定义多优先级场景：收益函数()朴素的想法：Weighted SLO Attainment 存在的问题：(1)丢弃或推迟trick：可以立即丢弃或无限期推迟任何判定为TTFT/TBT SLO无法达成的请求来hack;(2)对per-to

5、ken的延迟不敏感：平均指标TPOT掩盖了各token输出时间的波动性；(3)未区分首token和decode token：TTFT 衡量初始响应速度；TPOT 反映输出的流畅性改进的想法：Token-level Deadline-aware Gain(TDG)场景2:TPOT敏感的交互场景一些业务场景例如客服机器人等对话应用对输出流畅性要求极高，TPOT/TBT高度敏感Prefill和Decode混合运行不可避免会产生干扰LLM整体的推理流程：计算密集型的Prefill+多个小步Decode如何能更好的缓解Prefill和Decode的干扰？场景2:TPOT敏感型交互场景Proposal：采

6、用PD分离架构，使得P和D之间完全不会产生干扰PD分离：请求在Prefill实例上执行完后将KV Cache传输到Decode实例上，由Decode继续执行优势：消除PD在同一个batch内执行的互相干扰可以为Prefill和Decode设置不同的并行策略0 2技术落地挑战一.多优先级调度挑战挑战一：如何有效平衡延迟和优先级挑战二：静态调度器在动态工作负载下的自适应不足 EDF(earliest-deadline-first)更适合低负载场景；在高负载下过于“乐观”SJF(shortest-job-first)更适合高负载场景；在低负载下引发短请求饥饿 Priority-First虽然高优表现