Fine-Tune FunctionGemma with Ertas

Google 為工具呼叫量身打造的 270M 參數模型——一個 Gemma 3 衍生模型,專為將自然語言意圖映射到函式呼叫而訓練。是開源權重生態系中最小、最具公信力的函式呼叫模型,也是針對你自家工具 schema 進行微調的明確邀請。

270MGoogle

Overview

FunctionGemma 是 Google 於 2026 年 5 月 5 日釋出的 2.7 億參數 Gemma 3 衍生模型,只為一個工作而訓練：接受使用者訊息加上一組工具 schema,並發出帶正確參數的正確函式呼叫。它不聊天、不總結,也不做長篇推理。它將意圖映射到調用,且以一個小到可在 Raspberry Pi、手機或 Jetson Nano 上執行的模型大小達成——Q4 量化下不到 200MB。

這個模型是 Google 圍繞「為特定目的打造的小模型」更廣泛敘事的一部分。Gemma 3 與 Gemma 4 是具備原生多模態能力的通用家族,而 FunctionGemma 則被 Google 明確定位為微調的*基底*。他們在 model card 中陳述的意圖毫不含糊：「打算為你特定的函式呼叫任務進行微調。」這在開源權重釋出中相當不尋常——多數實驗室出貨通用 checkpoint,並預設將專業化交給使用者,但 FunctionGemma 的訓練與定位將微調推向建議工作流程的最前端。

FunctionGemma 在標準 Berkeley Function Calling Leaderboard（BFCL）任務上開箱即達到 82–88%,與大 10–30 倍的 3B–8B 通用模型具有競爭力。在領域特定工具 schema 上微調後——通常為 200–1,000 個精心整理的函式呼叫範例——目標工具上的準確率經常攀升超過 95%,在同一評估集上超越通用 7B–14B 模型所達到的水準。這種小腳印加上「微調後專業化」的組合,使 FunctionGemma 成為 2026 年「代理專家」趨勢的標準範例。

Key Features

FunctionGemma 的輸入格式是一個系統區塊,列出可用函式及其參數 schema,接著是使用者訊息。模型發出單一結構化輸出：函式名稱與其 JSON 形式的參數。沒有對話層、沒有前言、也沒有散文——輸出直接以函式呼叫起頭。這使解析器整合變得簡單,並消除了通用模型透過提示式 JSON 格式化進行工具呼叫時困擾的後處理脆弱性。

模型以 Gemma Terms of Use（Gemma 3 時代的授權）授權。Google 尚未像 2026 年 4 月對 Gemma 4 那樣將 FunctionGemma 重新授權為 Apache 2.0,因此商業使用者在處理觸及禁止使用列表的使用情境時應審閱授權條款。對於多數產品應用——行動助理、代理工作流程、內部自動化——授權足夠寬鬆。

FunctionGemma 的 tokenizer 與基底架構繼承自 Gemma 3,因此標準 llama.cpp、Ollama、MLX 與 TensorRT-LLM 工具鏈都不需修改即可支援。提供從 Q2_K 到 Q8_0 的 GGUF 量化;Q4_K_M 產生約 180MB 的二進位檔,在消費級 GPU 上以 800+ tokens/秒運行,在現代筆記型電腦 CPU 上以 180–250 tokens/秒運行。

Fine-Tuning with Ertas

FunctionGemma 是 Ertas 工具呼叫產品故事的標準微調目標。訓練資料格式與 Ertas Studio 原生支援的 JSONL 函式呼叫 schema 相同：每個範例為一個工具列表、一個使用者查詢與預期的函式呼叫。因為模型如此小,全參數微調可裝在消費級 GPU 上——12GB RTX 3060 在不使用 LoRA 下以完整序列長度訓練 FunctionGemma——而 LoRA 與 QLoRA 也可運作,並產生少於 50MB 的介面卡,可在推論時熱切換。

針對 FunctionGemma 的典型 Ertas 工作流程是：在 Studio 的 Data Craft 模組中定義你的工具 schema、產生 300–800 個代表性的函式呼叫範例（使用發出 ChatGPT/Claude/Gemini 提示範本的批次產生流程）、分割為訓練/驗證、以 FunctionGemma 基底在 Studio 中微調、在保留的函式呼叫上評估並匯出為 GGUF。在代表性工具 schema 上的完整循環,於 Studio 的標準 GPU 階層上以 1–3 小時牆鐘時間執行,並產出在訓練工具集上達到 95%+ 準確率的模型。

對於行動部署,Ertas Deployment CLI 取得 GGUF 輸出,並將其接到已安裝 llama.cpp 相依的 iOS Swift、Android Kotlin、Flutter 或 React Native 專案中。端到端——從原始工具 schema 到在真實 app 中的裝置端執行的微調函式呼叫模型——是幾個小時的工作,主要由資料集整理而非訓練或部署管線主導。

Use Cases

FunctionGemma 的主要使用情境是代理系統內的函式呼叫層：將使用者請求轉成下游程式碼可執行的結構化工具調用。對於擁有少量高頻工具的行動 app——預訂、排程、搜尋、對使用者資料的 CRUD 操作——裝置端 200MB 的 FunctionGemma 完全替代了雲端 API 呼叫,消除按 token 成本並從延遲敏感流程中移除網路往返。

對於支援 OpenAI 相容端點的代理框架（LangGraph、Pydantic AI、OpenAI Agents SDK、Smolagents、Mastra、Vercel AI SDK）,FunctionGemma 可作為更大推理模型背後的專屬工具路由層。模式為：7B–14B 模型處理開放式推理,FunctionGemma 處理結構化工具呼叫發出,兩者都在本地執行。推論成本大幅下降而不犧牲工具呼叫可靠性。

小尺寸也使 FunctionGemma 成為嵌入式與邊緣部署的正確選擇：運算受限的工廠機器人、需要自然語言控制的 IoT 裝置、每一 MB 模型權重都受爭議的車載系統。任何通用 3B–8B 模型過大、但需要乾淨意圖到調用映射的場景,FunctionGemma 都是預設起點。

Hardware Requirements

在 Q4_K_M 量化下,FunctionGemma 權重約為 180MB,推論時需要約 250MB 總 RAM,包括短上下文的 KV 快取。這舒適地裝在手機（iOS 14+ 裝置、配備 2GB+ RAM 的 Android 裝置）、單板電腦（Raspberry Pi 4/5）、嵌入式板（Jetson Nano）以及任何筆記型或桌上型電腦上。

消費級硬體上的吞吐量：現代筆記型電腦 CPU（Apple Silicon M1/M2 或 Ryzen/Intel mobile）上 180–250 tokens/秒、消費級 GPU（RTX 3060 以上）上 800+ tokens/秒、資料中心 GPU 上 1500+ tokens/秒。因為工具呼叫很短（典型輸出少於 100 tokens）,從提示到完整函式呼叫的牆鐘延遲在多數消費級硬體上落於 50–200ms 範圍——對互動式使用而言夠快,沒有可察覺的暫停。

對於在 Ertas Studio 中微調,12GB 消費級 GPU（RTX 3060、RTX 4060）以 1024 token 序列長度處理全參數訓練。LoRA 與 QLoRA 將此降至 6–8GB 並產生小到可作為模型修補出貨的介面卡。在代表性工具呼叫資料集（300–800 個範例,3–5 個 epoch）上的訓練時間,在 Studio 的標準 GPU 階層上通常為 30–90 分鐘。