Gemma 3 4B 端側延遲與部署

在手機、Raspberry Pi 或 IoT 閘道器上執行 AI——完全不依賴伺服器——徹底改變了什麼是可能的。沒有網路往返的延遲。沒有隨用戶數增長的 API 費用。不依賴網路連線。資料完全私密，因為什麼都不會離開裝置。

Gemma 3 是 Google 專為此目的打造的開放模型系列。Llama 和 Qwen 是為伺服器端推論設計、再壓縮至較小硬體的，而 Gemma 3 從一開始就是為資源受限環境所設計的。其結果是一個運行更快、記憶體占用更少、在同等參數量下比競爭對手更優雅地處理裝置端限制的模型。

4B 模型是大多數裝置端部署的目標。在 Q4_K_M 量化下，它可以運行在不到 3 GB 的 RAM 中——完全在現代智慧型手機、Raspberry Pi 5 或瀏覽器分頁的能力範圍內。當你針對特定任務進行微調後，它可以達到比它大 5 倍的模型的同等水準。

Gemma 3 模型規格

4B 模型是裝置端部署的最佳選擇。它夠大，足以處理有意義的任務（分類、擷取、簡單生成、意圖偵測），又夠小，能在人們已擁有的硬體上運行。

1B 模型適用於極端受限的場景——穿戴裝置、嵌入式系統，或需要絕對最小體積的情境。它能處理簡單的分類和短形式任務，但在需要超過基礎模式匹配的任何事情上都會遇到困難。

為何選擇 Gemma 用於裝置端

架構優化

Google 在設計 Gemma 3 時就考慮到裝置端推論：

• 交替層的滑動視窗注意力機制在同等上下文長度下，比完整注意力機制減少 30-40% 的記憶體使用。對於裝置端，這意味著你可以處理更長的輸入而不耗盡 RAM。
• 分組查詢注意力 (GQA) 採用 1:4 比例壓縮 KV 快取，減少推論期間的記憶體分配。在只有 6 GB RAM 的手機上，這是能否順利運行的關鍵差異。
• RMSNorm 搭配可學習縮放而非 LayerNorm——每層稍微更快，在 CPU/NPU 硬體上數十億次運算累積下來效果顯著。
• Logit 軟截止穩定輸出概率，降低量化模型產生退化輸出的機率。當你在手機 NPU 上以 Q4_0 運行時，這種穩定性至關重要。

推論速度比較

Gemma 3 4B 與同類模型在不同硬體上的比較，全部使用 Q4_K_M：

Gemma 3 在所有裝置端目標上比同等大小的模型快 15-30%。在 iPhone 的 Apple Neural Engine 上，優勢尤為明顯——Google 針對 Apple 的 ML 硬體優化了權重佈局。

記憶體占用

Gemma 3 4B 的基礎大小略高於 3B 模型（因為參數更多），但其 KV 快取效率意味著在較長上下文長度下差距縮小。在 4K 上下文時，Gemma 使用的 RAM 比 Phi-3.5 Mini 少，儘管其參數多了 2 億個。

微調 4B 模型

VRAM 需求

你可以在 RTX 3060 12GB、RTX 4060 8GB，或擁有 16 GB 統一記憶體的 M1 MacBook Pro 上以 QLoRA 微調 Gemma 3 4B。訓練速度很快——500 個範例在 rank 16 下通常在 12-18 分鐘內完成。

裝置端任務的資料集策略

裝置端任務有特定限制，應該塑造你的訓練資料：

簡短輸入，簡潔輸出。 在裝置端，每個 token 都有延遲和記憶體成本。訓練模型產生最小化的結構化輸出：

{"instruction": "Classify intent", "input": "Where's my order?", "output": "order_status"}
{"instruction": "Classify intent", "input": "I want to cancel", "output": "cancellation"}
{"instruction": "Classify intent", "input": "How do I change my payment method?", "output": "account_settings"}

而非：

