推荐语

深入解析Transformer架构的核心思想与技术细节，带你理解Attention机制的本质与价值。

核心内容：
1. Transformer架构的诞生背景与革命性意义
2. 传统RNN框架的局限与Attention机制的优势
3. 如何通过原论文理解Transformer的设计哲学

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

2017 年，Google 的八位科学家联合发表了机器学习领域的一篇里程碑式的文章 - 《Attention Is All You Need》[1]，在文章中作者提出了一种完全基于注意力机制的新型深度学习框架 - 也即日后鼎鼎大名的 Transformer。顶流就是顶流，时至今日，该文章的引用量已达惊人的 20W+，风头可谓一时无两。

图 1. 从 GFS，到 Kubernetes

再到 Transformer，Google 真可谓云计算领域的指路仙人

强烈推荐大家阅读一下《Attention Is All You Need》原文[1]。我知道，网上介绍 Transformer 框架的文章汗牛充栋，基于开源 PyTorch 库教你手把手实战 Transformer 的教程也比比皆是。然，“谋定而后动，知止而有得”，原汁原味地评鉴一下这篇经典文献（文章内容很精炼，八、九页纸的篇幅）绝对有助于你更好地了解 Transformer 背后的设计哲学，更深地理解 “Attention” 的本质，继而能够在自己的专业领域用好 “Attention”，服务好 “Attention”。

Pre-Transformer 时代是怎样的？

RNN（Recurrent Neural Networks，循环神经网络）可以说是上个时代的霸主，该框架在解决语言建模（language modeling）和机器翻译（machine translation）等任务上表现甚是出众。但是，RNN 这类深度学习的框架有两大“原罪”：

• 一者，RNN 需要维护一个隐藏状态（hidden states），该隐藏状态取决于上一时刻的隐藏状态。这种内在的串行计算特质极大阻碍了训练时的并行计算；
• 二者，RNN 依赖隐藏状态来传递信息，这个效果非常受限于序列距离。后来，业界已有提出注意力机制（attention mechanisms）来改善此问题，该机制能够无视序列的先后顺序，稳定、直接地捕捉序列间的关系。不过，彼时的注意力机制是配角，总是要委身于循环网络；

这个就是 Transformer 出道的两大动机，即直接摒弃先前的“循环”和“卷积”，完全基于注意力机制而构建的新型深度学习框架，最后达成了“既要”（训练时间更短），“又要”（训练成本更低），“还要”（训练效果更优）这一堪称 4.0 的效果。

所以，理解 Transformer 的关键是理解 Attention。但是，Attention 并不好解释，甚至 Attention - 注意力这个词本身就过于抽象了，不是吗？

在学习了各种资料之后，我逐渐形成了如下认知，私以为这些认知有助于朴实地理解什么是 Attention。

我们首先来回答一个问题：你觉得这个世界是可以描述的吗？嗯，我不要你觉得可以，我要我觉得可以。如果这个世界是可以描述的，依赖的自然是一些可观测的特征，譬如词汇（可基于此实现拼写纠错、词表映射、子词合并），语法（可基于此实现解析、信息抽取、依存关系判断），语义（可基于此实现语义检索、同义替换、聚类），实体/属性（人名，地名，机构等实体以及属性，可基于此实现知识抽取，知识问答），事件/时序/因果（可基于此实现摘要、时间线生成、推理），情感/语气/意图（可基于此实现情感分析、对话管理、意图识别），主题/话题分布（可基于此实现分类、检索、路由），......

图 2. 基于大量可观测的特征，人类逐渐成长，学会了去认知这个大千世界

没错，人类认知大千世界大体就是这个思路：“提取”各类事物的特征，然后去做特征“匹配”。不过，LLM 大模型并没有选择基于静态的、离散的特征表条目来演进自身的认知能力，因为这种形式的表述能力太弱；死板的 0/1 匹配亦无法提供近似表示；再者，不具备可微性亦导致无法自动发现有用特征；...... 总之，LLM 大模型选择引入向量这种表示形式。回头想一想，向量这种表示真是很有魔性，好，真好，咋那么好呢！相较于静态、离散的特征表条目，向量表示提供了高效、可微、具泛化能力且能压缩复杂语义的表述方式，甚至很适合用梯度学习从大量文本中自动提取模式，优势不可谓不显著。以 GPT‑3 175B 为例，它内部处理使用的向量维度大小（通常也被称为 hidden size）达到了惊人的 12288！啧啧啧，这表述能力得多强。总之，一个高维的向量表示提供了更多自由度去编码大量交织的属性，譬如词性、实体、时态、事实证据、上下文线索等等。

尤其地，向量表示的一个非常厉害的地方在于其提供了平滑泛化的能力，向量空间允许“相似”输入得到“相似”表示，模型可以对未见过的组合或近似表达进行合理推断。譬如你训练过 “red apple” 和 “green pear”，那么在语义空间上就能够推断 “green apple” 背后向量表示的位置。故而，基于一个向量的匹配查询（譬如基于向量内积运算），那么得到的就不是非 0 即 1 的死板的、确定性的查询结果，而是一系列的相似度值。关键点来了，因为向量的近似表示，针对某个查询（以向量的形式），我们会拿到一系列近似表示（同样也是一系列向量）的候选人，我们该如何选择呢？记住了，成年人不做选择！LLM 大模型引入权重矩阵，（也就是所谓的注意力矩阵），用来表示“用多大的权重去关注一众潜在候选人”，主打一个雨露均沾。

以上就是我对 Attention 注意力机制的理解，怎么样，是不是会感觉被点拨到了 ...... Anyway，铺垫完成啦，让我们继续 Transformer 的领悟之旅。

图 3 展示了一个 Decoder-only 架构的 Transformer 模型（这个图直接截取的原 Transformer 模型的 Decoder 部分，实际上 Decoder-only 的架构模型，可以参考文章[36]中的 GPT-1 的架构，只有 Masked Multi Self Attention），这类架构的 Transformer 模型最适合生成任务，也是目前 LLM 大模型的主流架构，譬如 OpenAI 的 GPT，阿里的 Qwen，Meta 的 Llama，Google 的 Gemini，不外如是。通常的 Transformer-based LLM 包含如下三大关键步骤：

• Embedding（嵌入层，图中红底部分）：该层主要做一些输入处理。譬如根据词汇表做分词，将文本输入(术语叫 prompt ) 切割成一个一个令牌（术语叫 token，可以是单词或者子词，譬如我们的 Qwen2.5 就使用了一个大小为 151643 的词汇表来做分词）。进一步地，每个 token 会被转换成 embedding 向量，这是一个高维向量，能够最大化地抓住词语的语义表示。正如上文提到的，GPT‑3 175B 这里的 embedding 向量维度就已达到 12288。具体这里的转换参数，自然就是各大 LLM 模型辛辛苦苦训练出来的结果，属于核心机密 🤫，不足为外人道也。另外，你看到了吗？图 3 里面针对 embedding 向量还有一个加号运算，这是要把输入序列中每个 token 的“位置”信息也转换成向量，然后叠加到 embedding 向量，总之，每个 token 的“位置”信息是很重要的，后续的训练/推理强烈地需要用到这些“位置”信息； 
• Transformer Block（图中灰色 Nx 重复处理层）：过了 Embedding 层，接下来是 Nx 重复处理层。这里的重复，指的是处理层的功能是重复的，但是处理参数自然不尽相同（同样，这些个参数也是 LLM 模型辛辛苦苦训练所得，属于核心机密 🤫，不足为外人道也）。经过层与层之间转换，Token 的表示也益发的高阶，益发的错综复杂。事实上，这里也是 Transformer 最为核心之处，是所谓大模型参数量的绝对主力。以 GPT‑3 175B 为例，它的 N 为 96，然后在 175B 的参数总量中，96 层的 Transformer Block 足足占据了 174B 的参数量。我们待会儿再详述该层的各种细节。总之，记住了，经过这一层复杂的处理，embeddings 向量就得到了对应的同维且上下文化的向量（contextualized embedding）。该怎么理解这个向量呢？这是一个含有丰富、分布式、上下文相关语义特征的向量，它的语义不是单一标签，而是由向量方向和子空间组合表达的丰富信息，譬如词义，句法，实体，任务信号等等（总之啊，向量表示YYDS！同志们呀，一定要教育下一代好好学习线性代数 😄）。这个向量已经足够支撑 LLM 大模型完成其真实野心：准确地预测出下一个令牌（next token）；
• Output Probabilities（输出概率，图中上面部分）：几乎所有 LLM 大模型最后都有这么一个 Linear 层（Language Model Head，线性投影层），它的用途是把上一层算出的 contextualized embedding，映射到 vocab_size 维的向量里，对，就是起初我们提到的词汇表，因为 LLM 最终要算的正是 vocab_size 个词汇表里每个词成为 next token 的概率。通俗一点来说，可以认为线性投影层做的事情是把上下文化的隐藏向量映射为对每个词的打分。然后，还有一步 Softmax 层（归一化）的处理，将打分的结果转换成条件概率分布，该分布就是模型在当前上下文下认为每个 token 出现的可能性。注意，此概率只是模型的预测分布，非真实概率，通常还需要再进一步通过 argmax/采样等策略方可得到具体下一令牌（next token）；

