Memory 技术日报 2026-08-03：持久 prefix、DCP L2 与压缩遥测

Memory 技术日报 2026-08-03：持久 prefix、DCP L2 与压缩遥测

本期用三条窗口内的一手工程更新，拆解上下文容量测量、DCP 分片后的 HiCache L2 页映射，以及压缩池满载时的失败遥测边界。

大模型 Memory 技术日报
大模型 Memory 技术日报@wei
这 24 小时里没有一篇能单独核验发布时间、且足以入选的大模型 memory 新论文。本期因此只收三条一手工程更新：oMLX 把「能装下多长上下文」和「重启后能否恢复 prefix」变成可操作的测试入口；SGLang 把 DCP 下的 HiCache L2 从物理页计数改成逻辑页分配，再在传输边界还原到各 rank 的物理行；Hermes Agent 则补上压缩池拒绝时的状态遥测。
它们共同指向一个比「缓存更大」更容易被忽略的问题：容量需要可测，页需要有明确的身份，失败需要能被观测。三条都值得复现，但都不应直接外推成端到端吞吐或模型效果提升。

1. oMLX：先测当前机器能承受的上下文

oMLX v0.5.4 于 2026 年 8 月 2 日 23:35:47（北京时间）发布。与 memory 直接相关的增量有三层：context benchmark 会在当前 Mac 上寻找「最大成功 prefill」，并可通过 API、Web dashboard 或 macOS app 应用这个结果；SpecPrefill 开始复用能跨请求、跨重启保留的 target prefix；长上下文缓存的恢复路径也修复了若干状态问题，包括 prefix-cache reconstruction 留在 engine stream 上，避免完全命中缓存的并发 prefill 在恢复时卡住。1

适合谁先跟进

这条更适合在 Apple Silicon 上维护 MLX 推理服务、需要给不同模型设置上下文上限的人。它把「配置一个很大的窗口」改成「先用当前机器测出最大的成功 prefill，再把结果写回服务配置」。这比把模型标称上下文长度当成实际可用容量更接近线上问题。

先复现什么

  1. 在同一台 Mac 上升级到 v0.5.4，从 context benchmark 的 API、Web dashboard 或 macOS app 入口跑一次，记录最大成功 prefill。源码 release note 没有给出一个可直接复制的命令，因此不要把某个自拟 CLI 当成官方复现步骤。
  2. 固定 system/tool prefix，分别测试连续请求和服务重启后的命中与恢复；重点观察 prefix 是否被重建、完全命中并发 prefill 是否还能继续，而不是只看首 token 延迟。
  3. 若要比较版本，必须保持模型、Mac、MLX/运行时、请求序列和 prompt 形态一致。

局限在哪里

release 同时列出了多项模型和 MTP 加速数字，但没有为本期的 context/cache 变化提供一套同时包含模型、硬件、运行时和基线的统一 benchmark；而且 v0.5.4 的 throughput prompt 从重复填充改成了自然文本，官方明确提示结果不能直接与 v0.5.3 比较。因此，本条能证明测试入口和恢复路径发生变化，不能证明它让所有模型的上下文容量或端到端吞吐按某个比例提升。

2. SGLang：DCP 的逻辑页，不能直接当物理页

SGLang 在 2026 年 8 月 2 日 23:35:27（北京时间）的 commit 1a3bea77f2abadb2206ba93293ee4fc4da76742a 中加入 DCP + HiCache L2 支持。核心不是把 host pool 简单扩大，而是让控制层看到 logical_size = physical_size × dcp_size，让 logical_page_size = physical_page_size × dcp_size，再按 index % dcp_size == dcp_rank 过滤当前 rank 的槽位，并用整除还原成 kernel 使用的物理行。metrics 也改用 logical size 计算 host 使用量。2
这个边界很具体：如果逻辑页没有在传输前翻译，radix 层可能把另一个 rank 的 KV 当成命中结果。commit 新增的注册测试正是用 Kimi Linear 的 DCP 场景检查这种错误，并用 KL 差异捕获它，而不是只看请求是否返回。

适合谁先跟进

这条适合正在把 DCP、MLA 和分层 KV 缓存组合起来的 SGLang 工程师。它提醒实现者把「控制器的逻辑容量」「每个 rank 持有的物理容量」「kernel 接收的物理 index」拆成三个可分别检查的量；只看 host pool 的总 token 数，很难发现 rank 间页身份错位。

先复现什么

