KV$缓存与KV$块。除了在处理单个请求的prefill和decode阶段之间复用KV$外，如果不同请求共享相同的前缀token，KV$也可以在这些请求之间复用。如图2（❷）所示，“A paper on”的K和V值对于#Req0和#Req1是相同的。因此，即使#Req0完成解码，我们仍然可以缓存其KV$以供#Req1使用，这极大地改善了#Req1的响应时间（即首token时间，TTFT）：它在prefill阶段只需计算“AI is”的K和V。KV$缓存通过节省计算量进一步提高了服务吞
吐量。鉴于此，现有服务系统都会缓存已完成请求的KV$。我们将此方法称为KV$缓存【索引29，vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention，2023，SOSP】【索引18，Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention，2024，USENIX ATC】【索引19，Prompt Cache: Modular Attention Reuse for Low-Latency Inference，2024，MLSys】【索引68，Efficiently programming large language models using sglang，2023，CoRR】【索引25，Ragcache: Efficient knowledge caching for retrieval-augmented generation，2024，CoRR】【索引36，Cachegen: KV cache compression and streaming for fast large language model serving，2024，ACM SIGCOMM】【索引64，Stateful Large Language Model Serving with Pensieve，2023，CoRR】，尽管也存在其他名称如前缀缓存或prompt缓存。KV$可以被缓存在GPU内存、主机内存（或远程机器内存），甚至SSD上。由于在token级别检查前缀匹配可能成本高昂，现有KV$系统的缓存粒度是块（block），每个块包含可配置数量token的KV。例如，vLLM【索引29，vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention，2023，SOSP】默认将16个token分组为一个块。
Figure 2: 展示了：❶ 一个预填充请求（Req#0）的KV$如何被Req#0的解码过程复用，以及 ❷ KV$如何被未来一个请求（Req#1）的预填充过程复用。
多轮服务。通过多轮对话与LLM交互是提升服务质量的常见模式【索引57，Autogen: Enabling next-gen llm applications via multi-agent conversations，2024，First Conference on Language Modeling】【索引55，Mint: Evaluating llms in multi-turn interaction with tools and language feedback，2023，arXiv】。具体来说，用户在收到LLM的生成内容后，可能会带着新的prompt发出下一轮请求。由于LLM需要之前的对话上下文进行处理，服务系统会将之前轮次的请求输入和输出拼接到新请求的输入之前，然后将这个新的输入送入LLM进行服务。为了方便管理多轮请求的历史，一个多轮对话中的请求通常被分组在一个会话（session）中。多轮请求自然会复用前几轮的KV$，因为当前的LLM系统会有意将历史输入和输出作为前缀附加到每个新请求上。
### 现实世界中的KV$工作负载特征
Trace A vs. Trace B。我们收集了两种追踪数据（A和B），代表两种典型的LLM服务工作负载。Trace A代表一个常见的to-C（面向消费者）场景，用户通过云端构建的服务与模型交互，如ChatBot（Text类型）或文件/多模态/搜索服务。to-C工作负载的一个关键特征是通常有人类参与其中（human-in-the-loop）。Trace B代表一个to-B（面向企业）工作负载，商业用户通过计算机程序调用云端托管的与OpenAI兼容的API与LLM交互【索引41，Openai developer platform】。API调用对商业用户至关重要，因为他们可以系统地利用LLM自动化任务，如文档翻译或用户请求分类。Trace B没有请求类型信息，因为与当前其他供应商提供的LLM接口调用类似【索引41，Openai developer platform】【索引20，Gemini api，2025】【索引4，Claude api，2025】，这些信息在客户端被拼接。
3.2 现实世界中的KV$复用分析
**KV$的可复用性**。图4展示了两种追踪数据在理想情况下的缓存命中率，即假设缓存容量无限。可以看出，LLM工作负载可以从缓存中受益——在Trace A和B上分别有62%和54%的命中率。命中率的计算方式如下：对于一个trace中LLM需要计算的总共N个KV$块，如果命中率为62%，这意味着这N个块中的62%可以复用先前请求计算并缓存的KV$。虽然理想命中率很高，但它低于在合成工作负载上报告的命中率（例如，超过80%【索引64，Stateful Large Language Model Serving with Pensieve，2023，CoRR】【索引68，Efficiently programming large language models using sglang，2023，CoRR】【索引18，Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention，2024，USENIX ATC】）。
Figure 4: 在真实世界LLM服务工作负载下一天内KV$缓存的理想缓存命中率分析。报告的访问和命中块数已进行归一化处理。
**单轮和多轮请求对KV$复用的同等重要性**。虽然普遍认为多轮请求是缓存命中的主要贡献者【索引64，Stateful Large Language Model Serving with Pensieve，2023，CoRR】【索引18，Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention，2024，USENIX ATC】，但在to-B工作负载（Trace B）上情况并非如此。图5显示了每种请求类型的贡献及其多轮比例。对于Trace A，它主要由聊天机器人发送的请求（78%）主导，除了多模态请求外，所有请求类型都有相似的多轮比例（47-51%）。对于Trace B，它只有API请求，且多轮比例可忽略不计（小于0.1%）。然而，单轮请求为Trace B贡献了97%的总缓存命中。
Figure 5: 我们收集的追踪数据中请求的工作负载类型和多轮比例。
单轮API请求在to-B工作负载中主导命中的原因。这主要有两个原因。首先，LLM API请求通过共同的系统提示（system prompts）共享KV$。具体来说，每个请求包括：（1）提供任务指令的系统提示（例如，文档翻译指南）和（2）包含特定请求数据的用户提示（例如，目标文档）。当程序进行API调用时【索引34，Parrot: Efficient serving of llm-based applications with semantic variable，2024，OSDI】，它们通常在程序中硬编码相同的系统提示，从而使得即使是单轮请求，也能在不同请求间共享KV$。其次，API请求通常表现出快速的提交率（例如，>10 QPS），这使得能够频繁复用来自系统提示的相同共享KV$。
**跨用户KV$命中罕见。图6展示了在无限大小KV$缓存假设下，用户之间的缓存命中热力图。颜色越深表示归一化后的命中次数越高。我们可以看到，对于每个用户，大多数命中都来自他们自己提交的请求（对角线）。虽然用户自然会复用自己请求的KV$——无论是通过多轮对话，还是通过程序调用具有相同系统提示的API来完成相同任务，但较低的用户间命中率表明，用户倾向于自定义自己的系统提示，而不是使用第三方库提供的模板提示【索引6，Prompt library】。因此，我们建议在设计KV$系统时，应更多地关注用户内（intra-user）的KV$复用，而非用户间（inter-user）的复用【索引19，Prompt Cache: Modular Attention Reuse for Low-Latency Inference，2024，MLSys】【索引68，Efficiently programming large language models using sglang，2023，CoRR】【索引25，Ragcache: Efficient knowledge caching for retrieval-augmented generation，2024，CoRR】【索引36，Cachegen: KV cache compression and streaming for fast large language model serving，2024，ACM SIGCOMM】。
Figure 6: 分析一个用户是否可能命中由另一个用户缓存的KV$。颜色越深，归一化的命中次数越高。注意，我们放大了对角线以防其过细，因为追踪数据提供商服务了大量用户。
**KV$复用存在倾斜。图7显示了不同用户贡献的KV$缓存命中以及累积命中情况。KV$命中模式高度倾斜：Trace A中19%的用户请求和Trace B中4%的用户请求贡献了超过90%的KV$块命中。这种倾斜源于两个因素。首先，请求在用户间的分布不均，尤其是在Trace B中。图8显示了不同用户发送的归一化请求数量：15%的用户（头部用户）贡献了Trace B中90%的请求。由于KV$命中主要发生在同一用户的请求之间（见图6），请求数量的倾斜预计会导致KV$命中的类似倾斜。其次，即使请求由不同用户相对均匀地发送，单个用户在KV$命中方面也存在显著差异。如图8所示，Trace A的请求分布呈中度倾斜：19%的用户产生50%的请求，72%的用户产生90%的请求。然而，KV$命中仍然是倾斜的。我们怀疑这是因为他们倾向于进行多轮请求。
Figure 7: 在无限缓存大小的理想设置下，不同用户贡献的归一化（norm.）命中分析。
Figure 8: 不同用户归一化（norm.）请求计数的分析。
#### 3.3 多轮请求特征分析
**多轮请求在to-C工作负载中主导复用**。我们首先研究多轮请求的特征，因为它们仍然在to-C工作负载中主导KV$复用。我们省略了Trace B的结果，因为其中多轮请求非常罕见。
不同请求类型的时间局部性也不同。其次，不同请求类型显示出不同的时间局部性。图14展示了按请求类型分类的多轮请求的复用时间分布。我们可以看到，聊天请求（Text）的复用时间比图像理解（Multimodal）长，但比文件理解（File）短。这源于工作负载的特性：用户通常花更多时间处理基于文件内容的复杂LLM输出，而不是处理对话聊天的随意输出。相反，视觉信息的处理速度比文本处理快【索引47，Your brain at work: Strategies for overcoming distraction, regaining focus, and working smarter all day long，2010，Journal of Behavioral Optometry】，导致图像任务的复用时间更短。最后，搜索（Search）工作负载的复用时间第二长，因为用户通常需要大量时间来分析搜索到的结果。
Figure 14: Trace A和B中多轮请求的KV$复用时间分布。B只有一种请求类别（API）。
**KV$复用时间概率遵循指数分布**。给定一个时间段和请求类别，KV$复用时间的概率分布遵循指数分布。图15展示了不同请求类别下KV$块的复用时间概率分布。对于每个类别，我们测量其KV$在缓存后特定时间间隔内被复用的可能性。我们通过计算请求执行后每一秒复用事件的频率来绘制这些分布。从结果中，我们得出三个关键观察。首先，指数分布能很好地拟合给定请求类别的复用概率。其次，该概率是工作负载感知的，即不同请求类别的分布，包括相同请求类型但不同轮次的分布，是不同的（例如，text-1 vs. text-2）。这意味着需要一种区分不同请求类别的工作负载感知设计。最后，具有相似流量模式的请求的分布是相似的。以text-1为例：如第一行所示，从上午9:00-10:00绘制的分布与上午10:00-11:00绘制的分布相似，但与夜间——凌晨3:00-4:00（第二行）绘制的分布显著不同。不同日期的分布也相似（第一行 vs. 第三行）。第一和第三个观察结合起来意味着我们可以使用最近的历史数据来获取一个请求类别的分布。
Figure 15: KV$块复用时间概率分布的经验分析。列表示不同请求类别的数据。第一行：高流量（白天）下的分布。第二行：低流量（夜间）下的分布。第三行：不同日期但流量模式相似的分布比较。
Figure 20: 不同请求类别下KV$块平均生命周期随时间变化的示意图。注意，x轴代表时间线。请求类别根据其使用情况排序。
**单个请求的KV$缓存使用量适中**。考虑缓存时的一个关键因素是要缓存的KV$大小，它与每个请求的输入长度和相应的模型输出长度成正比。图21显示了不同追踪数据上请求大小的分布。注意，我们报告的是相对于服务实例上可用于服务该请求的HBM的相对大小。这是因为相对值能更直观地显示缓存每个请求KV$所需的容量。可用于KV$的HBM是通过从服务实例中GPU的总HBM中减去模型参数和激活大小来计算的。由于每个请求的KV$大小取决于模型的具体注意力机制，我们报告了三种代表性模型在使用两种广泛使用的注意力方法时的结果：分组查询注意力（GQA【索引3，GQA: training generalized multi-query transformer models from multi-head checkpoints，2023，EMNLP】）和多头注意力（MHA【索引54，Attention is all you need，2017，NeurIPS】）。GQA使用较少的内存来存储KV$。我们可以看到，KV$的总体大小与HBM相比是适中的。以Trace A为例，在像Qwen2-7B这样的GQA模型上，主导请求类型Text中请求的第50、90和99百分位的HBM使用率分别为单轮请求的0.09%、0.15%和0.37%，以及多轮请求的0.36%、1.31%和2.21%。单轮和多轮请求的平均使用率分别为0.09%和0.56%。这种低使用率是由于每个token消耗的兆字节数很少，并且生产追踪数据中的请求往往较小：在Qwen2-7B中，16个token消耗0.875 MB的KV$，而单轮和多轮的平均总token长度（输入+输出）分别为973和5,953。对于其他模型，尽管Llama3-70B也采用GQA，但由于每个实例的GPU数量减少，其HBM使用率略高：参数大小增加了10倍，而我们测量的GPU数量仅增加了4倍。最后，MHA模型由于每个token的KV$增加，使用率最高。值得注意的是，最近的开源模型倾向于使用GQA（或每个token KV$更少的注意力机制，如MLA【索引35，Deepseek-v3 technical report，2024，arXiv】）。
Figure 21: 单轮和多轮请求在不同追踪数据上的KV$大小分布。大小是相对于可用于服务的GPU内存（HBM）进行归一化的。每个图内元组中的数字代表输入和输出的长度。
**整体KV$缓存所需内存适中**。我们通过测量多大的缓存可以确保理想的缓存命中率来分析所需的KV$缓存容量，这里假设采用理想的驱逐策略，即从不驱逐将被复用的KV$。测量方法如下：在给定时间，处理一个请求时，如果该请求的KV$将被复用，我们将其KV$大小加入总KV$大小；同时减去所有永远不会被复用的已缓存KV$的大小。一个棘手的问题是，所需的大小取决于为工作负载部署的服务实例数量：如果实例供应过剩，那么估计的需求会很小。为了获得最大需求，我们使用一个设置，即采用最少数量的服务实例，每个实例以最大QPS服务，因此没有供应过剩。图22显示了归一化到服务实例总HBM的结果。我们可以看到，GQA模型需要相对较小的缓存容量就能达到理想的缓存命中率：在Trace A中，Llama3-70B只需要4倍于可用HBM的KV$。这在现代服务集群中通常是可实现的，无需像远程内存或SSD这样的更多存储层次结构【索引18，Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention，2024，USENIX ATC】。例如，在一个典型的配置中，有8个A100 GPU和1TB的CPU内存，每个GPU平均可以访问128GB的CPU内存，这几乎是为存储KV$保留的HBM空间的4倍。此外，对于Trace B，KV$容量甚至小于保留的HBM，因此在GPU上缓存可能就足够了。尽管GQA需要较小的缓存，但我们应注意MHA模型确实需要大量的KV$缓存，这是由于它们每个token的KV对很大（见图21）。因此，在有限的缓存容量下，优化缓存驱逐策略仍然很重要。
Figure 22: 在不同模型和追踪数据上实现理想缓存命中率所需的KV$缓存大小分析。数据收集自上午10:00至11:00。
A2 方法细节
4.1 设计空间概述
**现有KV$缓存机制与策略**。现有KV$缓存系统【索引18，Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention，2024，USENIX ATC】【索引29，vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention，2023，SOSP】【索引68，Efficiently programming large language models using sglang，2023，CoRR】【索引64，Stateful Large Language Model Serving with Pensieve，2023，CoRR】遵循相似的缓存机制和策略。在机制方面，现有系统主要以分层方式在GPU和CPU上缓存KV$。KV$以块为粒度进行管理（见§2）：当一个KV$块生成时，它首先被缓存在GPU HBM上。如果GPU因内存不足无法缓存新生成的块，缓存系统会采用驱逐策略（如下所述）将一些块从GPU驱逐到CPU。被驱逐的块以逐层异步的方式交换到CPU，因此交换成本可以忽略不计。如果CPU也内存不足，这些块将被移除。在执行新请求之前，如果请求命中了缓存的块，服务系统会直接复用缓存的块以避免重复计算。注意，如果命中发生在CPU上，该块也会以逐层的方式交换到GPU。在策略方面，KV$缓存系统主要需要两种策略：如何确定缓存命中以及如何驱逐缓存的块。对于第一种策略，设计选择在其检查哪些块可能贡献命中的粒度上有所不同：一些系统检查所有请求间的匹配【索引68，Efficiently programming large language models using sglang，2023，CoRR】【索引25，Ragcache: Efficient knowledge caching for retrieval-augmented generation，2024，CoRR】，而另一些仅检查来自单个用户的请求内的匹配【索引64，Stateful Large Language Model Serving with Pensieve，2023，CoRR】【索引18，Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention，2024，USENIX ATC】。对于第二种策略，当前系统主要采用标准驱逐策略，如LRU或FIFO。尽管它们采用了一些扩展，如检查被驱逐的块是否在调度队列中【索引18，Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention，2024，USENIX ATC】，但总体原理没有改变。
**我们的解决方案：基于工作负载感知复用概率分布的KV$驱逐策略**。为此，我们提出了一种工作负载感知的缓存驱逐策略，该策略基于§3.4中描述的特征，考虑了每个请求类别的复用概率分布。在较高层面上，在驱逐时，我们为每个块计算一个优先级——即一个KV$在未来被复用的可能性，该可能性基于其请求类别（工作负载）的复用概率分布剖析。该优先级进一步综合考虑了空间局部性以及KV$块的短暂生命周期。优先级最低的块被首先驱逐。我们的缓存机制遵循现有系统【索引18，Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention，2024，USENIX ATC】【索引29，vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention，2023，SOSP】【索引68，Efficiently programming large language models using sglang，2023，CoRR】【索引64，Stateful Large Language Model Serving with Pensieve，2023，CoRR】——包括异步交换和流水线加载，因为这些技术已经趋于标准化设计。
Table 2: 基于§3发现的我们工作负载感知缓存驱逐策略中主要技术的总结
### 4.2 工作负载感知的KV$缓存驱逐策略
现有的工作负载感知策略。工作负载感知的缓存驱逐策略在文献中已有广泛研究【索引14，Improving WWW proxies performance with greedy-dual-size-frequency caching policy，1998，Hewlett-Packard Laboratories】【索引40，The LRUK page replacement algorithm for database disk buffering，1993，SIGMOD】【索引28，Caching strategies to improve disk system performance，1994，Computer】【索引24，LIRS: an efficient low interreference recency set replacement policy to improve buffer cache performance，2002，SIGMETRICS】【索引37，ARC: A self-tuning, low overhead replacement cache，2003，FAST】【索引11，LHD: improving cache hit rate by maximizing hit density，2018，NSDI】【索引48，Learning cache replacement with CACHEUS，2021，FAST】。一个代表性的策略是Greedy-Dual-Frequency-Size（GDFS）策略【索引14，Improving WWW proxies performance with greedy-dual-size-frequency caching policy，1998，Hewlett-Packard Laboratories】，它使用以下与工作负载相关的特征来评估每个缓存对象（例如KV$）的优先级：
其中，Clock捕获对象的最后访问时间（类似于LRU），Frequency是对象的总访问次数（类似于LFU），Size是缓存对象的大小，Cost是将缓存内容带回缓存的成本。优先级最低的对象被首先驱逐。
**GDFS策略的局限性**。虽然上述GDFS公式可以改造用于计算KV$块的优先级，但我们发现它没有充分考虑LLM服务中的KV$使用情况以及不同类别请求的已知概率分布。例如，由于KV$块的生命周期短，一个频繁访问的块未来可能不会被复用，导致一个频繁访问然后“死亡”的块浪费了KV$空间。此外，一个带回缓存成本更高的块并不一定意味着它在未来更有可能被复用。相反，我们应该优先将更有可能被复用的块带回缓存。虽然在GDFS的设置中这些工作负载信息不可用，但根据我们在前一节的特征分析，在服务LLM时这些信息是现成可用的。
**我们的策略**。我们遵循GDFS的方法来计算每个KV$块的优先级，并使用该优先级来确定驱逐顺序，但我们的优先级是根据我们所表征的KV$复用特征进行改造的：
`Priority = (ReuseProbw(t, life), −Offset)` (工作负载感知)
具体来说，优先级由一个包含两个指标的元组表示，我们按字典序比较元组。这两个指标的原理是：
- **ReuseProbw (➀)**：计算一个KV$块在给定时间t的复用概率，其中t是自上次访问以来的时间。对于每个工作负载（请求类别），复用概率通过一个两步过程计算。首先，我们在后台对最近访问的数据进行一段时间的采样。其次，基于图15中的观察，我们对采样数据拟合一个指数分布，并通过查找拟合曲线来获得复用概率。图23展示了如何计算复用概率的示例。我们首先使用上午9:00到10:00的后台采样数据来拟合给定工作负载复用概率的累积分布函数（CDF）（蓝线）。注意，拟合曲线与真实数据（红线）非常接近。之后，我们可以查找该曲线来获得一个KV$块在未来的复用概率。注意，该函数进一步考虑了块的预期生命周期（life），这对于考虑KV$的短暂生命周期至关重要，我们将在下面描述。
- Offset (➁)：考虑了§3.4中描述的空间局部性：优先级与KV$块在整个请求中的前缀长度成反比。
我们不显式考虑频率（➂），因为我们发现由于KV$块的生命周期短（见图19），即使是频繁复用的块，频率也无法为缓存策略提供有用的信息。更重要的是，我们还需要用生命周期来调节计算出的复用概率。否则，对于具有长尾复用时间分布的请求，拟合的复用概率将在很长一段时间内返回一个较大的概率值。这与KV$生命周期短的观察相矛盾，并导致有限缓存空间的低效利用。
Figure 23: 给定工作负载（请求类别）下如何计算KV$块复用概率的示意图。
详细的驱逐算法。图24展示了我们工作负载感知缓存驱逐算法的简化伪代码。在驱逐时，我们首先遍历所有缓存的块（第4-6行），并使用工作负载（b.w）为每个块计算复用概率。然后将该优先级与块的偏移量进行比较，以更新待驱逐的块（第7-9行）。
输入：B：缓存的KV$块；Life：KV$块的预期生命周期；H(w)：工作负载(w)拟合概率分布的超参数，该分布在后台定期更新。
输出：B：被驱逐的KV$块。
Figure 24: 我们工作负载感知缓存驱逐算法的简化伪代码。
**性能优化**。上述朴素算法的一个缺点是，它需要计算所有KV$块的复用概率来识别最不可复用的候选者。为了避免过多的计算开销，我们观察到每个工作负载内的所有KV$块根据指数分布自然地按其最后访问时间戳排序，因此我们可以在比较同一工作负载内的块时避免计算复用概率。具体来说，对于每个工作负载，我们维护一个按最后访问时间排序的KV$块优先级队列。在驱逐期间，我们不扫描所有块，而是首先将每个工作负载中最近最少使用的块作为驱逐候选。之后，我们运行图24中描述的算法来获得最终被驱逐的块。这将复杂度从O(N)降低到O(W)，其中W是工作负载的数量（通常在几十的范围内）。因此，工作负载感知策略的性能开销对服务来说是微不足道的，例如，我们观察到每次驱逐的策略延迟为79 µs，聚合开销仅为典型服务引擎（vLLM【索引29，vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention，2023，SOSP】）调度开销的1.2%。
模型架构：
- Qwen2-7B【索引9，Qwen technical report，2023，arXiv】：使用1个GPU。
- Llama2-13B【索引53，Llama: Open and efficient foundation language models，2023，CoRR】：使用1个GPU。
- Llama3-70B【索引15，The llama 3 herd of models，2024，CoRR】：使用4个GPU。
选择这些模型是为了覆盖不同的模型大小和注意力机制。
数据集：
- 使用§3.1中描述的Trace A和Trace B作为评估工作负载。
- 由于GPU资源有限，采用一种保留时间模式的缩放方法【索引50，Tracesplitter: a new paradigm for downscaling traces，2021，EuroSys】对追踪数据进行缩放以适应测试平台。
- 匿名追踪评估方法：通过为每个匿名块生成唯一的token列表来构建输入，以精确复现原始追踪的缓存命中模式，并根据追踪的输出长度约束模型，从而保留多轮请求的缓存模式。
消融研究：
- 策略组件效果：图28在Qwen2-7B和Trace A上进行的消融研究显示：
- 仅使用基于分布的方法（技术➀），命中率提升1%。
- 进一步考虑KV$的短暂生命周期（技术➂），命中率再提升2.4%。
- 其他模型趋势类似。
Figure 28: 在Qwen2-7B上，当#CPU Cache / HBM为1时的消融研究。
**公平性问题讨论**：
- 与现有系统一样，恶意客户端可能通过发送大量长相同前缀的请求来独占前缀缓存，引发公平性问题。确保公平性是一个与缓存策略正交的话题，可以通过与LLM服务策略（如FairRide）的协同设计来解决。
## A7 补充细节 (相关工作)
**通过KV$缓存在请求间复用KV$**。复用KV$以加速LLM服务已被广泛研究【索引29，vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention，2023，SOSP】【索引62，Chunkattention: Efficient self-attention with prefix-aware kv cache and twophase partition，2024，ACL】【索引18，Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention，2024，USENIX ATC】【索引19，Prompt Cache: Modular Attention Reuse for Low-Latency Inference，2024，MLSys】【索引68，Efficiently programming large language models using sglang，2023，CoRR】【索引61，Cacheblend: Fast large language model serving for RAG with cached knowledge fusion，2024，CoRR】并在商业LLM服务中得到应用。当前，生产系统仅通过前缀匹配来处理缓存命中，因为它保留了模型推理的原始算法且无精度损失。一些研究【索引19，Prompt Cache: Modular Attention Reuse for Low-Latency Inference，2024，MLSys】【索引61，Cacheblend: Fast large language model serving for RAG with cached knowledge fusion，2024，CoRR】【索引22，Epic: Efficient position-independent context caching for serving large language models，2024】已经研究了非前缀KV$缓存的方法。一旦这些方法成熟并部署到生产环境中，我们可以重新审视我们的特征分析。
**其他KV$相关的优化**。新兴工作【索引58，Efficient streaming language models with attention sinks，2024，ICLR】【索引67，H2O: heavy-hitter oracle for efficient generative inference of large language models，2023，NeurIPS】【索引32，Infinigen: Efficient generative inference of large language models with dynamic KV cache management，2024，OSDI】【索引13，Pyramidkv: Dynamic KV cache compression based on pyramidal information funneling，2024，CoRR】提出了运行时KV$压缩和删除方法以减小KV$大小。例如，StreamingLLM仅保留最近token的有限注意力窗口和一些初始token。H2O仅涉及对注意力得分贡献最大的token进行推理。KVQuant【索引21，Kvquant: Towards 10 million context length LLM inference with KV cache quantization，2024，NeurIPS】实现了3-bit KV缓存量化，以最小的困惑度下降为代价，实现了百万长度上下文的快速推理。这些方法减少了每个请求的KV$需求，但会降低准确性。我们的研究与这些工作兼容：如果一个未压缩/完整的KV$是可复用的，那么压缩或删除后的版本也同样是可复用的。
优化缓存策略。优化缓存策略在文献中已有长期研究，包括通用缓存策略【索引40，The LRUK page replacement algorithm for database disk buffering，1993，SIGMOD】【索引28，Caching strategies to improve disk system performance，1994，Computer】【索引27，2q: A low overhead high performance buffer management replacement algorithm，1994，VLDB】【索引52，EELRU: simple and effective adaptive page replacement，1999，SIGMETRICS】【索引31，LRFU: A spectrum of policies that subsumes the least recently used and least frequently used policies，2001，IEEE Trans. Computers】【索引24，LIRS: an efficient low interreference recency set replacement policy to improve buffer cache performance，2002，SIGMETRICS】【索引37，ARC: A self-tuning, low overhead replacement cache，2003，FAST】【索引70，Second-level buffer cache management，2004，IEEE Trans. Parallel Distributed Syst.】【索引10，CAR: clock with adaptive replacement，2004，FAST】【索引23，Clock-pro: An effective improvement of the CLOCK replacement，2005，USENIX ATC】【索引16，Lightweight robust size aware cache management，2022，ACM Trans. Storage】【索引11，LHD: improving cache hit rate by maximizing hit density，2018，NSDI】【索引48，Learning cache replacement with CACHEUS，2021，FAST】【索引66，SIEVE is simpler than LRU: an efficient turn-key eviction algorithm for web caches，2024，NSDI】【索引14，Improving WWW proxies performance with greedy-dual-size-frequency caching policy，1998，Hewlett-Packard Laboratories】或特定领域【索引59，A large scale analysis of hundreds of in-memory cache clusters at twitter，2020，OSDI】【索引12，The CacheLib caching engine: Design and experiences at scale，2020，OSDI】【索引49，Icebreaker: warming serverless functions better with heterogeneity，2022，ASPLOS】【索引17，Faascache: keeping serverless computing alive with greedy-dual caching，2021，ASPLOS】。我们延续了这一研究方向，并利用我们表征的KV$复用属性来优化KV$缓存策略。
优化LLM服务。我们延续了优化LLM服务系统性能的研究方向【索引69，Distserve: Disaggregating prefill and decoding for goodput-optimized large language model serving，2024，OSDI】【索引56，Loongserve: Efficiently serving long-context large language models with elastic sequence parallelism，2024，CoRR】【索引30，Efficient memory management for large language model serving with pagedattention，2023，SOSP】【索引33，AlpaServe: Statistical multiplexing with model parallelism for deep learning serving，2023，OSDI】【索引63，Orca: A distributed serving system for transformer-based generative models，2022，OSDI】【索引45，Splitwise: Efficient generative LLM inference using phase splitting，2024，ISCA】【索引18，Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention，2024，USENIX ATC】【索引65，Fast and live model auto scaling with O(1) host caching，2024，CoRR】，特别关注于为KV$缓存表征服务工作负载。我们的工作与KV$缓存之外的优化是正交的。
💬 评论讨论
欢迎在这里分享您的想法和见解！