---
template: sheet
theme: shadcn
title: Mnemosyne 与 hy-memory：2G2C 小机器的取舍
subtitle: 设计上 Mnemosyne 更轻，这台机器上只能用 hy-memory
cols: 3
source: 实测 1.7GB / 2 核 · hy-memory RSS 守护日志 · Mnemosyne v2.4.0 requirements
---
先看硬约束：Mnemosyne 是 AstrBot 插件，Hermes 里装不上，所以「这台机器用哪个」不是选择题。能比的只有「设计谁更省」，以及「hy-memory 现在这 455MB 该不该治」。

## A 一句话结论

```callout info 结论
设计上 Mnemosyne 更省：依赖只有 chromadb + psutil，记忆单位是总结，向量条数少一个量级，没有图库和稀疏索引。
这台机器上只能用 hy-memory：它已经装好在跑，而 Mnemosyne 需要整套 AstrBot。
```

真正的问题不是换插件，是 hy-memory 在只有 1977 条向量时吃到 455MB。

## B 硬约束

Mnemosyne 必须先有宿主 AstrBot v4.0.0+。记忆挂在 AstrBot 事件链上，Embedding 与 LLM 都借宿主 Provider。

也就是说要迁 Mnemosyne，得先在这台 2G2C 上再跑一个 AstrBot 实例。这台机器现在已用 900MB，剩 807MB 可用，AstrBot 加 Chroma 一装就到底了。

反过来 hy-memory 是 Hermes 的 memory provider，`kind: exclusive`，与本机现有的 hook 链对齐，不需要新框架。

## C 这台机器的实测

```kv cols=2
物理内存: 1708 MB
当前已用: 900 MB
可用: 807 MB
CPU: 2 核
hy-memory 重启后: 92 MB
正常增长后: 367 MB
触发守护阈值: 450 MB
历史重启次数: 81 次
```

```chart line unit=MB
| hy-memory RSS
12:04 | 91
16:32 | 367
17:00 | 455
17:00 重启后 | 92
```

守护脚本在 450MB 阈值上重启，冷却 45 分钟。今天 17:00 刚重启过一次，这是第 81 次。

## D 成本结构对比

| 项 | 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，都不在本机跑模型，这一点打平。差别在依赖面和图索引。

## E 455MB 才奇怪

```callout warn 关键数字
本机 Chroma 里只有 1977 条向量：`/root/.hy-memory/db/data/vector_db/chroma.sqlite3`。

1977 条向量撑不起 455MB。换算下来每条 230KB，远超正常量级。
```

这说明内存不是被数据撑起来的，是运行时开销在涨：embedding 缓存、BM25 稀疏索引重建、或分配器碎片。你之前调过 HNSW / IVF-PQ 和 malloc arena，方向就是对的。

对比之下 Mnemosyne 的语料是「每 5 轮一条总结」，同样数据量下向量条数比原子事实少一个量级，涨得慢是结构决定的。

## F 这台机器该怎么处置

按性价比排序，都不需要换插件：

- **先量再改**：重启后 92MB、四小时后 367MB，说明是持续增长。抓一次增长期的对象分配，比调阈值有用。
- **阈值降到 350MB**：1.7GB 机器上 455MB 已经接近安全线，cooling 45 分钟足够；代价是重启更频繁，冷启动要重建索引。
- **压记忆体量**：去重阈值现在 0.75 偏严，早期积累的重复记忆会持续被索引。定期淘汰低强度记忆比调索引参数省事。
- **别为对比改架构**：只有 2000 条记忆的规模，任何图检索的收益都很小，`ultra` 模式在这台机器上不划算。
- **保持远程算力**：embedder 和 LLM 都在 SiliconFlow，这是这台 2G 机器能跑记忆引擎的前提，别改成本地模型。

```callout ok 一句话
这台机器上更友好的方案不是换插件，是把 hy-memory 的 RSS 增长压回不超过 200MB。
```

## G 真要上 Mnemosyne 的代价

- 多一个 AstrBot 实例常驻，2 核要分一半给它。
- 记忆入口分裂：聊天走 AstrBot，Hermes 的会话拿不到这些记忆，除非再写桥。
- 记忆质量下降：总结型记忆答得了「哪段对话最像」，答不了「偏好变了没有」。你现在依赖的演进链会丢。
- 唯一真实好处：依赖少、面板好看、多租户过滤细。这些不值得为它再养一套框架。

未核实：Mnemosyne 的进程内存实测（没有 AstrBot 环境，跑不起来），以及 hy-memory 455MB 的具体归属对象（需要采样分析）。