{"instruction": "Classify the customer's intent from the following message", "input": "Where's my order?", "output": "The customer's intent is to check their order status. Category: order_status"}

冗長版本在輸入（較長的指令）和輸出（沒人要求的解釋）兩方面都浪費了 token。在以 28 t/s 生成的手機上，每個不必要的 token 都增加 36ms 的延遲。

針對延遲敏感模式進行優化。 如果模型需要在 200ms 內回應，你的訓練輸出應該少於 15 個 token。相應地設計你的任務格式。單標籤分類（1 個 token 輸出）是裝置端的理想選擇。簡短的 JSON 物件（5-10 個 token）是可接受的。段落長度的生成不適合延遲敏感的裝置端使用。

包含真實裝置使用中的邊緣案例。 行動用戶的輸入方式與桌面用戶不同——更多錯字、更多縮寫、更多非正式語言。在訓練資料中加入混亂的真實輸入：

{"instruction": "Classify intent", "input": "cant login pls help", "output": "authentication"}
{"instruction": "Classify intent", "input": "where tf is my package", "output": "order_status"}
{"instruction": "Classify intent", "input": "refudn pls", "output": "refund"}

訓練配置

Gemma 3 4B 裝置端微調的建議設定：

將最大序列長度設為 512 而非預設的 2048，可以顯著加快訓練速度，並產生針對裝置端使用典型的短輸入優化的模型。如果你的裝置端任務涉及較長的文件，可根據需要增加到 1024 或 2048。

GGUF 匯出與行動裝置量化

微調後，匯出為 GGUF 格式。你選擇的量化等級取決於你的部署目標：

對於近 2-3 年的手機（6 GB 以上 RAM）上的行動應用，Q4_K_M 是預設推薦。它夠小，足以與作業系統和其他應用程式共存，夠快以提供即時回應，且品質損失對分類和擷取任務來說微不足道。

對於 Raspberry Pi 或其他記憶體受限的邊緣裝置，Q4_0 節省 400 MB RAM，這可能是能否運行的關鍵差異。對簡單分類任務來說，品質下降是可以接受的。

對於透過 WebLLM 的瀏覽器部署，使用 Q4_0 或 Q4_K_M——模型需要下載到瀏覽器並放入 GPU 記憶體（與瀏覽器其他部分共享）。越小越好。

整合模式

React Native 搭配本地模型

使用 llama.rn 進行 React Native 整合。該函式庫封裝了 llama.cpp 並提供 JavaScript API：

1. 將 GGUF 檔案打包進你的應用程式（或在首次啟動時下載）
2. 在應用程式啟動時初始化模型（在 iPhone 15 上需要 2-4 秒）
3. 透過 JS bridge 執行推論
4. 模型在記憶體中保持載入，直到應用程式進入背景

典型分類延遲：包含 bridge 開銷在內 80-150ms。相比之下，API 呼叫最少需要 600-1,200ms。

原生 iOS 搭配 Core ML

使用 Google 的轉換工具將你的 GGUF 轉換為 Core ML 格式。Core ML 模型在 Apple Neural Engine 上執行，比 GPU 推論更快且更省電：

• iPhone 15 Pro：ANE 上 32-35 t/s，GPU 上 22-25 t/s
• 電池影響：ANE 在相同工作負載下比 GPU 少用約 40% 電力
• 記憶體：Core ML 比 llama.cpp 更有效率地管理模型記憶體

權衡之處：Core ML 轉換是額外步驟，且你失去一些彈性（無動態量化，固定批次大小）。對生產 iOS 應用值得；對原型開發則不值得。

原生 Android 搭配 NNAPI

在 Android 上，使用 llama.cpp 的 NNAPI 後端在 Qualcomm、MediaTek 和 Samsung NPU 上進行硬體加速推論：

• Pixel 8 Pro (Tensor G3)：NPU 上 22-25 t/s
• Samsung S24 (Snapdragon 8 Gen 3)：NPU 上 26-30 t/s
• 電池：NPU 推論比 CPU 少用 50-60% 電力

