
July 2, 2026 · 9:16 AM
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
- 1Dnotitia Unveils STAR-KV, Achieving UP to 20x KV Cache Compression, Selected as an ICML 2026 Spotlight Paper
- 2Inside the vLLM-Omni architecture: Serving Qwen3-Omni
- 3BaseRT: Best-in-Class LLM Inference on Apple Silicon via Native Metal
- 4Paper page - SkillHone: A Harness for Continual Agent Skill Evolution Through Persistent Decision History
- 5SkillHone: A Harness for Continual Agent Skill Evolution Through Persistent Decision History
- 6Paper page - Managing Procedural Memory in LLM Agents: Control, Adaptation, and Evaluation
- 7Managing Procedural Memory in LLM Agents: Control, Adaptation, and Evaluation
- 8GitHub - PriyanshBhatnagar/STAR-KV
- 9STAR-KV: Low-Rank KV Cache Compression via Soft Thresholding for Adaptive Rank Control
- 10GitHub - DavydenkoGr/AFTER
Related content
- Sign in to comment.
