（个人论文阅读记录，新手，2025年大四，仅仅为记录，错了我会改正）

题目:DroidSpeak：面向跨LLM通信与多LLM服务的KV缓存共享技术

（DroidSpeak针对的是源自同一基础模型、但经过不同微调的模型。这意味着它们“血脉同源”，但“后天经历”不同。）

论文承认这是一个ML难题，但其主要贡献不在于提出一种全新的ML算法来解决“完美转译”，而是：

1. 通过实证研究发现了一个经验规律：他们通过大量实验发现，对于同源微调模型，通常只有约10%的层是“关键层”，其余大部分层的KV缓存可以直接共享而质量损失可忽略。这个发现本身就是一个有价值的机器学习结论。

2. 基于此规律，设计系统策略：既然找到了规律（关键层很少），那么就可以在系统中设计一个策略——“只重算关键层，复用非关键层”。

3. 在系统层面高效执行该策略：接下来的贡献就是如何在一个分布式系统中，以最小的开销（延迟、带宽）去完成这个“识别-重算-复用”的流水线，并将缓存加载时间隐藏起来。

摘要：

  复合式AI系统（例如智能体系统）正成为大规模企业环境中的新兴趋势，这类系统通过多个专精于不同用户、任务和/或角色的LLM协同工作。在此类场景中，不同模型处理的输入数据往往具有相同的上下文前缀。（比如针对同一份公司会议纪要，财务分析模型，市场分析模型等都是针对同一材料文本）尽管过去已有大量研究实现了单模型跨输入重复使用前缀KV缓存，但如何让一个模型复用不同模型的前缀KV缓存，仍是亟待解决的关键问题。

  我们正式推出DroidSpeak——首个实现分布式LLM推理系统中KV缓存跨模型复用的创新方案。只要LLM架构相同，该系统就能在运行不同模型推理的分布式节点间实现KV缓存共享。我们首次系统性研究了跨LLM共享KV缓存的影响机制，并深入分析了共享条件对质量指标的关联性。基于研究发现，DroidSpeak采用选择性重计算策略：对源LLM生成的KV缓存少量关键层进行重计算，同时安全复用其余层级，在质量损失可忽略的前提下实现高效共享。通过精细设计层级重计算与缓存加载的流水线并行机制，系统进一步提升了推理性能。多样化数据集和模型对的实验表明：相较于禁止跨模型共享的基准方案，DroidSpeak可实现高达4倍的吞吐量提升，预填充阶段加速约3.1倍（首令牌生成时间），且在F1分数、Rouge-L指标及代码相似度得分上均保持可忽略的质量损失。

介绍：

当前，LLM推理已成为工业界资源消耗最大的工作负载之一，需要规模不断扩大的GPU机器集群[4, 85, 86, 87, 72, 106]。为降低计算需求，常见的优化方案是让运行**相同**LLM的GPU机器通过网络共享重复输入前缀的KV缓存[20, 42, 53, 61]。然而，如何使该优化方案在**不同**LLM间生效仍有待研究。

   事实上，在单一GPU集群中部署多个**不同**LLM正成为新兴趋势。这是因为随着LLM被应用于更复杂或个性化的任务，往往需要基于同一基础模型微调得到的多个LLM，以服务不同用户、任务或角色。这些LLM通过协同工作来完成复杂任务或提供差异化定制服务[9, 12, 29, 65, 95]。由于标准前缀缓存技术仅能在KV缓存被相同模型复用时生效，这就直接带来了一个挑战——在分布式环境中，如何在不同LLM之间高效地复用KV缓存。为阐明这一挑战的现实意义，我们重点介绍系统中多个微调模型协同工作的三大常见场景。

   为阐明这一挑战的现实意义，我们重点介绍系统中多个微调模型协同工作的三大常见场景。首先是多智能体系统，该系统运用不同的微调模型担任各类智能体，共同完成协作任务[14, 40]。第二类场景是多LoRA或多微调模型服务，例如随着新数据持续更新的迭代模型[46]，或同时服务多个LoRA适配器的系统[18, 79, 92]。第三类应用是个性化助手系统，该类系统会根据用户在编程或写作方面的个人偏好，为每个用户（或用户类型）定制专属的微调模型。

