手機跑 Gemma 4 實測

先看重點

測試方式

• 兩台手機都用 Google 官方的 LiteRT-LM 0.17.1（iOS 用 Swift 版、Android 用 Kotlin 版），載入同一個 .litertlm 模型檔。
• 題目相同：一段約上千個 token 的中文說明（題目、選項與解析），請模型用一個生活比喻重新解釋，要求 120 字以內。
• 8 種組合：模型 E2B／E4B × 運算 CPU／GPU × MTP 開／關。每種組合各跑一次。
• 讀題＝從送出到第一個字出現的時間。打字速度＝打字階段每秒產生幾個中文字（已扣掉載入與讀題）。載入＝切換組合後第一次把模型準備好的時間。

每次回答長度不同（144～412 字），所以比較時看「每秒字數」，不要直接比總秒數。

圖表

完整數據

每秒效能（不含第一次載入）

黃底＝該手機「150 字估算」最短的組合。150 字估算＝讀題秒數＋150 ÷ 打字速度，是推算值。

實測總時間（含第一次載入）

單位：秒。讀題＋打字＝實測總計－載入。字數是該次回答實際產生的中文字數。

第一次載入會讓數字看起來很怪

手機上的架構

模型、引擎和運算全部在手機裡完成。下圖是一段問題從送出到出現回答所經過的路徑：

1. 組 prompt：把角色規則（system prompt）和這次的題目、參考資料放在一起。先把正確資料交給模型、要它只根據資料回答，叫做 grounding，可以降低幻覺。

2. 對話模板與斷詞：引擎自動套上 Gemma 4 規定的對話格式，再把文字切成 token。

3. Prefill（讀題）：整段 prompt 一次送進模型，每一層算出 Q、K、V，並把 K、V 存進 KV cache。能平行運算，所以 GPU 加速最明顯。

4. Decode（打字）：每次只產生 1 個 token。新 token 跟 KV cache 做注意力運算，再用取樣挑出下一個字。每產生一個字都要把整個模型權重從記憶體讀一遍，所以速度受記憶體頻寬限制。

5. 回傳：文字以串流方式一段段送回畫面。整個過程不需要網路，資料不會離開手機。

為什麼不在手機上跑 12B 以上

Gemma 4 共有 5 種尺寸，Google 只替 E2B、E4B 推出手機版。載入權重所需記憶體（Google 官方數字，已含約 20% 額外開銷、不含 KV cache）：

• 沒有手機版。12B、26B、31B 都沒有 LiteRT-LM 的手機版模型檔，要跑只能換其他引擎並自行轉檔。
• 記憶體不夠。12B 就算壓成 4-bit，光權重就要約 6.7GB，還得加上 KV cache。手機系統對單一 App 能用的記憶體有上限，大約是實體記憶體的一半多，12GB 等級的手機也很難穩定載入，8GB 的手機更不可能。
• 速度會很慢。打字速度受記憶體頻寬限制，模型越大，每個字要讀的資料越多。12B 的權重約是 E4B 手機版的 2.5～3 倍，推估打字速度只剩 E4B 的 1/2～1/3（推估值，未實測）。
• 檔案太大。12B 模型檔約 7GB。26B MoE 雖然每次只啟用約 40 億參數，但 260 億參數都要載入記憶體，同樣不可行。
• 發熱與耗電。大模型長時間高負載會讓手機發燙降頻，速度再往下掉。

結論：E2B、E4B 是 Google 專為手機設計的尺寸，E4B 大約就是現在手機上的實用上限；12B 以上適合電腦或伺服器。

名詞解釋