FunctionGemma 與專用工具呼叫模型的崛起

Google 悄悄發布了一個比大多數人意識到的更重要的東西：FunctionGemma。這是一個擁有 2.7 億參數的 Gemma 3 模型——不是十億，是百萬——專門且完全為函數呼叫而微調。

2.7 億參數。比 BERT 還小。以 FP16 格式只需 540MB RAM，量化後不到 200MB。可以在 Raspberry Pi 上運行。它的工作只有一件事：接受用戶訊息和一組工具模式，輸出正確的函數呼叫及正確的參數。

這不是一個也能進行工具呼叫的通用模型。這是一個專為工具呼叫而建構的引擎。它標誌著我們建構 AI 系統方式的根本性轉變。

FunctionGemma 實際做什麼

FunctionGemma 接受兩個輸入：

1. 一組函數定義（帶有名稱、描述和參數類型的工具模式）
2. 一條用戶訊息

並產生一個輸出：

一個結構化的函數呼叫——函數名稱及其 JSON 格式的參數。

就是這樣。它不聊天，不做摘要，不寫詩。它將自然語言意圖映射到函數調用。一項任務，做好它。

範例

輸入：

可用函數：
- get_weather(location: string, unit: "celsius" | "fahrenheit") → 某地點的天氣資料
- search_restaurants(city: string, cuisine: string, price_range: 1-4) → 餐廳列表

用戶：「柏林的天氣怎麼樣？」

輸出：

{"function": "get_weather", "arguments": {"location": "Berlin", "unit": "celsius"}}

沒有前言，沒有解釋，沒有「當然，我很樂意幫助！」只有函數呼叫。

為何 2.7 億參數是個大事

為了理解 FunctionGemma 代表什麼，請與替代方案比較：

*準確率在 Berkeley Function Calling Leaderboard（BFCL）標準任務上測量。實際結果因工具複雜度而異。

FunctionGemma 在標準函數呼叫基準上以比 Llama 3.3 8B 少 30 倍的參數達到 82-88% 的準確率。它使用的 RAM 少 22 倍。僅在 CPU 上，它生成 token 的速度比 8B 模型快 10-15 倍。

對於標準 API 工具——天氣、搜尋、CRUD 操作、資料庫查詢——這通常足夠好。那 200MB 的「足夠好」開啟了 4.5GB 的「非常好」無法觸及的部署場景。

這預示著什麼：「一個模型做所有事」的終結

在過去三年，主流模式一直是：選擇您能負擔得起的最聰明模型，用它做所有事情。GPT-4 用於工具呼叫、GPT-4 用於摘要、GPT-4 用於分類、GPT-4 用於生成。一個模型、一個 API 金鑰、一份帳單。

FunctionGemma 代表相反的哲學：建構（或使用）一個只做一件事的模型，讓它在那件事上盡可能小和快。

這在軟體工程中不是新想法。我們不用資料庫伺服器來提供靜態文件服務。我們不用 Web 框架來處理批次 ETL 任務。專業化在除 AI 之外的各個地方都是常態，在 AI 中「使用 GPT-4」一直是每個問題的答案。

這種轉變正在發生，因為：

1. 開放權重模型變得足夠好可以進行專業化。您無法將 GPT-4 微調成專家（不是真的）。您可以微調 Gemma、Llama 和 Qwen。
2. 部署成本現在很重要。 原型階段已經結束。團隊每天運行 10K-100K 以上的查詢，API 帳單是真實的項目支出。
3. 延遲現在很重要。 用戶期望毫秒級回應。2.7 億模型在毫秒內回應。8B 模型在 CPU 上需要幾秒鐘。
4. 邊緣部署是真實的。 設備端、瀏覽器內、嵌入式硬體上——您需要適合受限環境的模型。

何時使用 FunctionGemma vs 微調自己的模型

這是實際問題。FunctionGemma 存在。您應該使用它嗎？

