一、迁移前先估算改造量

（一）统计用到的算子

把模型中出现的算子逐一列出，与目标环境的支持清单做一次比对，得到"直接可用""需要替换""需要自研"三档。这一步做完，工作量就有了大致范围。

（二）依赖库的适配情况

除框架本身，还要检查数据处理、分词、图像编解码等依赖库。这些库常常被忽略，却可能在运行到某个分支时才报错，排查起来很费时。

（三）先建立评测基线

在原有环境上跑一遍完整评测并保存结果，作为迁移之后的对照。没有基线的迁移，无法判断结果是否发生变化，也无法定位变化出在哪一步。

二、算子层面的改造

（一）不支持算子的三种处理

第一类是拆分成若干基础算子组合实现，成本最低；第二类是找功能相近的替代算子，需要验证数值差异；第三类才是自研，成本最高，应当尽量压缩到少数几个。

（二）自定义算子的开发

自研算子要同时保证正确性与性能，前者用与参考实现对比的方式验证，后者则要看是否用到了硬件提供的加速能力。两者都达标才算完成。

（三）融合算子的差异

不同环境对算子融合的策略不同，同样的代码可能生成不同的执行图。这会带来性能差异，偶尔也会带来数值差异，需要单独观察。

三、精度对齐怎么做

1. 数值差异从哪来

差异主要来自三方面：算子实现的计算顺序不同、低精度单元的处理方式不同、以及融合策略带来的重排。前两项可以通过配置消除，第三项通常需要代码调整。

2. 对齐的验证步骤

先在单算子上对比输入输出，再在子模块上对比，最后在整机上对比评测结果。由小到大逐层排查，定位速度最快。

3. 可接受的范围

设定一个量化的容差，比如输出差异的相对幅度与评测分数的允许波动。有了数字，就能判断哪些差异需要修、哪些可以接受。

四、性能调优的常见抓手

跑通之后若吞吐不及预期，按下面三条依次排查：

① 先确认数据读取是否跟得上，读取跟不上时算力会长时间空转。

② 再看算子是否有更合适的实现方式，尤其是被替换过的那几个。

③ 最后检查通信开销，多机场景下这部分常占较大比例。

五、回归验证与长期维护

（一）回归用例要覆盖边界

除常规输入外，超长序列、极端数值、空输入都要覆盖。这些边界情况最容易在新旧环境之间表现不一致。

（二）结果要可追溯

每次迁移保存环境版本、算子版本与评测结果，出问题时能快速定位是环境变化还是代码变化。记录可统一放到天翼云存储，便于团队共享。

（三）持续跟踪

框架与驱动更新之后要重跑一遍回归，确认没有引入新的差异。这一步自动化之后成本很低。

六、团队排期与人力分配

（一）改造与验证的比例

经验上验证与调优的时间不应少于改造时间。只算改造工期的排期，几乎都会延期。

（二）保留熟悉原环境的人

迁移期间需要有能随时回到原环境复现问题的人，否则差异定位会非常困难。

（三）分阶段推进

1. 先迁移一个非核心任务，跑通全流程并积累经验之后再推广，比一次性全量切换稳妥得多。

2. 迁移初期建议保留两套环境，关键任务仍在原环境执行，新环境稳定之后再逐步切换。迁移过程中要保留原有环境的访问能力，直到新环境稳定运行一段时间，这样随时可以回到旧环境复现问题。

（四）迁移验证与数值一致性

1. 算子替换之后要做专项验证，尤其是涉及归约、排序这类对顺序敏感的运算，数值差异往往出现在这些地方。

2. 随机数的生成方式也要对齐。不同环境下的随机序列不同，会让对比结果出现难以解释的偏差。迁移清单之外还要留意随机数与初始化方式，这些细节会造成难以解释的结果差异。

3. 数据读取的顺序在不同环境下可能不同，会影响训练过程中的样本排列，进而影响最终结果。

4. 低精度配置要逐项确认，不同环境对各类运算的处理方式存在差异，统一配置能减少偏差。

5. 多卡通信的实现方式要单独验证，这里是性能差异的高发区，也是数值差异的来源之一。

（五）性能对比与调优

1. 编译缓存有时会造成假象：第一次运行慢、之后变快，测性能时要先跑几轮预热再记录。

2. 性能对比要在相同的批量与序列长度下进行，条件不一致时得出的结论没有参考价值。

3. 编译与优化选项会影响最终表现，记录下最优组合并写入文档，减少每次重新摸索。

4. 算子缺失时的替代方案要评估性能影响，有些替代虽然可行，却会明显拖慢整体速度。

5. 显存占用在新环境下可能不同，批量规模需要重新试探，不能直接沿用旧参数。

6. 性能不达标时不要急于下结论，先排除读取与配置问题，再判断是否环境本身的能力限制。

（六）环境、依赖与编译管理

1. 迁移之前把依赖版本锁定并写入配置，减少不同环境下自动拉取到不同的版本。

2. 编译环境的差异也会带来问题，同一份代码在不同编译选项下表现可能不同。

3. 长期维护要考虑框架升级的兼容性，新版本可能引入新的算子或改变默认行为。

4. 训练过程中的日志要完整保留，对比新旧环境时，这些日志是最直接的证据。

（七）团队协作、沟通与归档

1. 迁移的经验要写成文档，包括遇到的问题与解决办法，下一个项目可以直接复用，节省大量时间。

2. 与硬件团队的沟通渠道要提前建立。遇到底层问题时，能快速找到人比自己摸索高效得多。

3. 与供应方建立技术问题反馈渠道，底层问题的定位往往依赖对方提供的工具与信息。

4. 团队内部应当有人专门跟进适配进展，把问题与解决办法集中管理，减少重复踩坑。

5. 评测数据与结果建议归档到天翼云存储，按项目分目录保存，便于长期对比与追溯。

6. 轻量验证任务可以放在天翼云主机上执行，不占用迁移目标的算力，让正式迁移过程更专注。

7. 迁移完成后做一次完整复盘，把耗时分布与主要障碍记录下来，为后续项目提供参考。

（八）推理与自动化脚本迁移

1. 推理场景的迁移相对简单，因为不涉及梯度与优化器，重点只需盯住算子与精度。

2. 自动化脚本要一并迁移并验证，包括数据处理、评测与部署脚本，遗漏会造成返工。

结语：迁移的难点从来不是把代码跑起来，而是让结果对得上、性能不掉队。先把算子清单与评测基线准备好，改造就有了明确的对照物；精度对齐要设一个可量化的容差，而不是凭感觉判断。排期上把调优与回归的时间留足，这两步最容易被压缩，也最容易在上线后才暴露问题。