AI 推理和 agent 型负载经常卡在冷启动上：模型权重几十 GB，每次新副本都要重新下载、加载进 GPU 内存，几分钟就过去了；agent 要执行的代码又需要隔离沙箱，每个请求一个，启动慢还不敢及时回收。于是很多人只能过度配置硬件来扛峰值，或者自己做一套应用层的快速恢复系统。

GKE Pod snapshots 是 Google Cloud 刚发布的功能，思路很直接：把运行中的工作负载整体状态——包括 CPU 和 GPU 内存——存成快照，需要的时候直接恢复。官方基准测试里，这种方式把大模型推理的启动时间最多降低了 89%，70B 参数的模型 37 秒启动，8B 参数的模型只要 15 秒。这个速度让基础设施可以按需扩容，不用再为峰值预留大量空闲 GPU。

冷启动在 AI 场景尤其贵。推理服务不仅要初始化进程，还要把几 GB 甚至几十 GB 的模型权重灌进显存，这一项就占掉启动时间的大头。agentic 工作负载更麻烦，代码执行、computer use 工具每次请求都要独立的沙箱，启动要快，空闲时最好能挂起。这两个场景下，启动延迟既毁了用户体验，也堵死了快速自动扩缩容的路。

GKE Pod snapshots 的做法是：先跑一次完整初始化，把 CPU/GPU 内存都抓下来，存到高吞吐的 Cloud Storage。扩容时新副本直接从这份状态恢复，跳过初始化阶段。Google 拿 llama3-70b 做了基准，启动延迟最多降 89%。平台团队因此可以放弃过度配置，改成按需 autoscaling，在满足 SLO 的同时降低空闲 GPU 成本。

对 agent 沙箱，这个功能也解决了两个问题：一是用一份初始沙箱快照快速拉起新沙箱；二是空闲沙箱可以整个挂起、捕获全部计算资源，等需要再近实时恢复。Codeway 旗下的 AI 照片编辑平台 Retake 是典型客户。他们原来在 A3 H100 上跑微调和推理，为了加速启动，自己写了一套复杂的编译产物缓存层，能把启动压到 1 分钟，但维护成本很高，也没法激进地 autoscale。换成 GKE Pod snapshots 后，启动延迟降到 8 秒，H100 可以按需拉起、用完就关，空闲 GPU 成本和代码复杂度都大幅下降。这段来自其 Lead DevOps Engineer 的直接引述。

配置上，GKE Pod snapshots 走的是声明式 CRD 策略：指定要快照哪些 Pod、存在哪里，存储生命周期由系统处理。可以在工作负载启动时通过 workload signal 触发，也可以在 Pod 运行中随时手动触发。还能设置快照保留策略来控制存储成本，恢复行为默认用最近一次快照，也可以在新 Pod 部署时指定用哪个快照。

这个功能本身不挑负载，AI 推理和 agent 沙箱只是最典型的场景。任何初始化阶段很长的应用——比如复杂的 Java 应用、游戏服务器、老单体——都能用同一套机制提速。Google 已经发布了文档，可以直接上手试。