直接使用 FunctionGemma 的時機：

您的工具是標準的。 如果您的函數模式看起來像典型的 REST API——CRUD 操作、搜尋端點、資料擷取——FunctionGemma 可能在訓練資料中見過類似模式。標準工具包括：

• 天氣、搜尋、地圖 API
• 資料庫讀寫操作
• 電子郵件、日曆、通知服務
• 支付處理（標準模式）
• CRM 操作（如果使用常見欄位名稱）

82-88% 的準確率是可接受的。 對於非關鍵應用程式、內部工具或有人工審核的系統，這個命中率有效。12-18% 的失敗主要是參數級別的錯誤（類型錯誤、缺少可選欄位），而非完全選錯函數。

您需要最小的部署佔用空間。 如果模型需要在 512MB RAM 的設備上運行，或在瀏覽器中通過 WebAssembly 運行，或在 $35 的單板電腦上運行，FunctionGemma 是為數不多的選項之一。

微調自己模型的時機：

您的工具是自定義的或特定領域的。 帶有非顯而易見命名慣例的內部 API、專有模式、特定領域術語。FunctionGemma 從未見過您的 initiate_claims_adjudication 函數。微調模型已見過它數百次。

您需要 95% 以上的準確率。 對於工具呼叫錯誤會造成真實問題的生產系統——金融交易、醫療保健工作流程、自動化部署——您需要在特定工具上訓練帶來的準確率。微調的 7B 模型在它們訓練的特定工具上常規達到 95-98%。

您有複雜的參數邏輯。 當正確的參數取決於不在函數描述中的上下文時——「使用客戶的首選倉庫，而非預設」或「企業帳戶始終設置優先級為高」——通用模型無法學習這些規則。微調模型可以。

微調 FunctionGemma 的時機：

這是有趣的選項。使用 FunctionGemma 作為基礎模型並在您的特定工具模式上微調它。您得到：

• 為函數呼叫而建構的模型的架構優勢
• 在您特定工具上訓練帶來的準確率提升
• 仍然很小的模型（微調通過 LoRA 增加 10-50MB）

早期結果顯示微調的 FunctionGemma 在自定義工具模式上達到 90-94% 的準確率——與微調的 3B 模型相當，但體積小 10 倍。取捨：複雜的多工具序列仍然偏好更大的模型。

決策框架

以下是如何選擇：

開始
  │
  ├── 您的工具是具有常見模式的標準 API 嗎？
  │     ├── 是 → 82-88% 的準確率可以接受嗎？
  │     │          ├── 是 → 直接使用 FunctionGemma
  │     │          └── 否 → 在您的模式上微調 FunctionGemma
  │     └── 否 → 您的工具是高度自定義/特定領域的嗎？
  │                ├── 是 → 微調 Qwen 2.5 7B 或 Llama 3.3 8B
  │                └── 中等 → 在您的模式上微調 FunctionGemma
  │
  ├── 您需要多步驟工具序列（連鎖 3 個以上工具）嗎？
  │     ├── 是 → 微調 7B 以上模型（FunctionGemma 專注於單步驟）
  │     └── 否 → FunctionGemma 或微調的 FunctionGemma
  │
  └── 部署限制？
        ├── 邊緣/設備（不足 1GB RAM） → FunctionGemma（微調或未微調）
        ├── 伺服器（8-16GB RAM） → 微調的 7B 模型
        └── 無限制 → 根據準確率需求選擇

比較：FunctionGemma vs 微調替代方案

結論：FunctionGemma 不是複雜場景中微調 7B 模型的替代品。它是一個在一小部分資源成本下用於簡單到中等工具呼叫的新選項。

更大的圖景：特定任務模型是未來

FunctionGemma 是趨勢中的一個資料點。預期會看到：

