企业官网建设流程全解析

MemPalace 小模型评估报告全解：75 组本地矩阵跑分、云模型上限测量与幻觉率评分伪影

【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And it's free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalace

本文解读 MemPalace 仓库中 2026-05-10 小模型评估分析报告 的完整结论：15 个候选模型在 5 个任务/模式组合下的 75 组本地跑分、两轮云模型上限测量、开放集发现功能的"不发布"裁定，以及一次基于源码核验的"幻觉率是评分伪影"调查。读完后你能掌握 MemPalace 如何为生产分类器做数据驱动的模型选型，如何用 benchmarks/model_eval 工具链在自己的硬件上复现全部数字，并理解各指标的统计含义与适用边界。

实验背景与测试矩阵

这轮评估在z690-ex-glacial（Intel i9-12900KF + RTX 3090 24GB + Ollama 0.23.2）上完成首轮全矩阵：15 个候选模型 × 5 个任务/模式组合 = 75 次运行，耗时 61.8 分钟，仅出现 1 次瞬态预热超时。原始数据见 2026-05-10-z690-ex-glacial.csv，自动渲染的表格见 2026-05-10-z690-ex-glacial.md，而该分析报告是人写成的对数字的解读。

评估矩阵的候选模型与分层定义都集中在 candidates.yaml 中：

• Tier 1：必须评估的均衡集合（q4_K_M 量化、跨家族各 3~4B），例如qwen3:4b-instruct-2507-q4_K_M、gemma3:4b-it-q4_K_M、llama3.2:3b-instruct-q4_K_M；
• Tier 2：显存受限用户的小规格（qwen3:1.7b、qwen2.5:1.5b等）；
• Tier 3：FP16 上限等特殊情况（qwen3:4b-instruct-2507-fp16）；
• cloud：Ollama 托管的参考上限模型（20B~1T 参数），用于测量本地最优与"大 100 倍模型能做到的水平"之间的差距；
• modern / community：首轮搜索遗漏的新一代模型（Gemma 4、Granite 4.1、Ministral 3、Qwen 3.5）与第三方微调。

配置文件里还写明了两条方法论约束：纯推理变体按策略排除（MemPalace 分类任务一律关闭 thinking）；云模型仅用于测量上限，不代表生产推荐——隐私与成本权衡下本地模型仍是默认。

评测的四类任务与指标

根据 benchmarks/model_eval/README.md，每个(model, task, mode)三元组记录：任务相关准确率、TTFT（首 token 时间）、TPS（每秒 token 数）、e2e 延迟（p50/p95）、VRAM resident（从 Ollama/api/ps读取的模型常驻显存）与 VRAM peak（nvidia-smi每 500ms 轮询的峰值）。每个模型的第一次运行被丢弃（缓存 + GPU 升频），保证统计干净。

数据集全部为合成数据（不含真实个人信息），生成一次后冻结，保证跨次运行数字可比。

一个值得注意的实现细节：harness 走的是生产同款代码路径——mempalace.llm_client.get_provider("ollama", model=tag)+provider.classify(...)，没有任何重新实现的 HTTP 层。在 runner.py 中可以看到_classify_with_timing()对每次调用都强制think=False，让带混合推理能力的 Qwen 3 模型保持快速分类模式；open 集与记忆抽取两个语义评分任务则依赖 embedding 模型计算相似度，runner 在缺模型时会自动ollama pull。

复现命令

报告给出了完整的复现流程：

# 拉取所有候选模型（100 Mbit 连接约 7 分钟） for m in $(grep -E "^ - tag:" benchmarks/model_eval/candidates.yaml | awk '{print $3}'); do ollama pull "$m" done ollama pull nomic-embed-text # 跑矩阵（RTX 3090 约 60 分钟） python -m benchmarks.model_eval.orchestrator \ --candidates all --tasks all \ --dataset-dir benchmarks/model_eval/datasets \ --output benchmarks/model_eval/results/$(date -u +%Y-%m-%d)-$(hostname).csv # 渲染报告 python -m benchmarks.model_eval.summarize \ --csv benchmarks/model_eval/results/$(date -u +%Y-%m-%d)-$(hostname).csv \ --output benchmarks/model_eval/reports/$(date -u +%Y-%m-%d)-$(hostname).md

orchestrator 支持--candidates tier1|local|cloud|modern|<精确 tag>等分层过滤，--n 30可截断样本数控制云成本；CSV 是增量写入，中途 Ctrl-C 安全。README 给出的验收基线：准确率应在基线 ±1% 内，速度数字因 GPU、驱动、热状态不可跨机比较，VRAM resident 在同 Ollama 版本下应基本一致。

