從 ECS 到 DSW、DLC：阿里雲生成式 AI 模型雲端訓練實踐

简介： 本文介绍基于阿里云 ECS、PAI-DSW 和 PAI-DLC 的云端AI开发与训练流程。通过 ECS 承担辅助任务、DSW 完成模型调试、DLC 执行多卡训练，并结合 CPFS 实现数据与实验结果管理。针对批量推理中的存储异常，优化文件校验与任务恢复机制，最终完成425项验证任务，提升训练稳定性与资源利用率，实现降本增效。

项目背景：从模型开发到云端训练的实际需求

随着生成式人工智能技术的发展，深度学习模型对计算资源和工程环境的要求不断提高。尤其是在视频生成等计算密集型任务中，模型训练不仅涉及 GPU 计算，还需要完成数据准备、开发环境配置、实验调试、训练任务管理以及结果验证等一系列工作。而在这一系列工作中，如何让不同环节稳定衔接，并合理利用云端计算资源，往往是实际研发过程中更加需要关注的问题，从而能实现降本增效。

在此前参与的一项生成式 AI 视频相关项目中，我需要开展模型训练、阶段性效果验证以及多组实验对比。项目初期以代码调试和小规模实验为主，需要频繁修改运行配置并观察结果；随着实验逐渐推进，部分任务开始涉及较长时间的计算和多卡 GPU 协同训练。如果始终采用同一种运行方式，那么就很难同时兼顾交互式开发的灵活性与较大规模训练的资源管理需求。

针对这些问题，我在项目中使用了阿里云云服务器 ECS（Elastic Compute Service），并结合人工智能平台 PAI 提供的交互式建模服务 DSW（Data Science Workshop）和分布式训练服务 DLC（Deep Learning Containers），逐步探索了一套适合实际研发需求的云端训练工作流程。其中，ECS 参与项目的云端计算与基础工程环节，DSW 主要用于交互式开发和单卡或者双卡实验验证，DLC 则用于组织八卡等甚至更多、计算规模更大的训练任务。通过对不同环境进行合理分工，可以将日常开发、实验验证和规模化训练结合起来，减少重复配置和任务切换带来的额外工作。

ECS：云端计算资源与基础运行环境

在整个项目中，ECS 是云端研发环境的重要组成部分。对于深度学习项目而言，选择计算资源时需要考虑的并不只有 GPU 性能，还包括 CPU、内存、磁盘读写能力、网络环境以及运行成本等因素。不同实验阶段对资源的需求差异较大，例如数据处理和文件检查可能更加依赖 CPU、内存和存储性能，而模型训练则通常需要较强的 GPU 计算能力。因此，合理规划不同类型的计算资源，比单纯追求更高的硬件规格更加重要。

阿里云 ECS 提供了较为灵活的实例配置方式，可以根据实际任务选择计算资源、操作系统镜像和存储配置。对于直接管理的 ECS 实例，开发者能够自行维护软件环境、检查系统状态并运行相应的工程任务。这种灵活性为 AI 项目提供了更多选择，但也意味着需要主动关注基础环境的稳定性。

在本次项目中，我使用阿里云 ECS 运行 Python 和 Shell 脚本、检查运行环境、整理训练日志与模型检查点，以及批量处理模型生成的验证结果。由于实验过程中需要反复训练和验证，产生了大量日志、模型文件和视频结果，因此我将部分重复性操作进行脚本化处理，以减少人工操作，提高实验管理效率。在实际运行过程中，曾遇到批量视频导出时 FFmpeg 提示 No space left on device，导致部分结果无法正常保存的问题。经过排查，发现不能仅根据磁盘剩余容量判断存储是否可用，还需要考虑存储配额、inode 数量以及目录写入限制等因素。针对这一问题，我进一步完善了存储空间检查、文件写入检测和结果完整性校验机制，确保输出文件经过验证后再正式保存，后续批量任务也得以正常完成。通过这次实践，我认识到，云端 AI 研发不仅需要充足的 GPU 算力，还需要稳定的基础运行环境和可靠的工程管理机制。而其中 ECS 在辅助任务执行、日志管理和实验结果维护等方面发挥了重要作用，也为 DSW 中的交互式开发与 DLC 中的多卡训练提供了必要的工程支持。

