当前位置：首页 > news >正文

【Deepseek学习大模型推理】MOONCAKE: A KVCache-centric Architecture实验部分（下）

news 来源：原创 2025/4/26 6:37:44

5 评估

如前所述，根据Kimi的历史统计数据，MOONCAKE在A800和H800集群上分别实现了比基于vLLM的原有系统多处理115%和107%的请求量。为进一步验证这一结果并确保可复现性，本节通过虚拟LLaMA3-70B模型对MOONCAKE展开一系列端到端实验与消融实验，旨在回答以下问题：

在实际场景中，MOONCAKE是否优于现有LLM推理系统？
相较于传统前缀缓存方法，MOONCAKE的存储设计是否显著提升了系统性能？
5.1 实验设置
测试平台
在可复现性实验中，系统部署于高性能计算节点集群以评估性能。集群中每个节点配置8块NVIDIA A800-SXM4-80GB GPU和4个200 Gbps RDMA网卡。MOONCAKE存储模块的KVCache块大小设为256。在部署MOONCAKE时，每个节点根据启动参数作为预填充实例或解码实例运行；而部署其他系统时，每个节点仅承载单个实例。

评估指标
具体而言，我们测量每个请求的首令牌生成时间（TTFT）和尾部延迟（TBT），其中TBT通过计算最长10%的token到达间隔的平均值确定。如§2所述，TTFT阈值设为30秒，TBT阈值根据场景分别设为100 ms、200 ms和300 ms。若请求的TTFT与TBT均低于各自阈值，则视为有效请求，有效请求占总请求的比例定义为有效请求容量。为简洁起见，后续未明确提及TTFT的实验均默认满足TTFT阈值。此外，为更细致地对比缓存性能，我们还测量预填充阶段的GPU耗时及每个请求的缓存命中率。

5.1 实验设置（续）

基线系统
我们选择vLLM[14]（当前最先进的开源LLM推理系统之一）作为实验基线。vLLM通过连续批处理（continuous batching）和分页注意力（PagedAttention）技术显著提升了推理吞吐量。尽管优势显著，但vLLM将预填充与解码阶段耦合的架构在长上下文场景中可能破坏解码稳定性。近期vLLM更新集成了前缀缓存（prefix caching）和分块预填充（chunked prefill）功能，以优化长上下文场景下的性能指标（如TTFT和TBT）。在实验中，我们对比了vLLM的这些新特性。实验使用vLLM的最新版本（v0.5.1），但由于当前实现的限制，我们分别单独测试了该版本的前缀缓存与分块预填充功能。

5.2 端到端性能

在端到端实验中，我们评估了MOONCAKE与基线系统在多种工作负载下的请求处理能力。具体而言，我们测量了在定义的SLO阈值范围内可维持的最大吞吐量。测试中采用了三类工作负载：两类从Kimi采样的真实场景追踪数据（分别代表在线对话与工具&代理交互），以及一个覆盖不同推理场景的合成负载。下文将首先描述这些工作负载的独特特性，继而讨论实验结果。最后，我们分析预填充阶段的GPU计算时间，进一步展示MOONCAKE Store在提升缓存利用率与降低计算成本方面的优势。

5.2.1 工作负载

合成工作负载。合成工作负载由多个公开可用数据集组合构建而成。我们将真实追踪中的请求分为三类：短对话、工具与代理调用、长文本摘要与问答。针对每种类别，我们分别选取了以下数据集：ShareGPT[32]、Leval[29]和LooGLE[30]。
ShareGPT包含输入长度较短的多轮对话。Leval是用于评估模型在长上下文场景中性能的基准测试集，可模拟请求中包含工具与代理交互典型冗长系统提示的场景。LooGLE专为长上下文问答与摘要任务设计，输入长度最高达100k tokens，涵盖多轮问答与单轮摘要生成，适用于长文本摘要与问答场景。总体而言，合成工作负载具有最长的平均输入长度。尽管其前缀缓存比例最高，但缓存命中较为分散，因此需要较大缓存容量。
在预处理阶段，每轮对话交互被映射为独立请求，并包含先前交互的输入与输出。对于包含相同冗长提示的多问题数据集，每个问题及其前置提示被视作单个请求。我们以1:1:1的比例合并处理后的数据集，在保留多轮对话请求内部时序关系的同时进行随机打乱。由于数据集未提供到达时间信息，我们通过泊松过程以预设速率调度请求，模拟真实场景条件。

5.2.2 有效请求容量

为评估不同工作负载下满足SLO（服务级别目标）的最大请求数量，我们测试了四种系统配置：MOONCAKE、vLLM、启用前缀缓存功能的vLLM，以及启用分块预填充功能的vLLM，每种配置均使用16个节点。

对话工作负载。该工作负载的测试结果如图1所示。由于输入长度变化较大且输出长度较长，预填充阶段的长上下文会导致vLLM系统的TBT（相邻输出间隔时间）出现显著波动。尽管分块预填充技术减少了解码干扰，但在预填充阶段提升MFU（内存占用效率）与解码阶段的TBT约束之间取得平衡仍具挑战。即使满足TTFT（首令牌生成时间）的SLO要求，其有效请求容量仍不理想。与vLLM相比，MOONCAKE的有效请求容量实现了显著提升。
在这里插入图片描述

工具与代理工作负载。相比之下，工具与代理工作负载具有高比例的前缀缓存和较短的输出长度，这使得vLLM系统更具优势——短暂的预填充时间对输出影响极小。然而如图6所示，由于预填充处理时间较长，vLLM与启用分块预填充的vLLM在解码阶段遭遇更严重的中断，导致其有效缓存容量低于启用前缀缓存的vLLM。MOONCAKE通过全局缓存池大幅增加缓存容量，并借助节点间传输优化缓存利用率，在高前缀缓存场景中表现卓越。因此，在200 ms阈值下，其有效缓存容量相比启用前缀缓存的vLLM提升了42%。
在这里插入图片描述

合成工作负载。合成工作负载具有最长的平均输入长度且缓存热点分散，导致在较小缓存容量下缓存利用率低下。如图7所示，MOONCAKE处理的多数请求保持TBT（相邻输出间隔时间）在100 ms以内，而vLLM处理的约20%请求超过300 ms。启用前缀缓存和分块预填充的系统性能与vLLM相似，因它们无法缓解长上下文对解码阶段的影响。相比vLLM，在200 ms阈值下，MOONCAKE的有效请求容量提升40%。

在这里插入图片描述
LLM Serving有效吞吐量的最大化实现 https://hub.baai.ac.cn/view/37129

5.2.3 预填充阶段GPU时间

预填充阶段GPU时间与请求的TTFT（首令牌生成时间）和服务成本呈正相关，其长短由请求的输入长度和缓存命中率决定。我们分析了不同工作负载下预填充阶段的平均GPU时间（如图8所示）。对于MOONCAKE而言，对话工作负载因输入长度更长且前缀缓存比例较低，导致预填充GPU时间最长。合成工作负载虽拥有最长平均输入长度，但由于其前缀缓存比例最高且缓存热点分散，在MOONCAKE的全局缓存池中实现了最优缓存命中率。因此，其预填充GPU时间反而短于对话工作负载。工具与代理工作负载因平均输入长度最短且前缀缓存比例较高，预填充GPU时间最短。
在这里插入图片描述

在不同系统对比中，MOONCAKE通过全局缓存池充分实现前缀缓存，相比vLLM显著降低预填充GPU时间：对话、工具与代理、合成工作负载分别减少36%、53%和64%。启用前缀缓存的vLLM依赖高带宽内存（HBM）的本地缓存，其容量远低于MOONCAKE。其预填充GPU时间在对话和工具与代理工作负载中分别比MOONCAKE高1.43倍和1.40倍。然而在缓存热点更分散的合成工作负载中，启用前缀缓存的vLLM预填充GPU时间几乎与普通vLLM持平，但仍达到MOONCAKE的2.59倍。启用分块预填充的vLLM为维持解码阶段较低TBT（相邻输出间隔时间）而牺牲部分预填充效率，导致预填充GPU时间最长：三种工作负载中分别为MOONCAKE的1.90倍、2.68倍和3.33倍。

5.3 MOONCAKE Store

为解答问题2，我们分析了MOONCAKE Store的全局缓存池对系统性能的影响。分析表明，尽管使用本地DRAM构建KVCache内存相比仅依赖高带宽内存（HBM）可提升缓存容量，但将缓存限制在单个节点仍会导致缓存利用率欠佳。我们将首先对缓存容量需求进行定量分析，随后通过实际工作负载实验验证其优势。

5.3.1 缓存容量的定量分析

图9：不同缓存容量下前缀缓存命中率的定量分析。我们仅考虑请求序列，未考虑预填充计算时间或缓存中热点副本等因素。300万token容量的虚线代表本地缓存容量，交叉点表示缓存命中率与理论最大命中率的比率。
在这里插入图片描述

以LLaMA3-70B模型为例，单个token所需的KVCache大小为320 KB。即使预留约1 TB的DRAM用于本地缓存，该配置仅能存储约300万token，显然不足。图9展示了不同工作负载及其组合下的理论缓存命中率。
结果显示，在大多数场景中，容量为300万token的本地缓存仅能达到理论最大命中率的不足50%。我们进一步发现，对于这些工作负载，5000万token的缓存容量几乎可达到100%的理论最大命中率，而这需要至少20个节点的DRAM进行池化。
以上结果表明，全局缓存通过整合多节点资源显著提升了容量，从而提高缓存命中率并减少GPU时间。
在这里插入图片描述

在这里插入图片描述

5.3.2 实际工作负载实验

为评估全局缓存与本地缓存机制的有效性，我们聚焦于两项指标：缓存命中率和预填充阶段的平均GPU计算时间。实验配置了一个包含10个预填充节点的集群，并将所有请求的输出长度限制为1，以隔离解码阶段的影响。在本地缓存设置中，每个节点的缓存容量为300万token，但只能访问自身缓存。全局调度器会将请求定向至前缀匹配率更高的节点，以最大化缓存利用率。相比之下，在全局缓存设置中，每个节点同样拥有300万token容量，但可通过主动的节点间缓存迁移实现全集群缓存共享。
在这里插入图片描述
实验数据（如图10所示）表明，在所有测试负载下，全局缓存的命中率更高且预填充阶段的平均GPU计算时间更短。与本地缓存相比，全局缓存的缓存命中率最高提升136%，预填充计算时间最多减少48%。

5.3.3 缓存副本机制
基于第4.2节讨论的缓存负载均衡调度策略，MOONCAKE Store中的缓存键（cache keys）可能以副本形式分布于不同机器上，从而降低热点缓存的访问延迟。为进一步探究系统的动态行为，我们统计了三种工作负载下缓存键的副本数量，如图11所示。
在这里插入图片描述
图11：不同工作负载下缓存键的复制次数
我们每30秒持续监测并记录所有缓存块的键及其计数，随后根据所有样本的累计计数对缓存键进行排序。此图展示了按排序后处于第10、100、1000和10,000位的缓存键的复制次数随时间的变化情况。

可以观察到，在对话（conversation）和工具/代理（tool&agent）工作负载中，存在高度集中的热点缓存（例如排名前100的键）。系统稳定后，这些热点缓存的副本几乎分布于预填充池中的所有实例上。相比之下，合成（synthetic）工作负载的共享前缀缓存较少，导致副本数量更少且存在潜在波动，即使是对排名前10的缓存块也是如此。这表明，第4.2节提出的调度策略能有效为热点缓存提供副本支持，尤其在前缀缓存高度集中的场景中表现显著。
在这里插入图片描述

5.4 KVCache传输性能

5.4.1 传输引擎

MOONCAKE的传输引擎旨在实现节点间高效缓存传输。我们将其延迟与主流方案进行对比，选取了两种基准方法：基于Gloo后端的torch.distributed和基于TCP的传输。所有方案均在64并发级别和128 KB最小传输粒度下测试。如图12所示，传输引擎的延迟显著低于其他方法。在传输40 GB数据（对应LLaMA3-70B模型128k token的缓存规模）时，传输引擎在4×200 Gbps和8×400 Gbps网络配置下分别达到87 GB/s和190 GB/s的带宽。这些速率比TCP协议分别快约2.4倍和4.6倍。该传输引擎的代码后续将开源，因其作为一个解耦且基础的工具，可广泛应用于多种场景（例如，它也被用于Moonshot AI的检查点传输服务）。
在这里插入图片描述

5.4.2 MOONCAKE的带宽需求

MOONCAKE的全局缓存池依赖高效的节点间缓存传输，以将缓存传输时间隐藏在GPU计算时间内。我们通过模拟24 Gbps至400 Gbps的带宽范围，并测量§5.2.1所述合成工作负载下的传输时间与首Token生成时间（TTFT），评估网络带宽对系统性能的影响。图13a显示，请求的平均TTFT随带宽增加而降低。当总通信带宽超过100 Gbps时，平均TTFT保持在2秒以下，显著优于重计算基线的TTFT。然而，当带宽低于100 Gbps时，系统性能显著下降，表现为TTFT急剧上升和明显的网络拥塞（如图13b所示，实际传输时间与理论值出现显著偏差）。因此，我们建议采用至少100 Gbps的网络带宽以确保系统性能最优。
在这里插入图片描述