图1：多个LLM共享相同上下文的各种应用场景。DroidSpeak可降低高达3.1倍的计算延迟，提升4倍吞吐量。

  所有这些场景都普遍存在前缀共享现象。以多智能体系统（图1A）为例：当编程智能体与验证智能体交互时，为确保对话连贯性，编程智能体的对话历史会被添加为验证智能体输入的前缀。在多LLM或多LoRA推理系统中（图1B），聊天机器人应用程序的更新版本模型可能需要引用旧版模型生成的同一段对话历史。在个性化助手系统中（图1C），虽然每个助手都针对不同用户偏好进行微调，但同一则新闻（即查询前缀）可被用于回答不同用户的查询。

  基于上述观察，我们提出核心问题：能否通过共享某个LLM在给定上下文生成的中间状态（即KV缓存），来加速另一个LLM的预填充阶段？ 本文将在两个LLM权重不同但架构相同的假设前提下，深入探讨这一问题。

  直观来看，这种中间状态共享可能带来的性能收益十分可观——此前针对单LLM的KV缓存共享研究已表明，通过加速LLM推理中计算成本高昂的预填充阶段（尤其对于长上下文工作负载），可实现高达8倍的延迟降低与吞吐量提升[31, 32, 49, 61]。然而，正如视频解码器无法解析由不同编码器压缩的视频流，若直接在不同LLM间简单粗暴地共享KV缓存，将导致生成质量严重下滑。

  我们提出一个关键假设：对于基于同一基础模型微调的两个模型，应当存在一种"少量重计算+大量复用" 的协同机制——由于模型仅经过微调，它们对相同输入上下文应具备相似的理解能力，从而能够相互加速推理过程。当然，核心挑战在于如何验证该假设，并精准确定哪些部分需要重计算、哪些部分可安全复用，同时避免引入过高延迟开销或质量损失。

   通过系统性实证研究（§3.2），我们对八组代表性模型进行了测量，发现仅需对层间KV缓存差异敏感的小部分层级（通常约10%）进行重计算。这些关键层级的身份标识因模型对而异，但在同一模型对不同输入间保持稳定。我们将其定义为关键层级。基于此，我们提出为每对LLM选择性重计算KV缓存中的这些关键层级。

  我们将这一洞察融入DroidSpeak——首个实现跨LLM高效KV缓存共享的分布式多LLM推理系统。首先，DroidSpeak通过预留"训练"集的离线性能分析，精准识别关键层组，在保证计算精度的前提下实现最大程度的层级复用。其次，系统采用智能KV缓存加载机制，将缓存加载与关键层重计算过程流水线化，最大限度隐藏远程节点的加载延迟。

   需要说明的是，选择性重计算KV缓存的高层思路并非首创。DroidSpeak与既有研究[31,32,61,97]的根本差异在于重计算动机与实现路径：本系统面向异质LLM间的缓存复用，而前人工作均基于单一LLM假设。正是目标场景的根本不同，导致现有方案均未采用DroidSpeak这种按层组重计算的范式。例如CacheBlend[97]虽会更新复用缓存，但仍将其馈送给生成该缓存的同源LLM使用，且其更新粒度是基于令牌而非本系统的层级维度。

我们在三大类任务（包括问答、文本摘要及代码生成）的六个数据集上，针对八组不同模型对开展了DroidSpeak性能评估。通过与多种基线方案（包括直接KV复用[31]、CacheBlend[97]及小型模型）的系统性对比，实验表明：本方案在F1分数、Rouge-L指标及代码相似度得分仅出现可忽略的质量损失前提下，最高可降低3.1倍延迟并提升4倍吞吐量。

尽管跨模型"转译"KV缓存本质上涉及机器学习难题，但我们的核心贡献在于将其落地于分布式系统实践——通过高效实现KV缓存转译的传输与计算流程，使该技术具备工程可行性。

我们已将系统实现与最先进的KV缓存管理库LMCache[25]及LLM推理引擎vLLM[51]深度集成，并完成了企业级环境验证。根据双盲评审要求，代码链接已做匿名化处理。

图2：基于Transformer的LLM自注意力机制中嵌入（E）、查询（Q）、键（K）、值（V）张量运用示意图。

2背景和动机

本节将简要介绍不同微调模型版本间上下文共享这一新兴工作负载的背景，并阐述DroidSpeak的设计动机。

2.1transformer基本的概念

当前生成式AI的浪潮主要由基于Transformer架构且仅包含解码器的高性能模型所推动[27, 30, 37]。

查询、键、值与嵌入： 在Transformer中，Q（查询）、K（键）和V（值）是注意力机制的核心组件[13, 58, 67, 84, 99]。LLM模型包含多个层级，每个层级在接收输入后都会生成各自的E/Q/K/V张量（图2）。我们将K与V张量统称为KV缓存，嵌入E张量称为E缓存。在每个层级内部，嵌入E是后续Transformer计算（包括注意力机制）的起点。

E/Q/K/V张量的质量直接决定模型理解与处理输入上下文的效能。预填充与解码阶段： 如图3所示，LLM通过两个不同阶段处理输入并生成输出：预填充阶段与解码阶段。 在预填充阶段，模型会处理整个输入上下文，生成所有层级的嵌入向量和KV缓存。在解码阶段，模型利用预填充阶段生成的KV缓存，以自回归方式逐个生成输出令牌。

微调LLM： 尽管基础LLM具备通用能力，但通过在特定领域数据上进行微调，可显著提升其专业任务表现。例如，通过对故障排除请求数据进行微调，可将基础LLM转化为客服支持助手[73]；通过对案例法和法规条文进行微调，则可打造法律助理[101]。如图4所示，经过微调的模型（包括Llama-3-70B-Instruct [5]、Mistral1ite [100]、Llama-3-8B-Instruct [5]及MammoTH2 [102]）在HotpotQA数据集[96]上的表现显著优于其源基础模型，印证了微调对目标领域准确性的提升效果。

近年来出现的参数高效微调技术（如LoRA[43]）通过仅更新部分模型权重，大幅降低了微调所需的计算和内存资源，使得微调模型的获取与应用变得更加便捷。

2.2LLM间的上下文共享

在复合AI系统中，前缀上下文¹通常在不同LLM间共享——这既是为了增强对话体验的连贯性，也是为了引用相同的背景文档集。为便于论述，本文采用以下术语：

• 发送方模型：生成某一上下文的KV缓存

• 接收方模型：复用该上下文的KV缓存（仅进行有限重计算）

下文将阐述不同LLM间上下文共享的几个具体应用场景。

