分析与模型案例

01

三个总参数少于 360 亿的开放模型

我们选取 Qwen 3.8 27B、Qwen 3.6 35B-A3B 和 Gemma 4 31B IT 作为编辑案例，涵盖两家提供商以及稠密和 MoE 架构。这不是最佳模型排名。首先应确认，同一任务是否存在可比的测量。

每个模型和测试均采用按主表规则选定的基础结果。排除量化变体、过时或未获当前确认的证据、冲突和污染警告。同一图组必须具有相同来源、测试版本、任务、指标、智能体、工具和评分设置。不同思考设置仍会显示；这并不能证明计算预算相同。

刻度为 0–100%。仅同组数值共享所列测试设置；不计算跨组优势。

点估计较高不代表具有统计优势。已披露的设置仍可能存在未报告的差异。

GPQA 反映科学问题求解能力，SciCode 关注科学编程，LiveCodeBench 关注竞赛编程。因此，GPQA 领先并不能确定哪个模型更适合处理你的代码。应先选任务领域，再在同一组内比较数值。

我们的结论是：与任务相关的共同证据，比这三个测试的平均值更有助于筛选候选模型。缺少共同测量时，信息缺口依然存在。总参数量本身也不能确定量化本地部署的实际内存需求或速度。

↑ 返回主题目录

02

同一个模型，两种 SWE-bench 结果

Claude Opus 5 说明了为什么仅有模型名和测试名还不够。我们并列展示 Vals 的独立运行和提供商的补充报告。每个结果都与其来源和评测设置绑定。

Vals 记录明确列出 mini-swe-agent 和 Bash。提供商记录描述了不同或披露不完整的设置，思考与重复次数的信息也不同。因此不能将分数差归因于单一原因；它既不能证明模型进步，也不能证明某个来源出错。

比较不同模型时，我们会先采用 Vals 的统一评测组。提供商报告作为其所测系统的补充证据。用于自己的项目时，仍需在自己的代码仓库、智能体和固定时间与 token 预算下测试。

↑ 返回主题目录