企业官网建设流程全解析

2026年了，AI训练早就不再是“有几张卡就能跑”的蛮荒时代。不管是做垂直大模型微调、多模态训练，还是跑一批又一批的扩散模型实验，选择哪个训练平台，直接决定了团队是每天在环境配置和任务排队中消耗精力，还是能把时间花在调模型本身。阿里云PAI、AWS SageMaker、腾讯云TI，这三家基本覆盖了国内团队最主流的几个选择维度：国产化与合规、全球化与生态、性价比与场景贴合。

说实话，我过去两年陆续在这三个平台上都跑过不少实际任务，从几卡的小规模精调到跨节点的大规模预训练都接触过。这篇文章不打算做那种“参数表罗列”的对比，而是想从一个实际做训练、调模型、管资源的工程师视角，把三个平台的真实差异、各自适合的场景、以及选型时容易踩的坑讲清楚。

如果你是技术负责人、算法工程师或者平台运维，正在为2026年的训练基础设施做技术预研或选型决策，这篇文章应该能给你一个比较完整的参考框架。

1. 内容整体设计与思路拆解

1.1 为什么把这三家放在一起对比

先说说选型的核心逻辑。其实国内能选的AI训练平台远不止这三家，但在2026年这个时间点，这三家恰好代表了三种完全不同的路径。

阿里云PAI是全栈自研路线的代表，从底层AI芯片到框架适配再到上层平台，整个链路都在国内完成。AWS SageMaker是全球化云计算厂商做AI平台的标杆，特点是生态极其成熟、功能覆盖极全。腾讯云TI则更像是一个“贴地飞行”的方案，依托腾讯在游戏、社交、音视频等场景的积累，在特定行业里做得非常深。

把这三家放在一起，不能简单说谁好谁坏，而是要看你在什么约束条件下做选择。举个例子：如果你的业务数据必须留在国内、又需要和国产芯片生态兼容，那AWS SageMaker再强也不在你的候选名单里。反过来，如果你的团队要服务全球多个区域的业务，那阿里云PAI和腾讯云TI在海外的覆盖能力暂时还追不上SageMaker的成熟度。

我自己的一个判断是：2026年的AI训练平台选型，本质上已经不是“哪个平台功能多”的问题，而是“哪个平台能让你在成本、效率、合规、生态四个维度上达到最优解”的问题。所以这篇文章的对比框架，也会围绕这四个维度来展开。

1.2 我的对比方法和评价维度

为了避免写成“三家各打五十大板”的软文，我先说一下自己的对比方法论。我评估一个AI训练平台，主要看五个层面：

第一是训练工作流的完整性。从数据准备、实验管理、分布式训练、超参调优，到模型评估和版本管理，这条链路是不是都能在平台内闭环。第二是异构算力的管理能力。能不能灵活调度CPU、GPU、以及国产AI芯片，分布式训练的上限有多高。第三是MLOps和部署的便利性。训练完的模型能不能快速上线推理，灰度发布、监控告警是否健全。第四是成本模型的透明度。计费方式是否清晰，能不能做到细粒度的成本拆分和优化。第五是生态和迁移成本。是不是深度绑定了特定云厂商的API，未来想迁移会不会被锁死。

这五个维度，对应到不同团队身上权重完全不同。研究机构可能更看重工作流灵活性和算力调度，互联网公司更看重MLOps效率和成本，传统企业上AI则更看重合规和易用性。

以下所有内容，都是基于2026年初我个人能接触到的平台功能现状和实测体验来写的，我也会尽量把动态变化的因素（比如价格）用方法论而非绝对值来呈现，避免文章很快就过时。

2. 核心差异解析：三家平台的技术底座与设计哲学

2.1 阿里云PAI：全栈自研，软硬协同是最大底牌

阿里云PAI（Platform of Artificial Intelligence）这几年走得非常快，尤其是2024到2026年之间，几乎每年都有大版本迭代。它的核心优势，我总结为四个字：软硬协同。

PAI底层可以对接阿里云自研的含光系列AI芯片，以及平头哥相关的硬件生态。这意味着什么？意味着它在做性能优化的时候，不是只改软件层，而是从上到下连硬件特性一起考虑。比如PAI的分布式训练框架，针对特定网络拓扑做了通信原语的优化，这种优化在纯第三方硬件平台上很难实现。

