Memory 技术日报 2026-08-06：召回档位、租户 KV 与 recurrent state 的三处边界

Memory 技术日报 2026-08-06：召回档位、租户 KV 与 recurrent state 的三处边界

OpenViking、vLLM 与 oMLX 的窗口内工程更新，分别收紧召回协议、共享 KV 的租户边界和 recurrent state 的恢复正确性。

大模型 Memory 技术日报
大模型 Memory 技术日报@wei
三处状态边界正在被分别修正：OpenViking 先约束召回内容能读到哪一层、何时可以再次出现；vLLM 把共享 Mooncake KV store 的租户命名空间显式化；oMLX 则保证混合注意力模型的 recurrent state 在变长 batch 和 SSD prefix-cache 中按原结构恢复。它们都没有给出新的端到端性能数字，价值在于让下一轮压测不再把错误状态当成收益。

1. OpenViking：召回档位不能越过请求上限

变化是什么

OpenViking 的 commit 674f5e6 于北京时间 2026 年 8 月 5 日 23:52:15 提交，标题是「fix(retrieval): honor context tier ceilings and stop cooling unserved recalls」。改动集中在 context retrieval 的三个边界：内容档位、去重冷却和请求预算。1
第一处是 detail 的上限。resources 或 skills 的摘要缺失、或超过单条上限时，旧路径会读正文并返回 overview；新路径在显式请求 detail="abstract" 时退化为 bare URI，不再跨过调用方设定的深度边界。这个区别对带凭证或大段代码的资源很实际：召回系统不应因为摘要不可用，就自行扩大读取范围。1
第二处是「没有可注入内容」的结果。no_relevant 会让 rendered 为空；这类 URI 不再写入 dedup_turns ledger，也不会被 cooling。否则一次空召回会把记忆在后续若干轮中提前冷却，结果看起来像「已经见过」，实际却从未进入上下文。commit 还为 cases、patterns、tools、trajectories 和 skill-usage memories 设立显式的 memories 类别，让 tier 和 other-peer penalty 有定义，同时不把它们错误塞进已有 quota bucket。1
第三处是时间预算。ZCode、OpenCode 和 pi 原本持有 OV session id，却没有转发，导致 query expansion 和跨轮去重静默失效。新路径把 session id 传给服务端，并按请求实际启用的阶段计算 deadline：带 session 的请求为 15 秒，同时请求 digest 时为 45 秒；这两个预算覆盖串行的 query expansion、retrieval、body read、budgeting 和 digest，而不是只覆盖最后的 rewrite fuse。查询扩展和结果压缩仍然是可关闭的可选模型调用。1

先复现什么

仓库定位是面向 AI Agent 的上下文数据库，统一 Agent Memory、Knowledge RAG 和 Skills；当前仓库元数据报告 AGPL-3.0 许可证和约 27,973 个 stars。仓库主页和 main 分支是复现入口，commit 本身同时给出了英文和中文集成文档的变更。2
git clone https://github.com/volcengine/OpenViking.git
cd OpenViking
git checkout 674f5e6039bab1d35b822d2c3dc29fcecf9bab5b
git show --stat --oneline HEAD
先构造四组断言：detail="abstract" 不读取 vectors-only resource 的 body；no_relevant 的 URI 下一轮仍可出现；带 session 的 harness 确实触发 query expansion 和跨轮去重；带 digest 的串行请求使用覆盖两个 fuse 的预算。它们验证的是读取协议，不是召回质量。

不能从中推出什么

commit 没有给出召回率、答案质量、TTFT 或吞吐对比。15 秒和 45 秒是请求预算，不是服务端在所有硬件和模型下都能达到的延迟承诺；query expansion 被启用，也不等于检索结果一定更好。

2. vLLM：共享 Mooncake KV store 需要显式租户名

变化是什么

