Mooncake技术报告

发现 KVCache 的调度是 LLM 服务调度的核心。为了提高整体吞吐量，通常有两种通用方法：

1) 尽可能多地复用 KVCache 以减少所需的计算资源；

2) 最大化每个批次中的令牌数量以提高模型 FLOP 利用率 (MFU)。

然而，从远程位置复用 KVCache 会延长 TTFT，而较大的批次大小会导致 TBT 增大。因此，这两种以吞吐量为导向的优化方法都可能导致违反与延迟相关的 SLO。

解码阶段具有不同的优化目标和约束。其目标是在解码批次中聚合尽可能多的令牌，以改进 MFU。然而，这一目标不仅受到 TBT SLO 的限制，还受到 VRAM 中可容纳的聚合 KVCache 总大小的限制。

• 整体吞吐量和TBT的权衡，kv cache数量的限制

主要思想：

1） 将尽可能多重用 KVCache 传输到选定的预填充实例；

2） 以块/层的形式完成预填充阶段，并将输出 KVCache 持续流式传输到相应的解码实例；

3） 加载 KVCache，并将请求添加到解码实例的连续批处理流程中，以生成请求输出

面临的问题：在prefill阶段，主要目标是尽可能地复用 KVCache，以避免冗余计算。然而，等待存储在低层存储上的 KVCache 可能会违反 TTFT SLO。KVCache 服务器的高需求可能会导致网络拥塞，从而延长等待时间。

一种解决思路：Conductor 还负责预测 KVCache 块的未来使用情况，并相应地执行交换和复制等调度操作。最热门的块应该复制到多个节点，以避免获取拥塞，而最冷门的块应该被交换出去，以降低预留成本。预填充调度还受到预填充节点中 DRAM 空间可用性的限制，尤其是在大部分内存都预留给全局 KVCache 池的情况下。

预测生成长达，短期的负载预测，设定拒绝策略。

1）KVCache重用
在接收到请求后，预填充节点加载前缀缓存（若存在）至GPU内存，以初始化推理。这一过程需要在重用KVCache、均衡节点负载以及满足TTFT要求之间寻找平衡。

2）增量预填充
预填充节点使用前缀缓存完成当前阶段的计算，并将新增的KVCache存储回CPU内存。当未缓存的输入token数量超过一定阈值时，预填充阶段将分块执行，以流水线方式提高计算效率。

3）KVCache传输
Messenger服务异步管理KVCache的跨节点传输，结合增量预填充步骤，将每层生成的KVCache实时传输至解码节点的CPU内存，最大限度降低等待时间。

4）解码
当解码节点接收完整的KVCache后，请求被加入连续批处理队列。Conductor根据节点负载预选解码节点，并由本地调度器二次验证实际负载情况。如果负载超出SLO限制，该请求将被拒绝，先前的预填充计算资源也随之浪费。