5.4.3 端到端延迟分解
MOONCAKE中单个推理请求的延迟可分为五部分：1）调度与排队时间；2）分层预填充时间；3）缓存传输时间；4）解码节点将缓存从DRAM加载至HBM的时间；5）解码时间。我们通过实验分析了前缀缓存比率为0%和95%时各组件的占比，如图14所示。
在这里插入图片描述

首先，图中明显可见，引入前缀缓存显著减少了预填充时间。具体而言，当输入长度为128k tokens时，前缀缓存将预填充时间降低了92%。此外，MOONCAKE引入的额外开销对系统性能影响极小。调度（Schedule）、传输（Transfer）和缓存加载（Load Cache）组件可与模型推理异步执行，因此不影响系统吞吐量。

进一步分析表明，这些开销导致的TTFT（首Token生成时间）增幅，小于前缀缓存带来的TTFT缩减量。即使计入所有开销，MOONCAKE的前缀缓存仍能在128k tokens输入长度下将TTFT降低86%。

5.5 P/D比率

作为部署的P/D分离系统，本节探讨不同P/D比率对系统性能的影响。我们将P/D比率定义为预填充节点与解码节点的数量比。通过使用包含16个节点但具有不同P/D比率的集群，我们测量了§5.2.1所述合成工作负载下的平均TTFT（首Token生成时间）和TBT（后续Token生成时间）。随后，我们根据§5.2.2中提出的方法计算有效请求容量，将TTFT和TBT的阈值分别设为10秒和100毫秒。
在这里插入图片描述
增加预填充节点数量会减少TTFT，但会增加TBT，反之亦然（图15b）。因此，需在TTFT与TBT之间寻求平衡。图15a表明，当P/D比率约为1:1时，MOONCAKE的有效请求容量达到峰值，表明预填充与解码集群的负载相对均衡。

值得注意的是，部分先前研究[7,9]提出动态切换节点在预填充与解码角色之间的功能。然而，在实际部署中，我们发现在线流量的统计特性通常较为稳定。因此，我们选择固定P/D比率，同时持续监控预填充与解码集群的负载，仅在出现显著负载波动时切换节点角色。
以下是用户要求的逐句翻译，格式与原文一致，引用标注符合规范：

6 相关工作

提升LLM服务系统效率的研究主要集中在调度、内存管理及资源解耦领域。生产级系统如FasterTransformer、TensorRT-LLM和DeepSpeed Inference通过优化设计显著提升吞吐量。Orca采用迭代级调度实现多阶段并发处理，而vLLM通过动态KVCache管理优化内存效率。FlexGen、Sarathi-Serve和FastServe则通过创新的调度与交换策略，在有限硬件资源下有效分配负载，这些优化方法往往互补。

进一步的优化工作[[7–9]]推动了预填充（prefill）与解码（decoding）阶段的分离，最终形成MOONCAKE的解耦架构。MOONCAKE的设计基于这些成果，尤其受益于vLLM开源社区的支持，我们对此深表感谢。

前缀缓存（Prefix caching）被广泛用于LLM推理系统以复用KVCache，降低计算开销[[14,34]]。Prompt Cache预计算并存储高频文本的KVCache，显著减少推理延迟。SGLang通过RadixAttention机制，在基数树结构中采用LRU缓存策略，实现多场景的自动缓存共享。

在这些方法中，与MOONCAKE同期的工作CachedAttention提出了一种分层KV缓存系统，利用高性价比存储介质保存所有请求的KVCache。MOONCAKE的架构设计与CachedAttention有诸多相似之处，但在长上下文推理中，KVCache规模极大，需结合高容量存储与高效数据传输，以及以KVCache为中心的全局调度策略。此外，MOONCAKE并非独立的缓存服务，而是整合了内存高效缓存机制与缓存感知调度策略，进一步提升前缀缓存效率。

分布式KVCache池的效益依赖于缓存命中率，而命中率随单位token缓存容量的降低而提升（在固定总容量下）。因此，正交技术如KVCache压缩[[39–41]]和KVCache友好的注意力架构[[42,43]]可进一步增强本方案的效果。