小模型小测评：面壁 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道```
9.11和9.9中，9.9更大。

strawberry中有3个字母r。
``````
9.11小于9.9，因此9.9更大。

在“strawberrrry”中，字母‘r’出现了5次。
``````
所以，总结一下：

• 9.11 > 9.9
• "strawberrrry" 中有 5 个 'r'。

```

Spark-X2.5-4B：

省流：9.9 对了2道，strawberrrry 对了0道```
9.11比9.9大。

strawberrrry中有4个r。
```[被第二道题搞到原地兜圈子，绕不出来了]```
9.9比9.11大。因为9.11 = 9.11，9.9 = 9.90，9.90 > 9.11。

单词“strawberrrry”中有 4个 r。
```

Qwen3.5-9B 蒸馏版：

省流：9.9 对了3道，strawberrrry 对了3道```
|Question|Answer|
|---|---|
|Which is larger?|9.9 > 9.11|
|Number of 'r' letters|5 r's|
``````

Final Answer Summary

Final Answer:

• 9.9 is larger than 9.11
• "strawberrrry" contains 5 'r's

```

测试 2：新闻搜集汇总

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

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

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

MiniCPM5-2B：

第1次：写入了一个没有后缀名的文件，然后卡死了

第2次：大方向上对了，但没有读全文，还是写了一个没有后缀名的文件，然后每个子文件都把全局的信息重复了一遍

第3次：先写入没有后缀名的文件，然后试图把它当文件夹再写入

从试图写入的正文内容来看，框架上是有的，但没有进一步搜集原文

Spark-X2.5-4B：

第1次：大方向对了，甚至还会用任务清单。不过时间较长，只有一篇正确写入了原文

从工具调用的日志来看，其实已经成功读到原文了，但5篇中只有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，最后形成了总结

直到最后，资料都在 /tmp 目录。

第2次：不理会“下到本仓库”还是老样子，最后形成了总结

第3次：这次意识到要下到仓库里了，但读写失败回到老样子，最后形成了总结

Spark-X2.5-4B：

第1次：正确下载到目录，并形成了总结

居然会用 powershell

碰到了经典的编码问题

最终文件和解析的TXT都在仓库里，也获得了总结：

第2次：正确下载到目录，并形成了总结

第3次：正确下载到目录，并形成了总结

Qwen3.5-9B 蒸馏版：

第1次：遇到困难马上就停下来，用户推动后形成了总结

随后我给出指示“方法1 + 3”，就继续推进了。虽然PDF下载到了仓库，但解析的代码却扔到了 C:\Users\用户名\.local\share\opencode\parse_pdfs.py。

最后通过代码获得了结论：

第2次：探测到了网络链接，但提取失败，还变成了英文

这次代码改成扔到了C:\Users\用户名\AppData\Local\Temp\opencode\extract_pdf.py

第3次：擅自加空格读写仓库失败，另辟蹊径通过网络解析获取到一篇内容，形成了总结

一开始擅自加了个空格读取失败：

后来还是成功下载到仓库内了。另辟蹊径，通过 jina 网络解析 PDF：

但第二篇解析失败。我分析了一下，是把 https 写成 http 导致的。最后根据第一篇输出了结论：

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

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

模型的总结质量排序

- MiniCPM5-2B

- Spark-X2.5-4B

- Qwen3.5-9B 蒸馏版

0
投票人

KV Cache 量化测试

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

普通对话

个人感觉表现差不多，包括被 strawberrrry 绕进去的概率

新闻搜集

感觉思考有些偏长，但好歹也算能完成任务

编程处理文字工作

主观感觉也是大差不差

另外，我还发现当显存占用非常接近上限时，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，其他工具懒得再配置了。大家有自己测试的结果也欢迎讨论。