对于 ECS 环境的管理，我认为比较重要的是明确计算任务与运行环境之间的关系。例如，实例规格需要与实际负载匹配，操作系统和软件依赖需要保持稳定，重要文件有可靠的保存方式。同时，还需要关注网络配置、存储访问以及实例生命周期，避免因为环境变化或资源释放而影响已有工作。

这一点对于需要持续迭代的 AI 研发任务尤其重要。相比一次性完成的计算作业，模型训练往往需要多轮调整和验证，因此基础环境不仅要能够支持当前任务，还应当便于后续维护和结果追溯。

DSW：利用交互式环境完成单卡训练验证

在完成基础计算环境的准备后，模型开发阶段主要使用 PAI-DSW 提供的交互式建模环境。DSW 集成了常见的深度学习开发工具，能够通过浏览器访问 Notebook、VS Code 和 Terminal 等工作界面。对于需要频繁修改代码和检查输出的任务而言，尤其是其中的 VS Code 开发方式比每次重新提交独立训练任务更加灵活。

在实际使用中，我首先关注的是训练环境的兼容性。深度学习项目通常依赖 Python、PyTorch、CUDA 以及多个第三方软件包，如果不同组件之间存在版本冲突，即使计算资源充足，训练程序也可能无法正常运行。因此，在正式开展模型实验之前，我会先检查基础环境是否能够正常识别 GPU，并通过 nvidia-smi 和 PyTorch 的相关接口确认计算设备状态，随后逐步验证数据读取和训练程序的运行情况。

我在实际使用过程中会更倾向于先进行小规模验证，通过少量数据和较短的运行流程，检查训练能否正常启动、GPU 利用率如何、日志是否持续更新，以及模型检查点能否正确保存。当这些基础环节通过验证后，再进一步开展更完整的大规模实验。

在这一阶段，DSW 调试效率有显著优势。当程序出现异常时，可以直接在现有环境中查看错误信息、检查文件并调整配置，不必反复创建完整的训练任务。这种方式对于开发初期的频繁迭代较为实用。

不过，在此前的训练过程中，我也遇到过训练数值表现正常、实际验证结果却未达到预期的情况。这让我意识到，训练程序能够正常运行与实验本身取得有效结果是两个不同的问题。除了观察训练日志，还需要进行阶段性效果验证，并结合实验记录分析问题。通过将代码调试、运行监控和结果检查结合起来，可以减少无效实验持续消耗计算资源的情况。

从 DSW 到 DLC：训练规模扩大后的工程调整

随着前期实验逐渐稳定，后续任务对计算资源和训练时间提出了更高要求。此时，继续将所有工作集中在交互式开发环境中，并不一定是最合适的选择。尤其是在涉及八卡甚至更多的 GPU 训练时，开发重点开始从代码调试转向任务执行、资源管理和运行稳定性。

因此，我将部分训练工作转移至 PAI-DLC，通过独立训练任务的方式组织后续实验。与 DSW 侧重交互式开发不同，DLC 更强调将运行环境、计算资源、启动命令及数据访问方式进行统一配置。开发者可以根据任务需求选择相应的计算资源，并通过任务管理界面查看运行状态和日志。

从 DSW 迁移到 DLC 的过程中，我发现一个需要特别关注的问题是环境一致性。某个训练程序能够在 DSW 中正常运行，并不意味着更换运行环境后就一定能够直接执行。不同环境之间可能存在依赖版本、文件路径或资源配置方面的差异，因此需要在任务提交前确认关键软件依赖、训练入口和数据访问方式是否正确。

阿里云 PAI 支持使用基于 ECS 等云产品的通用计算资源，并允许在创建训练任务时根据需要选择相应规格。从实际工程角度看，ECS 提供的云端计算能力与 PAI 的任务管理能力形成了不同层次的分工。前者关注计算资源和基础运行条件，后者负责将这些资源组织为适合模型开发或训练的运行环境。

因此，在训练规模扩大时，我将资源规格、运行环境、数据访问和任务管理放在一起考虑。这样可以使开发阶段和正式训练阶段的职责更加清晰，也能在遇到问题时更快地判断究竟应该检查基础资源、训练配置还是程序本身。

