一、迁移支持到什么程度：三种形态

跨域迁移不是一种动作，而是三种形态，代价与适用场景完全不同。

1. 任务动、数据不动

任务本身搬到目标区域，数据仍留在原地，运行时按需读取。适合数据更新频繁、单次读取量可控的场景，比如推理服务与在线交互。它的优点是准备期短，缺点是持续依赖两地之间的传输质量，链路一旦抖动，体验直接受损。

2. 数据动、任务不动

数据一次性搬到算力富集的区域，任务在新数据旁边启动。适合训练这类一次读取、反复迭代的任务。数据到位之后，任务对远端链路的依赖就解除了，后续跑得稳不稳只看本地。代价是首次搬移耗时长，要提前排期。

3. 两边都不动，只同步中间量

原始数据与任务都不出域，两地之间只交换模型参数、梯度或脱敏后的汇总结果。适合数据有边界要求的单位。这种形态保障了边界，也意味着协同深度有限，效果通常不如数据集中训练，要按业务要求取舍。

三种形态可以组合使用。常见的做法是训练走第二种、推理走第一种、敏感环节走第三种，按任务的性质分别安置，而不是一刀切。

二、什么样的任务适合迁：三条判据

不是所有任务都值得跨域迁移。判断一个任务能不能迁、值不值得迁，看三条。

1. 可中断、可续跑

任务要能定期把进度存下来，中断后能从存档点接着跑。训练任务天然满足这一条，长周期的批处理也满足；反过来，高交互的实时任务不满足，中断一秒就是事故。判据很简单：这个任务过去有没有做过中断续跑，做过，就具备迁移的基本条件。

2. 对时延不敏感

迁移的代价里有一项是传输时间。对时延不敏感的任务，多出来的传输时间可以接受；对时延敏感的任务，迁移省下的资源费会被体验损失吃回去。在线对话、实时风控这类任务，通常不该进迁移清单。

3. 环境可复刻

任务在目标区域能不能跑起来，取决于运行环境能否一致：同一套框架版本、同一类硬件规格、同一份依赖清单。环境差异大的任务，迁移前要先把环境固化成可复制的形态，否则到了目标区域还要重新适配，时间成本远超预期。

三条判据两条以上不满足的任务，建议不迁。硬迁的结果是把一次调度动作变成一次工程改造。

三、状态同步：检查点要存全四样

状态同步的核心是检查点。检查点存什么、多久存一次、恢复要多久，三个问题决定迁移的损失有多小。

1. 检查点要包含四部分

一是模型参数本身，这是主体；二是优化器的中间状态，缺了它恢复后续跑的收敛效果会受影响；三是数据读取进度，记到第几批第几个样本，否则恢复后会重复消费已经跑过的数据；四是随机状态，包括各处用到的随机种子，保证恢复前后的运行路径可对齐。四样缺一不可，少一样，恢复出来的任务就带着隐患。

2. 存档频率按损失承受力定

存得密，中断后损失小，但写入开销大；存得疏，写入省事，一旦中断要退回很远。常见做法是按固定间隔存档，另外在关键阶段额外存一次。存档文件要落到独立的存储位置，不要和任务输出混在一个目录，清理时才不会误删。

3. 恢复时间要实测

从任务中断到从存档点恢复运行，这段间隔是可以量化的。成熟体系能做到十几分钟级别回到存档点，前提是存档齐备、环境就绪。恢复时间要在正式迁移前用一次演练测出来，而不是等真实中断时才知道。演练时顺带确认：恢复后的前若干轮运行指标是否与中断前衔接，衔接不上说明存档有缺项。

四、数据搬移：先算账再动手

数据搬移是迁移里耗时较长、也较容易被低估的部分，动手前先把三笔账算清。

1. 体积账

数据集有多大、要搬多少、目标区域留多少余量。全量搬迁与只搬本次任务所需的分片，耗时可能差出一个量级。多数情况下按任务拆分搬移，不必整库搬运。搬移前先做一遍清理：过期的中间产物、重复的副本，留在原地即可，不必跟着走。

2. 时间账

传输耗时按链路的实际带宽估算，不要按标称带宽算。跨区域链路的实际吞吐通常低于理论值，按七成估算比较接近真实。估算出来的时间要和任务排期对齐：数据没到位就启动迁移，任务到了只能空等。

