Memory 技术日报 2026-06-24：LMCache P2P、Mem0 Pi 与 NVFP4 KV

过去 24 小时的 memory 增量更像一次工程栈下沉：长期记忆被打包成 coding agent 插件，KV cache 开始在多进程实例之间互拉，低精度 KV 的适配则推进到消费级 / SoC Blackwell 的开源 PR 栈里。本期按 2026-06-23 09:00 至 2026-06-24 09:00（北京时间）筛选；几篇相关 arXiv 论文提交时间落在窗口前，未纳入主表。

速览表

条目	时间依据	技术增量	今天该怎么跟进
Mem0 Plugin for Pi Code	Mem0 官方博客标注 2026-06-24 发布。1	给 Pi Code 增加跨 session、跨项目、跨设备的 persistent semantic memory；插件包含自动记忆捕获、语义搜索、project/session/global 三种 scope、dream consolidation、8 个 slash commands，以及可由 agent 调用的 `mem0_memory` tool。1	如果团队已经在用 coding agent，可先拿它做「记忆写入策略」试点：哪些技术决策要自动记、哪些偏好要人工确认、哪些旧记忆要定期合并或删除。
LMCache v0.5.0	LMCache 官号在 6 月 24 日 06:56（北京时间）发帖宣布 v0.5.0；GitHub release 页显示 v0.5.0 已发布。2 3	MP mode 下加入 P2P KV cache lookup / transfer；同时引入 asymmetric serde（例如 FP16 key + FP8 value）、Device-DAX 作为 hybrid L1 overflow、SGLang XPU connector、Aerospike L2 backend 与 MUSA 支持。2	有多实例 serving 或 prefix cache 复用压力的团队，应优先看 P2P adapter、transfer channel 和 coordinator 相关改动；这比单机 cache 参数微调更接近生产拓扑问题。
vLLM / FlashInfer NVFP4 KV stack	vLLM PR #46329 页面显示 6 月 23 日继续追加 commits；同日 16:07（北京时间）的社区解读给出了 PR 状态和部署口径。4 5	该 PR 将 Gemma 3/4 在 SM120/SM121 上的 NVFP4 KV cache 路由到 FlashInfer FA2，并为 Gemma 4 的 512-wide global heads 做 VO-split；FlashInfer 侧 PR #3684 补上 FA2 paged attention 的 NVFP4 KV read path 与 SM121 dispatch。4 6	这仍是 open PR 栈，不应对业务方承诺「vLLM 已正式支持」。适合 Spark / RTX PRO / consumer Blackwell 方向先建 watchlist，等校准 checkpoint 和依赖 PR 稳定后再压测。

逐条解读

1. Mem0 把 coding agent memory 做成 Pi Code 插件

Mem0 这次不是再讲「agent 需要记忆」的抽象理由，而是把记忆层直接打包进 Pi Code：自动从用户和助手消息里捕获可复用上下文，用语义搜索取回，并按 project、session、global 三个 scope 隔离记忆。对工程团队来说，scope 是这条消息里最关键的设计点：项目约定、迁移决策、技术偏好和踩坑记录不应该混成一个全局 transcript。1

另一个值得看的是 dream consolidation。插件说明里，它会合并重复记忆、处理矛盾、剪掉 stale entries，并允许 pin 重要记忆防止被清理。这个方向说明 coding agent memory 的竞争点正在从「能存」转向「能维护」：写入、合并、遗忘和可审计，比单纯扩 context 更影响长期质量。1

工程判断：可先把它当成「小范围 agent memory governance 试验」。不要一上来全自动记录所有对话；更值得测的是哪些记忆需要用户确认、哪些记忆应该随 repo 走、哪些记忆在 monorepo 里会跨服务误召回。

2. LMCache v0.5.0 开始处理多实例 KV 复用

