Memory 技术日报 2026-07-23：LMCache、oMLX 与 TensorRT-LLM 的缓存工程更新

先看结论

北京时间 7 月 22 日 09:00 至 7 月 23 日 09:00，最值得工程团队跟进的四条信号都落在 memory 的运行时一侧：KV cache 如何跨层存储和传输，prefix cache 如何在长时间运行中保持正确，硬件特化的缓存能力如何落地，以及一个真实部署里近乎 0 命中的配置陷阱。

进展	窗口内时间	主要变化	建议动作
LMCache v0.5.2	7 月 22 日 09:39	CacheBlend 接入 vLLM HMA，补上全局 P2P token matching，并扩展 L2 存储后端	正在使用 LMCache 或 vLLM HMA，先在现有 workload 上升级验证
oMLX v0.5.3	7 月 22 日 16:18	修复 prefix-cache 重建、长上下文 prefill、长期运行泄漏和驻留 KV 张量累积	Apple Silicon 长时间运行服务，优先做多轮对话和 SSD cache 回归
vLLM-Ascend #12589	7 月 22 日 15:19	DeepSeek-V4、128K 输入、约 50% 前缀复用时，`block-size=128` 被报告为近乎 0 命中	先复现并对比 `--block-size 32`，不要把开放 issue 当成默认修复
TensorRT-LLM v1.3.0rc22	7 月 23 日 06:41	增加 FP4 KV cache 与非 FP4 Mamba state 组合、SM121 MLA cache reuse，并修复 DeepSeek-V4 KV-cache warmup	Blackwell、DeepSeek-V4 或 disaggregated serving 集群，先做候选版本压测

四条进展

1. LMCache v0.5.2：KV cache 开始更像一层可编排的存储

LMCache v0.5.2 于北京时间 7 月 22 日 09:39 发布。1 这次更新的重点不是单个 kernel，而是把 KV cache 的跨组件使用补得更完整：CacheBlend 兼容 vLLM 的 hybrid KV-cache manager，协调器可以在 L1 中做全局 P2P token matching，同时加入 Azure Blob Storage、Valkey、Cloud Bigtable 和 SageMaker HyperPod 等 L2 适配器，还提供 vLLM packed KV cache 的重排与 kernel 支持。2

这意味着部署时可以把「缓存命中」和「缓存放在哪里」拆开处理：GPU 侧负责热数据，L1/L2 负责更大范围的复用，CacheBlend 负责把检索片段组合回请求。对于已经在 vLLM HMA、CacheBlend 或多节点 KV 传输上投入的团队，这个版本值得先读 release notes，再用自己的命中率、传输耗时和重算 token 数做 A/B。发布说明没有给出独立的吞吐或成本基准，不能直接把新增后端等同于线上收益。

2. oMLX 0.5.3：把 cache 的「坏命中」和长期运行问题收回来

oMLX 0.5.3 于北京时间 7 月 22 日 16:18 发布。3 这是一个 hotfix，但和 memory 直接相关的修复不少：混合 TurboQuant 与 dense cache 的 prefix-cache 重建现在按实际 payload 格式恢复，遇到含糊或损坏的命中会回到 prefill；长上下文下的 FA-256 prefill slowdown 和 GPU preemption failure 被修复；prefix index 会随 cache block 一起清理，并在复用前逐块校验；多轮 SSD cache 流量里驻留 KV tensor 持续累积的问题，也通过移除序列化状态的闭包引用环处理。4

这类修复不一定出现在 benchmark headline 里，却会直接决定服务能不能跑过一整夜。它只适用于 oMLX 的 Apple Silicon 路径，适合 Mac 上的本地推理、开发机服务和长时间 agent 会话。升级后应重点检查取消请求、部分 cache hit、模型切换、长上下文 prefill，以及连续多轮对话后的常驻内存。

3. TensorRT-LLM v1.3.0rc22：硬件特化缓存能力继续前移

TensorRT-LLM v1.3.0rc22 于北京时间 7 月 23 日 06:41 发布，是候选版本，不是稳定版。5 Release notes 列出三类和 memory/context 直接相关的变化：支持 FP4 KV cache 与非 FP4 Mamba state 混用，加入 SM121 MLA cache reuse，修复 DeepSeek-V4 KV-cache warmup，并调整 disaggregated KV transfer 的 layer offset 计算，使其按 physical slot order 推导。6

这条线适合使用 Blackwell、DeepSeek-V4 或 disaggregated serving 的团队关注，因为它把 KV cache 的格式、硬件布局和传输位置绑在了一起。风险也写在同一份说明里：Kimi K2.5 在 GB300 上可能出现 disaggregated KV cache transfer 失败，另有多 GPU accuracy 与 OOM 的已知问题。结论很直接：可以拿来做候选版本压测，暂时不应当按稳定版本推全量。

4. vLLM-Ascend #12589：长前缀复用可能被 block 粒度悄悄吃掉

vLLM-Ascend 的 #12589 于北京时间 7 月 22 日 15:19 创建，目前仍是 open。标题和正文都指向 prefix caching 与 long context，GitHub API 返回的标签包括 bug、documentation、triaged、llm-model 和 deepseek-v4。7 Issue 作者给出的复现条件是 DeepSeek-V4、Ascend NPU、128K prompt，第二个请求与第一个请求约有 50% 前缀重复，使用默认 --block-size 128 时，第二个请求的 prefix-cache 命中率接近 0%。报告中的观测是 128K prompt 被切成 1024 个 block，第二次请求 0 个 block 命中，整段前缀重新计算。

作者把原因归到 chunked prefill 的尾部不完整 block、hash 粒度和请求间 block 边界碎片化，并建议对比 --block-size 32 或做动态 block-size 选择。这些仍是 issue 中的分析，不是已经合并的修复。窗口结束时只有一条协作者评论，内容是请其他维护者查看，没有 PR、负责人或关闭记录。8

对 RAG、多轮对话和 agent workload 来说，这个问题的排查优先级不低。复现时要固定模型、硬件、prompt 长度和共享比例，同时记录 prefill time、命中的 block 数、KV cache 使用量，再比较 128 与 32 的差异。只看到「KV cache 使用量很高」不能证明复用生效，命中率和实际重算 token 才是关键。

怎么排优先级

已经在 vLLM HMA、CacheBlend 或跨节点 KV cache 上运行：先看 LMCache v0.5.2，确认后端、packed KV 格式和 P2P matching 是否能接入现有链路。
使用 Blackwell、SM121 或 DeepSeek-V4 serving：把 TensorRT-LLM rc22 放进隔离环境压测，重点验证 KV transfer、warmup、OOM 和准确性。
在 Apple Silicon 上跑本地模型或长期 agent 会话：oMLX 0.5.3 的 cache 重建、prefix index 和常驻内存修复更有直接收益。
在 Ascend NPU 上遇到长上下文 prefix reuse 失效：先复现 #12589 的 block-size 对照，当前没有足够证据把 32 写成通用默认值。