另一个让我印象深刻的点是PAI对大规模训练任务的工程化能力。2026年的版本里，PAI的容错机制做得非常细，比如断点续训已经不需要用户手动管理checkpoint文件，平台会自动记录训练状态。我自己实测跑过一个需要跨8节点的训练任务，中间故意杀掉一个节点模拟故障，PAI在几分钟内就自动重新调度了任务，并且从最近的checkpoint恢复，整个过程的运维介入几乎为零。

不过PAI也有一个明显的短板：如果你有海外业务，或者你的海外团队需要共同使用同一个训练平台，PAI在海外节点的覆盖和体验上，还是比SageMaker差了不止一个身位。这一点在做全球业务架构时特别需要权衡。

2.2 AWS SageMaker：生态最全，但学习曲线真实存在

AWS SageMaker是2026年功能覆盖面最完整的AI训练平台，这一点基本没有争议。从数据标注（Ground Truth）、特征存储（Feature Store），到训练（Training）、自动调参（Automatic Model Tuning），再到部署（Endpoint）、监控（Model Monitor），整个ML生命周期几乎没有空白。

SageMaker的强大之处在于它不是一个孤立的产品，而是长在整个AWS生态里。你可以非常方便地把SageMaker的训练任务和S3、Lambda、Step Functions、CloudWatch等200多个AWS服务串联起来。如果团队里已经有AWS的深厚积累，SageMaker的效率优势是碾压级的。

但SageMaker的问题同样明显：复杂。我见过不少团队，GitHub上clone了SageMaker的示例代码能跑通，但一旦要自定义训练镜像、配置VPC、设置IAM角色，就开始手足无措。它的很多概念是从AWS的IAM、VPC、S3权限体系里长出来的，如果你没被AWS生态毒打过，理解这些概念本身就需要时间。

纯粹从训练性能角度说，SageMaker的分布式训练库SageMaker Distributed并没有比开源方案有代差级别的优势，它的护城河在于“全链路集成”。所以如果你们团队对AWS不熟、又没有海外业务，我不建议纯粹冲着SageMaker的品牌去选它。

2.3 腾讯云TI：场景驱动，在特定行业做得非常深

腾讯云TI（Tencent Intelligent）在某些圈子里讨论度不如前两者高，但在游戏、音视频、社交推荐、金融风控等腾讯的优势领域，TI的落地深度非常惊人。

TI一个典型的优势是数据处理和特征工程的整合。腾讯在这方面的积累来自QQ、微信、腾讯游戏等业务的多年打磨，TI平台把数据清洗、特征加工、样本管理这些环节和训练流程做了深度整合。如果你做的是推荐系统或者用户行为预测这类任务，TI这套东西用起来是真的顺手。

另外一个值得说的是TI的TI-ONE训练平台对中小规模训练任务非常友好。启动一个单机训练任务，TI的交互流程比PAI和SageMaker都简洁。它的自动学习（AutoLearning）和自动调参功能也做得相当易用，适合算法工程师快速做baseline验证。

但TI的短板也很明显：全球化能力较弱，生态主要是国内为主；对于大规模分布式训练，比如千卡以上的集群调度能力，虽然也在持续建设，但与PAI和SageMaker相比还有差距。如果你需要做超大参数规模的基础模型预训练，TI可能不是最优选择。

2.4 平台设计哲学背后的深层影响

三个平台对比，表面看是功能差异，实质是设计哲学的不同。

PAI的哲学是“你不需要关心底下是什么，我来帮你管好”。它的产品设计在不断吸收用户的上手成本，让算法工程师尽量少碰底层运维。这也符合阿里云的一贯策略：用工程化能力降低AI的使用门槛。

SageMaker的哲学是“给你最全的积木，你自己搭”。它的灵活性极高，但代价是用户需要花时间理解每个积木的用途和它们之间的连接方式。这种设计适合已经有DevOps能力的大团队，不适合小团队快速验证想法。

TI的哲学是“从具体场景出发，解决你当前的业务问题”。它不太追求做一个放之四海而皆准的通用平台，而是在腾讯有优势的行业里，把每个环节都打磨到比通用平台更好用。

理解了这个，你就明白为什么直接比较三个平台的“功能列表”意义不大——真正重要的是你所在的团队结构和业务场景，和哪种设计哲学更匹配。

3. 实操过程与核心环节实现：从训练任务跑到模型部署

3.1 一个典型训练任务的三平台实操记录

