代理專家：FunctionGemma + Gemma 4 E2B 與微調出貨論點

2026 年最有趣的開源權重趨勢不是下一個更大的專家混合模型。而是 Google 與少數其他實驗室現在所稱「代理專家」的興起——明確設計為針對狹窄代理任務進行微調而非作為通用助理對話的小模型。

270M 參數的 FunctionGemma 與新發布的、約 2B 等效參數的 Gemma 4 E2B 是標準範例。兩者皆出貨原生函式呼叫特殊 token。兩者皆裝在手機上——在 Q4_K_M 下分別少於 200MB 與約 1.5GB。兩者皆作為基底模型發布,其 model card 幾乎逐字寫著「打算為你特定的函式呼叫任務進行微調」。這個措辭不是樣板。它是產品定位。Google 明確告訴你,這些不是聊天模型、不是通用助理,也不是完成的產品。它們是專業化的起點。

這是一個與過去三年不同的心智模型。舊假設是,你採用一個通用模型——Llama 3、Mistral 7B、Qwen 2.5——並要嘛更努力地提示它、更努力地對它檢索,要嘛如果有預算,微調它並希望基底能力在與你領域接觸後存活。由 FunctionGemma 與 Gemma 4 E2B 體現的新假設,是基底模型本身就應該已經為任務最佳化。微調不是模型不太契合的權宜之計。它是預期的工作流程。

如果你正在建構住在行動 app、桌面工具,或任何其他每一 MB 與每一毫秒都重要的代理,代理專家是決定你產品經濟模型是否成立的趨勢前緣。

「專家」標籤實際意味著什麼

通用 7B Instruct 模型被訓練做許多事都還不錯：總結、聊天、推理、寫程式碼、遵循指令、偶爾呼叫工具。能力預算分散在數十項能力上。工具呼叫是該預算的一個切片——不是焦點。

代理專家反轉優先順序。它在狹窄的任務分布上訓練：輸入是使用者訊息加上工具 schema、輸出是結構化函式呼叫。其他能力以較低保真度存在或完全移除。架構、tokenizer 與預訓練混合都圍繞那單一輸出形狀調整。

那個取捨——以通才廣度換取專家密度——是讓參數計數乍看顯得難以置信的原因。一個 270M 模型在標準工具呼叫基準上達到 82-88%,並未違反任何物理定律。它只是把參數花在一件事上,而不是五十件。

一段話講完 FunctionGemma（因為它有自己的文章）

我們在年初詳細介紹過 FunctionGemma。短版：270M 參數、單一目的的意圖到調用映射、Q4 下 200MB、消費級 GPU 上 800+ tokens 每秒以及純 CPU 上 180-250 tokens 每秒。開箱即用,它以 82-88% 準確率處理標準工具 schema——天氣、搜尋、行事曆、CRUD。在你的特定 schema 上微調,它落在 90-94% 範圍。它無法多步驟推理、無法聊天、無法總結。它在很小的腳印中以非常快的速度做一件事。

新的——也是這篇文章的核心——是 Google 現在已釋出大一號的模型。

Gemma 4 E2B：專家獲得多模態手足

Gemma 4 E2B（2026 年 4 月）是 Google 對真實缺口的回應。如果你的代理只需要文字進、函式呼叫出,FunctionGemma 很棒。當代理需要在呼叫 create_expense_report 前看一張收據照片,或在呼叫 navigate_to_setting 前讀一張螢幕截圖時,它就不夠了。行動代理特別不斷遇到多模態輸入,而 270M 的純文字模型讓它們束手無策。

Gemma 4 E2B 是大約 2B 等效參數、原生多模態的模型,具備與 FunctionGemma 相同的函式呼叫特殊 token 詞彙表。架構是 Gemma 家族的下一個迭代——E2B 中的「E」代表「effective」（等效）參數,搭配 Per-Layer Embeddings（PLE）快取,讓 2B 級模型使用比原始參數計數所暗示的小得多的活躍記憶體佔用。在 Q4_K_M 量化下,它在磁碟上約 1.5GB、工作記憶體約 2GB,使其在任何現代手機的範圍內。

關於 Gemma 4 E2B 如何定位的三件事很重要：