头号结论：qwen3:4b-instruct-2507 是最优小模型

原始 CSV 中的关键行可以印证报告的头条结论（qwen3:4b-instruct-2507-q4_K_M一行）：闭集房间分类 0.61、开放集相似度 0.586、实体 F1 0.778、记忆覆盖 0.95、calibration 0.95，闭集 e2e p50 仅 109 ms，常驻显存 7481 MB。

qwen3:4b-instruct-2507-q4_K_M在我们测量的每个任务上都是最好的小模型——calibration、闭集房间分类、实体抽取、记忆抽取全部第一或并列第一，代价是 7.5 GB 常驻显存、calibration 亚 100ms p50、最重的实体抽取任务 624 ms p50。

量化维度上，q4_K_M 扛住了与 q8_0 乃至 fp16 的对比：实体 F1 上 q4_K_M 以 0.778 对 0.772 微胜 fp16（噪声范围内）；其余任务与 fp16 上限差距都在 0.01~0.02。结论是：只有当任务把模型逼到极限时才值得为 VRAM 付费，q4_K_M 是正确的默认。

各任务冠军一览：

报告推荐的生产分层清单

报告给出的核心落地建议是更新MODEL_TIERS（报告写作时指向mempalace/local_model.py；当前仓库树中无此文件名，最接近的功能模块是零网络房间检测 room_detector_local.py 与 llm_client.py 中的 provider 抽象）。报告建议替换为：

