谷歌发布 GKE Pod 快照的基准测试结果。根据这份报告，启动延迟最高可以降低 89%：一个 700 亿参数的模型仅需 37 秒即可加载完毕，而一个 80 亿参数的模型仅需 15 秒。该功能可以保存工作负载的运行状态（包括 CPU 和 GPU 内存）并按需恢复。该功能已经于今年 5 月在运行 1.35.3-gke.1234000 及更高版本的集群上正式发布。
该快照属于检查点和恢复机制而非缓存。快照保留了应用程序运行时的所有内容：打开的文件描述符、线程、CPU 寄存器、内存。它还保留了容器的根文件系统、EmptyDir 卷以及 tmpfs 挂载点。新副本将从该状态继续运行，但不会执行加载模型的初始化过程。对于大型模型而言，这正是启动时最耗时的部分。
让这一切成为可能的是 gVisor，不过有一个前提条件：Pod 必须在 GKE Sandbox 中运行，因为 gVisor 运行时就驻留在该环境中。Autopilot 集群已经预装了 gVisor。标准集群则需要一个已启用 gVisor 的节点池。每个节点上的智能代理负责管理快照的生存周期，控制平面上的控制器则负责清理过期的快照。数据存储在 Cloud Storage 中。
配置工作由两个自定义资源完成。PodSnapshotStorageConfig 指向存储桶；PodSnapshotPolicy 根据标签选择 Pod，将触发器设置为工作负载或手动，并通过 lastAccessTimeout 以及每个组的快照数量上限来设置保留策略。
谷歌提供的客户案例是 Codeway。其 Retake 平台为编译后的构建产物配备了自定义缓存层，将启动时间缩短至 1 分钟。首席 DevOps 工程师 Ahmet Furkan Çomak 表示，Pod 快照将这一时间进一步缩短至“仅 8 秒”。现在，该团队会为特定任务启动 H100 实例，并在任务完成后将其关闭。
从业者的反应更多地集中在捕获快照之后发生的事情上，而非捕获过程本身。对于 Suresh Rajashekaraiah 在 LinkedIn 上对这次发布的分析，资深 DevOps 和 MLOps 工程师 Mohana Narasimha G. 写道：
恢复路径确实很有吸引力，但我怀疑快照失效问题比捕获本身更难解决。模型摘要、CUDA/驱动程序版本、GPU 类型/拓扑以及运行时配置都将成为关键的兼容性因素；而机密信息、 DNS 和下游连接在恢复后都需要显式地重新加载。你是否将快照视为不可变的工件，并在调度前进行了准入检查？
谷歌的文档解答了这个问题的前半部分。GKE 会根据 Pod 的关键运行时字段生成一个哈希值（称为“精简 Pod 规范”），并将其嵌入到快照中；从该快照恢复的 Pod 必须生成完全相同的哈希值。目标节点必须具有相同的机器系列和 CPU 架构（例如 N2 到 N2 或 G2 到 G2），而且 gVisor 内核版本与 GPU 驱动程序版本必须与快照中的版本一致。如果不存在兼容的快照，那么 Pod 将正常启动。
仅限 rootfs 作用域的快照会放宽这些规则。GKE 将跳过哈希值比较。而且，由于不会恢复进程内存，所以快照可以跨机器系列，包括迁移到 E2。
恢复半程（rehydration half）仍然由应用程序负责，相关文档对此有明确的说明。快照创建之前生成的加密密钥和证书必须在恢复后重新创建，因为恢复后的进程会继续保留其被冻结时的状态。环境变量存储在应用程序内存中，gVisor 无法可靠地查找和替换它们。因此，依赖新值的工作负载必须从 /proc/gvisor/spec_environ 目录下的文件中读取这些值。恢复操作会终止所有外部连接，并且不会针对持久化卷执行检查点操作，用户手动添加的 iptables、nftables 规则及路由条目也不会恢复。
如果上述变化具有代表性，那么工作重心将转向管理快照而非启用该功能。节点池升级后，gVisor 内核或 GPU 驱动程序的版本可能会发生变化，现有的快照将不再匹配。此时，Pod 会按照文档中描述的回退机制正常启动，而且不会出现任何错误，但由此带来的优势也便不复存在。
无论宣传的数据怎么样，恢复过程也并非瞬间就能完成。gVisor 内核会首先恢复，通常在几秒钟内完成。这时应用程序会开始运行，但其内存仍然在后台加载中。
硬件支持范围比宣传所暗示的要窄：E2 机器类型不支持 whole-pod 快照，多 GPU Pod 仅在 L4 GPU 上支持，而且不支持通过 Multi-Instance GPU 实现的 GPU 共享。
治理问题源于快照所包含的内容。Cloud Storage 中的文件保存了正在运行的工作负载的完整内存，而在代理沙箱的情况下，这部分内存曾用于执行不受信任的、由模型生成的代码。访问权限基于工作负载身份联合（Workload Identity Federation）以及每个 Pod 服务账户的 IAM 绑定。谷歌指出，这些绑定的传播可能需要一定的时间。
代理沙箱方案是以此为基础构建的。GKE 代理沙箱已经于 5 月正式发布。谷歌表示，其预热池每秒可以为每个集群分配多达 300 个沙箱，其中 90% 可以在 200 毫秒内完成；该方案利用 Pod 快照来暂停空闲代理，而不是使计算资源保持在预热状态。Agent Substrate 是谷歌同期推出的开源项目，用于在更高密度场景下探索相同的暂停与恢复多路复用机制。其代码库明确注明，该项目尚未准备好投入生产环境。
Meet Shah 是云平台与人工智能工程部门的副总裁 。他明确界定了两者的区别：
Agent Sandbox GA 是你执行安全规划的基础。Agent Substrate 则仍然在开放环境中持续演进。
谷歌对该功能的描述是“与工作负载无关”，并列举了 Java 应用、游戏服务器和传统单体应用，以及 AI 推理等场景。该功能留给团队的决策项包括：哪些节点池运行 gVisor、哪个存储桶存放快照以及谁可以读取它、快照的保留时长，以及当工作负载从预期之外的冻结状态恢复时需要刷新什么内容。
原文链接：https://www.infoq.com/news/2026/09/gke-pod-snapshots-benchmarks/
