35B-A3B工具调用基准测试：原始Qwen对比KAT Coder、Ornith和Tiel-Coder

随着Qwen3.8-35B-A3B发布的希望基本破灭，包括我在内的许多人开始关注Qwen3.6-35B-A3B的微调版本和其他变体，以便在显存有限的硬件上运行。我决定尝试对一些顶级竞争者进行基准测试：KAT-Coder、Ornith 1.5和最近的Tiel-Coder。我使用了SeraphimSerapis的tool-eval-bench工具作为基准测试套件。它衡量了不同模型处理工具调用的能力，包括一些非常困难的场景。 **TL;DR:** Ornith 1.5和Tiel-Coder（基于Ornith）在本次基准测试中并列获胜。它们得分远高于Qwen3.6-27B，并接近3.8-27B。KAT Coder也略优于原始35B-A3B。Ornith-1.5-Heretic令人失望。 不久前，我发布了一个类似的工具评估基准测试，针对不同的Qwen3.6-35B-A3B量化版本。事后看来，这效果不佳，主要是因为我考虑了太多变量（GGUF量化、KV量化、上下文深度/压力），且基准测试本身噪声较大，因此难以获得清晰结果。希望这次我做得更好！ **材料** 我访问了一个由32GB V100 GPU组成的集群。对于本次比较，我为每个模型选择了2-3种不同的量化版本（如果可能，来自不同供应商）。作为比较，我还包括了原始Qwen3.6-35B-A3B以及密集的3.6-27B和3.8-27B Qwen模型。我选择了大约Q4附近的量化版本（15GB到22GB GGUF文件），因为许多人似乎使用这种。对于原始Qwen模型，我选择了Unsloth UD-Q4量化版本，因为它们广为人知。我还包括了ByteShape的CPU-5量化版本的Qwen3.6-35B-A3B，因为这是我最近使用的量化版本。总共我基准测试了13个不同的GGUF文件，每个文件运行5次，共计65次运行。每次运行大约需要4.5小时GPU时间，除了27B模型需要7小时左右。总GPU时间超过300小时，包括一些失败的运行。 运行模型时，我使用了llama.cpp版本0.1.0-dev（构建10433，提交9b05354ec），日期为2026-08-14，并启用了CUDA支持。我使用了q8_0 KV缓存（这是像我这样显存有限的人常做的），并将ubatch-size设置为2048，因为基准测试进行了大量提示处理。我没有使用MTP或其他推测解码。这不是一个速度基准测试。 llama.cpp参数： -m $GGUF --temperature 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 --presence-penalty 0.0 --repeat-penalty 1.0 -ngl 99 --ubatch-size 2048 --fit-target 256 -ctk q8_0 -ctv q8_0 --port $PORT --seed $SEED 对于基准测试，我使用了tool-eval-bench 2.6.0。我将上下文长度设置为262144，上下文压力设置为50%。这意味着模型在50%上下文深度下进行基准测试，即大约128k可能干扰的聊天和工具调用历史。 tool-eval-bench参数： --base-url $BASE\_URL --hardmode --weight-by-difficulty --backend llamacpp --context-size 262144 --context-pressure $CONTEXT\_PRESSURE --seed $SEED **评分指标** 我查看的指标是tool-eval-bench报告的“总分”。启用--hardmode后，此版本的tool-eval-bench执行了88个独立测试。每个测试成功使用工具得2分，部分正确得1分，失败得0分。理论最大值为88 * 2 = 176分。 tool-eval-bench还返回一个总分，但这只是总分的四舍五入百分比，四舍五入会损失一些精度，因此我选择了原始总分。 **按模型结果（所有量化版本平均）** 以下是按模型的基准测试分数。我对同一模型的所有量化版本和每个量化的所有5次运行进行了平均。 model_id repetitions (n) avg total_score CI (95%) Qwen3.8-27B 5 152.6 [149.4, 155.8] Ornith-1.5 10 144.2 [141.7, 146.7] Tiel-Coder 10 144.0 [141.8, 146.2] Qwen3.6-27B 5 134.8 [131.2, 138.4] KAT-Coder-V2.5-Dev 15 133.8 [131.8, 135.8] Ornith-1.5-Heretic 10 132.2 [130.6, 133.8] Qwen3.6-35B-A3B 10 131.5 [129.9, 133.1] **按具体量化版本结果** 请参见图像。同一模型的量化版本之间没有显著差异，除了可能KAT-Coder，其中mudler APEX量化版本略优于bartowski的。此外，ByteShape的Qwen3.6-35B-A3B量化版本略优于Unsloth的，这是一个不错的意外。 **原始结果** 如果有人想深入了解，我在这里分享了包含tool-eval-bench结果的CSV文件。这包括例如特定类别的分数（即模型在特定类型的工具调用上表现如何）和总令牌数；在我的分析中我没有查看这些。 **发现** 在原始Qwen模型中，3.6-35B-A3B得分最低，3.8-27B得分最高，3.6-27B居中。这符合预期，表明基准测试提供了有用的信号。 Ornith-1.5和Tiel-Coder几乎并列。它们是35B-A3B变体中的明显赢家。它们得分高于3.6-27B但低于3.8-27B。 KAT-Coder可能略优于原始35B-A3B，但置信区间重叠。 Ornith-1.5-Heretic令人失望，比普通Ornith差很多。 **注意事项** 本基准测试完全依赖于tool-eval-bench任务及其评分方式。它可能代表也可能不代表实际工具使用性能。在我看来，tool-eval-bench的作者在设计逼真的工具调用任务方面做得很好，包括使用--hardmode启用的一些真正困难的任务。 我依赖于tool-eval-bench中的--context-pressure设置，该设置（根据我有限的理解）用看起来逼真的对话和工具调用历史填充上下文，这可能会混淆模型。 工具调用并非一切。如果你进行代理编码，编码质量也很重要。我在本次基准测试中没有直接衡量这一点，除了非常间接的方式。为此目的有其他基准测试。 基准测试分数存在显著变化和噪声，我通过用不同种子重复运行、平均和计算置信区间来缓解。 在X/Y图中，X轴代表大小，我没有检查模型是否包含MTP头，我只是查看原始GGUF文件大小。这对启用了MTP的模型稍显不公平，因为它们的文件更大，但MTP并不提高质量，只提高生成速度。 没有AI用于撰写本文。我使用了Tiel-Coder帮助我绘制结果图表。也重用了我自己之前的一些写作。我与模型或量化制作者或基准测试套件没有任何关联。