Переход с локального jupyter на Amazon SageMaker

Авторы: Викеш Пандей, Осман Хамзауи

Сегодня Jupyter Notebooks — одна из самых популярных IDE для большинства специалистов по данным (DS), которые проводят свои эксперименты по машинному обучению. Как правило, вы устанавливаете Jupyter Server на свой локальный компьютер или ИТ-сервер (в облаке) и начинаете работу. Хотя это дает вам независимость, часто вы ограничены вычислительной мощностью базовой среды (локальной/облачной), в которой работает сервер Jupyter.

Будь то запуск модели, требующей графического процессора, или обучение с такими большими наборами данных, которые заполняют локальную память, или даже просто проведение большего количества экспериментов, вы часто достигаете предела того, что вы можете делать с вашими локальными компьютерами или ИТ-серверами.

Чтобы улучшить этот опыт, в этом блоге мы пытаемся разбить шаги, которые необходимо выполнить для перехода от вашей локальной среды Jupyter к масштабируемой управляемой среде машинного обучения в облаке, такой как Amazon SageMaker.

Мы разделим блог на следующие разделы:

Обзор Amazon SageMaker
Проблемы, возникающие при миграции
Инструктивное руководство о том, как решить проблемы

1. Обзор Amazon SageMaker

Amazon SageMaker предоставляет полностью управляемые решения и API-интерфейсы, охватывающие каждый этап жизненного цикла машинного обучения, а также операционный аспект (т. е. MLOps). Цель состоит в том, чтобы позволить вам сосредоточиться на ускорении итераций машинного обучения и экспериментов, не беспокоясь о базовой инфраструктуре и среде. SageMaker также поставляется с собственной IDE: SageMaker Studio. Он предоставляет единую панель управления для выполнения различных шагов в жизненном цикле машинного обучения. Он построен на основе интерфейса JupyterLab, настроенного с использованием определенных виджетов, которые позволяют вам взаимодействовать с различными API-интерфейсами SageMaker.

В чем разница между SageMaker и SageMaker Studio?

SageMaker — это набор API для выполнения различных действий в жизненном цикле машинного обучения. Принимая во внимание, что SageMaker Studio — это инструмент пользовательского интерфейса / IDE для доступа к большинству этих API, а также предоставляет управляемую среду ML.

Проще говоря, вы можете использовать SageMaker API без использования SageMaker Studio IDE. В блоге мы также отдельно упомянули SageMaker и Studio, где это необходимо.

2. Проблемы, возникающие при миграции

Отказ от ответственности: Проблемы, с которыми сталкивается DS здесь, связаны со сменой парадигмы между локальным машинным обучением и облачным. Они не являются специфическими для SageMaker, а связаны с тем, как можно запускать машинное обучение в облаке. против местного. Итак, давайте приступим.

Итак, теперь вы рады попробовать SageMaker. Вы входите в учетную запись AWS, подключаетесь к домену SageMaker Studio и запускаете SageMaker Studio IDE. Но тут начинаются проблемы. Давайте взглянем на обучающую часть жизненного цикла машинного обучения и разберем проблемы:

Загадка: при локальной разработке DS имел полный доступ к инфраструктуре обучения (их ноутбук/облачный экземпляр). Все бегало в одном месте. Они могли видеть, где проходят тренировки. Они могли подключаться к учебной среде, выполнять отладку и иметь полный контроль и доступность. Принимая во внимание, что в случае с SageMaker разные части машинного обучения (обучение, настройка, развертывание, мониторинг и т. д.) выполняются в разных средах выполнения. Например: обучение происходит в управляемом SageMaker учебном кластере, который раскручивается по запросу и отключается после завершения задания обучения. И модель при развертывании размещается на другом вычислении. Различные среды выполнения иногда могут сбивать с толку.
Модель. При работе с локальным кодом обучающий код просто сохраняет модель в выбранный вами локальный каталог. Где это находится в облаке?
Данные. Пока DS проводят свои эксперименты на локальном компьютере, большую часть времени их данные хранятся на локальном компьютере или на каком-либо общем сервере озера данных, и они просто указывают обучающий код на эти пути. . Как это будет работать в облаке?
Конфигурации: локально DS предоставляет конфигурации среды и гиперпараметры прямо в самом скрипте в виде аргументов командной строки или в виде файла JSON. Как это будет работать в облаке?
Самостоятельная дилемма: SageMaker предоставляет полностью управляемые контейнеры для популярных фреймворков, таких как Tensforflow, PyTorch, HuggingFace и т. д., но что, если вы хотите использовать свои собственные контейнеры для обучения? Как это будет работать в облаке?

