Qwen3 工具调用实测：Ornith-1.5 与 Tiel-Coder 并列居首
用户用 tool-eval-bench 对 Qwen3 系列及多个 35B-A3B 微调变体进行工具调用实测，Ornit…
r/LocalLLaMA 用户针对 Qwen3.6-35B-A3B 及其主流微调变体，在工具调用（tool calling）维度做了一次较为系统的对比实测。在 Qwen3.8-35B-A3B 短期内不会发布的背景下，社区把目光投向了 35B-A3B 的各类微调模型，希望在 VRAM 受限的硬件上找到能力更强的替代方案。本次测试覆盖 KAT-Coder、Ornith 1.5、Tiel-Coder、Ornith-1.5-Heretic 以及 Qwen3 原生版本，并加入了 Qwen3.6-27B、Qwen3.8-27B 作为参照系。
测试对象与实验设置
作者使用一台搭载 32GB V100 的集群（多卡），选用 q4 量级（15GB–22GB 的 GGUF 文件）的多种量化版本以贴近本地部署用户的常见选择。原版 Qwen 模型选用 Unsloth 的 UD-Q4 量化，Qwen3.6-35B-A3B 还额外加入了 ByteShape 的 CPU-5 量化。整体共评估 13 个 GGUF 文件，每个文件跑 5 次，合计 65 次运行，累计 GPU 消耗超过 300 小时。
推理栈使用 llama.cpp 0.1.0-dev（CUDA 构建，2026-08-14），采用 q8_0 KV cache，ubatch-size 设为 2048 以适配 prompt processing；不开启 MTP 等投机解码，定位为能力评估而非速度测试。Benchmark 工具为 SeraphimSerapis 的 tool-eval-bench 2.6.0，启用 --hardmode 与 --weight-by-difficulty，context 长度设为 262144，context pressure 设为 50%，即模型在约 128k 的聊天与工具调用历史干扰下作答。
评分方式
tool-eval-bench 在 --hardmode 下共执行 88 个测试用例：完全成功的工具调用得 2 分，部分正确得 1 分，失败得 0 分，理论满分为 176 分。作者使用原始 total points 而非工具自带的百分比概览分，以减少四舍五入带来的精度损失。
主要结果
按模型汇总（不同量化与多次运行取均值，并给出 95% 置信区间）后，得到以下排序：
- Qwen3.8-27B：152.6 [149.4, 155.8]
- Ornith-1.5：144.2 [141.7, 146.7]
- Tiel-Coder：144.0 [141.8, 146.2]
- Qwen3.6-27B：134.8 [131.2, 138.4]
- KAT-Coder-V2.5-Dev：133.8 [131.8, 135.8]
- Ornith-1.5-Heretic：132.2 [130.6, 133.8]
- Qwen3.6-35B-A3B：131.5 [129.9, 133.1]
关键结论如下：
- Ornith-1.5 与 Tiel-Coder 几乎并列夺冠，是 35B-A3B 微调家族中表现最佳的选择，得分高于 Qwen3.6-27B 但仍落后于 Qwen3.8-27B。
- KAT-Coder 略好于原生 Qwen3.6-35B-A3B，但两者的置信区间存在重叠，优势并不显著。
- Ornith-1.5-Heretic 表现明显下滑，作者称之为「令人失望」，验证了去合并化的代价。
- 同模型不同量化版本之间没有巨大差距；Qwen3.6-35B-A3B 的 ByteShape 量化略好于 Unsloth 版本；KAT-Coder 的 mudler APEX 量化略好于 bartowski 版本。
局限与说明
本次评测只看 tool-eval-bench 的得分，工具调用只是一项能力维度，无法反映实际的代码生成质量或综合 agent 表现。Benchmark 整体仍存在明显噪声，作者通过多次重复取均值与置信区间来缓解。作者也强调：评分结果是否对应真实业务场景下的工具调用能力，并无定论。
对关注本地部署、需要在 32GB 及以下显存上跑 35B-A3B 量级模型的用户来说，若工具调用是核心诉求，Ornith-1.5 与 Tiel-Coder 是目前相对更稳妥的选择；追求绝对上限且具备更高显存预算的用户，仍应以 Qwen3.8-27B 为优先。作者同时公开了原始 CSV 数据，包含按测试类别细分的分数与 token 消耗，供进一步分析。