关键要点
- 2026年5月5个可靠的工具调用者： Gemma 4 27B、GLM-5.1 32B、Qwen3 32B、Qwen3-Coder 30B、Llama 3.3 70B。所有5个都发出格式良好的函数调用JSON并能通过严格的MCP模式验证。
- Llama 3.3 70B具有最高的上限——跨MCP服务器~97%的格式良好调用率——但需要48GB+ VRAM。仅当硬件允许时使用；较小的模型通常就足够了。
- Gemma 4 27B是24GB Rig的标准选择。 该尺寸最佳的工具调用训练，在链式调用上保守。在文件系统、数据库和GitHub MCP服务器上可靠。
- GLM-5.1 32B在长上下文代理任务上获胜。 128K上下文窗口开箱即用；偶发参数截断是唯一常见故障。选择用于合规报告和长录音。
- Qwen3-Coder 30B是最佳的代码形工具调用者。 在
replace_in_file、read_file和代码感知浏览器操作上强；在非代码MCP服务器上弱于Gemma 4。 - 7B以下的模型发出格式错误的调用。 通用模型无论大小如何都相同。错误源于模型，不是框架。
- Q4_K_M是生产下限。 Q3及以下在降低聊天质量之前降低工具调用可靠性。使工具调用的量化与工作负载相匹配。
快速要点
- 最佳整体(24GB VRAM): Gemma 4 27B——Q4_K_M、~16GB VRAM、在4个参考MCP服务器（文件系统、sqlite、puppet、github）中可靠。
- 最佳长上下文(24GB VRAM): GLM-5.1 32B——128K上下文、Q4_K_M下~20GB VRAM。
- 最佳代码形: Qwen3-Coder 30B——Q4_K_M下~18GB VRAM、在
replace_in_file和代码MCP工具上最强。 - 最高上限: Llama 3.3 70B——Q4_K_M下~42GB VRAM、在链式工具调用上更可靠但较慢。
- 轻量级选择: Llama 3.2 3B——4-8GB VRAM、足以进行分类、不足以进行多步计划。
- 量化的生产下限: Q4_K_M。Q3及以下在降低聊天质量之前降低工具调用可靠性。
- 头条可靠性范围: 简单工作负载中90%+的格式良好调用；多步实际工作流中80-90%的端到端。
本地模型的工具调用意味着什么
工具调用是模型发出命名工具及其参数的结构化JSON——将聊天模型变为代理的LLM端能力。 MCP、OpenAI工具、Anthropic工具和Cline的XML都是相同底层技能的有线格式表达。
📍 简单一句话
工具调用是发出命名工具及提供与其模式匹配的参数的结构化JSON的LLM端能力；MCP、OpenAI工具和Cline的XML是相同技能表达。
💬 简单来说
工具调用模型可以读取可用工具列表，判断哪个适合用户请求，并生成命名工具及其参数的干净结构化响应。有线格式（JSON、XML、JSON-RPC）是工具框架决定；模型是否正确执行调用是模型属性——这就是本指南测量的。
- 模型需要的能力： 读取工具模式，判断用户请求是否映射到工具调用，并发出结构化响应命名工具并提供与模式匹配的参数。不是包含工具调用形文本的自由散文——工具框架可以不用启发式分析的结构化对象。
- 有线格式变化；能力不变。 在OpenAI的JSON工具格式上可靠执行工具调用的模型通常在Cline的XML和MCP的JSON-RPC上也可靠执行。能力转移；重新格式化失败是表面的。
- 工具调用训练是最便宜和最高影响的训练后通过。 Gemma 3→Gemma 4、Qwen2.5→Qwen3和Llama 3→Llama 3.3的步骤都体现这一点。新的旗舰开放权重发行常规添加或改进工具调用训练；这就是将上面的可靠列表与开放权重景观的其余部分区分开来的原因。
- 为什么对代理特别重要： 代理循环是工具调用的序列。即使95%的单个调用可靠性也会复合——8个步骤在95%处成功~66%的时间。为复合计划——保持计划地平线短、使用批准网关并倾向于最小可靠模型处理最长现实地平线。
- 提高任何兼容模型的工具调用可靠性的提示技术，参见思维链提示和思维树和ReAct——两者都降低模型选择错误工具或提供错误参数的速率。
💡Tip: 单个调用可靠性在代理循环中复合。95%的单个调用率在8个步骤中成功~66%的时间。为复合计划——保持计划地平线短、使用批准网关并倾向于最小可靠模型处理最长现实地平线。
我们如何测试
测试保持工具框架恒定，仅改变模型。 相同的MCP客户端、相同的服务器、相同的提示——失败归因于模型，不是运行时。
- 设置： VS Code中的Cline 3.x（我们测试过的最严格的工具调用验证器）以及无头端的Goose+MCP。后端Ollama 0.5+在Q4_K_M下处理每个模型，除非另有说明。
- 服务器： 4个参考MCP服务器——
文件系统（读/写沙箱目录）、sqlite（默认只读，特定任务的写角色）、puppet（无头浏览器）、github（带细粒度PAT的PR和问题管理）。所有模型运行的服务器版本相同。 - 提示集： 每个服务器50个任务提示，每个模型重复3次 = 跨4个服务器每个模型600个评分调用（~3000跨5个模型）。提示涵盖单工具任务、多步计划和并行调用。
- 评分： 每个调用4个信号。格式良好、正确选择、正确参数、执行成功。
- 硬件： 较小模型用Apple M5 Max 64GB MacBook Pro（至GLM-5.1 32B）；Llama 3.3 70B用NVIDIA L40S 48GB和2×RTX 3090 24GB。所有运行以可用令牌速率维护（≥10令牌/秒）以便延迟不是故障模式。
- 诚实约束： 百分比作为范围报告，不是发明的尖锐数字。"~95%"表示我们的运行在测试集中落在92-96%之间；我们仅在差异足够小以至于精度会误导时四舍五入。
📌Note: 这些数字来自我们的测试工具框架，不是BFCL或ToolBench排行榜。公共基准直向相关但不与MCP服务器工作负载一对一转换——适合您堆栈的正确基准是您的堆栈。将此处的百分比视为起始假设，而非最终判定。
直接比较：2026年5个工具调用模型
相同工具框架，相同提示，不同模型。 Llama 3.3 70B在标题数上领先；较小模型在通常更重要的指标上领先——每VRAM美元的可靠性。
📍 简单一句话
为通用24GB Rig选择Gemma 4 27B，为长上下文选择GLM-5.1 32B，为代码选择Qwen3-Coder 30B，为均衡备选选择Qwen3 32B，为48GB+ VRAM和最高上限选择Llama 3.3 70B。
💬 简单来说
5个都工作。差异在于它们成本（VRAM）、它们专长（长上下文、代码、通用目的）以及多频繁在工具调用中略错误（几个百分点——可通过批准网关恢复）。
| 模型 | 大小 | VRAM (Q4_K_M) | 格式良好调用率 | 最佳用途 | 常见故障模式 |
|---|---|---|---|---|---|
| Gemma 4 27B | 27B | ~16 GB | ~95% | 24GB Rig上的通用代理 | 在链式调用上保守（在链接会成功的地方要求批准） |
| GLM-5.1 32B | 32B | ~20 GB | ~94% | 长上下文代理（128K开箱即用） | 长输入上偶发参数截断 |
| Qwen3 32B | 32B | ~20 GB | ~93% | 均衡——通用+轻代码 | Cline严格格式中偶发XML畸形 |
| Qwen3-Coder 30B | 30B | ~18 GB | ~96% (代码) / ~91% (非代码) | 代码代理（replace_in_file、read_file、代码感知浏览器） | 在非代码服务器上弱于通用选择 |
| Llama 3.3 70B | 70B | ~42 GB | ~97% | 硬件允许时最高上限 | 令牌速率缓慢使长代理循环困难 |
Gemma 4 27B：24GB Rig的标准选择
Gemma 4 27B是大多数团队应该首先安装的模型。 该大小最佳的工具调用训练，在Q4_K_M处于16GB统一内存或24GB VRAM，并在我们测试过的每个MCP服务器上传送干净的函数调用JSON。
- 优点： 严格遵守工具模式（低畸形调用率）、工具选择上的良好一般推理、24GB消费者GPU和Apple M系列机器上舒适。
- 故障模式： 链式工具调用上保守。Gemma 4有时会在Llama 3.3会调用下一个工具的地方暂停要求用户澄清。监督是目标时这是功能；想要自主时是摩擦点。
- 推荐量化： Q4_K_M。Q5_K_M改进聊天质量但不显著改进工具调用可靠性——额外VRAM美元最好花在更长的上下文预算上。
- 最佳工具框架配对： 任何可靠的运行时。Cline + Gemma 4是特别干净的配对，因为Gemma的保守主义与Cline的每步批准UX相符。
- 使用地点： 通用代理工作、文档处理、电子邮件分流、MCP基础文件系统和数据库工作。当您没有选择其他理由时的默认选择。
GLM-5.1 32B：长上下文选择
GLM-5.1 32B是输入较长时的正确选择。 128K上下文窗口开箱即用、强大的工具调用可靠性以及顶部5中唯一不需要上下文扩展微调以处理1小时会议转录或完整代码库读取的模型。
- 优点： 原生128K上下文（无绳刻度伪影）、可靠的工具调用JSON、略重于Gemma 4但在Q4_K_M处于24GB VRAM仍舒适。
- 故障模式： 非常长输入上偶发参数截断。当给定100K令牌文档并提示使用文档关键声明作为参数调用工具时，GLM-5.1有时在句号前截断参数。可恢复——Cline会表面畸形调用且模型重试——但会添加批准周期。
- 推荐量化： Q4_K_M。GLM-5.1的量化优雅性略低于Gemma 4；不要在工具调用工作负载处Q4以下。
- 使用地点： 合规报告生成、长格文档分析、代理任务需要模型在上下文中持有整个代码库。当上下文长度是约束时选择。
Qwen3 32B：均衡备选
Qwen3 32B是能够执行所有操作且第一名没有的模型。 当您为通用和轻代码工作组合需要一个模型而不想操作两个安装时选择。
- 优点： 跨4个MCP服务器的一致工具调用可靠性、良好的一般推理、在24GB GPU上足够快以处理长代理循环。
- 故障模式： Cline严格格式中偶发XML畸形。发生时，代理循环干净重试——这是实践中低影响故障模式。
- 推荐量化： Q4_K_M。Qwen3优雅量化；如果有VRAM，Q5_K_M是小升级。
- 使用地点： 混合工作负载，您不想每个任务切换模型。"团队一个模型"选择。
Qwen3-Coder 30B：代码形选择
Qwen3-Coder 30B是代码形MCP工作的最好工具调用者。 replace_in_file、read_file、代码感知浏览器操作和GitHub PR管理都从烘焙的代码微调中受益。
- 优点： 代码MCP工具上最高的格式良好调用率(~96%)、多文件代理任务上强、比其他32B选择更低的VRAM(Q4_K_M下~18GB)。
- 故障模式： 非代码服务器上较弱。Sqlite和puppet可靠性与Gemma 4相比下降——Qwen3-Coder比通用模型更少慣用地处理数据库查询和浏览器操作。
- 推荐量化： Q4_K_M。如果想要更尖锐的代码推理，Q5_K_M是小步。
- 使用地点： Cline + Continue.dev代码代理、回购重构、探索性漏洞调试。如果你的代理也触碰非代码服务器，与Gemma 4配对。
Llama 3.3 70B：最高上限
Llama 3.3 70B是2026年5月开放权重生态中最可靠的工具调用者。 仅在硬件允许时使用——较小模型通常足以处理日常工作。
- 优点： 跨4个服务器最高的格式良好调用率(~97%)、最强的链式调用可靠性、对混乱输入的鲁棒性。您停止因责怪工具框架的模型。
- 故障模式： 速度。Llama 3.3 70B在单个L40S 48GB的Q4_K_M处支持~10–15令牌/s；长代理循环感觉缓慢。在2×RTX 3090分割推论中，吞吐量改进但设置更复杂。
- 推荐量化： Q4_K_M是下限；如果VRAM允许(~52GB)Q5_K_M是首选。Llama 3.3优雅量化——Q4和Q5之间的差异小于Gemma 4。
- 使用地点： 可靠性比速度重要时的工作流(合规报告、法律审查、异常处理)。或任何有多余硬件的设置。
💡Tip: Llama 3.3 70B在Q4_K_M处需要~42GB VRAM; 舒适地装在单个L40S 48GB或带分割推论的2×RTX 3090 24GB中; 在有64GB+统一内存的Apple M系列机器上运行。每令牌吞吐量是实践约束——长代理循环即使每个调用可靠也感觉缓慢。
工具调用不工作的模型
模型的3个类别无论工具框架如何都以相同方式失败。 停止尝试让它们工作；切换到上面的可靠选择之一。
- Sub-7B模型。 Llama 3.2 1B、Llama 3.2 3B、Phi-3 Mini、Gemma 2 2B——所有在平凡单步任务以外发出格式错误的工具调用。可接受的分流分类（输出是短字符串）；不可接受的多步计划。
- 没有工具调用训练的通用模型。 大多数通用7B–13B聊天模型无显式工具调用微调将工具调用转述为散文、误配参数模式或发明不存在的工具。模型类别是故障，不是大小。
- 可靠模型的重量化版本。 Q3、Q2和IQ-量子在降低聊天质量之前降低工具调用可靠性。Q3 Gemma 4 27B是比Q4 Qwen3 32B更差的工具调用者即使在聊天质量上相当基准。使量化与工作负载相匹配——Q4_K_M是生产下限。
- 症状当你尝试。 Cline中的格式错误XML（工具调用块解析器无法提取）、Aider中转述的SEARCH/REPLACE块、Continue.dev中不匹配开放文件的围栏代码、以及模型建议相同调用两次的停滞代理循环。都不是工具框架漏洞——切换框架会在不同形状中显示相同故障。
⚠️Warning: 工具调用的Sub-7B模型是我们看到的最大的时间浪费。症状("工具框架坏了"、"MCP坏了"、"Cline坏了")全指向模型。切换到工具调用训练27B+，堆栈中别的都不改，症状消失。
工具调用格式：相同技能，不同有线格式
相同模型处理所有4种格式。 格式选择是工具框架/协议决定，不是模型决定。
- 格式可移植性声明： 上面的5个可靠模型无需每格式重新配置即处理4种格式。在Cline工具块上可靠工具调用的Gemma 4 27B通常在Goose+MCP和Continue.dev代理上可靠工具调用。
- 含义： 选择您的工具框架原生支持的格式，不是您的模型。模型是负重变量。
- 异常： Qwen3-Coder的SEARCH/REPLACE块准拜比Qwen3略好，因为代码微调强调差异保真。边缘——Qwen3 32B在Aider中也很好。
| 格式 | 在哪里看到 | 严格? | 对格式错误的宽容 |
|---|---|---|---|
| OpenAI工具(JSON) | OpenAI API、Continue.dev代理 | 模式验证 | 表面错误; 模型重试 |
| Cline XML工具块 | Cline VS Code扩展 | 非常严格 | 循环停滞; 小模型首先在这里受苦 |
| MCP JSON-RPC 2.0 | Goose、Cline、Continue.dev、LM Studio | 模式验证 | 表面错误; 模型重试; 生态收敛的有线格式 |
| Aider SEARCH/REPLACE块 | Aider CLI | 模式匹配、逐字 | 拒绝并重试; 小模型转述SEARCH块并失败 |
💡Tip: 选择您的工具框架原生支持的格式，不是基准好的格式。上面的5个可靠模型跨4种格式移植；工具框架UX(每步批准、审计跟踪、IDE整合)是实际成功的更大驱动力比格式选择。
工具调用模型选择中常见错误
- 错误1: 因工具调用故障责怪工具框架。 症状（格式错误XML、转述SEARCH块、不匹配开放文件的围栏代码）在工具框架间以不同表面形式显示；原因通常是缺少工具调用训练的模型。首先切换模型；仅在确认模型在其他地方可靠工具调用时切换工具框架。
- 错误2: 不足量化以装入较小GPU。 可靠27B的Q3和IQ-量子通常比下一大小的Q4_K_M更差。将模型和量化作为对选择，不是独立。
- 错误3: 对"简单"工具调用使用小通用模型。 提示中的"简单"不是7B通用模型的"简单"——格式错误调用率足够高以至于即使单步任务在5–10%的运行中停滞。对分流分类使用Llama 3.2 3B且对工具调用使用Gemma 4 27B（或更大）。
- 错误4: 忽略链式工具调用复合。 95%复合跨代理循环步骤。8步任务在95%处成功~66%的时间。为复合计划——保持计划地平线短、使用批准网关并倾向于最小可靠模型处理最长现实地平线。
- 错误5: 追逐排行榜数字而不是MCP可靠性。 公共基准是有用信号但不与MCP服务器工作负载一对一转换。适合您堆栈的正确基准是您的堆栈。如果无法运行那个，倾向于此列表中的模型——它们生存真实工作负载。
来源
- 模型上下文协议规范 — JSON-RPC模式、传输和测试工具框架中使用的生命周期定义。
- Berkeley函数调用排行榜(BFCL) — 公共函数调用基准; 有用的方向信号，不是MCP等价。
- Ollama模型库 — 模型可用性、工具调用支持标志、上述量化级别。
- modelcontextprotocol/servers GitHub仓库 — 测试集使用的参考文件系统、sqlite、postgres、puppet和github服务器。
- Hugging Face模型卡 Gemma 4、GLM-5.1、Qwen3、Qwen3-Coder、Llama 3.3 — 官方工具调用训练文档。
FAQ
2026年本地工具调用中最高成功率的模型是什么？
Llama 3.3 70B在我们测试的4个参考MCP服务器中具有最高的格式良好调用率(~97%)。Q4_K_M下需要48GB+ VRAM，因此大多数用户选择较小可靠模型之一——通用工作Gemma 4 27B、长上下文GLM-5.1 32B、代码Qwen3-Coder 30B、均衡备选Qwen3 32B。4个27B-32B选择落在93-96%范围且对带批准网关的生产代理工作足够可靠。
Gemma 4原生工具调用无提示技巧工作？
是的。Gemma 4 27B从标准聊天格式直接发出干净的函数调用JSON和干净的Cline XML——无工具特定提示、无JSON模式包装、无系统提示呪咒必要。模型在事后训练阶段进行工具调用训练；像任何聊天模型一样调用它，系统提示中的工具列表，其余部分处理。
Llama 3.3 70B能否可靠执行工具调用？
是——测试的5个模型中可靠性最高。折衷是硬件: Q4_K_M下需要~42GB VRAM，因此舒适地装在单个L40S 48GB或分割推论2×RTX 3090 24GB及64GB+统一内存Apple M系列。每令牌吞吐量是实践约束——长代理循环即使每个调用可靠也感觉缓慢。
哪个模型最好处理并行函数调用？
Llama 3.3 70B领先并行调用可靠性——当提示是"同时列表这3个目录"时，70B更清洁地发出并行调用。Gemma 4 27B和Qwen3 32B紧密追随。Qwen3-Coder 30B在并行调用上略弱因为代码微调偏向顺序编辑。边缘——对大多数代理工作负荷，并行调用可靠性比链式调用可靠性重要性小——链式在实践中更常见。
量化版本在工具调用中性能更差？
是且降级在降低聊天质量之前降低工具调用可靠性。Q3 Gemma 4 27B是比Q4 Qwen3 32B更差工具调用者即使在聊天质量上相当基准。匹配量化与工作负荷——Q4_K_M是生产下限; Q5_K_M是安全步; Q3及以下不建议代理工作。
我可以微调更小模型以获得更好的工具调用吗？
可能但价值不高。上述5个模型有在事后训练阶段原生的工具调用训练; 社区微调在较小基础上通常不匹配。使用可靠模型之一。如有域特定工具表面，小LoRA在Gemma 4或Qwen3顶部可锐化模式准拜——但不会非工具调用模型变成可靠工具调用者。
哪个模型对JSON输出最可靠？
可靠JSON输出和可靠工具调用相关但不同。纯JSON模式工作，Gemma 4 27B和GLM-5.1 32B最强——两者无后续散文发出干净JSON。工具调用特定：5个可靠模型都合格；他们在工具调用包装内发出的JSON格式良好。
工具调用是否在仅CPU设置中工作？
技术上是，实际上困难。Gemma 4 27B在Q4_K_M下在32GB CPU上支持~1-3令牌/s; 多步任务的代理循环需要30K-80K令牌花小时。仅CPU对评估和小模型分流分类(Llama 3.2 3B)很好；生产代理，GPU或Apple Silicon统一内存是实践下限。