3. Рекомендации по решению проблем

В рамках решения мы сосредоточимся на первых двух задачах в этом блоге, а следующие две рассмотрим во второй части этого блога. Последнее испытание (пункт 5 выше) заслуживает отдельного блога, и это будет часть 3, финал.

Итак, давайте поговорим о том, как решить эти проблемы. Мы обсудим два разных способа решения проблем.

Запуск как есть: часто также называется «быстрым способом». Прост в исполнении, но очень неэффективен и не дает преимуществ запуска кода в облаке.
Нативное облачное решение. Немного больше работы, но оно того стоит, учитывая экономическую эффективность и масштабируемость, которые оно обеспечивает.

3.1. Запустить как есть

В этом случае DS запускает IDE SageMaker Studio, запускает блокнот, копирует и вставляет свой локальный обучающий код в ячейки блокнота и запускает его. Никаких других изменений не требуется !!

Давайте возьмем этот образец блокнота из PyTorch QuickStart tutorial. Вы можете запустить этот блокнот как есть в SageMaker Studio, если выберете правильный образ/ядро в Studio. Мы протестировали блокнот с PyTorch 1.12 Python 3.8 CPU optimized образом с Python3 ядром в Studio, и он работал без ошибок. Взгляните на скриншот ниже, чтобы выбрать правильный образ и ядро в Studio:

А почему не так..

Проблема в этом случае заключается в том, что вы только что перенесли свой код машинного обучения в облако, но не использовали большинство преимуществ эфемерных сред выполнения, предоставляемых SageMaker и облачной IDE. Вы также можете в конечном итоге заплатить больше, используя более крупные экземпляры, имеющие больше оперативной памяти, ЦП и графических процессоров, но столкнетесь с большим временем простоя вычислительных ресурсов. Иллюстрация ниже объясняет то же самое:

Одним из ключевых преимуществ использования облака является модель ценообразования «оплата по мере использования», или, другими словами, «платите только за то, что используете, а не больше». Предполагая, что вы работаете 8 часов в день, ЦП используется большую часть времени, тогда как ГП используется только в течение 2 часов (25% времени безотказной работы экземпляра). Другими словами, 75% затрат, генерируемых графическим процессором, ушли в никуда.

3.2 Облачное приложение

Чтобы воспользоваться эластичностью облака, вы можете использовать меньшие вычислительные ресурсы при написании, отладке или тестировании кода на небольших выборках и использовать более крупные вычислительные кластеры по запросу, предоставляемые SageMaker, при выполнении обработки больших данных, обучении или выводах. Кроме того, это было бы довольно экономично, поскольку вы используете подходящие вычислительные ресурсы для работы. Однако, чтобы достичь такого разделения среды выполнения, вам необходимо внести немного модульности и структуры в нашу кодовую базу.

В следующем примере мы покажем, как можно перейти от типичного учебного примера PyTorch, который можно запускать локально как есть, к экономичному и масштабируемому обучению в облаке.

Мы будем использовать API управляемого обучения SageMaker для PyTorch. API позволяет запустить обучение на удаленном эфемерном вычислительном кластере, полностью управляемом SageMaker, при этом оплачивается только продолжительность обучения. Пройдемся по необходимым изменениям:

Сначала просто скопируйте весь код ячейка за ячейкой в скрипт Python. Или используйте nbconvert, чтобы сделать это автоматически.

Примечание: убедитесь, что вы удалили код предсказания модели из примера, так как мы сосредоточились на обучении только ради этого примера.

Пока давайте оставим код загрузки данных как есть, читая из API PyTorch DataSet. Мы изменим это во части-2 этого блога.
Поскольку обучение происходит в эфемерном вычислительном задании, нам нужен способ доступа к обученной модели, даже если экземпляр остановлен. Когда SageMaker запускает обучающее задание, он извлекает контейнер (PyTorch) (поскольку этот пример относится к PyTorch) и устанавливает список переменных среды. Одной из этих переменных среды является SM_MODEL_DIR, локальный путь, по которому каждый существующий файл будет упакован и помещен в корзину S3 по вашему выбору. Мы сохраним нашу модель там:

#add couple of imports to the beginning of the script
import os
import argparse
#immediately after imports, add the code to load the environment variable
parser = argparse.ArgumentParser()
parser.add_argument("-model-dir", type=str, default=os.environ["SM_MODEL_DIR"])