• 分類模型，不足 5 億參數，以比提示詞 GPT-4 更快、更便宜的方式將文字分類
• 提取模型，專為從非結構化文字中提取結構化資料而建構
• 路由模型，決定對給定請求使用哪個工具、哪個模型或哪個管道
• 驗證模型，檢查生成的輸出是否符合模式或品質標準

未來的架構不是一個大模型。而是一個小型專家的圖，每個都做一件事：

用戶請求 → 路由器 (100M) → 選擇的專家
  ├── 工具呼叫者 (270M - FunctionGemma)
  ├── 摘要器 (1B)
  ├── 分類器 (500M)
  └── 生成器 (7B - 僅在需要完整語言生成時)

系統總 RAM：可能 6-8GB。延遲：大多數路徑不到 100ms。成本：每次查詢零費用。

相比之下，將每個請求發送到 GPT-4：每次查詢 $0.03，500-2000ms 延遲，完全無法離線運行，完全依賴第三方 API。

這對 Ertas 用戶意味著什麼

如果您已經在使用 Ertas 微調模型，FunctionGemma 為您的工具箱提供了一個新選項：

對於新的工具呼叫專案： 從 FunctionGemma 開始。上傳您的工具模式，生成訓練範例，微調。如果準確率足夠（在您的評估集上測試），部署它。如果不夠，升級到 7B 基礎模型並微調那個。

對於現有部署： 如果您有一個微調的 7B 模型同時處理簡單和複雜的工具呼叫任務，考慮分割：簡單路由用 FunctionGemma，複雜路由用 7B 模型。您釋放了 GPU 容量並降低了簡單路徑的延遲。

對於邊緣部署： FunctionGemma 是第一個使設備端工具呼叫實際可行的模型。移動應用程式、信息亭、IoT 閘道——任何需要在沒有網路存取的情況下工作的 AI 代理，這是起點。

如何在 Ertas 上微調 FunctionGemma

流程與任何其他模型相同：

1. 準備您的工具呼叫資料集（輸入：用戶訊息 + 工具模式，輸出：函數呼叫 JSON）
2. 選擇 FunctionGemma 作為基礎模型
3. 配置 LoRA（考慮模型的小尺寸，rank 8-16 就足夠了）
4. 訓練 3-5 個 epoch（在單個 GPU 上需要 5-10 分鐘）
5. 在您的測試集上評估
6. 部署——模型在不到 300MB 的 RAM 中提供服務

微調很快，因為模型很小。您可以快速迭代：訓練、評估、調整訓練資料、重新訓練。一個完整週期在 30 分鐘內完成。

誠實的評估

FunctionGemma 在其所做的事情上令人印象深刻。它不是萬能的。以下是真實的限制：

• 無多輪推理。 它處理單輪函數呼叫。對於多步驟代理，您仍然需要更大的模型或專家架構。
• 有限的上下文視窗。 擁有 2.7 億參數，上下文視窗很小。如果您有 20 個以上帶有複雜模式的工具，模型會掙扎。最好每次請求 3-10 個工具。
• 無對話能力。 它無法解釋為何選擇某個函數或提出澄清問題。它映射輸入到輸出。對於對話代理，與聊天模型配對使用。
• 基準 vs 現實。 82-88% 的基準準確率是在乾淨、格式良好的請求上。真實用戶輸入是雜亂的。在沒有微調的情況下，預計生產流量的準確率會低 5-10%。

儘管有這些限制，FunctionGemma 的存在改變了計算方式。問題不再是「小型模型能做工具呼叫嗎？」而是「對於這個特定使用案例，我們能做多小？」

延伸閱讀

• 微調小型模型 vs GPT-4：小模型勝出的時機 — 特定任務小型模型優於通用前沿 API 的更廣泛論據
• 2026 年最佳微調開源模型 — FunctionGemma 與 Qwen、Llama、Mistral 和其他基礎模型的對比定位
• 工具呼叫微調：如何建構可靠的 AI 代理 — 使用微調模型建構工具呼叫代理的完整指南