一、抢占发生的原理：为什么按需实例会被回收

按需付费算力的底层逻辑是资源共享。算力平台把物理GPU集群划分为多个虚拟实例，按需分配给不同用户。当集群资源充裕时，所有按需实例都能正常运行。但当资源紧张时——比如某个大客户启动了大规模训练任务，或者平台需要为预留实例腾出空间——平台会触发资源回收机制。

资源回收的优先级规则通常是固定的。预留实例的优先级高于按需实例。长期运行的按需实例优先级高于刚启动的按需实例。同一优先级的实例按照启动时间排序，后启动的先被回收。这个规则意味着，你的训练任务运行得越久，被回收的风险反而越高——因为系统倾向于保护新启动的任务，牺牲已经运行了一段时间的任务。

抢占的通知机制因平台而异。部分平台会在回收前几分钟发送告警，给用户留出保存检查点和迁移数据的时间。部分平台则不提供任何通知，直接终止实例。了解目标平台的抢占通知策略，是制定防护策略的第一步。如果平台提供抢占告警，可以通过监听告警事件来自动触发检查点保存和任务迁移。

二、预留实例的保障机制：确定性是第一价值

预留实例的核心价值不是省钱，而是确定性。预留实例意味着你预先承诺了一段时期的使用量，平台为此保留了对应的物理资源，不会因为资源紧张而被回收。

预留实例的保障机制分为两个层面。第一个层面是资源预留。平台在物理集群中为你划拨了确定的GPU资源，这些资源不会被其他用户使用，也不会被系统回收。即使集群整体资源紧张，你的预留实例依然正常运行。第二个层面是容量保障。预留实例保证在预留期内，你随时可以启动指定规格的实例，不会遇到“资源不足无法创建”的情况。这对于需要在特定时间窗口内完成训练任务的场景至关重要。

预留实例的代价是你需要为预留的资源支付费用，即使你没有使用。这是一个典型的用成本换确定性的交易。预留的时间越长，单位成本越低，但灵活性也越低。预留的时间越短，灵活性越高，但单位成本也越高。开发工程师需要根据训练任务的稳定性和可预测性来选择预留周期。

预留实例还有一个容易被忽略的好处：它可以作为按需实例的“安全垫”。当按需实例被抢占时，预留实例可以作为备用资源接管训练任务，保证核心业务不中断。这种混合使用的方式，比单纯依赖预留实例或按需实例都更高效。

三、按需实例的适用场景：让它做擅长的事

按需实例虽然有不稳定的缺点，但在某些场景下仍然是不可替代的选择。

第一个适用场景是短周期的实验性任务。调试代码、验证模型结构、测试超参数组合——这些任务通常只需要几分钟到几小时，即使被抢占，损失也很小。而且实验性任务的数量和时机往往不可预测，用预留实例来跑实验会造成严重的资源浪费。

第二个适用场景是弹性扩缩容。当业务高峰期到来，预留实例不足以支撑全部负载时，按需实例可以作为补充资源快速拉起。高峰过后再释放，不需要为闲置资源付费。这种弹性伸缩的能力是按需实例独有的优势。

第三个适用场景是新框架或新工具的测试。当你需要验证某个新框架在特定GPU型号上的表现时，按需实例可以让你快速启动测试环境，测试完成后立即释放，不需要长期承诺。

用好按需实例的关键是接受它的不确定性，并为这种不确定性设计容错机制。如果你的任务不能容忍中断，就不要把它放在纯粹的按需实例上。

四、混合搭配的策略：让预留实例做骨干，按需实例做弹性

预留实例和按需实例不是非此即彼的选择，而是可以协同工作的搭档。合理的搭配策略可以让两者的优势互补，劣势对冲。

最经典的搭配策略是“预留实例做基座，按需实例做弹性”。具体来说，分析你的训练任务在过去一个月中的资源使用曲线，找到资源使用的基线值——也就是无论何时都至少需要这么多GPU才能维持基本运转。将这个基线值用预留实例来覆盖，保证核心任务在任何时候都不会被中断。超出基线的部分，也就是峰值需求，用按需实例来补充。

