Google 公布的基准测试显示，GKE Pod 快照最高可将启动延迟降低 89%，并让一个 70B 参数模型在 37 秒内完成加载。它通过 gVisor 检查点保存 CPU 与 GPU 内存，再把快照写入 Cloud Storage。对于大模型推理服务，这相当于把启动路径从“重新下载并加载模型”改成“恢复已经准备好的进程状态”。
但速度只是问题的一半。快照能否复用取决于 Pod spec 哈希、机器系列、内核以及驱动版本等条件。模型、运行时或底层节点发生变化后，旧快照到底应该复用、隔离还是删除，往往比创建快照更考验平台工程能力。
37 秒恢复意味着什么
大模型 Pod 的冷启动通常包含多段工作：
- 调度到具备足够 GPU 和内存的节点；
- 拉取容器镜像；
- 下载或挂载模型权重；
- 把权重读入 CPU 内存；
- 初始化 CUDA、通信库和推理引擎；
- 将参数搬入 GPU 显存，并进行预热。
Pod 快照保存的是已经运行起来的状态，包括 CPU 和 GPU 内存，因此可以跳过其中相当一部分重复计算与数据搬运。对于 70B 级别模型，权重体积、反序列化时间和显存初始化成本都很高，所以快照恢复的收益尤其明显。
不过，“最高降低 89%”不能直接当作所有工作负载的容量规划数据。实际恢复时间仍会受到以下因素影响：
- Cloud Storage 到节点的吞吐和并发读取压力；
- 快照大小以及 CPU、GPU 内存规模；
- 节点是否已经就绪，还是需要等待集群扩容；
- 容器镜像和依赖层是否命中缓存；
- 快照恢复后的健康检查与应用预热时间；
- 同一时间恢复多少个副本。
因此，团队需要分别记录“节点等待时间”“快照读取时间”“进程恢复时间”和“首次请求可服务时间”，而不是只观察 Pod 从 Pending 变成 Running 的时长。
复用快照的边界比创建快照更重要
快照并不是普通模型缓存。它包含与执行环境紧密耦合的内存状态，所以兼容性判断必须保守。已知匹配条件包括 Pod spec 哈希、机器系列、内核版本和驱动版本。这些条件变化后，平台不应假设旧快照仍然安全可用。
实际管理中还应把应用层状态纳入失效键：
- 模型名称、精确 revision 或文件摘要；
- 容器镜像 digest，而不是可变的
latest标签； - 推理引擎版本及其编译参数；
- CUDA、GPU 驱动和相关通信库版本；
- 量化方式、张量并行规模和最大上下文长度；
- 影响内存布局的启动参数；
- 机器系列和 GPU 型号；
- 应用自身定义的快照 ABI 版本。
一种稳妥做法是生成显式的 SNAPSHOT_COMPAT_KEY，并把它放进 Pod spec。这样，只要关键输入变化，Pod spec 就会变化，不会无意中匹配旧快照。
下面是一个可改造的 Deployment 片段。它不会自行启用 GKE Pod 快照；快照功能的开通方式应以当前 GKE 版本和项目配置为准。这个示例只负责把应用层兼容性键写进 Pod spec：
apiVersion: apps/v1
kind: Deployment
metadata:
name: model-server
namespace: inference
spec:
replicas: 1
selector:
matchLabels:
app: model-server
template:
metadata:
labels:
app: model-server
spec:
containers:
- name: server
# 运行前替换为真实镜像，并使用不可变 digest。
image: REGION-docker.pkg.dev/PROJECT/REPOSITORY/model-server@sha256:REPLACE_ME
env:
- name: MODEL_REVISION
value: "model-70b-revision-2025-01"
- name: SNAPSHOT_COMPAT_KEY
value: "replace-with-generated-hash"
resources:
limits:
nvidia.com/gpu: "8"
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
failureThreshold: 60
这里把兼容性键放在容器环境变量中，而不只放在 Deployment 注解里，是为了确保它确实构成 Pod spec 的一部分。修改该值会触发滚动更新，也会改变用于匹配的规格输入。
用脚本生成失效键，而不是靠人工记忆
下面的脚本可以直接保存为 update-snapshot-key.sh。运行前需要准备一个已存在的 inference/model-server Deployment，并设置模型 revision、镜像 digest、机器系列、内核基线和 GPU 驱动版本。
#!/usr/bin/env bash
set -euo pipefail
NAMESPACE="${NAMESPACE:-inference}"
DEPLOYMENT="${DEPLOYMENT:-model-server}"
CONTAINER="${CONTAINER:-server}"
: "${MODEL_REVISION:?Set MODEL_REVISION, for example model-70b@abc123}"
: "${IMAGE_DIGEST:?Set IMAGE_DIGEST, for example sha256:0123...}"
: "${MACHINE_SERIES:?Set MACHINE_SERIES, for example a3}"
: "${KERNEL_LINE:?Set KERNEL_LINE to the approved node kernel baseline}"
: "${GPU_DRIVER:?Set GPU_DRIVER to the deployed GPU driver version}"
SNAPSHOT_ABI="v1"
COMPAT_KEY="$({
printf 'model=%s\n' "$MODEL_REVISION"
printf 'image=%s\n' "$IMAGE_DIGEST"
printf 'machine=%s\n' "$MACHINE_SERIES"
printf 'kernel=%s\n' "$KERNEL_LINE"
printf 'driver=%s\n' "$GPU_DRIVER"
printf 'snapshot_abi=%s\n' "$SNAPSHOT_ABI"
} | sha256sum | awk '{print $1}')"
echo "Applying snapshot compatibility key: $COMPAT_KEY"
kubectl -n "$NAMESPACE" set env \
deployment/"$DEPLOYMENT" \
--containers="$CONTAINER" \
SNAPSHOT_COMPAT_KEY="$COMPAT_KEY"
kubectl -n "$NAMESPACE" annotate deployment "$DEPLOYMENT" \
snapshot-ops.example.com/compat-key="$COMPAT_KEY" \
--overwrite
kubectl -n "$NAMESPACE" rollout status \
deployment/"$DEPLOYMENT" \
--timeout=30m
示例运行方式：
chmod +x update-snapshot-key.sh
MODEL_REVISION='model-70b@8f27c1d' \
IMAGE_DIGEST='sha256:0123456789abcdef' \
MACHINE_SERIES='a3' \
KERNEL_LINE='approved-kernel-2025-01' \
GPU_DRIVER='approved-driver-550' \
./update-snapshot-key.sh
脚本中的内核和驱动值应来自节点镜像发布流程或集群资产清单，而不是开发者手工猜测。更成熟的流水线可以从目标节点池读取这些信息，在部署前自动生成兼容性键。
要注意，这段脚本只保证关键变化进入 Pod spec，并不替代 GKE 自身的匹配检查。平台仍然可能因为机器系列、内核或驱动不兼容而拒绝某个快照；这是一种必要的安全边界。
Cloud Storage 也需要生命周期和安全策略
快照写入 Cloud Storage 后，会产生新的运维对象：大文件、多个版本、跨环境访问权限以及持续增长的存储成本。如果只创建不清理，过期快照会逐渐变成昂贵而难以审计的库存。
可以为快照使用独立 Bucket，并设置生命周期规则。下面的例子会删除 pod-snapshots/ 前缀下超过 14 天的对象。运行前必须把 BUCKET_NAME 替换为专用 Bucket 名称，并确认该 Bucket 没有其他需要长期保存的数据：
cat > snapshot-lifecycle.json <<'EOF'
{
"rule": [
{
"action": {
"type": "Delete"
},
"condition": {
"age": 14,
"matchesPrefix": ["pod-snapshots/"]
}
}
]
}
EOF
BUCKET_NAME='replace-with-dedicated-snapshot-bucket'
gcloud storage buckets update "gs://${BUCKET_NAME}" \
--lifecycle-file=snapshot-lifecycle.json
保留时间不应只按成本决定，还要覆盖回滚窗口。如果生产环境允许回滚到最近三个模型版本，那么生命周期策略和版本发布频率必须确保这三个版本的快照仍然存在。
安全方面也不能把它当作普通静态模型文件。内存快照可能包含访问令牌、解密后的配置、用户请求片段或应用缓存。因此至少要检查：
- Bucket 是否使用最小权限 IAM；
- 生产与测试快照是否彻底隔离；
- 是否需要客户管理的加密密钥；
- 快照读写与删除操作是否进入审计日志；
- 应用是否会把长期凭据或敏感请求保留在内存中；
- 删除 Bucket 对象后，相关快照元数据是否也会清理。
上线前把它当成一套缓存系统来验收
Pod 快照适合模型大、初始化昂贵、运行环境相对稳定的推理服务。频繁更换驱动、每天重建节点镜像，或者模型每小时更新的场景，可能会出现命中率低、存储量高的问题。
上线前建议确认以下事项：
- 用业务自己的模型测量冷启动和恢复时间，不直接套用基准数字；
- 为模型、镜像、驱动、内核和推理引擎定义统一兼容性键；
- 对快照命中、未命中、恢复失败和回退到冷启动分别监控；
- 在批量扩容测试中验证 Cloud Storage 吞吐，而不只测试单个 Pod；
- 为旧快照配置自动过期策略，并保留必要的回滚版本；
- 把内存快照纳入敏感数据、IAM、加密和审计范围；
- 验证快照恢复失败时，服务能够安全退回常规冷启动。
GKE Pod 快照把模型加载时间从计算和 I/O 问题转化成了缓存一致性问题。37 秒恢复很有吸引力，但长期收益取决于团队能否准确回答三个问题：这个快照属于哪个版本、它还能在哪类节点上恢复，以及什么时候必须删除它。