1. 它是 Apache 2.0 授權。商業使用乾淨、可重新散布、可微調,且可在 app 內出貨而無需另行協商授權。這與 Gemma 家族其餘部分姿態相同,但值得重申,因為它是與不少出貨於使用受限授權的其他開源權重模型的差異化。

2. 它有原生函式呼叫 token。模型發出結構化工具呼叫,無需在輸出上事後解析或 regex。這聽起來小,但並不小——這是「在微調下可可靠呼叫工具的模型」與「產出大部分能解析、大部分能用的 JSON 的模型」之間的差別。

3. Model card 明確將其定位為代理應用的微調基底,而非通用助理。開箱即用,它在工具呼叫上稱職,但在聊天上平平。預期的工作流程,如同 FunctionGemma,是針對你的領域進行微調。

對於行動與邊緣代理建構者,Gemma 4 E2B 是第一個小到可在裝置上執行的開放授權、多模態、原生函式呼叫的模型。六個月前,那種組合並不存在。

微調出貨論點

這是驅動整個對話的計算。

通用 7B Instruct 模型,搭配良好的提示與對你工具 schema 的檢索,在中度自訂工具集上達到大約 60-70% 準確率。檢索失敗占部分失誤、提示範本變異占更多,而其餘是模型產生看似可信的參數值的一般傾向。在生產中,這看起來像一個大部分能用的系統,失敗到尷尬的程度足以讓你建立重試邏輯,並消耗 Q4 下 4.5GB 的記憶體加上你的檢索器使用的任何記憶體。

在同一工具集上微調的 FunctionGemma 270M 在訓練工具上達到超過 95% 準確率,無需檢索,因為 schema 已烤入權重。Q4 下腳印為 200MB。這在訓練工具上以更高準確率達到記憶體 22 倍縮減,且因為沒有檢索往返而大幅降低延遲。

陷阱是「在訓練工具上」這句話。微調的專家在其訓練分布外是脆弱的。新增工具到你的代理,你需要快速重新訓練執行才能讓該工具開始可靠運作。對多數代理產品這沒問題——你的工具表面變更很少,且你本來就有部署流程——但這就是擺在桌上的取捨。你以通用性換取準確率與腳印。

微調出貨論點是,對絕大多數代理產品,尤其是住在 app 內的代理,該取捨是正確的。原因：

• 你的工具集是有限且已知的。 真實產品有固定的動作目錄。能在執行期處理任意未知工具的通才之論據,主要是研究案例。
• 你的準確率標準很高。 工具呼叫驅動真實動作。70% 準確率不可接受。95% 是生產的下限。
• 你的單位經濟模型要求低邊際成本。 一旦你跨過幾千名執行多步驟代理流程的活躍使用者,前沿 API 成本吃掉你的利潤。裝置端專家使每次推論成本實質上為零。
• 你的 app 無法出貨 4.5GB 二進位檔。 200MB 到 1.5GB 模型是使用者會接受的下載與會放棄的下載之間的差別。

專家加上微調命中所有四個約束。通才加上提示一個都沒命中。

何時挑選哪個專家

FunctionGemma、Gemma 4 E2B 與較大微調模型之間的選擇,主要關於輸入模態與推理深度。

FunctionGemma 270M 在以下情境是正確答案：

• 輸入僅為文字。
• 代理的工作是純粹的意圖到調用映射,沒有中間推理。
• 腳印約束緊——模型總預算少於 500MB。
• 你的工具計數在個位數到低雙位數。

這是最輕量可能的部署。微調在單張 GPU 上花 5-10 分鐘、產出的模型從少於 300MB 的 RAM 提供服務,且推論在任何裝置上實質上是即時的。

Gemma 4 E2B 在以下情境是正確答案：

• 輸入包括圖像、螢幕截圖、照片或其他視覺內容。
• 代理在發出工具呼叫前受益於較長上下文的多輪對話。
• 腳印約束允許大約 2GB 工作記憶體。
• 工具計數適中——非簡單 schema 的工具最多到幾十個。

微調工作流程類似 FunctionGemma,但訓練執行較長（在單張 GPU 上通常 30-60 分鐘）且資料集較大（500-1500 範例為甜蜜點,如果使用視覺輸入則包括多模態範例）。

較大的微調模型——Qwen3-4B、Phi-4-Mini 或類似 在以下情境是正確答案：

