CycleUser上次的小模型批量测试对于需要速度的场景来说也就是可以看个乐，对于需要质量的情况来说，可能就完全不够看了，毕竟模型参数规模小，决定了能力上限很难和更大规模的模型相比。 另外，当时的OllamaModelTester的参数解析有一点bug，读取 prompt evaluation rate (eval_rate_tps) 和evaluation rate (eval_rate_tps)的时候会弄混，全都用 prompt evaluation rate (eval_rate_tps) ，而且正好用过了三次修改的机会，于是挨打要立正，错就错了，无非就是丢人了。
这回用的都是参数超过 20B 的模型上。
主要原因有两个： * 一方面是这些20B以上的大模型算是具备了初步的可用性了，在很多场景下都能够提供和当初GPT3.5相比都不逊色的性能。要知道当年GPT3.5刚出的时候也是让很多人追捧的小甜甜，但现在应该是早成了牛夫人了。
- 另一方面，对于主流配置的游戏本来说，20-30B左右的模型基本上是流畅运行的上限。本次对比也加入了gpt-oss:120b，但速度明显要慢一些。
另外，需要额外说明的是，此次测试用的是Windows11系统，之前发现同样是用Ollama运行同样的模型，在Ubuntu 24.04上哪怕是gpt-oss:120B，速度都能达到接近10tokens/s，而在Windows11上，速度只有5-6tokens/s，据此推测，其他模型在本次Windows11上测试的速度可能都会比Ubuntu 24.04上要慢一些。
这些模型使用8G显存的4060笔记本电脑跑，8G显存肯定是不够，所以还要依靠128G的大内存，这样才能跑起来。以gpt-oss:120B为例，需要占用超过90G的内存来运行，而显存只用了5G左右，如下图所示。
可惜目前没想到什么好办法来让这些模型和gpt3.5进行直观对比，想当年3.5出来的时候，也是让很多人非常惊叹，但现在看来，那性能已经完全不够用，估计远不如本地的qwen3，但是这个差距到底有多少呢？要是有办法能比较直观的对比就好了。反正这次咱们先对所有能本地布置的模型，利用之前设计的本地任务测试工具来测测，看看不同场景下到底谁厉害一些。
具体选用的模型如下表所示：
表1-模型参数规模对比
| 模型名称 | 参数规模（近似） |
|---|---|
devstral:24b |
24B |
deepseek-r1:32b |
32B |
gemma3:27b |
27B |
gpt-oss:20b |
20B |
gpt-oss:120b |
120B |
qwen3:30b-a3b-instruct_Q8 |
30B |
qwen3:30b-a3b-thinking_Q8 |
30B |
qwen3-coder:30b-a3b-instruct_Q8 |
30B |
qwen3:30b |
30B |
qwen3-coder:30b |
30B |
说明： - 参数规模中的
B表示十亿（Billion）。 - 部分模型如qwen3-coder系列是代码专用模型，适合编程任务。
所选的模型中，参数规模最大的是gpt-oss:120B，参数规模最小的是gpt-oss:20B，其他的基本都是30B左右的，另外有几个Q8的模型放上去，主要是对比看看不同量化应该是没啥区别。
使用Ollama获取要用的模型
首先是使用ollama的命令来拉取模型：
ollama pull devstral:24b
ollama pull deepseek-r1:32b
ollama pull gemma3:27b
ollama pull gpt-oss:20b
ollama pull gpt-oss:120b
ollama pull hopephoto/qwen3-coder-30b-a3b-instruct_q8
ollama pull hopephoto/qwen3-30b-a3b-thinking_q8
ollama pull hopephoto/qwen3-30b-a3b-instruct_q8
ollama pull qwen3:30b
ollama pull qwen3-coder:30b
运行 OllamaModelTester
可以获取代码，然后安装依赖包，然后运行：
git clone https://github.com/EasyCam/OllamaModelTester.git
cd OllamaModelTester
pip install -r requirements.txt
cd ollamamodeltester
briefcase dev
也可以下载安装包来安装： 网盘链接: https://pan.baidu.com/s/1imh6uF3lFGSz17KJopF5Ww?pwd=CUGB 提取码: CUGB
界面比较粗糙简陋，大家自行探索以下基本都能运行起来。
结果对比
测试大概效果如下图所示，自评分就是自己对自己对各个任务生成内容的评价，这方面来看，deepseek-r1:32b好像很没信心，而qwen3-30b-a3b-thinking_q8更低。推测着大概是推理模型在对待任务处理的环节里生成了太多的所谓思维链内容，被一并考虑拉低了评分。实际上使用起来，有不少朋友就挺烦这个思维链的，有时候会放大错误并且降低速度。
自评分环节，就是对自己生成的内容自己给个评分，其实这也可能会评了个寂寞，不过这里体现出其他模型都对自己生成的内容挺有信心，除了gpt-oss:20b对自己的中英互译环节给分只有5分。
按照tokens/s进行整体性能排名，实际上比Ubuntu 24.04是慢多了，不过这几个模型这次都是在Windows11下运行，相对比起来还可以说得过去。这一环节里，gpt-oss:20b拿下第一，平均有8.5 tokens/s，接下来是qwen3的各个30b模型，其中q8的稍微慢一点，这些都不出乎意料。 比较让人意外的是，gpt-oss:120b居然要比devstral:24b和gemma3:27b快上不少，而此次测试中deepseek-r1:32b垫了底。
很明显，此次测试中，各环节的性能对比来看，qwen3-2507的这几个，在中英互译环节辗压群雄，而gpt-oss:20b是综合性能最好的，gemma3:27b和deepseek-r1:32b垫了底。
将tokens/s除以模型参数规模（换算到m），得到的分数如下图所示，很明显，还是gpt-oss:20b的分数最高，然后是qwen3-2507的一些列，而gpt-oss:120b是最低，deepseek-r1:32b排名第九。
和上次一样，这次也是很不严谨很没有参考意义的测试，希望各大厂商千万不要理会咱这只小虾米。
具体结论见仁见智了，标题虽然说了“对比”，但其实我这也就是用简单的案例做个测试，不一定有什么代表性，大家自行测试吧。