Amazon MLA-C01: MLOps 与模型生命周期管理 — 学习指南

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

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

核心概念

AWS 中的模型生命周期管理核心在于将模型视为具有可审计血缘、自动化晋升门控和可复现管道的版本化构件。Amazon SageMaker 提供了基础构件：用于编排的 SageMaker Pipelines，用于版本控制和审批状态的 SageMaker Model Registry (ModelPackage/ModelPackageGroup)，用于 CI/CD 的 SageMaker Projects 和 CodePipeline，以及用于持续质量和偏见检查的 Model Monitor/Clarify。一个稳健的生命周期始于可复现的输入——存储在 S3 中、经过服务器端 KMS 加密并采用严格存储桶策略或 Lake Formation 管控的不可变训练数据，在源代码仓库中进行版本控制的代码，以及在传递给

undefined

或 sagemaker SDK

undefined

的容器镜像 URI 和实例类型中声明的训练环境。

操作控制包括通过

undefined

的

undefined

(

undefined

和

undefined

) 和

undefined

实现网络隔离以阻止出站流量，以及遵循最小权限原则的 IAM 角色（例如，

undefined

仅对特定存储桶拥有

undefined

和

undefined

权限）。当训练作业完成时，使用

undefined

或 SDK 的

undefined

调用，通过指定

undefined

将构件注册到 Model Registry，并将

undefined

设置为 “PendingManualApproval” 以驱动人工门控。血缘元数据——如训练超参数、Docker 镜像、输入数据 S3 URI、Git 提交——应作为模型包元数据附加，以便下游的 CI/CD 和审计可以从生产端点追溯回代码和数据集。

机器学习的 CI/CD 与传统的 CI/CD 不同，因为其构件（模型、基线、监控器）体积庞大且输出具有非确定性。使用 SageMaker Projects 模板结合 AWS CodePipeline 和 CodeBuild 来实现 CI/CD。使用 CodeBuild 运行单元测试、模型训练冒烟测试（例如，使用较少的轮次或数据子集）和集成测试。使用 CodePipeline 编排“源代码 → 构建 → 注册模型”的步骤，并集成一个 ManualApproval 操作或基于 Lambda 的自定义操作，通过

undefined

来切换

undefined

的

undefined

。对于自动化晋升，CodePipeline 可以调用 SageMaker 的

undefined

和

undefined

API，或者使用 SageMaker Projects 生成的 CloudFormation 堆栈，以可预测的基础设施即代码方式进行部署。

关键服务和配置

SageMaker Pipelines 是编排层：在 Python 中声明

undefined

、

undefined

、

undefined

、

undefined

和

undefined

等步骤对象。在步骤上使用

undefined

(

undefined

)，以便在输入和参数未改变时重用步骤的输出；这可以避免不必要的实例配置。对于

undefined

，使用

undefined

，并将

undefined

和

undefined

设置为 “PendingManualApproval”，从而将审批门控集成到管道图中。使用

undefined

API 启动运行，并使用

undefined

或控制台来检查运行状态和血缘。

SageMaker Model Registry 在一个

undefined

下存储模型包，并为其分配

undefined

标识符。相关的 API 包括

undefined

、

undefined

、

undefined

，以及用于将

undefined

更改为 “Approved” 或 “Rejected” 的

undefined

。

undefined

对象应包含元数据字段，如

undefined

(

undefined

,

undefined

,

undefined

) 和

undefined

。部署时，使用模型包 ARN 调用

undefined

并指定

undefined

和

undefined

，然后调用

undefined

并配置

undefined

(

undefined

,

undefined

,

undefined

) 以启用推理捕获。

对于监控和偏见检测，使用 SageMaker Model Monitor 和 SageMaker Clarify。Model Monitor 需要一个通过

undefined

创建的基线，该操作会调用

undefined

来生成基线统计数据和约束；这些基线存储在 S3 中，并在

undefined

中被引用。监控计划通过

undefined

创建，并可通过

undefined

/

undefined

来启动/停止。要对实时端点进行临时的偏见检查，可以运行一个使用 Clarify 容器的 SageMaker Processing 作业（通过

undefined

或

undefined