智能体工作流：
智能体工作流代表了LLM领域自动化和协作的范式转变[3,7,33,44,54,55,90]。这些工作流整合了多个专门化的LLM智能体（每个智能体都针对特定任务进行微调），通过协同合作解决复杂的多步骤问题，或在智能体辩论中扮演不同角色。例如，已有研究提出使用微调模型作为不同智能体，以提升生成质量和智能体泛化能力[14,22,23,81]。与在同一模型上使用不同提示词相比，采用微调模型作为不同智能体能更有效提升输出质量[14,81]。

• 上下文共享需求：在智能体工作流中，不同智能体常需共享公共上下文（通常是其他智能体的对话历史），以确保智能体间的连贯性与一致性[36,40,89]。具体而言，在包含编程与测试智能体的编码工作流中，测试智能体（接收方）必须同时读取输入指令和编程智能体（发送方）生成的代码，才能编写符合用户需求的单元测试[40,76,89]。

个性化模型：
针对个体用户或任务定制的个性化模型在LLM系统中日益普及，尤其在聊天机器人、虚拟助手和推荐引擎等应用中[11,17,83]。这类应用中的不同助手通常是根据不同用户偏好微调的LLM[41,55]。例如，为软件工程师定制的个人助手可微调为生成高质量简洁代码片段，而为金融分析师定制的助手则专注于从文档中识别市场视角而无需技术细节。

• 上下文共享需求：这些模型常需处理重叠的上下文（如共通的对话历史或共享知识库），以确保连续性与相关性。例如，两个助手在回答关于时事的相似查询时，都需要处理相同的头条新闻。

多LLM或多LoRA服务：
在聊天机器人应用中，LLM需要持续更新以整合新信息，从而为用户提供最新支持与更高质量答案[8,26]。例如，ChatGPT API约每两个月发布基于同一基础模型的新版本，通过新兴数据进行微调[64]。此外，系统常需同时服务多个LoRA适配器[18,79]，以完成不同任务或服务不同用户群体。

上下文共享需求： 在此场景中，更新后的模型（接收方）常需要重新处理旧版模型（发送方）曾处理过的相同热门上下文。多个LoRA适配器在处理相同上下文时，亦可共享其KV缓存。

正是当前工作负载中的这些新兴趋势，催生了对跨微调LLM高效上下文共享技术的迫切需求，这也构成了DroidSpeak系统的设计动因。

2.3分布式LLM推理系统

随着LLM推理需求的持续增长，在GPU节点集群中部署LLM服务已成为常态。多家企业已开发出自有的分布式推理系统，例如vLLM生产套件[85]、NVIDIA Dynamo[4]以及字节跳动AIBrix[86]。在这些框架中，跨节点KV缓存共享是减少预填充计算、提升整体吞吐量的关键技术特性。具体而言，当针对同一模型的多个请求查询相同前缀上下文时，这些系统可传输由其他用户请求生成的KV缓存（无论来自其他GPU节点或通过集中式存储后端[20,31,50]）。

然而，现有分布式推理系统尚未针对多LLM推理场景进行优化——当请求查询不同模型时，系统并未探索跨GPU节点共享KV缓存的可能性。

2.4预填充干扰

基于第2.1节所述的预填充与解码阶段特性差异，过长的预填充阶段会显著降低推理系统的有效吞吐量——即在延迟服务等级协议范围内每秒处理的查询数量[106]。这是因为首令牌时间随输入长度呈超线性增长，且解码阶段必须等待预填充完成后才能启动。因此，长输入往往会使预填充延迟成为端到端性能瓶颈。如图5所示（在单A100 GPU上运行Llama-3-8B模型，使用5K与20K令牌的合成输入长度），当设定3秒延迟SLO时，仅将输入规模增大4倍就会导致有效吞吐量暴跌高达32倍。

本文采用的模型配对。对于每对模型，我们使用符合§3.1所列要求的数据集（即接收方模型需具备优于发送方模型的质量）。

为什么要选择优于发送方的模型呢？

性能的变化（无论是好是坏）究竟是由“KV缓存共享”造成的，还是由“模型能力的固有差异”造成的？

3 跨LLM复用KV缓存

消除重复计算其他LLM已生成KV缓存开销的直接方案，是复用其他模型产出的KV缓存。具体而言，在A100 GPU上使用Llama-3.1-8B-Instruct模型时，对40K令牌长度的输入复用KV缓存，可将预填充延迟从4秒大幅缩减至0.08秒。

这自然引出一个关键问题：直接复用其他LLM的KV缓存会对生成质量产生何种影响？

本节首次通过实证研究，系统探讨复用其他模型KV缓存对输出质量的影响机制，并深入分析这种影响是否随缓存层级的变化而呈现差异化特征。

3.1构建基准测试与数据集

在深入探讨KV缓存共享模式之前，我们首先阐述为DroidSpeak构建的基准测试集。本研究需要共享数据集所提供上下文的模型对，并在构建基准时遵循以下假设：

• 模型对应源自同一基础模型。具体而言，模型对可包含基础模型与其衍生的微调模型，或基于同一基础模型的两个微调模型。

• 所选数据集需与某个模型的微调任务相关。这一点至关重要，因为在任何上下文共享场景中，接收方模型都需要执行其专精任务。

• 在对应数据集任务上微调的接收方模型，其输出质量应优于配对中的发送方模型。

