Amazon MLS-C01: 训练、分布式训练与超参数优化 — 学习指南

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

属于 AWS Machine Learning Specialty MLS-C01 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

训练任务、容器以及以最少代码改动过渡到云端训练

将训练工作负载迁移到 SageMaker 时，主要的设计目标是避免重写模型代码，同时确保容器运行时能暴露 SageMaker 所需的环境变量和通道路径。使用 SageMaker 脚本模式（Script Mode）及特定框架的 Estimator（PyTorch、TensorFlow、XGBoost），这样同一份训练脚本只需极少改动即可在本地和云端运行：从 SM_CHANNEL_TRAIN 读取数据，将模型写入 SM_MODEL_DIR，并遵循 SM_NUM_GPUS/SM_HOSTS/SM_CURRENT_HOST 的设置。对于自定义环境，可以构建一个扩展自官方 AWS Deep Learning Containers（或 SageMaker 训练工具包）的 Docker 镜像，并将其推送到 Amazon ECR；确保容器的入口点（entry point）遵循 SageMaker 的训练契约（training contract）。根据计算特性选择实例类型：CPU 密集型任务选用 ml.c5/m5 系列，GPU 训练选用 ml.p3、ml.p4d、g4dn 或 g5 实例；根据内存和 GPU 与 CPU 的配比来选择实例大小。常见的陷阱包括：硬编码本地文件路径、假设只有一个主机（这在分布式任务中会出错），以及未声明训练输入模式（Pipe vs File），后者会影响 I/O 性能。为了保证可复现性和成本可预测性，只有在添加了稳健的检查点（checkpointing）机制并将 max_wait 设置为大于 max_run 以允许 Spot 中断后，才应启用托管式 Spot 训练。

分布式训练模式、数据输入模式与存储选择

分布式深度学习需要在模型并行、数据并行和 I/O 架构之间取得平衡。对于单机多 GPU 和多机训练，可以使用框架的原生基元（primitives）——如 torch.distributed 或 TensorFlow 的 MultiWorkerMirroredStrategy——或利用 SageMaker 的 smdistributed 库：smdistributed.dataparallel 用于数据并行扩展，smdistributed.modelparallel 或 DeepSpeed 用于超大型 Transformer 模型。将 S3 作为大型数据集的规范存储，但要避免大量小文件的 S3 GET 请求：可以将文件合并为较少的归档文件，使用 RecordIO/TFRecord 分片文件，或挂载一个 POSIX 文件系统。对于大型数据集，选择 Pipe 模式以直接从 S3 流式传输训练数据，从而减少本地磁盘使用和启动时间；当训练需要随机访问或需要将完整数据集存放在 EBS 卷上时，使用 File 模式。若需跨多个实例实现高吞吐量和 POSIX 语义，可以挂载 Amazon FSx for Lustre 或 Amazon EFS；FSx 更适合高性能的并行读取。常见的失误包括：未能跨主机对数据进行分片（导致数据重复处理）、高估了单个实例的 S3 吞吐量，以及在增加并行度时忽略了批次大小（batch-size）和学习率的缩放规则。

Spot 训练、检查点设置与成本优化策略

如果您的训练设计能够容忍中断，托管式 Spot 训练可以显著降低成本。通过 SageMaker Estimator (use_spot_instances=True) 配置托管式 Spot，并结合检查点设置：提供一个持久化的 checkpoint_s3_uri 和本地的 checkpoint_dir，并足够频繁地保存检查点以限制返工时间。将 max_wait 设置得远大于 max_run，这样任务就可以在 Spot 时间窗口内重试被中断的实例。对于具体框架，应实现原子性的检查点写入和一个稳健的恢复逻辑，该逻辑会检查最新的 S3 检查点，恢复优化器和调度器的状态，然后继续训练。检查点频率应在写入开销和潜在的计算浪费之间取得平衡；对于耗时长的 epoch 或非常大的模型，可以使用梯度累积快照或基于步数的保存在 epoch 中途设置检查点。成本陷阱包括：忘记将检查点持久化到 S3（导致中断后完全重启）、依赖实例的临时存储，以及将 max_wait 设置为等于 max_run（这会阻止重试）。将 Spot 训练与混合精度（AMP）结合以节省更多计算资源，并与更小的检查点负载（仅保存权重和优化器）结合以降低 S3 写入成本和恢复延迟。

超参数优化、调优策略和实用决策标准

有效的 HPO（超参数优化）融合了搜索策略、资源分配和提前终止机制。SageMaker 的 HyperparameterTuner 支持随机搜索和贝叶斯搜索，并可配置 ContinuousParameter、IntegerParameter 和 CategoricalParameter 的范围；对于大型搜索空间，应先从随机搜索开始进行广泛探索，然后运行贝叶斯优化，在有前景的区域进行深度挖掘。使用 Hyperband 或 SageMaker 内置的提前终止等方法来节省预算，并利用热启动调优在相关实验中复用结果。仔细选择目标指标（例如，对于不平衡任务使用验证集 AUC，对于类别不平衡的欺诈检测使用 F1 分数，对于库存缺货场景使用自定义成本加权指标）。常见的陷阱包括：设置过宽的范围导致大量作业失败、对本质上连续的超参数使用分类编码，以及未能扩展资源感知型 HPO 的规模：应先用较小实例的短时间探测性作业找到粗略区域，再在全尺寸 GPU 实例上进行更长时间的运行。对于分布式训练，需要同时调优算法超参数（如学习率、批量大小）和系统级可调参数（如梯度累积步数、数据分片数量）。使用 SageMaker Debugger 进行检测，并利用 CloudWatch 指标来发现噪声测量；当存在高方差时，应增加每个配置的重复次数或使用基于中位数的选择方法。

实际问题：用例场景

场景： FinRetailer 在 SageMaker 中运行数千个按 SKU 划分的 30 天需求预测；他们在 S3 中存储了多年的每日 CSV 文件，并要求对长尾需求商品保持高准确性，同时在批量评分作业中保持可接受的推理延迟。

挑战： 预测数千个具有长历史数据且重要性不均衡（缺货成本高于库存过剩成本）的时间序列，在保持对罕见高需求事件的准确性的同时，最大限度地降低计算成本。

推荐方法：

使用 SageMaker 内置的 DeepAR 或封装在脚本模式 Estimator 中的自定义 PyTorch 时序模型（基于 Transformer）；将训练数据存储为分片的 RecordIO/TFRecord 文件，并结合使用文件模式与 FSx for Lustre，以实现高吞吐量的多实例训练。
从使用较小实例的分布式训练（smddp 或 Horovod）开始，以调整模型架构和超参数，同时使用带有贝叶斯搜索和提前终止功能的 HyperparameterTuner；将目标定义为一个加权分位数损失，该损失对预测不足施加更重的惩罚。
启用托管的 Spot 训练，并设置 checkpoint_s3_uri 和频繁的基于步骤的检查点；将 max_wait 设置为大于 max_run，以容忍中断并从最新的 S3 检查点恢复。
对于生产推理，使用多模型终端节点或在计算优化型实例上运行异步批量转换作业进行批量评分；应用后处理业务规则和考虑了缺货成本的校准阈值。

基本原理： 使用 DeepAR/Transformer 架构可以高效处理大量时间序列；分片的二进制格式和 FSx for Lustre 减少了分布式训练的 I/O 瓶颈；带有定制化目标的贝叶斯 HPO 将搜索重点放在运营成本指标上；而带检查点的 Spot 训练在不牺牲进度的情况下降低了成本。

← 时间序列与预测 · 所有领域 · 部署、推理与服务 (ML 实施与运维) →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →