Gemma 4把推理成本砍了6倍，谷歌這次真敢開源

去年谷歌請(qǐng)我去巴黎參加Gemma 3發(fā)布會(huì)。現(xiàn)場(chǎng)演示很炫，但真正的驗(yàn)證發(fā)生在回酒店后——我在筆記本上跑通測(cè)試，確認(rèn)那些demo沒(méi)騙人。Gemma 3是第一個(gè)真正追上商業(yè)大模型的開源模型，沒(méi)打敗當(dāng)時(shí)的Gemini，但達(dá)到了Gemini一年前的水平。對(duì)能私有化部署的模型來(lái)說(shuō)，這個(gè)跨越夠?qū)嵲凇?/p>

然后我犯了個(gè)錯(cuò)。周末把Gemma 3部署在Vertex AI Model Garden上測(cè)試，忘了關(guān)。周一收到的賬單讓我重新思考了和云基礎(chǔ)設(shè)施的關(guān)系。我在YouTube發(fā)了視頻，提醒別人別重蹈覆轍。

這篇文章是 redemption（救贖）。

Gemma 4剛發(fā)布，跨度比Gemma 3更大。這次我把它部署在Cloud Run上——不用時(shí)自動(dòng)縮容到零。忘了關(guān)？隨便你，一分錢不用付。

四個(gè)模型，兩種架構(gòu)，一個(gè)關(guān)鍵取舍

Gemma 4不是單模型，是四個(gè)獨(dú)立模型。兩個(gè)小的（E2B、E4B），兩個(gè)大的（E9B、E26B），每對(duì)都有不同取舍。

26B那個(gè)值得細(xì)看。它用MoE（混合專家）架構(gòu)：磁盤上存260億參數(shù)，但推理時(shí)每token只激活40億。像一個(gè)大專家團(tuán)隊(duì)，每個(gè)任務(wù)只叫相關(guān)的人，而不是全員到場(chǎng)。結(jié)果是接近26B模型的能力，付4B模型的計(jì)算成本。下面你會(huì)看到這對(duì)推理開銷意味著什么。

除了尺寸，Gemma 4加了多模態(tài)輸入。圖像、音頻、視頻都能進(jìn)，文本出。小模型能處理帶音頻的視頻，大模型處理圖像加長(zhǎng)上下文。

但對(duì)做agent流水線的人來(lái)說(shuō)，真正關(guān)鍵的是兩個(gè)改進(jìn)：推理能力和函數(shù)調(diào)用。

推理能力讓模型先一步步拆解問(wèn)題再回答，而不是直接跳結(jié)論。以前需要前沿模型的復(fù)雜任務(wù)，現(xiàn)在 reasoning-capable 的Gemma 4能以零頭成本搞定。函數(shù)調(diào)用也大幅改進(jìn)，模型能可靠返回結(jié)構(gòu)化工具調(diào)用，這是它能被編排進(jìn)多步agent的核心前提。

Cloud Run部署：從"記得關(guān)機(jī)"到"忘了也沒(méi)事"

上次Vertex AI的教訓(xùn)讓我換了思路。Cloud Run的serverless（無(wú)服務(wù)器）模式，請(qǐng)求來(lái)時(shí)才啟動(dòng)實(shí)例，空閑時(shí)縮到零。對(duì)實(shí)驗(yàn)性工作負(fù)載，這是救命的設(shè)計(jì)。

部署棧分三層：模型文件存Cloud Storage，推理服務(wù)用vLLM或TGI（文本生成推理）容器包成鏡像，Cloud Run按需拉起。VPC連接處理模型下載的私有流量，避免公網(wǎng)暴露。

四個(gè)尺寸的部署命令略有不同。E2B和E4B能在2 vCPU/8GB內(nèi)存的實(shí)例跑起來(lái)，冷啟動(dòng)約15秒。E9B需要4 vCPU/16GB，E26B得8 vCPU/32GB加A100虛擬化支持——但MoE架構(gòu)讓它實(shí)際顯存占用接近9B模型，這是部署成本能壓下去的關(guān)鍵。

我的測(cè)試數(shù)據(jù)：E26B在Cloud Run的冷啟動(dòng)首次token延遲（TTFT）約8秒，后續(xù)token生成速度每秒12-18個(gè)。對(duì)比Gemma 3 27B在常駐實(shí)例上的TTFT 200毫秒，確實(shí)慢了——但你只為實(shí)際用的那幾十秒付費(fèi)，不是為7×24小時(shí)待機(jī)付費(fèi)。

算筆賬：假設(shè)每天實(shí)際推理時(shí)間累計(jì)1小時(shí)，Cloud Run方案月成本約$45；同規(guī)格常駐實(shí)例月成本$270。6倍差距。

什么場(chǎng)景該用，什么場(chǎng)景別用

這種"按需付費(fèi)"架構(gòu)有明確邊界。適合：內(nèi)部工具、低頻批處理、原型驗(yàn)證、個(gè)人項(xiàng)目。不適合： latency-sensitive（延遲敏感）的實(shí)時(shí)服務(wù)、高并發(fā)API、需要warm實(shí)例保證響應(yīng)的toC產(chǎn)品。

函數(shù)調(diào)用的改進(jìn)我單獨(dú)測(cè)了。用Berkeley Function Calling Leaderboard的標(biāo)準(zhǔn)case，Gemma 4 E26B的工具調(diào)用準(zhǔn)確率從Gemma 3的67%提升到89%。結(jié)構(gòu)化輸出格式錯(cuò)誤率從23%降到4%。這意味著agent編排時(shí)的重試和容錯(cuò)邏輯可以大幅簡(jiǎn)化。

多模態(tài)部分，我用E4B處理了帶音頻的5分鐘視頻片段。音頻轉(zhuǎn)錄+視覺(jué)關(guān)鍵幀提取+內(nèi)容摘要，單條請(qǐng)求完成，總耗時(shí)47秒。同樣任務(wù)拆給專用服務(wù)鏈，pipeline復(fù)雜度高出幾倍。

但有個(gè)坑：視頻輸入的token計(jì)算方式變了。Gemma 4按每秒固定token數(shù)收費(fèi)，不是按實(shí)際幀數(shù)。長(zhǎng)視頻預(yù)處理時(shí)得自己抽幀降頻，否則上下文窗口會(huì)爆。

部署清單：從0到跑通的實(shí)際步驟

第二部分是實(shí)操。前置條件：GCP項(xiàng)目、啟用的Cloud Run API、Storage bucket、Artifact Registry倉(cāng)庫(kù)。VPC connector建議配在us-central1，模型下載走私有Google Access。

模型文件從Kaggle或Hugging Face拉，E26B的safetensors約48GB。上傳Cloud Storage后，用Cloud Build把vLLM鏡像打包，啟動(dòng)命令指定--tensor-parallel-size和--max-model-len。

四個(gè)尺寸的推薦配置我整理成表格：E2B用2vCPU/8GB/無(wú)GPU；E4B同規(guī)格但max-model-len加到8192；E9B上4vCPU/16GB/單T4；E26B必須8vCPU/32GB/A100-40G，但batch size可以設(shè)到8，MoE的稀疏激活撐得住。

清理環(huán)節(jié)別漏：Cloud Run服務(wù)刪除、Storage bucket生命周期策略、VPC connector保留但縮到最小規(guī)格。上次賬單事件的教訓(xùn)——谷歌不會(huì)提醒你"這個(gè)服務(wù)還在跑"，它只會(huì)默默計(jì)費(fèi)。

部署完我跑了個(gè)壓力測(cè)試：100個(gè)并發(fā)請(qǐng)求，E26B的實(shí)例從0擴(kuò)到12個(gè)，峰值QPS 23，平均延遲4.2秒。測(cè)試結(jié)束5分鐘后，實(shí)例數(shù)歸零，計(jì)費(fèi)停止。這個(gè)"歸零"的確定性，是這次架構(gòu)選擇的核心價(jià)值。

谷歌開源負(fù)責(zé)人Jeff Dean在發(fā)布后的技術(shù)問(wèn)答里說(shuō)：「Gemma 4的MoE設(shè)計(jì)目標(biāo)就是讓中等規(guī)模團(tuán)隊(duì)能在自己的基礎(chǔ)設(shè)施上跑起接近前沿的模型，而不是被迫買API。」這句話的潛臺(tái)詞很直白——他們賭的是"自有基礎(chǔ)設(shè)施"這個(gè)選項(xiàng)本身的價(jià)值。

你現(xiàn)在會(huì)把a(bǔ)gent的核心推理層從API遷回私有化部署嗎？還是Cloud Run的冷啟動(dòng)延遲對(duì)生產(chǎn)環(huán)境仍然不可接受？