小模型小测评：面壁 MiniCPM5-2B、讯飞 Spark-X2.5-4B、阿里 Qwen3.5-9B（民间蒸馏版）

这次实测比较三款可在 16 GB 显存环境运行的小模型，重点不是单轮问答分数，而是它们在 Windows 上执行搜索、文件写入、PDF 下载与解析等 Agent 任务时的稳定性。原帖发布于 2026 年 9 月 9 日，以下按原测试条件和结果整理。

测试环境与模型配置

• 操作系统：Windows。
• 运行工具：LM Studio，并通过其 API 向外提供模型服务。
• 显卡：RTX 5070 Ti 16 GB。
• 运行时：CUDA 12 版 llama.cpp，版本 v2.34.0。
• 每个测试连续执行 3 次，记录成功情况与失败模式。

三款模型均设置 131,072 上下文：

Qwen3.5-9B 蒸馏版支持视觉输入，但这轮没有测试视觉能力。

测试一：基础对话

测试包含小数大小比较和字符串中字母计数两个常见易错任务，各模型执行三轮。

• MiniCPM5-2B：两个任务分别正确 2 次。
• Spark-X2.5-4B：小数比较正确 1 次，字母计数三次均错误，并出现反复推理无法结束的情况。
• Qwen3.5-9B 蒸馏版：两个任务均连续正确 3 次。

测试二：搜索新闻并按目录写入

测试在 Obsidian YOLO 插件中进行。任务要求搜索当天的 5 条中文 AI 新闻，核对日期、读取原文，并按日期创建目录和 Markdown 文件。每轮结束后删除新目录，保持初始状态一致；搜索使用智谱搜狗版。

MiniCPM5-2B

三次均暴露文件系统规划问题：有一次先写出无扩展名文件后卡住；另外两次没有正确创建目标目录或文件，也没有完成原文采集。虽然能生成基本内容框架，但无法稳定完成整条流程。

Spark-X2.5-4B

第一轮能使用任务清单并读取原文，但 5 篇中只有 1 篇正确写入；第二轮有 2 篇正确写入，另有标题中的斜杠被错误解释成目录；第三轮再次把内容写入无扩展名文件。整体工具使用最积极，但目录和文件名处理仍不稳定。

Qwen3.5-9B 蒸馏版

第一轮在网页读取受阻后停止继续寻找可访问来源；第二轮没有按要求拆分文件，并把摘要页误当成原文；第三轮仍未分文件，但有 2 篇完成原文写入。任务结构理解尚可，遇到外部访问失败后的恢复能力偏弱。

测试三：下载并解析两份 PDF

测试在 OpenCode 中进行，本地已安装 PyMuPDF 等依赖。要求把两份指定 PDF 下载到当前仓库，然后综合文档内容；每轮同样清理新增文件。

MiniCPM5-2B

模型多次忽略 Windows 环境，持续使用 /tmp。前两轮虽然形成总结，但文件留在错误位置；第三轮意识到目标仓库后仍发生读写失败。

Spark-X2.5-4B

三轮都把 PDF 下载到正确目录并形成总结。模型能识别 PowerShell 环境；其中一轮遇到编码问题，但总体完成度明显高于另外两款。

Qwen3.5-9B 蒸馏版

模型在遇到困难时容易提前停止，需要用户推动。测试中出现脚本写入用户目录或临时目录、路径被意外加空格、把 HTTPS 写成 HTTP 等问题。部分轮次通过替代网页解析取得一篇内容，但第二份 PDF 仍失败，结果稳定性不足。

Spark-X2.5-4B 的 KV Cache 量化补测

Spark-X2.5-4B 使用 Q8 KV Cache、上下文 262,144 时，显存占用为 8.49 GB。基础对话、新闻搜索和文字处理的主观表现与前述测试接近。

继续把上下文提高到 500,000 时，显存占用约 13.87 GB，初始速度约 155 token/s；打开多个浏览器页面、进一步占用显存后，速度降到约 64 token/s。这个结果说明，在显存接近上限时，其他桌面应用的显存占用会显著影响生成速度。

原帖结论与适用边界

在作者自己的工作流中，Spark-X2.5-4B 综合体验最好；Qwen3.5-9B 民间蒸馏版相较原版有明显改善，但这部分包含主观判断；MiniCPM5-2B 则在部分基础对话题上表现更好。

测试只覆盖 YOLO 与 OpenCode 两种执行框架，模型表现也会受到框架、工具定义、系统提示词、随机性和 Windows 环境影响，因此结果不能直接外推到其他 Harness 或业务场景。

原作者：concentrate1（c.1）
原帖：https://linux.do/t/topic/2880701