Memory 技术日报 2026-07-12：PKAS、Graphify 与 LiteLLM 网关压缩

过去 24 小时的 memory/context 信号不算多，但三条都贴近生产系统：KV cache 不只是模型内部状态，还会影响调度器能不能接纳新请求；代码知识图谱不是建完就结束，还要防止 watch/rebuild 把仍存在的源误删；上下文压缩也开始从单个 agent SDK 前移到 LLM gateway。今天这期收缩为三条，重点看它们分别把 memory 问题放在了调度、图谱和网关三层。

PKAS 的问题设定很直接：LLM 推理里，KV cache 内存会随着序列长度和 batch size 线性增长；现有 runtime 常用 continuous batching 提高 GPU 利用率，但调度器如果贪婪接纳 prefill 请求，就可能没给后续 decode 阶段留下足够 KV cache 空间。论文摘要把后果说得很清楚：KV cache overflow 会触发 preemption 和 recomputation，吞吐和延迟都会被拖下来。1

它的解法是 Predictive KV Cache-Aware Scheduling：先用低开销方式模拟未来 KV cache 使用，再结合轻量输出长度预测来指导新请求接纳。换句话说，调度器不只看当前 batch 还能不能塞进去，还要估计这些请求进入 decode 后会不会把缓存预算挤爆。1

摘要给出的性能数字很亮眼：在多种模型和工作负载上，相比现有最优调度方案，PKAS 最高实现 7.34x 更高吞吐和 8x 更低延迟。这里要保守读：当前抓取只读到 ACM 页面摘要，没读到完整实验设置、工作负载分布和代码入口，所以今天只能把它当作值得跟进的系统论文信号，而不是已经可直接复现的调度方案。1

工程判断：这条对 serving 团队很重要。过去很多 KV cache 优化讨论集中在压缩、offload 或复用，但 PKAS 提醒我们，调度策略本身也会制造或避免 KV overflow。在线推理如果同时有长 prompt、长输出和高并发，单纯提高 batch 利用率可能会把问题推到 decode 阶段。

Graphify 的定位是把代码、SQL schema、R/shell 脚本、文档、论文、图片或视频转成可查询知识图谱，面向 Claude Code、Codex、OpenCode、Cursor、Gemini CLI 等 coding agents；它把 app code、database schema 和 infrastructure 放进同一张图里。4

这次窗口内的信号不是大版本发布，而是一条很具体的 watch/rebuild 修复：旧逻辑把「source identity 不在 collected corpus 中」视为删除，并据此驱逐 nodes、edges 和 hyperedges。但 corpus absence 是歧义信号，文件可能还在磁盘上，只是因为 ignore rules 或 filters 改变而没被采集。3

提交说明给了一个生产味很重的例子：升级到 merged-.gitignore scan semantics 后，一个刻意构建且被 .gitignore 的 docs 目录曾被 mass-evict 655 nodes；这些文件其实仍存在，却被 rebuild 报告为成功。新逻辑改成 fail-closed：在驱逐 corpus-absent identity 前，必须确认 Path(identity).exists() is False；仍存在但被排除的源会保留 nodes、edges 和 hyperedges，并输出提示。3

工程判断：这条不炫，但很像真实 agent memory 会遇到的问题。代码库记忆不是一次性 embedding，而是持续同步的结构化状态；当 .gitignore、过滤规则、分支或工作区布局变化时，系统要区分「真的删除」和「本轮没采到」。否则 agent 会把还存在的设计文档、schema 或依赖关系从记忆里清掉，后续回答看似干净，实际少了上下文。

Headroom/LiteLLM 这篇工程博客的核心不是一个新的压缩算法，而是放置位置：如果 agent 调用已经统一经过 LiteLLM proxy，Headroom 可以作为 pre-call guardrail 接到网关上，在不改 client code 的情况下压缩每一次流经网关的 LLM 调用。5

文章可见部分明确提到压缩对象包括 tool outputs、logs 和 RAG chunks，也提到模型会拿到一个工具，在需要时再取原文。这一点比「把 prompt 变短」更关键：它把上下文压缩从应用层 prompt 拼接，变成了网关层的默认请求处理。5

这条的边界也要写清楚。当前抓取到的是 Medium 可见正文和 friend link 提示，文章可见部分没有给出完整配置、开源仓库、压缩率、延迟代价或线上 benchmark。因此它适合作为「网关层上下文压缩」的工程实践信号，而不是可验证的性能结论。5

工程判断：如果团队已经用 LiteLLM 做多模型路由、限流和日志，gateway 是压缩 memory payload 的自然位置。真正要评估的是三件事：压缩后的摘要是否保留引用和可追溯性，模型回取原文的动作是否可观测，以及压缩层会不会破坏 prefix caching 或工具调用的稳定格式。

今天三条线索共同指向一个变化：memory 系统正在从「存更多上下文」转向「在哪一层减少无效读写」。PKAS 让调度器提前看 decode 阶段的 KV 预算，Graphify 修补代码知识图谱的删除证据，Headroom/LiteLLM 把压缩放到所有请求共同经过的 gateway。

如果只选一条继续跟，serving 团队先看 PKAS，因为它直接关系到高并发长输出场景下的吞吐和尾延迟；做 coding agent 或代码库 RAG 的团队先看 Graphify，因为记忆同步的误删会变成长期隐性质量问题；已经有 LiteLLM 网关的应用团队可以关注 Headroom 这条，但暂时不要把博客里的方向性描述当作已验证 benchmark。