Generated by Answer me with HTML 0.5.10 · 2026-10-29 10:05 · ★ Star on GitHub

Hy-Memory 2.0 的内存与 token 账

同一份生产库副本、同一批 3 条输入、同机同时段实测

source隔离 A/B 实测 2026-10-29 · 硅基 Xing4.0-29B · 提炼历史 0 轮 · reconcile 关

Lead: 结论有点反直觉。2.0 在内存上更省，约轻 130 MB；在 token 上更贵，同样的输入贵 62%。 不打提炼历史补丁的话贵 156%，因为那个 or 5 老 bug 在 2.0.8 里还在。

A

结论

一句话

内存：2.0 赢。三次写入后平台 238 MB，1.2.21 是 374 MB。 token：2.0 输。每次提炼 prompt 1545 → 2668 token。 两边各有代价，看你先肉痛哪一头。

测法
生产库副本 3 条同输入
写入后内存
374 MB → 238 MB
每次提炼 prompt
1545 → 2668 token
3 次写入合计
5171 → 8402 token
补丁缺口代价
再涨到 13254
单组样本
各 1 轮，看量级不看小数
B

写入侧的 token 账

配置 每次 prompt 3 次合计 token 抽出事实 单次耗时
1.2.21（现役口径） 1545 5171 6 条 17.6 / 6.6 / 8.0 s
2.0.8 未补丁 4060 13254 13 条 11.8 / 11.1 / 8.8 s
2.0.8 + 提炼历史补丁 2668 8402 3 条 7.8 / 2.1 / 2.3 s
差在哪两层

第一层是基础 prompt 变大：1545 → 2668 token，涨 72%。 2.0 的抽取 schema 和治理字段更多，这部分关不掉。 第二层是历史注入 bug：2.0.8 仍是 or 5，设 0 无效。 不补丁每次多塞两千多 token，还会重抽旧话题，13 条对 3 条。

C

内存曲线

阶段 1.2.21 2.0.8（补丁后）
冷启动 90 MB 98 MB
第 1 次写入后 364 MB 243 MB
第 3 次写入后 374 MB 243 MB
形态 首写大跳后仍上行 首写大跳后横住
为什么 2.0 更省

embed_service 整个重写了：embedding 缓存改 LRU 上限淘汰、LLM 客户端按 key 缓存复用。 我们那些本地内存补丁，2.0 已经吸收了一大半。 剩下的 list[float] 存储问题还在，但实测平台已经压在 240 MB 一线。

D

召回与日志开销

项目 1.2.21 2.0.8 说明
召回注入上限 5 条 / 4000 字符 同 你设的 limit 决定，两版同价
5 条召回正文 359 ~ 780 字符 498 ~ 1090 字符 约 200 ~ 605 token
检索耗时 0.3 ~ 1.9 s 0.2 ~ 2.4 s 同量级
返回字段 memories 三段 再加 episode / rerank 四段 插件只取 memories
日志落盘 每步 JSONL 必写 可关，原文降到 DEBUG 2.0 更省磁盘
别把这栏当成版本开销

召回正文长度取决于库里命中哪几条，不是版本差异。 你调 limit 和 4000 字符上限，两版省的是同一笔。 真正稳定的区别只有写入侧那笔 token。