Google Gemma 官方 X 帳號近日分享一則令開發者社群興奮的消息：Reddit 用戶 Antikythera 在 r/LLMDevs 版塊展示了自行研發的「校準感知量化」（Calibration-Aware Quantization）技術，成功將 Gemma 4 壓縮到在 iPhone 上僅需約 516MB 活躍記憶體即可執行，且完全離線。
Gemma 4 running on an iPhone with just ~500 MB of RAM!
User Antikythera on r/LLMDevs shared their calibration-aware quantization approach to shrink Gemma 4 keeping speed and accuracy on an iPhone. They demoed it using an offline assistant that manages calendar actions with just… pic.twitter.com/ZVjXvmwB4W
— Google Gemma (@googlegemma) August 4, 2026
開發者成功在 iPhone 上以 516MB 記憶體離線執行 Gemma 4 大模型
要理解 Antikythera 的成果為何引人注目，得先回到 Google 在前不久 2026 年 6 月 5 日發布的 Gemma 4 QAT（Quantization-Aware Training，量化感知訓練）檢查點。傳統的訓練後量化（Post-Training Quantization，PTQ）是在模型訓練完成後才進行壓縮，就像把已經蓋好的房子硬擠進更小的空間，牆壁和結構難免受損。對小型模型而言，PTQ 造成的品質損失尤其嚴重，在 15B 參數以下的模型中，量化噪聲足以破壞語義連貫性，導致輸出品質大幅下滑。
QAT 的做法截然不同：它在訓練過程中就模擬低精度運算的效應，讓模型學會在 4-bit 甚至 2-bit 的限制下工作。技術上，前向傳播時會執行「偽量化」（Fake Quantization），將權重映射到整數值再反量化回浮點數進行計算；反向傳播時則透過直通估計器（Straight-Through Estimator）繞過取整函數的導數問題，讓梯度能直接傳遞到高精度的主權重上。訓練結束後，所有權重被永久轉換為低位元表示時，精度損失接近零。
Google 這次發布了兩類 QAT 檢查點：一是適用於全系列模型的 Q4_0 格式，二是專為行動裝置設計的 Mobile QAT 格式。後者針對 E2B 和 E4B 兩款邊緣模型進行了四項關鍵設計：通道級量化（對齊 NPU 記憶體佈局）、Token 生成層採用 2-bit 壓縮、預計算縮放常數、以及針對行動加速器的自訂排程。使用 Mobile QAT 格式後，E2B 純文字模型的記憶體佔用降至 1GB 以下。
從 1GB 到 516MB：Antikythera 的極限壓縮
Google 官方的 QAT 已經將 E2B 壓到 1GB 以下，但 Antikythera 的校準感知量化技術進一步將這個數字推到了約 516MB 活躍記憶體。這個數字代表什麼意義？大多數現代智慧型手機的記憶體在 6GB 到 12GB 之間，而一個完整的 AI 模型只佔用其中不到十分之一的空間，意味著使用者在跑模型的同時，手機的其他功能幾乎不受影響。
更關鍵的是，Antikythera 展示的不僅僅是「能跑」，而是「能用」。從他分享的截圖可以看到，一個名為 fraQtl 的應用程式在 iPhone 上以完全離線模式執行 Gemma 4，推理速度達到 13.7 tok/s。使用者在飛航模式下對它說「幫我找週四有空的時間開 VC meeting」，模型不僅找到了 11:30 AM 到 12:30 PM 的空檔，還直接在行事曆中建立了對應的事件。切換到行事曆應用確認，「VC meeting」確實出現在正確的時間段上。
這端側模型已從單純回答問題的聊天機器人，進化為能與手機系統深度整合、執行實際任務的智慧助理。完全離線意味著所有資料都在裝置上處理，不會傳送到任何伺服器，對隱私敏感的使用者來說是一大優勢。
Unsloth 的貢獻：讓量化不再是黑箱
在 Gemma 4 QAT 的生態系中，開源社群 Unsloth 扮演了關鍵角色。他們發現，直接將 Google 的 QAT BF16 檢查點轉換為 llama.cpp 相容的 Q4_0 格式時，精度損失相當明顯，以 26B-A4B 模型為例，直接轉換的 Top-1 準確率僅 70.2%。Unsloth 開發了一套動態量化方法（Unsloth Dynamic），將準確率提升到 85.6%，同時模型檔案還縮小了 200MB。
更具體地看，E2B 模型在 Unsloth 的處理下，平均 KLD（KL 散度，衡量量化後輸出與原始輸出差異的指標）僅 0.00173，相較於直接轉換的 0.05109，改善了 29 倍，且檔案體積還小了 22%。他們還推出了 UD-Q2_K_XL 量化版本，將 E2B 和 E4B 進一步壓縮到 2-bit 精度，為記憶體極度受限的裝置提供選擇。
端側 AI 的現實門檻
儘管成果令人振奮，端側部署仍有必須面對的現實限制。首先是硬體門檻：根據社群回報，E2B 模型至少需要 iPhone 13 Pro（6GB RAM）以上的裝置才能穩定執行，E4B 則需要 iPhone 15 Pro（8GB RAM）等級。記憶體低於 6GB 的裝置在扣除作業系統和背景應用後，可能沒有足夠空間載入模型。
其次是速度與品質的權衡。社群實測資料顯示，E2B 在 iPhone 16 Pro 上約可達到 12-20 tok/s，E4B 則在 8-15 tok/s 之間。相較於雲端 API 動輒數十甚至上百 tok/s 的速度，端側推理仍有明顯差距。不過對於行事曆管理、文字摘要、離線翻譯等日常任務而言，這個速度已經足夠實用。
電池與散熱也是不可忽視的因素。在裝置上執行 LLM 屬於持續高負載運算，性質接近玩遊戲或匯出影片。長時間對話會明顯消耗電力並導致裝置發熱，短暫使用則影響不大。部分社群開發者建議在應用設定中將 KV cache 切換為 q4_0 格式，能在犧牲少量品質的前提下顯著提升長對話的速度。
從實驗室到日常：端側 AI 的下一步
Gemma 4 QAT 與 Antikythera 這類社群開發者的貢獻，正在推動端側 AI 從技術展示走向實際應用。Google 的 AI Edge Gallery 已在 App Store 和 Google Play 上架，提供完整的 Gemma 4 模型執行環境；MediaPipe LLM Inference API 背後的 LiteRT-LM 執行時則是 Google 為行動裝置打造的推理框架，取代了舊版 MediaPipe 的維護模式。
對台灣的開發者與使用者而言，在不久的將來，手機上的 AI 助理可能不再需要網路連線就能完成日常任務，查行事曆、寫摘要、翻譯文件、甚至簡單的程式碼輔助。而 Apache 2.0 授權加上 Hugging Face 上的開源檢查點，也讓個人開發者有機會打造自己的離線 AI 應用。Google DeepMind 官方 QAT 發布後僅兩個月，Reddit 社群就將記憶體佔用壓到了 516MB。端側 AI 從技術展示到日常實用的進展速度，超出了多數人的預期。