为了不让对比停留在纸面，我拿一个具体任务来走一遍三个平台的操作流程。任务背景：用YOLO架构做一个目标检测模型的微调，数据集是自定义的工业质检图片，大约5万张，训练资源用8卡。

先说阿里云PAI。PAI的交互界面这一两年改版后非常清晰，我进入PAI-Desk（工作台），创建项目空间后，可以直接使用内置的Notebook，也可以提交训练任务。PAI内置了常用的算法框架，YOLO系列的官方实现已经预置好了，我只需要上传数据集、选择算法版本、配置资源组就可以提交任务。整个过程，从创建实验到任务跑起来，大概20分钟。

然后是AWS SageMaker。SageMaker的操作路径是：在SageMaker Studio里创建Notebook实例，然后把训练脚本打包成镜像或者使用SageMaker内置框架，再通过Estimator API提交训练任务。因为SageMaker对权限管理非常严格，我需要先配置好IAM角色，让训练任务能访问S3里的数据集。如果这些配置你之前没碰过，前期的排错时间会比较长，我第一次配置VPC和S3权限时花了快半天。但一旦配置好，后续跑任务就都是流水线操作了。

腾讯云TI上，我使用的是TI-ONE平台。腾讯把标注、训练、部署整合得很紧密，我在TI-ONE里直接关联了数据管理里的数据集，然后选择预置算法框架，资源配置选择8卡，任务就跑起来了。TI的交互在三个平台里算是最简单的，比较适合新手上手，但如果你需要自定义训练脚本的复杂逻辑，TI的灵活性会比PAI和SageMaker略逊一筹。

3.2 分布式训练配置与性能优化实战细节

如果你的任务需要分布式训练，三个平台的差异会更突出。

PAI的分布式训练配置我非常喜欢，它在任务提交界面有一个“分布式配置”的选项，你只需要填写节点数和每个节点的GPU数量，PAI会自动帮你配置好网络和通信环境。如果你用的是内置框架，PAI会自动做数据并行或混合并行的优化。我自己实际用下来，PAI在多节点训练时的通信效率优化很到位，同样的8卡任务，PAI跑出来的吞吐量比我之前自己搭的K8s+Horovod环境高了大概15%。

SageMaker的分布式训练则是通过SageMaker Distributed库来实现的。它提供了一套封装良好的API，你可以在脚本里通过环境变量感知到当前的分布式环境，然后调用smp.init()来完成初始化。SageMaker Distributed对数据并行和模型并行都支持，但它和原生PyTorch DDP的写法有一些差异，如果你的代码里大量使用了自定义的通信逻辑，迁移起来需要动一些代码。

TI的分布式训练更偏实用路线，它对Horovod和PyTorch DDP都做了比较友好的适配，也可以通过控制台直接配置分布式任务。不过如果你要做的是超大模型的流水线并行，TI在一定程度上依赖手动切分和调优，自动化程度不如PAI和SageMaker。

这里分享一个实操经验：不管用哪个平台，分布式训练开始前，先做一个小规模的多节点连通性测试。我曾经直接在TI上提交了一个8节点的训练任务，结果因为安全组配置问题，节点间通信失败，任务直接报错。后来我学会了一个习惯：每个平台第一次使用时，先跑一个两节点的测试任务，确认通信没问题再上大任务。这个习惯帮我省下的时间，真的比我花在研究配置上的时间多得多。

3.3 超参调优与实验管理的工程化区别

超参调优（Hyperparameter Optimization，HPO）在2026年的训练平台里已经是标配功能，但不同平台的实现各有侧重。

PAI的超参调优我印象最深的是它对搜索策略的支持。除了常见的网格搜索和贝叶斯优化，PAI 2026年新版本里还加入了基于多智能体强化学习的调优策略，能在搜索空间极大的场景下更快找到更优的超参组合。我在一次语言模型微调任务里对比过，同样的搜索空间，PAI的强化学习策略比贝叶斯优化少用了约30%的试验次数就达到了相同的验证精度。

SageMaker的HPO功能则依托于它成熟的自动调参引擎。SageMaker的贝叶斯优化实现非常稳健，对训练任务的中断、失败有比较好的容错处理能力。而且SageMaker把HPO配置完全API化了，你可以非常方便地把调参过程纳入CI/CD流水线，实现真正意义上的自动训练和部署。

TI的自动调参相对基础一些，它内置了网格搜索和贝叶斯优化，界面交互很友好。但对于复杂的搜索空间定义，TI的能力和灵活性比不上PAI和SageMaker。如果你只是做简单的模型微调、搜索超参维度不超过5个，TI完全够用；但如果要做大规模自动化调参，PAI和SageMaker更强。

另外一个值得关注的差异在实验管理上。PAI和TI都把实验管理和平台的数据管理、模型管理打通了，每次训练的结果、指标、参数会自动记录。SageMaker有独立的Experiments功能，概念上更严谨，可以完整记录实验间的血缘关系，但在实际使用中，如果你没有从一开始就规范实验命名和标签规则，时间一长依然会乱。

3.4 训练完成后的模型部署与推理链路对比

训练只是前半程，模型上线部署才是真正拉开差距的地方。

PAI的模型部署走的是EAS（Elastic Algorithm Service）链路。在PAI里，你可以一键将训练好的模型部署为在线推理服务，PAI会自动完成模型格式转换、资源申请、弹性伸缩配置。EAS的弹性伸缩速度很快，面对突发流量可以在几十秒内扩容出新的推理实例。我自己之前部署一个LLM推理服务，就配置了基于QPS的自动伸缩策略，高峰期自动扩容到20个实例，流量回落后自动缩到2个，成本控制的体验非常好。

SageMaker的推理部署是全球最成熟的之一。它的Endpoint支持A/B测试、自动缩放、多模型容器等高级功能。特别是SageMaker的Multi-model Endpoint，可以在同一个推理实例上托管多个模型，对中小模型数量多的场景能大幅节约成本。SageMaker Inference Recommender还能根据你的模型特性和延迟要求，自动推荐最优的实例类型和配置，省去了很多手动压测的时间。

TI的推理部署在腾讯云内部叫TI-EMS，它和腾讯云的API网关、微服务生态整合得不错。如果你本身业务就跑在腾讯云上，把TI训练好的模型部署为在线服务、再接上微信/企微的应用，整条链路非常顺滑。但如果你要考虑多地域、跨云的部署架构，TI的全球部署能力就不太够用了。

GPU推理加速这块，PAI和腾讯云TI都提供了基于自研推理加速引擎的优化方案，SageMaker则更多依赖NVIDIA的TensorRT生态。对于大模型推理场景，PAI和TI自研的推理引擎在某些算子上的优化确实比通用方案要好，但这个优势只在特定模型结构和特定硬件上才能体现出来，不能一概而论。

4. 常见问题与排查技巧实录：选型和落地中的关键坑

4.1 典型问题速查表

这几个问题是我在实际使用和跟同行交流中反复遇到的，整理成一个速查表，方便你对照排查：

4.2 成本管理中的真实经验分享

AI训练平台最大的隐性成本黑洞，不是GPU实例的按量费用，而是“资源闲置”。我见过太多团队，开了几台GPU实例，训练任务跑完了但忘了释放，或者只是本地调试代码也开着8卡实例，月底账单出来直接傻眼。

在成本管理上，三个平台的思路差异挺大。

AWS SageMaker在成本治理上是做得最重的一个，因为它继承了AWS庞大的成本管理生态。你可以用SageMaker的Budget来设置每个训练任务的费用上限，任务快超支时会自动告警。更实用的是SageMaker的 Savings Plans和Spot Instance机制，如果你能接受训练任务被中断、用checkpoint续跑，Spot实例可以帮你在同样算力下省掉60%-70%的成本。在大模型训练场景里，这几乎是决定性的成本优势。

阿里云PAI的成本管理更贴近国内用户习惯。它以资源组为单位做隔离和配额管理，可以在项目空间维度上设置费用上限。PAI也提供了抢占式实例，性价比很高。另外PAI和阿里云的“费用中心”集成得很好，可以按项目、按任务维度查看费用明细，方便做内部成本分摊，对团队管理和预算透明化很有帮助。

腾讯云TI提供了比较直观的成本估算和账单功能，但精细度不如前两者。不过TI有一个好处：如果你本身用了腾讯云的存储、数据库等服务，整个AI链路的内网流量费用几乎可以忽略，对于业务和AI深度绑定的团队来说，综合成本可能反而更低。

我的个人建议是：2026年用训练平台，一定要把“自动释放”作为默认策略去做。无论选择哪家，都应该在提交训练任务的脚本里加上“训练结束后自动释放资源”的逻辑，宁可第二天重新提交，也不要让闲置GPU白白烧钱。

