前言

在vLLM的新版本中有个零开销的前置缓存(Zero-Overhead Prefix Caching)特性，其中零开销是指使用prefix cache和全量计算两种情况下，即使prefix命中率为0，它们的性能也近乎相等。为什么可以做到零开销？这需要分析该特性的具体实现，本文就这个问题展开讨论。

1.问题背景介绍

前置缓存(prefix caching)由于能够降低prefill阶段的计算量从而提升首token性能，被越来越多地使用。其原理是通过跨请求/对话的kv cache复用来减少计算。看一个例子，推理三个不同的请求0,1,2。请求0计算完后可将计算的kv cache保存下来，在请求1计算时前面两个token块的cache就可以复用。同样，请求3可复用3个块，仅需计算tokens_3的内容。

prefix示例

前置缓存设计要考虑的问题：

• 搜索匹配：如何快速匹配新请求的prompt与历史的prompt，找到可复用的kv cache；
• 内存：由于kv cache需要保存在内存中，所要用一定的淘汰策略定期清理；
• 复用内容选择：仅复用prefill阶段kv-cache，还是结合decode阶段内容（当前还不支持PD分离复用）；
• 块的结构大小：每个内存块里面能够容纳多少tokens？选择太长复用率低，太短管理操作成本高；

这些点的变化会影响prefix cache的命中率（hit rate）和推理性能。设计不当时会出现一种情况：当命中率低（复用的kv cache少）时，使用prefix cache特性计算速度比全量计算要低。

在极端情况下，当完全没有匹配的kv cache（即hit rate=0%）时，由于搜索匹配本身需要耗时，这样肯定要比不开prefix cache速度慢。为了发挥prefix cache更大价值，于是就产生了一个问题：如何保证开启prefix cache始终对系统来说都是有正收益的？

尽管prefix cache功能已在vLLM V0中实现，由于存在一定可能导致性能损失，所以默认不开启prefix特性。而到V1版本优化后就可以直接开启，里面做了什么改进？

2.内容分析

在V1版本中主要降低了prefix cache的操作开销，在命中率低场景下prefix cache的创建、查找匹配、管理、淘汰删除等操作基本不影响推理的计算过程。主要进行了：结构优化、操作优化、代码优化。

2.1

vLLM的cache结构优化

在V1版本中对kv cache的管理结构进行了优化，管理对象由seqGroup变为了request id；管理内容得到简化：

• 关键模块：KVcacheManager、BlockPool
• 基本元素：KVcacheBlock，FreeKVCacheBlockQueue。

KVcacheBlock是基础单元，通过它可以构建一个双向链表，其存储信息仅包含block id值、ref_cnt值、block hash值。这个结构有两个好处：

1. 链表中删除block复杂度为O(1)；
2. 不需要引入python的双端队列，简化了存储。

基于KVCacheBlock构建的kv cache架构包括几个关键模块：

• 块池（Block Pool）：存储KVCacheBlock，一般初始化时决定数量，避免多次的python操作。
• 空闲队列（Free Block Queue）：空闲的块的队列，仅存储头尾节点指针信息。
• 缓存块（Cache blocks）：一个map记录hash key 到block id的映射关系，其中的block有kv cache数据
• 请求块（Request blocks）：记录了请求id到block的映射关系。

对比V0：

• 在V0版本中通过LRUEvictor管理空闲队列，其内容相比Free Block Queue复杂；
• PrefixCachingBlockAllocator负责内存块的管理，内容比Block pool复杂；
• V1中cache blocks、request blocks的结构未变，但存储内容上V1更加简单。

2.2

基本操作优化

先分析V0版本的kv cache管理的过程：开辟、释放、淘汰；

• 开辟（allocate）步骤：根据prompt的内容长度计算是否有充足的block，没有返回；若有则到cache_block中去匹配，如果匹配到了block的引用计数+1，没有就直接使用新的block；
• 释放（free操作）：引用计数-1，然后由LRUEvictor管理，
• 淘汰（evictor）主要是维护一个free_table，通过LRU策略淘汰block。

V1的主要操作也是这些，但细节有所不同：

内存开辟步骤：

1. 检查是否有足够的空间为新请求来开辟block；
2. 从cache block检查是否可以复用，可以复用从free队列剔除，引用计数+1；
3. 若无复用数据从free队列中头中弹出一个block用于写数据
4. 如果block写满了数据，则被cached block标记

内存释放：request使用完后，将block送回free队列里面，如果是cached block，引用计数-1，最后的这个block 最先放入队列中，它可能未被cache；

淘汰策略：根据LRU策略淘汰队首的block cache，并从cached blocks字典中去除记录。

这里分析一下block的状态，如下图所示，所有的block存放在block pool里面，block在free block和cached block里面可能有记录（标记）

• cached block 里面记录历史request请求的block id，这些块中所有的tokens位置都完成了计算。部分计算block不会记录到cached block里面。
• free queue里面标记未被请求占用的block；
• block还一种状态就是被request在使用但内容未完全占满，那么它即不在free queue中、也未被cached block记录。

下面举一个例子来说明block的管理机制，每个block支持最多4个tokens使用，block pool里面有10个block。现在需要处理3个请求，抵达和释放时机如下：

请求的时序

请求0的处理：

请求0的prompt：A-O，如下图，它需要使用block0~3，其中block0,1,2的存储都被使用完，所以其ID会被cache blocks字典记录；block3只使用3个tokens，不会被记录。

请求0 Prefill阶段

请求0的decode阶段时候会生成tokens（假设是两个）如下所示，此时block3也会被cache blocks记录。

请求0的decode阶段

请求1的处理：

请求体1的prompt是14个tokens，有10个tokens与请求体0相同，能够复用block0和block1。block2中尽管有2个tokens相同但是不能够复用，因为必须block的tokens全部相同才能复用。

请求1的处理

cache blocks状态刷新：增加了一个hash值对应A-J,kl，字典记录ID值：0 1 2 3 5

请求体0和请求体1的释放

先释放请求体0资源，再释放请求体1资源

请求体0的释放：blocks 2,3,4按照相反顺序被加到了free queue的队尾。block2和3依然保留了cache block的hash值；block0,1由于被请求1继续使用，不能加入free queue中。

请求体1释放：block0,1,5,6 按照相反顺序加入free queue；cache block记录继续保留。

请求2的处理：

请求2一共有29个tokens：A-L,0-16，根据规则先会到cache blocks去匹配。由于A-L有历史记录，所以会复用blocks0,1,2。 这些block从自由队列中去除，队列ID变为了：7-8-9-4-3-6-5。

接着tokens 0-16需要完成计算，从队列里面弹出5个blocks依次是7,8,9,4,3承载新的计算输出。

cache blocks状态： 由于blocks 3被请求2重新使用，所以它先从cache blocks里面删除(淘汰)。接着，blocks7,8,9,4的hash值会存入cache blocks字典中。

2.3

代码效率提升

整体简化：（代码实现位置vllm/v1/core/)主要功能实现在三个文件中，block和free queue作为独立元素定义在kv_cache_utils里面。block_pool负责block的开辟、释放、cache等操作，还承载free queue；kv_cache_manager 则是对外的接口类（无继承关系），串联所有模块，同时兼容了非prefix的场景。

减少了python对象(object)的使用。比如在cached blocks构建中v1版本就简化存储对象用str和int代替。

KVCacheBlock定义简化。内容仅包括：两个int数据、两个链表指针（python中的对象ID）、hash值。

结构类简化：FreeKVCacheBlockQueue相比LRUEvictor需要操作的内容更少。LRUEvictor单独维护一个free table，且free table里面存储的是BlockMetaData。相比之下v1的管理仅需要维护一个简单双向链表，仅需要存储python id。

由于结构优化、操作优化和代码优化，使得cache命中率为0的场景下性能基本无影响，而只要命中率>0就能提速推理，整体呈现正收益。在vLLM V1版本中，prefix cache经过优化做到了在0命中率的情况下对性能无损，如下图所示是一个对比测试。

最后

为什么要学AI大模型

当下，⼈⼯智能市场迎来了爆发期，并逐渐进⼊以⼈⼯通⽤智能（AGI）为主导的新时代。企业纷纷官宣“ AI+ ”战略，为新兴技术⼈才创造丰富的就业机会，⼈才缺⼝将达 400 万！

DeepSeek问世以来，生成式AI和大模型技术爆发式增长，让很多岗位重新成了炙手可热的新星，岗位薪资远超很多后端岗位，在程序员中稳居前列。

与此同时AI与各行各业深度融合，飞速发展，成为炙手可热的新风口，企业非常需要了解AI、懂AI、会用AI的员工，纷纷开出高薪招聘AI大模型相关岗位。

最近很多程序员朋友都已经学习或者准备学习 AI 大模型，后台也经常会有小伙伴咨询学习路线和学习资料，我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师给大家这里给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频 全系列的学习资料，这些学习资料不仅深入浅出，而且非常实用，让大家系统而高效地掌握AI大模型的各个知识点。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

AI大模型系统学习路线

在面对AI大模型开发领域的复杂与深入，精准学习显得尤为重要。一份系统的技术路线图，不仅能够帮助开发者清晰地了解从入门到精通所需掌握的知识点，还能提供一条高效、有序的学习路径。

但知道是一回事，做又是另一回事，初学者最常遇到的问题主要是理论知识缺乏、资源和工具的限制、模型理解和调试的复杂性，在这基础上，找到高质量的学习资源，不浪费时间、不走弯路，又是重中之重。

AI大模型入门到实战的视频教程+项目包

看视频学习是一种高效、直观、灵活且富有吸引力的学习方式，可以更直观地展示过程，能有效提升学习兴趣和理解力，是现在获取知识的重要途径

光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。

海量AI大模型必读的经典书籍（PDF）

阅读AI大模型经典书籍可以帮助读者提高技术水平，开拓视野，掌握核心技术，提高解决问题的能力，同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说，阅读经典书籍是非常有必要的。

600+AI大模型报告（实时更新）

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。

AI大模型面试真题+答案解析

我们学习AI大模型必然是想找到高薪的工作，下面这些面试题都是总结当前最新、最热、最高频的面试题，并且每道题都有详细的答案，面试前刷完这套面试题资料，小小offer，不在话下

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】