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 для вывода в реальном времени (подготовленные или бессерверные) обеспечивают задержки от менее 100 мс до нескольких секунд, что подходит для интерактивных API; выбирайте семейства инстансов, такие как ml.c5/m5 для моделей на CPU, ml.g4dn или ml.p3 для моделей на GPU, или ml.inf1 для недорогого вывода с высокой пропускной способностью на Inferentia. Асинхронный вывод (Asynchronous Inference) и пакетное преобразование (Batch Transform) подходят для сценариев с большими пакетами данных или переменной задержкой: Batch Transform идеален для крупных офлайн-задач (разбивайте большие объекты S3 на фрагменты и используйте инстансы ml.m5/c5 или GPU по мере необходимости), в то время как SageMaker Asynchronous Inference поддерживает более крупные полезные нагрузки с организацией очереди для пакетной обработки, близкой к реальному времени. Конечные точки для нескольких моделей (Multi-model endpoints) размещают множество моделей в одном контейнере, сокращая накладные расходы на хранение за счёт загрузки моделей по требованию; они лучше всего работают, когда модели небольшие, имеют умеренные затраты на холодный старт, а паттерны доступа разрежены. Выбирайте SageMaker Serverless Inference для непредсказуемых рабочих нагрузок с низкой пропускной способностью, чтобы избежать управления инстансами; остерегайтесь холодных стартов и ограниченного времени выполнения. Ключевые критерии для принятия решения включают SLO по задержке, стоимость за вызов, паттерн параллелизма, размер модели и устойчивость к холодным стартам. Распространённая ошибка — использовать конечные точки реального времени для пакетных рабочих нагрузок с чрезвычайно большим объёмом данных — это дорого; вместо этого используйте Batch Transform, Async Inference или вызывайте конечные точки с помощью пакетной обработки и параллельных воркеров.

Масштабирование, управление трафиком и оптимизация затрат

Автомасштабирование, переключение трафика и контроль затрат должны проектироваться совместно с топологией развёртывания. Используйте Application Auto Scaling для масштабирования вариантов конечных точек SageMaker с помощью политик отслеживания целевого значения (target-tracking) на основе метрик вызовов или пользовательских метрик CloudWatch; определите разумные минимальную/максимальную ёмкость и периоды восстановления (cooldowns), чтобы избежать частых переключений. Для развёртываний по схеме blue/green и канареечных выкаток (canary rollouts) используйте конечные точки с несколькими вариантами (multi-variant endpoints) или обновления EndpointConfig с процентным разделением трафика и его постепенным увеличением; интегрируйтесь с AWS CodeDeploy для автоматизации переключения трафика. Оптимизация затрат включает прунинг (упрощение) модели, квантование (FP16 или int8), компиляцию с помощью SageMaker Neo или AWS Neuron для Inf1, а также перенос нечувствительных к задержке рабочих нагрузок на Batch Transform или бессерверный вывод. Spot-инстансы снижают затраты на обучение, но неприменимы для конечных точек реального времени; вместо этого подбирайте инстансы правильного размера (cpu, gpu или inferentia) и при необходимости консолидируйте модели с помощью конечных точек для нескольких моделей. Остерегайтесь таких ошибок, как избыточное выделение ресурсов при использовании отслеживания целевого значения без понимания пропускной способности одного инстанса, или предположение, что конечные точки для нескольких моделей устраняют ограничения по памяти — загрузка модели всё равно требует памяти и может увеличить задержку. Также сжимайте артефакты модели (ONNX, TF SavedModel с помощью gz) и используйте стратегии ленивой загрузки, чтобы сократить время хранения и холодного старта.

Граничные вычисления, вывод с низкой задержкой и размещение пре/постобработки

Для сред с ультранизкой задержкой или без подключения к сети развёртывайте модели на 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), чтобы избежать накладных расходов на холодный вызов и уменьшить размеры полезной нагрузки, отправляемой модели.

Мониторинг, аудит, управление и обработка данных