MODEL_TIERS = [ # Tier 1 — Best balance of speed/quality (instruct-tuned) (r"qwen3:4b-instruct-2507", 100), (r"gemma3:4b-it-q4_K_M", 88), (r"gemma3:4b-it-qat", 87), (r"qwen2\.5:3b-instruct", 82), # Tier 2 — Fast but lower accuracy on hard tasks (r"llama3\.2:3b-instruct", 70), (r"phi3\.5:3\.8b-mini-instruct", 68), (r"qwen2\.5:1\.5b-instruct", 55), # Tier 3 — Fallback only (r"gemma3:1b-it", 45), (r"llama3\.2:1b-instruct", 40), (r"qwen2\.5:0\.5b-instruct", 30), # Reasoning-default tags below dedicated instruct variants. Picked # only as a last resort. The runner forces think=False on every # call, so even when these match they run in fast-classification # mode rather than reasoning mode. (r"qwen3:4b", 25), ]

相对旧清单的四处改动及依据：

1. 删掉qwen3\.5:4b和qwen3:3b模式：Ollama 上不存在这两个精确 tag，属于永远不会命中的臆测条目（后续 modern 轮用真实存在的qwen3.5:4b验证了这一点——新版并未赢过旧版，见下节）；
2. 删掉 Tier 2 的qwen3:1\.7b与qwen3:0\.6b：实体抽取 F1 分别只有 0.31 和 0.48（CSV 可查：1.7b 的 mean_precision 0.67 / mean_recall 0.23，纯靠低召回撑高分精确率），记忆覆盖尚可（0.84/0.74）但小号的类型精度差，不值得推荐；
3. 删掉 Tier 3 的gemma2:2b、phi3:mini、tinyllama：不在本轮测试矩阵里，没测过就先下架；
4. qwen3:4b通用 tag 从 30 降到 25：runner 端think=False让它即使被匹配到也跑在快速分类模式，但它在每个任务上仍输于显式 instruct 版本，理应垫底。

第二轮与第三轮：现代模型与云上限

首轮落地后做了两次追加检查：可复现性抽查（重跑qwen3:4b-instruct-2507-q4_K_M全任务集，各指标偏差 ≤0.7%——room-closed 0.610→0.604、room-open 0.586→0.584、实体 F1 0.778→0.771、记忆覆盖 0.950→0.950、calibration 0.950→0.950，确认 harness 可靠、单轮精度数字可信）；幻觉率调查（见"评分伪影"一节）；云上限测量（n=30，原始数据 2026-05-10-cloud-z690-ex-glacial.csv 为 v1、2026-05-11-cloud-z690-ex-glacial.csv 为 v2，全部数字均可在 CSV 中逐行核对）。

第三轮（2026-05-11）补测了首轮搜索遗漏的五个本地家族granite4.1:3b、gemma4:e2b、gemma4:e4b、ministral-3:3b、qwen3.5:4b，数据见 2026-05-11-modern-z690-ex-glacial.csv，有三个值得单独提出的发现：

1. gemma4:e4b-it-q4_K_M成为新的本地房间分类冠军：闭集 0.624（超过 qwen3:4b 的 0.610），开放集0.653——所有被测模型（本地与云）中的最高分，云模型开放集上限是 0.61。一个 4B 本地模型超过了 1T 参数的云参考。代价是 230 ms p50（qwen3:4b 为 109 ms，2.1 倍慢）和 10.6 GB 常驻（7.5 GB 的 1.4 倍）；
2. ministral-3:3b记忆覆盖 0.99（实测 0.9875，接近云的 1.00），但闭集只有 0.49、实体 F1 0.63——只适合"记忆是主任务"的场景；
3. qwen3.5:4b-q4_K_M打不过qwen3:4b-instruct-2507：实体 F1 略好（0.79 vs 0.78），记忆覆盖差（0.85 vs 0.95）、闭集差（0.59 vs 0.61）。版本号升级在这个负载上没有收益——这也印证了"newer ≠ better"的选型原则。

对生产清单的净影响：房间分类（主用例）新推荐默认是gemma4:e4b-it-q4_K_M；紧显存硬件的通用抽取仍选qwen3:4b-instruct-2507-q4_K_M；开放集发现功能从"无限期搁置"放宽为"先用 gemma4:e4b + 提示词调优重测再下死刑"——距 0.70 发布阈值的差距从 0.09 缩到 0.05。

云模型两轮结果（v2 完整表）

v1 五个候选（kimi-k2:1t-cloud全任务 HTTP 500）；v2 更新阵容（kimi-k2:1t-cloud已被kimi-k2.6:cloud取代，并加入 DeepSeek V4 Flash/Pro），7 个候选全部成功：

闭集房间分类：真实的天花板差距

云模型明显更强：qwen3-coder:480b 与 gpt-oss:20b 达到 0.897~0.900，对本地 0.610，绝对差约 30 分、相对差 47%。这是目前支持提供mempalace mine --classifier cloud选项的最强论据——面向能接受隐私与成本权衡的高价值归档用户。对默认场景（隐私优先、无需 API key），本地仍是正确选择。

一个有趣观察：gpt-oss:20b 在该任务上追平 qwen3-coder:480b，尽管参数只有 1/24——从结果推断，qwen3-coder 的代码特化对自然语言分类既不是优势也不是拖累。

开放集发现：上限被两轮云测量证伪

第一轮云上限 0.587（qwen3-coder:480b）；DeepSeek V4 略微抬高：v4-flash 0.607、v4-pro 0.605。仍低于本地最佳 0.612（gemma3:4b-it），仍远低于 0.70 发布阈值。两轮合计，所有云候选开放集都在 0.55~0.61，本地候选 0.46~0.61，同一个区间。模型类别整体进入平台期：4B、284B、480B、671B、1T MoE 全部收敛到相同的 0.55~0.61 余弦相似度区间。

这不是模型规模问题，而是任务表述问题：模型必须自创一个与人工选定"preferred"标签语义对齐的开放词表标签，本质是风格对齐问题，加算力跨不过去。结论：--mode discover功能搁置，用户自定义房间列表的闭集分类仍是唯一路径。值得探索的两条路（都是研究项目而非调参）：更好的提示词（few-shot 示例或约束词表）；两遍聚类（小模型先标注、再聚类合并近义项）。在此之前，闭集要求不变——但如前所述，gemma4:e4b 的 0.65 已把差距缩到 0.05，重测优先。

实体抽取与记忆抽取：云略优但无决定性

gpt-oss:120b（0.829）与 deepseek-v3.1:671b（0.828）领先，本地 qwen3:4b 0.778——差距真实但温和，常规使用本地够用。记忆覆盖上 gpt-oss:20b 与 120b 在 n=30 都打出 1.000，qwen3-coder 与 DeepSeek 0.967，本地 0.950，云帮助有限。calibration 任务在所有强模型间已饱和（0.90~0.95），只剩 sanity check 价值。

延迟与成本观察

• 推理基础设施效率因模型而异，不只因规模：qwen3-coder:480b 是云端最快选项（闭集 599 ms p50），尽管比 gpt-oss:120b（1656 ms）大 4 倍；deepseek-v3.1:671b 735 ms 同样快于 gpt-oss:120b。对本地 4B 的 109 ms，云慢 5~15 倍（含网络 RTT）——交互场景要命，批量挖掘历史归档无所谓；
• gpt-oss 系列即使请求体里think: false仍持续生成推理 token（作者用 curl 直接验证过）。harness 只提取干净的content字段，但云推理时长与配额消耗包含被要求跳过的推理生成。作者建议对 Ollama Cloud 的上游think: false支持提 issue；在此之前，云延迟数字应视为上界；
• Ollama Cloud 不强制结构化输出（这是真实发现，依据 Ollama 官方文档）：harness 发送的format: json在云请求上被静默忽略。云模型"恰好"输出合法 JSON 是因为其默认行为恰好是 JSON 形状，而非平台强制。这解释了 K2.6 记忆抽取valid_json_rate: 0.367——其余 63% 的响应是 markdown 代码围栏、散文前言或别的 schema，那个 0.367"覆盖率"实际是"JSON 解析率 × 单样本覆盖"，不能与其他模型的质量分直接比较。其他六个云候选 100% valid_json_rate 属于"运气好默认输出就是 JSON 形状"，同样脆弱；
• 云可复现性差于本地：v1→v2 重跑 4 个共有候选出现漂移——gpt-oss:20b 闭集 0.833→0.897（+0.064），gpt-oss:120b 0.800→0.767（-0.033），qwen3-coder 与 deepseek-v3.1 稳定为 0。6.4 分跳变远超本地 temperature=0.1 的 ±0.7% 噪声底，可能原因是云端模型权重静默轮换、服务端负载影响非确定性、或 n=30 切片受模型侧缓存状态影响。方法论结论：本地数字报点估计（±0.7% 可复现），云数字必须报区间——"cloud-best 闭集 0.83~0.90，local-best 0.61"。

意外发现与异常分析

q4_K_M 在实体 F1 上击败 fp16

0.778 vs 0.772，远在轮次噪声之内，但该任务上量化没有任何质量悬崖：q4_K_M 下载 2.5 GB、常驻 7.5 GB，fp16 是 8.1 GB / 13.2 GB——同等精度，一半内存。

0.36"幻觉率"是评分方法伪影，不是模型弱点

初读数据：qwen3:4b 记忆覆盖 0.95 却有 0.36 的预测不匹配任何标注记忆（qwen2.5:3b 为 0.00，gemma3:4b 0.19），看起来模型"过于热衷"。作者对 5 个代表性样本做了人工并列核查（预测 vs 源文本 vs 标注），结论反转：

• 把捆绑记忆拆成原子项：mem_006的标注是一条捆绑记忆（"不再用 NPK + 改用堆肥 + 今年秋天开始"），qwen3:4b 输出两条：决策 + 时间承诺，两者都在源文本里。标注时合、模型时拆，两边都没错；
• 抓到标注遗漏的承诺：mem_001标注只列了 cosine-to-Jaccard 决策，qwen3:4b 还抽出了"明天重跑基准"——字面就在源文本中。是标注遗漏，不是幻觉；
• 把捆绑事实拆成原子事实：mem_013两条标注记忆被拆成三条原子项，全部可回溯到源文本。

对照组更有说服力：qwen2.5:3b 在同样样本上是欠抽取——它"0.00 幻觉"是因为每条样本只出一条记忆，经常整条漏掉第二条真值（mem_021漏"重构大纲"承诺、mem_031漏"AR 查询走邮件"决策）。

指标本身在说谎。回看 score.py 的实现可以精确定位机制：scorer 把预测与真值逐条嵌入后做贪心一对一匹配（similarity_threshold=0.6，先占先得），然后

coverage = len(matched_truth_indices) / len(truth) hallucination_rate = (len(pred) - len(matched_pred_indices)) / max(1, len(pred))

当模型产出比真值更细粒度的抽取（对记忆抽取而言是正确行为）时，多出来的预测项找不到可配对的真值，全被计为"幻觉"。作者把 0.36 拆解开看：真幻觉（预测但源文本没有）估计 <5%（需独立 scorer 确认）；粒度分歧约占一半（一条真值捆绑拆成 N 条预测）；标注遗漏约 30%（预测在源文本里，标注者漏了）。

对选型的净效应：qwen3:4b-instruct-2507-q4_K_M维持推荐——0.95 覆盖才是真信号，模型选型的临时准则是"信mean_coverage，忽略mean_hallucination_rate"。后续修复方案（跟进 PR）：(a) 把预测与源文本也做嵌入匹配，"匹配源但不匹配真值"改判为标注遗漏而非幻觉；或 (b) 把coverage、granularity_factor（预测/真值数量比）、source_traceability拆成三个独立指标不再合并。

速度冠军 phi3.5:3.8b 与 VRAM 异常

phi3.5:3.8b-mini-instructcalibration p50 仅 30 ms，比 qwen3:4b 快 2.8 倍（推测与其量化布局激进的批处理有关），但代价写在 CSV 里：常驻 16.6 GB（4B 级最高）、闭集房间 0.47、实体 F1 0.64。适合"延迟主导、精度宽容"的利基场景，不适合做默认。

其余异常

• gemma3:4b-it 家族赢开放集：q4_K_M 与 qat 都是 0.612，超过 qwen3 家族。推测 Gemma 训练语料含更多"按约定命名"的样本，自创 slug 时更守常规。若开放集功能某天发布，起点应是 gemma3:4b-it 而非 qwen3；
• 小参数 Qwen 3 低于同尺寸级：qwen3:1.7b/qwen3:0.6b实体 F1 0.31/0.48，高精确率低召回（P/R 0.67/0.23 与 0.57/0.47）——抽得不够多。同参数量的 Qwen 2.5 1.5B 反而 F1 0.37 更高。可能是 JSON 模式提示词 + think=False 与微型混合模型的交互伪影，建议任何 sub-3B Qwen 3 变体先调查再推荐；
• llama3.2:3b 的 p95 悬崖：calibration p50 92 ms，p95 5050 ms（55 倍离群，CSV 中 ttft_p95 5029 ms、e2e_p95 5050 ms 可查）——单个样本冷启动或被中途重新调度。不改变分层（它本来不在 Tier 1），但标记待重跑确认；
• gemma3:270m 基本不可用：calibration 5%（5 类里比随机还差）、闭集 12%、开放集 38%、记忆覆盖 2.5%。指令遵循不够，任何任务都撑不住——应从分层清单移到文档"勿用"行。

VRAM 观察

峰值 VRAM 列波动剧烈，因为它反映测量瞬间 GPU 上发生的一切（包括 Ollama 正在拉起下一个模型），resident 才是可靠数字。按常驻显存分档：270m/0.5B~1B 级 1~4 GB；1.5B~3B 级 2.5~7 GB；4B 级 q4_K_M 4.7~7.5 GB、q8_0 9.3 GB、fp16 13.2 GB。由此得出部署指引：24 GB 卡单跑任何 4B 模型都从容；16 GB 卡上 q4_K_M 是唯一务实的 4B 选项；8 GB 卡落在 1.5B~3B 区间。Phi-3.5 的 16.6 GB 常驻对 3.8B 模型明显异常（可能是不同的 KV cache 策略），值得为紧显存用户单独写进部署文档。

后续计划与方法论要点

报告按优先级列出后续动作，值得作为"评估如何驱动产品决策"的案例阅读：

1. 把MODEL_TIERS更新为推荐清单（数据已支持，注释指向本报告）；
2. 在第二台机器（如 16 GB 卡）上跑 Tier 1 子集，确认精度数字可跨硬件迁移——速度不可迁移，精度应在 1~2% 内；
3. 用更大的参考模型（qwen3:30b-cloud或gpt-oss:20b-cloud）探索开放集发现，小模型的 0.612 上限不排除大模型可发布 discover；
4. 调查 qwen3:4b q4_K_M 的记忆幻觉率（收紧提示词或加抽取后过滤）；
5. 重跑 llama3.2:3b calibration 确认 p95 悬崖；
6. 条件允许时补测phi-4-mini、nemotron-mini（两者带函数调用调优，可能利好实体/记忆任务）。

最后把整份报告的方法论约束浓缩为三条，这也是 benchmarks/model_eval/README.md 中"维护者须知"的原文要旨：

• format: json本地强制、云端忽略，云模型输出 JSON 是默认行为使然，K2.6 的valid_json_rate: 0.37就是文档化的表现；
• 记忆抽取的hallucination_rate指标过度惩罚细致模型（见上文源码分析），模型选型期信mean_coverage；
• 云可复现性差于本地（gpt-oss:20b 单次漂移约 6 分），云数字报区间、本地数字报点估计。

这套 harness 用真实生产代码路径（llm_client.py 的get_provider+classify）、冻结的合成数据集与逐行留存的 CSV，把"选哪个小模型"从凭感觉变成了可复现的数据问题——而分析报告中每一次"反直觉数字"（幻觉率、云漂移、p95 悬崖）都指向了评分器或基础设施的可定位原因，这正是它作为工程评估范本的价值所在。

【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And it's free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalace