Google Cloud 官方於二零二六年十一月七日宣佈，新一代儲存優化 Z4M 機型系列在 Google Compute Engine 正式全面可用，可選虛擬機器與裸機實例；官方標示最高約十六萬八千 GiB Local SSD，並搭配最高四百 Gbps Cloud RDMA 網絡，面向 AI／機器學習檢查點、分散式鍵值快取與平行檔案系統等吞吐與低延遲並重的工作負載。本文已核對 Google Cloud 官方博文，來源真實性已驗證。

Google Cloud／官方：儲存優化 Z4M 正式可用——本地 SSD 最高十六萬八千 GiB、四百 Gbps RDMA；隨機讀 IOPS 最高約一千五百六十萬

Google Cloud 於二零二六年十一月七日在雲端博客刊登《Introducing Z4M: storage-optimized compute for AI/ML and parallel file systems》，由產品管理署名 bob Napaa，宣佈下一代儲存優化 Z4M 機型系列在 Google Compute Engine 正式全面可用（GA），並同時提供虛擬機器（VM）與裸機實例。官方將 Z4M 定位為服務 AI／機器學習訓練與推論中的檢查點、分散式鍵值（KV）快取與平行檔案系統等「資料量極大、需大量平行處理，且同時要求高儲存與網絡吞吐」的場景；低延遲存取則被寫成維持 GPU／TPU 滿載的關鍵。以下只整理官方博文已公開的規格、架構主張與合作夥伴測試聲明，來源真實性已驗證。

一、核心事件：儲存優化 Z4M 在 GCE 全面可用

技術細節

官方指出，Z4M 採用第五代 Intel Xeon Scalable 處理器，並搭配 Titanium 最新強化；Local SSD（LSSD）容量最高可達約十六萬八千 GiB，Cloud RDMA 網絡最高約四百 Gbps。官方稱 RDMA 相對 TCP 可把資料存取延遲最多降低約六成，以便在正確調整雲端投資規模的同時提高應用吞吐。VM 組合除了總容量外，亦強調每個 vCPU 對應約八百七十五 GiB LSSD，亦即 vCPU：LSSD 比例為一比八百七十五。裸機實例則提供沒有虛擬化層的實體硬體直達，官方寫明適合自訂虛擬機監控程式、有特定授權需求的工作負載，以及需要大規模隔離沙箱的代理式 AI 場景（包括與 Agent Substrate 併用）——後者僅屬官方列舉的一項用途，本文焦點仍是 Z4M 儲存優化運算本身。

除十六萬八千 GiB LSSD 外，Z4M VM 與裸機實例最高可配約一百九十二個 vCPU、約一千五百三十六 GiB 記憶體。實例以 Titanium SSD 為基礎，官方稱可把本地儲存處理自 CPU 卸載，以換取即時資料處理、低延遲、高吞吐與強化的儲存安全。效能方面，官方標示隨機讀 IOPS 最高約一千五百六十萬、循序讀吞吐最高約七萬五千六百 MiB／秒；相對上一代 Z3，LSSD 效能與吞吐最多分別提升約七成與約百分之一百一十。

網絡與直連儲存方面，Z4M 以四百 Gbps 的 RDMA 標準網絡降低存取延遲，並支援 NVIDIA GPUDirect Storage 與 TPUDirect Storage，官方稱即使處理大型多模態資料集，亦可按線路速率傳輸大量資料以維持加速器利用率；同時主張在本地處理資料的同時仍能以滿線路速率外傳，LSSD 與網絡吞吐的平衡比例約為一點四比一。

工作負載分類上，官方表格列出三類：AI／機器學習訓練與推論（檢查點、分散式 KV 快取）；平行檔案系統與企業級儲存（點名合作夥伴 Weka、Sycomp、Silk、VDURA）；以及業務關鍵企業資料庫（SQL、NoSQL、向量資料庫與搜尋）。編排上，可用 Cluster Director 與 Cluster Toolkit 設定、部署與管理大型 Z4M 叢集，並在緊湊拓樸（追求效能）與分散拓樸（高可用／可用性網域）之間選擇，亦可把維護操作合併或錯開；官方並指可將 Z4M 實例與 GPU／TPU 叢集共置，以便即時、大規模處理極大資料集。

