Qwen3.6-35B-A3B 工具调用基准测试：ByteShape 对比 Unsloth GGUFs、KV 缓存量化及长上下文性能

我之前发布过一些小的性能基准测试，但这次我对定性方面产生了兴趣。u/Substantial_Step_351 几周前发帖询问[为什么模型不进行工具调用基准测试](https://www.reddit.com/r/LocalLLaMA/comments/1tvb7lq/why_do_we_benchmark_quants_on_perplexity_and/)，而 u/complexminded 在评论中指出了 SeraphimSerapis 开发的 [tool-eval-bench](https://github.com/SeraphimSerapis/tool-eval-bench) 工具。这让我对测试几个我一直好奇但似乎没有明确答案的问题产生了兴趣： 1. ByteShape 对 Qwen3.6-35B-A3B 的量化是否真的像他们在[博客](https://byteshape.com/blogs/Qwen3.6-35B-A3B/)中声称的那样好？他们的基准测试显示，他们的 ~4bpw 量化保留了未量化模型 >99% 的基准分数，与 Unsloth、AesSedai 和 bartowski 等其他量化方案相当甚至更优，同时速度更快且通常体积更小。 2. KV 缓存量化对实际性能有何影响？q8_0 是免费午餐吗？q4_0 有多差？ 3. 如果查看长上下文设置而不是短提示，情况是否会发生变化？ **TL;DR**：ByteShape 与 Unsloth 之间没有明显赢家；q8_0 是免费午餐，但 q4_0 较差；在所有场景下，长上下文会显著降低工具调用性能。 # 材料 我临时获得了一个大部分空闲的 V100 GPU 集群，每块 GPU 有 32GB 显存，因此我开始使用 llama.cpp 和 tool-eval-bench 进行一些实验。首先，我选择了以下 Qwen3.6-35B-A3B 量化方案进行比较，包括 IQ 和 Q 类型量化： 1. ByteShape IQ3_S-3.48bpw 又名 GPU-3（15.1 GB），ByteShape 推荐用于 16GB 显存（刚好能放下） 2. ByteShape IQ4_XS-4.15bpw 又名 GPU-5（18.0 GB），ByteShape 推荐用于 24GB 显存 3. ByteShape Q4_K_S-4.22bpw 又名 CPU-5（18.3 GB），我在 6GB 显存笔记本电脑上使用的版本，部分在 CPU 上运行 4. Unsloth UD-IQ3_XXS（13.2 GB），非常紧凑的 IQ 量化，适合 16GB 显存，在某些基准测试中表现超出预期 5. Unsloth UD-Q3_K_XL（16.8 GB），一种 Q 量化，大小与 ByteShape CPU-5 相近 6. Unsloth UD-IQ4_XS（17.7 GB），一种 IQ 量化，大小与 ByteShape GPU-5 相近 7. Unsloth UD-Q4_K_M（22.1 GB），许多人的默认量化大小 8. Unsloth UD-Q6_K（29.3 GB），我能在 32GB 显存中放下的最大版本 我决定不测试其他来源的量化，因为我主要关心 ByteShape 与其他方案的对比，而 Unsloth 似乎是许多人信赖的常见选择。 为了测量 KV 缓存量化的效果，我决定测试三种配置：默认 f16、q8_0/q8_0 和 q4_0/q4_0。为了限制运行次数，这次我决定不测试非对称 KV 缓存量化。 为了测量长上下文与短上下文下的性能，我使用了 tool-eval-bench 的 `--context-pressure` 参数（以下简称 cp），将其设置为 0.0 或 0.5。0.0 表示短上下文（约 5k 令牌的系统提示，包含工具调用定义），而 0.5 表示提示将额外包含 122k 令牌的文本，可能会混淆模型。这模拟了上下文窗口已被对话和工具调用历史填充 50% 时模型的行为。 我对每个基准测试运行使用不同的随机种子重复三次。总共 (8 个 GGUF) × (3 种 KV 量化) × (2 种上下文长度) × (3 次重复) = 144 次运行。短上下文运行仅需约 15 分钟，但长上下文运行每次约需 4 小时。因此总用时约为 300 个 GPU 小时，包括一些实验和失败的运行。 # 软件设置 为了运行模型，我使用了支持 CUDA 的 llama.cpp 版本 9529（96fbe0039）。对于工具使用基准测试，我使用了 tool-eval-bench 2.0.4。 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 $KV_QUANT -ctv $KV_QUANT --port $PORT` tool-eval-bench 参数：`--base-url $BASE_URL --hardmode --weight-by-difficulty --backend llamacpp --context-size 262144 --context-pressure $CONTEXT_PRESSURE --seed $SEED` 我没有花太多时间优化甚至测量 PP/TG 速度，因为我只关心输出质量，而不是原始性能。出于同样的原因，我没有启用 MTP 或其他推测解码。在非常慢的长上下文运行中，瓶颈主要是 PP 速度，因此我将 `--ubatch-size` 增加到 2048，这似乎有所帮助。 # 评分指标 我查看的指标是 tool-eval-bench 报告的“总点数”。启用 `--hardmode` 后，此版本的 tool-eval-bench 会执行 84 个独立的测试。每个测试成功使用工具得 2 分，部分正确使用工具得 1 分，失败得 0 分。理论最大值是 84 × 2 = 168 分。tool-eval-bench 还会返回一个总体分数，但这只是总点数的百分比四舍五入，会损失一些精度，因此我选择了原始总点数。我不太清楚 `--weight-by-difficulty` 选项的作用；它似乎对分数没有影响。 # 按 GGUF 分类的结果 以下是模型概览，包括大小、总体得分以及按 KV 缓存量化和短/长上下文分别划分的分数。另请参见散点图。 |model_name|model_size|avg_overall|avg_kv_f16|avg_kv_q8_0|avg_kv_q4_0|avg_cp_0.0|avg_cp_0.5| |:-|:-|:-|:-|:-|:-|:-|:-| |Unsloth UD-IQ3_XXS|13.2|143.6|142.2|143.2|145.5|**150.7**|136.6| |ByteShape GPU-3|15.1|144.5|147.0|144.5|142.0|149.7|139.3| |Unsloth UD-Q3_K_XL|16.8|143.8|145.0|143.7|142.8|147.3|140.3| |Unsloth UD-IQ4_XS|17.7|144.8|143.0|146.8|144.5|149.7|139.9| |ByteShape GPU-5|18.0|**146.8**|**147.8**|**147.3**|145.3|149.0|**144.7**| |ByteShape CPU-5|18.3|142.2|143.0|141.5|142.0|145.4|138.9| |Unsloth UD-Q4_K_M|22.1|144.4|143.0|143.7|**146.5**|148.3|140.4| |Unsloth UD-Q6_K|29.3|145.2|147.7|146.7|141.2|**150.7**|139.7| 总体最佳模型是 ByteShape GPU-5，在平均分数上击败了包括 Unsloth UD-Q4_K_M 和 UD-Q6_K 在内的更大模型。它在长上下文任务上的表现尤其突出。ByteShape CPU-5 是表现最差的。模型大小似乎与基准分数相关性较弱；这也可能表明基准指标存在噪声。 # 按 KV 缓存量化分类的结果 以下是按所用 KV 缓存量化分组后的基准分数细分。首先是总体分数，然后是短/长上下文的条件分数。另请参见柱状图。 |kv_quant|avg_overall|avg_cp_0.0|avg_cp_0.5| |:-|:-|:-|:-| |f16|**144.8**|**149.2**|**140.5**| |q8_0|144.7|**149.2**|140.1| |q4_0|143.7|148.1|139.3| f16 和 q8_0 KV 缓存量化几乎持平；它们的基准分数非常接近，很可能在误差范围内。然而，在长上下文（cp=0.5）情况下，f16 可能略有优势。q4_0 量化落后其他方案约 1 分。 # 发现 * 尚不清楚 ByteShape 还是 Unsloth 的量化更好。ByteShape 既有表现最好的量化（GPU-5），也有表现最差的量化（CPU-5）。 * f16 和 q8_0 KV 缓存量化几乎持平，因此 q8_0 可视为免费午餐。使用 q4_0 的影响出人意料地小，但确实存在。 * 长上下文严重影响性能，cp=0.0 和 cp=0.5 情况之间的平均差距接近 10 分。在长上下文压力下，ByteShape GPU-5 量化比其他方案更具韧性。 # 注意事项 本次基准测试完全依赖于 tool-eval-bench 的任务及其评分方式。它可能代表也可能不代表真实的工具使用性能。在我看来，tool-eval-bench 的作者在创建逼真的工具调用任务方面做得非常出色，包括一些通过 `--hardmode` 启用的真正困难的任务。 对于长上下文运行，我依赖于 tool-eval-bench 的 `--context-pressure` 设置，该设置（根据我的理解）