Amazon MLA-C01: 模型部署与推理 — 学习指南

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

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

实时、无服务器、异步和批量端点 — 核心概念

Amazon SageMaker 中的实时推理是一种低延迟、有状态的服务模型。您需要创建一个 Model、一个 EndpointConfig 和一个 Endpoint，该 Endpoint 会分配预置的计算资源（ml.* 实例类型）并保持可用状态，通过 InvokeEndpoint API 提供请求服务。CreateEndpointConfig 接受 ProductionVariants，每个 ProductionVariant 定义了 ModelName、InitialInstanceCount、InstanceType 和 InitialVariantWeight；您可以使用 UpdateEndpointWeightsAndCapacities 或 UpdateEndpoint 来更改流量和容量。对于可预测的低延迟需求，预置的实时端点是主要选择，并支持多容器推理管道，以链接预处理、模型和后处理容器。

无服务器推理（Serverless Inference）无需管理实例，并在端点级别通过 ServerlessConfig 进行配置，该配置为每个 ProductionVariant 指定 MemorySizeInMB 和 MaxConcurrency；SageMaker 负责管理容器的预置，并在空闲时缩容至零，使其成为处理突发性、低吞吐量工作负载的理想选择。异步推理（Asynchronous Inference）针对运行时间长或客户端不需要同步响应的请求进行了优化。异步端点通过 CreateEndpointConfig 中的 AsyncInferenceConfig（包含 S3OutputPath 的 OutputConfig、可选的 ClientConfig 和 MaxConcurrentInvocationsPerInstance）创建，客户端调用 InvokeEndpointAsync，提供一个输入的 S3 URI；结果会写入配置的 S3 输出位置。批量转换（Batch Transform）是一种独立的作业类型（CreateTransformJob），用于大型离线推理工作负载；其 API 需要 TransformInput（包含 S3Uri 和 S3DataType 的 S3DataSource）、TransformOutput（S3OutputPath、Accept、AssembleWith）和 TransformResources（InstanceType、InstanceCount）。当吞吐量而非延迟至关重要时，批量转换是最佳选择，并且它支持跨数据集的大规模并行处理。

多模型端点、推理管道、影子测试与 A/B 测试 — 关键服务与配置

当托管大量模型且每个模型的 QPS 较低时，SageMaker 多模型端点（Multi-Model Endpoints, MME）允许单个容器托管数十到数千个存储在 S3 中的模型构件，并按需加载它们。您需要构建一个实现了 SageMaker 多模型服务器模式的模型服务器容器，或使用支持的框架镜像，将模型 tarball 上传到 S3，并创建一个引用该容器的 Model 资源。在调用时，您通过 InvokeEndpoint API 的参数 TargetModel（或标头 X-Amzn-SageMaker-Target-Model）传递目标模型名称，以便服务器将该模型从 S3 加载到内存中。对于大型模型集群，MME 可以节省内存和运营成本，但会为尚未驻留在运行时的模型增加冷加载延迟。

推理管道被实现为多容器模型，其中 Model 资源按顺序列出 Containers；端点将有效负载（payload）依次路由通过第一个容器（预处理）、模型容器，然后是后处理容器。在 CreateModel 中为每个容器定义其自己的 ModelDataUrl 和环境变量。对于金丝雀发布或蓝绿部署式测试，可以在 EndpointConfig 中使用多个 ProductionVariants，并通过 InitialVariantWeight 控制流量分割，之后可通过 UpdateEndpointWeightsAndCapacities 进行调整。影子部署（shadow deployment）可以通过两种方式实现：一是在应用层将每个请求的副本发送到一个影子端点（生产端点上没有流量权重），二是创建一个低权重的 ProductionVariant，以便端点基础设施接收一些镜像流量；应用层的请求复制可以为您提供完全的实验隔离和独立的可观察性。

为了进行按需和持续监控，可以在创建端点时配置 DataCaptureConfig，以将请求和响应的有效负载持久化到 S3。DataCaptureConfig 中值得关注的字段包括 EnableCapture (true)、InitialSamplingPercentage、DestinationS3Uri 和 CaptureOptions (REQUEST, RESPONSE)。捕获的数据成为 SageMaker Model Monitor 和 SageMaker Clarify 部署后检查的基础；您可以使用 Model Monitor 的 CreateMonitoringSchedule 创建基线，并运行临时的 Processing 作业，这些作业使用内置的模型监控容器来计算约束和漂移指标。

设计模式与权衡

当您需要个位数到两位数毫秒级的延迟，并且能够承担始终在线的容量成本时，请选择预置的实时终端节点。如果空闲时的每分钟成本是主要限制因素，且流量是间歇性的，那么无服务器终端节点可以减少运维工作：为每个变体配置 ServerlessConfig.MemorySizeInMB 和 ServerlessConfig.MaxConcurrency，然后让 SageMaker 自动扩展。对于具有长时间运行推理或重负载交换模式的工作负载，异步终端节点将客户端生命周期与计算解耦；它们需要 S3 用于输入/输出，并且最适用于客户端可以轮询或接收 S3 完成通知的场景。

多模型终端节点可以减少内存重复和 S3 对象管理的复杂性，但它们会增加每个模型的冷启动延迟，并需要一个能够按需从 S3 加载模型并进行适当生命周期管理（如驱逐/LRU）的模型服务器。如果每个模型的延迟至关重要，请将热门模型托管在专用的 ProductionVariants 上，并将低流量模型卸载到多模型终端节点（MME）。推理管道将预处理和后处理逻辑集中到更靠近模型的位置，从而减少客户端代码并确保训练和推理之间转换的一致性，但它们会增加终端节点的启动复杂性，并要求稳健的容器契约设计（输入/输出编解码器和内容类型）。

