Google Spot VM新增120秒抢占通知正式可用：准备窗口独立于关机脚本
2026年9月30日，Google Cloud宣布Spot VM的120秒抢占通知时长选项正式可用。用户可以在创建Spot虚拟机时选择这一设置，为保存计算进度、停止接收新任务或通知调度器留出额外准备时间。对可中断批处理、模型训练和弹性任务池，这是一项很具体的运行机制变化：需要处理的信号更早出现，但应用必须主动接住它。
配图为AI生成的概念插图，表现计算节点在退出前保存检查点，不是Google Cloud真实界面或时长承诺。
两分钟从元数据信号开始计算
按官方文档，Compute Engine准备抢占时，会把虚拟机默认元数据中的preempted值改为TRUE。通知时长指的是从这个信号出现，到发送ACPI G2 Soft Off软关机信号之间的间隔。创建时可选择120秒，也可以保持默认的0秒；默认值为0意味着没有这段专用等待时间。
软关机信号之后才进入关机阶段，并触发已配置的关机脚本。Spot VM这一阶段是尽力而为，最长30秒。因而“120秒通知”不能改写成“关机脚本自动获得两分钟”，更不能把两个数字相加后向业务承诺绝对可靠的150秒。通知阶段与操作系统关机阶段应分别监测、分别设计职责。
只保留旧关机脚本，可能用不到新窗口
Google在公告中明确提醒，迁移现有工作负载时，需要让应用在关机脚本之外处理抢占，并测试这一过程。这是此次更新最重要的落地条件。若应用仍只等关机脚本启动才保存进度，即使虚拟机配置了较长通知，也可能把前面的时间白白放过去。
一个常见设计是由常驻工作进程监听或等待抢占元数据变化，在检测到信号后进入退出准备状态：不再领取新任务，记录当前任务阶段，把可恢复进度写到虚拟机之外，再让调度器知道该节点不宜接单。具体执行顺序需要根据业务调整。对于跨节点协同任务，还要避免一个节点停接任务而其他节点一直等待它，形成新的僵局。
保存了文件，还要证明能恢复
更长的通知窗口提高了做检查点的可行性，但检查点是否有效仍是应用问题。训练任务可能需要同时保存模型、优化器和数据迭代位置；数据转换任务可能需要记录已提交的输出范围与输入偏移。只写出一个文件、没有记录对应任务状态，恢复时仍可能重复计算或漏处理。
这里可以建立一个清晰的验收标准：在测试环境触发抢占，记录信号收到时间、停止接单时间、检查点完成时间及替代节点恢复时间，然后核对输出是否连续且没有重复。若保存动作本身需要超过窗口，就应调整检查点频率或任务粒度，而不能假定云平台会因为写入尚未结束而继续等待。
STOP与DELETE会决定后续处理
文档说明，终止动作设为STOP或未指定时，抢占后虚拟机进入TERMINATED状态；设为DELETE则删除虚拟机。停止状态下不再收取虚拟机运行小时费用，但保留的持久磁盘仍产生存储费用。自动删除标记也会影响删除虚拟机时的磁盘去留，因此成本和恢复策略必须一起看。
对任务池而言，保留实例与磁盘可能有助于调查问题，但长期留下大量停止资源会带来管理和存储负担。反过来，选择删除实例可以简化资源回收，却要求业务进度已经离开会被一同删除的资源。较长通知不是备份策略，不能成为把唯一检查点放在临时节点上的理由。
低价机制与容量约束没有改变
Google的Spot文档继续说明，Spot资源使用折扣价格，实际价格可能每天变化，并且Spot VM不受Compute Engine服务等级协议覆盖。此次GA公告没有表示抢占风险消失，也没有保证被中断后立即能在原可用区获得替代容量。通知时长提升和资源重新获得的等待时间，是两个不同的问题。
衡量任务成本时，应同时看完成一次任务消耗的计算量、检查点开销、重算损失与恢复等待，而不只看实例小时单价。对于有硬性完成期限的工作，可以测试Spot与常规容量的组合；这属于用户的调度选择，并非本次功能新增的自动保底能力。文章中的两分钟也不是可用性或作业完成时间承诺。
谁值得优先调整
最值得先试的，是已有检查点、单次保存略超旧关机窗口，或需要协调多个参与者退出的工作负载。对完全无状态、可直接丢弃重试的短任务，收益可能较小；对无法安全中断的单点事务，把窗口变长也未必解决根本风险。应从真实中断损失出发，而不是为所有虚拟机统一套用一套动作。
此次更新提供了一段更清晰的准备时间，也把责任边界说得更明确：平台发出信号，应用停止新工作并保存可恢复状态，调度系统再把任务接续下去。把这三段都验证通过，才能把抢占从一次突然失败转化为可预期的任务迁移。
官方资料
资料核对：2026年10月3日。以下解读基于官方公告与文档，产品规则以官方后续更新为准。
