Memory 技术日报 2026-07-15：LMCache 回收 IPC KV、vLLM 拆分读写监控

先看结论

过去 24 小时，memory 方向最值得跟进的变化不在新模型论文，而在 serving 内部：KV 的释放、读写占用、页索引和 prompt 路径都被单独拿出来优化。四条改动分别来自 LMCache、vLLM、SGLang 和 NVIDIA Dynamo，发布时间均落在 2026 年 7 月 14 日 09:00 至 7 月 15 日 09:00（北京时间）窗口内。

项目	窗口内改动	对线上系统的直接含义
LMCache	实例释放时回收 CUDA IPC 导入的 KV memory，新增专门测试	多进程 KV 传输后的显存回收不再只依赖引用计数和 `empty_cache()`
vLLM	把 CPU KV offload 占用拆成读、写两个 gauge	可以区分「缓存快满」和「读写流水线正在锁块」两种压力
SGLang	在 device 上计算 KV token 到 page 的索引，再做 D2H 传输	disaggregated prefill/decode 少一次先搬回 CPU 再计算的路径
Dynamo	用压缩路径 arena 重写 KV router 的 prompt block tracker	prompt 复用索引从逐节点链表变成压缩边结构，释放和一致性检查一起重做

LMCache：KV 释放终于处理到 CUDA IPC 这一层

LMCache 的 #4015 修复了一个容易被压测遗漏的生命周期问题：通过 CUDA IPC 导入的 KV memory，在实例释放后可能仍然被映射着。提交把释放流程改成批量处理，先关闭并注销所有 entry，清空引用，再调用 torch_dev.empty_cache() 和可用的 torch_dev.ipc_collect()。其中 ipc_collect() 的位置很关键，必须等最后一个 tensor 引用消失后才有机会解除 CUDA IPC segment 的映射。1

这次改动还补了 unregister、stale-instance reaper 和 close() 的测试：未知实例不触发回收，批量 reaper 只做一次 allocator reclaim，没有 ipc_collect 的设备后端也能继续工作。对使用多进程 KV transfer 的团队，应该重点观察实例反复加入、退出后的显存曲线，而不是只看单请求吞吐。这个 commit 没有给出回收前后的量化 benchmark，收益仍需在实际设备和进程拓扑中验证。

vLLM：CPU KV offload 不再只有一个「占用率」

vLLM 的 #47666 在 CPU KV offload 中新增两个指标：vllm:kv_offload_cpu_cache_write_usage_perc 和 vllm:kv_offload_cpu_cache_read_usage_perc，原来的总占用率仍然保留。实现通过 _num_write_pending_blocks 跟踪尚未完成的 store，读占用则由总占用减去写占用得到；失败的 store 也会释放对应计数。2

这比新增一个监控字段更有用。CPU offload 的总量接近满载时，问题可能来自持续写入、批量读取，或者两者叠加；没有读写拆分，调度器和运维人员只能看到一个混合信号。现在可以把 write usage 和 store 延迟、read usage 和 load 延迟放在同一张图上，再决定是调小 in-flight store、调整 block 数，还是改变 offload 路径。提交新增了正常 store、load、读写并发和失败 store 清理测试，但没有声称吞吐提升。

SGLang：把 KV page 索引计算留在 device 上

SGLang 的 #31173 针对 disaggregated prefill/decode 的 KV transfer 路径，把 token 到 page 的索引计算从「先 .cpu().numpy()，再计算」改成直接接收 device tensor，在 device 上完成切片、stride 和整除，最后再统一转成 NumPy。C128 state payload 仍显式转为 np.int32，以满足 ZMQ 反序列化约定。3

这不是 KV 压缩算法，价值在于减少 transfer metadata 自己制造的 D2H 往返。它改动了 decode.py、prefill.py 和 mem_cache/common.py，共 53 行变更。当前提交信息没有提供端到端延迟或带宽数字，因此更稳妥的判断是：它消除了一个明确的路径级开销，实际收益取决于 page 数量、传输批次和设备同步行为。

同一时间窗内，SGLang 还修复了 KV replication fan-out 的 transfer-byte 统计，以及 disaggregated prefill grammar error 下的重复 KV release。4 5

Dynamo：prompt block tracker 改成压缩路径 arena

Dynamo 的 #11644 不是调一个阈值，而是重写了 KV router 里记录 prompt 路径的方式。新实现引入 CompressedPathArena 和压缩路径节点，用压缩边替代每个 hash 一个独立节点；prompt 路径与 output hashes 分开维护，路径发生 split 时保留 suffix 节点句柄，避免请求持有的 tail handle 失效。释放、fraction 统计和一致性校验也同步改写。6

提交规模是 block_tracker.rs 新增 446 行、删除 553 行，另增 233 行 compressed_path_arena.rs。新增校验覆盖 prompt hash 去重、terminal ownership、output ownership 和 active block 统计。这个变化直接对应高复用 prompt 的索引开销，但 commit 没有给出压缩比例或 router benchmark，不能把「压缩路径」写成已证实的吞吐提升。复现时应同时测长公共前缀、频繁分支释放和 prompt/output 混合请求，否则只测稳定单分支会看不到数据结构重写的价值。

给工程团队的三个检查点

先看回收，再看容量。 使用 CUDA IPC 或跨进程 KV transfer 时，实例 churn 后的显存是否真正回落，比静态峰值更能说明系统有没有泄漏式增长。
把读写压力拆开。 CPU KV offload 的总占用率只能回答「还有多少空间」，读写 gauge 才能回答「谁在占空间、占多久」。
把 metadata 路径纳入 profiling。 page index、prompt path 和 transfer-byte 统计都不是模型算子，却会决定缓存系统是否能在高并发下保持可解释。

这一批改动共同指向同一个工程事实：KV cache 的问题已经从「放不下」扩展到「释放是否及时、占用由谁造成、路径结构是否浪费、传输元数据是否多走一步」。