使用 ProductionVariant 权重进行 A/B 测试对于流量拆分和离线指标收集来说非常直接，但是当您希望在不影响生产指标的情况下进行流量影子测试时，应首选应用层面的镜像。对于渐进式部署和回滚自动化，请将 UpdateEndpointWeightsAndCapacities 集成到 CodePipeline 或 Step Functions 工作流中，该工作流应包括使用 CloudWatch 指标和 Model Monitor 警报进行自动指标评估，以及一个用于控制最终上线的需要手动批准的操作。

常见陷阱与决策标准

一个常见的运维错误是假设 Model Monitor 会检测标签可用性问题；Model Monitor 可以从捕获的请求中检测特征分布偏移和数据质量违规，但要衡量基于标签的指标（如 F1、召回率）的下降，您必须将真实标签（ground-truth labels）以监控作业可以使用的格式回传到 S3，并安排一个监控作业来计算预测与真实值的对比。另一个陷阱是未能恰当地设置 ServerlessConfig.MemorySizeInMB 的大小；内存配置不足会导致节流或容器崩溃，而过度配置则会增加成本。对于多模型端点，忽略设置适当的 S3 对象布局和生命周期（前缀、模型清单）会使冷加载变慢，并使驱逐策略复杂化。

在处理欺诈检测中的类别不平衡问题时，为了最小化运维开销，应优先选择算法原生加权，而不是繁重的采样管道；例如，XGBoost（SageMaker XGBoost 容器）支持 ‘scale_pos_weight’ 超参数，您可以将其计算为 negative_examples/positive_examples，并通过 CreateTrainingJob 调用中的超参数映射传递。对于手动部署门控，请使用 SageMaker Model Registry：创建一个 ModelPackageGroup，调用 CreateModelPackage 注册一个模型包，并将其状态设置为 PendingManualApproval；然后，外部的 CodePipeline 手动审批操作或 Step Functions + SNS 手动确认可以调用 UpdateModelPackage 将 ApprovalStatus 设置为 “Approved”，之后再运行 CreateModel 或 CreateEndpoint。

实践问题：用例场景

FraudDetectCo 正在构建一个在线欺诈检测系统，该系统必须整合 S3 中的交易日志和本地 MySQL 中的客户资料表，训练一个 XGBoost 模型，以近实时延迟部署它，对生产发布强制执行手动审批门，并能按需检测数据集异常和模型漂移。

数据聚合与预处理：使用 AWS Database Migration Service (DMS) 或 AWS Glue 的 JDBC 连接器，将本地 MySQL 表持续复制到 S3 (parquet 格式) 或支持 Amazon RDS/Athena 的数据湖中；使用 AWS Glue 进行数据编目，并在 Amazon SageMaker Feature Store 离线存储中注册特征，以提供一致的训练和在线服务特征查找。这可以集中管理特征血缘，并强制执行 S3 安全策略和 Lake Formation 治理以实现隔离。
训练与类别不平衡处理：使用 SageMaker XGBoost 内置容器运行 SageMaker 训练作业。计算训练标签的比例，并在 CreateTrainingJob 的 HyperParameters 映射中设置 XGBoost 超参数 “scale_pos_weight”，以最少的预处理来解决类别不平衡问题。为训练通道使用 Pipe 模式（DataSource 中 S3DataSource 的 S3DataType 设置为 S3Prefix，并且如果使用 Pipe 模式，需启用 “RecordWrapperType”:“None”），以减少连续作业的启动时间和数据下载延迟。
模型注册与手动审批：通过在 ModelPackageGroup 中调用 CreateModelPackage，将训练好的模型注册到 SageMaker Model Registry。将初始的 ApprovalStatus 设置为 PendingManualApproval，集成一个包含 AWS 手动审批操作的 AWS CodePipeline，在手动确认后，调用 UpdateModelPackage 将 ApprovalStatus 设置为 “Approved”，然后再通过 CreateModel 和 CreateEndpointConfig 将 ModelPackage 推广到生产环境。
部署与推理拓扑：将模型部署到预置的实时端点以进行低延迟评分。如果后续需要托管数百个模型，请评估使用多模型端点 (Multi-Model Endpoint)，并使用 InvokeEndpoint 的 TargetModel 参数来调用存储在 S3 中的特定模型。配置 DataCaptureConfig (EnableCapture=true, InitialSamplingPercentage=100, DestinationS3Uri=s3://<bucket>/captures, CaptureOptions=[‘REQUEST’,‘RESPONSE’]) 来收集请求/响应负载，以供按需分析。
监控与异常检测：使用 CreateMonitoringSchedule 安排 SageMaker Model Monitor 基线作业，以监控数据质量和特征漂移。对于数据集级别的异常检测和可视化，将捕获的 S3 数据输入到 Amazon Lookout for Metrics 以自动检测异常，并输入到 Amazon QuickSight 以创建仪表板。对于按需的偏见和漂移评估，可以针对捕获的数据运行 SageMaker Clarify 处理作业，或启动一个临时的 Model Monitor 处理作业（通过 CreateProcessingJob），该作业会应用已存储的基线约束并生成比较报告。

方案解析：该方法集中管理特征以实现可复现的训练和低延迟服务，使用 XGBoost 的 scale_pos_weight 以最小的管道复杂性处理类别不平衡问题，通过与 CodePipeline 集成的 Model Registry 强制执行手动审批，使用 Pipe 模式流式传输训练数据以减少训练启动延迟，并利用捕获的推理数据提供自动化异常检测 (Lookout for Metrics) 和按需的公平性/漂移检查 (Clarify + Model Monitor)。

← 模型评估与选择 · 所有领域 · MLOps 与模型生命周期管理 →

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