算力合同里那句“提前若干天通知即可解除”，工程上要准备什么
一、通知期不是法务条款，是你的可迁移窗口
据公开报道，两家公司之间的一份算力协议里，有可提前较短时间发出通知即解除的安排，报道给出的量级是九十天。这个天数我们只当例子，不代表行业通用惯例，也不据此对任何一方作评价或推断协议的真实性与后续变化。本篇只借这一条条款问一个纯工程的问题：当对方能在一个较短通知期后把你正在用的容量撤走时，被服务的一方手里到底要有多少东西，才谈得上活下去。
很多人把解除条款读成一句谈判筹码，觉得真到那天再去谈。错在时间。通知期就是你可迁移窗口的物理长度，窗口一旦短过迁移所需时长，谈判空间是别人给的，不是自己挣的。所以读这类合同的正确姿势，是先假设解除会在通知期结束时真的发生，再看每一项条款在这个假设下意味着什么。
二、读算力合同要盯死的六个条款
一份算力合同，工程侧要逐字确认的条款有六项，每一项都直接对应一个动作。
| 条款 | 要问的问题 | 读出问题的后果 |
|---|---|---|
| 容量性质 | 是保证值还是尽力值 | 尽力值意味着高峰可能给你不了，得自己留余量 |
| 解除通知期与触发条件 | 多久通知、什么条件触发 | 决定你的可迁移窗口有多长 |
| 迁出期与费用 | 解除后数据给你多久搬、搬走要不要另收费 | 迁出期短过迁移时长，数据就卡在原地 |
| SLA 与赔偿上限 | 达不到承诺赔到哪为止 | 上限过低时赔偿远盖不住业务中断损失 |
| 硬件型号变更 | 换成别的型号算不算违约 | 若不算，你的一致性验证要随时准备重跑 |
| 替代容量权 | 能否自建或转购别家 | 不许转购，缺口就没有合规的补法 |
六条里最容易被跳过的是硬件型号变更这一条。合同允许对方把容量换成另一代或另一型号的硬件而不算违约，那你就不能把效果绑定在某一种硬件上——换型会改变数值表现与并行切分，你的收敛曲线和一致性验证都得跟着重来。第二条解除通知期是全篇的锚，后面所有预案都围着它展开。
三、按通知期长短，反推该备三套不同的预案
通知期不同，该做的准备完全不同，别一套预案套到底。我们按三档分。
短通知期的档位，窗口可能不够现场迁移，唯一能活的做法是容量已经在别处预热过——第二家在离线、可切换的路由已经配好，随时能切。这时你备的不是迁移步骤，而是一份常备的备用容量与切换开关。
中通知期的档位，窗口刚好够搬，但要留出回归验证的余量。这档要的不是随时切的冗余，而是一套演练过、能在规定时长内跑完的迁移预案：谁负责搬、按什么顺序搬、搬完怎么验。
长通知期的档位，你有充足时间，反而不必投入工程冗余，把力气放在合同谈判上就行，把迁出期、赔偿、变更这些条款谈到对自己有利。
分档的价值在于别把资源投错：短窗口还不备预热容量是赌博，长窗口却去养双份容量是浪费。判断落在同一个动作上——把通知期的量级和自己实测的迁移时长放到一起比，谁长谁短决定进哪一档。
四、列一份如果明天被解除的依赖清单
不管在哪一档，都该有这张清单：假设今天收到解除通知，明天就要动，你到底依赖对方什么。依赖项要点名到能交接的粒度，至少九项。
- 训练任务与检查点位置：跑到一半的任务、上一次落盘的检查点存在哪、能不能完整取走。
- 数据与对象存储副本：训练与评测数据是否只有一份在对侧，本地有没有可独立访问的副本。
- 镜像与依赖仓库：运行时镜像、包与模型依赖能不能整体导出，别只剩一个引用。
- 推理服务与网关：线上推理链路的配置、路由与鉴权怎么迁走。
- 缓存与向量库：热缓存和已建索引能否迁出，重建要多久。
- 监控与日志管道：历史日志与指标的存放位置、导出格式、保留期。
- 密钥与证书：调用密钥、TLS 证书在谁手里，能不能自行签发替换。
- DNS 与出口 IP 白名单：依赖对方固定出口 IP 的下游白名单，换了地址会不会断。
- 外部数据源的拉取通道：训练数据若靠一条专线或对侧代理拉取，断供后走哪条路。
这张清单的纪律在于逐问能不能独立访问。只要有一项的答案是只能等对方给我，它就是解除时的单点。清单要定期回填状态，不是列一次就完。
五、迁移时长要测五项，最容易被低估的是效果一致性
预案能不能落地，取决于你对迁移时长的实测，而不是感觉。要测的五项是：数据搬迁耗时（受带宽封顶，几百 TB 不是点一下就完）、环境重建耗时、任务重放与检查点对齐耗时、效果一致性验证耗时、以及双跑期的资源成本。前四项各测一次就有数，第五项是钱要单独算。
其中最容易被低估的是效果一致性验证。原因不是它慢，而是它根本不是能不能跑通的问题。不同代际、不同型号的硬件，会改变浮点数值表现和并行切分方式，同一段训练在新环境里的收敛曲线可能对不上，Loss 能降不代表结果和原来等价。你真正要验的是同一批评测任务在新旧两套环境上的指标差异、输出格式稳定性与成本对比，差异超过阈值时还要有一套取舍规则。把这段想成跑起来就行，就会在最不该出问题的时候出问题。
由此推出双跑期的定法：双跑要开多久，由一致性验证真正需要的天数决定，不能拿上线日期倒推着砍。双跑期省下的钱，往往在切换后发现是拿没验透的风险换的。
六、真被撤了容量怎么补，迁出证明和一张长期台账
即便有窗口，也可能出现容量缺口，应对分三档，代价从轻到重：短期租用其它区域的容量顶上去；把非关键的训练任务先停掉，把资源让给主链路；缩小训练规模，并明确记录这是一次性能降级而不是正常水位。三档要提前定好触发条件，真到那天不至于临时拍脑袋，尤其第三档的降级记录，是事后对外解释效果变化的依据。
数据与模型的迁出要有证明，不能只是搬完了。要留导出清单、逐份数据的校验方式，并要求原侧在约定时点清除、留下一条清除记录。这三样建议直接写进合同的迁出条款里，作为解除时的固定动作，而不是事后临时索取。
最后把这一切收成一张运维台账。每一笔容量承诺记成一行：来源、保证量、可用窗口、通知期、到期日、对应业务、替代方案与替代方案的就绪度。有了这张表，通知期就不再是合同里的一句话，而是能和就绪度并排比较的一个数——哪笔业务压在一份短通知、又没有预热替代的容量上，一眼就看得境。
洹拓给做算力采购这一侧的建议是：把解除条款当成工程约束来读，先假设它会真的发生，再用依赖清单和迁移时长实测回答那个最朴素的问题——从收到通知到跑起来，我需要多少天，而我手里到底有没有这么多天。