Memory 技术日报 2026-07-14：KVeXpress、Oracle LangGraph 与 Rapid-MLX

今天的三条信号都指向同一个问题：memory 不再只是「存在哪里」，而是「什么时候分配、谁来搬、怎样证明复用不会错」。KVeXpress 把 KV cache 迁移从 prefill 侧推送改成 decode 侧拉取；Oracle 把 LangChain / LangGraph 的 retrieval、chat history、semantic cache、checkpoint 收敛到一个数据库后端；Rapid-MLX 则把 Gemma 4 的 cross-layer KV sharing 变成可测试的加载期契约。

DriveNets 这篇文章的关键点不是「换一个更快网络」，而是把 disaggregated LLM inference 里的控制权重新分配。传统 push-based 迁移要求 decode node 在 prefill 完成前先预留显存，prefill node 还要参与实际数据搬运；KVeXpress 改成 decode-side pull，让 decode node 在真正要接收时再分配和拉取，prefill node 更早释放去处理下一个 prompt。1

文章给了一个很具体的量级：在 8-GPU tensor-parallel decode group 里，一个 32K-token request 跑 671B model，KV cache 可能约 50GB，而且不是一整块连续内存，而是大量 paged KV memory mappings。1 这解释了为什么「搬 KV」会同时牵涉页映射、显存预留、RDMA transaction 粒度和调度时序。

KVeXpress 的三个动作分别对应三个工程痛点。JIT Decode Allocation 延后 decode 显存分配，减少空等；Vectorized KV Transfer 把物理相邻的页打包成更大的传输块，减少小事务；Decode-Driven Movement 把传输编排从 prefill 侧移到 decode 侧。1

需要克制看 benchmark。DriveNets 的 sweep 是 3-node AMD MI355X cluster、2P1D topology、64K input tokens + 1K output tokens 的长上下文 workload；文中汇总称相对 Mooncake baseline，SGLang 场景 TTFT 平均降低 13.4%，TPOT / ITL 分别变慢约 8.5% / 8.6%，E2E latency 降低 5.6%，cluster throughput 提升 8%。1 这不是「所有 serving 都更快」的结论，更像是一个提醒：当 prefill 很重、decode 显存提前占用明显时，handoff 时序可能比单纯链路带宽更重要。

Oracle 这篇是官方工程路线说明，立场很明确：把 vectors、chat history、semantic cache、checkpoints、documents、relational data 放到同一个 Oracle AI Database connection pool 后面，减少多系统带来的一致性、备份、治理、延迟和审计碎片。3

具体到 LangChain，langchain-oracledb 新增两类 memory primitive：OracleSemanticCache 用向量距离匹配近义 prompt，作为 LLM response cache；OracleChatMessageHistory 把会话历史持久化到 Oracle 表，并支持按 session 隔离和 bounded read。3 这不是单纯多了一个向量库 adapter，而是把「短期会话记忆」和「语义缓存」纳入同一个生产后端。

LangGraph 侧的新包 langgraph-oracledb 提供 OracleSaver / AsyncOracleSaver 做 graph checkpointing，并提供 OracleStore / AsyncOracleStore 做 long-term agent memory；后者支持 namespaced key-value store、put/get/search、batch operations，以及可选 HNSW 或 IVF vector indexes。3

这条的工程判断是：它适合需要合规、审计、备份一致性的企业 agent，而不是追求最轻量 prototype 的团队。Oracle 博客还写明，OracleSemanticCache 和 OracleChatMessageHistory 属于 Python-first memory primitives；hybrid keyword-and-vector search through DBMS_HYBRID_VECTOR.SEARCH 需要 Oracle AI Database 26ai。3 也就是说，路线清晰，但版本、数据库选型和团队运维栈会决定落地成本。

Rapid-MLX 的窗口内提交最值得看的不是最新的 CLI update check，而是几分钟前合入的 #1104：它给 Gemma 4 cross-layer KV-sharing 增加加载期 guard 和测试。提交说明称，Gemma 4 的部分 decoder layers 会「borrow」上一层 same-type producer 的 K/V，而不是自己计算一份；make_cache() 返回 producer-only cache list，forward path 把 producer K/V 喂给 borrower。4

这个改动的价值在「防静默退化」。提交里写到，load-time guard 会区分 active sharing、inactive sharing 和 malformed config；当 num_kv_shared_layers 非法或 borrower 找不到同类型 producer 时，走明确错误，而不是让模型悄悄变成另一种缓存形态。4 对本地推理来说，这类 guard 很实际：KV sharing 一旦失效，用户看到的可能不是立刻崩溃，而是显存占用、吞吐或结果路径慢慢偏离预期。

提交还给出一个诚实的边界。对 mlx-community/gemma-4-e2b-it-4bit 的测量里，borrow active 时 35 层里有 15 个 producer caches、20 个 borrower；KV memory footprint 在 1024 tokens 下从 44.04 MB 降到 18.87 MB，约 2.33x smaller，且 1k / 4k / 8k token ratio 大体恒定。但同 checkpoint 下 prefill / TTFT wall-time 约 1.00x，没有可测速度提升。4

这比「KV-share 让推理变快」更有用。它说明 Apple Silicon 本地推理的一个真实约束：cross-layer KV sharing 首先是内存预算工具，尤其对小量化模型；如果 k/v projection 本来只占 prefill 的很小比例，TTFT 不一定会明显下降。工程上该跟进的是 guard、测试和显存曲线，而不是只看首 token 延迟。

第一，KV cache 的工程问题正在从「缓存有没有」进入「缓存生命周期怎么编排」。KVeXpress 关注跨节点 handoff，Rapid-MLX 关注层间 KV sharing 的配置正确性，二者都在处理 memory reuse 的生命周期边界。

第二，agent memory 的生产化路线开始分岔。Oracle 的路线是统一数据库后端，适合治理要求高的企业栈；Rapid-MLX 这样的本地推理路线则把正确性 guard、显存曲线和模型结构契约放在更前面。两边都不是单一「向量库」能概括的 memory 问题。

第三，今天这三条都带着代价说明：KVeXpress 的 TPOT / ITL 变慢，Oracle 的数据库版本和生态绑定明显，Rapid-MLX 的 KV-share 主要省内存而非提速。对线上系统来说，这种负面边界反而比亮眼数字更值得看。