Google把26B模型壓成4B算力，開發者實測賬單直接歸零

去年Gemma 3發布時，Google把作者 flown 到巴黎。現場演示很炫，但真正重要的發現發生在回酒店后——他跑了自己的測試，確認演示沒騙人。這是開源模型第一次逼近商業大模型的性能邊界。

然后他就栽了。周末把Gemma 3部署在Vertex AI Model Garden測試，忘關機，回來收到一張足以重塑云信仰賬單。他專門做了期YouTube視頻，防止后人重蹈覆轍。

這次Gemma 4發布，作者選了Cloud Run——不用時自動縮容到零。忘關機？隨便你，賬單為零。

四張牌，兩種打法

Gemma 4不是單一模型，是四個。E2B、E4B兩個小的，I9B、I27B兩個大的，各自對應不同取舍。

26B參數那個（I27B）用了混合專家架構（MoE，Mixture of Experts）。磁盤上存26B，推理時只激活4B。像大醫院里的會診制度——不是全院醫生圍著一張床轉，而是按癥狀叫對應科室。能力接近26B，算力成本按4B算。下文實測數據會展示這個差距有多夸張。

多模態是另一塊增量。圖像、音頻、視頻都能進，文本出。小模型（E2B、E4B）能處理帶音頻的視頻；大模型專攻圖像，支持更長上下文。

但對做Agent流水線的人來說，真正改規則的是推理能力和函數調用。

推理+工具調用：Agent的門檻被拆了

推理意味著模型先拆解問題、逐步推導，再輸出答案。以前這種活必須 frontier 模型才干得了，現在Gemma 4能以幾分之一成本接手。函數調用也大幅改進，結構化工具調用的可靠性提升，讓它能被編排進多步驟Agent里當組件用。

這兩個能力疊加，開源模型第一次具備了搭建復雜自動化流程的完整工具箱。

作者把Gemma 4四個尺寸全跑了一遍Cloud Run部署。核心發現：I27B在推理任務上的延遲表現，接近某些專有API的中小模型，成本卻是按秒計費的函數級開銷。

部署棧：從VPC到模型上傳的完整路徑

技術棧分三層。底層是Cloud Run的GPU實例，支持按需啟停；中間是vLLM推理引擎，負責把模型權重轉成可調用服務；頂層是Google Cloud Storage，存模型文件。

關鍵配置在VPC聯網。模型文件通常幾十GB，走公網下載既慢又貴。作者建議開VPC Connector，讓Cloud Run實例通過私有網絡直連云存儲，內網帶寬不計費。

四個尺寸的部署命令差異主要在資源配額。E2B/E4B用單張L4 GPU即可；I9B需要A100 40GB；I27B得A100 80GB或多卡L4。Cloud Run的并發設置建議調到1，避免多請求擠爆顯存。

縮容到零的冷卻時間默認5分鐘，可手動調短。作者測下來，冷啟動加載I27B大約需要90秒——對非實時場景可接受，實時場景建議保持最小實例數為1。

清理環節比部署更重要。Cloud Run服務刪除后，關聯的GPU配額和VPC Connector不會自動釋放，需要手動掃一遍。作者第一次測試時漏了VPC Connector，月底賬單多了17美元閑置費。

性能數據方面，I27B在GSM8K數學推理基準上得分72.4，接近Gemma 3的27B全量版本；但推理成本按激活參數4B算，實際GPU占用只有同規模密集模型的15%-20%。

函數調用的準確率，作者用ToolBench子集測了200輪，結構化輸出合規率91%，失敗案例主要集中在嵌套工具調用超過三層時。