重要なポイント
- 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サーバー全体で正しく形成された呼び出しレート — 48GB + VRAMが必要です。ハードウェアが適合する場合にのみ使用。小さいモデルで十分です。
- Gemma 4 27Bは24GBリグの標準的な選択肢です。 サイズのベストインクラスツール呼び出しトレーニング、チェーンされた呼び出しで保守的。ファイルシステム、データベース、GitHub MCPサーバーで信頼できます。
- GLM-5.1 32Bは長いコンテキストエージェントタスクに勝ちます。 128Kのコンテキストウィンドウを直接使用できます。引数トランケーションはまれな唯一の一般的な欠陥です。コンプライアンスレポートと長いトランスクリプトに選択してください。
- Qwen3-Coder 30Bは最高のコード形状ツール呼び出し機です。
replace_in_file、read_file、コード認識ブラウザアクションで強い; Gemma 4よりもコード以外のMCPサーバーで弱い。 - 7B以下のモデルは不正な形式の呼び出しを発行します。 明示的なツール呼び出しトレーニングのない汎用モデルも同じです。エラーはハーネスではなく、モデルです。
- Q4_K_Mは本番フロアです。 Q3以下は、チャット品質を低下させる前にツール呼び出しの信頼性を低下させます。量子化をVRAMバジェットだけでなくワークロードに適応させます。
クイックファクト
- ベスト全体(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ステップで~66%が成功します。構成を計画 — プランの地平線を短く保つ、承認ゲートを使用し、最長の現実的な地平線を処理する最小の信頼できるモデルを選択してください。
- ツール呼び出しの信頼性を改善するためのプロンプト技術については、チェーン・オブ・ソート・プロンプティングとシンク・オブ・ソート・リアクトを参照してください — どちらもモデルが間違ったツールを選択するか、間違った引数を提供する率を低下させます。
💡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 graded呼び出し(~3000は5つのモデル全体)。プロンプトは単一ツールタスク、マルチステッププラン、並列呼び出しをカバーします。
- グレーディング : ツール呼び出しあたり4つのシグナル。正しく形成された、正しい選択、正しい引数、実行成功。
- ハードウェア: Apple M5 Max 64GB MacBook Pro for小さいモデル; NVIDIA L40S 48GB と 2×RTX 3090 24GBはLlama 3.3 70B向けです。すべてが使用可能なトークンレート(≥10トークン/秒)で維持されました。
- 正直さの制約: パーセンテージは範囲として報告されます。"~95%"は92-96%の範囲を意味します。
📌Note: これらの数値は、BFCLまたはToolBenchリーダーボードではなく、テストハーネスから取得しています。パブリックベンチマークは直接的に相関しますが、MCPサーバーワークロードと1対1の相関はしません。あなたのスタックに適したベンチマークはあなたのスタックです。これらのパーセンテージを開始仮説として扱い、最終的な判定として扱うのではなく。
直接比較: 2026年の5つのツール呼び出しモデル
同じハーネス、同じプロンプト、異なるモデル。 Llama 3.3 70Bは見出しで導く;小さいモデルはしばしば重要なメトリクスで導く—VRAMドルあたりの信頼性。
📍 一文で説明
汎用24GBリグには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リグでの汎用エージェント | チェーンされた呼び出しで保守的(チェーンが機能したであろう場合に承認を求める) |
| 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リグの標準的な選択肢
Gemma 4 27Bは、ほとんどのチームが最初にインストールする必要があるモデルです。 サイズのベストインクラスツール呼び出しトレーニング、16GBの統合メモリまたは24GB VRAMをQ4_K_Mで保持、そしてテストした各MCPサーバー上でクリーンなJSON関数呼び出しを配信します。
- 強み: ツール スキーマ への厳密な準拠(低い不正形成呼び出しレート)、ツール選択で優れた一般的な推論、24GBコンシューマGPUとApple Mシリーズマシンで快適。
- 障害モード: チェーンされたツール呼び出しで保守的。Gemma 4は、Llama 3.3が次のツールを呼び出したであろう場所で、ユーザーに明確化の質問を求めることがあります。
- 推奨量子化: Q4_K_M。Q5_K_Mはチャット品質を改善しますが、ツール呼び出し信頼性を著しく改善しません。
- ベストハーネスペアリング: 任意の信頼できるランタイム。Cline + Gemma 4 は Clineのステップごと承認UXとGemmaの保守主義が整列するため特に清潔なペアリングです。
- 使用場所: 汎用エージェント作業、ドキュメント処理、Eメールトリアージ、MCPベースのファイルシステムとデータベース作業。特定の理由がない場合はデフォルトの選択肢。
GLM-5.1 32B: 長いコンテキストの選択肢
GLM-5.1 32Bは、入力が長い場合の正しい選択肢です。 128Kのコンテキストウィンドウをボックスから直接取得し、強力なツール呼び出し信頼性があり、1時間のミーティングトランスクリプトまたはフルコードベースの読み取りにコンテキスト拡張ファインチューンが必要ないトップ5の唯一のモデルです。
- 強み: ネイティブ128Kコンテキスト(ropeスケーリングの成果物なし)、信頼できるツール呼び出し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は、すべてを能力的に実行し、最初の場所で何もなく行うモデルです。 汎用作業と軽いコード作業の組み合わせのために1つのモデルが必要な場合を選択; 2つのインストールを操作しません。
- 強み: 4つのMCPサーバー全体での一貫したツール呼び出し信頼性、優れた一般的な推論、24GB GPU上の長いエージェントループに対して十分な速度。
- 障害モード: Clineのきつい形式でまれなXML不正形成。発生した場合、エージェントループはクリーンに再試行します — これは実践では低影響の障害モードです。
- 推奨量子化: Q4_K_M。Qwen3はエレガントに量子化します; Q5_K_MはあなたがVRAMを持っている場合の小さな勾配です。
- 使用場所: タスク別にモデルを切り替えたくない場合は、混合ワークロード。「チーム用の1つのモデル」選択。
Qwen3-Coder 30B: コード形状の選択肢
Qwen3-Coder 30Bはコード形状のMCP作業で最高のツール呼び出し機です。 replace_in_file、read_file、コード認識ブラウザアクション、GitHub PR管理はすべて、焼き付けられたコードファインチューニングから利益を得ます。
- 強み: コードMCPツール(~96%)の最高のwell-formed呼び出しレート、マルチファイルエージェントタスク上で強い、他の32Bピックより低いVRAM(~18GB at Q4_K_M)。
- 障害モード: コード以外のサーバーでより弱い。SqliteとPuppeteerの信頼性は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つのサーバー全体で最高のwell-formed呼び出しレート(~97%)、最も強いチェーンされた呼び出し信頼性、不潔な入力への耐性。ハーネスのせいにするのをやめるモデル。
- 障害モード: スピード。Llama 3.3 70B at Q4_K_M on single L40S 48GBは~10–15トークン/sを保持; 長いエージェントループは遅く感じます。2×RTX 3090分割推論では、スループットが改善されますが、セットアップが関係しています。
- 推奨量子化: Q4_K_Mはフロアです; VRAMが許す場合はQ5_K_Mが好まれます(~52GB)。Llama 3.3はエレガントに量子化します — Q4とQ5の違いはGemma 4より小さいです。
- 使用場所: 信頼性がスピードより重要な場合のワークフロー(コンプライアンスレポート、法的レビュー、例外処理)。またはスペアハードウェアを持つセットアップ。
💡Tip: Llama 3.3 70B at Q4_K_Mは~42GB VRAMが必要です; 単一のL40S 48GBまたは分割推論を備えた2×RTX 3090 24GBに快適に適合;Apple Mシリーズマシンで64GB+統合メモリで実行されます。トークンごとのスループットは実践的な制約です — 長いエージェントループはそれぞれの呼び出しが信頼できるとしても遅く感じます。
ツール呼び出しが機能しないモデル
3つのカテゴリのモデルはハーネスに関係なく同じ方法で失敗します。 それらを機能させようとするのをやめる; 上記の信頼できるピックの1つに切り替えます。
- Sub-7Bモデル。 Llama 3.2 1B、Llama 3.2 3B、Phi-3 Mini、Gemma 2 2B — すべてが自明な単一ステップタスクを超えて不正な形式のツール呼び出しを発行します。トリアージ分類に受け入れ可能(出力は短い文字列); マルチステッププランには不可。
- 明示的なツール呼び出しトレーニングのない汎用モデル。 ほとんどの一般的な7B–13B チャットモデルは、ツール呼び出しを散文にパラフレーズし、引数スキーマを不正適合させ、存在しないツールを発明します。モデルクラスはエラー; サイズではなく。
- 信頼できるモデルの重く量子化されたバージョン。 Q3、Q2、IQ-quantsはツール呼び出し信頼性をチャット品質より前に低下させます。Q3 Gemma 4 27BはQ4 Qwen3 32Bより悪いツール呼び出し機です。
- 症状。 Clineの不正なXML、Aiderの言い換えられたSEARCH/REPLACEブロック、Continue.devの開いたファイルと一致しないフェンシングコード、そして同じ呼び出しを2回連続で提案しているモデルを持つ停滞したエージェントループ。どれもハーネスバグではなく、ハーネスを切り替えるとハーネスのさまざまな形で同じ障害が表示されます。
⚠️Warning: ツール呼び出しの場合のSub-7Bモデルは、私たちが見る最大の時間浪費です。症状(「ハーネスは壊れている」、「MCPは壊れている」、「Clineは壊れている」)はすべてモデルを指します。Tool-Call-トレーニング27B+に切り替えると、スタック内の他に何も変えずに症状は消えます。
ツール呼び出し形式: 同じスキル、異なるワイヤフォーマット
同じモデルが4つの形式をすべて処理します。 形式の選択はハーネス/プロトコル決定であり、モデル決定ではありません。
- 形式移植性クレーム: 5つの信頼できるモデルすべてが、形式ごとの再構成なしで4つの形式を処理します。
- 意味: ハーネスがサポートする形式を選択する; モデルは負荷は軸変数です。
- 例外: Qwen3-Coderのサーチ/交換ブロック準拠はQwen3より少し良いです。
| 形式 | どこで見えるか | きつい? | 不正な出力への寛容さ |
|---|---|---|---|
| OpenAIツール(JSON) | OpenAI API、Continue.dev Agent | スキーマ検証 | エラーを表面化; モデルが再試行 |
| 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サーバーワークロードと1対1で翻訳されません。スタックに適したベンチマークはあなたのスタックです。あなたがそれを実行できない場合は、このリスト内のモデルを好む — 彼らは実際のワークロードを生き残ります。
ソース
- モデルコンテキストプロトコル仕様 — JSON-RPCスキーマ、トランスポート、テストハーネスで使用されるライフサイクル定義。
- Berkeley Function Calling Leaderboard (BFCL) — 公開関数呼び出しベンチマーク; 有用な方向信号、MCP相当ではなく。
- Ollama Model Library — モデル可用性、ツール呼び出しサポートフラグ、上記の量子化レベル。
- modelcontextprotocol/servers GitHub Repository — テストセットで使用される参照ファイルシステム、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サーバーの最高のwell-formed呼び出しレート(~97%)を持っています。Q4_K_MでVRAMを48GB+必要のため、ほとんどのユーザーは小さい信頼できるモデルの1つを選択します — 一般作業の場合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_K_Mの同じモデルより明らかに悪いツール呼び出し機です。Q4_K_Mは5つの信頼できるモデルの本番フロアです; Q5_K_Mは安全な手順です; Q3以下はエージェント作業に推奨されません。
より良いツール呼び出しのためにより小さなモデルをファインチューンできますか?
可能ですが、価値が低いことがあります。上記の5つのモデルは事後トレーニング段階で組み込まれたツール呼び出しトレーニングを持っています。コミュニティファインチューンは通常一致しません。信頼できるモデルの1つを使用してください。ドメイン固有のツール表面がある場合、小さいLoRAはシステムの準拠を鋭くする可能性があります — しかし非ツール呼び出しモデルを信頼できるツール呼び出し機に変えることはできません。
どのモデルがJSON出力に最も信頼できるですか?
信頼できるJSON出力と信頼できるツール呼び出しは相関していますが、同じではありません。純粋なJSON-modeの仕事のために、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-onlyはテスト。本番エージェント用、GPUまたはApple Silicon統合メモリは実践フロアです。