Amazon MLA-C01: ML 工作负载的成本优化 — 学习指南

By Laurynas Brazys · 4 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

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

核心概念：成本来源与优化手段

机器学习工作负载的成本主要来自三个基本方面：用于训练和推理的计算，用于数据集和检查点的存储与数据传输，以及因基础设施利用率不足或配置不当产生的运营开销。当您训练大型模型或运行大量实验时，训练通常是最大的单项开支。当您大规模提供模型服务或需要为交互式应用提供低延迟时，推理成本则占主导地位。核心的优化手段包括：选择实例系列和大小，购买选项（按需 vs Spot vs Savings Plans），模型生命周期模式（批量 vs 实时 vs 无服务器），以及运行时优化，如模型编译、缓存和实例整合。

运营技术将这些手段付诸实践。使用带检查点的托管 Spot 训练，与按需实例相比，可将训练计算成本降低高达 70%，但需配合使用检查点（CreateTrainingJob 参数 CheckpointConfig → S3Uri），并将 CreateTrainingJob 标志 EnableManagedSpotTraining 设置为 true，以便任务在中断后能够恢复。通过分析实际的 CPU/GPU/IO 使用情况（例如 CloudWatch 指标中的 GPUUtilization、HostCPUUtilization 以及来自 SageMaker Debugger 的分析器跟踪数据）来合理调整实例规模，然后切换到与工作负载特征相匹配的计算实例系列（ml.c5/ml.c6 用于 CPU，ml.g5/ml.p4 用于 GPU，ml.r5 用于内存密集型）。对于推理，优先选择成本与使用量成正比的模式：对于流量波动大、吞吐量低的工作负载，使用无服务器推理（CreateEndpointConfig 的生产变体中设置 ServerlessConfig → MemorySizeInMB 和 MaxConcurrency）；对于许多小型模型，使用多模型端点或模型编译（SageMaker Neo）来缩减实例需求；并将大型或对延迟不敏感的工作负载转移到异步或批量转换（AsyncInferenceConfig 和 Batch Transform）。

关键服务与配置

Amazon SageMaker 提供了明确的成本控制选项。为了降低训练成本，请使用托管 Spot 训练：在 CreateTrainingJob API 中设置 EnableManagedSpotTraining=true，包含 CheckpointConfig.S3Uri，并设置 MaxWaitTimeInSeconds > MaxRuntimeInSeconds 以便有时间获取 Spot 容量。在 SageMaker Python SDK 中，您可以设置 estimator.use_spot_instances=True，并将 estimator.max_wait 和 estimator.checkpoint_s3_uri 设置为 S3 检查点位置。为了在连续的训练任务中实现可复现的低延迟，当实验节奏有此要求时，可以利用 SageMaker Processing 或在持久性预置基础设施上运行训练容器来保持容器“温暖”；否则，可以通过使用更小的容器镜像、预构建的 SageMaker 容器或在开发环境中重用一个持久的训练实例来减少容器启动时间。

对于推理成本控制，CreateEndpointConfig/UpdateEndpointConfig 支持多种策略。在 ProductionVariants 中使用 ServerlessConfig，让 SageMaker 管理扩展，并按调用次数和内存计费，而不是按整个实例小时数计费；ServerlessConfig 需要 MemorySizeInMB 和 MaxConcurrency 值。对于稳定、高吞吐量的工作负载，使用 Provisioned 实例，并对端点应用 Application Auto Scaling 目标跟踪策略，以避免过度预置。当您需要托管许多不常用的模型时，多模型端点通过共享单个容器并按需从 S3 加载模型构件来降低成本。如需模型规模调整建议，可在 Inference Recommender 中调用 CreateInferenceRecommendationsJob，它会提供实例类型、批量大小以及延迟/吞吐量方面的指导。

账单承诺最好通过 SageMaker Savings Plans 或 AWS Compute Savings Plans 来处理。通过 AWS Billing 控制台购买 Savings Plan，承诺在 1 年或 3 年的期限内每小时消费一定金额；这会为跨实例系列的按需 SageMaker 计算（训练和托管）提供折扣。请注意，Savings Plans 适用于按需使用量，不适用于 Spot 实例，因此应结合使用多种策略：为基准的稳定使用量购买 Savings Plans，并为突发性或实验性的训练使用 Spot 实例。

设计模式与权衡取舍

对于长时间或大规模的分布式训练任务，托管 Spot + 检查点模式是首选方案。它只需最少的代码更改：启用 EnableManagedSpotTraining，提供 CheckpointConfig.S3Uri，并设置一个合适的 MaxWaitTimeInSeconds 来容忍 Spot 调度。其权衡之处在于，如果 Spot 中断频繁，重启会更复杂，挂钟时间会稍长；但好处是成本会大幅降低。对于连续作业之间的启动延迟非常重要的迭代式实验，可以维护一个温热的开发环境：使用较小的、预置的 ml.m5 或 ml.c5 实例，并在 NVMe/本地缓存上预加载数据，或者使用 SageMaker Processing 或 Studio notebook 在同一实例上将多个实验作为本地处理作业运行。这会增加基线成本，但能减少总周期时间。

对于推理，应根据流量模式在无服务器端点和预置端点之间进行选择。无服务器推理 (ServerlessConfig) 无需进行容量规划，并且由于您按调用次数和内存分配付费，因此对于间歇性、不可预测的流量而言成本最低。其权衡之处在于冷启动延迟和大小限制；对于有严格低延迟 SLA 的场景，应首选带自动扩展功能的预置实例，并考虑使用 SageMaker Neo 进行模型优化以减少实例数量。在需要托管许多模型但每个模型的流量都很低的情况下，多模型端点可以整合磁盘和内存使用，降低每个模型的成本，其代价是未加载模型的冷启动加载时间会稍长一些。

合理调整规模应首先依赖观察，而不是猜测。使用 SageMaker Debugger 的性能分析功能和 CloudWatch 收集 GPUUtilization 和 DiskReadOps；然后运行一个 Inference Recommender 作业 (CreateInferenceRecommendationsJob) 来验证实例类别/类型和性能。如果模型延迟要求非常严格，可以考虑模型量化、使用 SageMaker Neo 进行编译，或使用 Elastic Inference 加速器将部分 GPU 推理能力附加到 CPU 实例上；Elastic Inference 允许您将一个小型加速器附加到 CPU 实例，与完整的 GPU 实例相比，这可以降低某些模型的成本。

常见陷阱与决策标准

一个常见的错误是把单一的成本优化策略应用于所有工作负载。Savings Plans 对于稳定的基线利用率非常强大，但应与用于实验性工作负载的 Spot 实例以及用于尖峰推理的无服务器模式相结合。不要认为 Spot 是免费的——它需要设置检查点和容错的训练逻辑；配置 CreateTrainingJob.CheckpointConfig 和 EnableManagedSpotTraining，并计算一个能反映您可接受的延迟启动时长的 MaxWaitTimeInSeconds。另一个陷阱是忽略遥测：如果不进行分析（使用 SageMaker Debugger、CloudWatch 和 Inference Recommender），您可能会面临过度配置或选择了 CPU、GPU 与内存特性不匹配的实例系列的风险。最后，无服务器推理简化了成本，但可能引入不可预测的冷启动；在使用 ServerlessConfig 时应测量端到端延迟，并在有严格 SLA 要求时回退到使用自动扩展的预置终端节点。

实践问题：用例场景

公司：FinSight Analytics。挑战：FinSight 必须构建一个欺诈检测管道，该管道能基于存储在 S3 中的交易日志和客户资料进行频繁训练，保持数据隔离，支持在生产部署前进行手动审批的模型版本治理，降低夜间重新训练的成本，在快速实验期间最小化每个作业的启动延迟，并提供一个对尖峰流量具有成本敏感性的低延迟实时终端节点。

集中化的安全数据和模型注册表。将数据存储在安全的 S3 存储桶中，使用默认加密和存储桶策略将访问权限限制为 SageMaker 执行角色。在 SageMaker Model Registry 中注册模型；使用 SageMaker Pipelines 的 RegisterModel 步骤创建模型包，并将 ModelApprovalStatus 默认设置为 “PendingManualApproval”。通过创建一个能发出模型包和手动审批步骤的 SageMaker Pipeline 来实现手动审批的人工工作流；当授权审核员完成验证后，他们调用 boto3 sagemaker.update_model_package(ModelPackageName=..., ModelApprovalStatus='Approved') 以允许部署。理由：Model Registry 提供集中化的版本控制，而 ModelApprovalStatus 直接与 SageMaker API 集成，从而最大限度地减少了自定义操作。
经济高效的夜间重新训练。通过创建设置了 EnableManagedSpotTraining=true 的训练作业来使用托管 Spot 训练，包含 CheckpointConfig.S3Uri 以持久化优化器状态，并适当设置 MaxRuntimeInSeconds 和 MaxWaitTimeInSeconds，以便作业能在 Spot 中断后恢复。将此方法与购买基准 Savings Plan（其规模应能覆盖平均的按需训练/推理小时数）相结合以降低稳定成本，并将 Spot 用于可容忍中断的实验。理由：托管 Spot 以最少的代码更改降低了计算成本；Savings Plans 应用于基线按需使用量，以降低可预测的开销。
减少实验的启动延迟。对于交互式实验周期，在 SageMaker Studio 中维护一个持久的开发实例（如 ml.c5 或 ml.m5），或一个在 EBS/NVMe 上预加载了数据集的小型专用笔记本实例，并重用该环境进行多次快速训练运行。对于生产环境的夜间作业，仍使用带检查点的托管 Spot 训练。理由：持久化环境避免了容器冷启动，提高了迭代速度，同时为重度运行保留了成本节约。
低延迟、成本敏感的实时服务。将已批准的模型部署到预置终端节点以获得基线低延迟，并为该终端节点附加一个 Application Auto Scaling 策略，以便在非高峰时段缩减实例。对于不可预测的流量尖峰，可以为低流量模型设置一个无服务器推理选项，或对于繁重的非实时批量评分任务使用异步推理（使用 AsyncInferenceConfig 和 S3 OutputConfig）。在部署前对模型应用 SageMaker Neo 编译，以减少 CPU/GPU 占用。理由：预置加自动扩展的组合提供了稳定的低延迟和成本控制；无服务器或异步终端节点能更经济高效地处理尖峰或批量工作负载，而 Neo 则降低了实例需求。

这种方法结合了用于降低训练成本的 EnableManagedSpotTraining 和 CheckpointConfig，用于手动审批的 SageMaker Model Registry 和 UpdateModelPackage，用于减少启动延迟的持久化开发实例，以及用于优化推理成本的预置、无服务器和编译后模型的混合使用。

← 生成式 AI 与基础模型 · 所有领域 · 计算机视觉、NLP 与专业化 ML →

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