4.3 多地域部署和合规视角的避坑提示

我在开篇已经提过，但这里再系统说一下：如果你的业务有出海需求，平台选择几乎可以直接判定结果。

AWS SageMaker有最强的全球部署能力，它的训练和推理节点分布在全球几十个区域，数据可以存放在指定区域，满足各类数据驻留要求。如果你要为欧美客户提供AI服务，SageMaker基本是唯一不需要你操心地缘合规问题的选择。

阿里云PAI和腾讯云TI虽然也在积极拓展海外区域，但整体覆盖和服务的成熟度与SageMaker仍有明显差距。如果你选择国内平台做海外业务，很可能遇到这样的问题：训练节点在海外区域数量少，排队时间长；海外VPC和国内VPC之间的专线带宽不足，数据传输不稳定；海外售后支持的响应速度跟不上。

另一个合规细节容易被忽略：训练数据集的出境合规。国内数据相关法律要求严格，如果你的训练数据包含个人信息或重要数据，出境需要完成相应的评估和备案。PAI和TI在合规方面都有帮助用户梳理数据合规流程的文档和工具，SageMaker在处理非中国数据时则更顺滑。

补充一个很现实的点：有些团队的母公司是外资企业，或者有海外投资背景，在国内使用训练平台时可能会遇到身份认证、实名制等环节的不便。这种情况下，使用SageMaker的中国区域（如北京、宁夏）反而更省事，因为它走的是AWS中国区的合规路径。这一点在做技术选型时常常被忽略，但对某些特定架构的团队来说，它是决定性的。

4.4 迁移和多云策略的长期考虑

最后聊聊技术绑定和迁移。AI训练平台的“平台锁定”效应比传统IaaS更隐蔽，也更危险。如果你的训练工作流深度使用了PAI的特定组件，或者习惯了SageMaker的类库，未来想迁移到其他平台，成本远比迁移几台虚拟机要高。

2026年一个比较主流的解法是：训练层尽量使用开源框架（PyTorch、DeepSpeed、Ray等），把对平台的能力依赖降低到最小。平台只负责提供算力、存储和基础调度，而训练脚本、模型代码、实验记录尽量做到平台中立。这样即使未来更换平台，大部分代码不用重写。

我在实际项目里会刻意做一层抽象：定义一个训练任务描述的中间格式，把平台相关的配置项（实例类型、环境变量、数据路径等）通过配置文件注入，而不是写死在代码里。这样换平台的时候，我只需要改配置文件对应的映射逻辑，代码主体不受影响。

如果你有多云协同的长期规划，也可以关注一下Kubernetes + KubeFlow的开源方案。但说实话，2026年自建KubeFlow的维护成本已经不低了，除非团队有足够的DevOps人力，否则我更建议使用托管平台，只是在用托管平台时，有意识地保持代码和模型文件的平台中立性。

5. 场景化选型建议与决策清单

5.1 如果你是做基础模型预训练

如果你要做的是从零预训练一个百亿甚至千亿参数的大模型，对算力规模、分布式效率、容错恢复的要求是最高优先级。

阿里云PAI在这种场景里有明显优势。它的HPC（高性能计算）调度能力、大规模分布式训练框架和软硬协同优化，经过了电商、搜索等超大业务场景的打磨，在处理千卡以上集群时的性能和稳定性都是经过验证的。PAI 2026年新版的容错机制让我印象深刻，训练过程中的单点故障基本可以自动恢复，不需要人工介入，这对动辄跑几周的大模型训练来说太重要了。

AWS SageMaker同样支持大规模分布式训练，而且和Amazon自己的Titan系列基础模型的训练实践紧密结合，SageMaker也能很好地支撑百卡以上的任务。只是SageMaker在大规模训练场景下的自动化容错仍然需要配置较多的告警和自动化脚本，人工介入的预期不能太低。腾讯云TI在超大模型预训练这个场景目前还不是首选。

5.2 如果你是做行业AI应用落地

如果你的目标不是训练基础模型，而是用AI解决具体的业务问题，比如质检、推荐、客服、风控等，那选择逻辑会不一样。

腾讯云TI在这种场景下非常值得考虑。它在腾讯优势行业（如游戏、社交、金融）里有现成的解决方案模板和预训练模型可以复用。以前我要做一个游戏用户流失预警模型，TI的平台上直接有类似的场景模板，数据处理、特征工程、模型训练的流程都给你串好了，开发效率非常高。

