- 综合排序
- 最热优先
- 最新优先
- 来自专栏信数据得永生
KVCache原理简述
所以我们通过传入KVCache保证K和V是完整的，输入字符只传入最后一个，也就是上一次GPT生成出来的字符，就可以了。
87240编辑于 2023-10-13 - 来自专栏存储公众号：王知鱼
深解华为UCM的KVCache优化之道
Transformer架构的自回归机制与长上下文需求，共同将矛头指向了KVCache——这项“以存代算”的关键技术在提升速度的同时，也带来了巨大的显存压力，成为新的性能枷锁。 当KVCache直通向HBM，当重算不再是“一刀切”而是“精准手术”，当自回归的串行瓶颈可以被“历史记忆”检索所打破，AI推理的效能边界是否将被重新定义？ 阅读收获 掌握系统级稀疏化新思路：理解GSA算法如何超越传统稀疏注意力，通过“最大范数+SVD”的块表征与系统IO协同，从而优化KVCache在外存与显存间的数据流动效率。 UCM Github仓库 这款聚焦AI推理过程KVCache管理的中间件产品，在预发布演讲中，曾介绍其核心几大“黑科技”，今天我们一起来看看 UCM 是如何看待未来推理场景的 KVCache 管理的。 KVCache 分块重用原型 虽然业内现在已经支持KV Cache片段重用，但仍存在一些问题。其一是重算的精度的泛化性，其二是重算的性能仍有提升的空间。
17510编辑于 2026-03-09 - 来自专栏存储公众号：王知鱼
大模型推理的KVCache小IO瓶颈解析
KVCache生成原理：计算物理特性的二元对立 要理解KVCache为何成为瓶颈，首先必须从数学和物理层面剖析其生成过程。 这两个阶段在计算强度、内存访问模式以及KVCache的生成方式上存在本质的二元对立 1。 2.1 Transformer注意力机制的数学本质 KVCache的存在是为了加速自回归生成。 KVCache交互： 读取（Load）： 为了计算当前token的注意力，GPU必须从显存中加载之前所有保存的KVCache（即Prompt的缓存 + 之前生成的token缓存）。 3.2.1 逻辑块与物理块的解耦 系统将KVCache切分为固定大小的块（Block），例如每个Block存储16或32个token。 逻辑视图： 对模型而言，KVCache依然是连续的张量。 识别与表征KVCache的I/O特征：解构“小I/O”瓶颈 那么为什么GB级别的KVCache会表现出“小I/O”特征？如何识别和量化这些特征？ 4.1 什么是“小I/O”？
21610编辑于 2026-03-09 - 来自专栏腾讯开源的专栏
分布式KVCache多级缓存架构 - FlexKV正式开源！
1、项目简介 FlexKV 是由腾讯云主导并开源的分布式KVCache多级缓存架构，用以解决分布式 KV Cache 和多级缓存的精细管理，并建起推理引擎到云存储的桥梁。 项目地址 欢迎 Star & Fork，共建高性能分布式KVCache多级缓存架构！
1.6K10编辑于 2025-10-10 LLM推理中 KVCache 提示推理效率的几点应用
LLM推理中KVCache提示推理效率的几点应用这是基于2025AICon大会的马腾的演讲整理而成通过kvCache的优化提升效率，如模型算法优化减少KVCache产生量，KVCache压缩，KVCache 答案或许就藏在"KVCache"这个看似技术化的概念中。KVCache，全称Key-ValueCache，是大模型推理过程中最核心的优化点之一。 从计算角度看，KVCache的引入将自回归生成的时间复杂度从O(n²)降低到了O(n)，大大提升了推理效率。1.2KVCache的规模然而，KVCache的规模往往超出我们的想象。 1.3KVCache的挑战KVCache带来的挑战主要体现在以下几个方面：内存占用是首要问题。GPU显存是稀缺资源，大量的KVCache会占用宝贵的显存空间，影响模型的并行处理能力。 分离指的是将KVCache从模型推理过程中分离出来，形成独立的服务。模型推理节点不再负责KVCache的存储和管理，而是专注于计算任务。
20710编辑于 2026-01-14《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》阅读笔记
需要注意的是，整个架构的kvcache transfer engine是一个distributed kvcache pool，也就是各个节点的内存池信息是互通的，有助于kvcache的共享传输。 其中B是kvcache的传输带宽，G是芯片算力，d代表模型的隐藏层维度，a、b、s是常量，p是序列长度，gqa是q头数量除以kv头数量。 算法思路是先选择P节点，把所有P节点遍历一遍，预估选择每个P节点计算的总耗时，耗时包括3个部分：kvcache传输时间、任务排队时间、做计算的时间。 不满足best_len/prefix_len>kvcache_balancing_threshold，那么就不需要从最佳节点拷贝kvcache过来，直接在这个节点进行计算即可，这种情况T_transfer step6：如果TTFT或者TBT不满足SLO，拒绝请求；step7：进行kvcache拷贝传输。
46600编辑于 2025-05-30- 来自专栏存储公众号：王知鱼
Agentic AI 时代的内存（3）-KVCache卸载与PNM、PIM
现代AI大模型对工作记忆（KVCache）的需求已经超出了当前主流内存技术的极限，形成了一个两难的“架构困境”。 注：上述结论仅从物理时延角度评估 LLM 推理对内存带宽和容量的理论需求，实际工程实践中结合PD分离、Flash Attention 等机制能有效缓解 KVCache的容量和带宽问题。 可以将PNM/PIM 理解为 向量数据库核心算法（HNSW/ANN） 的硬件实现，或者说是实现KV缓存的语义检索，和DPU解耦系统中的网络通信相似，PNM/PIM 的最终目的是解耦推理系统对KVCache Agentic AI and Memory Centric Computing Notice：Human's prompt, Datasets by Gemini-2.5-Pro #FMS25 #KvCache
58210编辑于 2025-11-20 - 来自专栏AI SPPECH
Block Manager 设计：Paged KVCache 内存块管理深度解析
作者：HOS(安全风信子) 日期：2026-01-19 来源平台：GitHub 摘要： 本文深入剖析vLLM中Block Manager的设计原理与实现细节，探讨其在Paged KVCache管理中的核心作用 vLLM作为当前最流行的高性能推理框架之一，其核心创新点之一就是引入了Paged KVCache机制，而Block Manager正是实现这一机制的核心组件。 1.3 vLLM Block Manager的创新点 vLLM的Block Manager通过引入Paged KVCache机制，成功解决了上述挑战： 块级内存管理：将KVCache划分为固定大小的块， 核心更新亮点与新要素 2.1 块分配算法：高效的内存管理机制 Block Manager采用了创新的块分配算法，将连续的KVCache划分为固定大小的块（通常为16KB或32KB），每个块可以独立分配和释放 动态调整：随着生成过程的进行，不断分配新的块来存储生成的token的KVCache。 碎片管理：定期检测碎片率，必要时进行碎片整理。 请求完成：请求处理完成后，释放所有相关块，供其他请求使用。
11610编辑于 2026-01-26 - 来自专栏AI SPPECH
58: vLLM 核心模块逐文件：kv_cache.py
背景动机与当前热点 1.1 KVCache 在大模型推理中的核心地位 在大语言模型推理过程中，KVCache（Key-Value Cache）扮演着至关重要的角色，它直接决定了推理性能和内存效率。 ：随着上下文长度扩展到百万级别，传统 KVCache 设计难以高效支持 分布式场景下的通信开销：在多 GPU 推理中，KVCache 的同步和通信成为性能瓶颈 多模态场景的适配：多模态模型需要更复杂的 KVCache 面临的诸多问题。 核心更新亮点与新要素 2.1 新要素一：Paged KVCache 2.0 架构 vLLM 4.0 版本对 KVCache 模块进行了重构，推出了 Paged KVCache 2.0 架构。 实现原理 Paged KVCache 是 vLLM 最核心的创新之一，它借鉴了操作系统中的虚拟内存分页思想，将连续的 KVCache 逻辑地址映射到非连续的物理地址块上。
15410编辑于 2026-02-10 基于 openFuyao 的 AI 推理加速实战：智能路由与 PD 分离式 KVCache 架构揭秘
为此，openFuyao 社区推出了面向 AI 推理场景的算力释放创新组件，其中“智能路由”与“PD 分离式分布式 KVCache”架构成为关键突破。 PD 分离分布式 KVCache（Parameter-Data Separation）传统推理场景下，KVCache（键值缓存）往往与推理引擎绑定部署，易导致数据耦合、缓存命中率低。 四、性能对比：延迟下降，算力利用率提升在实际测试中，使用智能路由 + PD 分离式 KVCache 后，openFuyao 推理集群的性能提升显著。 性能提升主要来源于：智能路由降低请求调度延迟；PD 分离式 KVCache 提升缓存复用率；集群负载自动均衡，减少节点空转。 这得益于系统在路由调度与 KVCache 分布式访问策略上的协同优化。
36510编辑于 2025-12-11- 来自专栏AI SPPECH
24: 2026 推理工程师能力矩阵：多模态扩展层
2.2 多模态KVCache设计 多模态KVCache是多模态推理系统的核心组件，2026年的主要创新包括： 异构KVCache：针对不同模态数据设计不同的KVCache结构 共享KVCache：支持不同模态数据之间的 3.2.1 多模态KVCache的设计原则 多模态KVCache的设计原则包括： 异构性支持：支持不同模态数据的KVCache存储 高效访问：支持快速的KVCache访问和更新 内存优化：优化内存使用， 动态调整策略：根据负载动态调整KVCache的大小和结构 以下是多模态KVCache的架构示意图： 这个示意图展示了多模态KVCache的架构： 模型层通过统一KVCache接口访问KVCache KVCache 管理器负责KVCache的分配和管理 不同模态数据有各自的KVCache存储 模态感知Eviction根据模态特点设计KVCache替换策略 内存分配器负责KVCache的内存分配和管理 3.2.3 多模态 4.2 多模态KVCache设计对比 设计方案 异构支持 内存效率 访问速度 扩展性 实现复杂度 统一KVCache 低 中 高 低 低 分离KVCache 高 高 中 高 中 混合KVCache 高
28610编辑于 2026-01-22 大模型推理显存和计算量估计方法
显存估计 大模型推理的过程中，显存主要用来存储kvcache。kvcache的大小和token的数量成正比，我们首先来看一下单个token的kvcache怎么计算。 = (total_mem - model_size*kvcache_dtype_byte)*mem_coefficient*1024*1024*1024 # byte kvcache_block_size = 128 max_block_num = np.floor(mem_for_kvcache/(kvcache_block_size*one_token_cache)) print("max_block_num ，然后估算了可以分配多少个kvcache_block。 接着计算一个sequence所需要的kvcache_block数量，最后用总的kvcache_block数量除以一个sequence所需要的kvcache_block数量，得到的就是支持的最大batch
83900编辑于 2025-06-22- 来自专栏深度学习与python
Etcd 客户端缓存实践
) = self.kvcache { if let Some(value) = kvcache.load().cache.search(req.get_key()).await { }); if let Some(ref kvcache_arc) = self.kvcache { let kvs = resp.get_kvs(); let kvcache = kvcache_arc.load(); for kv in kvs { let (succeed, is_insert) = kvcache }); // Wait until cache is updated and then return if let Some(ref kvcache) = self.kvcache { while let Some(kv) = kvcache.load().cache.search(req.get_key()).await { if kv.get_mod_revision
1.3K20编辑于 2023-03-29 - 来自专栏AI SPPECH
12. 推理工程师职责：性能瓶颈诊断
2.2 核心新要素 本文引入了3个全新要素： vLLM KVCache溢出诊断方法：详细介绍了KVCache溢出的表现、原因和诊断方法，包括内存监控、请求特征分析等。 诊断方法： 使用nvidia-smi监控GPU内存使用情况，观察KVCache占用比例。 使用vLLM内置的内存监控工具，跟踪每个请求的KVCache使用情况。 启用KVCache压缩，将KVCache内存占用减少30%。 长期措施： 优化调度策略，优先处理短上下文请求，减少长上下文请求对系统的影响。 实现动态KVCache管理，根据请求特征自动调整KVCache大小。 3.4.4 修复效果 修复后，GPU利用率恢复到80%以上，吞吐量恢复到故障前水平。 诊断要点： 观察KVCache内存占用随请求数量的变化。 分析长上下文请求对KVCache内存的影响。 定位内存回收过程中的性能瓶颈。
31610编辑于 2026-01-20 - 来自专栏AI SPPECH
38. GPU 显存碎片问题如何解决：vLLM的碎片管理技术深度解析
频繁的内存操作：推理过程中会频繁地分配和释放内存，尤其是KVCache的管理，进一步加剧了显存碎片化。 1.3 vLLM在显存碎片管理中的创新点 vLLM作为当前最流行的高性能推理框架之一，在显存碎片管理方面进行了多项创新： Paged KVCache：将连续的KVCache空间映射到离散的物理显存块，避免了对连续内存的需求 核心更新亮点与新要素 2.1 Paged KVCache：从根本上解决连续内存需求 vLLM的核心创新是引入了Paged KVCache机制，将连续的KVCache虚拟地址空间映射到离散的物理显存块上。 KVCache内存池：预分配固定大小的KVCache内存池，用于存储所有请求的KVCache数据。 块大小优化：根据模型和应用场景，优化内存块的大小，平衡内存利用率和管理开销。 未来的推理框架都将采用类似Paged KVCache的内存模型，解决显存碎片问题。
22610编辑于 2026-01-26 - 来自专栏GiantPandaCV
如何看待 DeepSeek 发布的 MoE 大模型 DeepSeek-V2？
size : predict next token 需要完整 load 之前的 KVCache Weight Size：predict next token 需要完整 load 激活参数 Compute FLOPs：模型 forward 一次的计算量 KVCache 显存计算公式与比较 首先给出 KVCache 的计算公式： 其中： MLA 和 GQA 的对比 根据技术报告中的 Table 1 我们可以知道 ：MLA 在推理成本上等效于 GQA 的 我们统一假设对于 KVCache 而言 ， 对于 Weight 而言 ，seq len 默认取 4k，则二者需要的显存可以见下表： DeepSeekV2 单机可以支持 DeepSeekV2 带宽需求：需要加载 236GB (weight size) + 363GB (kvcache) 的显存 2. 该预测结果和 DeepSeekV2 技术报告中的 KVCache 节省量的估计出入较大，而我们可以认为 DeepSeek-67B 是一个 LLaMa3-70B 的近似版本（在 Inference 角度）
81820编辑于 2025-02-03 - 来自专栏AgenticAI
速看！DeepSeek开源周第一弹：FlashMLA加速GPU计算！
使用 from flash_mla import get_mla_metadata, flash_mla_with_kvcache tile_scheduler_metadata, num_splits o_i, lse_i = flash_mla_with_kvcache( q_i, kvcache_i, block_table, cache_seqlens, dv,
19300编辑于 2025-03-18 - 来自专栏Se7en的架构笔记
DeepSeek 开源周第五弹：3FS —— 专为 AI 训练和推理设计的分布式存储
推理 KVCache：提供比 DRAM 缓存更具性价比的方案，具备高吞吐能力，并显著提升缓存容量。 3FS 的性能如何？ KVCache KVCache 是一种用于优化 LLM 推理过程的技术。它通过缓存解码器层中先前 token 的键值向量来避免冗余计算。 下图展示了所有 KVCache 客户端的读取吞吐量，其中峰值吞吐量高达 40 GiB/s。
44010编辑于 2025-05-21 - 来自专栏深度学习与python
不用英伟达严选？DeepSeek 为何自研高性能文件系统 3FS，挑战行业“标准答案”
涵盖了从数据准备（将数据分析管线的输出组织成分层目录并高效管理海量中间结果）、数据加载（无需额外预取或洗牌数据集，支持跨节点随机访问训练样本）、检查点（提供并行高吞吐的检查点保存与重载）到推理阶段的 KVCache 在推理场景下，为优化大规模语言模型（LLM）的 KVCache 查找速度，3FS 提供了高吞吐、强一致性的数据访问能力，单个客户端节点峰值可达 40+ GiB/s，同时支持高效的垃圾回收操作。 通过与 WEKA 集成，并利用其 KVCache 技术，实现了高效的令牌缓存，极大地提升了数据处理的容量、速度和效率。 其三是提供 KVCache 访问协议，在大规模 AI 推理场景下有优势。他指出 DeepSeek 的 KVCache 访问协议，提供了更具性价比的推理解决方案，对于业界来说是“一个很大的突破”。 把 KVCache 放到高性能分布式文件系统缓解了推理对显存容量的要求，把 KVCache 卸载到存储上，以存代算，可以节省算力出来支撑更多的计算任务。
53910编辑于 2025-03-03 - 来自专栏AI SPPECH
2. 训练 vs 推理：真正烧钱的是哪一步
文章深入分析了推理成本的核心瓶颈——KVCache与通信开销，并详细阐述了vLLM如何通过Continuous Batching技术提升吞吐量，以及量化技术在推理中的ROI。 KVCache瓶颈：KVCache的显存占用是推理成本的主要驱动因素，占比高达90%。 智能KVCache压缩：结合多种压缩技术，将KVCache的显存占用降低了60%以上。 3. 优化KVCache：使用PagedAttention和压缩技术，降低KVCache的显存占用。 动态资源调整：根据请求量的变化，动态调整GPU资源，避免资源浪费。 vLLM 0.5+ CUDA 12.0+ NVIDIA GPU（A100/H100推荐） 关键词： vLLM, 推理成本, 训练成本, Continuous Batching, 量化技术, 全栈性能调优, KVCache
23710编辑于 2026-01-19
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号