基于这些假设，我们构建了如表1所示的基准测试集。我们在6个数据集（包括HotpotQA [96]、multifieldQA_en [48]、2wikimQA [38]、multi_news [28]、lcc [35]和repobench-p [60]）上使用了8对模型，并直接采用各数据集原有的质量评估指标。

我们重点关注发送方模型为上下文生成中间状态、接收方模型复用这些中间状态的应用场景。该场景具有显著挑战性：由于发送方模型精度低于接收方模型，要实现高质量输出就必须对KV缓存进行精准刷新。

3.2关于KV缓存的实证性洞察

简单复用策略效果欠佳：
我们的首要发现关乎于在接收方模型上简单复用发送方模型KV缓存的效果。具体而言：

洞察1：在模型间整体复用KV缓存会导致精度大幅损失。

跨模型复用中间状态最直接的方式是原样照搬KV缓存。此时，接收方模型直接获取发送方模型对整个输入提示词生成的KV缓存，并在解码阶段直接使用该缓存来生成输出令牌，从而跳过预填充阶段。

图6展示了这种做法对质量的影响。针对每组模型对和数据集，我们分别呈现了：a) 接收方模型独立推理、b) 复用发送方模型KV缓存的接收方模型、c) 发送方模型独立推理三种情况下的F1分数（分数越高越好）。

尽管复用发送方KV缓存的接收方模型质量仍优于发送方模型本身，

但其精度已出现显著衰减。在大多数模型对中，HotpotQA数据集的精度损失普遍超过50个百分点，而其他数据集在不同模型对间则呈现不同程度的精度波动。

层级敏感度差异：
我们的第二项发现旨在探究KV缓存复用是否对所有层级产生同等影响。

洞察2：仅小部分层级对KV缓存复用在精度方面表现敏感。

图7展示了逐层复用发送方模型KV缓存导致的质量下降情况。具体而言，每个柱状图代表接收方模型在仅复用发送方模型对应层KV缓存（其余层级均经重计算）时达到的质量指标。

在大多数模型对中，我们发现仅小部分层级对KV缓存偏差敏感（即F1分数显著下降），这些被标记为红色的关键层级平均仅占所有层级的11%。

敏感度在不同输入间的稳定性：
我们的第三项观察聚焦于不同输入是否呈现相似的层级敏感模式。

洞察3：KV缓存敏感模式的输入间变异仅关键层级显著。

图8展示了HotpotQA数据集中，当llama-3-8b-sft-lora-ultrachat模型逐层复用finger-llama-3-8b模型KV缓存时，各输入F1分数归一化变化的小提琴图。第23层（在图7中被标记为该模型对最关键的层级）在不同数据点间呈现较大变异度，多数数据点的F1分数变化超过50%。然而，所有非关键层级的F1分数变化方差均不显著，这意味着这些层级的敏感度不随输入变化而改变。

该现象在其他模型对中也普遍存在。直观而言，这是因为关键层级承载着模型的核心推理能力[21]或完成特定下游任务的能力[19]。无论输入内容如何变化，这些推理能力都必须保持准确无误。

4 DroidSpeak系统设计

基于前一节的实证洞察，我们设计了DroidSpeak系统以增强两个LLM间的上下文共享能力。系统核心致力于解决以下问题：如何在保证质量损失最小化的前提下，确定需要重计算的层级以实现延迟优化？

4.1选择性KV缓存复用面临的挑战

洞察2表明，选择性复用KV缓存并重计算关键层级可能保持输出质量。然而，若简单选择LLM中分散各处的所有关键层进行重计算，将在效率和质量层面均导致次优结果。

效率挑战： 对非连续分布的关键层进行重计算将导致效率低下。

在预填充阶段，复用KV缓存的层级其输出仅包含首个生成令牌的信息。而重计算KV缓存需从该层级的E缓存开始处理完整上下文。虽然可通过从首层到第l层执行完整预填充来获取该层E缓存，但这种方式完全违背了KV缓存复用的初衷。

为解决此问题，我们利用发送方模型的E缓存在从KV缓存复用切换至重计算的过渡层启动计算。这类过渡层如图9所示：对于任何复用与重计算之间的过渡层，发送方模型都需存储并传输其E缓存至接收方模型。

E缓存容量通常十分庞大——对于Mistral-7B或Llama-3-8B模型系列，其尺寸可达KV缓存的两倍；而由于组查询注意力机制[6]对KV缓存的优化，Llama-3.1-70B的E缓存更是高达KV缓存四倍。因此，在GPU内存中存储E缓存及其跨节点传输带来的延迟开销可能非常显著，远超单独存储加载KV缓存的成本。

精度挑战： 此外，在过渡层复用发送方模型的E缓存还会损害最终输出精度。这是因为从发送方模型加载的E缓存（作为重计算的起点）已与接收方模型产生偏差。这种差异将从重计算点开始引入误差，并传播至后续所有层级。必须最大限度降低此类偏差导致的误差。

若我们选择所有通常非连续分布的关键层（图7），将会出现多个从复用到重计算的过渡层，从而导致E缓存偏差的多次引入。

图10清晰地展示了这一现象。如果我们仅选择重算关键层（即第16-18层、第20层和第25-27层），就需要在第16、20和25层加载E缓存。然而，每次加载E缓存时，其携带的误差都会传播至后续关键层（例如在第16层加载的E缓存会将误差传递至16-18层），并最终影响输出结果。因此，即使重算了所有关键层，仍会导致显著的输出误差。

