@akshay_pachaar：每个推理引擎都犯了同样的错误。像 vLLM 或 SGLang 这样的推理引擎，是位于你的请求与模型权重之间的软件……

每个推理引擎都犯了同样的错误。 像 vLLM 或 SGLang 这样的推理引擎，是位于你的请求与模型权重之间的软件。它的工作是将模型加载到 GPU 上，将你的提示词输入模型，然后尽可能快地流式返回 token，只要硬件允许。 它擅长的一切，归根结底就是让 GPU 忙于做数学计算。 随着上下文窗口的增长，引擎也开始承担缓存管理任务，这部分也融入了同一个流程。KV 缓存是模型对已读取 token 的已保存理解，而存储它、加载它、以及在 GPU 和 CPU 之间来回传输，都与注意力计算争夺相同的资源。 于是两者轮流占用资源。 Google 的 TurboQuant 展示了这种限制有多严格。它将 KV 缓存压缩到每个值 3 比特，且精度无损，这样缓存块占用更少的 GPU 内存，并更快地传送到 CPU 内存或磁盘。 但压缩并非免费。在传出时需要压缩每个块，在返回时需要解压缩，而这些工作运行在同一个正在生成 token 的 GPU 上。 开启 TurboQuant 后，推理吞吐量相比关闭时下降 20% 以上。问题不在于压缩本身，而在于它运行的流程。 LMCache 是一个开源解决方案，它将缓存管理移入一个与引擎并行的独立进程中。这种拆分带来了三个好处。 → 交接非常轻量。引擎只需要发送它需要的块 ID，这些是几个标识符而不是数 GB 的数据，而所有缓存的向量实际移动发生在另一端，同时引擎继续计算注意力。 → 两个进程直接共享 GPU 内存。在两个 GPU 之间传递缓存状态通常需要多次复制数据，而在这里它们读写同一区域，因此一个缓存文档不再在每个 worker 上重复存储。 → 查找可并行进行。缓存块存在于四个位置：首先是 GPU 内存，然后是 CPU 内存，接着是本地 SSD，最后是云存储。逐一检查意味着最慢的那个决定了你的基准，因此 LMCache 同时查询所有四个位置，并从最先响应的位置流式读取。 这才是真正的转变。缓存工作是 I/O 密集型的，而推理是计算密集型的，将它们放在同一个进程中意味着你对缓存的任何改进都会牺牲推理时间。 在 H200 上使用 Qwen3-235B 模型和 50 个并发用户时，将它们分离实现了 14 倍的首 token 延迟降低和 4 倍的解码加速。启动时间从超过三分钟降至大约 30 秒。 @lmcache 可以直接插入 vLLM、SGLang 和 TensorRT-LLM，支持 NVIDIA 和 AMD，并且任一侧崩溃都能存活，引擎会回退到无缓存推理，直到缓存进程重新连接。 在 GitHub 上查看：https://github.com/LMCache/LMCache （别忘了点星标 🌟） 下图追踪了一个提示词经过整个路径的过程。我写了 LMCache 工作原理的完整解析，文章引用如下。