谷歌发布GKE Pod快照，模型启动延迟最高降89%

谷歌公布的基准测试显示，GKE Pod快照可将大模型服务启动延迟最高降低89%。70B参数模型恢复加载约需37秒，8B参数模型约需15秒。该功能已于2026年5月随1.35.3-gke.1234000及更高版本正式推出。

这项能力属于检查点与恢复机制，并非普通缓存。快照会保存CPU、GPU内存、线程、文件描述符、寄存器、容器根文件系统、EmptyDir和tmpfs等状态，使新副本直接从冻结位置继续运行，跳过最耗时的模型初始化。底层依赖gVisor，因此Pod必须运行在GKE Sandbox中；Autopilot已预装，标准集群则需使用启用gVisor的节点池。快照数据存放于Cloud Storage，节点代理负责生命周期管理，控制面控制器负责清理过期内容。

用户可通过两个自定义资源完成配置：PodSnapshotStorageConfig用于指定存储桶，PodSnapshotPolicy则按标签选择Pod，并设置工作负载触发或手动触发、lastAccessTimeout以及每组快照数量上限。Codeway的Retake平台此前通过自定义缓存将构建产物启动时间降至1分钟，使用Pod快照后进一步缩短至8秒；团队还可按任务启动H100实例，完成后关闭。

恢复并非没有限制。GKE会根据关键运行时字段生成“精简Pod规范”哈希并写入快照，恢复时必须完全匹配；目标节点的机器系列、CPU架构、gVisor内核和GPU驱动版本也必须一致。若找不到兼容快照，Pod会正常启动。仅恢复rootfs的快照不比较哈希，也能跨机器系列迁移至E2，但不会恢复进程内存。节点升级导致内核或驱动变化时，旧快照会失效并触发无错误回退。

应用仍需自行完成恢复后的重新初始化。加密密钥和证书必须重建，依赖新环境变量的程序应从/proc/gvisor/spec_environ读取；外部连接会被终止，持久化卷不会被检查点，手动添加的iptables、nftables规则和路由也不会恢复。gVisor通常数秒内先完成内核恢复，应用随后启动，但内存可能仍在后台加载。

目前E2不支持whole-pod快照，多GPU Pod仅支持L4，且不支持通过MIG共享GPU。由于Cloud Storage中的快照包含完整运行内存，其中可能有模型生成的不受信任代码，访问权限依赖Workload Identity Federation和Pod服务账户的IAM绑定，权限传播也可能存在延迟。

该机制还被用于GKE Agent Sandbox：其预热池每秒可为每个集群分配最多300个沙箱，90%可在200毫秒内完成，并用快照暂停空闲代理。同期推出的开源Agent Substrate仍处于非生产状态。团队需要自行决定启用gVisor的节点池、快照存储桶及访问者、保留期限，以及工作负载从冻结状态恢复后需要刷新哪些内容。