在先前的 讯飞 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 对了1道，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**
| **Question** | **Answer** |
|:---|:---|
| Which is larger: 9.11 or 9.9? | **9.9** |
| How many 'r's in "strawberrrry"? | **5** |
## **Final Answer:**
* **9.9 is larger than 9.11**
* **"strawberrrry" contains 5 'r's**
测试 2：新闻搜集汇总
对我而言，小模型最可能的场景是知识库管理。所以这次依旧在佬友制作的 Obsidian YOLO 插件 里测试。提示词相比上次再升级了一下：
帮我搜索一下今天全球最新的中文AI新闻，选择5条作为精选新闻。要核对是不是确实是今天的新闻，如果不是要重新搜索。然后，利用网络工具读取新闻原文全文。最后，在仓库新建 news-test 目录、下面再以今天日期命名一个子文件夹，用分别的文件记录这些新闻，文件名格式为“序号_短标题.md”。每个文件都要有新闻的摘要、日期、关键词、原文、消息来源链接。
每次测完都会把新建的目录删掉，保证仓库不变。搜索引擎接的是智谱搜狗版，因为腾讯新闻网页抓取出问题的概率少一点。虽然有一定随机性，但模型能否应对应该也是能力的一环。
MiniCPM5-2B：
Spark-X2.5-4B：
Qwen3.5-9B 蒸馏版：
测试 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：
Spark-X2.5-4B：
Qwen3.5-9B 蒸馏版：
第1次：遇到困难马上就停下来，用户推动后形成了总结
随后我给出指示“方法1 + 3”，就继续推进了。虽然PDF下载到了仓库，但解析的代码却扔到了
C:\Users\用户名\.local\share\opencode\parse_pdfs.py。最后通过代码获得了结论：
第3次：擅自加空格读写仓库失败，另辟蹊径通过网络解析获取到一篇内容，形成了总结
一开始擅自加了个空格读取失败：
后来还是成功下载到仓库内。但读取又碰到问题，于是另辟蹊径，通过 jina 网络解析 PDF：
但第二篇解析失败。我分析了一下，是把 https 写成 http 导致的。最后根据第一篇输出了结论：
至于总结的质量，大家吃过瓜的可以评判一下：
- 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 tok/s：
开了几个浏览器以后就跌到 64 tok/s 了：
总结
至少在个人的用例中，Spark-X2.5-4B 的综合体验最好，Qwen3.5-9B 民间蒸馏版相比原版体验意外地有明显提升（个人主观感受），MiniCPM5-2B 在部分对话问题的表现比 Spark-X2.5-4B 更好。
如果有什么想让我测的案例，也可以发出来，或许之后有空可以测一下。不过 harness 仅限 YOLO 和 opencode，其他工具懒得再配置了。大家有自己测试的结果也欢迎讨论。