LMCache v0.5.0 的主线不是一个单点 kernel 优化，而是把 KV cache 从「本实例命中」推进到「多进程实例之间能互相查询和拉取」。release notes 里，P2P KV transfer 覆盖 P2P adapter、MP mode transfer channel、P2P lookup / lock RPC、MP coordinator 注入 P2P info，以及 L2 adapter 的运行时注册 / 注销。2

콘텐츠 카드를 불러오는 중…

这对线上 serving 的意义很直接：如果请求被路由到不同 worker，prefix cache 的收益通常会被调度打散。P2P lookup / transfer 的方向，是让 cache 复用不再完全依赖「请求恰好落在同一个进程」。同时，asymmetric serde 允许同一个 KV cache 里混合精度，例如 FP16 keys 和 FP8 values；Device-DAX overflow 则把 hybrid L1 的溢出路径扩到更接近系统存储层。2

工程判断：如果你现在的瓶颈是「cache 命中率随负载均衡波动」，这条比继续调 batch size 更值得排期。真正要验证的是 P2P 拉取延迟、跨进程锁和 coordinator 对 tail latency 的影响，而不是只看单请求命中收益。

3. NVFP4 KV cache 正在进入 Blackwell 边缘形态

vLLM PR #46329 的重点是把 Gemma 3/4 的 NVFP4 KV cache 接到 consumer / SoC Blackwell（SM120 / SM121）上的 FlashInfer FA2 path。PR 页面显示，6 月 23 日追加的一组 commits 包括 NVFP4 KV cache on consumer Blackwell、Gemma 4 VO-split prefill、compressed-tensors 接受 NVFP4 KV scheme，以及 Gemma 3/4 multimodal prefix span masking。4

github.com · GitHub PR #46329

vllm-project/vllm#46329

https://github.com/vllm-project/vllm/pull/46329

콘텐츠 카드를 불러오는 중…

FlashInfer 侧 PR #3684 是这个栈的 kernel 依赖：它实现 FA2 paged attention 的 NVFP4 KV-cache read path，补了 SM120 / SM121 dispatch，并处理 QK=512、VO=256 的非对称 head 形态。社区解读还提醒，这组 PR 仍处于 open / 非正式支持阶段；如果要试，只能按分支构建、使用已校准 checkpoint，并显式配置 --kv-cache-dtype nvfp4。6 5

工程判断：这条适合进入「硬件可用性 watchlist」，不是立刻进生产。值得提前做的是准备一组固定 prompt 长度、图文混合输入和长输出压测脚本；等 PR 合并后，直接对比 BF16 / FP8 / NVFP4 KV 在容量、正确性和尾延迟上的差异。

工程判断

今天三条线索合起来，给 memory 系统一个清晰方向：长期记忆在上层做治理，KV 记忆在下层做跨实例和低精度复用。Mem0 关心「该记住什么、怎么清理」；LMCache 关心「命中结果能不能跨 worker 复用」；vLLM / FlashInfer 关心「同一硬件里能不能装下更多 KV」。

对读者的跟进优先级可以这样排：

做 coding agent 的团队：先看 Mem0 插件的 scope 和 consolidation 设计，补一份内部「记忆写入 / 遗忘策略」。1
做 LLM serving 的团队：把 LMCache v0.5.0 的 P2P transfer 放进 staging 压测，重点看跨实例命中是否抵消传输成本。2
押注本地 / 边缘 Blackwell 的团队：关注 vLLM PR #46329 与 FlashInfer PR #3684 的合并状态；合并前只做实验分支验证，不要写进生产 SLA。4 6

今天没有把窗口前的 arXiv 论文硬塞进主表。原因很简单：这类日报的价值不是凑满论文数，而是让读者知道今天真正能跟进、能复现或需要放进 watchlist 的 memory 进展在哪里。

速览表

逐条解读

1. Mem0 把 coding agent memory 做成 Pi Code 插件

2. LMCache v0.5.0 开始处理多实例 KV 复用

3. NVFP4 KV cache 正在进入 Blackwell 边缘形态

工程判断

참고 출처