3. 路径账

数据从哪里出发、经过什么通道、落到哪里，路径要提前定好，并且中途不改。搬运过程中途换路径，容易出现两份不一致的副本，事后要花成倍的时间核对。搬运完成后要做完整性校验，比对文件数量与校验值，确认无误再让任务启动。

4. 别忘了镜像与依赖

除了数据，运行镜像、依赖包、编译产物也要同步准备到目标区域。镜像体积大的，提前传输；依赖复杂的，提前在目标区域做一次部署验证。这些物件不起眼，缺一样，任务就起不来。

五、迁移前的一致性核对

规划好的路径，要落到一张核对单上，迁移执行前逐项确认。

1. 环境一致性

目标区域的硬件规格、框架版本、驱动版本与原区域对齐。硬件型号不一致时，要衡量兼容风险：算子支持、精度策略、通信方式都可能因硬件差异而变化，必要时先跑一次小规模验证。

2. 网络一致性

确认两区域之间的传输质量满足要求：带宽够不够、抖动大不大。状态同步依赖链路的稳定性，链路质量差的任务要调高存档频率，把可能的中断损失压小。

3. 权限一致性

原区域的访问授权不会自动带到目标区域，存储权限、镜像拉取权限、日志写入权限都要事先逐项开好。权限遗漏是迁移当天出现频率较高的卡点，且表现为五花八门的报错，排查方向容易跑偏。

4. 回退方案

迁移执行前写明：什么情况算迁移失败、失败后怎么回到原区域继续跑。回退的前提是原区域的环境与数据在迁移期间保持可用，不提前释放、不提前清理。

六、迁移执行与回切

执行阶段的关键不是快，而是稳。

1. 先迁低风险任务

第一次跨域迁移不要拿核心任务做首次尝试。选一个可中断、影响面小的任务先走一遍全流程，把核对单逐项验证一遍，再迁重要任务。首次演练暴露的问题，往往比任何规划讨论都多。

2. 切换时序要错开

原区域的任务停、目标区域的任务起，两个动作之间要留观察窗口，确认目标侧运行正常后再停原侧。两侧同时切换，一旦目标侧起不来，任务就彻底断了。

3. 业务零中断靠什么

秒级切换的案例之所以能做到业务不断流，靠的是任务可秒级重建、状态点齐备、入口自动导向。这三样都依赖前期的规划，不是切换那一刻的技巧。达不到这个条件的任务，就按分钟级或小时级窗口安排切换，把窗口放在业务低峰。

4. 回切机制要保留

迁移到目标区域运行一段时间后，业务可能需要迁回原区域，比如调度周期结束、或目标区域资源紧张。回切与迁移是同一套路径的反向执行，规划时就应包含双向方案。回切演练定期做一次，确保机制真的可用，而不是纸面上的承诺。

七、迁移后的验收与日常化

迁移完成不等于工作结束，还有两件事要做。

1. 验收看三个数

一是任务恢复点之后的运行指标，与迁移前的基线对比，确认效果没有偏移；二是目标区域的资源实际占用，与预估对不对得上；三是迁移全过程的总耗时，含数据搬移、状态恢复、验证观察，记录下来作为下次排期的依据。

2. 沉淀成可复用的迁移手册

把这次迁移的核对单、耗时记录、踩到的坑整理成一份手册。跨域迁移这件事，第一次较费神，从第二次起就有章可循。手册更新的触发条件很明确：每迁一次，补一次。

结语

算网融合调度对任务跨域迁移的支持是真实存在的，工程实践里既有秒级完成的推理切换，也有小时级完成的训练搬迁。但支持的成色取决于规划：状态同步靠齐备的检查点，四样内容缺一不可，恢复时间要靠演练实测；数据搬移靠算清体积、时间、路径三笔账，镜像与依赖也要提前就位；执行阶段先易后难、错峰切换、保留回切。把这套路径规划成固定动作之后，跨域迁移就从一次不可控的尝试变成一次有据可依的调度动作，算力跟着任务走、任务跟着规划走，两条路径都清楚，迁移这件事才算真正落地。