先跑两个入口：
  • test/registered/unit/mem_cache/test_hicache_dcp_host_pool.py，检查 widened page、logical/physical sizing、DCP index translation，以及 transfer entry point 是否收到物理行。
  • test/registered/radix_cache/unified_radix_tree/test_unified_radix_cache_kl_dcp.py，使用 moonshotai/Kimi-Linear-48B-A3B-Instruct、tp-size 4、dcp-size 4、page-size 64、tokenspeed_mla、fp8_e4m3、bfloat16 和 UnifiedRadixTree，测试 HiCache L2 的命中一致性。注册配置指定了 4 张 B200，并启用 10GB HiCache 和 write_through。
先确认单元级的逻辑页与物理行映射，再跑 GPU 注册测试；这两个测试覆盖的是不同层次的问题，不能用前者替代后者。

局限在哪里

commit 明确把支持范围限制在 MLA host pool 和 HiCache L1/L2。L3 storage backend、speculative decoding、LMCache、HiSparse 以及非 MLA backend 与 DCP 的组合会被拒绝或仍未实现；page_size 还必须能被 dcp_size 整除。注册测试本身是 Blackwell/tokenspeed_mla 路径，不能据此推出 MHA、其他 GPU 或 L3 的行为，也没有给出端到端吞吐收益。

3. Hermes Agent：压缩被拒绝，也要留下状态

Hermes Agent 的 commit a0e700c4cf3c9f59a2e6fcd4892d5261985fc6fa 于 2026 年 8 月 3 日 07:16:36（北京时间）提交，作者时间为 06:35:59。它修的是一个可观测性缺口：有界 compression pool 满载时，fail-fast admission 路径原来只写 WARNING，遥测流看起来就像「从未尝试压缩」。现在 run_compress_context_with_progress_timeout 接收 telemetry_agent，拒绝请求时沿用既有的 compression-attempt telemetry，写入 failure_class=pool_saturated、commit_status=aborted、split_status=aborted 和 started_at；run_agent.py 把当前 agent 传入。3

适合谁先跟进

这条适合维护 agent context compression、需要区分「没触发压缩」「压缩排队」「压缩被池容量拒绝」「压缩执行失败」的工程团队。对于线上诊断，pool_saturated 比一条笼统的 timeout 更接近调度原因，也能避免把压缩池饱和误报为模型或摘要器本身失效。

先复现什么

运行 tests/agent/test_compression_review_76354.py 中扩展的 saturation regression：让已有 worker 占满压缩池，再触发第五个请求，捕获包含 compression attempt telemetry 的日志并解析 JSON。测试应同时看到 failure_class=pool_saturated、commit_status=aborted、固定的 session id，且 fallback 原样返回、第五个 worker 没有真正执行。
复现时要保留「池满」这个前置状态；如果只是正常触发一次压缩，测不到这次 commit 的差异。

局限在哪里

这只是失败状态的可见性和回归测试，不是压缩算法、摘要质量、上下文长度或延迟优化。它没有证明压缩池扩容后吞吐更高，也没有证明 pool_saturated 发生时 fallback 一定满足业务质量要求。commit 的 GitHub API 记录显示它未签名，工程上仍应以 diff 和测试结果核对实际版本，而不是把 commit message 当成独立 benchmark。

放在一起看

进展证据与复现入口适合纳入的工程动作不能外推
oMLX v0.5.4官方 release；context benchmark、prefix recovery；API/Web/macOS app 入口为具体 Mac 和模型建立可用上下文上限，单独做重启后的 prefix 恢复测试不能与 v0.5.3 直接比较，也没有统一 cache/吞吐 benchmark
SGLang DCP + HiCache L2官方 commit；host-pool unit test + Kimi Linear 注册测试把 logical page、physical row、rank translation 分开测，再验证 cache hit 一致性仅 MLA、L1/L2；不覆盖 L3、MHA、speculative、LMCache、HiSparse
Hermes pool_saturated telemetry官方 commit；压缩池 saturation regression给压缩拒绝补 failure class，并把池容量状态接入告警/诊断不代表压缩质量、吞吐或延迟改善
本期的共同判断是：memory 系统的下一步工程工作不只在「再塞进更多 token」。oMLX 先把容量与恢复变成机器相关的测量；SGLang 先把分片后的页身份校准；Hermes 先让压缩失败可见。复现这三条时，应分别记录容量账、索引映射和失败状态，不能把它们合并成一个未经验证的性能结论。

References

  1. 1oMLX v0.5.4 release
  2. 2SGLang DCP + HiCache L2 commit
  3. 3Hermes Agent compression telemetry commit

Related content

  • Sign in to comment.
More from this channel
View the full content archive of "大模型 Memory 技术日报"Explore more channels on Discover