Настройка и развертывание Huggingface Transformers с помощью Vertex AI — Часть 3 Запустите распределенную настройку и…

Настройка и развертывание Huggingface Transformers с помощью Vertex AI — часть 3. Запуск распределенной настройки, обучения и обслуживания

Введение

Я считаю, что документацию Google очень сложно понять, особенно когда речь идет о Vertex AI. Мне потребовалось несколько дней, чтобы создать задание по настройке гиперпараметров, получить наилучшие параметры и обучиться с этими значениями. Итак, я решил написать средний пост об этом. Это долгий путь, и поэтому это будет серия статей. Шаги будут такими:

Настройка инфраструктуры
Загрузка набора данных
Настройка гиперпараметров
Тренировка с лучшими параметрами
Развертывание модели в конечной точке и получение прогнозов

Окончательный результат будет выглядеть так

Это третья часть книги «Настройка и развертывание ВЧ-трансформаторов с помощью Vertex AI».

В части 1 мы создали необходимые компоненты GCP.

Во второй части мы создали код обучения и настройки модели и обернули его в контейнер докеров.

Для просмотра всего кода мы будем использовать этот репозиторий GitHub.

Откройте среду Jupyter Lab из Vertex AI или воспользуйтесь редактором оболочки и создайте файл training.py . Вы можете изменить имя, конечно.

Начнем с импорта и некоторых констант для инициализации AI Platform.

PROJECT_NAME: название вашего проекта
BUCKET_NAME: имя вашей корзины Google Cloud Storage для сохранения метаданных обучения или сохранения моделей
REPOSITORY_NAME : название вашего репозитория Google Cloud Artifact Registry Docker
РАСПОЛОЖЕНИЕ: с чего следует начать обучение и настройку? Если вы следовали предыдущим частям, это должно быть europe-west4 . Поскольку все части обучения будут проходить в одном и том же регионе, все будет происходить быстрее и с меньшей задержкой.
IMAGE_URI: URI используемого образа док-станции для обучения
TIMESTAMP. : мы будем использовать это при присвоении названий должностям для обучения и настройки моделей.

Чтобы создать HyperparameterTuningJob, нам нужно сначала создать CustomJob.

Объект CustomJob требует 3 параметра: display_name , project_name и worker_pool_specs . Первые два настраиваются очень просто. Последний по-прежнему прост, но он длиннее.

Каждый рабочий пул должен установить три параметра. machine_spec , container_spec и replica_count .

машина_спецификация

Какую машину вы хотите использовать для рабочих в вашем пуле рабочих? Хотите ли вы использовать GPU в своих воркерах, какой и сколько? Для выбора подходящего типа машины и типа GPU смотрите здесь.

Я разорился и использую бесплатную пробную версию GCP. Поэтому я выбираю базовую машину без GPU :)

container_spec

Какой контейнер вы хотите использовать для своих воркеров? И какие аргументы командной строки вы хотите добавить в свой контейнер? Мы завершили наш dockerfile, используя ENTRYPOINT, помните? Теперь вы можете видеть, что причина в том, что мы хотим «добавить» эти аргументы в контейнер.

worker_pool_specs

Обратите внимание, что это не словарь, это список словарей! Он может иметь не более 4 элементов, и каждый элемент имеет свою ответственность. Непосредственно из источника:

Рабочий пул 0 настраивает основной, главный, планировщик или «главный». В MultiWorkerMirroredStrategy все машины обозначаются как рабочие, то есть физические машины, на которых выполняются реплицированные вычисления. В дополнение к тому, что каждая машина является рабочей, должен быть один рабочий, который берет на себя дополнительную работу, такую как сохранение контрольных точек и запись сводных файлов в TensorBoard. Эта машина известна как главный. Существует только один главный рабочий, поэтому счетчик рабочих для пула рабочих 0 всегда будет равен 1.

Вы можете добавить графические процессоры, но имейте в виду, что для MultiWorkerMirroredStrategy каждая машина в вашем кластере должна иметь одинаковое количество графических процессоров. Добавление графических процессоров также увеличит стоимость обучения.

И рабочий пул 1 — это место, где вы настраиваете рабочих для своего кластера.