相比之下，重算从第16层到第27层的连续层组，通过重计算位于关键层之间的非关键层KV缓存，有效避免了这一问题。如图10所示，重算连续层组方案的输出误差远低于仅重算关键层的方案。

4.2重计算配置的性能剖析

核心问题依然存在：如何确定需要重计算的关键层组？

基于洞察3，对KV缓存差异敏感的关键层级基本不随输入变化。这启发了我们的设计思路：通过示例输入确定关键层组，并将其应用于其他新输入。具体而言，针对每个模型对，我们使用"训练"数据集来确定关键层组，并将该组称为重计算配置，旨在探究关键层组与生成质量之间的关联规律。

图11展示了glue_sst2与conllpp模型对的性能剖析示例。散点图中每个点代表在特定重计算层数下达到的F1分数。通过这些点我们可得到帕累托边界，该边界记录了在特定层组设置下能达到的最高F1分数。例如，重计算11层的配置就是帕累托边界上的一个典型方案——在将F1分数下降控制在接收方模型原始精度5%以内的同时，实现了重计算层数的最小化。

剖析开销： 剖析开销复杂度为O(l2)O(l2)（ll表示LLM的层数）。以32层的Llama-3-8B为例，在A100 GPU上需耗时三小时。由于这些模型通常大规模部署[72,106]，这种一次性开销可忽略不计。此外，通过分层组进行剖析可大幅降低开销：例如以2层为粒度进行剖析，能将耗时减少约3倍。在即将展开的§5评估中，我们均采用2层组剖析粒度。

4.3DroidSpeak运行时设计

如图12所示，DroidSpeak包含两个阶段。离线阶段（详见§4.2）使用训练数据集剖析各层数值变化对生成质量的影响关系，此步骤使得系统能根据可用资源动态选择最佳重计算配置。接下来我们将详述在线阶段——该阶段运用离线剖析结果动态决策KV缓存的关键层级，并通过部分重计算维持高质量生成。

具体而言，在线阶段中，DroidSpeak根据延迟SLO动态选择帕累托边界上的最优操作点（详见附录§B）。我们假定各过渡点的E缓存与KV缓存均已预计算存储，但它们也可由发送方模型实时生成并直接传输。随后，接收方模型选择性重计算关键层组并复用其他层级，最终实现计算效率与输出质量的最优平衡。

智能KV缓存加载： 由于承载不同LLM的GPU可能分布于不同节点，DroidSpeak需要频繁从远程节点获取KV缓存。若缺乏精心设计，这种传输会显著增加端到端延迟——尤其在重计算层数较少时（即需要传输更多KV缓存层）。

我们通过一个示例说明：假设存在两个接收方模型A和B，各包含10个层级。模型A需要重算第4-10层并复用第1-3层的KV缓存，而模型B则重算第1-3层并复用第4-10层的KV缓存。

图13展示了三种不同加载与重计算策略的时间线。我们假设请求在时刻0到达模型A，2个时间单位后到达模型B，且重计算或传输单层缓存（KV/E缓存）均需1个时间单位。最基础的策略是在每个任务开始重计算前，完整加载所有KV缓存层。例如模型A（橙色）需先加载第4层E缓存及全部KV缓存，再进行7个单位重计算，模型B同理，最终导致总TTFT达到47个单位（图13a）。

改进策略是在重计算前仅加载可复用层的KV缓存（对应模型A的1-3层，模型B的4-10层）。如图13b所示，该方法将总TTFT降至30。

然而，这两种方案均未实现重计算与缓存加载的并行化。实际上，一旦接收到过渡层E缓存即可立即启动重计算。如图13c所示的最优方案采用流水线方式协调加载与重计算：模型A首先传输第4层E缓存，在并行加载1-3层KV缓存的同时启动4-10层的重计算；类似地，模型B的E/KV缓存加载可在模型A完成重计算前提前开始。这种流水线策略将总TTFT降至17个单位——较方案(b)实现约2倍提升。

什么是E缓存？

E缓存（Embedding Cache，嵌入缓存）是Transformer模型在预填充阶段，对输入文本进行初步理解后，在每一层产生的“原始中间状态”，它是计算该层KV缓存的直接输入。

1. 它是什么？

• E缓存存储的是每个Transformer层输出后的完整隐藏状态。

• 对于一个长度为 N 的输入序列，E缓存就是一个维度为 [N, Hidden_Dimension] 的张量。它代表了该层对输入序列的“理解结果”。

2. 它和KV缓存的关系？（对应图中流程）

• 依赖关系：如流程图所示，E缓存是计算KV缓存的“原料”。当模型执行到第L层时，必须基于该层的E缓存，才能经过自注意力计算，生成该层的K缓存和V缓存。

• 内容不同：

  • KV缓存 是键值对，是注意力机制中用于计算上下文权重的“索引”和“内容”。

  • E缓存 是更“原始”的中间激活值，是生成KV缓存前的“数据准备阶段”。

3. 为什么DroidSpeak需要关心E缓存？

这是理解DroidSpeak设计难点的关键。当接收方模型需要从“复用KV缓存”切换到“重计算KV缓存” 时，它遇到了一个“启动问题”：

• 要重计算第L层的KV缓存，你必须要有第L层的E缓存作为输入。

• 但是，接收方模型并没有自己计算过这个E缓存，因为它跳过了预填充阶段。

• 解决方案：直接复用发送方模型在第L层产生的E缓存。