И затем ближе к концу скрипта вместо:

torch.save(model.state_dict(), "model.pth")

Измените его на:

path = os.path.join(args.model_dir, "model.pth")
torch.save(model.state_dict(), path)

Вы также можете ознакомиться с этим справочным обучающим скриптом с такими же изменениями.

Теперь нам нужен способ запустить обучающий скрипт. Для этого SageMaker предоставляет PyTorch Estimator, который содержит информацию о том, где находится код, на какой инфраструктуре запускать скрипт и т. д. SageMaker предоставляет полностью управляемые контейнеры для популярных фреймворков, таких как TensorFlow, PyTorch, MXNet, HuggingFace и т. д. Заинтересовано читатели могут прочитать больше здесь. Ниже приведен код, который вам нужно поместить в ту же записную книжку, где мы запускали пример как есть. Просто добавьте новую ячейку и вставьте следующий код:

import sagemaker # importing sagemaker python SDK
from sagemaker.pytorch.estimator import PyTorch # import PyTorch Estimator class 
from sagemaker import get_execution_role # import fn to fetch execution role

#Store the execution role. 
#Here the same role used which was used to create a sagemaker studio user profile
execution_role = get_execution_role()

#Using the PyTorch estimator tells SageMaker to use an AWS provided PyTorch container
estimator = PyTorch(
    entry_point = "train.py", # training script
    framework_version = "1.12", #PyTorch Framework version, keep it same as used in default example
    py_version = "py38", # Compatible Python version to use
    instance_count = 1, #number of EC2 instances needed for training
    instance_type = "ml.c5.xlarge", #Type of EC2 instance/s needed for training
    disable_profiler = True, #Disable profiler, as not needed
    role = execution_role #Execution role used by training job
)

#Start the training
estimator.fit()

Приведенный выше код запускает задание обучения на эфемерном обучающем вычислительном экземпляре, созданном и управляемом Amazon SageMaker. Экземпляр будет автоматически завершен после завершения задания. Созданная модель будет упакована в tar.gz и сохранена в пути S3 по умолчанию, созданном заданием обучения SageMaker, но вы можете переопределить этот путь, указав свое собственное местоположение Amazon S3 в качестве одного из аргументов. в оценщике PyTorch».

Еще один момент, на который стоит обратить внимание: созданная модель не зависит от SageMaker. Вы можете разместить/развернуть эту модель где угодно, даже за пределами SageMaker.

Есть ли какой-то средний путь, кроме как покинуть местную среду?

Если вы все еще хотите продолжать работать в локальной среде Jupyter, вы можете это сделать. Просто настройте свои учетные данные AWS в локальной среде и используйте там SageMaker SDK.

Итак, что вы получили, внеся эти изменения?

Ваше обучение теперь более модульное, что позволяет вам запускать его в другой среде (вычислительный экземпляр), а не в той, где вы пишете код (например, в среде jupyter IDE). Теперь вы можете запускать несколько обучающих заданий параллельно, каждое из которых имеет разные требования к вычислительным ресурсам и памяти.
Это дает вам возможность запускать записные книжки на менее мощных экземплярах и проводить обучение на более крупных экземплярах, если это необходимо.
Это позволяет свести затраты к минимуму, платя только за то, что вы используете, и упрощает масштабирование за счет параллельного проведения нескольких тренингов.
Нет больше свободных ресурсов. Больше не нужно платить за экземпляры графического процессора весь день только для того, чтобы выполнить 2-часовое задание по обучению.
Использование блокнотов SageMaker Studio дает гораздо больше преимуществ. Заинтересованные читатели могут Погрузиться в архитектуру ноутбуков Amazon SageMaker Studio.

Резюме и следующие шаги

Подводя итог, можно сказать, что в этом блоге вы узнали, как перенести учебный код из собственной среды jupyter в SageMaker и использовать IDE SageMaker в качестве среды jupyter. Весь код, связанный с блогом, доступен в этом git-репозитории.

Но в этом блоге мы не рассмотрели несколько моментов:

Как насчет того, чтобы указать свои собственные местоположения данных? Как это будет работать с SageMaker?
Как насчет других конфигураций, специфичных для среды? Гиперпараметры? Как это сработает?

Об этом мы и поговорим в Части 2. Читайте дальше, чтобы продолжить знакомство с SageMaker.

Переход с локального jupyter на Amazon SageMaker — Часть 1