举例来说，你的团队通常需要8张GPU来维持日常训练，但每周会有两天需要16张GPU来处理大批量数据。这种情况下，可以预留8张GPU作为基座，另外8张GPU在需要时用按需实例拉起。预留实例保证了日常训练的稳定性，按需实例提供了峰值期间的弹性。

另一种搭配策略是“预留实例跑长任务，按需实例跑短任务”。长周期训练任务——比如大模型的预训练、微调和强化学习——对稳定性要求极高，一旦中断损失巨大，应该放在预留实例上。短周期任务——比如数据预处理、模型评估、推理验证——对稳定性要求较低，可以放在按需实例上，即使被抢占也可以快速重新拉起。

还有一种策略是针对多团队共享资源的场景。核心团队的训练任务使用预留实例，保证业务连续性。外围团队或临时项目的任务使用按需实例，提高资源利用率。这种策略需要在团队之间建立清晰的资源分配规则和优先级体系。

五、自动容错与断点续训：为抢占做好准备

无论采用哪种搭配策略，都不可能完全杜绝按需实例被抢占的情况。为抢占做好准备，是负责任的技术方案必须包含的内容。

自动容错的核心是检查点机制。训练脚本应该定期保存模型权重、优化器状态、学习率调度器状态、当前epoch和batch编号等关键信息。检查点的保存频率需要权衡——保存太频繁会增加IO开销和训练时间，保存太少又会增加中断后的损失。通常的做法是每完成一个epoch保存一次，或者每隔固定步数保存一次。

当抢占发生时，系统应该能够自动检测到实例被回收，并触发一系列恢复动作。检测抢占的方式有多种：监听平台提供的抢占告警事件、定期检查实例的健康状态、监控训练进程的输出日志。检测到抢占后，系统应该立即保存当前状态的检查点，然后将任务重新提交到可用的实例上。

断点续训的逻辑是从最近的检查点恢复，而不是从头开始。恢复时加载模型权重和优化器状态，跳过已经完成的epoch和batch，继续后续的训练。断点续训的精度取决于检查点的保存频率——如果检查点保存得足够频繁，恢复后的训练结果与从未中断过的训练结果之间的差异可以忽略不计。

对于使用混合搭配策略的团队，自动容错系统还应该具备资源调度的能力。当一个按需实例被抢占时，系统可以自动将任务迁移到预留实例上，或者重新申请一个新的按需实例。迁移过程中需要处理好数据同步和环境一致性的问题。

六、成本与稳定性的权衡：找到你的平衡点

预留实例和按需实例的搭配没有标准答案，每个团队都需要根据自己的业务特点找到平衡点。

成本敏感型团队可能倾向于多用按需实例、少用预留实例。这种策略的成本较低，但稳定性较差，需要较强的自动容错能力来弥补。适合预算有限、训练任务多为短周期实验的团队。

稳定性优先型团队可能倾向于多用预留实例、少用按需实例。这种策略的稳定性最高，但成本也最高，可能出现预留资源闲置的情况。适合核心业务对稳定性要求极高、预算相对充裕的团队。

均衡型团队的做法是前面提到的“预留实例做基座，按需实例做弹性”。这种策略在成本和稳定性之间取得了较好的平衡，适合大多数常规的AI研发团队。

还有一个容易被忽视的因素是团队的技术能力。自动容错和断点续训的实现需要一定的工程投入。如果团队没有足够的工程能力来实现这些机制，那么即使选择了成本较低的按需实例策略，实际损失可能反而更大。在这种情况下，适当增加预留实例的比例，用成本换取稳定性，反而是更经济的选择。

结语

按需付费算力避免资源被抢占，核心不在于完全抛弃按需实例，而在于学会把预留实例和按需实例搭配使用。预留实例提供稳定性和确定性，适合承载长周期核心训练任务；按需实例提供弹性和灵活性，适合承载短周期实验和峰值负载。两者搭配使用时，“预留实例做基座、按需实例做弹性”是最经典的策略。同时，自动容错和断点续训机制是所有策略的基础保障——无论采用哪种搭配方案，都要为抢占做好准备。开发工程师在设计算力资源方案时，最需要把握的原则是“用确定性覆盖核心，用弹性应对波动，用容错兜底意外”。当这三个层面都部署到位时，按需付费的不确定性就不再是威胁，而是可以被管理和利用的资源特性。