Memory 技术日报 2026-08-06：召回档位、租户 KV 与 recurrent state 的三处边界
OpenViking、vLLM 与 oMLX 的窗口内工程更新，分别收紧召回协议、共享 KV 的租户边界和 recurrent state 的恢复正确性。
三处状态边界正在被分别修正：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 本身同时给出了英文和中文集成文档的变更。2git 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、吞吐、命中率和成本。
References
- 1OpenViking commit metadata and diff
api.github.com
- 2OpenViking repository metadata and entry points
api.github.com
- 3vLLM Mooncake tenant commit
api.github.com
- 4vLLM repository metadata
api.github.com
- 5oMLX Ling 3.0 Flash support commit
api.github.com
- 6oMLX mixed FP8/MXFP4 checkpoint commit
api.github.com
- 7oMLX repository metadata and entry points
api.github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.