• 代理需要在工具呼叫之間有推理步驟。Plan-and-execute 模式、多跳工具鏈、錯誤恢復、對先前工具輸出的條件邏輯。
• 輸出結構複雜——不只一個函式呼叫,而是結構化計畫或多步決策樹。
• 你能負擔 2.5-3.5GB 工作記憶體。

關於 Pydantic AI 裝置端的前一篇文章正是針對 Qwen3-4B 走過這個案例。當代理需要既可靠呼叫工具又能在它們之間做輕度推理時,它是正確大小。

任何這些的 Ertas 管線

無論你從哪個專家基底起步,工作流程都相同。

1. 在 Data Craft 整理資料集。 貼入你的工具 schema。使用批次產生提示範本透過 Claude 或 ChatGPT 種出數百個範例,然後讓 Studio 在加入訓練集前依 schema 驗證每個範例。針對 Gemma 4 E2B,混入多模態範例——影像加文字輸入配對預期的工具呼叫輸出。

2. 在 Studio 中微調。 挑選 FunctionGemma、Gemma 4 E2B 或你決定的較大模型。Studio 對工具呼叫微調的預設是 QLoRA 在 rank 16-32、3 個 epoch。驗證損失曲線通常在 epoch 2-2.5 附近平緩;auto-eval 標記出現的過擬合。

3. 對保留資料評估。 要看的三個指標是工具名稱準確率、參數名稱準確率與參數值準確率。生產就緒的專家微調在所有三項上都得分超過 95%。如果任何低於 95%,原因幾乎總是資料集缺口——找出失敗的範例、加入代表性訓練資料,並從既有 checkpoint 執行漸進式訓練。

4. 匯出為 GGUF。 Studio 的匯出流程在你選擇的量化等級下產出 GGUF 二進位檔。Q4_K_M 是行動的預設。

5. 以 Ertas Deployment CLI 出貨。 對你的 iOS、Android、Flutter 或 React Native 專案執行 CLI,模型在幾分鐘內就接到可運作的推論呼叫。CLI 安裝 llama.cpp 行動 FFI 綁定、放入 GGUF 模型,並在你的程式碼庫中暴露型別化推論函式。

從空專案到在手機上執行的微調專家的端到端時程：是小時,不是週。訓練 FunctionGemma 的同一資料集可訓練 Gemma 4 E2B、可訓練 Qwen3-4B——Studio 跨基底模型重複使用資料集,所以你唯一的選擇是哪個大小與模態契合你的產品。

更大的趨勢

2024 與 2025 年的開源權重模型故事是能力上限。每個新發布都推升給定參數量下的可能上限。Llama 3 讓 8B 具競爭力。Qwen 2.5 讓 7B 具競爭力。Mistral 讓小模型超越其重量。

2026 年的故事越來越是專業化下限。不是「最小具公信力模型可以多大?」而是「這個特定工作的最小具公信力模型可以多小?」270M 的 FunctionGemma 與 2B 的 Gemma 4 E2B 正在為工具呼叫推下那個下限。我們將在分類、擷取、路由、驗證中看到相同模式——明確設計為被微調並出貨、而非被聊天的領域特定基底。

對於行動 app 建構者,該趨勢是擺脫代理成本懸崖的方法。前沿 API 對每個多步驟代理流程花費數十美分。在一千名日活躍使用者下,那是每天數百美元。在一萬下,是數千。專家加上微調加上裝置端部署將每次推論成本移到實質上為零,而今年發布的代理專家——FunctionGemma、Gemma 4 E2B 以及將跟進的浪潮——使該移動在技術上變得直接,而非一個 MLE 季的工作。

微調並出貨。挑選契合工作的最小專家。在你的確切工具上訓練它。把它放在裝置上。架構現在已穩定到剩下的唯一問題是執行。

延伸閱讀

• FunctionGemma 與專屬工具呼叫模型的興起 — 對啟動這個類別的 270M 專家的更深入探討
• Pydantic AI 裝置端：為型別安全的行動代理微調 Qwen3-4B — 當代理需要在工具呼叫之間進行推理且 4B 基底是正確大小時
• 2026 年最佳開源微調模型 — FunctionGemma 與 Gemma 4 E2B 在 Qwen、Llama、Mistral 與 2026 年其餘基底模型景觀中的位置