），并使用捕获的推理日志作为输入；Clarify 支持模型偏见检查，并将报告返回到 S3。

为了安全地聚合异构数据源，可以使用 AWS Glue 和 Lake Formation 来发现、编目和 ETL 来自 S3、JDBC 源（例如通过 AWS Glue JDBC 连接器连接的本地 MySQL，并可选择使用 DataSync 进行批量数据迁移）以及流式源的数据。AWS Glue 作业 (PySpark) 可以将经过整理的数据集写入到加密的 S3 数据湖中，并通过 Lake Formation 进行细粒度访问控制。对于自动化异常检测和可视化，可以在托管服务之间进行选择：Amazon Lookout for Metrics 执行自动化的时间序列异常检测，而 SageMaker Data Wrangler 提供快速的可视化探索和转换，并能将预处理管道导出回 SageMaker Processing 或 Pipelines。对于需要可视化仪表板的持续异常检测，可以将用于检测的 Lookout for Metrics 与用于可视化和下钻分析的 Amazon QuickSight 结合使用。

设计模式与权衡

一个常见的模式是管道优先：编写一个 SageMaker Pipeline，其中包含数据预处理 (ProcessingStep)、训练 (TrainingStep)、模型评估 (ProcessingStep 或 ClarifyProcessor)、注册模型 (RegisterModel) 以及部署 (ModelStep 或手动提升)。使用步骤缓存来最大限度地减少冗余计算并加速迭代开发。为了安全地提升模型，将 model_approval_status 设置为 “PendingManualApproval”，并集成 CodePipeline 的 ManualApproval 操作或一个用于更新模型包的审批 Lambda。这种设计提供了一条从数据和代码到生产环境的可审计路径，同时支持人在回路的治理。

对于 CI/CD，需要在两种权衡之间做出选择：基于指标门限的全自动提升（速度快，手动步骤少）与手动审批工作流（满足合规性）。通过 CodeBuild 执行一个小的 evaluate.py 脚本来实现基于指标的门控，该脚本调用 SageMaker Runtime 或加载模型包，计算指标，并输出一个工件供 CodePipeline 用来决定通过/失败。如果合规性要求人工签核，可以插入一个 AWS CodePipeline ManualApprovalAction，它通过 SNS 触发一封电子邮件，并要求指定的审批人才能继续；或者，将模型注册表（Model Registry）的状态作为权威事实来源，并且仅在 ModelApprovalStatus 等于 “Approved” 时才允许部署。

减少训练任务的启动延迟通常在于避免重复的完整预置过程。如果许多管道运行在相同的输入上重新训练，请启用管道的 CacheConfig，这样当输入未改变时，TrainingStep 就会被跳过。对于每次运行都必须训练但要求低延迟的迭代，可以在 SageMaker Studio 中使用较小的实例类型进行快速原型设计，或者在持久化的 Amazon EC2 实例或由 EKS 支持的自定义训练编排器上运行多个实验，以避免容器冷启动——这是用运维开销换取更低延迟的做法。对于生产级的可扩展性，应接受一定的启动延迟，转而专注于自动化可复现性。

常见陷阱与决策标准

一个常见的错误是仅依赖端点日志进行漂移检测，而没有在部署时启用 DataCaptureConfig；若不捕获数据，Model Monitor 和 Clarify 将无法分析真实的推理输入。务必在 CreateEndpointConfig 中配置 DataCaptureConfig（包括 EnableCapture=true、DestinationS3Uri、CaptureOptions 和 InitialSamplingPercentage），并通过 CreateMonitoringSchedule 设置一个链接到基线统计数据的监控计划。

另一个陷阱是 S3 和网络安全措施不足。必须保持隔离的训练任务应在 CreateTrainingJob 中使用 VpcConfig，并为 S3 对象启用 KMS 加密。不要依赖公共访问控制；而应使用 S3 存储桶策略、VPC 端点 (com.amazonaws.region.s3) 和 IAM 角色范围限定。最后，为了避免脆弱的 CI/CD，应将评估指标和模型卡元数据“烘焙”到模型包中，并使用不可变的版本控制 (ModelPackageVersion) 来代替覆盖旧的构件。

