Memory 技术日报 2026-06-19：Brain、KV 压缩竞赛、DeepSeek/GLM 服务栈
June 19, 2026 · 9:12 AM

Memory 技术日报 2026-06-19：Brain、KV 压缩竞赛、DeepSeek/GLM 服务栈

本期筛出 4 条 memory 方向进展：Perplexity Brain 把 agent 工作轨迹做成可追溯 context graph，KV cache 压缩讨论转向 TurboQuant、OSCAR 与 EpiCache 的组合取舍，Together AI 暗示 DeepSeek V4 Pro 的 cache state 已模型特化，Phala 用 W4AFP8 给 GLM-5.2 留出 1M context 服务余量。读完可判断今天该跟进工作记忆、KV 压缩，还是长上下文 serving 的显存账。

大模型 Memory 技术日报
大模型 Memory 技术日报@wei

Research Brief

窗口内可确认的高信号条目集中在两件事：agent memory 开始从「用户画像」转向「工作轨迹」，KV cache 则继续从单点压缩走向可部署的服务栈。本期覆盖 2026-06-18 09:00 至 2026-06-19 09:00（Asia/Shanghai）。

速览

进展时间窗证据Memory 关键词工程动作需要留意
Perplexity Brain 把 agent 过往工作整理成可追溯 context graph，并在 Research Preview 中面向 Max / Enterprise Max 推出MarkTechPost 报道发布于 06-19 04:26；Perplexity 官方页标注 Jun 18 1 2外部记忆、工作记忆、可追溯图谱把 corrections、dead ends、source links 做成可复用记忆，而不是只存偏好早期效果数字来自 Perplexity 自测，暂无独立 benchmark 2
MarkTechPost 对 TurboQuant、OSCAR、EpiCache 做了一次 KV cache 压缩横向梳理06-18 17:14 3KV quantization、episodic cache、长上下文成本按约束选择：模型无关、INT2 部署、长会话多轮记忆它是窗口内技术梳理，不是三篇论文的首发；关键数字要回到原论文或代码复核 4 5 6
Together AI 解释 DeepSeek V4 Pro 的 KV cache 不再是通用缓存，而要同时处理 sliding window、indexer 与 compression states06-19 08:45 7KV cache 复用、sparse attention serving模型接入时检查 cache state 语义，避免只按传统 key/value tensor 处理这是官方工程说明帖，详细技术报告仍需后续链接补全 7
Phala 把 GLM-5.2 服务问题拆成 HBM 与 KV cache 余量：W4AFP8 权重从 755GB 降到 368GB06-19 07:50 8权重量化、1M context、KV headroom先释放 HBM，再给 KV cache、CUDA graphs、runtime buffers 留空间Phala 的质量检查是自报数据，适合做部署线索，不等于第三方评测 9

1. Brain：把「这次任务怎么做成的」变成 agent memory

Perplexity 对 Brain 的定义很清楚：它不是主要记住用户喜好，而是记住 Computer 这个 agent 做过什么、哪里做对、哪里走了弯路、用户后来怎样纠正。官方说明称，Brain 会构建一张 context graph，并在夜间一类固定周期内综合历史会话、connector 结果、源文档变化和 corrections，生成新的 LLM wiki；这些 wiki 会被加载到 agent sandbox 里供后续任务使用。2
Perplexity Brain ablation study
Perplexity 官方图展示 Brain ablation 中 correctness、recall、currentness 与 efficiency 的变化；这些是第一方早期测试结果。2
这条进展对工程团队的提示很直接：agent memory 不一定从「给用户建一份 profile」开始。更可控的起点，是把任务过程本身做成可追踪日志：输入来源、检索路径、失败来源、用户修正、最后采纳的 artifact。Perplexity 还强调每条 memory 都能回链到 session、file 或 source，这一点比「记得更多」更重要。没有可追溯来源的记忆，会在几轮任务之后变成新的幻觉入口。1
可复现性上，现在只能把 Brain 当作产品级方向信号。官方披露了正确性、召回和成本改善，但没有公开完整 benchmark、样本构成或 API。企业内部如果要复刻，第一步不是训练记忆模型，而是先把「工作记忆对象」定义清楚：什么能进入长期图谱，什么必须过期，什么需要人工确认。

2. KV cache 压缩：三条线分别解决「怎么存」「怎么选」「怎么跨轮用」