图 3. Transformer 模型 Decoder 部分

实际 Decoder-only 模型可参考文章[36] 里 GPT-1 架构

接下来，我们要揭开 Transformer Block 层的面纱，一览这里针对 embedding 向量做的各种奇妙变换。

事实上，这里包括两个处理子层，其一谓之自注意力计算子层，让令牌与其他令牌通信，捕获上下文信息和单词之间的关系。在这一子层，每个 token 的 embedding 向量会被首先转换成三大向量：Query (Q)，Key (K)，和 Value (V)。怎么转换呢？当然是依赖 LLM 大模型辛辛苦苦训练出来的核心结果 🤫，这个训练结果就包括每一层的注意力投影矩阵（W_q, W_k, W_v）。Transformer-based LLM 大模型正是根据这个注意力投影矩阵，获得了 Query，Key，Value 这三大向量。

该怎么理解这三大向量呢？以我们日常使用搜索引擎来查找某类信息来打个比方，Query (Q) 可类比我们具体的查询输入；搜索结果出来后，我们会看到非常多相关网页，Key (K) 可类比每个搜索结果页的标题，而 Value (V) 则类比具体搜索结果页的内容。这里，我们一定要始终坚持一个认知，向量表示的查询是丰富的，具备平滑泛化能力的。也就是说，每一层的职责是不一样的，每一层的表示也是不一样的，故而进入每一层，均需要重新映射出相应的符合该层表示的 Query (Q)，Key (K)，Value (V)。通俗来讲，Q 表示“在这一层，我要找什么”，K 表示“在这一层，我有哪些可被匹配的标签”，V 表示“在这一层，被选中后要返回的内容”。如下图 4 所示，我们来看一个具体例子。这个输入一共有 6 个 tokens，每个 token 是 768 维的向量（dmodel = 768），经过某一层三大注意力投影矩阵（W_q, W_k, W_v，这投影矩阵大小为 768*768 ）的线性变换，为每个位置映射出 Query、Key、Value 三种向量，实际应用中还得加上 Bias 偏置向量，这里就不展开介绍了。正如上文所述，每一层的注意力投影矩阵（W_q, W_k, W_v）是 LLM 大模型辛辛苦苦训练出来的，属于核心机密，实不足为外人道也 🤓

图 4. 从 Embedding 向量到每一层投影后的 Q/K/V 三大向量

终于要直面 Attention 了

然后呢？如图 5 所示，按照 Transformer 论文呈现的（我们不妨将其奉为金科玉律 😄）。这里的参数 d_k是所谓键值向量 K / 查询向量 Q 的维度，跟 LLM 大模型里常常提及的 Multi-Heads（多头）概念有关，即上文提及的 embedding 向量维度 dmodel 除以头数，便得到了这里的 d_k 。总之，经过 K 的转置换算，然后与 Q 的矩阵相乘，继而再除以缩放因子，再做 Softmax 归一化处理，最后再通过与矩阵 V 的矩阵相乘运算，即得到了注意力矩阵。注意力矩阵为每一个位置将上下文信息按相关性权重保存，以用于最终的 next token 预测。

注意，针对一个输入的 Prompt，通常是由一个 tokens 序列组成的，这里 Attention 输出的 out 张量，事实上是面向每一个位置用于“预测下一个 token”的上下文信息，并以相关性权重的方式保存。对于本文重点要探讨的 LLM 推理场景而言，这里自然关心的是最后一个 out 向量。动一动你的小手，推导一番，很容易就能够推导出，最新 token 位置对应的 out 向量，依赖前面所有 token 的 K 向量，前面所有 token 的 V 向量，以及仅仅依赖当前 token 的 Q 向量。关于此处的推导，vLLM 的经典论文[14]里也有精炼的概括，诸君不妨拜读一下。

到现在，我们总算是破题了：为什么有 KV Cache 一说，那是因为过往 token 相关的 K，V 这两处缓存可以大量节约当前 token 的 Attention 的计算量，而 Q 呢？即用即算，没有缓存的意义。所以，坊间一直有流传，KV Cache 用得好，KV Cache 用得妙，LLM 大模型的推理能力顶呱呱。

图 5. 大名鼎鼎的 Attention 函数，将上下文信息按相关性权重保存

用于预测 next token

我们再简单聊一聊 Transformer Block 层的另一个子层，前馈网络（FFN）子层（Feed-Forward Network），即对 Attention 输出进行非线性变换，用非线性激活构造高阶特征。注意，前面的 Attention 变换只做按权重把别处的信息混合回来，它并不在通道维度上做复杂的非线性组合，故而这里的 FFN 子层进一步提供了位置级别的非线性表达能力，例如扩大维度，激活函数，生成高阶特征等等。可以说，没有 FFN 子层，LLM 大模型就丧失了大量表示能力，难以生成高质量文本信息。不过，FFN 是对每个令牌位置，独立地、完全相同地实施变换。故而，这块的复杂计算跟我们本文要探讨的 KV Cache，关系不大。多说一句，FFN 子层的运算复杂，相关参数也是 LLM 大模型辛辛苦苦训练出来的，层与层之间的参数各不相同。并且，FFN 子层的输入输出的外部维度保持不变（标准 Transformer 中的 FFN 在每个位置上把维度从 dmodel 映射到更大的中间维 dff，再映射回 dmodel）。至于参数量，大体可以认为，FFN 子层的参数量是 Attention 子层参数量的两倍，两者一起撑起的几乎是 LLM 大模型的参数全量。也正因参数量巨大，FFN 这一层的优化空间也非常地大，可谓宽阔天地，大有可为！相较于本文讨论业界在自注意力计算层的各类优化——主要围绕着 KV Cache 展开的，FFN 这块算法级优化给 LLM Inference 带来的改进同样不可小觑。

图 6. 前馈网络 FFN 子层，对 Attention 输出进行非线性变换，激发高阶特征

以上是对 Transformer 模型的浅显介绍。不才深耕有状态分布式系统这个技术领域十余年，要说 Transformer 模型给我最深刻印象，大抵三处：一者，“向量表示”；二者，“next token 机制”；三者，“contextualized 化的 attention 机制”。其余者，无它，唯大力出奇迹尔 ......