Рабочий пул 2 предназначен для ParameterServerStrategy, и если вы хотите добавить оценщика, вы должны добавить рабочий пул 3.

Теперь, когда мы установили рабочие пулы 0 и 1, мы настроили три машины только с ЦП. При запуске кода обучающего приложения MultiWorkerMirroredStrategy распределяет обучение между обеими машинами.

ГиперпараметрТунингДжоб

Теперь мы подошли к легкой части!

Я думаю, что этого мема достаточно, чтобы рассказать, что мы здесь делали! :) Хочу добавить одно пояснение по поводу scale параметров.

Линейная шкала: как правило, вы выбираете этот вариант, если диапазон всех значений от самого низкого до самого высокого относительно мал (в пределах одного порядка величины), потому что однородный поиск значений из диапазона даст вам разумное исследование всего диапазона.

Логарифмическая шкала: логарифмическая шкала работает только для диапазонов, значения которых больше 0.

Выберите логарифмическое масштабирование при поиске в диапазоне, охватывающем несколько порядков. Например, если вы настраиваете модель и указываете диапазон значений от 0,0001 до 1,0 для гиперпараметра learning_rate, равномерный поиск в логарифмическом масштабе дает лучшую выборку всего диапазона, чем поиск в линейном масштабе. потому что при поиске по линейной шкале в среднем 90 процентов вашего бюджета на обучение будет потрачено только на значения от 0,1 до 1,0, а на значения от 0,0001 до 0,1 останется только 10 процентов вашего бюджета на обучение.

Обратное логарифмическое масштабирование: обратное логарифмическое масштабирование поддерживается только для непрерывных диапазонов гиперпараметров. Он не поддерживается для целочисленных диапазонов гиперпараметров.

Обратное логарифмическое масштабирование работает только для диапазонов, полностью лежащих в диапазоне 0‹=x‹1,0.

Выбирайте обратное логарифмическое масштабирование при поиске в диапазоне, который очень чувствителен к небольшим изменениям, очень близким к 1.

Чтобы узнать больше о весах, вы можете посмотреть здесь, здесь и, наконец, здесь.

max_trial_count: сколько различных значений я должен попробовать?

parallel_trial_count: сколько пробных версий я должен попробовать одновременно? Важным моментом здесь является то, что вам нужно сделать это число небольшим, например, 3. Потому что Vertex AI использует байесовскую оптимизацию, которая использует предыдущие испытания, чтобы выбрать лучшие гиперпараметры, чтобы попробовать дальше.

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

Теперь, когда мы получили наилучшие параметры от theHyperparameterTuningJob, мы можем приступить к обучению. На этот раз мы будем использовать данные поезда + проверки.

Во-первых, мы создали CustomContainerTrainingJob, который позволяет нам создавать обучающие задания с использованием контейнеров. Мы отдаем наш учебный образ container_uri и устанавливаем образ развертывания, подготовленный самим Vertex AI. Существуют более быстрые образы для развертывания вашей модели, созданные Vertex AI, но это тема для другой статьи.

Перед запуском задания мы устанавливаем для параметра «hp» значение False и добавляем лучшие гиперпараметры в аргументы модели. Мы устанавливаем 3 в качестве количества реплик, и само задание автоматически создаст для нас 1 шеф-повара и 2 рабочих.

replica_count (int):
количество рабочих реплик. Если число реплик равно 1, будет предоставлена одна главная
реплика. Если replica_count › 1, остальные будут
предоставлены в качестве пула рабочих реплик.

После завершения обучения мы получим объект Model, который мы можем использовать для получения информации о модели, запуска пакетного прогнозирования или развертывания в конечной точке. Теперь пришло время развернуть нашу модель и получить прогнозы.

Это довольно легко, верно? По сути, мы выбираем тип машины и вызываем deploy(), что дает нам объект Endpoint. Затем мы загружаем токенизатор из нашего обучающего кода, токенизируем текст и получаем прогноз, заключая его в список и передавая в качестве параметра predict().

Вот и все! После 3-х частей нам удалось настроить, обучить и обслужить модель Huggingface Transformers! Следующим шагом должно быть разделение всех компонентов на функции и их развертывание в виде конвейера Kubeflow.

Надеюсь, вам понравится читать эту серию статей!