MarkTechPost 的横向梳理把 TurboQuant、OSCAR 和 EpiCache 放到同一个问题里：长上下文下，KV cache 会线性增长，Llama-3.1-70B 在 BF16 下每 token 约 0.31MB；128K 上下文约 40GB，1M 上下文超过 300GB。3
TurboQuant 在 4x KV 压缩下接近全精度召回
MarkTechPost 图中转录了 TurboQuant 论文的 Needle-in-a-Haystack recall 对比；它适合说明「近无损压缩」的目标，不应被单独当作完整部署结论。3
三类方法的差别值得按约束拆开看：TurboQuant 主打无需校准、模型无关的 3-4 bit 近无损压缩；OSCAR 走 attention-aware rotation 和 INT2 部署路线，并强调 SGLang 集成、paged cache 与 prefix-cache 兼容；EpiCache 则面向多轮长会话，把 conversation history 切成 episode，再做匹配检索和层级预算分配。3
OSCAR INT2 量化对比图
MarkTechPost 图中转录了 OSCAR 论文在约 2.28 bits per KV element 下的 mean pass@1 accuracy；它说明 INT2 路线的部署吸引力，但仍需在目标模型上复测。3
工程判断不是「谁赢了」。如果目标是支持 128K 以上上下文且模型集合经常变化，模型无关量化更方便；如果目标是把少数已知模型压到 INT2 并跑在生产 serving 上，OSCAR 这种系统化路径更接近落地；如果痛点是多轮会话越滚越长，EpiCache 处理的是 token 选择和 episodic retrieval，而不是量化精度本身。三者可以叠加，但叠加后的质量、延迟和 cache miss 行为需要重新测。

3. DeepSeek V4 Pro：KV cache state 正在模型特化

Together AI 在窗口内的一条工程说明里指出，DeepSeek V4 Pro 的 KV cache 与以往 DeepSeek 模型不同：sliding window attention、indexer、compression states 都必须正确存储，才能获得好的 cache reuse。该帖还列出他们为加速实现的几类优化：fused attention setup kernels、更快的 sparse attention kernels、更好的 kernel overlap，以及在 graph 层剪掉不需要的 ops。7
这条信号的价值在「cache 已经不只是缓存」。许多 serving 接入默认把 KV cache 当成标准 tensor 复用问题，但新模型把窗口、索引和压缩状态一起放进计算路径。接入方如果只关注显存占用，很容易在 correctness、cache hit rate 或长会话稳定性上踩坑。
可执行动作：新增模型时，不要只跑短 prompt latency。至少补三组检查：长上下文多轮 cache reuse、窗口边界附近的输出一致性、开启 sparse / compressed cache 后的 regression。只看单轮吞吐，无法发现「状态存错但还会生成」的问题。

4. Phala 的 GLM-5.2 W4AFP8：1M context 先问 HBM 还剩多少

Phala 对 GLM-5.2 的窗口内说明更偏部署：官方 FP8 weights 为 755GB，W4AFP8 weights 为 368GB，释放出的 387GB 可用于 KV cache、CUDA graphs、runtime buffers，以及 full 1M-token window 的 serving headroom。8 另一条同线程说明给出自测质量数字：GPQA-Diamond 45.5 → 45.2，IFBench 70.5 → 70.5，AA-LCR 47.0 → 48.7。9
这不是又一条 GLM-5.2 发布消息，而是把长上下文部署的约束说得更具体：1M context 不是「模型支持」就够了。权重、KV cache、CUDA graph、runtime buffer 都在抢 HBM。权重小一半，真正释放出来的是长上下文并发和 serving 稳定性的空间。
采用这类路线时，要把质量评测和内存收益分开验收。内存收益可以从权重大小、KV headroom 和并发槽位直接算；质量变化要用自己的长上下文任务、工具调用任务和中文/代码场景复测。Phala 的数字适合作为候选 baseline，不适合作为直接上线依据。

工程判断

今天四条线索指向同一个结论：memory 系统正在从「把更多文本塞进上下文」转成「让状态可追溯、可压缩、可复用、可失效」。
  • 做 agent memory：先记录工作轨迹和 corrections，再谈个性化画像。
  • 做长上下文 serving：先测 KV cache hit rate、状态正确性和 HBM 余量，再谈 1M token 卖点。
  • 评估 KV 压缩：把量化、token 选择、多轮 episode 管理分开测，不要用一个 Needle-in-a-Haystack 分数替代生产结论。
  • 接新模型：把 cache state 当成模型接口的一部分，而不是推理框架里的透明实现细节。
如果只能选一件事跟进，优先把自己的 agent / RAG 系统加上「可追溯工作记忆」和「KV cache 命中率观测」。前者决定记忆会不会污染结果，后者决定长上下文成本是否可控。

References

  1. 1Perplexity Launches Brain
  2. 2Self-improving Memory for Agents
  3. 3The KV Cache Compression Race
  4. 4TurboQuant arXiv
  5. 5OSCAR arXiv
  6. 6EpiCache code
  7. 7Together AI on DeepSeek V4 Pro KV cache
  8. 8Phala on GLM-5.2 W4AFP8 memory footprint
  9. 9Phala quality checks for GLM-5.2 W4AFP8

Related content

Picked from other channels by content similarity—find new creators to follow.

Add more perspectives or context around this Post.

  • Sign in to comment.