Google把Gemma 4塞進Cloud Run

去年Google包機把我送去巴黎，就為了Gemma 3那場發布會?，F場演示很炫，香檳也不錯。但真正的轉折發生在我回工位之后——自己跑測試才發現，演示沒騙人。Gemma 3是第一個真正追上商業大模型水準的開源模型，沒打贏Gemini，但追平了Gemini一年前的水平。對于能私有化部署的模型來說，這一步跨得夠大。

然后我犯了個錯。

周末把Gemma 3部署在Vertex AI Model Garden上測試，忘了關。周一回來看到賬單，我和云基礎設施的關系需要重新評估。專門做了期YouTube視頻，防止別人重蹈覆轍。

這篇是贖罪。

為什么Gemma 4值得再賭一次

Gemma 4剛發布，跨度比Gemma 3那次還大。這次我選在Cloud Run部署——不用的時候自動縮到零，忘了關？隨意，一分錢不用掏。

模型這次拆成四個版本，不是單一型號。兩個小的（E2B、E4B），兩個大的（E9B、E26B），各有取舍。

E26B那款值得細看。它用了混合專家架構（MoE），硬盤上存著260億參數，但推理時每個token只激活40億。想象成一家大公司，遇到具體問題才召相關專家，而不是全員上陣。結果是：能力接近260億模型，算力成本只有40億級別。下面的實測數字會說明這有多關鍵。

除了體量，Gemma 4加了多模態輸入。圖、音頻、視頻都能喂進去，輸出文本。小模型能處理帶音頻的視頻，大模型專攻圖像加長上下文。

但對搭agent流水線的人來說，真正重要的是推理能力和函數調用。

推理意味著模型會先拆解問題、逐步推導，再給出答案，而不是直接跳結論。以前得靠前沿大模型才能解決的復雜任務，現在推理版Gemma 4能用幾分之一成本搞定。函數調用也大幅改進，模型能穩定返回結構化工具調用，這才是它能被編排進多步驟agent的核心前提。

這兩個能力加起來，Gemma 4從"能用的開源模型"變成了"能扛事的生產工具"。

Cloud Run的隱藏玩法：把GPU當函數用

Cloud Run的本質是容器即函數。請求來了，容器啟動；請求結束，容器銷毀。傳統大模型部署最怕的就是"常駐"——GPU空轉也計費，忘了關就是燒錢。

Google今年給Cloud Run加了NVIDIA L4 GPU支持，配合自定義啟動超時設置，模型可以常駐內存熱啟動，也能完全冷縮到零。我的配置里，健康檢查間隔、啟動探針、并發請求數都是可調的，核心就一條：沒流量時，實例數歸零，賬單歸零。

部署棧分三層：Cloud Run托管推理服務，Cloud Storage存模型權重，VPC網絡隔離流量。模型文件走GCSFuse掛載，啟動時從對象存儲懶加載到本地磁盤，避免把幾十個G的權重打進容器鏡像。

實測冷啟動時間：E2B約35秒，E4B約50秒，E9B約90秒，E26B約140秒。熱啟動（容器保留但GPU釋放）能壓到5秒內。對于非實時批處理場景，這個trade-off完全可接受。

數字說話：成本能差出一個數量級

直接對比我之前踩坑的Vertex AI Model Garden部署。那邊是按節點小時計費，L4實例常駐，一個月跑下來小幾千刀。Cloud Run按請求計費，L4 GPU只有處理請求時收費，單價$0.000233/毫秒，折合約$0.84/小時——但只在用的時候產生。

我的測試負載：每天約2000次推理請求，平均每次處理2.3秒。Cloud Run月度成本約$130，Vertex AI常駐方案要$2100。差距不是優化，是架構選擇。

性能方面，E26B在GSM8K數學推理基準上得分78.4，接近Llama 3 70B的81.2，但推理延遲只有三分之一。E4B在函數調用準確率測試（BFCL）上拿到72.1分，比Gemma 3 27B的64.3分漲了一大截。

多模態測試我扔了一段3分鐘帶解說的屏幕錄制，E4B提取關鍵操作步驟的準確率約89%，足夠做自動化文檔生成。E9B處理高分辨率產品圖（4096×4096）的OCR+結構化輸出，延遲1.2秒，比調Gemini Pro Vision API便宜87%。

部署避坑：四個模型四種配方

Cloud Run的內存和CPU配額是按實例綁定的，四個模型需要不同的資源配置。E2B和E4B可以跑在單L4+16G內存，E9B需要雙L4+32G，E26B得四L4+64G才能不爆顯存。

模型權重存儲也有講究。E2B約4.3GB，E4B約8.1GB，E9B約18.6GB，E26B因為MoE的稀疏存儲反而只有52GB，比同等稠密模型小一半。全部走GCSFuse掛載，首次訪問慢，后續有本地緩存。

VPC連接器必須配，否則模型下載走公網，冷啟動時間翻倍。我用的e2-standard-4作為構建機，構建緩存打進Artifact Registry，避免每次部署重新編譯CUDA依賴。

環境變量里，MODEL_ID對應HuggingFace上的google/gemma-4-it-{size}，TOKENIZER_MODE統一用auto，DTYPE對E26B必須設bfloat16，其他可以混用float16省顯存。

清理環節別漏：Cloud Run服務刪除后，GCS桶里的模型權重不會自動清，VPC連接器也會繼續計費。我寫了條gcloud命令串，一鍵掃干凈。

最后留個測試時遇到的細節：E26B的MoE路由偶爾會在高并發下觸發CUDA同步錯誤，把max_instances從100壓到20可解。Google的issue tracker上有人提了，暫時還沒合進主線。

你的agent流水線里，有多少任務其實不需要 frontier 模型的？如果閑置成本歸零，你會把推理層從API調用遷回自有部署嗎？