云端存储：连接不同训练环境的重要环节

在 DSW 与 DLC 之间切换时，除了运行环境之外，数据和模型文件的管理也是一个关键问题。

深度学习训练通常需要读取大量数据，并持续产生训练日志、模型检查点和验证结果。如果这些文件仅保存在某个临时运行环境中，就可能在实例停止或任务结束后面临访问不便的问题。同时，如果不同环境分别维护各自的数据副本，还可能出现文件版本不一致、重复传输以及结果混淆等情况。

在实际项目中，训练代码、实验日志和模型检查点等文件使用了 CPFS 相关存储目录进行管理。通过持久化存储保存重要文件，可以减少计算任务生命周期与实验资料生命周期之间的相互影响。阿里云 PAI 支持在 DSW 和 DLC 中挂载 CPFS 文件系统，使不同阶段能够通过统一的存储方式访问所需数据。

不过，在配置训练任务时，仍然需要确认文件系统、网络环境、挂载路径以及访问权限是否正确。特别是在不同实例或训练任务之间切换时，应当检查程序读取的实际文件路径，避免因为路径差异导致数据读取失败或输出结果保存到错误位置。

这一过程也让我认识到，云端研发中的存储并不仅仅是保存数据的工具，还承担着连接不同计算环境的重要作用。将计算资源与持久化存储进行适当分离，比反复复制整个项目目录更有利于长期实验的管理和维护。

DLC 多卡训练：从资源扩展到运行管理

进入 DLC 训练阶段后，实际需要关注的问题与单卡调试明显不同。

在单卡环境中，训练异常通常可以通过当前终端直接定位；但是在多卡训练时，任务可能涉及多个计算进程，运行状态也会受到资源分配、数据加载和进程通信等因素影响。即使训练程序本身没有明显错误，整体运行效率仍然可能受到其他工程环节的限制。

在此前的实验中，我使用八卡 GPU 资源开展训练任务。随着训练规模扩大，我逐渐意识到，多卡训练并不是简单地将 GPU 数量增加，就一定能够获得相应比例的速度提升。实际训练效率还取决于模型计算特点、数据处理速度、进程间通信以及任务执行方式。如果某个环节成为瓶颈，额外的计算资源就可能无法得到充分利用。

因此，在 DLC 中执行训练任务时，我会关注训练日志、GPU 资源使用情况和任务状态，并结合实际训练进度判断运行过程是否符合预期。对于耗时较长的实验，还需要及时检查模型检查点是否正常生成保存到指定目录中，确保后续能够进行结果验证或恢复训练。

训练和推理验证之间的资源冲突也是不可忽视的一点。对于需要较多显存的生成式 AI 任务，如果训练与推理同时使用同一组 GPU，就可能产生资源竞争，严重时甚至导致显存不足。因此，在安排实验任务时，需要明确不同任务的资源占用情况，合理规划训练与验证的执行顺序。对于资源较为有限的环境，优先保证当前训练任务稳定完成，再释放 GPU 资源开展后续验证会更加稳妥。

通过这些实践，我逐渐认识到，规模化训练不仅需要计算资源，还需要合理的任务组织方式。对计算资源、运行环境和实验任务进行统一管理，能够帮助开发者减少一些重复性的工程操作，也使训练过程更加容易追踪。

实验管理与结果验证：减少重复计算和资源浪费

随着实验次数增加，区分不同实验及其结果也是一个重要问题。在模型训练过程中，不同实验可能使用不同的配置和运行环境，如果没有统一的记录方式，后续很容易出现日志与模型文件无法对应、不同版本结果混淆等问题。因此，我比较重视实验记录的完整性，尽量保留训练任务的基本信息、运行状态、相关日志以及最终输出文件之间的对应关系。

对于运行时间较长的任务，模型 checkpoints 的保存同样十分重要。一旦训练过程出现中断，及时保存的检查点可以为恢复训练提供基础，减少重新执行已有计算的成本。但检查点并非保存得越频繁越好，过多的文件写入也可能增加存储开销。因此，需要在恢复能力和运行效率之间进行合理权衡。