• 新问题：

  1. 精度损失：发送方和接收方模型的参数不同，它们的E缓存必然存在偏差。用一个有偏差的E缓存作为重计算的起点，这个误差会传播并放大，影响后续所有层。

  2. 传输开销：E缓存的体积非常庞大，通常比KV缓存还大（论文中指出，对于Llama-3.1-70B，E缓存可达KV缓存的4倍）。存储和传输E缓存带来了巨大的额外开销。

一个简单的比喻

想象两个厨师（发送方和接收方模型）要按照不同的食谱（模型权重）做同一道菜。

• KV缓存 像是切配好的半成品食材（如切好的胡萝卜丁、调好的酱汁）。接收方厨师可以直接拿来用，但可能因为食谱不同，味道有点偏差。

• E缓存 则像是切菜前的完整蔬菜（一整根没切的胡萝卜）。如果接收方厨师要从头开始切菜（重计算），他需要这根原始胡萝卜。

• DroidSpeak的挑战：当接收方厨师需要从“使用对方的半成品”切换到“自己动手切菜”时，他发现自己没有原始胡萝卜。他只能问发送方厨师要一根对方已经切过几刀的胡萝卜（有偏差的E缓存）来继续工作，这自然会影响到他后续切菜的形状和最终菜品的味道。

4.4系统实现

我们基于PyTorch v2.0、CUDA 12.0和LMCache 0.1.4 [24,25]，使用约3000行Python代码实现了DroidSpeak。系统通过以下接口操作LLM推理服务引擎：

• 存储接口：将KV或E缓存按层级分割，并存储至GPU内存的键值存储系统中。

• 获取接口：根据先前存储操作的内容，加载对应LLM特定层级的KV或E缓存。

• 部分预填充接口：接收重计算配置与上下文信息（包括预填充阶段需重计算的层级），随后生成输出文本。

我们在vLLM [51]与LMCache [25]中实现了这三个接口。对于KV缓存存储，当LLM为某段上下文生成KV缓存后，系统会计算该上下文文本的哈希值，若当前存储中不存在该上下文，则将其存入键值存储。在运行任何LLM推理前，我们会从离线剖析（§4.2）中获取重计算配置，该配置包含需重计算和复用KV缓存的层级编号。在线推理阶段，系统调用部分预填充函数，该函数通过获取接口加载需复用的KV缓存层及过渡层的E缓存。KV/E缓存获取功能均通过torch.distributed [74]实现，支持从远程GPU节点获取缓存数据。所有传输操作将被置于与PyTorch默认计算流不同的CUDA流[75]中，从而实现KV缓存传输与重计算过程的并行化，有效隐藏传输延迟。

5 性能评估

本章评估的核心结论如下：

• 在三大数据集与八组模型对测试中，DroidSpeak可在保证精度无损的前提下，将预填充延迟降低1.7至3.1倍，平均加速达到2.1倍。

• 在线服务系统中，DroidSpeak可实现高达4倍的吞吐量提升。

• DroidSpeak的重计算层剖析机制在不同数据集和模型类型间均表现出良好鲁棒性。

5.1实验设置

模型配置： 我们在八组不同规模的模型对（表1）上评估DroidSpeak，这些模型均基于Mistral-7B、Mistral-24B、Llama-3.1-8B等基础模型的微调版本，严格遵循§3.1的筛选标准。这些微调模型专注于对话增强、代码生成及长上下文推理等任务。针对Llama-3.1-70B与Llama-3-70B大模型，我们采用AWQ [57] 4位量化技术使其可部署于单A100 GPU。

需特别说明，接收方模型并非全部直接微调自发送方模型，其中包含源自同一基础模型的两个不同微调变体。

硬件环境： 实验在微软Azure平台两台通过InfiniBand互联的A100虚拟机上执行，具体型号为Standard_ND96amsr_A100_v4，每台虚拟机配备8块80GB显存的A100 GPU。

数据集： 我们在六个数据集上评估DroidSpeak，其上下文长度统计信息见表2。针对每组模型对，我们根据“接收方模型在选定数据集上必须优于发送方模型”的原则，从中选取三个数据集进行结果汇报。这些源自LongBench评测集 [10] 的任务涵盖多跳推理、文本摘要及代码理解与补全等LLM核心能力。

训练/测试集划分： 如§4.2所述，DroidSpeak通过离线“训练”数据集剖析关键层组，确保质量损失控制在原始质量5%以内。具体而言，我们使用HotpotQA数据集的50条上下文作为训练集，通过§4.2所述的剖析机制确定关键层组，并将该配置应用于基准测试中所有其他测试数据集。

质量指标： 我们沿用既有研究 [10,61,97] 的标准，采用各数据集固有指标评估生成质量：

• F1分数：用于问答任务，衡量生成答案与标准答案的匹配概率

• Rouge-L分数：用于摘要任务，评估生成摘要与标准摘要的最长公共子序列

• 代码相似度得分：用于代码补全任务，计算生成代码与标准代码的编辑距离

系统指标： 我们采用§2.1列出的系统指标（包括TTFT首令牌时间、TBT令牌间时间、E2E端到端延迟）对比DroidSpeak与基线方案。在§5.2中额外测量预填充延迟（含GPU计算时间与跨节点InfiniBand链路加载KV/E缓存的传输延迟）。

基线方案：

• 完整预填充：接收方模型使用vLLM [51] 对上下文执行标准预填充，代表计算开销最大但质量最优的基准

