Benchmark Report


一、硬件环境

| 项目 | 规格 | |

date: “2026-07-02T00:00:00+08:00”
GPUIntel Arc 130T (16GB)
推理框架Ollama v0.9.x
WebGPU buffer limit1024MB (硬件限制)
模型存储SSD

⚠️ 关键约束: Intel Arc WebGPU 的 storage buffer binding limit 仅 1024MB,任何 >1GB 的权重块都无法完全在 GPU 上运行,会退化为 CPU 推理。


二、评测模型

模型参数量文件大小上下文来源
qwythos-9b~9B7.4 GB65KEmpero AI
qwen2.5:3b~3B3.4 GB32KQwen / Alibaba

三、速度测试

3.1 基准:200字中文生成

指标qwythos-9bqwen2.5:3b优势方
首token时间 (TTFB)14.3s9.2sqwen2.5:3b (+36%)
推理速度8.8 tok/s28.9 tok/sqwen2.5:3b (×3.3)
总耗时72.6s16.0sqwen2.5:3b (×4.5)
Token间隔波动0-5854ms0-1834msqwen2.5:3b (更稳定)

3.2 速度分析

qwen2.5:3b 完胜。原因:

  • 3B 模型权重小,Intel Arc 的 1024MB buffer 限制对其影响较小
  • qwythos-9b 虽然设置了 num_gpu 99,但实际大部分权重在 CPU 上运行,且 9B 模型在 CPU 推理本身就慢
  • qwythos-9b 的 Token 间隔波动极大(最高 5.8s),说明存在频繁的 CPU-GPU 数据交换瓶颈

四、能力测试

4.1 测试用例与结果

测试项qwythos-9bqwen2.5:3b说明
数学逻辑⚠️ 部分通过⚠️ 部分通过两者都犯了 15/2=7.5 的错误
代码能力✅ 通过✅ 通过均能生成可运行的排序算法
中文理解✅ 通过✅ 通过成语解释和造句
常识推理✅ 通过✅ 通过演绎推理正确

4.2 详细表现

数学逻辑题

小明有15个苹果,给了小红一半,又买了8个。现在小明有多少个苹果?

  • qwythos-9b: 用英文做 CoT 推理,最终给出 15/2=7.5 的答案,没有意识到苹果不能拆分
  • qwen2.5:3b: 同样算出 7.5,但尝试做了取整处理(7个或8个),更合理

两者均未得出正确答案 (16个: 15→7或8→+8=15或16),属于同级别错误。

代码能力

用Python写一个快速排序算法

  • qwythos-9b: 先用英文思考再写代码,代码本身正确
  • qwen2.5:3b: 直接生成带注释的代码,结构清晰,可直接运行

中文理解

请解释"胸有成竹"

  • qwythos-9b: 正确解释了含义(比喻做事之前已有通盘考虑)
  • qwen2.5:3b: 解释更生动,追溯到"画竹子"的典故本源

常识推理

如果所有猫都会爬树,Tom是猫,Tom会爬树吗?

  • qwythos-9b: 正确推理,但冗长的英文 CoT
  • qwen2.5:3b: 简洁正确的中文回答

五、综合评分

维度qwythos-9bqwen2.5:3b满分
速度2/108/1010
稳定性3/107/1010
代码能力7/107/1010
中文理解6/108/1010
逻辑推理5/105/1010
实用性3/108/1010
总分4.47.060

六、结论与建议

🏆 本次评测赢家: qwen2.5:3b

在 Intel Arc 130T 平台上:

  1. 速度快 3.3 倍,响应延迟低 36%
  2. 稳定性好,Token 生成间隔波动小
  3. 中文能力更强,回答更简洁直接
  4. 代码和推理能力相当

💡 优化建议

对于 qwythos-9b:

  • 当前 num_gpu 99 设置在此硬件上不生效,建议改为 CPU 推理或换用量化版本(Q4_K_M)
  • 考虑使用 qwythos-9b-Q4_K_M.gguf (~5GB) 或其他 7B 级量化模型
  • 9B 模型在 Intel Arc 上体验不佳,建议降级到 3-5B 量级

对于后续评测:

  • 建议增加 HumanEval 等标准化代码基准
  • 建议增加 C-Eval / CMMLU 等中文知识基准
  • 可考虑 llama.cpp SYCL 后端(已验证可用,build 9297)做对比

七、原始数据

完整 JSON 数据见 benchmark_report.json。

← 返回文章列表