GKE Pod 快照把 AI 推理的「冷启动」变成「内存快照恢复」做推理服务的人都有一个共同的痛扩容慢。新副本起来了但它得先把几十 GB 的模型权重从存储读进 GPU 内存 —— 这期间 Pod 是 Running但一个请求都接不了。K8s 的 HPA 看着 Running 就认为扩容成功实际流量打进来全是超时。GKE 的Pod 快照Pod snapshots就是来解决这件事的。它不是加速模型加载而是干脆跳过加载——把一个已经跑起来的 Pod 的内存状态整个存下来新副本直接从这份内存快照里醒过来。这篇文章基于 Google 官方文档把它的机制、边界、以及几个很容易踩的坑讲清楚。一、它到底做了什么官方定义很直接Pod 快照通过恢复正在运行的 Pod 的快照来缩短工作负载启动延迟。快照会保存整个 Pod 状态包括内存和文件系统更改。创建新副本时系统从快照恢复这些副本从而让工作负载恢复resume而不是从新状态开始。这里的动词很关键不是start是resume。官方点名的受益场景就包括把大量权重加载到内存中的 AI 推理模型以及加载大量依赖项的应用。反过来官方也明确说了什么时候没用启动时间已经很短的工作负载通常不会受益于 Pod 快照。所以别拿它去优化一个本来 2 秒就起来的服务 —— 恢复内核本身就要几秒钟。二、架构三个 CRD 三段式分工整套东西是声明式的由三个自定义资源描述CRD作用PodSnapshotStorageConfig指定快照存储位置。仅支持 Cloud Storage 存储桶PodSnapshotPolicy按Kubernetes 标签选择器定义要拍快照的 Pod包含大部分配置含触发方式、快照范围、保留政策PodSnapshotManualTrigger可选。不用工作负载触发器时用它手动为特定 Pod 创建快照运行时是三段分工每个 GKE 节点上的代理管理快照生命周期按策略决定何时创建快照、何时用现有快照恢复新 PodGKE 控制平面上的控制器清理过时快照、解决问题Cloud Storage存快照数据。三、快照到底存了什么官方原表这张表是全文最实用的部分直接决定你的应用能不能用类别✅ 已包含❌ 已排除应用状态进程内存、执行线程、CPU 寄存器、打开文件描述符无捕获所有内存中的进程状态文件系统容器根文件系统rootfs、emptyDir卷、tmpfsPersistentVolumeClaim 对象、其他未列出的卷/存储类型网络环回连接、监听套接字、Unix 网域套接字活跃的外部连接恢复时关闭自定义路由—用户定义的规则iptables、nftables两个要特别注意的点emptyDir和 tmpfs 会被存下来但 PVC 不会。如果你把模型权重放在 PVC 上快照里没有它 —— 恢复后还得重新读盘。外部连接在恢复时被关闭。如果 Pod 里维持着到数据库、到上游服务的长连接恢复后这些连接是断的应用必须自己能重连。四、两种触发方式别选错工作负载触发器手动触发怎么做Pod 内的应用主动向 GKE 代理发信号表明已准备好被快照创建PodSnapshotManualTriggerCR执行次数在工作负载周期中执行一次例如就绪状态下可按需执行任意次适用最适合缩短横向伸缩的启动延迟你无法修改应用去发就绪信号时选型逻辑很清楚如果你的应用能改加一行我准备好了的信号用工作负载触发器 —— 这样每次都是在一个已知良好的状态下拍快照。如果应用是第三方的、动不了才退而用手动触发。五、⚠️ 最容易踩的坑恢复 ≠ 可用这一节建议所有做推理服务的人认真看。官方文档里写得很清楚但很容易被忽略。恢复过程是这样的GKE Sandbox 内核先恢复—— 通常需要几秒钟内核一恢复应用立即恢复执行不等应用内存加载完—— 这是为了最大限度缩短启动延迟应用内存靠后台流式传输慢慢灌如果应用读到还没加载的内存 → 触发缺页中断→ GKE Sandbox 拦截、暂停该线程、立即从存储拉取所需内存页这个按需拉取的优先级高于后台流。代价是恢复后的前几秒内存访问会有短暂延迟等内存状态完全同步才消失。而最关键的一句是这句 —— 它同样适用于 GPU大语言模型LLMPod可能看起来处于 Running 状态即使其 GPU 内存仍在填充中也会响应网络检查。在 GPU 状态完全恢复之前模型不会完全响应推理。翻译一下这个陷阱你以为的Pod Running → 可以接流量了 实际上的Pod Running → 网络探针通了 → 但模型还不响应推理如果你用默认的 **readiness probe就绪探针**做判断它会误报就绪—— 探针只是网络层面通了不代表模型能推理。官方给的解法衡量恢复速度时必须以模型服务器准备好处理请求为准可以用TTFTTime To First Token首次令牌时间或者改Pod 就绪性探针让它真的能判断模型是否就绪这件事的实际后果如果你的 HPA 依赖 readiness而 readiness 又误报那么扩容瞬间打进来的流量会全部超时。快照省下的加载时间可能被这段假就绪窗口吃掉。六、GPU 状态是怎么存的GPU 这块单独说因为机制不太一样触发 GPU Pod 的快照时NVIDIA 的cuda-checkpoint工具会把 GPU 状态保存到进程内存这样能确保存在 GPU 上的数据比如模型权重被包含进快照GKE 会暂停 Pod然后拍摄快照恢复时反向执行。⚠️ 一个具体的容量陷阱由于 GPU 状态会写入进程内存在快照和恢复操作期间Pod 内存用量会增加。在为 Pod 设置内存限额时请考虑这一额外的内存需求。也就是说你的 memory limit 不能按模型跑起来占多少来设得留出 GPU 状态序列化到内存时的那一份。设得太紧会在拍快照那一刻被 OOM Kill。七、恢复后必须处理的 6 件事从 Kubernetes API 看恢复出来的是一个新的 Pod 对象。有些状态必须变才能作为新实例运行#项恢复后1网络接口收到新 IP所有接口和路由重新配置快照时的外部连接被关闭监听套接字、环回、Unix 域套接字正常2主机名采用新身份、新主机名3挂钟时间跳到当前时间4应用状态每个 Pod 的应用状态必须唯一例如实验 ID 或随机数种子——必须在恢复后重新初始化5Secret拍摄快照前创建的加密密钥和证书必须重新创建6环境变量快照与恢复之间可以改但环境变量存在应用内存里GKE Sandbox无法可靠地找到并替换它们。若恢复后依赖新环境变量Pod 必须手动刷新新变量可在/proc/gvisor/spec_environ取用格式同/proc/pid/environ第 4 条最容易被忽略。如果你的服务用随机数种子、UUID、或者启动时生成的自增 ID 来区分实例 ——恢复出来的每个副本都会带着同一个种子。做 A/B 实验、做请求去重、做分片路由的这一条会直接出 bug。八、兼容性不是随便就能恢复能不能从快照恢复取决于一套匹配规则。whole-pod 范围默认严精简规范哈希GKE 从 Pod 规范的基本运行时字段算出唯一哈希目标 Pod 必须算出相同的哈希。字段范围包括containersname / image / command / args / workingDir / ports / volumeMounts / securityContext …、initContainers、volumes、dnsPolicy、runtimeClassName等等。硬件兼容目标 Pod 必须在相同机器系列 CPU 架构的节点上 ——N2 只能到 N2G2 只能到 G2。版本兼容GKE Sandbox 内核版本和GPU 驱动程序版本必须与快照捕获时一致。rootfs-only 范围松GKE 1.35.3-gke.1031000不计算、不比较精简 Pod 规范哈希—— 可以恢复到资源、环境或其他配置字段不同的目标 Pod底层容器映像和节点版本仍须兼容因为不恢复进程内存可以跨机器系列恢复包括 E2。这就是两个范围的核心取舍whole-podrootfs-only恢复内容进程内存 文件系统只有文件系统匹配严格度严哈希 机器系列 内核/驱动版本松跨机器系列❌✅含 E2加速效果跳过模型加载只省掉文件系统准备如果你要的是跳过几十 GB 权重加载必须用 whole-pod—— rootfs-only 不恢复进程内存GPU 里的权重还得重新灌。九、硬性要求清单要跑起来这些条件一条都不能少项要求集群版本1.35.3-gke.1234000 或更高身份必须启用Workload Identity Federation for GKEAutopilot 默认启用沙箱Pod 必须在 GKE Sandbox 中运行快照依赖它提供的隔离环境。Autopilot 默认支持Standard 需创建或更新节点池GPU 支持范围单 GPU Pod单 GPU / 多 GPU 节点均支持多 GPU Pod仅 L4g2-standard-*支持的机型g2-standard-4/8/12/16/321×L4、g2-standard-484×L4、g2-standard-968×L4、a2-highgpu-1g1×A100-40GB、a2-ultragpu-1g1×A100-80GB、a3-highgpu-1g1×H100-80GB启用命令# Autopilot新建集群gcloud container clusters create-auto CLUSTER_NAME\--enable-pod-snapshots\--locationCONTROL_PLANE_LOCATION\--cluster-versionCLUSTER_VERSION# 已有集群先把版本升上去再开启gcloud container clusters upgrade CLUSTER_NAME\--cluster-versionCLUSTER_VERSION\--locationCONTROL_PLANE_LOCATION gcloud container clusters update CLUSTER_NAME\--enable-pod-snapshots\--locationCONTROL_PLANE_LOCATION十、限制清单选型前先看这个限制说明E2 机型默认whole-pod 范围不支持 E2文件系统快照rootfs-only支持MIG不支持多实例 GPUMIG共享Cloud Storage FUSE CSI边车容器不支持Pod 快照TPU不支持Autopilot 默认机型GKE可能默认用不支持快照的机器类型。用 whole-pod 时官方建议用自定义 ComputeClass优先兼容机型Autopilot 那条有个现成的坑你什么都不配Autopilot 可能给你调度到 E2 上然后快照功能直接不可用。官方的做法是定义一个ComputeClassapiVersion:cloud.google.com/v1kind:ComputeClassmetadata:name:non-e2-classspec:priorities:-machineFamily:n2-machineFamily:c3activeMigration:optimizeRulePriority:falsewhenUnsatisfiable:DoNotScaleUp然后在 Pod 里引用spec:nodeSelector:cloud.google.com/compute-class:non-e2-classwhenUnsatisfiable: DoNotScaleUp的意思是宁可扩容失败也不要调度到不兼容的机器上。十一、多租户场景的一个延迟问题如果你是多租户每个租户一个 ServiceAccount这里有个坑Pod 快照需要为每个 Pod 的 Kubernetes ServiceAccount 手动创建 IAM 绑定才能使用 Cloud Storage。手动 IAM 绑定可能需要一段时间才能传播——如果你需要在创建 Pod 后立即拍摄快照这可能会成为问题。解法不用手动绑定改用节点服务账号按需铸造短期令牌。在PodSnapshotStorageConfig里用tokenSource字段取值行为podKSA默认Pod 的 ServiceAccount 与 Cloud Storage 存储桶之间的手动 IAM 绑定federatedP4SA由节点服务账号铸造的、特定于路径的令牌多租户规模大的话federatedP4SA能省掉IAM 传播等待这一环。小结把 GKE Pod 快照的要点浓缩成几句它加速的不是加载是恢复—— 把已运行 Pod 的内存整个存下来新副本从内存快照 resume而不是 start。最大的坑是Running ≠ 可用—— 官方明说 LLM Pod 可能在 GPU 内存还没填满时就响应网络检查默认 readiness 探针会误报。必须用 TTFT 或能真正反映模型就绪的探针。GPU 状态会写进进程内存会吃内存限额—— 设 memory limit 时要留出余量否则拍快照那一刻会被 OOM。whole-pod 与 rootfs-only 是两条路—— 想跳过权重加载只能用 whole-pod但它匹配严格机器系列、内核、驱动版本都要一致且不支持 E2。它不是万能加速器—— 启动本来就快的工作负载、TPU、MIG 共享、Cloud Storage FUSE 边车都不适用。一句话选型如果你的痛点是几十 GB 权重每次扩容都要重灌这个功能值得评估如果只是Pod 调度慢那不是它解决的问题。参考资料内容来源核验时间快照机制、包含/排除内容、触发方式、兼容性匹配、后台加载、GPU 状态、恢复后差异、要求与限制GKE Pod 快照简介官方文档 · 简体中文2026-10-07集群版本要求、Workload Identity Federation、启用命令、ComputeClass 示例准备使用 Pod 快照官方文档 · 简体中文2026-10-07CRD 字段参考PodSnapshot CustomResourceDefinition 参考文档2026-10-07说明本文未引用任何第三方基准数字。InfoQ 有一篇带性能数据的报道但其页面返回HTTP 405人机验证未能核对原文故不使用。标签云原生/kubernetes、人工智能摘要≤256 字GKE Pod 快照通过保存正在运行 Pod 的完整内存与文件系统状态让新副本从快照 resume 而非重新初始化用于缓解 AI 推理等重加载工作负载的扩容延迟。本文基于 Google 官方文档梳理三个 CRD 的分工、快照包含与排除的内容、工作负载触发与手动触发两种方式、whole-pod 与 rootfs-only 两种范围的兼容性差异并重点说明三个易踩的坑 —— LLM Pod 可能显示 Running 但 GPU 内存未填充完、默认就绪探针会误报须用 TTFT 衡量、GPU 状态写入进程内存会推高内存用量。另附集群版本、机型、Sandbox 等硬性要求与限制清单。 GKE Pod 快照：把 AI 推理的「冷启动」变成「内存快照恢复」
GKE Pod 快照把 AI 推理的「冷启动」变成「内存快照恢复」做推理服务的人都有一个共同的痛扩容慢。新副本起来了但它得先把几十 GB 的模型权重从存储读进 GPU 内存 —— 这期间 Pod 是 Running但一个请求都接不了。K8s 的 HPA 看着 Running 就认为扩容成功实际流量打进来全是超时。GKE 的Pod 快照Pod snapshots就是来解决这件事的。它不是加速模型加载而是干脆跳过加载——把一个已经跑起来的 Pod 的内存状态整个存下来新副本直接从这份内存快照里醒过来。这篇文章基于 Google 官方文档把它的机制、边界、以及几个很容易踩的坑讲清楚。一、它到底做了什么官方定义很直接Pod 快照通过恢复正在运行的 Pod 的快照来缩短工作负载启动延迟。快照会保存整个 Pod 状态包括内存和文件系统更改。创建新副本时系统从快照恢复这些副本从而让工作负载恢复resume而不是从新状态开始。这里的动词很关键不是start是resume。官方点名的受益场景就包括把大量权重加载到内存中的 AI 推理模型以及加载大量依赖项的应用。反过来官方也明确说了什么时候没用启动时间已经很短的工作负载通常不会受益于 Pod 快照。所以别拿它去优化一个本来 2 秒就起来的服务 —— 恢复内核本身就要几秒钟。二、架构三个 CRD 三段式分工整套东西是声明式的由三个自定义资源描述CRD作用PodSnapshotStorageConfig指定快照存储位置。仅支持 Cloud Storage 存储桶PodSnapshotPolicy按Kubernetes 标签选择器定义要拍快照的 Pod包含大部分配置含触发方式、快照范围、保留政策PodSnapshotManualTrigger可选。不用工作负载触发器时用它手动为特定 Pod 创建快照运行时是三段分工每个 GKE 节点上的代理管理快照生命周期按策略决定何时创建快照、何时用现有快照恢复新 PodGKE 控制平面上的控制器清理过时快照、解决问题Cloud Storage存快照数据。三、快照到底存了什么官方原表这张表是全文最实用的部分直接决定你的应用能不能用类别✅ 已包含❌ 已排除应用状态进程内存、执行线程、CPU 寄存器、打开文件描述符无捕获所有内存中的进程状态文件系统容器根文件系统rootfs、emptyDir卷、tmpfsPersistentVolumeClaim 对象、其他未列出的卷/存储类型网络环回连接、监听套接字、Unix 网域套接字活跃的外部连接恢复时关闭自定义路由—用户定义的规则iptables、nftables两个要特别注意的点emptyDir和 tmpfs 会被存下来但 PVC 不会。如果你把模型权重放在 PVC 上快照里没有它 —— 恢复后还得重新读盘。外部连接在恢复时被关闭。如果 Pod 里维持着到数据库、到上游服务的长连接恢复后这些连接是断的应用必须自己能重连。四、两种触发方式别选错工作负载触发器手动触发怎么做Pod 内的应用主动向 GKE 代理发信号表明已准备好被快照创建PodSnapshotManualTriggerCR执行次数在工作负载周期中执行一次例如就绪状态下可按需执行任意次适用最适合缩短横向伸缩的启动延迟你无法修改应用去发就绪信号时选型逻辑很清楚如果你的应用能改加一行我准备好了的信号用工作负载触发器 —— 这样每次都是在一个已知良好的状态下拍快照。如果应用是第三方的、动不了才退而用手动触发。五、⚠️ 最容易踩的坑恢复 ≠ 可用这一节建议所有做推理服务的人认真看。官方文档里写得很清楚但很容易被忽略。恢复过程是这样的GKE Sandbox 内核先恢复—— 通常需要几秒钟内核一恢复应用立即恢复执行不等应用内存加载完—— 这是为了最大限度缩短启动延迟应用内存靠后台流式传输慢慢灌如果应用读到还没加载的内存 → 触发缺页中断→ GKE Sandbox 拦截、暂停该线程、立即从存储拉取所需内存页这个按需拉取的优先级高于后台流。代价是恢复后的前几秒内存访问会有短暂延迟等内存状态完全同步才消失。而最关键的一句是这句 —— 它同样适用于 GPU大语言模型LLMPod可能看起来处于 Running 状态即使其 GPU 内存仍在填充中也会响应网络检查。在 GPU 状态完全恢复之前模型不会完全响应推理。翻译一下这个陷阱你以为的Pod Running → 可以接流量了 实际上的Pod Running → 网络探针通了 → 但模型还不响应推理如果你用默认的 **readiness probe就绪探针**做判断它会误报就绪—— 探针只是网络层面通了不代表模型能推理。官方给的解法衡量恢复速度时必须以模型服务器准备好处理请求为准可以用TTFTTime To First Token首次令牌时间或者改Pod 就绪性探针让它真的能判断模型是否就绪这件事的实际后果如果你的 HPA 依赖 readiness而 readiness 又误报那么扩容瞬间打进来的流量会全部超时。快照省下的加载时间可能被这段假就绪窗口吃掉。六、GPU 状态是怎么存的GPU 这块单独说因为机制不太一样触发 GPU Pod 的快照时NVIDIA 的cuda-checkpoint工具会把 GPU 状态保存到进程内存这样能确保存在 GPU 上的数据比如模型权重被包含进快照GKE 会暂停 Pod然后拍摄快照恢复时反向执行。⚠️ 一个具体的容量陷阱由于 GPU 状态会写入进程内存在快照和恢复操作期间Pod 内存用量会增加。在为 Pod 设置内存限额时请考虑这一额外的内存需求。也就是说你的 memory limit 不能按模型跑起来占多少来设得留出 GPU 状态序列化到内存时的那一份。设得太紧会在拍快照那一刻被 OOM Kill。七、恢复后必须处理的 6 件事从 Kubernetes API 看恢复出来的是一个新的 Pod 对象。有些状态必须变才能作为新实例运行#项恢复后1网络接口收到新 IP所有接口和路由重新配置快照时的外部连接被关闭监听套接字、环回、Unix 域套接字正常2主机名采用新身份、新主机名3挂钟时间跳到当前时间4应用状态每个 Pod 的应用状态必须唯一例如实验 ID 或随机数种子——必须在恢复后重新初始化5Secret拍摄快照前创建的加密密钥和证书必须重新创建6环境变量快照与恢复之间可以改但环境变量存在应用内存里GKE Sandbox无法可靠地找到并替换它们。若恢复后依赖新环境变量Pod 必须手动刷新新变量可在/proc/gvisor/spec_environ取用格式同/proc/pid/environ第 4 条最容易被忽略。如果你的服务用随机数种子、UUID、或者启动时生成的自增 ID 来区分实例 ——恢复出来的每个副本都会带着同一个种子。做 A/B 实验、做请求去重、做分片路由的这一条会直接出 bug。八、兼容性不是随便就能恢复能不能从快照恢复取决于一套匹配规则。whole-pod 范围默认严精简规范哈希GKE 从 Pod 规范的基本运行时字段算出唯一哈希目标 Pod 必须算出相同的哈希。字段范围包括containersname / image / command / args / workingDir / ports / volumeMounts / securityContext …、initContainers、volumes、dnsPolicy、runtimeClassName等等。硬件兼容目标 Pod 必须在相同机器系列 CPU 架构的节点上 ——N2 只能到 N2G2 只能到 G2。版本兼容GKE Sandbox 内核版本和GPU 驱动程序版本必须与快照捕获时一致。rootfs-only 范围松GKE 1.35.3-gke.1031000不计算、不比较精简 Pod 规范哈希—— 可以恢复到资源、环境或其他配置字段不同的目标 Pod底层容器映像和节点版本仍须兼容因为不恢复进程内存可以跨机器系列恢复包括 E2。这就是两个范围的核心取舍whole-podrootfs-only恢复内容进程内存 文件系统只有文件系统匹配严格度严哈希 机器系列 内核/驱动版本松跨机器系列❌✅含 E2加速效果跳过模型加载只省掉文件系统准备如果你要的是跳过几十 GB 权重加载必须用 whole-pod—— rootfs-only 不恢复进程内存GPU 里的权重还得重新灌。九、硬性要求清单要跑起来这些条件一条都不能少项要求集群版本1.35.3-gke.1234000 或更高身份必须启用Workload Identity Federation for GKEAutopilot 默认启用沙箱Pod 必须在 GKE Sandbox 中运行快照依赖它提供的隔离环境。Autopilot 默认支持Standard 需创建或更新节点池GPU 支持范围单 GPU Pod单 GPU / 多 GPU 节点均支持多 GPU Pod仅 L4g2-standard-*支持的机型g2-standard-4/8/12/16/321×L4、g2-standard-484×L4、g2-standard-968×L4、a2-highgpu-1g1×A100-40GB、a2-ultragpu-1g1×A100-80GB、a3-highgpu-1g1×H100-80GB启用命令# Autopilot新建集群gcloud container clusters create-auto CLUSTER_NAME\--enable-pod-snapshots\--locationCONTROL_PLANE_LOCATION\--cluster-versionCLUSTER_VERSION# 已有集群先把版本升上去再开启gcloud container clusters upgrade CLUSTER_NAME\--cluster-versionCLUSTER_VERSION\--locationCONTROL_PLANE_LOCATION gcloud container clusters update CLUSTER_NAME\--enable-pod-snapshots\--locationCONTROL_PLANE_LOCATION十、限制清单选型前先看这个限制说明E2 机型默认whole-pod 范围不支持 E2文件系统快照rootfs-only支持MIG不支持多实例 GPUMIG共享Cloud Storage FUSE CSI边车容器不支持Pod 快照TPU不支持Autopilot 默认机型GKE可能默认用不支持快照的机器类型。用 whole-pod 时官方建议用自定义 ComputeClass优先兼容机型Autopilot 那条有个现成的坑你什么都不配Autopilot 可能给你调度到 E2 上然后快照功能直接不可用。官方的做法是定义一个ComputeClassapiVersion:cloud.google.com/v1kind:ComputeClassmetadata:name:non-e2-classspec:priorities:-machineFamily:n2-machineFamily:c3activeMigration:optimizeRulePriority:falsewhenUnsatisfiable:DoNotScaleUp然后在 Pod 里引用spec:nodeSelector:cloud.google.com/compute-class:non-e2-classwhenUnsatisfiable: DoNotScaleUp的意思是宁可扩容失败也不要调度到不兼容的机器上。十一、多租户场景的一个延迟问题如果你是多租户每个租户一个 ServiceAccount这里有个坑Pod 快照需要为每个 Pod 的 Kubernetes ServiceAccount 手动创建 IAM 绑定才能使用 Cloud Storage。手动 IAM 绑定可能需要一段时间才能传播——如果你需要在创建 Pod 后立即拍摄快照这可能会成为问题。解法不用手动绑定改用节点服务账号按需铸造短期令牌。在PodSnapshotStorageConfig里用tokenSource字段取值行为podKSA默认Pod 的 ServiceAccount 与 Cloud Storage 存储桶之间的手动 IAM 绑定federatedP4SA由节点服务账号铸造的、特定于路径的令牌多租户规模大的话federatedP4SA能省掉IAM 传播等待这一环。小结把 GKE Pod 快照的要点浓缩成几句它加速的不是加载是恢复—— 把已运行 Pod 的内存整个存下来新副本从内存快照 resume而不是 start。最大的坑是Running ≠ 可用—— 官方明说 LLM Pod 可能在 GPU 内存还没填满时就响应网络检查默认 readiness 探针会误报。必须用 TTFT 或能真正反映模型就绪的探针。GPU 状态会写进进程内存会吃内存限额—— 设 memory limit 时要留出余量否则拍快照那一刻会被 OOM。whole-pod 与 rootfs-only 是两条路—— 想跳过权重加载只能用 whole-pod但它匹配严格机器系列、内核、驱动版本都要一致且不支持 E2。它不是万能加速器—— 启动本来就快的工作负载、TPU、MIG 共享、Cloud Storage FUSE 边车都不适用。一句话选型如果你的痛点是几十 GB 权重每次扩容都要重灌这个功能值得评估如果只是Pod 调度慢那不是它解决的问题。参考资料内容来源核验时间快照机制、包含/排除内容、触发方式、兼容性匹配、后台加载、GPU 状态、恢复后差异、要求与限制GKE Pod 快照简介官方文档 · 简体中文2026-10-07集群版本要求、Workload Identity Federation、启用命令、ComputeClass 示例准备使用 Pod 快照官方文档 · 简体中文2026-10-07CRD 字段参考PodSnapshot CustomResourceDefinition 参考文档2026-10-07说明本文未引用任何第三方基准数字。InfoQ 有一篇带性能数据的报道但其页面返回HTTP 405人机验证未能核对原文故不使用。标签云原生/kubernetes、人工智能摘要≤256 字GKE Pod 快照通过保存正在运行 Pod 的完整内存与文件系统状态让新副本从快照 resume 而非重新初始化用于缓解 AI 推理等重加载工作负载的扩容延迟。本文基于 Google 官方文档梳理三个 CRD 的分工、快照包含与排除的内容、工作负载触发与手动触发两种方式、whole-pod 与 rootfs-only 两种范围的兼容性差异并重点说明三个易踩的坑 —— LLM Pod 可能显示 Running 但 GPU 内存未填充完、默认就绪探针会误报须用 TTFT 衡量、GPU 状态写入进程内存会推高内存用量。另附集群版本、机型、Sandbox 等硬性要求与限制清单。