实践问题：用例场景

AcmePay — 交易流的欺诈检测。挑战在于构建一个安全、可审计的生命周期，该生命周期能够聚合 S3 交易日志、客户资料和本地 MySQL 表，训练一个 XGBoost 欺诈分类器，维护一个带有生产前手动审批流程的中央模型注册表，按需检测数据和偏见漂移，并最小化版本控制和迭代运行的操作开销。

1. 集中化数据：使用 AWS Glue 通过 AWS Glue JDBC 连接器（通过安全的 DataSync 传输或 VPC 对等连接实现网络访问）来抓取 S3 交易日志和本地 MySQL。在 Glue Data Catalog 中对数据集进行编目，并通过 AWS Lake Formation 强制执行访问控制。将整理好的训练集存储在加密的 S3 前缀中（使用 KMS CMK），并结合使用存储桶策略和 VpcEndpoint 来防止公共访问。

2. 构建可复现的管道：编写一个 SageMaker Pipeline，其中包含用于特征工程的 ProcessingStep（使用 Data Wrangler 或 Glue ETL 导出）、运行内置 XGBoost 容器并配置超参数的 TrainingStep，以及一个调用 RegisterModel 并设置 model_package_group_name=“acmepay-fraud-group” 和 model_approval_status=“PendingManualApproval” 的 RegisterModel 步骤。在预处理和训练步骤上启用 CacheConfig，以便在输入/代码未更改时重用输出，从而减少重复的实例配置。

3. CI/CD 与审批：创建一个 SageMaker Project，它会搭建一个 AWS CodePipeline 的脚手架。该管道在 CodeBuild 中运行单元测试，触发 SageMaker Pipeline，并在 RegisterModel 步骤后包含一个 CodePipeline 的 ManualApproval 操作。当手动审批操作被批准后，它会调用一个 Lambda 函数，该函数调用 UpdateModelPackage 将 ModelApprovalStatus 设置为 “Approved”，然后触发 CreateEndpointConfig 和 CreateEndpoint 进行部署。使用 SageMaker Projects 生成的 CloudFormation 资源来保持基础设施的可复现性。

4. 保护训练与部署安全：提交训练任务时，使用 CreateTrainingJob 的 VpcConfig (SubnetIds, SecurityGroupIds) 并设置 EnableNetworkIsolation=true；确保 SageMaker 执行角色拥有对 KMS 密钥的 kms:Decrypt 权限，以及仅对整理好的数据集前缀拥有 s3:GetObject 权限。对于端点，创建 CreateEndpointConfig 时配置 DataCaptureConfig (EnableCapture=true, SamplingPercentage=100, DestinationS3Uri=s3://acmepay-prod/capture)，以便保留推理数据用于监控。

5. 按需进行漂移和偏见检查：在捕获的推理数据和真实标签（如果可用）上，通过一个 ProcessingJob 使用 SageMaker Clarify 按需运行 ModelBias 和 ModelExplainability 分析；当数据科学团队请求评估时，从 Lambda 或 Step Functions 中通过 ClarifyProcessor.run() API 调用它。对于持续的漂移警报，通过 DefaultModelMonitor.suggest_baseline 创建一个 Model Monitor 基线和一个 MonitoringSchedule；使用 CreateMonitoringSchedule 运行定期检查，并为违规情况配置 SNS 通知。

AWS 方案解析：Glue + Lake Formation 以最少的自定义 ETL 代码集中并保护了异构数据源；SageMaker Pipelines + CacheConfig 最大限度地减少了迭代运行中的基础设施变动；Model Registry 提供了不可变的版本控制和元数据（ModelPackageGroupName 和 ModelPackageVersion），并通过 ModelApprovalStatus 与审批工作流原生集成；而 SageMaker Clarify 加上 Model Monitor 则同时提供了按需偏见评估和定期的漂移检测。使用 SageMaker Projects 和 CodePipeline 可以标准化 CI/CD，并在生产部署前强制执行从 “PendingManualApproval” 到 “Approved” 的可审计、可重复的晋升流程。

← 模型部署与推理 · 所有领域 · 模型监控与可观测性 →

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

浏览 Amazon →