当前版本只支持在A+K（Ascend+Kunpeng）形式的组合硬件上部署使用，MindIO UCE和MindIO ARF不支持在Atlas 800 训练服务器（型号：9000）上使用。
众多大模型框架都支持ZeRO（Zero Redundancy Optimizer）来减少对显存的使用，当前MindIO TFT仅支持开启ZeRO-1，支持DP（Data Parallelism） Size为偶数，同时使用不同的功能对DP Size有不同的限制：
- MindIO TTP功能
  - 为了保证故障发生后，有完整的优化器状态数据，要求副本数是2时，DP Size大于1；其他副本数时要求DP Size能被副本数整除。
  - 开启MoE（Mixture of Experts）前要求稠密层DP Size大于1；开启MoE后要求稠密层和稀疏层DP Size都大于1。
  - 针对分布式优化器，MindIO TFT实现优化器数据副本的方式，是在ZeRO-1功能的基础上，通过以算代传实现，在DP Size域上减少优化器ZeRO-1切分范围，实现了优化器副本。
- MindIO UCE和MindIO ARF功能
  - 若要实现从当前Step恢复训练，对DP Size限制与MindIO TTP功能一致。
  - 对于显存有限，不做副本的情况，即DP Size=1，此时若发生UCE或者节点故障，支持在线从周期性CheckPoint中加载模型权重和优化器参数恢复训练，损失当前Step到上次周期性CheckPoint的Step之间的训练成本。
- 分布式优化器在开启ZeRO特性后，优化器状态数据全局只有一份，无数据冗余。MindIO TFT通过增加优化器状态冗余数据副本，保证故障场景下优化器状态数据的完整性，但同时该方案会导致片上内存使用增加。在原有的模型配置基础上，直接使用MindIO TFT可能会导致模型训练启动过程中出现片上内存OOM（Out Of Memory）异常。在此情况下，需要通过扩容增加训练作业的片上内存总量。
  增加副本对应增加的片上内存大小计算公式：增加片上内存总量（GB） = 模型参数量N（B） * 12 * 副本数，其中，模型参数量的单位为B（十亿），通过以上公式，计算出需要增加的片上内存，扩容后，再使用MindIO TFT。
训练容错框架中有一个Active Controller与两个Backup Controller，为了包括Active Controller在内多张卡发生故障时，能够顺利切换到Backup Controller完成临终保存，需要状态正常的卡的数量大于world_size的一半。
MindIO TFT会对优化器状态数据做副本，MindIO UCE或MindIO ARF修复时，寻找有效副本修复故障卡，当训练集群故障较多，通过副本仍然无法拼凑出一个完整副本时，则从Step在线修复退化为在线加载周期CKPT修复。
MindIO TFT在生成临终CheckPoint数据时，除了考虑一个完整的数据副本，还要校验数据是否一致。如果发生故障后，存在一个OS（Optimizer State）数据Shard长期处于修改状态，或者OS数据不同Shard间训练迭代不一致，都认为是全局数据不一致，无法生成临终CheckPoint数据。
MindIO TTP不使用MindIO ACP（Async Checkpoint Persistence）的异步CheckPoint保存功能。MindIO TTP完成临终CheckPoint保存后会结束训练进程。为确保在进程退出前，临终CheckPoint已经保存到持久化存储，约束MindIO TTP写数据不使用ACP异步CheckPoint保存方式，而是直接写入到持久化存储。
MindIO TFT目前不支持级联故障场景。例如：当MindIO TTP正在保存时，如果出现其他故障，就会保存失败。
MindIO TFT会增加显存占用，详情请参见表1 原生优化器与开启故障快速恢复特性后优化器参数的理论数值变化。
默认开启TLS（Transport Layer Security）安全特性，关闭可能导致伪造Controller连接影响训练进程。
MindIO ARF需要多个节点（≥2），不支持Controller节点发生故障，不支持级联故障；MindIO ARF修复失败后，由MindCluster控制后续流程。
日志保存路径默认在运行脚本同级目录下“logs/ttp_log.log”文件，可在运行脚本里自行配置，默认日志级别为“INFO”，单日志文件大小限制为10MB，写方式为单个追加写，单日志文件达到大小上限后会新建滚动日志文件，滚动日志文件数量限制为5个，多个文件循环写覆盖旧文件。

约束限制