这里岔开一下话题。自从 ChatGPT 问世以来，Transformer 的确是火热异常，到了“凡有井水饮处，即能歌柳词”的地步。Transformer 的演进终态能够抵达白月光 AGI 么？恐怕未必。前段时间看到斯坦福大学教授、World Labs 创始人李飞飞的一个博客访谈[2]，聊及当前火热的 LLM 大语言模型，给了一些很有见地的输出。李飞飞认为，当前的 LLM 主要通过海量的文本数据学习，的确达成了非常惊人的成就，但是这并不足以支撑人类构建出 AGI（Artificial General Intelligence，通用人工智能）。原因在于，人类大量的知识是无法仅仅通过语言来捕捉的，事实上，人类的学习过程本质上是具身的，我们在没有语言的情况下与世界有大量的互动，感知光线、触觉、重力和空间关系等等。当前基于 LLM 的 AI 真的懂物理吗？譬如目前很多生成式视频能够展现出水流或树木摆动，是的，看着非常真实。不过，相信大部分人都认同，这些基于 LLM 生成的物理现象（甚至包括重力、碰撞等现象）更多是基于统计规律的模仿，这是基于海量数据的统计学涌现，而并非基于牛顿力学计算。故而，为了构建真正的 AGI，当前的 AI 需要走出文本限制，即进入 Post-Transformer 时代，通过视觉和行动去体验物理世界。再有一个是持续学习的范式，我们人类在遇到新的环境时候会不断地学习，而 LLM 这类大型语言模型在训练后参数就基本固定了，尽管在测试时的推理阶段会再有一定程度的学习。

图 7. 从牛顿力学，到工业革命，物理科学极大地推动了人类社会的发展

所以，Post-Transformer 时代何时到来呢？李飞飞乐观地预计在五年内，这个时间点预计当然与她在主导的 “World Models” 以及 “Spatial Intelligence” 利益相关。不管怎样，包括 OpenAI，DeepMind，Anthropic 和 DeepSeek 等公司的首要目标都是 AGI，那么，我们有理由相信，人类距离 Post-Transformer 时代，不会太远。

Anyway, leave the strategy to the suits upstairs — we’re here to execute perfectly ：）

让我们将话题回归 LLM 大模型本身。当前，大型的语言模型，参数通常在数十亿至数万亿级别，训练的数据规模集更是超百万亿级别，从商业的角度来看，大规模的数据和参数意味着巨大的算力需求，而且算力和能源总归有上限。事实上，2020 年 OpenAI 的一篇经典论文里了提出了描述 LLM 大模型的 Scaling Law 定律，该定律指的大模型的最终性能主要与计算量、模型参数量和训练数据量三者的大小相关，而与模型的具体结构（层数/深度/宽度）基本无关 [3]。之后，各大 AI 厂商就进入了基础模型训练的军备竞赛，总之就是堆算力、堆数据。经过这几年疯狂的发展，各大 LLM 大模型面临的局面是：人类可用的预训练数据即将耗尽！另外算力资源，包括人类能够产出的电力资源，这方面的瓶颈已然浮现。

图 8. 全球各大 AI 大模型，产生了巨大的能源消耗，尤其是电力资源

故而，大力出奇迹的 Age of Scalling 已过，业界重回精耕细作的 Age of Research[4]，研究如何提升预训练数据的质量，研究如何在强化学习阶段，包括推理阶段更聪明地使用算力。

是的，训练与推理，可谓当前 LLM 大语言模型的两大修罗场，各方诸侯厮杀正酣。我们更关注推理这个修罗场，正如 Google 云的一篇文章里面宣称的[5]，市场在 AI 推理这个赛道的投入，即将超过训练大模型本身的开销。这个很好理解，“天下苦 AI 训练久矣”，模型演进了那么多年，市场投入了那么多真金白银，是到了考虑收益的时候了。君不见，我中华各类发电厂众多，火力发电，水力发电，风力发电，太阳能发电，核能发电，甚至潮汐发电，...... 终究是国家电网这类输电类的企业主体成长为了业界巨擘，也诞生了特高压输电这类领先蓝色星球的核心技术。

这篇文章，关注的是 AI 推理过程中的 KV Cache，或者我们应该称之为 “attention caches”，我们将深入地探究一下 KV Cache 提速 AI 推理的奥义之所在。

如上文描述的，Transformer-based LLMs 在自回归输出 next token 的时候，需要最新 token 的查询（Query），和目前为止前序所有 tokens （自然也包括最新的 token）的键（Key），值（Value）做 Attention 注意力计算，随着 tokens 数量的不断增长（这里包括 prompt 里的 tokens，以及已经输出的 tokens），需要的计算复杂度达到了立方级 —— 。

很直观地，业界很快地意识到，如果在 LLM 推理过程中充分利用 KV Cache，即缓存已经处理过的 token 的键（Key），值（Value），那么每轮只需要计算当前 token 的键（Key），值（Value），与 KV Cache 做 concatenate，最终再和当前 token 的查询（Query）一起计算注意力向量，这样就可以降低算力需求至平方级 —— 。这个自然称得上是惊艳级的诱惑：既能大幅节约成本，又能显著提升推理速度，故而，一时引得天下各路诸侯竞折腰，各种创新、优化接踵而至。尤其地，GPU 的算力是非常紧张的，亦是非常昂贵的，特别是在当前的国际政治形势之下，故而，国内的从业者们对 KV Cache 的关注度显得更加炽热 😄

不过，我觉得我们首先得面向广大存储人，纠正一个叫法，这里的 Cache 叫 “KV Cache”，合适么？

图 9 是存储人所熟知的传统意义上的分布式 “KV Cache”，身处计算节点与分布式存储之间，服务对象是后端分布式存储系统。分布式存储系统面临着日益高涨的访问需求，特别是读请求的压力与日俱增。故而，架构师们选择在“计算”，“存储”的中间，引入一层 KV Cache Layer，抗住了绝大部分的读请求压力。就个人而言，我通常会把这种场景下的 KV Cache 形容为面向“历史记录”的缓存，它要解决的问题空间是明确的，无论 Key 抑或是 Value，都静静地躺在分布式存储系统中，它们一直都在那里 ...... 并且，自始至终，KV Cache Layer 的目标只有一个，访问加速，甚至不去考虑数据持久化。通常，后端分布式存储系统要做数据持久化，数据要落盘，而 KV Cache Layer 大多以内存为主，故而访问加速这个目标，实际并不难实现。

图 9. 传统意义上的 KV Cache，身处 “Compute” 和 “Storage” 之间，做存储访问加速

LLM Inference 阶段的 “KV Cache” 在整个系统中的位置呢？如图 10，是的，它自然算是某种 “Cache”，这个定位没有错，不过它更像 “Compute Cache”，不是么？它能够出道的全部理由均在于避免重复计算，更具体来说，通过缓存计算的中间产物，来避免中间过程中的一些重复计算。我更愿把这种场景下的 KV Cache 形容为面向“未来认知”的缓存，它要解决的问题空间几乎可以认为是不可穷举的。所以，相较于纯依赖 GPU 的向量计算，这里引入“Compute Cache”有两大目标：更快的响应，更低的成本。

这并不是一句废话，要知道传统的分布式“KV Cache”在访问速度上，相较于后端分布式存储系统是具备碾压级优势的。而在 LLM Inference 场景，“Compute Cache” 通常是一个分级存储架构，从 GPU VRAM，到 CPU DRAM，再到 NVMe Storage，甚至是 Storage Backends，...... 特别是到了 Storage Backends，谁又能打包票，咱这里的存储读写一定快过本地的 GPU 算力呢？所以，更加极致的访问延迟需求，更加极致的访问吞吐需求，这是所谓“Compute Cache”的宿命。是呀，这不得看跟谁比嘛。

再说成本，因为 “Compute Cache” 面向的是“未来认知”的场景，故而其缓存空间需求没有上限（传统的分布式 KV Cache 的缓存上限，就是后端的分布式存储系统）。从 GPU VRAM，到 CPU DRAM，再到 NVMe Storage，甚至是 Storage Backends，...... LLM Inference 场景下，需要在这多级缓存之间实现高效的数据流动，最终实现访问效率最大化，整体成本最优化。这个并不容易，很多时候这里本身就是一笔糊涂账。

图 10. AI 推理场景下的 Compute Cache，缓存了计算的中间产物，避免昂贵的重复计算

拿生活中案例类比，分布式存储系统中的“KV Cache”可以类比电影预告片，通常预告片要简短有力地吸引观众的注意力，直接地表达电影正片的主题；而 AI 推理场景下的“Compute Cache”呢？可以类比演员们在每天开拍前，并不需要把之前的剧情再演绎一遍，而是看下回放找感觉，然后就可以继续表演啦。

所以啊，“Compute Cache” 称得上是个新课题（遵循大家已经形成的认知习惯，下文还是继续称之为 KV Cache 吧 😳），本章节，我们尝试梳理一下业界在 KV Cache 这块做的一系列里程碑式的探索，正是这些探索在持续地、卓有成效地提升着 LLM Inference 的核心性能。大幕拉开，这里将亮相的，我愿称之为 “LLM 推理界五虎”，它们分别是：vLLM，SGLang，LMCache，Moonshot Mooncake，以及 NVIDIA Dynamo。

vLLM 作为 LLM 推理框架的“一哥”位置已然牢固。

所以说，凡事得趁早，早起的鸟儿有虫吃。vLLM 出道于 2023 年，作为一款古早的以 KV Cache 为中心打造的开源推理框架，其在 GitHub 已经斩获 65K+ Stars，Contributors 众多；生态圈建设成绩斐然，与主流大模型、GPU 等硬件厂商都保持着密切合作；vLLM 一直以来都与 HuggingFace 有着深度集成，持续支持着各类开源大模型。

图 11. vLLM 在 LLM 模型部署这一块的影响力还是非常大的

vLLM 的开山之作，是 PagedAttention 的这篇论文[14]。虽说业界早早地意识到了 KV Cache 的重要性，但是以往的深度学习框架通常以连续内存空间来存储张量信息，Transformer-based LLMs 沿袭了这类框架部署，无奈受限于两处掣肘，KV Cache 无法发挥最大效能：

• 内存碎片问题：一个 prompt 请求对应的 tokens，连同其生成的 tokens 都要摆放在一个连续的内存空间，那么框架只能按照最大可能长度来准备一块连续内存。有的请求长，有的请求短，内存碎片自然而然就产生了。即使说吧，这个框架比较神奇，能够预测到请求的长度大小，提前给准确地分配了一块不大不小正合适的连续内存，问题是在这个请求的生命期里（依托于 next token 机制，生成的 token 还得一个一个吐出来），这块内存空间是不可被利用的。再者说了，这种连续分配内存的机制，必然会产生一些外部内存碎片，即虽然空闲但是因为大小不合适而无法被有效利用起来；
• 内存共享难题：实际的 LLMs 的解码算法是很丰富的，譬如 parallel sampling 和 beam search，这些算法都会针对一个 prompt 输入，产生不同的 sequences (对应不同的 outputs)，这里自然就存在相当的 KV Cache 共享空间。然而，在已有的 LLM 框架中，针对不同 sequence 都是分配的不同的连续内存空间来管理的，何来内存共享这一说？

为什么我们要对 GPU VRAM 内存扣的这么细？这里的一个背景知识是 LLM Inference 过程中，每个 prompt 所需的内存空间都不是个小数目。以 13B 的 OPT 模型为例，单 token 所需 KV Cache 空间就已达到 800KB，而一个 2048 tokens 的 sequence 所需要的 KV Cache 空间则达到了 1.6GB。当今的 GPU 技术持续迭代，从 NVIDIA A100 到 H100，FLOPS 计算力增强了 2 倍有余，GPU 内存却继续停留在 80GB 😕。可以预见地，GPU 内存资源肉眼可见地变得紧张了起来。

说回 vLLM，它的优化思路朴素地可能会让今人哑然失笑：参考操作系统中经典的内存管理机制，引入虚拟内存（virtual memory）与分页机制（paging techniques）。如图 12 所示，PagedAttention 分配内存以 “KV Block” 为单位，每个 “KV Block” 可以存储指定数目的 tokens 对应的 Key 向量及 Value 向量。基于 PagedAttention 机制，vLLM 可以把 “KV Block” 摆放在非连续的内存空间，进而具备了更加灵活的内存管理能力。

继续以图 12 右边的例子来说明，每个 “KV Block” 可以存储 4 个 tokens 对应的 KV Cache 向量，此时有一个 Prompt 为 “Four score and seven years ago our”，这里的 Block Table 继而给其分配 2 个逻辑的 “KV Block”，序号为 0，1，对应到物理 GPU VRAM 上的 “KV Block” 序号为 7，1。注意，因为 Prompt 一共就 7 个 tokens，故而分配到的第 2 个 “KV Block” 并没有填充满，表中有个 #filled 标志来记录该 Block 中已填充的数目，此时数值为 3。在进入到 Output 阶段后，第一个 token 是 “fathers”，那么继续放置在第 2 个 “KV Block” 的最后位置， #filled 标志也一并更新为 4，不浪费一点儿空间。下一个输出 token “brought” 在物理上则开始使用 Block #3 的空间，的确很灵活。对于内存共享场景，这个对于 vLLM 自然也是 easy 模式，多个逻辑 “KV Block” 是可以映射到同一个物理 “KV Block” 的。这不，它还为每个物理 “KV Block” 引入了经典的 reference count，以及 “copy-on-write” 机制以支持共享缓存的分叉情形。总之，抄作业抄得很彻底。

在具体的 Prompt 执行流程上，vLLM 引入了一个中心化的 Scheduler 角色来协调不同 GPU Workers 一起工作。具体的内存管理则通过 Scheduler 进程内部的 KV Cache Manager 模块来实施。vLLM 的 Scheduler 怎么调度一个一个 Prompt 请求呢？首先，它充分地借鉴了当时已有的改良版的 batching 技术，即不再按照请求粒度做 batching，而是按照 iteration 粒度做 batching，这个很有意思，兼顾公平性以及防饿死；其次，有关 “KV Cache” 的驱逐策略，vLLM 使用了一种启发式的算法来预测哪些个 “KV Block” 在最近不会被访问，就选择驱逐这些个 “KV Block”。要点来了，一个 sequence 内的所有 blocks 是利害共同体，秉承着 “all or none” 的指导思想，要么一起被驱逐，要么都保留；最后，关于如何管理这些被驱逐的 “KV Block”，类似经典操作系统中的 Swap 技术，vLLM 也在每个 GPU Worker 分别引入 GPU block allocator，以及 CPU block allocator，后者即承载了被驱逐的 “KV Block”。自然，在适时的时候， CPU block allocator 也负责将这些个 “KV Block”重新加载回 GPU vRAM。

图 12. vLLM 的系统架构，以及 PagedAttention 内存分配机制

这里要特别探讨一下 Scheduler 模块的状态问题（不才的职业习惯，看到任何系统架构，第一反应都是它是否有状态，如何管控状态，如何做高可用，😄）。官方的文档里提到了 vLLM 的三种部署模式[24]，分别是 Single-GPU，Single-node multi-GPU，以及 Multi-node multi-GPU。对于高可扩展的多节点多 GPU 模式，自然有个直接依赖，中心化的 Scheduler 如何与 Workers 们认识并通信？答案是更基础的分布式计算框架 - Ray[25]。好吧，状态依赖转移了，Ray 同学需要负责 Scheduler 与 Workers 的服务发现，负载均衡等等。那么，Ray 需要分布式协调服务（类似 Google Chubby，Hadoop ZooKeeper，Kubernetes Etcd）做元数据存储以及服务高可用么？你别说，还真别说，......，Ray 的社区还真探讨过这个问题 [27]，当前 Redis 是其单点依赖。

vLLM 是一个成熟的用于部署各类主流 LLM 大模型推理服务的框架，业界演进的速度很快，vLLM 也在不停地迭代进化。现在回过头来看，vLLM 最大的贡献是什么呢？我认为更多地在于它定义了一个推理框架应该具备的基础功能模块，譬如围绕着虚拟内存建设的高效 KV Cache 管理模块，譬如考虑 KV Cache 分布情形来做相应请求路由的灵活的 Scheduler 调度模块，譬如对各类解码算法的支持，parallel sampling，beam search，等等，譬如一个多级存储架构（从 GPU VRAM，到 CPU DRAM，再到 NVMe Storage，甚至是 Storage Backends）以支持 KV Cache 根据其热度在不同层之间的高效流动，......

更为重要的是，vLLM 展示了 KV Cache 的确可以是 LLM Inference 的性能胜负手，此处的优化空间巨大。此番意义，不亚于茫茫的淘金时代，当众人在苦苦找寻的时候，忽然有人喊了一声：“我这里发现金子了！”，于是乎，众人皆蜂拥而至 ......

vLLM vs. SGLang，一时瑜亮也。

SGLang 全称是什么？Structured Generation Language for LLMs，这居然是一种编程语言 ......

图 13. SGLang 出道于 2023 年岁末，其高效的推理效率

以及对多模态的内在支持，技惊四座

可以说，SGLang 的出现，完全是顺应了 LLM Inference 服务大规模应用部署后发生的新形态变化，比如多轮对话，推理任务，多模态输入以及格式化输出等等。形势比人强，我们与 LLMs 交互的方式也从简单的对话模式，升级为更复杂的类编程的方式（LM Programs，Language Model Programs）。事实上，我们常听闻的 prompting techniques（提示词工程）以及 Agentic workflow（智能体工作流）也都属于这个用法范畴。

简单来说，所谓 LM Programs，须得具备两大基本属性：

• 通常依托控制流组合多个基本的 LLM 调用，以此实现复杂任务，并提升整体质量；
• 支持结构化输入与结构化输出，这样有利于 LM Programs 之间的组合使用，包括与现有软件系统的整合；

但是，已有的系统支持 LM Programs 不给力啊！一者，因为 LLMs 本质上的不确定性（如上文探讨的，Trasformer-based LLMs 应该算是统计学的涌现），如何编程实现 LM Programs 的确不是个简单的事情，毕竟无以遵循；二者，因为执行 LM Programs 太低效了，简单来说就是很费资源，无论是 GPU 计算资源，还是 Memory 内存资源，都很费！

图 14. SGLang 的架构，前端简化 LM Program 编程，后端运行时则优化执行

这些理由已经足以支撑 SGLang 出道了[15]。如图 14 所示，SGLang 是 “前店后厂” 模式，前端提供了一个嵌入到 Python 的 DSL 编程语言[18]，支持一些原语语义（譬如与 LLM 互动的 extend, gen, select，以及用于并发控制的 fork, join 等等）。SGLang 在后端运行时（Runtime）则做了大量的优化，包括大名鼎鼎的 RadixAttention 以优化 KV Cache 复用率；压缩的 FSM 以支持更快速的结构化输出（譬如 JSON 格式的输出）；与闭源的 LLM （譬如 GPT-4）近乎黑盒般交互情况下的 API 级专项执行优化。

我们首先囫囵吞枣般过一下如何写一个 SGLang 风格的前端机。图 15 展示了一个基于 SGLang 实现的支持多模态输入的文章评审功能。这里会添加一些系统提示词（System Prompt），然后将图片，以及评语部分一并作为 Prompt 提交，根据相关性评估结果，如果不相关，则直接返回；否则，并行地从“Clarity”，“Originality”，“Evidence”三个维度做进一步的评审。最后，还明确地约束输出为 JSON 格式。这个实现看着还是比较简洁的，不是么？

事实上，结合后面 SGLang 在 Runtime 做的大量优化，我们会发觉 SGLang 前端提供的编程范式是个必要的前提条件，它事实上已经将多轮调用按照工作流进行了有效组织，这个给予了后续 Runtime 极大的优化空间。

图 15. 基于 SGLang 实现支持多模态输入的文章评审

红色字体的皆为 SGLang 提供的原语

我们接着重点聊一聊 SGLang Runtime 的核心优化：RadixAttention。虽然 RadixAttention 看起来跟 vLLM 的 PagedAttention 比较类似，不过两者属于关公战秦琼，不挨着，事实上两者倒是可以组合起来使用。下图 16 展示了一个 RadixAttention 示例，包括其 LRU 风格的缓存驱逐策略。在（2）~（3）步骤，是单独的一个会话，分别缓存了 System Prompt - “You are a helpful assistant”，以及 User Prompt，还有 LLM 的 Response；步骤（4）则新建一个聊天会话，其与原会话共享 System Prompt 相关的 KV Caches。步骤（6）则是接收了一个小样本学习（Few-shot Learning）的查询请求，故而根节点要分裂，这块与先前的会话无任何可共享的 prefix KV Caches。步骤（7）则是接收了更多的小样本学习的请求，这里自然就存在可共享的 prefix KV Caches。伴随着更多的缓存进入 Radix Tree，近期最少被使用的叶子节点对应的 KV Cache 会被驱逐。

本身 RadixAttention 还需配合以 Cache-aware Scheduling 策略方可最大化缓存命中率，提升整体的推理效率。SGLang 的推理框架中，请求调度器（request scheduler）并不是按照 FIFO 策略来服务的，而是在一批 Prompt 请求中（contiguous batching），通过基于 RadixTree 深度优先的遍历，找到 prefix 最长匹配的请求优先处理。SGLang 给自己的做法提供了一个定理证明（果然是学术风满满 😄），如下：

Theorem 3.1. For a batch of requests, we can achieve an optimal cache hit rate by visiting the radix tree of the requests in the depth-first search order, with a cache size ≥ the maximum request length. The longest-shared-prefix-first order is equivalent to a depth-first search order.

图 16. SGLang 最引以为傲的 RadixAttention，一个示例

同样，这里要展开探讨一下 SGLang 的状态问题。毕竟 "Cache-aware Scheduling" 是 SGLang 的一大特色，这里显然是存在状态依赖的。事实上，在分布式架构下，SGLang 会维护两层 Router：一层是中心式的 Router 维护了 Meta-RadixTree；另外一层是每个 Worker 在维护的 Sub-RadixTree。自然，中心式的 Router 需要状态维护，需要 HA 高可用建设，社区也曾发起过这类讨论[28]。总而言之，言而总之，类似 Etcd 这类分布式协调服务还真是一个强劲的、无处不在的基础依赖啊 😄

有关 SGLang 通过压缩的 FSM 支持结构化输出，以加速 LLM Inference 的输出效率，以及与闭源的 LLM（譬如 GPT-4）近乎黑盒般交互情况下的 API 级专项执行优化，这里我们就不再赘述了。总之，因其领先的执行效率，包括内存的高效使用，SGLang 在业界的影响力是越来越大。图 17 是 SGLang 官方展示的合作方，覆盖了各大硬件厂商，主流大模型背靠的云厂商金主们，五花八门的 LLMs 应用侧客户，国际知名的高校、研究所等等。

图 17. SGLang 的生态属实一片盎然生机，的确值得上手一试

坦率地说，相较于 vLLM，SGLang 的确很适合复杂的多轮对话、推理任务和多模态输入等等场景。虽然上手成本高了许多，但是在收益面前，这些都不是问题。业界 SGLang 相关的实践已然很多。

vLLM 与 SGLang 的鏖战正酣，两强争霸的态势隐然若现。

无论 vLLM，还是 SGLang，两者都有一个共同的出发点在于高效地管理 KV Cache，进而提升推理效率。话虽如此，两者都想成为 LLM Inference 这个领域的 “the de facto industry standard”，故而，LLM 推理界双雄在各条战线上展开了火拼。

所谓术业有专攻，小强 LMCache 盯上了具体的 KV Cache 这一块，潜心经营，反倒率先显现出成为“LLM 推理框架 KV Cache 层的工业界事实标准”的气质。如图 18 所示，LMCache 的定位非常清晰，专注于缓存层的抽象与优化，与两强的关系都不赖，分别有被 vLLM 以及 SGLang 集成进生态，混的那叫一个风生水起。LMCache 自身以一种分布式的方式，有效地管理起计算侧的 GPU 缓存。向下，LMCache 充分地利用各种存储后端（Mooncake，Redis，InfiniStore，......），适时地将 KV Cache offloading，从而提供更具水平扩展性的 KV Cache Layer。

图 18. LMCache 定位很清晰：上承主流 LLM Inference 框架，中连 GPU 计算侧缓存，下抚一众存储后端

图 19 给出了 LMCache 归纳总结的 KV Cache 两个主要场景 [21]，一者是所谓 “Context Caching”，这里缓存的 KV Cache 来自公共的 System Prompt，以及专业知识库相关的 RAG Context 等等，通常这部分 KV Cache 比较大，甚至需要 offloading 至 CPU Memory，乃至 Local Disk；其二是所谓 “P/D Disaggregation Caching”，推理俩阶段，生成首 token 的 Prefill 阶段，以及逐个生成后续 tokens 的 Decode 阶段。两个阶段对资源需求截然不同，前者要充分地利用 GPU 并行化的强劲算力，后者则非常依赖 Prefix KV Caches。故而，目前主流生产实践都在应用“P/D Disaggregation”架构。这个架构的一个强依赖就是 Prefill 引擎与 Decode 引擎之间的高效通信，分享 Prefix KV Caches。

图 19. LMCache 支持的两大 Caching 场景：

query 请求之间，与一个请求内的 P/D 分离

LMCache 对 KV Cache 的应用场景总结，可谓善也。所以，旨在统一 KV Cache Layer 的 LMCache 祭出了何等大杀器？无他，惟如下三点：

• 其一，模块化的 KV Cache Connector，提供标准化的访问接口，将 KV Cache Layer 从快速演进的 LLM Inference 框架中脱离出来（一份统计报告宣称，2025 年里每周都至少有 15~20 个新的开放权重的 LLM 模型发布，LLM Inference 框架需要快速迭代，更好地利用硬件，更好地适配新权重的模型），不影响上下游的兼容性。这个解耦的思路与云计算大背景下的计算存储分离的演进是类似的；
• 其二，有关 KV Cache 的高效管理，包括高效地 storing KV Cache，包括高效地 loading KV Cache。这里的一大优化是 pipelining 技术，涉及到 GPU compute 与 data loading/storing 之间的 pipelining，以及 KV Cache 的 storing 与 loading 之间的 pipelining；另一大优化是 batching 技术，以 chunk 为单位（远大于具体操作的 page 页大小）store/load KV Caches，以充分地利用存储设备与 GPU 内存之间的网络带宽；另外，在不同存储层之间移动 KV Cache 数据时候，应用 zero-copy 零拷贝技术，减少内存拷贝；
• 其三，面向 KV Cache 的管控平面，这个很新颖，也是 LMCache 根据实际大规模应用后提炼的真实需求，即 LLM Inference 框架的其它模块有着 KV-cache-aware 的切实需求。故而，LMCache 提供了这个一个管控平面，用户可以针对 KV Caches 做诸如 pinning, lookup, cleanup, movement, and compression 等操作。譬如 2025 年早些时候，某金融公司即在生产场景下给 LMCache 提出需求，希望能够 pin 住 KV Cache 中经常需要访问的金融类文档信息；而另一家 agent 公司则提出需求，能够根据指定内容，寻找相应的 KV Cache，压缩之，然后在节点之间传输压缩的 KV Cache；

来看一看 LMCache 的架构设计。如图 20，我们分别以存储（Store），读取（Retrieve），查询（Lookup）三个常见操作来看下请求的工作流：

• 存储（Store）：当一个 Prompt 请求进来，它首先会到 KV Connector 模块。该模块会准备相应的 metadata，包括 tokenized input prompt，以及对应 pages 的 GPU 地址；然后交由 Token Processor 模块继续处理，该模块会确认这里有多少 tokens 对应的 KV Cache 不在存储后端；最后，Storage Manager 模块会通过 Transfer Channel 模块，将这部分新的 tokens 对应的 KV Cache 缓存至 backends；
• 读取（Retrieve）：当一个请求进来需要从后端加载 KV Cache，同样，首先依赖 KV Connector 模块准备相应的 metadata，然后 Token Processor 模块会识别出来已经在存储后端的 prefix-matched 的 tokens 数量；然后是 Event Manager 模块，它检查相同的 query id 是否已经存在：如果存在，说明 KV Cache 的地址信息已经收集，可以直接返回给 GPU Connector 模块，该模块会负责将 KV Cache 加载回 GPU VRAM；如果不存在，该请求会被转发给 Storage Manager 模块，它会查询 KV Cache 的 CPU 内存地址。最终也还是经由 Event Manager 模块，交 GPU Connector 模块加载至 GPU 内存；
• 查询（Lookup）：有些时候，LLM Inference 框架里的上层模块，譬如 KV-cache-aware 的 router 需要查询 Cache Controller 模块，检查指定 tokens 对应的 KV Cache 是否在后端。Cache Controller 模块维护了一个 token 池，记录了哪些 tokens 对应的 KV Cache 当前是在后端存储的。所以当 LMCache 实例存储或者驱逐了一个 KV Cache，其内嵌的 LMCache Worker 要把这个该信息及时汇报给 Cache Controller 模块，后者及时更新，这样总是可以提供一个全局的、最新的 tokens 记录池；

多聊几句 Cache Controller，这是一个中心化的角色，负责全局性的 metadata 管理，Cache 操作，以及请求路由。如图 20，这是一个两层的架构，中心化的 Cache Controller，与散落在每个节点上的 LMCache Worker 共同组成。自然，这里存在着服务寻址，服务高可用，元数据存储等等一系列需求，看起来这里也应该需要一个类似 Etcd 这类的轻量的、强一致性、高可用的分布式协调服务，这也是业界的最佳实践。不过，我并没有找到 LMCache Controller 直接依赖类似 Etcd/ZooKeeper 三方组件的证据，反而看起来是依赖 LMCacher Worker 主动汇报并重建全局一致的状态信息[33]，可能是不希望架构变得复杂，也可能是单纯地不希望引入更多外部依赖。

不过，现实情况是，Cache Controller 这个模块的存在也非必须，例如 Ceph 提出的 vLLM + LMCache + Ceph 最佳实践中，就不需要这个中心化的 Cache Controller 模块[29]，这个思路与 Ceph 的 “计算 location 胜于查询 location”的设计哲学如出一辙，强依赖 S3 提供的 GetObjectAttributes 能力，依据每个 token block 的哈希值，直接就可以定位到相应的 KV Cache 地址。

图 20. LMCache 的整体框架，e2e 的视角看其各功能模块是如何协作的

LMCache 专注于 KV Cache Layer 优化，的确做的有声有色：它为 vLLM v1 提供了高性能的 CPU KV Cache offloading，Prefill/Decode 分离的功能支持，P2P KV Cache 共享能力；它同时也为 SGLang 提供了 KV Cache 的 offloading 能力；除此之外，关于如何更高效地表示 KV Cache，如何尽可能地提高 KV Cache 复用率，LMCache 也一直在努力探索着[21]，真可谓一手抓工业落地，一手抓学术研究，两手都很硬 😄。

Kimi 与 DeepSeek，宛若双子星般的存在，这两年是名声赫赫，自不必过多介绍。

Mooncake 是 Kimi 的服务部署平台，也是为 Training/Inference 两大场景而重磅推出的 "KVCache-centric disaggregated architecture"，也斩获了 FAST'25 Best Paper Award。

Mooncake 最让人印象深刻的，绝对是它先进的架构。如图 21 所示，首先看到的应该是其 Prefill Instance 以及 Decoding Instance 吧？是的，当业界还在争论 Prefill/Decoding 这个架构在大规模部署场景下是否行得通（主要考虑是给网络带宽带来了更高有求，以及 chunked prefill 的相关权衡），Mooncake 通过其高度优化的 Transfer Engine 在实际应用场景中证实了这条技术路线的可行性。所以，Mooncake 架构里单独维护了 Prefill 以及 Decoding 资源池，当然这里的配比是很有讲究的，Mooncake 在论文里给出了自己的实践经验。

然后呢？资源池化，彻底的池化，GPU 集群里面的各种资源，从 CPU，DRAM，SSD，包括 RDMA 资源全面的池化以支持 Global Cache。

再有，一个强大的 Transfer Engine，只有充分地挖掘 RDMA 网络通信能力，才能让 "Transfer KV Cache" 相较于 "Recompute KV Cache" 更合算，同时从成本以及响应时间两个维度的双赢。Mooncake 在论文里给出了详尽的数学分析，严谨地论述了跑赢 GPU 的可行性。

还有，就是左侧的全局调度器，KVCache-centric Conductor，这里也包括三块细分的调度器，分别是面向 Prefill 阶段的 Cache-aware Scheduler，它不仅仅考虑尽可能复用 KV Caches，还进一步考虑了每个 Prefill Instance 的请求队列的忙碌情况；然后是面向 Decoding 阶段的 Load-balance Scheduler，主要考虑每个 Decoding Instance 的负载均衡情况；还有个关键的 KVCache Balance Scheduler，也就是核心的 Mooncake Store，它统筹了全局的各类资源，提供了 Distributed KVCache Pool，是既管 Storage，又管 Transfer，妥妥的核心竞争力。

图 21. Mooncake 的整体架构图

借着图 22，我们从一个请求的处理流程，来看各个模块是如何协作的。当处理一个 prompt 请求时候，首先自然是分词（tokenizing），然后 Conductor 会为该请求选择一对 prefill nodes，以及一个 decode node，接着：1）从 CPU 内存加载 Prefix KV Cache，秉承着”能用尽用“的原则，加载到 GPU 内存以供给生成首个 token；2）在 prefill 阶段，自然也需要计算一些新的，增量的 KV Cache，这部分要存储到 CPU 内存；3）然后是传输，这个阶段很关键，可以与前面的阶段 pipeline 处理，提升整体效率，目的地是 decode node；4）最后就到了 decode 阶段，类似 vLLM 中提到的，采用一种 continuous batching 模式，逐个生成 next token。

图 22. 从一个 prompt 请求处理流程

看 prefill instance 与 decode instance 如何协作

我们得好好聊一聊 Mooncake 的 Transfer Engine，个人认为这块也是 Mooncake 做生态最可能出圈的地方。关键还是抽象，Transfer Engine 的目标有三：

• 充分地利用多个 RDMA NIC 设备，灵活分配传输任务，聚合传输带宽，充分地挖掘网络传输带宽的能力；
• 抽象出统一 API 接口，隐藏硬件相关的技术细节，支持 DRAM，VRAM，以及 NVMe 等存储设备之间的数据移动；隐藏 RDMA 连接管理的复杂性，支持 TCP，RDMA (InfiniBand/RoCEv2/eRDMA/NVIDIA GPUDirect)，以及NVMe over Fabric (NVMe-of) 等等网络通信协议；
• 处理临时网络故障，当面临网络故障时，Transfer Engine 内部能够自动选择备用链路，保障数据传输；

Transfer Engine 早期的假想敌之一是 NCCL（NVIDIA Collective Communications Library），这个通信库倒是也能够充分地利用多个 RDMA NIC 设备的通信带宽能力，不过，它并不能友好地支持网络拓扑动态变换的场景，也不支持 DRAM-to-DRAM 的传输链路，这个也使得 NCCL 无法从容应对网络故障情形。

而 Transfer Engine 这一边，如图 23 所示，每个 Server 都会生成一个拓扑矩阵（topology matrix），并在集群内广播。这个拓扑矩阵记录了啥？不同 memory 类型对应的 preferred NICs 列表，以及 secondary NICs 列表。图 23 中的例子，cpu:0 对应的 preferred NICs 列表有两个 [mlx5_0, mlx5_1]。如果此时有个传输任务，需要把数据从 buffer 0（分配给了 cpu:0） 传输至 buffer 1（分配给了 cpu:1），那么 local NIC 可能会选择 mlx5_0，而 target NIC 则可能选择 mlx5_3。此外，Transfer Engine 会通过 local NUMA，或者 GDR（GPU Direct RDMA）through the local PCIe 来加速 RDMA 相关操作。引入拓扑矩阵的好处，一方面是支持故障逃逸；另一方面是大的 request 请求可以切片后并行传输，充分地利用 RDMA 网络传输带宽。

图 23. Mooncake Store 的核心竞争力 - Transfer Engine

这里再单独聊一聊 Mooncake 的 P2P Store 场景，它主打的场景是集群内跨节点的临时对象分享，譬如训练的快照文件，防止单点网络带宽被打爆的情形。这块工作，跟咱们家的 OSS Connector 当前发力的点比较类似。OSS Connector 内部基于 DADI P2P 的传输分发方案，提供跨 Pod 的分布式内存数据传输分发，从而降低了对底层 OSS 读吞吐的线性强依赖。这类无主 P2P 结构，通常会引入基于一致性哈希算法的一系列 cache server，避免单点瓶颈。而在哪里维护这些 cache server list 呢？Mooncake P2P Store 选择的是 Etcd。

图 24. Mooncake 社区生态发展的很好

Mooncake 拥有着一个欣欣向荣的社区生态。如图 24，Mooncake 与 vLLM，SGLang，LMCache 都有着不同程度的生态集成，NVIDIA 重磅推出的 Dynamo 中 NIXL 通信库也官方支持 Mooncake 的 Transfer Engine 作为 backend plugin。尤其地，Mooncake 还集成了阿里云自研 eRDMA 网络的底层传输路径，以及兼容 eRDMA 的 GPUDirect，大赞啊！

在 2025 年 3 月份 GTC 2025 峰会上，NVIDIA 面向广大 Reasoning AI Models 重磅推出了高吞吐、低延迟的开源推理框架 - Dynamo（是的，跟 AWS 的 Dynamo 数据库重名了）。这个出道时间也比较微妙，Dynamo 宣称的几大优势在前面几个 LLM Inference 重量级选手面前都算不上太新鲜，可能其最大优势还是在 NVIDIA 原厂支持吧 ......

图 26 展示了 Dynamo 的整体架构，如文章[17]里面介绍的，Dynamo 包括四大核心组件：Planner，Smart Router，Distributed KV Cache Manager，以及 NVIDIA Inference Transfer Library (NIXL)。

Dynamo Planner 主要做 GPU 计算资源规划的。在 Prefill/Decoding 分离架构下，大规模的 GPU 集群里如何有效供给 GPU 算力会变得非常复杂。事实上，Mooncake 的文章里也探讨过如何合理地配比 Prefill/Decoding 实例数，他们认为静态配比也已足够使用，动态配比过于复杂且收益没有那么大。Dynamo Planner 呢？它会实时监控全局范围的 GPU 关键性能指标，结合 LLM Inference 应用的 SLO 约束 - Prefill 阶段的 time-to-first-token (TTFT)，以及 Decoding 阶段的 inter-token latency (ITL)，然后给出及时的决定：是否要 Prefill/Decoding 分离的方式服务请求，还是采用耦合的方式服务请求？是否要给 Prefill/Decoding 分离的两个阶段补充更多 GPU 算力？

到了 Smart Router，它做的就是本文主要探讨的如何最大程度地复用 KV Cache，以节约宝贵的 GPU 算力（是呀，连 NVIDIA 自己都觉得贵）。它的基本思路也是引入一个 RadixTree 来做高效的 Prefix 匹配，继而将请求发送至最相关的 workers，这样做到最大程度复用 KV Caches。当然，Smart Router 也包括定制化的 KV Cache 保存以及驱逐机制。

Distributed KV Cache Manager 则是一个分层的存储解决方案，承接 GPU VRAM 里比较旧的那些 KV Cache 的 offloading。所以，它包括哪些存储层呢？CPU host memory，local storage，以及 network object storage。有了这个分层的存储解决方案，Dynamo 可以以一个经济的方式支持 PB 级的 KV Cache 数据。

图 25. NVIDIA Dynamo 的整体系统架构

重点说一说 NIXL 通信库吧，它的野望与 Mooncake 的 Transfer Engine 几乎如出一辙：AI Inference 场景下 hardware-agnostic，network-agnostic 的高性能通信库，提供一致的语义支持点对点的高吞吐、低延迟的数据传输。如图 27 所述，这个数据传输可以发生在 CPU Memory，本地的 Block，File，Object 等类型存储，也可以与现有的 UCX，GDS，S3 等通信库交互数据。甚至，NIXL 也支持选择 "the best backend connection"。此外，类似支持 large embeddings 的 zero-copy RDMA transfer，这对于 NIXL 已属常规操作。不得不感叹，NVIDIA 的生态太强了，像 NIXL 这么底层的通信框架库，NVIDIA 的确很容易做出圈的。

图 26.NVIDIA Inference Transfer Library (NIXL)

Dynamo 也依赖 Etcd，特别是分布式部署场景。Dynamo NIXL 依赖 Etcd 做服务发现与元数据存储[31]，每个节点启动后会向 Etcd 注册以便于互相发现；此外，每个节点在完成初始化并分配好所有 KV Cache 内存，会将相应的内存描述符这个元数据信息存储在 Etcd，这样各个节点查询中心式的元数据，继而可以依赖 RDMA 直接访问远端节点的内存数据。

分享了这么多，继续回答第 3 章节一开始的问题：相较于传统的面向分布式存储系统的 Distributed Cache，KV Cache 是新瓶装旧酒吗？

答案很明确，不是。还记得人家真名吗，"Compute Cache"。

正如前文给两者之间的区别做了一个非常生活化的比拟，我们再回顾一下：

拿生活中案例类比，分布式存储系统中的“KV Cache”可以类比电影预告片，通常预告片要简短有力地吸引观众的注意力，直接地表达出电影正片的主题；而 AI 推理场景下的“Compute Cache”呢？可以类似演员们在每天开拍前，并不需要把之前的剧情再演绎一遍，而是看下回放找感觉，然后就可以继续表演啦。

图 27. AI Inference 里的 KV Cache 可类比拍电影时看回放

目的是为了接下来的拍摄

所以，从来都是 LLM 计算侧定义了什么是 KV Cache，它甚至没有“实体”，也就是说，KV Cache 存在的意义，从来都是由 LLM 侧决定的。哪些 KV 是 Cache 呢？从开始的 Prefill/Decoding 之间复用 KV Cache，然后是一个会话内的多个请求之间复用 KV Cache，再包括 System Prompt 作为 KV Cache 的复用，哦，别忘记了 RAG（Retrieval-Augmented Generation，检索增强生成）代表的长上下文的 KV Cache，...... 这个定义权一直在 LLM 大模型。

另外，哪些 KV Cache 能用呢？从经典的 Prefix Caching，到 Prompt Caching，业界也在探索更多更高效的 Caching 机制，譬如 EuroSys‘15 的 Best Paper，CacheBlend 机制[32]提出了面向 RAG-based KV Cache 的优化机制，在保证充分利用 KV Cache 提升 Inference 效率的前提下，解决了交叉注意力（cross-attention）缺失的挑战。是呀，否则这 RAG-based KV Cache 就是给你了，你也没法好好用，毕竟不能光图一个“快”字，推理结果不准确也不管不顾了；再譬如，业界正推出的多种基于线性注意力（Linear Attention）的混合模型架构（咱们的 Qwen3-Next 在内的多个下一代主流模型架构也都选择了基于 Linear Attention 的混合模型架构），这类架构在维持模型表达能力的同时，显著地降低了长上下文推理场景下的计算与内存开销。

在这两大基础问题解决之后，业界其它技术领域（网络，存储，以及计算调度等等）方才进来承接业务需求，全力解决各类瓶颈问题。

譬如，因为当前的 Transformer-based LLM 大模型在 Prefill/Decoding 两个阶段的目标以及资源瓶颈呈现的显著差别，这才有了 Prefill/Decoding 分离的架构。也正是大规模的 Prefill/Decoding 分离架构，这也进而给与了网络通信库强劲的发展诉求，无论是 Mooncake 的 Transfer Engine，还是 NVIDIA 的 NIXL，皆乘了这股东风。

再譬如，因为 "Compute Cache" 巨大体量的诉求，这就有了分层存储。首先是近计算侧的 CPU Memory，Local SSD Storage，这是 Redis 的机会，也是 DADI 这类近计算侧的分布式缓存的机会。然后，这块也进一步纳入了各类分布式存储系统，Google 推出了 Managed Lustre[5]，阿里云存储的 CPFS [34]，阿里云数据库 PolarKVCache[35]，...... 不管多少层存储，注意了，最终消费侧在 GPU Memory，故而这里才是实际在用 KV Cache 的容量上限。

最后，再多说一句纯纯的个人观点，各位看官轻喷。YY 一个 KV Cache 存在性的潜在“隐忧”，GPU 算力。如果 GPU 算力速度更快，成本更低，那么在到达一个临界点之后，KV Cache 存在的合理性可能会消失？这里绝非是要给 KV Cache 泼冷水，相反，现在看起来投入 KV Cache 还正当时呢。只是希望大家也能够更多关注 Transformer-based LLM 大模型本身的发展，毕竟，这是 KV Cache 的衣食父母也。

参考文章：

[1] Attention Is All You Need，https://papers.nips.cc/paper_files/paper/2017/hash/3f5ee243547dee91fbd053c1c4a845aa-Abstract.html；

[2] How World Models are Changing the Future of AI Beyond Transformers，https://www.youtube.com/watch?v=9VcXiyE40xw；

[3] Scaling Laws for Neural Language Models，https://arxiv.org/abs/2001.08361；

[4] Ilya Sutskever – We're moving from the age of scaling to the age of research，https://www.dwarkesh.com/p/ilya-sutskever-2；

[5] Reducing TCO for AI inferencing with external KV Cache on Managed Lustre，https://cloud.google.com/blog/products/storage-data-transfer/choosing-google-cloud-managed-lustre-for-your-external-kv-cache；

[9] What is a Transformer?，https://poloclub.github.io/transformer-explainer/；

[11] 上下文缓存（Context Cache），https://help.aliyun.com/zh/model-studio/context-cache；

[13] MOONCAKE: Trading More Storage for Less Computation – A KVCache-centric Architecture for Serving LLM Chatbot，https://dl.acm.org/doi/10.5555/3724648.3724658；

[14] Efficient Memory Management for Large Language Model Serving with PagedAttention，https://dl.acm.org/doi/10.1145/3600006.3613165；

[15] SGLang: Efficient Execution of Structured Language Model Programs，https://dl.acm.org/doi/10.5555/3737916.3739916；

[16] An Efficient KV Cache Layer for Enterprise-Scale LLM Inference，https://lmcache.ai/tech_report.pdf；

[17] NVIDIA Dynamo, A Low-Latency Distributed Inference Framework for Scaling Reasoning AI Models，https://developer.nvidia.com/blog/introducing-nvidia-dynamo-a-low-latency-distributed-inference-framework-for-scaling-reasoning-ai-models/；

[18] Writing a Domain Specific Language (DSL) in Python，https://dbader.org/blog/writing-a-dsl-with-python；

[21] LMCache - Accelerating the Future of AI, One Cache at a Time，https://lmcache.ai/；

[24] Parallelism and Scaling for vLLM，https://docs.vllm.ai/en/stable/serving/parallelism_scaling/；

[25] Scale Machine Learning & AI Computing | Ray by Anyscale，https://www.ray.io/；

[27] when head node failes, how to keep the ray cluster still work，https://github.com/ray-project/ray/issues/10065；

[28] SGLang Router design discussion，https://github.com/sgl-project/sglang/issues/2389；

[29] KV Caching with vLLM, LMCache, and Ceph，https://ceph.io/en/news/blog/2025/vllm-kv-caching/；

[31] NVIDIA Inference Xfer Library (NIXL)，https://github.com/ai-dynamo/nixl；

[32] CacheBlend: Fast Large Language Model Serving for RAG with Cached Knowledge Fusion，https://dl.acm.org/doi/10.1145/3689031.3696098；

[33] Support full sync controller-side and update all，https://github.com/LMCache/LMCache/pull/2261；

[34] 文件存储 CPFS，https://www.aliyun.com/product/nas_cpfs；

[35] 大模型推理加速（PolarKVCache），https://help.aliyun.com/zh/polardb/polardb-for-mysql/user-guide/polarkvcache-inference-acceleration；

[36] Meet GPT, The Decoder-Only Transformer，https://towardsdatascience.com/meet-gpt-the-decoder-only-transformer-12f4a7918b36/；