小模型小测评：MiniCPM5-2B、Spark-X2.5-4B、Qwen3.5-9B 蒸馏版

在先前的 讯飞 Spark-X2.5 测试 过后，官方推出了量化版本 GGUF，llama.cpp 也更新了相关架构。昨天，面壁智能发布了 MiniCPM5-2B 。此外，虽然 Qwen3.5-9B 已经出局了，但 有网友 让我也测一下民间做的 claude-opus-4.6 蒸馏版。所以就放到一起简单品鉴一下吧。

基础配置

所有模型都在 Windows 端 LM Studio 运行（利用其自带的API功能向外部开放），显卡为 RTX 5070 Ti 16GB。更新最新 CUDA 12 llama.cpp 运行时（v2.34.0）以支持 Spark-X2.5-4B 架构（不用自己编译了）。之后每道题都连续测 3 次，记录结果。

MiniCPM5-2B：FP16 原版，测试上下文为 131,072，显存占用 7.55 GB。已经是最高上下文。
Spark-X2.5-4B：Q4_K_M 量化，测试上下文为 131,072，显存占用 8.11 GB。上下文最高 1,048,576，此时显存预估 47.03 G。
Qwen3.5-9B 蒸馏版：Q4_K_M 量化，测试上下文为 131,072，显存占用 11.86GB。上下文最高 262,144，此时显存预估 16.8 G。此模型支持视觉，本次测试不涉及。

测试 1：普通对话

先来测一下曾经大模型都容易翻车的问题：

9.11和9.9谁大？
strawberrrry中有几个r？

MiniCPM5-2B：

省流：9.9 对了2道，strawberrrry 对了2道 （点击了解更多详细信息）

Spark-X2.5-4B：

省流：9.9 对了2道，strawberrrry 对了0道 （点击了解更多详细信息）

Qwen3.5-9B 蒸馏版：

省流：9.9 对了3道，strawberrrry 对了3道 （点击了解更多详细信息）

测试 2：新闻搜集汇总

对我而言，小模型最可能的场景是知识库管理。所以这次依旧在佬友制作的 Obsidian YOLO 插件 里测试。提示词相比上次再升级了一下：

帮我搜索一下今天全球最新的中文AI新闻，选择5条作为精选新闻。要核对是不是确实是今天的新闻，如果不是要重新搜索。然后，利用网络工具读取新闻原文全文。最后，在仓库新建 news-test 目录、下面再以今天日期命名一个子文件夹，用分别的文件记录这些新闻，文件名格式为“序号_短标题.md”。每个文件都要有新闻的摘要、日期、关键词、原文、消息来源链接。

每次测完都会把新建的目录删掉，保证仓库不变。搜索引擎接的是智谱搜狗版，因为腾讯新闻网页抓取出问题的概率少一点。虽然有一定随机性，但模型能否应对应该也是能力的一环。

MiniCPM5-2B：

第1次：写入了一个没有后缀名的文件，然后卡死了 （点击了解更多详细信息） 第2次：大方向上对了，但没有读全文，还是写了一个没有后缀名的文件，然后每个子文件都把全局的信息重复了一遍 （点击了解更多详细信息） 第3次：先写入没有后缀名的文件，然后试图把它当文件夹再写入 （点击了解更多详细信息）

Spark-X2.5-4B：

第1次：大方向对了，甚至还会用任务清单。不过时间较长，只有一篇正确写入了原文 （点击了解更多详细信息） 第2次：和上一次差不多，有两篇正确写入了原文，还有一篇被标题中的“/”坑了 （点击了解更多详细信息） 第3次：写到没有后缀名的文件里去了 （点击了解更多详细信息）

Qwen3.5-9B 蒸馏版：

第1次：基本对了，除了读全文碰壁以后就放弃 （点击了解更多详细信息） 第2次：没有按照要求分文件写入，读了一个总结的新闻就以为读了原文 （点击了解更多详细信息） 第3次：没有按照要求分文件写入，两篇写入了原文 （点击了解更多详细信息）

测试 3：编程处理文字工作

在 opencode 中测试，想看看小模型下载文件（检查过网络环境）、解析PDF（本地已经安装 pymupdf 等 pip 包）、读取长文件这些工具调用的能力。提示词：

帮我下载这两份资料到本仓库：
https://cims.nyu.edu/~tristanb/statement.pdf
https://cdn.openai.com/pdf/32d9f210-8b73-45e0-91bc-82a30aef8a9a/navier-stokes.pdf
综合其中的信息，告诉我发生了什么

同样的，每次测完都会把新增的文件删掉，以确保启动状态相同。

MiniCPM5-2B：

第1次：没有意识到是在Windows下，非常强烈地想要用 /tmp 目录，甚至还派发了子 Agent，最后形成了总结 （点击了解更多详细信息） 第2次：不理会“下到本仓库”还是老样子，最后形成了总结 （点击了解更多详细信息） 第3次：这次意识到要下到仓库里了，但读写失败回到老样子，最后形成了总结 （点击了解更多详细信息）

Spark-X2.5-4B：

第1次：正确下载到目录，并形成了总结 （点击了解更多详细信息） 第2次：正确下载到目录，并形成了总结 （点击了解更多详细信息） 第3次：正确下载到目录，并形成了总结 （点击了解更多详细信息）

Qwen3.5-9B 蒸馏版：

第1次：遇到困难马上就停下来，用户推动后形成了总结 （点击了解更多详细信息） 第2次：探测到了网络链接，但提取失败，还变成了英文 （点击了解更多详细信息） 第3次：擅自加空格读写仓库失败，另辟蹊径通过网络解析获取到一篇内容，形成了总结 （点击了解更多详细信息）

顺便放一个不在这三次之内，但让我气笑了的案例：

至于总结的质量，大家吃过瓜的可以评判一下：

模型的总结质量排序

• MiniCPM5-2B
• Spark-X2.5-4B
• Qwen3.5-9B 蒸馏版

点击以查看投票。

KV Cache 量化测试

Spark-X2.5-4B 这个模型宣称超长上下文，但在上下文达到 1M 的时候显存占用依然非常可观。所以加测一个 KV Cache 量化。在都是Q8量化的情况下，262,144 上下文显示占用 8.49 GB 显存。

普通对话 （点击了解更多详细信息） 新闻搜集 （点击了解更多详细信息） 编程处理文字工作 （点击了解更多详细信息）

另外，我还发现当显存占用非常接近上限时，Token 速度对系统其他应用的显存占用就比较敏感了。例如下面我进行了 500,000 上下文（13.87 GB）的测试，一开始的速度是 155 tk/s：

开了几个浏览器以后就跌到 64 tk/s 了：

总结

至少在个人的用例中，Spark-X2.5-4B 的综合体验最好，Qwen3.5-9B 民间蒸馏版相比原版体验意外地有明显提升（个人主观感受），MiniCPM5-2B 在部分对话问题的表现比 Spark-X2.5-4B 更好。

如果有什么想让我测的案例，也可以发出来，或许之后有空可以测一下。不过 harness 仅限 YOLO 和 opencode，其他工具懒得再配置了。大家有自己测试的结果也欢迎讨论。