• 全KV缓存复用 [31]：接收方模型直接复用发送方模型的KV缓存，仅执行解码过程

• CacheBlend [97]：我们扩展其算法至跨LLM场景，基于首层重计算KV缓存与发送方原始缓存的差异，确定需重计算的关键令牌

• 轻量模型：在§5.6中，我们将搭载DroidSpeak的Llama-3.1-70B-Instruct与同指令集微调的Llama-3.1-8B-Instruct进行精度-延迟权衡对比

5.2 保持精度下的延迟优化

我们首先通过图14展示DroidSpeak在降低预填充延迟与精度权衡方面的表现。在三大数据集上的八组模型对测试中，相较于完整预填充方法，DroidSpeak在保证生成质量无损的前提下，实现了预填充延迟**1.7至3.1倍**的降低。另一方面，与全KV缓存复用方案相比，DroidSpeak虽延迟略有增加，但成功保持了接收方模型的优质输出。相较于CacheBlend，DroidSpeak在延迟与质量权衡上表现更优：在相近预填充延迟下，DroidSpeak的质量指标高出5-33%（平均16%）。

DroidSpeak优势分析：
对比完整预填充：通过仅预填充少量关键层，显著降低延迟
对比全KV复用：虽因执行部分预填充导致延迟较高，但通过利用层级敏感特性极大保障了精度
对比CacheBlend：因能精准重计算对缓存偏差最敏感的关键层组，质量更优；而CacheBlend基于首层令牌选择的机制无法识别关键层

5.3吞吐量与延迟提升

为评估在线场景性能，我们通过泊松分布模拟请求到达序列，在Kubernetes集群（搭载vLLM生产套件[85]）部署实验环境。集群包含两个8*A100 GPU节点，每个模型部署8个副本，采用轮询路由策略。

如图15所示（以HotpotQA数据集四组模型对为例），在精度损失控制在1%以内的配置下：

TTFT（首令牌时间）：完整重计算基线因预填充延迟过高，其TTFT在较低QPS时即出现队列延迟导致的曲线拐点，而DroidSpeak能支撑更高并发。

TBT（令牌间时间）与E2E（端到端延迟）：虽然DroidSpeak直接优化TTFT，但通过减轻系统干扰和优化调度，间接实现了TBT与E2E延迟的同步下降。

吞吐量：在避免高队列延迟的SLO约束下，DroidSpeak可实现**2-4倍**的吞吐量提升。

 5.4 跨数据集鲁棒性

如图17所示（以glue_sst2与conllpp模型对为例），通过对比在原始测试集与另两个数据集上获得的帕累托边界发现：基于训练集剖析结果在测试集上得到的边界，与直接基于测试集剖析的边界高度吻合。所有相关配置中最大分数差异仅4个百分点，平均差异2个百分点，验证了剖析策略的充分性与鲁棒性。

5.5 多任务与多模型案例研究

数学任务：为验证DroidSpeak机制在其他任务类型的适用性，我们将其应用于数学推理数据集。 我们在专精数学推理的微调模型对上应用DroidSpeak，并使用GSM8K [102] 数据集进行测试。如图18(a)所示，获得的帕累托边界与LongBench模型及数据集的模式高度相似，证明了DroidSpeak广泛的适用性。

智能体工作流案例： 我们基于领先的多智能体框架MetaGPT [40] 构建编码智能体系统进行实测。该系统包含使用evolcode模型的编程智能体与使用toolace模型的测试智能体，前者负责根据提示编写Python函数，后者负责测试代码并为下一轮修改提供反馈。

通过以不同速率向系统发送HumanEval数据集问题，结果如图16所示：在保持生成质量（pass@1得分52.5）的重计算配置下，DroidSpeak将TTFT显著提升2.7倍，并同步降低了问题解决的端到端延迟。

专家混合模型测试： 我们在MoE模型上验证DroidSpeak效果。如图19所示，当发送方为Mixtral-8x7B、接收方为Mixtral-8x7B-Instruct时，DroidSpeak同样实现预填充延迟的显著降低。尽管MoE模型可能针对不同输入激活不同专家，但该选择仅发生在注意力模块之后的线性层（即KV缓存使用环节），因此DroidSpeak的缓存共享机制对MoE架构依然有效。

5.6 轻量模型对比分析

为展示DroidSpeak在质量-延迟权衡上的优势，我们将搭载DroidSpeak的大模型与同架构轻量模型进行对比。

如图18(b)所示，我们对比了采用DroidSpeak的Llama-3.1-70B-Instruct与同指令集微调的轻量版Llama-3.1-8B-Instruct。数据显示：轻量模型虽实现约4倍预填充延迟降低，但其F1分数较大模型原始得分暴跌约50%。

使用轻量模型加速存在显著缺陷——大小模型切换开销。当资源充足需切换回大模型以提升服务质量时，将产生重新加载大模型的额外开销。而DroidSpeak可通过动态调整重计算层数灵活适配计算资源，为按需弹性伸缩提供更多可能。

5.7 网络带宽影响分析

图20对比了DroidSpeak与未采用流水线优化的基线方案在不同网络带宽下的表现。可见在几乎所有带宽条件下DroidSpeak均优于基线。值得注意的是，在高带宽环境下TTFT的绝对提升幅度会减小，因为此时传输延迟在总延迟中的占比已显著降低。

6 局限性

跨基础模型的KV缓存共享：当前DroidSpeak尚不支持源自不同基础模型的LLM间KV缓存共享，因其生成的KV缓存尺寸存在差异。该场景将留待未来研究。

网络自适应重计算机制：在§4.3中，我们仅基于系统负载调整重计算比例。未来工作可扩展自适应算法以应对网络带宽变化，例如在带宽受限时扩展关键层组的重计算范围。

重计算配置的数据漂移问题：DroidSpeak通过离线剖析确定各模型重计算配置。但当实际测试数据与剖析所用"训练"数据发生显著漂移时，可能导致质量下降。通过定期重剖析更新配置可应对数据变化，此项增强将留待后续研究。

7 相关工作

模型微调：虽然针对特定任务的LLM微调日益重要，但其资源消耗依然巨大。LoRA、LISA等参数高效微调方法[69,79,88,98]有效降低了微调所需的内存与计算资源。

多智能体系统：多智能体系统在代码生成[15,39,40,45,47,76,82]、游戏竞技[1,16,34,59,66,103,104]与社会模拟[70,71]等领域展现潜力。采用微调LLM作为智能体可提升问答系统[14]、工具学习[78]与个性化服务[55]的效果。DroidSpeak重点致力于降低此类系统中的通信延迟。

LLM服务加速：现有研究通过内存同时托管多个LoRA模型来加速服务，而DroidSpeak通过消除预填充计算实现更优加速。其他改进包括优化调度[2,51,56,63,72,80,106]、LoRA模型内存管理[18,79]与KV缓存卸载[31,42,49,52]等，这些工作与DroidSpeak相互正交且互补。

另一类紧密相关的研究通过精简模型架构[62,77,91]实现质量与速度的权衡，但需在GPU中同时托管多尺寸模型，会降低系统服务容量。DroidSpeak仅通过调整重计算层数实现优化，无需面临此问题。

KV缓存优化：先前大量研究聚焦单模型KV缓存优化，包括通过压缩与卸载降低内存和传输成本[52,68,93,94,105]，以及针对同模型多上下文混合非前缀KV缓存时减少预填充延迟[32,97]。由于DroidSpeak专注于跨模型缓存共享，这些正交技术可与其结合使用。

8 结论

本研究针对多模型协同处理共享上下文时存在的重复计算核心挑战，提出了面向复合AI系统的KV缓存共享框架DroidSpeak。我们成功识别出仅需对部分关键层级进行重计算即可维持输出质量，并在多类型模型对、多样化数据集上验证了方案的鲁棒性。

拓展：

数据漂移： 指的是模型在生产环境中遇到的实际数据分布，与它训练（或调试）时所用的数据分布发生了显著变化。当这种变化达到一定程度时，模型之前学到的规律和模式就会失效或变得不准确，导致其性能下降。

本文是如何确定关键层：

第1步：逐层敏感性测试

• 方法：研究人员不是凭猜测，而是通过控制变量实验，对模型对的每一层进行单独测试。

• 具体操作：

  • 对于模型中的第 i 层，让接收方模型直接复用发送方模型对应的第 i 层KV缓存。

  • 与此同时，强制接收方模型重新计算所有其他层（第1到i-1层，以及i+1到最后一层）的KV缓存。

  • 在这个特定的配置下，在测试数据集上运行推理，并记录输出质量（如F1分数、Rouge-L等）。

• 目的：这样就能孤立地看出，单独复用某一层而对其他层进行“净化”重计算时，这一层对最终质量的独立影响。如果复用这一层导致质量大幅下降，说明它非常“敏感”。

第2步：识别关键层

• 方法：分析所有层的测试结果。

• 具体操作：

  • 将每个层在“单独复用”配置下得到的质量分数，与接收方模型完全重计算（质量最高）和完全复用（质量最低）的分数进行对比。

  • 如果复用某一层导致质量分数显著下降（例如，F1分数暴跌超过50%），那么这一层就被定义为 “关键层”。

  • 反之，如果复用某一层后，质量依然接近完全重计算时的水平，则该层被视为 “非关键层”，可以安全复用。

• 核心发现：论文通过此方法发现，对于同源微调的模型对，通常只有约10%的层是关键层。

第3步：构建帕累托边界

• 方法：这是一个系统优化过程，目标是找到质量和计算开销之间的最佳平衡点。

• 具体操作：

  • 不再只是测试单层，而是枚举或智能地组合不同的层组作为重计算目标。

  • 对于每一种重计算层组的组合，计算两个指标：

    1. 质量分数：在该组合下，模型能达到的输出质量。

    2. 重计算开销：通常用重计算的层数来衡量，层数越多，延迟越高。

  • 将所有组合的结果画在一个散点图上（X轴是重计算层数，Y轴是质量分数）。

  • 找出其中的帕累托最优解集，即“帕累托边界”。边界上的点意味着：在相同的计算开销下，它能提供最高的质量；或者说，在相同的质量要求下，它需要最少的计算开销。

第4步：选择最优配置

• 方法：根据预设的质量容忍度，在帕累托边界上做出工程决策。

• 具体操作：

  • 论文中设定了一个质量损失阈值，例如F1分数下降不超过5%。

  • 在帕累托边界上，找到满足这个质量要求（即F1分数 >= 原始分数的95%）的点中，重计算层数最少的那个点。

  • 这个点所对应的重计算层组，就是最终为这个模型对确定的 “重计算配置” 或 “关键层组”。