Amazon MLS-C01: 部署、推理与服务 (ML 实施与运维) — 学习指南

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

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

部署模式与服务选项

模型服务选项需要在延迟、成本、吞吐量和运维复杂性之间进行权衡。实时的 SageMaker 端点（预置型或无服务器型）提供亚百毫秒到秒级的延迟，适用于交互式 API；CPU 模型可选择 ml.c5/m5 等实例系列，GPU 模型可选择 ml.g4dn 或 ml.p3，而对于低成本高吞吐量的 Inferentia 推理，则可选择 ml.inf1。异步推理和批量转换适用于大批量或可变延迟的用例：批量转换是大型离线作业的理想选择（将大型 S3 对象拆分为分片，并根据需要使用 ml.m5/c5 或 GPU 实例），而 SageMaker 异步推理支持更大的负载，并通过排队机制实现近实时的批量处理。多模型端点在单个容器后托管多个模型，通过按需加载模型来减少存储开销；当模型较小、冷启动成本适中且访问模式稀疏时，这种方式效果最好。对于不可预测的低吞吐量工作负载，选择 SageMaker 无服务器推理可以避免实例管理；但要注意冷启动和有限的运行时。关键决策标准包括延迟 SLO、单次调用成本、并发模式、模型大小和冷启动容忍度。一个常见的陷阱是为超高容量的批量工作负载使用实时端点——这样做成本高昂；正确的做法是使用批量转换、异步推理，或通过批处理和并发工作程序来调用端点。

扩展、流量整形和成本优化

自动扩展、流量转移和成本控制必须与部署拓扑协同设计。使用 Application Auto Scaling，基于调用指标或自定义 CloudWatch 指标，通过目标跟踪策略来扩展 SageMaker 端点变体；定义合理的最小/最大容量和冷却时间以避免抖动。对于蓝/绿部署和金丝雀发布，使用多变体端点或更新 EndpointConfig，设置流量拆分百分比并逐步增加；与 AWS CodeDeploy 集成以自动化流量转移。成本优化措施包括模型剪枝、量化（FP16 或 int8）、使用 SageMaker Neo 或 AWS Neuron 为 Inf1 进行编译，以及将对延迟不敏感的工作负载转移到批量转换或无服务器推理。Spot 实例可降低训练成本，但不适用于实时端点；相反，应合理选择实例类型（CPU vs GPU vs Inferentia），并在适当情况下使用多模型端点整合模型。注意一些陷阱，例如在不了解单个实例吞吐量的情况下使用目标跟踪导致过度预置，或者想当然地认为多模型端点能消除内存限制——模型加载仍然需要内存，并可能增加延迟。此外，压缩模型构件（ONNX、使用 gz 压缩的 TF SavedModel）并采用惰性加载策略，可以减少存储和冷启动时间。

边缘、低延迟推理以及前/后处理的部署位置

对于超低延迟或离线环境，可将模型部署到 AWS IoT Greengrass (v2)，或使用 SageMaker Edge Manager 在边缘设备上打包和监控模型；使用 SageMaker Neo 或 AWS IoT Greengrass 组件进行编译，并使用量化来满足内存/CPU 限制。将预处理和特征提取放置在能最大限度减少端到端延迟和成本的位置：简单的过滤器可以在设备固件或 Greengrass Lambda 中运行，批处理和重型转换则应放在边缘网关或云端。对于流式事件窗口（例如，滑动的 10 分钟窗口），使用 Amazon Kinesis Data Streams 或 Amazon MSK 进行数据采集，使用 Kinesis Data Analytics 或 Flink/Apache Spark 进行窗口化和聚合，然后将汇总后的特征转发到 SageMaker 端点或轻量级的边缘模型——这可以减少网络出口流量和模型调用频率。注意一些陷阱，例如忽略边缘设备上的模型版本控制，或未能为模型构件预置足够的设备存储空间。对于服务器端微服务，将预处理（API Gateway + Lambda 或 ALB + Fargate）部署在同一位置，以避免冷调用开销并减少发送到模型的负载大小。

监控、审计、治理和数据处理

运维级机器学习（Operational ML）需要持续的模型健康状况监控和数据治理。使用 SageMaker Model Monitor 通过 DataQualityJob 为训练数据建立基线，并配置持续监控以检测数据漂移、模型质量下降、缺失值和自定义约束；在端点上启用 DataCaptureConfig，将输入/输出捕获到 S3 并触发 Model Monitor 作业。为了实现特征级别的血缘关系和审计，可结合使用 Amazon SageMaker Feature Store（在线和离线存储）与 AWS Glue Data Catalog 及 CloudTrail 来跟踪数据集的访问和转换；Amazon Macie 和 Glue/SageMaker Processing 作业可以在训练前发现并编辑个人身份信息（PII）。加密方面的陷阱包括 SSE-KMS：当 S3 对象使用客户管理的 CMK 加密时，请确保 SageMaker 执行角色拥有 kms:Decrypt 和 kms:GenerateDataKey 权限，并且 CMK 策略授予了访问权限；同时还要确保 S3 存储桶策略和 VPC 端点不会阻止访问。对于每日产生的大型 S3 对象（例如 100 GB），应避免单文件摄取——将其分区为许多更小的对象，以 Parquet 格式存储并进行压缩，然后使用 Athena/Glue 进行模式检测。常见的陷阱包括监控计划不足、未为 Model Monitor 生成适当的基线，以及忘记向所有需要解密的服务主体（SageMaker、Glue、Lambda）授予 KMS 访问权限。

实践问题：用例场景

场景： Streamlytic Media 在 AWS 上运营一个播客分析平台。他们使用 Kinesis Data Streams 摄取用户事件，将聚合后的特征存储在 S3 中，并在 SageMaker 中托管模型以进行实时用户参与度预测。数据偶尔包含 PII，并使用 SSE-KMS 客户管理的密钥进行加密。

挑战： 在 10 分钟的滚动事件窗口上提供低延迟预测，在模型训练前编辑 PII，确保 SageMaker 能够读取加密的 S3 数据，并实施针对特征漂移的持续监控。

推荐方法：

创建一个 Kinesis Data Stream 来摄取事件，运行 Kinesis Data Analytics (Flink) 来维护 10 分钟的滚动窗口，并将聚合后的特征以 Parquet 格式按小时分区输出到 S3。
使用 Amazon Macie 进行发现，并使用 SageMaker Processing 作业（或 AWS Glue 作业）应用确定性的编辑/令牌化来检测和编辑 PII；将结果存储在 Feature Store 离线存储中用于训练。
为 SageMaker 执行角色授予对 CMK 的 kms:Decrypt 和 kms:GenerateDataKey 权限，将该角色添加到 CMK 密钥策略中，并确保 S3 存储桶策略或 VPC 端点允许 SageMaker 访问。
将模型部署为 ml.inf1 实例上的 SageMaker 实时端点，启用 DataCaptureConfig，从训练数据创建 Model Monitor 基线，并配置持续监控以及向 CloudWatch 发送警报。

基本原理： 使用 Kinesis + Flink 进行流式聚合可最大限度地减少事件量和延迟；在处理时进行编辑可保护隐私并确保合规性；明确的 KMS 权限可防止访问失败；由 Inferentia 支持的端点和 Model Monitor 在低推理成本与运维可观察性之间取得了平衡。

← 训练、分布式训练与超参数优化 · 所有领域 · 安全、隐私与合规 →

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