根據 InfoQ 在 2026 年 9 月的報導，Google 公布了 GKE Pod Snapshots 的基準測試結果。這項功能主要解決大型 AI 模型啟動時間過長的問題。測試數據顯示，啟動延遲最高可降低 89%，一個 700 億參數的模型可以在 37 秒內完成載入，80 億參數的模型則只需 15 秒。該功能已於 2026 年 5 月正式推出，適用於 GKE 1.35.3-gke.1234000 或更新版本的叢集。
這不是快取，而是檢查點與恢復機制。快照保存的是工作負載當下完整的執行狀態，包括 CPU 與 GPU 記憶體、開啟的檔案描述符、執行緒、CPU 暫存器，以及容器根檔案系統、EmptyDir 磁碟區和 tmpfs 掛載。當新的 Pod 副本啟動時，它直接從快照恢復，跳過載入模型參數的初始化過程，而這正是大型模型啟動時間的主要來源。
核心內容：gVisor 與 GKE Sandbox
要實現這種暫停與恢復，關鍵在於 gVisor。gVisor 是一個以使用者空間方式運作的容器執行期，它攔截系統呼叫，讓整個工作負載的狀態可以被序列化保存。因此，使用 Pod Snapshots 的前提是 Pod 必須在 GKE Sandbox 中執行。Autopilot 叢集已經內建 Sandbox，Standard 叢集則需要建立開啟 gVisor 的節點池。
在架構上，每個節點上有一個代理程式負責處理快照的生命週期，控制平面上的控制器則負責清除過時的快照，快照資料儲存在 Cloud Storage。配置透過兩個自訂資源完成：PodSnapshotStorageConfig 用來指定存放快照的儲存桶，PodSnapshotPolicy 則依標籤選取 Pod，設定觸發方式為 workload 或 manual，並以 lastAccessTimeout 和每組快照數量上限來控制保留策略。
相容性與恢復限制
Google 的文件明確說明了快照恢復的相容性規則。GKE 會根據 Pod 的關鍵執行期欄位產生一個雜湊值，稱為精煉 Pod 規格，並將它嵌入快照中；要從快照恢復的 Pod 必須產生完全相同的雜湊值。目標節點也必須具備相同的機器系列與 CPU 架構，例如 N2 對 N2、G2 對 G2，同時 gVisor 核心版本與 GPU 驅動程式版本都必須一致。如果找不到相容的快照，Pod 就會以正常方式啟動。
如果採用僅根檔案系統的範圍，規則會放寬。GKE 會跳過雜湊比對，而且因為不恢復處理程序記憶體，快照可以跨機器系列使用，甚至包括 E2。但完整 Pod 快照目前不支援 E2 機器類型，多 GPU Pod 僅支援 L4 GPU，也不支援 Multi-Instance GPU 共享。
恢復後的重新水合是應用程式必須自己處理的部分。加密金鑰與憑證在快照前建立的話，恢復後必須重新建立，因為恢復的處理程序會繼續持有凍結當下的狀態。環境變數存在應用程式記憶體中，gVisor 無法可靠地找到並替換它們，因此依賴新值的應用程式必須從 /proc/gvisor/spec_environ 檔案讀取。外部連線在恢復時會終止，持久磁碟區不會被納入快照，使用者自行加入的 iptables 或 nftables 規則與路由也不會恢復。此外，恢復並非瞬間完成。gVisor 的核心會先恢復，通常只需幾秒，應用程式在此時就開始運行，但記憶體仍在背景載入中。
實務影響與社群反應
Google 提供的客戶案例是 Codeway。該公司的 Retake 平台原本有一套自訂的快取層來加速編譯產物，將啟動時間壓低到約一分鐘。首席 DevOps 工程師 Ahmet Furkan Çomak 表示，改用 Pod Snapshots 後，啟動時間縮短到 8 秒。團隊現在可以針對特定工作啟動 H100 實例，完成後就關閉，不需要維持常駐的運算資源。
實務社群的反應集中在快照之後的生命週期管理，而非快照本身。在 LinkedIn 上，Suresh Rajashekaraiah 發布了對這項功能的分析，資深 DevOps 與 MLOps 工程師 Mohana Narasimha G. 在回應中指出，快照失效會比快照本身更難處理。模型摘要、CUDA 與驅動程式版本、GPU 類型與拓撲、執行期設定都會成為相容性金鑰的一部分；密鑰、DNS 與下游連線則需要在恢復後明確重新水合。這段回應也提出了一個尖銳的問題：團隊是否應該將快照視為不可變更的工件，並在排程前加入准入檢查。Google 的文件針對相容性問題給出了具體規則，但後半部分——是否在排程前進行准入檢查——則留給團隊自己處理。如果節點池升級，gVisor 核心或 GPU 驅動程式版本可能改變，既有快照就不再匹配，Pod 會依照文件記載的備援路徑正常啟動，不會報錯，但快照帶來的效益就消失了。
安全與生態系統
安全治理是另一個需要考量的面向。快照檔案放在 Cloud Storage 中，內容是執行中工作負載的完整記憶體。在代理程式沙盒的場景中，這份記憶體可能執行過不受信任的、由模型產生的程式碼。存取控制依賴 Workload Identity Federation（一種讓工作負載以自身身分取得雲端資源存取權的機制）與每個 Pod 服務帳戶的 IAM 綁定，Google 也提醒這些權限的傳播可能需要時間。
GKE Agent Sandbox 同樣在 5 月達到 GA，Google 表示其暖池每秒可配置最多 300 個沙盒，其中 90% 在 200 毫秒內完成，而且它使用 Pod Snapshots 來暫停閒置代理程式，而不是保持運算資源持續待命。Google 同時推出的開源專案 Agent Substrate 則在探索更高密度的暫停與恢復多工複用，但官方儲存庫明確標示尚未達到生產就緒。雲端平台與 AI 工程副總裁 Meet Shah 在兩者之間畫出界線：Agent Sandbox GA 是可以規劃的安全執行基礎，Agent Substrate 則是在開源中持續發展的密度篇章。
Google 將這項功能描述為與工作負載無關，除了 AI 推論之外，也提到 Java 應用程式、遊戲伺服器與傳統單體應用程式。但團隊仍然需要決定哪些節點池執行 gVisor、快照儲存在哪個儲存桶以及誰能讀取、快照保留多久，以及工作負載從一個它沒有預期會被凍結的狀態恢復時，需要重新整理哪些資料。這些決策，才是 Pod Snapshots 真正把工作轉移到的地方。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。