vLLM 的 commit d36f24b 于北京时间 2026 年 8 月 6 日 08:31:18 提交，标题为「[KV Connector][Mooncake] Add tenant ID support to MooncakeStoreConnector (#48069)」。它为 MooncakeStoreConfig 增加 tenant_id，默认值是 default；配置读取时会把 None、空白字符串和带首尾空格的字符串规范化，非字符串则抛出 TypeError。非默认值会在 store.setup() 中作为 tenant namespace 透传。3
这个字段改变的是共享 KV store 的命名边界。producer 和 consumer 需要使用相同 tenant id 才能共享数据；不同 vLLM 部署可以用不同 tenant namespace，避免把所有部署默认放进同一个可见范围。单元测试覆盖了默认值、规范化、类型错误，以及默认 tenant 不传参、非默认 tenant 传参的两条初始化路径。3

先复现什么

vLLM 官方仓库定位是高吞吐、内存高效的 LLM 推理与 serving 引擎，当前仓库元数据报告 Apache-2.0 许可证和约 88,283 个 stars。4
git clone https://github.com/vllm-project/vllm.git
cd vllm
git checkout d36f24b66a9ce71cf15f1cb9249f5d4092f32d11
pytest -q tests/v1/kv_connector/unit/test_mooncake_store_worker.py
测试通过后再启动 Mooncake 多租户环境，分别用 tenant-a 和 tenant-b 建立 producer/consumer。需要同时核对三件事：Mooncake master 是否以 --enable_multi_tenants=true 启动，tenant quota policy 是否注册，底层 MooncakeDistributedStore.setup() 是否支持 tenant_id。standalone-store 模式还要让外部 mooncake_client 使用同一个 tenant id。3

不能从中推出什么

vLLM 端新增字段不等于完成访问控制，也不单独构成严格隔离证明。多租户 master、quota policy、底层 Mooncake 版本和 standalone client 有一处没有同步，命名空间就可能无法按预期工作。commit 没有给出 KV 命中率、TTFT、吞吐或显存节省数字。

3. oMLX：recurrent state 要和 KV cache 一起恢复

变化是什么

oMLX 的 commit c624463 于北京时间 2026 年 8 月 5 日 17:22:28 提交，完成 Ling 3.0 Flash / bailing_hybrid 支持。模型同时包含 global attention 和 linear attention：global 层使用 KVCache，linear 层使用四槽 ArraysCache，分别保存 recurrent_state、conv_q、conv_k 和 conv_v。5
这次改动真正与 memory 相关的地方有三处。变长 batch 会根据当前 chunk lengths 构造 mask，避免右 padding 把 recurrent state 向前推进；cache type handler 会逐个恢复 variable-length state；prefix-cache 重建也改用 reconstruct_cache 保留四个 state slot。scheduler 额外检查实际 cache 槽位是否匹配模型期望，旧的 zero-slot cache 会被拒绝。测试覆盖了变长 batch 与单请求 greedy token 一致、旧一槽 cache 升级，以及 SSD prefix-cache 恢复四槽 state。5
同一窗口内，d4adcc3 又在北京时间 8 月 6 日 08:57:39 补齐了 Ling 3.0 Flash 的混合 FP8/MXFP4 checkpoint 加载：routed experts 使用 MLX 原生 MXFP4，其他投影继续走 FP8，并增加严格加载测试。它处理的是权重布局和量化映射，不是 KV cache 容量或上下文上限；两类变化不要合并成一个收益数字。6

先复现什么

oMLX 官方定位是面向 Apple Silicon 的连续 batching 与 SSD caching LLM inference server，当前仓库元数据报告 Apache-2.0 许可证和约 18,477 个 stars。7
git clone https://github.com/jundot/omlx.git
cd omlx
git checkout c62446352814b8b4ca8bd4d435b97f32bbddfb2d
pytest -q \\
  tests/test_bailing_hybrid_patch.py \\
  tests/test_cache_type_handlers.py \\
  tests/test_prefix_cache.py
先比较变长 batch 和单请求的 token 序列，再检查 prefix-cache 从 SSD 恢复后四个 state slot 是否都存在。通过后才适合测 SSD 命中率、端到端延迟和连续 batching；如果第一步失败，后面的性能数字没有解释价值。

不能从中推出什么

源码和测试没有提供该 commit 的 TTFT、吞吐、显存或 SSD 命中率对比。d4adcc3 的 FP8/MXFP4 支持也不能写成 KV 容量提升；它改变的是 checkpoint 权重的加载方式。

把三条更新放在同一条复现链上

更新被收紧的状态第一组断言不能外推
OpenViking retrieval 1请求的 detail ceiling、空召回的 ledger、session deadline不越级读 body；未注入的 URI 不被冷却；预算覆盖实际串行阶段没有召回率或延迟收益
vLLM Mooncake tenant 3共享 KV store 的 namespace 和隔离前提tenant 规范化；producer/consumer 同名可共享；异名不混用没有访问控制或性能证明
oMLX recurrent/prefix state 5变长 state 的槽位、mask 和恢复结构batch token 与单请求一致；四槽 state 可从 prefix cache 恢复没有 KV 容量或 serving 性能数字
三条更新的连接只到状态协议这一层。先看 OpenViking 的读取边界，确认「请求了什么」和「实际注入了什么」没有错位；再看 vLLM 的共享命名空间，确认「谁能看到这份 KV」不是默认全局事实；最后看 oMLX 的恢复结构，确认「读回来的 state」仍然具有正确槽位和长度。这个顺序能减少压测中的误判，但不支持把三项改动合成一个统一 benchmark 结论。对线上系统最直接的动作，是先把这些断言写进回归测试，再测 TTFT、吞吐、命中率和成本。

참고 출처

  1. 1
    OpenViking commit metadata and diffapi.github.com
  2. 2
    OpenViking repository metadata and entry pointsapi.github.com
  3. 3
    vLLM Mooncake tenant commitapi.github.com
  4. 4
    vLLM repository metadataapi.github.com
  5. 5
    oMLX Ling 3.0 Flash support commitapi.github.com
  6. 6
    oMLX mixed FP8/MXFP4 checkpoint commitapi.github.com
  7. 7
    oMLX repository metadata and entry pointsapi.github.com

관련 콘텐츠

  • 로그인하면 댓글을 작성할 수 있습니다.