Операционное машинное обучение (ML) требует непрерывного контроля за состоянием модели и управления данными. Используйте SageMaker Model Monitor для создания базового набора (baseline) обучающих данных с помощью DataQualityJob и настройте непрерывный мониторинг для обнаружения смещения данных (data drift), регрессии качества модели, пропущенных значений и пользовательских ограничений; включите DataCaptureConfig на конечных точках (endpoints) для сбора входных/выходных данных в S3 и запуска заданий Model Monitor. Для отслеживания происхождения признаков (lineage) и аудита на уровне признаков используйте Amazon SageMaker Feature Store (онлайн- и офлайн-хранилища) в сочетании с AWS Glue Data Catalog и CloudTrail для отслеживания доступа к наборам данных и их преобразований; Amazon Macie и задания AWS Glue/SageMaker Processing могут обнаруживать и скрывать персональные данные (PII) перед обучением. К подводным камням шифрования относится SSE-KMS: когда объекты S3 зашифрованы с помощью управляемого клиентом ключа (CMK), убедитесь, что роль выполнения SageMaker имеет разрешения kms:Decrypt и kms:GenerateDataKey, а политика CMK предоставляет доступ; также убедитесь, что политики бакета S3 и конечные точки VPC не блокируют доступ. При работе с большими ежедневными объектами S3 (например, 100 ГБ) избегайте загрузки в виде одного файла — разбивайте данные на множество мелких объектов, храните в формате Parquet со сжатием и используйте Athena/Glue для определения схемы. Распространенные ошибки включают недостаточно частое расписание мониторинга, отсутствие правильно созданного базового набора для Model Monitor и забывчивость предоставить доступ к KMS всем субъектам-службам (principals), таким как SageMaker, Glue и Lambda, которым требуется расшифровка.

Практическая задача: сценарий использования

Сценарий: Компания Streamlytic Media управляет платформой аналитики подкастов на AWS. Они используют Kinesis Data Streams для приема событий пользователей, хранят агрегированные признаки в S3 и размещают модели в SageMaker для прогнозирования вовлеченности в реальном времени. Данные иногда содержат персональные данные (PII) и зашифрованы с помощью управляемого клиентом ключа SSE-KMS.

Задача: Обеспечить прогнозирование с низкой задержкой на основе скользящего 10-минутного окна событий, скрывать PII перед обучением модели, гарантировать, что SageMaker может читать зашифрованные данные из S3, и внедрить непрерывный мониторинг для отслеживания смещения признаков (feature drift).

Рекомендуемый подход:

1. Создать поток Kinesis Data Stream для приема событий, запустить Kinesis Data Analytics (Flink) для поддержания скользящих 10-минутных окон и вывода агрегированных признаков в S3 в формате Parquet с ежечасным партиционированием.
2. Обнаруживать и скрывать PII с помощью Amazon Macie для обнаружения и задания SageMaker Processing (или задания AWS Glue) для применения детерминированного скрытия/токенизации; хранить результаты в офлайн-хранилище Feature Store для обучения.
3. Предоставить роли выполнения SageMaker разрешения kms:Decrypt и kms:GenerateDataKey для CMK, добавить эту роль в политику ключа CMK и убедиться, что политика бакета S3 или конечная точка VPC разрешает доступ для SageMaker.
4. Развернуть модель как конечную точку SageMaker реального времени на инстансах ml.inf1, включить DataCaptureConfig, создать базовый набор (baseline) для Model Monitor из обучающих данных и настроить непрерывный мониторинг с оповещениями в CloudWatch.

Обоснование: Потоковая агрегация с помощью Kinesis + Flink минимизирует объем событий и задержку; скрытие данных на этапе обработки обеспечивает конфиденциальность и соответствие требованиям; явные разрешения KMS предотвращают сбои доступа; конечные точки на базе Inferentia и Model Monitor обеспечивают баланс между низкой стоимостью вывода и операционной наблюдаемостью.

← Обучение · Все домены · Безопасность →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →