GitHub user Ray7788 edited a comment on the discussion: LLM 推理 KV Cache 分布式缓存方案
前期调研 # KV Cache 背景介绍 目标是KV Cache缓存层可以作为独立的代理层运行，也可以作为嵌入到同一推理栈中的库运行。 (GPU → CPU → Disk) 在推理过程中，每个新生成的token都依赖于之前生成的所有token。 模型会为每一层保存注意力键和值，以避免每次都重新计算整个上下文。这些键和值统称为 KV 缓存。 如果没有缓存，每次请求都会重新计算之前所有token的嵌入向量——这对于较长的上下文和重复的提示来说很快就会成为瓶颈。 大多数推理引擎（例如 vLLM、Text Generation Inference或 Hugging Face Transformer）已经在单个会话中使用了缓存。 然而，这些缓存会在请求完成后被丢弃——这意味着后续查询中相同的前缀会触发完整的重新计算。 ## LM Cache LMCache充当客户端和 LLM 引擎之间的加速层。LMCache不会让每个请求都从头开始，而是识别重复的前缀，检索先前计算的 KV 缓存，并将它们直接提供给模型。与 vLLM 不同，LMCache 可以将 KV 缓存存储在单个请求的生命周期之外——跨会话、用户甚至服务器。 它在模型执行之前增加了一个缓存查找阶段，在推理之后增加了一个缓存存储阶段，有效地包围了 LLM 引擎。 层级位置延迟使用场景GPU 内存最快 < 1 毫秒 活跃会话和热门前缀CPU 内存中等 ~10 毫秒 热缓存， 不常用上下文磁盘/固态硬盘最慢 ~100 毫秒 用于不常用或大型上下文的长期存储 缓存会根据访问时间和访问频率在各层之间动态迁移——这是一种类似于现代内存层次结构的热/温/冷数据策略。 键值缓存可以高效地从推理引擎中提取并加载回推理引擎，存储在分层存储设备（CPU内存、本地磁盘、远程磁盘和Redis）中，并通过不同的网络（以太网、RDMA、NVLink）传输。 当 GPU 或 CPU 内存已满时，LMCache 会使用LRU（最近最少使用）和TTL（生存时间）策略来清除过期的缓存条目。 它还会维护轻量级元数据（例如哈希值、偏移量和张量形状），以确保即使在重启后缓存的一致性。 GitHub link: https://github.com/apache/dubbo-go-pixiu/discussions/860#discussioncomment-15581293 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
