为什么我要给 Nowledge Mem 换了本地模型？

最近我把 Nowledge Mem 的记忆处理从云端模型换到了本地模型。原因很简单：我经常订阅不同的 token plan，导致给 Mem 配置的模型提供商很不稳定，token 经常用完，然后Mem的智能处理就停了，有时候好几天才发现。

ps: 强烈建议 @wey_gu 做个 llm fallback 功能

所以我决定用本地模型，这样就不用担心额度问题了，但哪个本地模型更适合 Nowledge Mem呢？

Nowledge Mem 官方默认用的是 Gemma-4 E2B，毕竟要适配最广大的用户，所以用这个小模型能保证使用下限。但对于有高配置的电脑来说，肯定是不够的。先说说我的测试环境：

- Mac mini，M4 Pro，64GB 统一内存
- LM Studio 0.4.19+2
- GGUF Runtime：llama.cpp 2.25.2
- MLX Runtime：1.10.1

其实在此之前，我已经简单测试了一波：

基础测试

首先固定所有测试参数：
- 上下文长度：32,768 token
- Temperature：0
- Top P：1
- Thinking/Reasoning：关闭
- GPU Offload：最大
- 并发请求：1个
- 模型并行槽位：默认 4
- 最大输出：700 token

统一的系统提示词：

你是长期记忆整理器。只保留未来仍然有用的信息；区分临时闲聊、旧信息和当前信息；不得把临时天气、情绪或一次性寒暄保存为长期记忆。严格按用户要求输出 JSON，不要 Markdown

测试场景：
- 从聊天中提取长期记忆
- 正确区分新记忆和旧记忆
- 把旧记忆标成 superseded
- 把新记忆标成 current
- 不要把“今天天气很热”“刚喝了一杯水”存进长期记忆
- 连续 3 次输出合法 JSON

测试提示词：

请从下面对话中整理长期记忆。
对话：
用户：我主要使用中文沟通。
用户：以前 AI Builders Digest 使用 agent_browser 后端。
用户：从今天开始，正式改用 opencli，agent_browser 不再作为当前后端。
用户：自动化任务每次最多处理 20 条内容。
用户：任何发布或对外发送动作必须先征得我的确认。
用户：我希望记忆整理时保留被新决定替代的旧决定，并明确标为 superseded。
用户：今天天气真热。
用户：刚才喝了一杯水。
返回一个 JSON 数组，每项必须且只能包含：
{"memory":"简洁记忆内容","status":"current 或 superseded","kind":"preference、decision 或 rule"}

该提示词测了 4 件事：
1. 提取：能不能找全 6 条长期信息：中文偏好、旧后端、新后端、每次最多20条、发布前确认、保留旧决定的整理偏好
2. 更新：能不能识别 opencli 已经替代 agent_browser。
3. 保留历史：旧决定不能直接消失，而是标成 superseded。
4. 过滤噪声：天气和喝水不能混进长期记忆

每个模型连续执行 3 次完全相同的任务，每次都检查 JSON 能否正常解析，然后记录：
- 整体耗时
- 首字延迟，也就是 TTFT
- 生成速度，也就是 tok/s
- 输出是否为合法 JSON
- 是否通过全部质量检查

最后取 3 次耗时的中位数，但这里有个重要说明，第 2、3 次会受益于 LM Studio 的提示词缓存，所以最终表格里的“记忆整理耗时”，代表模型常驻后的日常服务速度，不是每次都重新加载模型的冷启动速度。

最后评分项必须同时满足下面 9 项，才算满分：

1. JSON 数组中正好有 6 条记忆。
2. 保存了默认使用中文的偏好。
3. 保存了旧的 agent_browser 决定。
4. 旧决定状态为 superseded。
5. 保存了新的 opencli 决定，状态为 current。
6. 保存了每次最多处理 20 条的规则。
7. 保存了发布前必须确认的规则。
8. 保存了“被替代的旧决定也要保留”的偏好。
9. 没有保存天气和喝水。

这次三个模型连续 3 轮都通过了全部检查，所以表里写的是 3/3 满分。

长上下文测试

我又生成了一段长的项目日志，把下面这条信息藏在正中间：

关键长期事实：项目代号是青岚-7391，发布前必须由用户确认。

前后各重复 180 次下面这句干扰内容：

项目日志：本轮检查正常，没有新增长期决定；继续遵循既有流程。

最后只问模型：请只回答项目代号，不要解释
三个模型最终都回答了 青岚-7391
表格里的“长文首字”，记录的是模型从收到这段长文本，到吐出第一个 token 的时间。

测 RSS 峰值

这是我之前忽略掉的，古老师提醒后，所以在这次的评测中加入进来。
RSS 可以粗略理解为：进程当前真正驻留在物理内存里的大小。
通过 GPT 的帮助，我创建了一个脚本，使用以下流程进行采样：
1. 卸载全部模型。
2. 等推理进程完全退出。
3. 每 0.08 秒读取一次 macOS ps 的 RSS。
4. 先连续采样 10 次，得到 LM Studio 空载基线。
5. 开始加载模型，并持续采样。
6. 模型加载后空闲等待 1.5 秒。
7. 连续执行 3 轮记忆任务。
8. 执行一次长上下文任务。
9. 任务结束后再观察 0.8 秒。
10. 取整个过程中的最高值。

分别记录：
- 新启动的模型推理进程 RSS
- LM Studio 主进程及全部子进程的 RSS 总和
- 相比空载基线增加了多少 RSS

另外，RSS 相加可能重复计算进程间共享的内存页，因此这个数字适合横向比较模型，不等于系统可用内存的精确减少量。

最终结果

三个模型都正确提取了 6 条长期记忆，也都过滤掉了天气、喝水等临时信息。
所以这轮没有出现“谁更聪明”的明显分差，主要差距在速度和内存。

为什么 35B 反而比 12B 快？

因为 Qwen 35B-A3B 和 Gemma 26B-A4B 都是 MoE 模型。
名字里的 A3B、A4B，可以粗略理解为：虽然模型总参数很大，但每次推理只让其中一部分专家出来干活，而 Gemma 12B 则没有采用这种设计。
简单说：
35B 像一家有很多员工的大公司，但每次只叫 3B 左右的专家小组开会，所以它的知识容量更大，实际计算量却没有参数名看起来那么吓人。

三个模型怎么选？

• 只想选一个：Qwen3.6 35B-A3B MLX，这是我现在最推荐的默认模型。记忆整理约 2.64 秒，生成速度 78.1 tok/s，长上下文首字也最快。
  对于 Nowledge Mem 这类需要长期读取聊天、合并记忆、处理冲突的工具，它的综合体验最好。
  但它冷加载需要 11.55 秒。
  最好让模型常驻，不要每处理一条记忆就卸载一次。
• 经常加载和卸载：Gemma 4 26B-A4B MLX
  它的冷加载加记忆整理合计约 10.85 秒，反而比 Qwen 35B 的约 14.19 秒更省时间。
  生成速度也有 70.6 tok/s，和 Qwen 35B 的差距不大。
  如果你的记忆工具不会让模型常驻，我会优先选它。
• 32G < 内存 < 64G：Gemma 4 26B-A4B MLX 4bit
  和Qwen3.6 35B-A3B MLX性能差距不大，但如果遇到不同任务，Qwen3.6由于参与的专家更多，所以会占用更大的内容，因此 Gemma 4 26B-A4B 是较稳妥的选择
• 内存 <32G：Gemma 4 12B GGUF
  它的优势是省内存，LM Studio 全进程峰值约 10.65GiB，比两个大模型少了约 7GiB。
  如果是 16GB 或 24GB 的 Mac，或者你还要同时开浏览器、IDE、微信和一堆 Electron 应用，12B 会更稳妥

MLX 还是 GGUF？

这轮不能简单说“MLX 一定比 GGUF 快”，因为三个模型的架构不同，并不是同一权重的格式对照实验。
但有一个实际结论很清楚：
在 Apple Silicon 上，Gemma 26B-A4B 和 Qwen 35B-A3B 的 MLX 版本已经非常能打

• 如果只在 Mac 上使用，我会优先 MLX
• 如果还要把模型复制到 Windows、Linux 或其他 llama.cpp 工具里，再选 GGUF

最后

在以前，我一直以为参数更小的模型运行更快
这次实测却刚好相反：
- 12B 最省内存，但最慢
- 26B-A4B 和 35B-A3B 反而速度更快

当然，这只是一组固定提示词下的受控测试，不代表 Qwen3.6 35B 在所有问题上都一定更聪明
但至少在“本地记忆管理”这件事上，它现在是我这台 Mac 的最佳选择