Memory 技术日报 2026-07-02：STAR-KV、vLLM-Omni 与程序记忆评测
本期收录 5 条 memory/context 工程信号：STAR-KV 公开低秩 KV cache 压缩实现，vLLM-Omni 把多模态 token 纳入统一 KV/prefix caching，BaseRT 在 Apple Silicon 上做零分配 decode 与 paged-KV，SkillHone/AFTER 则把 agent 记忆推进到技能修订历史和跨角色迁移评测。
今天的 memory 信号分成两条线：一条继续把 KV cache 当成 GPU/内存/调度问题处理，另一条把 agent 的长期记忆从「检索一段文本」推进到「沉淀可迁移的技能与修订历史」。窗口按北京时间 2026-07-01 09:00 至 2026-07-02 09:00 统计；其中 SkillHone 和 AFTER 是 Hugging Face Papers 在 7 月 1 日的社区提交，原始 arXiv 版本早于窗口，下面会分开写清。
速览
| 信号 | 窗口依据 | Memory 增量 | 今天该怎么跟 |
|---|---|---|---|
| STAR-KV 开源低秩 KV cache 压缩 | Dnotitia 新闻稿在北京时间 7 月 2 日 07:30 发布，称论文和源码已释放1 | 软阈值自适应选秩 + 混合分解 + 量化，目标是同时压 KV 容量和 attention 计算 | 先看 repo 的 latency/eval 脚本能否贴近自家上下文长度，不急着把 20x 当生产收益 |
| vLLM-Omni 统一多模态 token 的 KV cache | Red Hat 在 7 月 1 日发布 Qwen3-Omni serving 架构文章2 | KV cache 存所有模态 token 的 key/value，调度器保持模态无关；prefix caching 复用 vLLM 机制 | 多模态 serving 不要先写一套按模态分叉的缓存逻辑，先确认 stage 和 KV group 边界 |
| BaseRT 把 Apple Silicon 本地推理的 decode loop 做到零分配 | Hugging Face 社区文章 7 月 1 日发布3 | KV cache、scratch buffers、logits/token buffers 在模型加载时预分配，server 支持 paged-KV cache 和 prefix caching | 如果团队用 Mac 做本地 agent 或离线评测，可以把它当作 llama.cpp/MLX 的对照基线 |
| SkillHone 让 agent 记住「修订过程」 | HF Papers 7 月 1 日提交；原始 arXiv v1 为 6 月 7 日、v2 为 6 月 23 日45 | 不只保留最终 skill，还保留诊断、拒绝方案、证据和结果，让下一轮不用重踩坑 | 做 agent memory 时，把「为什么没选某条路径」也结构化存下来 |
| AFTER 把程序记忆放进可迁移评测 | HF Papers 7 月 1 日提交；原始 arXiv v1 为 6 月 22 日67 | 382 个企业任务、6 个角色、22 个程序技能，测本地提升、跨任务、跨角色和跨模型迁移 | 不要只看同一任务反复优化后的分数，至少补一个跨角色或跨模型迁移切分 |
STAR-KV：低秩压缩不只省显存，还盯上 attention 计算
Dnotitia 今天发布的 STAR-KV 信号有两层：论文被列为 ICML 2026 Spotlight，源码也已在 GitHub 公开18。它的核心不是把 token 直接丢掉，而是把 KV cache 投影到低秩空间，再用可学习的软阈值决定每个注意力头、每个块保留多少秩9。
新闻稿给出的数字很激进：仅低秩压缩最高可减少 75% KV cache；再结合混合精度量化，整体 KV cache 最高压到 20x；Triton 定制 kernel 让 attention 模块最高 6.9x，加上端到端生成吞吐最高 3.1x1。这里要看两件事：第一，压缩率和吞吐提升是否在自家模型、batch size、上下文长度上同时成立；第二，repo 目前没有正式 release，README 里还列着权重文件、量化延迟测试等待办项8。
工程上可以先把 STAR-KV 当作「可复现实验候选」，不是现成基础设施。最有价值的起步动作是跑它的
latency.py 和 eval.py，把 32K、64K、128K 三档上下文下的准确率和 TTFT/吞吐曲线画出来。只有压缩收益没有把长上下文准确率打穿，它才值得进入 serving 路线图。vLLM-Omni：多模态 serving 的缓存边界变清楚了
Red Hat 这篇 vLLM-Omni 文章值得看，是因为它把 Qwen3-Omni 这类多阶段、多模态模型放回 serving 架构里讲。Qwen3-Omni 被拆成 Thinker、Talker、Code2Wav 三段：Thinker 负责文本/视觉/音频/视频输入后的推理和文本生成，Talker 在音频输出时生成音频码，Code2Wav 再把码变成波形2。
对 memory 读者更关键的是缓存抽象：vLLM-Omni 的自回归阶段复用 vLLM 原生 scheduler，KV cache 存所有模态 token 的 key/value，不按文本、图像、音频再做分叉；prefix caching 也复用 vLLM 的 KV cache prefix caching，只是当前限定在自回归阶段、单 KV cache group 的场景2。
这给多模态 agent serving 一个很实用的提醒：先把模态输入对齐成统一 token 序列，再决定哪些 stage 能共享前缀缓存。否则很容易为了「音频/图像看起来不一样」写出两套缓存路径，最后调度器、显存预算和 prefix 命中率都难以解释。
BaseRT：本地推理的 memory 优化还在继续往下钻
BaseRT 不是长上下文论文，但它把 Apple Silicon 本地推理里的 memory path 写得很具体。它直接面向 Metal 写 C++ runtime，不依赖 MLX、PyTorch、CoreML；decode loop 在模型加载后不再分配内存，residual、attention、feed-forward scratch buffers、logits、token buffers 和 KV cache 都一次性预分配3。
文章报告的对比是：M4 Pro 上 Qwen3-0.6B Q4 decode 相比 llama.cpp 最高 1.56x，相比 MLX 最高 1.35x；MoE prefill 在 Qwen3-30B-A3B 的 128-token prompt 下，相比 llama.cpp 最高 1.81x，相比 MLX 最高 1.78x3。它还把 OpenAI-compatible server、continuous batching、paged-KV cache、prefix caching 一起放进本地 runtime 里3。
如果你的 agent 测试链路仍在开发机上跑，这类 runtime 的价值不只是「每秒 token 更多」。它会影响本地复现时的上下文上限、缓存命中、并发测试成本。别只看小模型 decode 峰值，最好补一组长 prompt、多会话复用前缀的 benchmark。
SkillHone：agent memory 该记住失败路径
SkillHone 把 agent skill 看成会持续演化的对象。论文的切入点很直接：现有方法常常只保留最后改好的 skill，把诊断、被拒绝的方案、评估证据和结果都丢掉；下一轮 agent 接手时，只能重新猜为什么前一次这么改5。
它的做法是把 skill revision 和 evaluation-side evidence 绑在一起，形成持久化决策历史。作者报告，SkillHone 在 GAIA 上比一个商业 deep-research agent 高 15.8 分，在 WebWalkerQA-EN 上高 3.2 分；在 7 个内部 tool-mediated analysis 场景里，平均准确率提升 18.8 分45。
这类工作对生产 agent 的提醒很朴素：memory store 里只放「最后答案」不够。真正能让 agent 变稳的，往往是失败路径、验证命令、被排除的修复方案和它们失败的证据。它们不一定要进 prompt 全文，但应该能被下一轮检索到，并且能解释「为什么当时没有走那条路」。
AFTER：程序记忆要测迁移，不只测同题复做
AFTER 关注的是程序记忆，也就是 agent 在工作流里学到的可复用技能。它给出 382 个企业任务，覆盖数据工程、数据科学、生成式 AI、基础设施、项目管理、软件工程 6 类角色和 22 个程序技能；评估切分包括本地提升、跨任务、跨角色、跨模型泛化67。
论文报告，单次 refinement round 可让整体性能提升 3.7-6.7 分；从多模型执行轨迹演化出的技能，跨模型测试准确率达到 73.1%，优于所有单模型轨迹来源7。代码与任务材料已经在 GitHub 公开，README 里也列出了任务、角色、技能矩阵和 oracle-side/agent-visible 的目录边界10。
这比「给 agent 加一个长期记忆库」更接近生产问题。一个 skill 在原任务上变好，不代表它能迁移到另一个角色；一个由单一模型轨迹学出来的 skill，也可能只适配那个模型的习惯。要判断程序记忆是否可靠，至少需要一个 held-out task，一个跨角色切分，最好再加一个跨模型切分。
工程判断
今天可跟的动作有三个优先级：
- 长上下文 serving 团队：把 STAR-KV 放进离线 benchmark，而不是直接放进线上。重点看 64K/128K 上下文的准确率、TTFT、吞吐和显存曲线，尤其要确认 Triton kernel 的收益是否覆盖重建开销。
- 多模态 serving 团队：读 vLLM-Omni 的 stage/KV group 设计。多模态模型的缓存问题会先表现为调度复杂度，而不是单个 attention kernel 慢。
- agent 平台团队：把 SkillHone 和 AFTER 放到同一张路线图里看。前者提醒你记住修订历史，后者提醒你评测迁移；少任何一边，memory 都容易变成「能存但不一定有用」。
如果今天只能做一件事，优先补齐自家 agent 或 serving 系统的 memory 观测项：KV cache 命中率、前缀缓存命中率、cache 重建成本、skill 复用成功率、失败路径复用次数。没有这些指标，后面再换压缩方法或记忆架构，很难判断到底是系统变好，还是只是多存了一堆东西。
References
- 1
- 2Inside the vLLM-Omni architecture: Serving Qwen3-Omni
developers.redhat.com
- 3
- 4
- 5
- 6
- 7
- 8GitHub - PriyanshBhatnagar/STAR-KV
github.com
- 9
- 10GitHub - DavydenkoGr/AFTER
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.