训练结束后，还需要将日志与实际验证结果结合起来分析。特别是对于生成式 AI 任务，单纯观察训练损失或任务状态并不足以完整判断模型效果。通过对不同阶段的输出进行检查，可以进一步识别模型效果方面的问题，并据此决定是否需要安排后续实验。

从完整流程来看，ECS、DSW 与 DLC 分别提供了不同层面的工程能力，而持久化存储和实验记录则帮助这些环节形成连续的工作流程。相比每次实验都重新准备环境、复制文件和整理结果，这种方式更有利于在长期研发过程中保持工作的连续性。

实践效果与资源使用反思

回顾此次云端研发实践，ECS、DSW 和 DLC 的结合，最直接的价值在于使不同类型的工作能够采用更适合的运行方式。

在基础工程环节，ECS 提供了可管理的云服务器资源，使开发者能够根据需求关注计算规格、操作系统、网络和存储等基础条件；在模型开发阶段，DSW 的交互式环境方便了代码调试和单卡实验验证；当任务逐渐转向较长时间或多卡训练时，DLC 则提供了更适合独立任务运行和资源管理的环境。

相比将整个研发过程集中在单一环境中，这种分工有助于减少开发调试与正式训练之间的相互干扰，也方便根据任务特点安排计算资源。

当然，我认为不能仅仅因为使用了更多 GPU 或更多云产品，就认为研发效率一定得到了提升。真正值得关注的是，开发环境是否稳定、训练任务是否能够持续执行、异常问题是否能够及时定位，以及实验结果是否具有可追溯性。

在成本方面，也需要结合实际资源使用情况进行判断。云端计算资源具有灵活配置的优势，但如果实验配置尚未验证就启动长时间训练，或者在任务结束后仍然保留不必要的实例，就可能造成额外开销。因此，我更倾向于先通过小规模实验验证运行流程，再根据需要扩大计算规模，并在任务结束后及时检查文件保存情况和资源状态。

在此前的一次云端批量推理与结果验证任务中，我需要对25个阶段性模型版本分别执行17组测试，共计425项验证任务。初次运行时，由于视频文件写入过程中出现存储空间异常，任务阶段性记录仅完成96项，完成率约为22.6%。针对这一问题，我结合运行日志检查了存储空间、文件系统配额及输出目录状态，并进一步完善了文件写入检测、临时文件管理和结果完整性校验机制，避免异常中断导致不完整文件被误认为有效结果。经过调整和后续补跑，最终结果索引成功登记全部425项任务，覆盖率达到100%。其中，一次补跑任务的日志记录运行耗时为23,730秒，约6小时35分钟，并以正常退出状态结束。这次实践让我认识到，云端训练流程的稳定性不仅取决于 GPU 计算能力，可靠的存储管理、异常检测与任务恢复机制同样十分重要。

总结：云端 AI 研发需要完整的工程流程

此次生成式 AI 模型训练实践，让我对云端计算资源与 AI 开发平台之间的关系有了更深入的理解。

起初，我更加关注模型能否正常运行，以及训练结果是否达到预期。随着实验逐渐深入，我发现环境配置、资源管理、数据存储、任务调度和结果追踪同样会影响整个研发过程。如果这些基础环节缺乏合理规划，即使拥有较强的计算资源，也可能因为重复调试、任务冲突或者文件管理问题而浪费大量时间。

在这次实践中，阿里云 ECS、PAI-DSW 与 PAI-DLC 分别承担了云端研发中的不同角色。ECS 提供基础计算资源及相关环境管理能力，DSW 为交互式开发和实验验证提供便利，DLC 则支持将经过验证的程序组织为独立训练任务，并根据需要使用更多计算资源。配合持久化存储与规范的实验管理方式，可以形成从基础环境准备、模型调试、规模化训练到结果验证的相对完整流程。

对我而言，从这次工程流程中获得的最大的收获是根据不同研发阶段的实际需求选择工具。对于需要频繁修改和验证的工作，灵活的开发环境更为重要；对于计算量较大、运行时间较长的任务，稳定的训练执行和资源管理能力则更加关键。

在实际 AI 项目中，计算资源的扩展应当建立在训练流程已经充分验证的基础之上。只有同时重视环境一致性、资源利用、异常恢复和结果可追溯性，才能让云端算力真正转化为有效的研发能力。