LMCache：开源方案解决LLM大规模KV缓存管理难题
How do LLMs handle GBs of KV cache in production?
做LLM推理部署的同学必看，LMCache给出了KV Cache跨节点复用和持久化的完整工程解法，实测吞吐提升显著，直接落地参考其架构。
How do LLMs handle GBs of KV cache in production?
大语言模型在生产环境中如何处理 GB 级别的 KV Cache？
(a popular technical LLM interview question)
（一个流行的技术类 LLM 面试问题）
At scale, KV cache becomes a storage system.
在大规模场景下，KV Cache 演变为一种存储系统。
Every attention layer creates KV tensors while processing a prompt.
每个注意力层在处理提示词时都会创建 KV 张量。
During generation, the model reads this state instead of processing the entire sequence again for every new token.
在生成阶段，模型读取该状态，而不是为每个新 token 重新处理整个序列。
For a single request, this is temporary GPU data.
对于单个请求而言，这仅是临时的 GPU 数据。
But when multiple requests and inference workers reuse the same prompt prefix, the cached data must remain available after the original request finishes.
但当多个请求和推理工作节点复用相同的提示词前缀时，缓存数据必须在原始请求结束后依然可用。
It may even need to survive after the engine that created it restarts.
它甚至需要在创建它的引擎重启后继续存在。
So a cache hit now requires more than identifying matching tokens.
因此，现在的缓存命中不仅仅需要识别匹配的 token。
The system must find the relevant blocks, bring them back into GPU memory, remove old blocks when storage fills, and let multiple workers reuse the same data.
系统必须找到相关的块，将其重新加载到 GPU 内存中，在存储空间满时移除旧的块，并允许多个工作节点复用相同的数据。
Consider a request that shares 80% of its prompt with an earlier request.
考虑一个请求，其提示词有 80% 与之前的请求共享。
The matching tensors may already be in GPU memory. Otherwise, the system could retrieve them from CPU memory, a local SSD, or remote storage.
匹配的张量可能已经位于 GPU 内存中。否则，系统可以从 CPU 内存、本地 SSD 或远程存储中检索它们。
The model then processes only the uncached 20%. It stores the newly created tensors so later requests can reuse them.
随后模型仅处理未缓存的 20%。它将新创建的张量进行存储，以便后续请求可以复用。
This involves moving large amounts of data between memory and storage while the GPU is also generating tokens.
这涉及在 GPU 同时生成 token 的过程中，在内存和存储之间移动大量数据。
Inference engines such as vLLM are mainly designed to schedule requests and run the model. Cache management requires a different set of operations around storage, movement, and cleanup.
vLLM 等推理引擎主要设计用于调度请求和运行模型。缓存管理则需要围绕存储、移动和清理的一套不同操作。
The solution is actually open-source and implemented in the LMCache package.
该解决方案实际上是开源的，并在 LMCache 包中实现。
It runs KV cache management as a standalone service beside the inference engine.
它将 KV Cache 管理作为独立服务运行，与推理引擎并列。
The engine requests the required blocks, while LMCache finds them, moves them into the right memory, and stores new blocks afterward.
引擎请求所需的块，而 LMCache 负责查找它们，将它们移动到正确的内存中，并在之后存储新的块。
LMCache uses CUDA IPC, a mechanism that lets separate processes access the same GPU memory. This avoids copying the full cached tensors through ordinary messages between the two processes.
LMCache 使用 CUDA IPC，这是一种允许不同进程访问同一块 GPU 内存的机制。这避免了在两个进程之间通过普通消息复制完整的缓存张量。
Cached blocks can also move between GPU memory, CPU memory, local storage, and remote storage. On a hit, the inference engine restores the reusable blocks and processes only the missing tokens.
缓存的块也可以在 GPU 内存、CPU 内存、本地存储和远程存储之间移动。发生命中时，推理引擎恢复可复用的块，并仅处理缺失的 token。
Multiple vLLM instances on the same machine can share one LMCache service. Cache storage can scale separately, and restarting an inference worker does not automatically remove the saved cache.
同一台机器上的多个 vLLM 实例可以共享一个 LMCache 服务。缓存存储可以独立扩展，重启推理工作节点不会自动删除已保存的缓存。
The LMCache paper reports up to 15x higher throughput when combining it with vLLM across the evaluated workloads.
LMCache 论文报告称，在评估的工作负载中，将其与 vLLM 结合使用时吞吐量最高可提高 15 倍。
The visual below traces one prompt through the inference engine, cache service, shared GPU memory, and storage levels.
下图展示了单个提示词在推理引擎、缓存服务、共享 GPU 内存和存储层级中的流转过程。
LMCache GitHub: https://github.com/LMCache/LMCache
LMCache GitHub: https://github.com/LMCache/LMCache
(don’t forget to star it ⭐)
（别忘了给它点个星 ⭐）
If you want to dive deeper, I recently wrote a detailed breakdown of KV, prefix, prompt, and semantic caching, including where LMCache fits into the serving stack.
如果你想深入了解，我最近写了一篇关于 KV 缓存、前缀缓存、提示词缓存和语义缓存的详细解析，其中包括 LMCache 在服务架构中的定位。
Read it below.
点击下方阅读。
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力