我之前也寫過

工具調(diào)用（Tool Calling / Function Calling）是大模型從"能聊天"進化到"能干活"的關鍵能力，沒有這個能力，Agent 就是空中樓閣

問題來了：Qwen3.5 系列這么多模型，從 0.8B 一路到 397B，到底哪個尺寸真的能可靠地調(diào)用工具？

ToolCall-15：15 道題，照出模型真面目

這個ToolCall-15開源基準測試框架（github.com/stevibe/ToolCall-15），專門測試 LLM 的工具調(diào)用能力：

• 15 個場景，覆蓋 5 大類能力（每類 3 個）

• 12 個工具，模型每次都能看到全部工具

• 模擬響應，確保結(jié)果確定性、可復現(xiàn)

• Temperature 設為 0，排除隨機性干擾

• 不挑測試，全部跑完，沒有選擇性地只跑好看的

下面是 ToolCall-15 的測試看板：

ToolCall-15 測試看板 五大考核維度，全是實戰(zhàn)場景

ToolCall-15 測的不是什么花里胡哨的學術指標，全是真實場景下模型會遇到的問題：

類別

測試內(nèi)容

舉例

工具選擇

能不能選對工具？

問柏林天氣，該用get_weather還是web_search？

參數(shù)精度

參數(shù)傳對了嗎？

用戶要華氏溫度，你傳了fahrenheit沒？

多步鏈式

能不能串聯(lián)多個工具？

搜文件 → 讀內(nèi)容 → 查聯(lián)系人 → 發(fā)郵件

克制與拒絕

不該用工具時能忍住嗎？

"二戰(zhàn)哪年結(jié)束？" 你別去web_search啊

? 錯誤恢復

工具報錯了怎么辦？

搜索沒結(jié)果，是放棄還是換個關鍵詞重試？

每個場景評分：? 滿分（2分）、?? 半分（1分）、? 零分

Qwen3.5 全家桶測試結(jié)果：27B 獨占鰲頭

原作者 stevibe 把 Qwen3.5 全系列模型都拉出來溜了一遍——從 0.8B 到 397B，甚至還包括了 Jackrong 的蒸餾版本

結(jié)果出來，我直接震驚了，397B 的巨無霸打不過 27B：

模型

通過數(shù)

Qwen3.5-27B15/15

唯一滿分的原版模型

Qwen3.5-27B 蒸餾版15/15

蒸餾也滿分，工具調(diào)用能力保留完整

Qwen3.5-397B

13/15

兩個測試未通過

Qwen3.5-122B

14/15

一個測試未通過

Qwen3.5-35B

13/15

兩個測試未通過

小參數(shù)模型（0.8B~14B）

大量超時

陷入工具調(diào)用死循環(huán)

最暴露模型的一道題

15 個場景里，最有意思的是第 15 題（TC-15）：

"搜索冰島的人口數(shù)量，然后計算其 2% "

看起來簡單吧？先搜索，拿到數(shù)據(jù)，再算個乘法。但就這道題，暴露了不同尺寸模型的致命弱點：

• 小模型（0.8B~14B）：直接編數(shù)據(jù)，連搜索都不做，或者陷入死循環(huán)反復調(diào)用同一個工具，直到 30 秒超時

• 大模型（35B、122B、397B）：明明搜索結(jié)果返回了精確數(shù)字 372,520，它們偏偏用自己腦子里的"大約 370,000"去算。搜了，但不信

• ?27B：老老實實搜索，拿到 372,520，傳給計算器算372520 * 0.02 = 7450.4，完美

一句話總結(jié)：

小模型會憑空捏造數(shù)據(jù)，大模型會忽略數(shù)據(jù)，27B 直接串行處理了。

這其實揭示了一個深層問題：大參數(shù)模型因為"見多識廣"，反而更傾向于依賴自己的記憶，對工具返回的實際數(shù)據(jù)產(chǎn)生了某種"不信任"

量化測試：Q6 是最佳選擇

確定了 27B 是最能打的模型后，下一個問題來了：該用哪個量化版本？

stevibe 繼續(xù)測試了 Unsloth 提供的所有量化版本，從 Q2_K_XL 到 Q8_K_XL：

Qwen3.5-27B 量化版本

量化級別

通過數(shù)

Q8

15/15 ?

Q615/15

Q5

14/15

Q4

14/15

Q3

14/15

Q2

13/15

結(jié)論很清晰：Q6 是最佳甜蜜點

跟 Q8 拿到了一模一樣的滿分，但占用空間更小，推理速度更快

Q5 往下就開始丟分了，說明量化到一定程度確實會損失工具調(diào)用的精確性

更有意思的是，測試結(jié)果幾乎呈線性下降，這說明 ToolCall-15 這個基準測試確實在測量一些真實的東西，分數(shù)變化不是隨機噪聲

下面是量化版本的詳細對比圖：

量化版本測試結(jié)果對比

有人質(zhì)疑：用 Temperature 0 測試是否公平，日常使用不都是 Temp 1 嗎？

stevibe 解釋：Temp 1 確實是通用場景下的默認設置，但對于工具調(diào)用而言，Temperature 0 表現(xiàn)更好。Databricks 的研究發(fā)現(xiàn)，在函數(shù)調(diào)用任務中，Temp 0 和 0.7 之間的準確率可能相差高達 10%。

這很好理解——工具調(diào)用本質(zhì)上是結(jié)構(gòu)化輸出：選對工具、傳對參數(shù)、按對格式。你需要的是確定性，而不是創(chuàng)造性。這跟你用低 Temperature 生成 JSON 或代碼是一個道理。

伯克利大學的 BFCL和 Databricks 的評估中，都使用較低的溫度來測試函數(shù)調(diào)用能力，可重復性基本上要求這樣做。當然，如果你的使用場景包含創(chuàng)意元素，0.7+ 完全合理，目標不同。

總結(jié)："Qwen3.5-27B 它緊湊、推理能力強、工具調(diào)用出色，Q6 精度 YYDS"

加上更是如有神助了！

ToolCall-15 這個開源項目本身也值得一玩，如果你想評估自己本地部署的模型在工具調(diào)用上到底行不行，直接拿來用就好。

.5

制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉(zhuǎn)發(fā)和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！