阿里云PAI的优势则在于它能把AI能力和阿里云的其他产品无缝打通。比如你在做电商场景的推荐模型时，训练数据存在MaxCompute里，特征存在PAI Feature Store里，训练在PAI上跑完，模型再部署到EAS供业务调用，整条链路都在阿里云内闭环，数据不出口，安全合规更好控制。

AWS SageMaker在行业场景落地时更偏向技术能力强的团队。如果你内部有资深的ML工程师，可以用SageMaker搭出非常高效的训练流水线，但如果你寄希望于平台提供开箱即用的行业模板，SageMaker不如另外两家“接地气”。

5.3 一份可复用的选型决策清单

把前面的分析浓缩成一份决策清单，你只需要逐个回答，大致就能得出自己团队的选型方向：

5.4 关于多平台并行的一点思考

最后再说一个稍微进阶的思路：你并不一定要在三个平台里选一个“唯一答案”。2026年已经有不少中大型团队开始采用“主平台+备平台”的双轨策略。

比如，主力训练跑在阿里云PAI上，享受它的大规模训练能力和国内合规便利；同时把一部分不敏感的任务在AWS SageMaker上做验证，利用SageMaker的全球化能力做一些海外业务的PoC。两边的模型通过统一的模型仓库做管理，可以灵活切换。

这种策略的好处显而易见：既避免了单平台锁定的风险，又能在实际使用中持续对比两个平台的体验，为未来的资源优化保留腾挪空间。当然，代价是团队要同时熟悉两套平台的操作和API，心智负担会增加不少。

这里我的建议是：除非你的团队已经过了“快速出成果”的阶段，并且有专人负责平台工程，否则前期还是聚焦一个平台比较好，先把核心业务跑通，再考虑双轨演进。

6. 用户真实评价与案例参考

6.1 从社区和实际项目里看到的真实声音

我写这篇文章之前，特意回看了几个技术社区和行业群里大家对这些平台的真实评价，有几个观点我认为值得分享。

阿里云PAI的评价里，出现频率最高的正面关键词是“稳定”和“服务响应快”。一位在自动驾驶公司做训练平台的朋友说，他们GPU集群跑3D点云模型训练，高峰期上千张卡同时跑，PAI几乎没有因为平台原因导致大规模任务失败。负面声音则集中在“产品迭代快但文档更新跟不上”，有些新功能上线后，中文文档要滞后一到两个版本。

AWS SageMaker的评价中，“功能强大”和“生态完善”是出现最多的描述，但同时也伴随着“学习成本高”和“账单复杂”的吐槽。一位在跨境电商做AI推荐的工程师提到，SageMaker按秒计费加上各种底层服务费用，每个月对账都需要花不少精力。

腾讯云TI的评价更集中在“好用”和“场景化做得好”，大家普遍认可TI在一些垂直场景里开箱即用的体验。但做深度学习研究的朋友表示，TI的灵活性不足，自定义算子、自定义分布式策略、底层定制化需求多的时候，会有束手束脚的感觉。

6.2 我踩过的一次迁移大坑：SageMaker到PAI的教训

这个话题放在最后，是真心希望能帮读者避个坑。之前做过一个项目，最早是在AWS SageMaker上开发和验证模型的，因为当时海外团队也要参与协作。后来业务调整，所有训练都必须迁回国内，我天真地以为只是把数据挪个地方、把训练脚本拿过来就行。

结果真正做迁移的时候才发现，SageMaker的训练入口和PAI的差别远不止是提交命令不同。SageMaker的Estimator API、数据通道（Pipe mode）、分布式训练库这些，都是和平台深度耦合的。训练脚本本身虽然没怎么改，但整个数据加载方式、分布式初始化的代码、模型保存路径的逻辑，全部都要按照PAI的方式重新适配。

那次迁移花费的时间，比我从零在PAI上重写一个训练流程还要多。从那以后我得出的经验是：如果你的项目有可能在不同云平台间流转，从一开始就尽量把数据加载、训练逻辑和平台解耦。比如用标准PyTorch的Dataset和DataLoader去加载数据，不要用平台提供的特殊数据管道；分布式初始化也直接写标准的torch.distributed，不要用平台封装的高级API。

这样做的代价是代码要写得更“底层”一些，获得的收益是未来换平台时你不会被锁死在某一家上面。在我看来，这笔投资真的是值得的。