4B 版本 因量化丢失指令理解能力，8B版本虽能调用工具但存在内容偏差。14B+就能正常对话了，本地小模型可用性在逐步上升，但我距离流畅交互还差一块 16G 显卡的距离?
听闻昨晚发布 qwen3 优化了模型的 Agent 和 代码能力，进而加强了对 MCP 的支持。
Qwen3：思深，行速
https://qwenlm.github.io/zh/blog/qwen3/
引言里面的这句话
小型MoE模型Qwen3-30B-A3B的激活参数数量是QwQ-32B 10%，表现更胜一筹，
`Qwen3-4B 这样的小模型也能匹敌 Qwen2.5-72B-Instruct 的性能`。让我很是兴奋了一把，于是下班回去在 nas服务器 用 Ollama pull 模型部署好，使用 cherry studio，启用 obsidian-mcp，开始测试，测试结果却啪啪打脸。
测试内容：
1. 查询我的 obsidian 知识库最近 1 天的改动，模型瞎回答
模型命中不了 tool。
1. 使用 obsidian 的 mcp 的 obsidian_get_recent_changes 工具，查询我的知识库最近 1 天的改动
我都提示工具名称了，模型还是瞎回答。
qwen3 模型
模型评测项说明
| ArenaHard | ||
| AIME'24 / '25 | ||
| LiveCodeBench | ||
| CodeForces（Elo Rating） | ||
| GPQA | ||
| LiveBench | ||
| BFCL | ||
| MultiIF（8 Languages） |
Obsidian-MCP
Obsidian-MCP 通常用于以下任务：
• 日志/笔记内容的语义检索与总结（嵌入 + 问答） • 自我对话（多轮历史上下文） • 任务建议、卡片联想等基于上下文的 " 思维增强 " • 私有知识库的记忆回调（streamable / SSE 模式长连接） • 本地嵌入 + 轻量推理，不依赖公网 LLM
这些任务主要要求：
• 指令遵循能力 • 上下文感知（少量上下文） • 中等推理能力 • 响应快，模型小，易部署
Obsidian API 工具列表
JSON 搜索获取周期笔记内容获取最近周期笔记列表获取最近修改的文件
测试 Qwen3-4B 能力是否匹配上述需求
qwen3:4b，吐字飞快，回答的水准也是高了，但是文不对题啊，连要调用 tool 都没识别出来。于是去看了下 hugging_face 的tokenizer_config.json模型配置,的确有
tool_call这一层啊，咋就不 working，难道是这个q4量化导致智商减退厉害?
以为我 nas 上 4b 的小 n 卡终于派上用场了，看来还得再等等。想再试试 8b 但是本地显存不够，下面换成
openrouter 的服务测试 8b,14b，30b 的。测试 Qwen3-8B 能力是否匹配上述需求
使用 cherryStudio 测试 qwen3:8b，是能够调用 tool，不过回答的有幻觉，返回的笔记名称都改了
Qwen3-4B-本地模型 + Obsidian-MCP的`本地问答`.md
回答成了
01Project/Blog/draft/Qwen3-4B-本地模型 + Obsidian-MCP的`本地问题`.md这个时候笔记使用
git 同步的优越性就出来了，本地使用 mcp 对笔记进行整理时，如果出现错误，可随时回滚到上次提交的版本！
那这 8B 基本只能闲聊，在我这个场景属于中看不中用
测试 Qwen3-14B 能力是否匹配上述需求
使用 openrouter 的 qwen3:14b 模型进行测试
看着不错，能正常返回结果。
但想深入测试内容却报 token 不足。按官方数据，
qwen3:14b模型的最大 token 是128K，15 万字，我想这足够分析一篇笔记了。但是我测试的时候，让读取笔记内容进行总结，却提示 token 超过 40k 了，不知道为啥？
从这段报错可以明确看出：
模型当前上下文限制为：40960 tokens➤ 超限。
判断是 openRouter 自家部署时的限制。换成通义官方的 qwen3-demo：
https://huggingface.co/spaces/Qwen/Qwen3-Demo
测试下来同样的文本，是可以正常总结的，128k 的 token 数是足够的，那看来 8B,14B，32B 还是能在本地派上用成。
结论
使用 Qwen3 与 Obsidian-MCP 的知识库交互测试得出结论：
4B 版本：量化压缩导致失语
• 工具调用能力完全丢失，面对明确的 obsidian_get_recent_changes指令无动于衷• token 容量 32K，长会话可能难以完整处理
8B 版本：看似能用实则危险
• 虽能识别工具调用，但返回的文件路径存在较高的错误率； • 内容总结时出现 幻觉改写，笔记名会被修改；• 如果 MCP 调用 API 出现误删除，又没有 git 备份会更危险
14B+ 版本：真香警告
• 128K token 容量完美适配知识库场景，测试中准确调用 Obsidian API • 但本地部署需 16G 显存，让多数 NAS 用户望而却步
在我的 16G 显卡到来前，要注意做好隐私保护，先通过云端大模型 +MCP，读取非敏感数据目录作为问答的上下文。
毕竟，做技术的驾驭者，要懂得 在现实约束中寻找最优解。
