转载说明：本文经作者授权，转载自 Versun（@VersunPan）发表于 X 的实测文章《给 AI 装“记忆大脑”，Gemma 12B、26B 和 Qwen 35B 谁更适合？结果有点反常》。测试数据、结论与第一人称经验均来自原作者；Nowledge Labs 仅做格式整理、术语统一与文档链接补充。阅读原文
一句话答案
模型常驻时选 Qwen3.6 35B-A3B；每次按需加载选 Gemma 4 26B-A4B；先给浏览器和 IDE 留内存，就选 Gemma 4 12B。
选择指南
别按参数量选，先看模型会不会常驻。
反常之处在取舍：12B 少占约 7 GiB，热态任务却慢了约 2.8 倍；26B 与 35B 的 RSS 和热态耗时几乎相同，真正拉开选择的是冷加载策略。
- 保持常驻
Qwen3.6 35B-A3B MLX
在这台 64 GB Mac 上，热态任务和生成速度最快。
- 2.64 秒 · 78.1 tok/s
- 按需加载
Gemma 4 26B-A4B MLX
每次冷启动时，总等待低于 Qwen 的 14.19 秒。
- 加载 + 任务 10.85 秒
- 节省内存
Gemma 4 12B GGUF
比两个大模型少约 7 GiB，但热态任务较慢，需要 7.38 秒。
- 总 RSS 10.65 GiB
三个模型只是在同一套固定九项记忆任务中连续三轮得到 3/3，不能据此推断通用质量相同。16/24/32 GB 建议来自这台 64 GB 机器的 RSS 数据，并非对应机型实测。
为什么现在重测本地模型
Nowledge Mem 从一开始就是 Local First。早期版本可以完全依靠 App 内置的小模型处理记忆。0.5 之后，Mem 开始持续整理对话、合并变化、处理冲突，也要服务 Background Intelligence、AI Now 和 Timeline。任务更长、更复杂，内置 4B 模型逐渐不够用，订阅服务或 BYOK 成了很多人的日常选择。
从 0.10 开始，本地运行时从早期的 M1 Mac 扩展到桌面端与 Linux headless；官方 Docker 镜像提供 CPU、CUDA 和 Vulkan 版本。内置多模态模型的视觉能力也已经用于 Library 文档解析。App 之外，Mem 还支持 Lemonade、Ollama 和 LM Studio；社区贡献者 abn 完成了 Lemonade 集成中的大量工作。
Versun 没有跑通用排行榜。他直接用 Nowledge Mem 的记忆整理、更新、噪声过滤和长上下文任务，回答一个更具体的问题：今天要长期用本地模型，质量、等待时间和内存应该怎么取舍？
为什么我要给 Nowledge Mem 换成本地模型？
最近我把 Nowledge Mem 的记忆处理从云端模型换到了本地模型。原因很简单：我经常订阅不同的 token plan，导致给 Mem 配置的模型提供商很不稳定。token 经常用完，然后 Mem 的智能处理就停了，有时候好几天才发现。
所以我决定改用本地模型，不再担心额度问题。但哪个本地模型更适合 Nowledge Mem？
先说测试环境：
- Mac mini，M4 Pro，64 GB 统一内存
- LM Studio
0.4.19+2 - GGUF Runtime：llama.cpp
2.25.2 - MLX Runtime：
1.10.1
在这轮完整测试前，我还做过一轮初步对比。Nowledge Labs 的 Wey 看到后，也在讨论线程里追问了上下文、内存与整理过程，才有了这次更完整的测试。
基础测试
首先固定所有测试参数：
- 上下文长度：32,768 token
- Temperature：0
- Top P：1
- Thinking / Reasoning：关闭
- GPU Offload：最大
- 并发请求：1
- 模型并行槽位：默认 4
- 最大输出：700 token
统一的系统提示词：
你是长期记忆整理器。只保留未来仍然有用的信息；区分临时闲聊、旧信息和当前信息；不得把临时天气、情绪或一次性寒暄保存为长期记忆。严格按用户要求输出 JSON，不要 Markdown。
测试场景包括：
- 从聊天中提取长期记忆
- 正确区分新记忆和旧记忆
- 把旧记忆标成
superseded - 把新记忆标成
current - 不把“今天天气很热”“刚喝了一杯水”存进长期记忆
- 连续三次输出合法 JSON
测试提示词如下：
请从下面对话中整理长期记忆。
对话：
用户：我主要使用中文沟通。
用户：以前 AI Builders Digest 使用 agent_browser 后端。
用户：从今天开始，正式改用 opencli，agent_browser 不再作为当前后端。
用户：自动化任务每次最多处理 20 条内容。
用户：任何发布或对外发送动作必须先征得我的确认。
用户：我希望记忆整理时保留被新决定替代的旧决定，并明确标为 superseded。
用户：今天天气真热。
用户：刚才喝了一杯水。
返回一个 JSON 数组，每项必须且只能包含：
{"memory":"简洁记忆内容","status":"current 或 superseded","kind":"preference、decision 或 rule"}这条提示词测了四件事：
- 提取：能不能找全六条长期信息——中文偏好、旧后端、新后端、每次最多 20 条、发布前确认、保留旧决定的整理偏好。
- 更新：能不能识别
opencli已经替代agent_browser。 - 保留历史：旧决定不能直接消失，而要标成
superseded。 - 过滤噪声：天气和喝水不能混进长期记忆。
每个模型连续执行三次完全相同的任务。每次都检查 JSON 能否正常解析，并记录整体耗时、首字延迟（TTFT）、生成速度、JSON 合法性和质量检查结果。
最后取三次耗时的中位数。这里有个重要说明：第二、三次会受益于 LM Studio 的提示词缓存，所以表格里的“记忆整理耗时”代表模型常驻后的日常服务速度，不是每次重新加载模型的冷启动速度。
要拿到满分，输出必须同时满足九项检查：
- JSON 数组里正好有六条记忆。
- 保存了默认使用中文的偏好。
- 保存了旧的
agent_browser决定。 - 旧决定状态是
superseded。 - 保存了新的
opencli决定，而且状态是current。 - 保存了每次最多处理 20 条的规则。
- 保存了发布前必须确认的规则。
- 保存了“被替代的旧决定也要保留”的偏好。
- 没有保存天气和喝水。
三个模型在这套固定提示词上连续三轮都通过了全部检查，所以最终都是 3/3。这个结果只说明它们通过了这一个受控任务，不能推断三者的通用质量相同。
长上下文测试
我又生成了一段很长的项目日志，把下面这条信息藏在正中间：
关键长期事实：项目代号是青岚-7391，发布前必须由用户确认。
前后各重复 180 次这句干扰内容：
项目日志：本轮检查正常，没有新增长期决定；继续遵循既有流程。
最后只问模型：“请只回答项目代号，不要解释。”三个模型都回答了“青岚-7391”。表格里的“长文首字”，就是模型收到整段长文本后吐出第一个 token 的时间。
测 RSS 峰值
RSS 可以粗略理解为进程当时真正驻留在物理内存里的大小。这次用脚本按下面的流程采样：
- 卸载全部模型。
- 等推理进程完全退出。
- 每 0.08 秒读取一次 macOS
ps的 RSS。 - 先连续采样 10 次，得到 LM Studio 空载基线。
- 开始加载模型并持续采样。
- 模型加载后空闲等待 1.5 秒。
- 连续执行三轮记忆任务。
- 执行一次长上下文任务。
- 任务结束后再观察 0.8 秒。
- 取整个过程中的最高值。
分别记录新启动的模型推理进程 RSS、LM Studio 主进程和全部子进程的 RSS 总和，以及相对空载基线增加的 RSS。
RSS 相加可能重复计算进程间共享的内存页，因此这个数字适合横向比较模型，不等于系统可用内存的精确减少量。
最终结果
| 模型 | 磁盘大小 | 冷加载 | 记忆整理 | 生成速度 | 长文首字 | 模型 RSS 峰值 | LM Studio 总 RSS 峰值 | 质量 |
|---|---|---|---|---|---|---|---|---|
| Gemma 4 12B GGUF | 7.15 GB | 3.82 s | 7.38 s | 29.4 tok/s | 36.79 s | 9.33 GiB | 10.65 GiB | 3/3 |
| Gemma 4 26B-A4B MLX | 15.64 GB | 8.17 s | 2.68 s | 70.6 tok/s | 13.83 s | 16.38 GiB | 17.69 GiB | 3/3 |
| Qwen3.6 35B-A3B MLX | 20.43 GB | 11.55 s | 2.64 s | 78.1 tok/s | 9.87 s | 16.42 GiB | 17.72 GiB | 3/3 |
三个模型都正确提取了六条长期记忆，也都过滤掉了天气、喝水等临时信息。因此这轮没有出现“谁更聪明”的明显分差，主要差距在速度和内存。
为什么 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。如果记忆工具不会让模型常驻，我会优先选它。
- **基于 RSS 推断，32 GB 到 64 GB：Gemma 4 26B-A4B MLX 4-bit。**它和 Qwen3.6 35B-A3B 的热态性能接近，但不同任务可能激活更多 Qwen 专家，因此 26B-A4B 是较保守的选择。这轮没有在 32 GB 机器上直接测试。
- **基于 RSS 推断，低于 32 GB：Gemma 4 12B GGUF。**LM Studio 全进程峰值约 10.65 GiB，比两个大模型少约 7 GiB。如果还要同时运行浏览器、IDE、微信和其他桌面应用，12B 会留下更多余量。这轮也没有在 16 GB 或 24 GB 机器上直接测试。
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 的最佳选择。
Nowledge Labs 的展望
这次实测给的是今天的答案，不是永久结论。我们期待 4B 左右的模型有一天能再次覆盖记忆整理、变化合并、冲突处理和背景智能，但目前没有时间表，也不能从这组三模型测试推出这个结果。
本地多模态链路已经用视觉能力处理 Library 文档。PII 过滤和音频会议处理仍是后续方向，不属于本次 benchmark 的已交付或已验证范围。
如果你也准备把模型请求留在自己的设备上，可以继续阅读 Nowledge Mem 文档：用完全本地的模型运行 Nowledge Mem。
原始讨论：