Welcome Gemma 4: Frontier multimodal intelligence on device
一句話版本
Gemma 4 係一個可本地部署、支援文字加影像加音訊嘅開放多模態模型家族，重點唔只係能力強，而係佢刻意做成容易跨裝置、跨推論框架落地，對我哋評估本機代理同長上下文工作流特別有參考價值。
點解重要
- 開放授權唔係小事
- 佢用 Apache 2，代表如果我哋要做內部產品化、客製化整合、甚至後續再分發，法律同商業阻力會細好多，唔使一開始就被授權條款卡住。
- 「on-device」令部署選項實際可行
- 呢篇唔係單講 benchmark，而係強調可以喺本機設備跑得動，呢點直接關乎我哋可唔可以用單機、低依賴方式做穩定控制系統，減少雲端延遲、成本同資料外流面。
- 多模態唔再只係加張圖咁簡單
- Gemma 4 由設計上同時食文字、影像，細型號仲支援音訊，意味住如果我哋之後要處理 GUI 截圖、影片片段、語音輸入，唔需要為每種媒介各自砌一套模型鏈。
- 長 context 對代理型工作流有直接幫助
- 128k 到 256k context window，唔單止係「可以塞更多字」，而係可以令模型一次過帶住較完整嘅任務歷史、工具回傳、政策提示同證據內容去判斷，減少中途失憶同狀態切碎。
- 模型尺寸分層，代表選型空間大
- 由細到大有 E2B、E4B、31B 同 26B A4B，唔同成本同硬件條件都有位落腳，對我哋好重要，因為實際系統通常要按工作類型分配模型，而唔係所有任務都丟去最大模型。
- 26B A4B 個 MoE 方向值得留意
- 佢強調總參數 26B，但每次只啟動 4B，意思係有機會用較低運算成本換到接近大模型級別表現；如果我哋重視單機吞吐同功耗，呢類架構會比單純追求 dense 大模型更實際。
- 架構取向明顯偏向「易部署」而唔係炫技
- 文章特別提到避開複雜或未證明穩定嘅特性，改為選擇對函式庫、裝置相容性更高嘅組合，呢種工程取向比純研究新奇更啱實戰環境。
- 共享 KV Cache 係實用型優化
- 呢類設計直接打向推論記憶體同效率問題，對長上下文尤其重要；如果真係有效，代表本機跑大型任務時，瓶頸未必咁快落喺記憶體上。
- Per-Layer Embeddings 反映佢想改善細模型表達能力
- 呢個設計本質上係令每層可以攞到更貼近當下需要嘅 token 資訊，唔使全部訊息一開始就擠進同一個 embedding；對細模型嚟講，呢可能係提升穩定性同任務適應力嘅關鍵。
- 影像編碼器支援可變長寬比同可調 token 預算
- 呢點非常實務，因為真實世界嘅截圖、文件頁面、手機畫面唔會自動變成理想尺寸；可以按速度、記憶體、品質取捨，代表我哋可以依任務重要性做分級處理。
- 作者特別強調「開箱已經夠強」
- 呢句背後意思係初期 PoC 未必要先微調，可能先靠提示、工具調度同工作流設計就已經攞到可用結果，呢對縮短驗證週期有幫助。
- 跨生態支援降低整合成本
- 同時提到
transformers、llama.cpp、MLX、WebGPU、Rust 等，表示佢唔係綁死某一條工具鏈；我哋之後如果要喺 Python 控制面、Mac 本機推論、甚至前端 demo 之間切換，阻力會細好多。 - 多模態能力同 agentic use case 被放埋同一個脈絡
- 呢個訊號幾重要，因為佢唔係將多模態當做展示功能，而係當成代理工作流一部分，意味住模型被期待去理解畫面、聲音，再配合函式呼叫同長上下文做決策。
- benchmark 之外，文章用語透露作者對主觀體感有信心
- 佢哋唔只報分數，仲直接講預覽版本已經令佢哋難搵 fine-tuning 示範題材，反映基線能力可能真係高到足以影響我哋「先 tune 定先上流程」嘅優先次序。
我哋點睇
- 如果我哋要做單機、可控、可審核嘅代理系統，Gemma 4 值得列入候選，原因唔係單一分數高，而係佢喺本機部署、多模態輸入、長上下文同開放授權四方面同時對得上。
- 初步評估唔應該一開始就做 fine-tune，應該先驗證三樣嘢：長任務歷史下嘅穩定性、GUI/截圖理解質素、同埋喺 Mac 本機推論時嘅延遲與記憶體曲線。
- 如果我哋之後真係落手試，模型選型應該按任務分層：細模型做路由、分類、簡單回覆；較大模型先留畀高風險判斷、多步推理同複雜多模態任務。