微软+UBC+英伟达联合推出CASCADE：让LLM推理性能暴增2.4倍

当前大语言模型服务集群往往采用多负载混合部署的模式，同一套模型实例可能同时支撑聊天交互、代码生成、智能体工具调用、多步复杂推理等多种类型的请求。这种部署模式能够提升昂贵GPU资源的利用率，但也带来了新的调度难题：相同SLO标准下，不同请求的输入长度、生成长度、KV缓存复用情况差异可达数个量级，传统调度策略始终难以在SLO达标率、集群有效吞吐量、跨请求类公平性三者间找到最优平衡。

论文标题：Cascade: Exploiting SLO-Aware latency budget for fair and high goodput LLM inference serving

论文链接：https://arxiv.org/pdf/2608.06557

研究背景

大语言模型推理分为预填充和解码两个阶段，前者是计算密集型，后者是内存带宽密集型，服务提供商通常会针对两个阶段分别定义SLO：预填充阶段对应首包时间（TTFT），解码阶段对应单token生成间隔（TPOT）。

为了降低预填充阶段的计算开销，现在的服务系统普遍采用前缀KV缓存技术，将重复的上下文KV状态存储在不同层级的内存中，复用后可以大幅降低预填充耗时，不过当KV缓存存储在NVMe等深层存储介质时，状态传输的延迟也可能成为SLO达标的瓶颈。

传统的LLM服务系统中，请求调度和KV缓存管理是两个独立的模块：调度模块常用的FCFS策略会导致严重的队头阻塞，短请求可能被前面的长上下文请求卡住无法及时处理；SJF策略虽然能减少队头阻塞，但会系统性压低长上下文请求的优先级，导致代码、推理类请求的SLO达标率极低；EDF策略引入了截止时间感知，但无法区分相同截止时间下剩余工作量差异巨大的请求。而KV缓存管理模块通常只会根据缓存容量、复用概率、传输成本决定数据的留存、驱逐和恢复，不会考虑使用这个缓存的请求是否能承受对应的传输延迟，可能出现深层缓存命中反而导致SLO违规的情况。

研究团队通过对生产负载的分析发现，调度排队、资源竞争、KV缓存传输带来的延迟开销，本质上都是消耗同一个资源：请求的剩余延迟预算，也就是请求的SLO减去预测的剩余服务时间。不同请求的延迟预算差异极大，同样的1秒延迟，对于某些预算充足的请求来说影响很小，但对于预算已经所剩无几的请求来说就会直接导致SLO违规。如果系统能够感知每个请求的剩余预算，将不可避免的延迟开销转移到预算充足的请求上，就能在不额外提升硬件成本的前提下，同时优化SLO达标率和集群有效吞吐量。

CASCADE 核心设计思路

基于上述观察，研究团队提出了CASCADE ，这套大语言模型服务系统将单请求延迟预算作为核心依据，统一协调请求调度和跨内存层级的KV缓存管理，不需要修改模型权重，也不需要额外硬件支持。

请求进入服务节点后，首先会经过TTFT估算器，模块会结合请求的上下文长度、多层级前缀KV缓存命中情况、服务实例当前的负载，通过离线训练的预测模型输出不同场景下的预填充延迟。为了避免估计过于乐观导致SLO违规，系统会取实际负载和最大负载下的延迟平均值，再乘以一个经验保护系数得到最终的预估延迟。之后延迟预算引擎会用请求所属类别的SLO减去预估延迟，得到该请求的初始延迟预算。

预算为正的请求会进入Tier1优先级队列，预算为负的请求不会被直接丢弃，而是进入Tier2队列，系统会预留固定比例的批处理配额给Tier2的请求，同时会持续更新请求的预算，当集群负载下降、请求预算转正后，会将其重新提升到Tier1队列。

调度器每次迭代时，会先更新所有请求的剩余预算，也就是初始预算减去请求已经等待的时间，之后按照剩余预算从小到大排序，优先调度剩余预算最少的请求，这种策略不会像SJF那样系统性歧视长上下文请求，只要长请求的预算充足，就不会被持续压低优先级。

同时KV缓存管理也会基于剩余预算决策：当需要的KV缓存不在HBM中时，系统会计算从对应层级恢复该缓存需要的传输时间，如果传输时间在请求的剩余预算范围内，就启动预取，否则直接重算对应的前缀，避免传输延迟导致SLO违规。当HBM内存不足需要抢占时，系统会优先抢占剩余预算最多的请求，因为这类请求能够承受重执行带来的额外延迟，抢占后请求会回到队列，剩余预算会重新计算，避免出现持续抢占的情况。

实测效果

研究团队基于vLLM实现了CASCADE ，扩展了Vidur模拟器来模拟集群级调度和多层级KV移动，在NVIDIA GB200 NVL72硬件上采集了性能profile，测试覆盖了Qwen-2.5-72B、Llama-3-70B、Llama-3-405B三个主流大语言模型，以及包含聊天、智能体、代码、推理类请求的生产trace。

测试结果显示，相比于vLLM默认的FCFS调度器，CASCADE 的有效吞吐量最高提升2.4倍，SLO违规率降低40%。在长请求占比较高的trace中，增益更加明显，比如混合trace和Llama-3-405B的代码重负载trace中，有效吞吐量提升可达2.7倍，这是因为传统调度策略下长请求会卡住后续的短请求，而CASCADE 会将等待转移到预算充足的长请求上，避免短请求超时。在负载较轻的trace中，增益也能达到1.1倍到1.5倍，这部分收益主要来自于预算感知的KV缓存预取。

在公平性方面，CASCADE 的Jain公平指数在所有测试场景下都保持在0.98到1.0之间，是所有参测策略中最高的。SJF策略的公平性最低，在部分场景下甚至降到0.6左右，主要是因为长上下文请求被持续压低优先级，SLO达标率极低。FCFS和EDF的公平性介于两者之间，但它们的公平是建立在所有请求的SLO违规率都很高的基础上，整体有效吞吐量远低于CASCADE。

在集群容量敏感性测试中，当减少服务实例数量时，FCFS和EDF的有效吞吐量会迅速降到基线的0.05倍，SLO违规率超过90%，而CASCADE 在Qwen-2.5-72B场景下，即使减少22%的GPU实例，有效吞吐量仍然高于满配下的FCFS，同时SLO违规率保持在16%以下。在负载压力测试中，当QPS从32提升到48时，FCFS和EDF的有效吞吐量降到基线的0.05倍，违规率超过90%，而CASCADE 仍然能保持1.5倍于基线的有效吞吐量，违规率仅为14%。

落地价值

对于云服务商和大模型部署方来说，CASCADE 的价值主要体现在三个方面：首先是能够在不额外增加硬件成本的前提下，大幅提升集群的有效吞吐量，降低单请求的服务成本；其次是能够保障异构负载下的公平性，不会出现长上下文类请求被系统性饿死的情况，适合多业务混合部署的场景；最后是实现成本低，CASCADE 基于vLLM开发，只增加了预算相关的逻辑模块，不需要修改底层的连续批处理、分页KV缓存等机制，也不需要调整模型权重，现有生产集群可以较低成本接入。

目前大模型服务的成本仍然是制约规模化落地的核心因素之一，这类面向生产场景的调度优化，能够在现有硬件基础上充分释放集群性能，同时保障服务质量，对于推进大模型的商用落地有较高的实用价值。