Gemma 4 E2B：在瀏覽器裡跑的 AI Agent，完全不離開你的機器

「完全本地，不需要伺服器。」這句話聽起來像行銷口號，但當 Google Gemma 官方帳號發出這則推文的時候，背後有一整套可以驗證的技術棧。

這個 agent 做的事情很具體：搜尋瀏覽器歷史、讀取並摘要當前頁面、管理分頁——全部在瀏覽器內執行，模型推論不走網路，資料不上雲。要讓這件事成真，需要把幾個條件同時對齊：夠小的模型、夠快的量化、以及瀏覽器現在真的支援 GPU 運算。

這篇文章從技術棧拆開講，再談清楚限制在哪裡。

模型本身：5.1B 參數，有效只用 2.3B

Gemma 4 E2B 的「E2B」代表 Effective 2B——總參數量約 5.1B，但實際推論時激活的有效參數是 2.3B。這個設計讓它在保有足夠模型容量的同時，推論速度比前一代的 E4B 快 3 倍，Google 聲稱整體 Gemma 4 系列比前代快最多 4 倍，耗電降低最多 60%。

context window 是 128K token，支援文字、圖像、音訊多模態輸入，授權為 Apache-2.0，可商用。

在瀏覽器裡跑，使用的是 Hugging Face 上的 onnx-community/gemma-4-E2B-it-ONNX 這個版本，透過 @huggingface/transformers 套件載入，量化格式為 q4f16（4-bit 權重、16-bit 激活），VRAM 用量約 1.5GB。搭配 LiteRT 2-bit/4-bit 量化的更極端設定，某些裝置上可以壓到 1.5GB 以下。Google 官方數字是 LiteRT 可在 3 秒內完成 4,000 input token 跨兩個 skill 的推論。

WebGPU 是讓這件事成立的前提

瀏覽器本地 GPU 推論的關鍵是 WebGPU API——它讓 JavaScript 可以直接調用 GPU 的計算著色器（compute shader），不再被限在 WebGL 的圖形管線裡。

目前的支援狀況：

Chrome 113+：預設開啟，生產就緒
Edge（Chromium 核心）：同樣支援
Safari 26+：Apple Silicon 上表現良好
Firefox：仍需手動進入 about:config 開啟 WebGPU 旗標，不能視為普遍可用

換言之，如果你的目標是做一個給不特定用戶用的 Chrome extension，WebGPU 在桌面上已經夠穩定。但如果你要跨瀏覽器部署，Firefox 是個明確的例外——不是技術做不到，是預設沒開。

實作架構：offscreen document + service worker + content script

開源實作 kessler/gemma-gem（GitHub，Apache-2.0）的架構分三層，這個設計不是隨意的，是 Chrome extension 在 Manifest V3 限制下的必然選擇：

Offscreen Document（模型住在這裡）

offscreen document 是一個在背景不可見執行的 HTML 頁面，可以持有 WebGPU context。模型載入、tokenization、推論全部發生在這裡。把模型放在 offscreen document 的原因：service worker 的生命週期不穩定（Chrome 可能在閒置時終止它），而 offscreen document 只要 extension 活著就持續存在。

Service Worker（訊息路由）

service worker 是 background script，負責在三個元件之間轉發訊息——接收來自 content script 的使用者輸入，把 tool call 請求送到對應的執行層，再把結果回傳給 content script。它不持有模型，只做路由。

Content Script（DOM 工具 + 聊天覆蓋層）

content script 注入到目標頁面，提供兩件事：一是可以操作 DOM 的 tool 集合，包含 read_page_content、click_element、type_text、scroll_page、take_screenshot、run_javascript；二是用來跟 agent 對話的浮層 UI。

模型的 native tool calling 讓 agent 可以直接宣告要用哪個 tool、帶什麼參數，service worker 接收到之後轉發給 content script 執行，結果再回流給模型做下一步推論。整個迴圈不需要任何外部 API。

隱私角度：「不上雲」實際上代表什麼

對雲端 AI assistant 來說，每一次你輸入的 prompt、每一個被讀取的頁面內容，都會離開你的瀏覽器送到服務商的伺服器處理。即使有加密和隱私政策，資料的傳輸本身就是一個邊界。

這個架構把這個邊界消除了：推論在本地 GPU 上跑，content script 讀出來的頁面文字直接進 offscreen document 的模型，沒有 HTTP request 出去。這對幾類使用場景有實際意義：

需要讀取內部文件或企業內網頁面的工作流程
不想讓瀏覽歷史被任何服務看到的使用者
在有網路管制環境中工作的場景

但是，「資料不離開瀏覽器」不等於「完全安全」——extension 本身的程式碼邏輯是你需要自己審查的，content script 對頁面 DOM 有完整讀取權限，這個攻擊面仍然存在。

但是：限制在哪裡

這個方向在技術上成立，但有幾個現實限制需要正視。

首次載入延遲。 1.5GB 的模型檔案在第一次使用時必須下載到本地，載入時間取決於硬體和網路。extension 的圖示通常會顯示進度，但這段等待對不熟悉 ML 工具的用戶來說是個摩擦點。後續使用可以從快取載入，延遲問題只在第一次出現。

Firefox 不能假設可用。 如前述，Firefox 的 WebGPU 需要手動啟用。如果你要做一個給普通用戶用的 extension，Firefox 用戶目前基本上被排除在外。

行動裝置覆蓋率分散。 Android 的 WebGPU 支援程度取決於 GPU 驅動成熟度，各裝置差異大。iOS 上需要 WebKit 版本把關，不能假設通用可用。把行動裝置列為主力部署目標之前，需要做明確的裝置矩陣測試。

模型能力邊界。 E2B 的有效參數是 2.3B，對於瀏覽器內的輔助任務（摘要、導航、搜尋歷史查詢）夠用，但對需要複雜推論或長文脈絡追蹤的任務，能力會有明顯上限。這不是工程問題，是模型規模的現實。

跟雲端方案比：各有適用場景

OpenAI 的 ChatGPT 瀏覽器 extension、Anthropic 的 Claude.ai Web UI，以及各種雲端 AI assistant 提供的是另一個取捨：模型能力強很多，延遲主要來自網路而非本地計算，但資料必然離開瀏覽器，且需要持續的 API 費用或訂閱。

本地 WebGPU 方案換來的是隱私和離線能力，付出的代價是模型能力上限和首次載入成本。這兩個取捨不是誰優誰劣的問題，是不同使用場景的選擇。

對開發者來說，kessler/gemma-gem 這個開源實作的價值在於它示範了一個可以直接 fork 的架構模板——offscreen document 持模型、service worker 路由、content script 操作 DOM——這個三層分工在 Chrome Manifest V3 的約束下是目前最合理的設計。

Gemma 4 E2B 的出現讓「瀏覽器本地 AI agent」從概念驗證走到了有具體效能數字支撐的可用狀態。WebGPU 的桌面覆蓋率已經夠高，Apache-2.0 授權讓商業應用沒有障礙。剩下的問題是：你的使用場景是否真的需要「100% 本地」這個特性，以及你能否承受行動端和 Firefox 的覆蓋缺口。