NNAPI 支援因裝置而異。務必包含 CPU 備用路徑。

透過 WebLLM 的瀏覽器端

WebLLM 使用 WebGPU 在瀏覽器中執行 GGUF 模型：

• M2 MacBook 上的 Chrome：15-18 t/s
• 遊戲筆記型電腦 (RTX 4060) 上的 Chrome：20-25 t/s
• iPhone 15 Pro 上的 Chrome：8-10 t/s

模型下載一次後快取在瀏覽器儲存空間中（IndexedDB）。後續載入幾乎即時。適合需要離線功能或資料隱私的網頁應用程式。

透過 llama.cpp 的 Raspberry Pi

對於 IoT 和邊緣部署，在 Pi 上直接執行 llama.cpp：

• Raspberry Pi 5 (8 GB)：Gemma 3 4B 在 Q4_K_M 下，6-7 t/s
• Raspberry Pi 5 (4 GB)：Gemma 3 4B 在 Q4_0 下，5-6 t/s（很緊但可用）
• Raspberry Pi 4 (8 GB)：Gemma 3 4B 在 Q4_0 下，2-3 t/s（可用於批次處理）

對於 Pi 4，考慮使用 Gemma 3 1B 模型——它在 Q4_K_M 下以 8-10 t/s 運行，並能可靠地處理簡單分類。

真實裝置效能基準測試

微調過的 Gemma 3 4B (Q4_K_M) 在 12 類意圖分類任務上的表現（500 個訓練範例）：

請注意，所有裝置的準確率相同——量化對所有平台的影響是相同的。差異純粹在於延遲/速度。每台裝置對分類任務都能提供低於一秒的回應，對即時面向用戶的功能來說已足夠快。

作為參考，GPT-4o API 呼叫進行同樣的分類任務平均需要 850ms，P99 為 3,200ms。裝置端模型在一台 200 美元的手機上，延遲上比世界最佳 API 快 10 倍。

真實使用案例

離線表單驗證

一家現場服務應用使用 Gemma 3 4B 驗證和修正技術人員在無訊號地區的平板上輸入的備忘錄。模型檢查拼字、標記缺失的必填欄位，並對工作類型進行分類——全部離線完成。在 300 個技術人員備忘錄範例上進行微調，部署在 Android 平板上使用 Q4_K_M。準確率：92%。延遲：120ms。

裝置端意圖分類

一家銀行應用使用 Gemma 3 4B 在路由到相應服務之前對客戶訊息進行意圖分類。在裝置端運行意味著訊息文字永遠不會離開手機——這是多個司法管轄區的合規要求。在 400 個範例上進行微調，透過 Core ML 部署在 iOS 上。準確率：95%。延遲：55ms。

IoT 感測器分析

一家工業監控系統在 Raspberry Pi 5 閘道器上執行 Gemma 3 4B，將感測器讀數分類為正常、警告或危急。每個閘道器處理來自 12 個感測器的資料。在 500 個感測器資料模式範例上進行微調，以 Q4_0 部署。準確率：97%（三類分類）。處理速度：每個閘道器每秒 4 次讀數。

注重隱私的文字處理

一家醫療記錄應用使用 Gemma 3 4B 在醫療提供者的 iPad 上結構化和分類臨床備忘錄。沒有患者資料離開裝置。在 350 個去識別化範例上進行微調。HIPAA 合規變得更簡單，因為 AI 處理完全在裝置端進行——無需雲端、無 API、推論步驟無需 BAA。

延伸閱讀

• Edge AI and Local Inference in 2026 — 裝置端 AI 部署的全貌，包括硬體、框架和真實效能資料。
• AI Agents Offline: Edge Fine-Tuned — 如何使用微調的邊緣模型構建無需網路連線即可工作的 AI 代理。
• LoRA Adapter Edge Deployment Optimization — 針對邊緣裝置最小化體積優化 LoRA 適配器。