維護方面，官方稱 VM 與裸機都會提前數日通知必要維護。LSSD 在約四萬二千 GiB 或以下的 Z4M VM 可在維護事件中即時遷移（live-migrate）；約八萬四千 GiB 或以上的 Z4M VM，以及 Z4M 裸機實例，則須在計劃維護中終止並重新啟動，同時透過計劃維護保留資料。Hyperdisk 支援方面，官方確認 Z4M VM 與裸機可搭配 Hyperdisk Balanced、Hyperdisk Throughput 與 Extreme Hyperdisk，每實例網絡附加儲存容量最高約五百一十二 TiB；一般用途的 Hyperdisk Balanced 每實例最高約三十二萬 IOPS，Hyperdisk Extreme 則標示超低延遲，並支援每 Z4M VM／裸機實例最高約五十萬 IOPS 與約一萬二千五百 MiB／秒吞吐。官方稱 Z4M 已在全球選定區域提供，可在主控台建立新 VM 或 GKE 節點集區時，於 Storage-Optimized 機型系列下選擇 Z4M；區域細節以 Google Cloud 銷售與產品頁為準。

合作夥伴聲明須與官方規格分開理解：Silk 首席研發官 Adik Sokolovski 指，在其測試中 Cloud RDMA 於 Z4M 相對 TCP 延遲最多約低三點七倍、CPU 使用最多約低六倍；WEKA 首席產品官 Ajay Singh 指，在其測試中新 Z4M 相對 Z3 系列讀取吞吐約為兩倍、IOPS 最多約多七成九。Nutanix 與 Sycomp 亦發表對 NC2／智慧資料儲存平台與 Z4M 結合的產品敘事。以上數字均為合作夥伴自身測試主張，並非 YSK Limited 的獨立量測。

二、技術原理深度解析

Z4M 要同時滿足的，是「本地盤夠大、夠密」與「網絡夠快、夠低延遲」兩條通常互相拉扯的約束。AI 訓練檢查點與分散式 KV 快取會產生極大、可平行寫入／讀取的狀態資料；平行檔案系統則要把本地處理與對客戶端的線路速率傳輸疊在同一節點上。官方用高 vCPU：LSSD 密度（一比八百七十五）回應容量與平行度，用 Titanium SSD 卸載本地儲存路徑以減少 CPU 爭用，再用四百 Gbps Cloud RDMA 與 GPUDirect／TPUDirect Storage 把加速器與儲存層之間的往返縮短——並以約一點四比一的 LSSD／網絡吞吐平衡，主張「本地處理」與「對外傳輸」不必二擇一。

對叢集營運而言，Cluster Director 的緊湊／分散拓樸與可用性網域維護錯開，等於把「效能優先共置」與「高可用分散」寫進同一編排面；與 GPU／TPU 叢集共置的敘事，則把 Z4M 明確放在加速器叢集旁邊的「熱資料層」，而不是一般用途的遠端塊儲存替代品。維護模型亦反映本地盤狀態的重量：較小 LSSD 的 VM 仍可即時遷移，超大 LSSD 與裸機則改走計劃終止／重啟並保留資料——這會直接影響容災劇本與批次視窗設計。Hyperdisk 作為可獨立調校效能與容量的網絡附加塊儲存，則補足「本地熱層之外仍需可擴充持久層」的企業資料庫與混合負載需求。

四、日常應用場景

1. 開發者與技術團隊

訓練平台、推論服務與儲存工程團隊，可把 Z4M 評估為檢查點節點、KV 快取層或平行檔案系統資料節點的候選機型：先對照官方的一百九十二 vCPU、一千五百三十六 GiB 記憶體、十六萬八千 GiB LSSD 與四百 Gbps RDMA 上限，再按實際檢查點大小、並發與 GPU／TPU 共置距離做容量與拓樸設計。導入時應分開閱讀官方規格與合作夥伴測試聲明，並以自家基準測試驗證 IOPS、延遲與 CPU 卸載收益；超大 LSSD 與裸機的維護終止／重啟要求，亦應寫進維運 runbook。

2. 企業與隱私敏感行業

金融、醫療與持牌機構若已在 Google Cloud 運行向量資料庫、搜尋或高交易量 SQL／NoSQL，可評估 Z4M 的持續高 I／O 與 Hyperdisk Extreme 路徑是否符合延遲與吞吐目標；有自訂虛擬化或授權綁定硬體的工作負載，則可檢視裸機選項。合規上仍須確認區域可用性、資料駐留、加密與維護窗口是否符合內部政策；代理式 AI 沙箱若涉及敏感工具呼叫，亦應把隔離邊界、映像供應鏈與稽核日誌一併納入設計，而非只看儲存密度。

3. 一般用戶

個人開發者與中小企若尚未有大規模檢查點或平行檔案系統需求，未必需要立刻切到 Z4M；可先以官方文件理解 Storage-Optimized 系列定位，並在真正出現本地盤瓶頸或 RDMA／GPUDirect 需求時再評估。選定區域與配額以 Google Cloud 主控台及銷售資訊為準，不宜假設全球所有區域同步提供相同機型。

4. 香港與亞洲市場視角

香港與亞洲企業正把多模態訓練、企業知識庫與代理式工作流推上雲，本地熱資料層與加速器叢集的共置距離，往往決定訓練吞吐與推論尾延遲。董事會與平台長更關心的是：檢查點能否跟得上 GPU／TPU、平行檔案系統節點密度是否划算、以及維護窗口會否打斷受規管系統。若你正在規劃私有模型託管、熱資料管線與可共置的 AI 基礎設施，可參考 YSK Limited 的企業私有 LLM 全託管與 AI 自動化服務（https://ysk.hk/services/ai-automation），把訓練／推論周邊的儲存與編排需求一併納入架構。

五、專業評價與潛在考量

優勢

官方同步提供 VM 與裸機，並公開十六萬八千 GiB LSSD、四百 Gbps RDMA、一百九十二 vCPU 與一千五百三十六 GiB 記憶體等可核對上限
明確寫出相對 Z3 的 LSSD 效能／吞吐提升主張，以及隨機讀約一千五百六十萬 IOPS、循序讀約七萬五千六百 MiB／秒等數字
把 GPUDirect Storage、TPUDirect Storage、Cluster Director 拓樸與 Hyperdisk 系列一併列入產品敘事，貼近 AI 叢集與企業資料庫雙軌需求
維護規則依 LSSD 規模區分即時遷移與終止重啟，方便容量規劃時預留視窗

需要留意的地方

區域可用性為「選定區域」，具體開通清單須向 Google Cloud 確認，不能假設與加速器區域完全重疊
約八萬四千 GiB 或以上 LSSD 的 VM 與裸機須計劃終止／重啟，對 24×7 關鍵系統可能構成窗口風險
Silk、WEKA 等延遲／IOPS／吞吐倍數均為合作夥伴自身測試主張，部署前應以目標工作負載重跑基準
相對 Z3 的「最多約七成／百分之一百一十」屬供應商世代對比上限敘事，實測會隨存取模式與佇列深度變化
代理式 AI 沙箱僅為官方列舉用途之一；隔離與治理仍依賴上層平台（例如 Agent Substrate 等）的完整設計，而非單靠機型規格

結語

Z4M 把高密度 Local SSD、Titanium 卸載與四百 Gbps Cloud RDMA 收成 Google Compute Engine 上正式可用的儲存優化機型系列，並以檢查點、分散式 KV 快取、平行檔案系統與企業資料庫為主要故事。對正在把 GPU／TPU 叢集與熱資料層共置的香港與亞洲團隊而言，價值在於用可核對的容量與網絡上限，重新估算訓練吞吐與推論資料路徑，而不是把合作夥伴基準測試直接當成自身 SLA。若你需要把私有模型、資料管線與雲端 AI 基礎設施連成可落地的企業方案，可進一步了解 YSK Limited 的企業私有 LLM／AI 自動化服務：https://ysk.hk/services/ai-automation。

參考來源

Google Cloud 官方：Introducing Z4M: storage-optimized compute for AI/ML and parallel file systems — https://cloud.google.com/blog/products/compute/storage-optimized-z4m-machine-series-are-ga/
YSK Limited 企業私有 LLM／AI 自動化 — https://ysk.hk/services/ai-automation