Generated by Answer me with HTML 0.5.7 · 2026-10-23 18:10 · ★ Star on GitHub
Mnemosyne 与 hy-memory：2G2C 小机器的取舍
设计上 Mnemosyne 更轻，这台机器上只能用 hy-memory
先看硬约束：Mnemosyne 是 AstrBot 插件，Hermes 里装不上，所以「这台机器用哪个」不是选择题。能比的只有「设计谁更省」，以及「hy-memory 现在这 455MB 该不该治」。
一句话结论
设计上 Mnemosyne 更省：依赖只有 chromadb + psutil，记忆单位是总结，向量条数少一个量级，没有图库和稀疏索引。 这台机器上只能用 hy-memory：它已经装好在跑，而 Mnemosyne 需要整套 AstrBot。
真正的问题不是换插件，是 hy-memory 在只有 1977 条向量时吃到 455MB。
硬约束
Mnemosyne 必须先有宿主 AstrBot v4.0.0+。记忆挂在 AstrBot 事件链上，Embedding 与 LLM 都借宿主 Provider。
也就是说要迁 Mnemosyne，得先在这台 2G2C 上再跑一个 AstrBot 实例。这台机器现在已用 900MB，剩 807MB 可用，AstrBot 加 Chroma 一装就到底了。
反过来 hy-memory 是 Hermes 的 memory provider，kind: exclusive，与本机现有的 hook 链对齐，不需要新框架。
这台机器的实测
- 物理内存
- 1708 MB
- 当前已用
- 900 MB
- 可用
- 807 MB
- CPU
- 2 核
- hy-memory 重启后
- 92 MB
- 正常增长后
- 367 MB
- 触发守护阈值
- 450 MB
- 历史重启次数
- 81 次
数据
| hy-memory RSS | |
|---|---|
| 12:04 | 91MB |
| 16:32 | 367MB |
| 17:00 | 455MB |
| 17:00 重启后 | 92MB |
守护脚本在 450MB 阈值上重启，冷却 45 分钟。今天 17:00 刚重启过一次，这是第 81 次。
成本结构对比
| 项 | Mnemosyne | hy-memory（本机实测） |
|---|---|---|
| 依赖 | chromadb + psutil | chromadb + kuzu + scikit-learn + tiktoken + numpy + openai |
| 进程 | 宿主同进程 | 独立进程 19527 |
| 磁盘 | 未测（chromadb 体积为主） | venv 700MB + 数据 195MB |
| 内存峰值 | 未测 | 455MB（实测） |
| 记忆单位 | 对话总结 | 抽取的原子事实 |
| 本地算力 | 无（走宿主 Provider） | 无（embedder 与 LLM 都走 SiliconFlow） |
| 图索引 | 无图库 | Kuzu 图库 |
两者的 embedder 都是远程 API，都不在本机跑模型，这一点打平。差别在依赖面和图索引。
455MB 才奇怪
本机 Chroma 里只有 1977 条向量：/root/.hy-memory/db/data/vector_db/chroma.sqlite3。
1977 条向量撑不起 455MB。换算下来每条 230KB，远超正常量级。
这说明内存不是被数据撑起来的，是运行时开销在涨：embedding 缓存、BM25 稀疏索引重建、或分配器碎片。你之前调过 HNSW / IVF-PQ 和 malloc arena，方向就是对的。
对比之下 Mnemosyne 的语料是「每 5 轮一条总结」，同样数据量下向量条数比原子事实少一个量级，涨得慢是结构决定的。
这台机器该怎么处置
按性价比排序，都不需要换插件：
- 先量再改：重启后 92MB、四小时后 367MB，说明是持续增长。抓一次增长期的对象分配，比调阈值有用。
- 阈值降到 350MB：1.7GB 机器上 455MB 已经接近安全线，cooling 45 分钟足够；代价是重启更频繁，冷启动要重建索引。
- 压记忆体量：去重阈值现在 0.75 偏严，早期积累的重复记忆会持续被索引。定期淘汰低强度记忆比调索引参数省事。
- 别为对比改架构：只有 2000 条记忆的规模，任何图检索的收益都很小，
ultra模式在这台机器上不划算。 - 保持远程算力：embedder 和 LLM 都在 SiliconFlow，这是这台 2G 机器能跑记忆引擎的前提，别改成本地模型。
这台机器上更友好的方案不是换插件，是把 hy-memory 的 RSS 增长压回不超过 200MB。
真要上 Mnemosyne 的代价
- 多一个 AstrBot 实例常驻，2 核要分一半给它。
- 记忆入口分裂：聊天走 AstrBot，Hermes 的会话拿不到这些记忆，除非再写桥。
- 记忆质量下降：总结型记忆答得了「哪段对话最像」，答不了「偏好变了没有」。你现在依赖的演进链会丢。
- 唯一真实好处：依赖少、面板好看、多租户过滤细。这些不值得为它再养一套框架。
未核实：Mnemosyne 的进程内存实测（没有 AstrBot 环境，跑不起来），以及 hy-memory 455MB 的具体归属对象（需要采样分析）。