Google Cloud 5 月更新整理

Google Cloud 這次 5 月更新，重點是把 AI、儲存和 GKE 的日常維運做得更省事。

Google Cloud 在 2026 年 5 月 23 日丟出一包更新。說真的，這包不算花俏，但很實用。主角包含 Google Kubernetes Engine、Cloud Run、Apigee，還有 Google AI Edge。

這次更新有幾個數字很直白。AI Edge Portal 支援 120+ Android 裝置。Fractional G4 VMs 提供 1/2、1/4、1/8 三種 GPU slice。整包更新也在 5 月 23 日公開。這些數字看起來不炫，但很像雲端團隊真正會在意的東西。

GKE 的儲存，開始少一點手動踩雷

GKE 這次最實際的更新，是 Dynamic Default Storage Classes。Google 的說法很簡單。當叢集混用不同世代的 VM 時，系統會自動挑比較合適的 storage class。

講白了，Kubernetes 的儲存一直很麻煩。新節點和舊節點常常不是同一套特性。你如果手動指定錯 storage class，效能可能卡住，容量也可能浪費。這種問題很少在 demo 裡出現，卻很常在上線後冒出來。

這種自動化不是要取代規劃，而是減少人為失誤。對平台團隊來說，少改一次 YAML，就少一次半夜查問題的機會。對開發者來說，至少不用每次擴容都重新猜一次預設值。

• 適合混合世代 VM 的 GKE 叢集
• 會自動挑選 storage class
• 減少儲存維運的手動調整
• 降低混叢集時的設定失誤

我覺得這類功能很無聊，但很值錢。因為真正吃掉人力的，從來不是模型跑不跑得動，而是基礎設施一直出小毛病。

Cloud Run worker pools，補上背景工作缺口

Cloud Run 的 worker pools 現在已經 GA。這代表它不只適合 HTTP request，也能更自然地處理 pull-based jobs、背景任務，還有大規模 AI inference。

這點很重要。很多團隊一開始都拿 serverless 跑 API。結果一碰到 queue、Kafka lag、批次處理，就開始東拼西湊。你會看到腳本、cron、autoscaler、告警規則一起上場，然後維運地獄就來了。

worker pools 的定位，就是把這種非 HTTP 工作拉回雲端平台本身。你不用硬把背景任務塞進 request/response 模型。這樣設計比較合理，也比較少出現奇怪的延遲抖動。

“Cloud Run worker pools provide a new resource type designed specifically for pull-based, non-HTTP workloads.”

Google 也把 CREMA 開源了。它是 Cloud Run External Metrics Autoscaler，底層建在 KEDA 上。它可以用 Pub/Sub backlog 或 Kafka lag 來做擴縮。

• Cloud Run worker pools 已經 GA
• CREMA 已開源
• 底層採用 KEDA
• 可依 Pub/Sub backlog 與 Kafka lag 擴縮

這對 AI 團隊很實用。因為 inference pipeline 很常不是單純的 API。它更像一串背景任務。對平台團隊來說，這也少掉很多自己造輪子的機會。

Apigee MCP，讓企業 API 變成 agent 工具

這次另一個重點，是 Apigee 搭上 MCP。Google Cloud 的做法，是把企業 API 直接包成 MCP tools。開發者就能把既有服務變成 agent 可用的端點，不必另外架一套 local MCP server。

這件事很像企業 AI 的真實樣貌。大家嘴上都在講 agent，但真正上線時，卡住的通常不是模型。卡住的是權限、稽核、資料存取，以及你到底能不能知道 agent 做了什麼。

Google 的方向很清楚。它不是把 agent 當聊天玩具。它是把 agent 當軟體系統的一部分。這表示你要有政策控管，也要有 audit logs。沒有這些，agent 進企業環境只會變成新的風險來源。

“The goal is to manage governed MCP endpoints, tool access to enterprise data, and audit logs on Google Cloud.”

這句話很直白，也很現實。很多公司現在最缺的，不是更多 LLM，而是能讓 LLM 安全碰到內部系統的方法。Apigee MCP 就是在補這個洞。

• Apigee MCP 已進入一般可用
• 可把企業 API 直接變成 MCP tools
• 不必額外維護 local MCP server
• 適合內部 copilot 與交易型 agent

如果你在做內部助理、客服代理，或流程自動化，這類能力很值得看。因為真正能上線的 agent，不是會聊天就好，而是能在規則內做事。

AI Edge 與開發工具，繼續往實作靠攏

AI Edge Portal 這次加了新的 benchmark 和 debug 功能。重點是它能在 120+ Android 裝置上測 LLM。這不是玩具功能。這是很務實的工程需求。

你如果做過 on-device AI，就知道不同手機差很多。旗艦機跑得順，不代表中階機也行。記憶體、散熱、晶片版本、Android 版本，都可能讓結果差一截。Google 這次的方向，就是把這些差異提早攤開。

另外還有 Google Cloud Workbench Notebooks 的 Visual Studio Code extension。它能讓你在編輯器裡連到 managed cloud 環境。Google 也把它放到 GitHub。

• AI Edge Portal 支援 120+ Android 裝置
• 新增 LLM benchmark 與 debug 工具
• Workbench Notebooks 可接 VS Code
• extension 已開源

這種工具鏈很對味。算力放雲端，開發體驗盡量留在本機。對台灣很多小團隊來說，這比華麗簡報有用多了。因為你要的是快一點試、少一點切換、少一點環境問題。

這包更新在跟誰比

如果拿這次更新去看其他雲平台，Google Cloud 的重心很明顯。它不是只拼模型，也不是只拼 GPU。它在補基礎設施的縫。這些縫包括 storage、autoscaling、API governance、edge testing，還有 notebook workflow。

這跟 AWS、Microsoft Azure 的打法有點像，但切法不同。AWS 很強在服務廣度。Azure 很強在企業整合。Google Cloud 這波比較像在往 AI 工作流的操作細節鑽。

你可以把它理解成三層比較。第一層是模型能力，大家都在追。第二層是工具鏈，很多人開始補。第三層是維運細節，這才是上線後最痛的地方。Google 這次明顯在第三層下功夫。

• AWS 強在服務廣度
• Azure 強在企業整合
• Google Cloud 這次更偏向 AI 維運細節
• 重點放在降低日常操作成本

再看數字也很有意思。120+ 裝置測試，代表它在碰碎片化硬體。1/8 GPU slice，代表它在壓低進場成本。GA 的 worker pools，代表它想把背景工作正式納入平台能力。這些都不是口號，都是工程選擇。

雲端 AI 會越來越像營運問題

這次更新給我的感覺很直接。AI 已經不是單純模型競賽。它更像一門營運學。你要管成本、管權限、管儲存、管背景工作，還要管裝置碎片化。

Google Cloud 這包更新，剛好把這些痛點一個個補上。它不一定每項都很亮眼，但合起來很像一套可上線的工程答案。這對開發者來說，比喊口號有用多了。

我自己的判斷是，接下來大家會更常問：這個 AI 系統能不能被管住？能不能被稽核？能不能在不同硬體上穩定跑？如果答案都能說清楚，才算真的能進 production。

如果你現在正在評估 Google Cloud，這篇更新最值得先看的是 GKE storage、Cloud Run worker pools，還有 Apigee MCP。這三個東西，最接近實際上線時會碰到的問題。