用抢占式实例跑第一性原理计算

它便宜，但随时可能被收回去。把"会被打断"当成设计前提，而不是意外，你就能安全地用它省下大部分机时费。

2026-10-17 · 约 7 分钟读完

一、它便宜的原因就是你担心的那件事

抢占式（竞价）实例用的是云厂商的闲置算力，价格随供需浮动，通常明显低于按量付费。作为交换，厂商需要在容量紧张时收回这些机器，会给一个短暂的宽限期（具体时长与通知方式以厂商文档为准），之后实例被停止或释放。

所以判断一个任务能不能上抢占式，只问一句：被强行中断后，我损失多少？

二、把"丢结果"变成"丢十分钟"

关键只有一件事：让检查点足够频繁，让任务可以从最近一次检查点原样重启。VASP 天然支持这件事，前提是你别偷懒：

1. 几何优化：每个离子步结束后，VASP 都会写 CONTCAR。用 cp CONTCAR POSCAR 续算即可；把 ISTART=1, ICHARG=1 之外的默认设置保持原样，避免从头算电荷密度。
2. 单点/静态：保留 CHGCAR，中断后用 ICHARG=11 读回，省掉一次完整的自洽。
3. WAVECAR：续算最省时间的入口，但它体积大（几 GB 到几十 GB）。只在你确实要续算时开 LWAVE=.TRUE.，否则每个离子步都写一次盘，IO 会吃掉可观的时间。
4. 每 N 步同步到对象存储：本地盘随实例一起消失，务必把关键文件（OUTCAR、CONTCAR、CHGCAR）定时同步出去。一个 5 分钟的定时任务足够。

# 每 10 分钟把关键结果推到对象存储（示例思路，路径按需改）
*/10 * * * * cd /root/calc && ossutil cp -r -u . oss://my-bucket/calc/ >> /var/log/sync.log 2>&1

三、避免"整批实例同时消失"

批量跑 20 个体系时，最糟的情况是它们全被同一时间回收。三个降低风险的做法：

• 分散规格与可用区：不要 20 台全部同规格同可用区，混合 2～3 种规格能显著降低同时被收的概率。
• 任务粒度切小：把"一个 200 步的优化"拆成"4 个 50 步的段"，每段独立提交，被回收只损失一段。
• 监控 + 自动重提：一个外部脚本每隔几分钟检查实例与任务状态，发现实例消失就把未完成的任务重新提交到新实例。这是性价比最高的一步，通常是几十行脚本。

四、省下的钱到底有多少

用估算器算出总 core-hour 之后，把单价换成抢占式的实际单价再算一次，两者之差就是你能承受的"重跑损失"。一个经验法则：

值得用抢占式 ⇔ 中断概率 × 单次损失机时 < 省下的机时费

举例：任务总机时 500 core-hour，按量 0.06 元、抢占式 0.03 元，全跑完省 15 元；即使被中断两次、每次损失 20 core-hour 的重算（约 1.2 元），依然划算。反过来，如果是跑一周的 GW，中断一次就是全部白费，再便宜也不该用。

五、什么时候不值得折腾

如果你的任务总量只有几十 core-hour，抢占式省下的钱可能还不到一杯咖啡，而多出来的运维脚本、存档规则、重提逻辑会消耗你一整天。这种情况下直接按量跑完，把时间花在算例本身。