Инфраструктура для глубокого обучения ИИ

Опубликовано 12 March 2020

Глубокое обучение - это эмпирическая наука, а качество инфраструктуры группы - это показатель прогресса. К счастью, сегодняшняя экосистема с открытым исходным кодом позволяет любому создать отличную инфраструктуру глубокого обучения.

В этом посте мы расскажем о том, как обычно проводятся исследования с углубленным изучением, опишем выбор инфраструктуры, который мы сделали для его поддержки, а также открытый исходный код kubernetes-ec2-autoscaler, пакетный менеджер масштабирования для Kubernetes. Мы надеемся, что этот пост окажется полезным для создания собственной инфраструктуры глубокого обучения.


Вариант использования


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


Для того, чтобы модель действительно работала, обычно требуется увидеть, как она выходит из строя всеми возможными способами, и найти способы исправить эти ограничения. (Это похоже на создание любой новой программной системы, в которой вы будете многократно запускать свой код для создания интуиции о том, как он ведет себя.)


Таким образом, инфраструктура глубокого обучения должна позволять пользователям гибко анализировать модели, недостаточно просто представлять сводную статистику.


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


Ранний исследовательский процесс не структурирован и быстр, последнее методично и несколько болезненно, но абсолютно необходимо получить отличный результат.



Вам нужно осматривать свои модели с разных сторон, чтобы понять, что они на самом деле изучают. Этот обучающий агент по подкреплению (управляющий правым игроком) от Dario Amodei достигает высокого результата в понге, но когда вы смотрите его игру, вы заметите, что он просто стоит на одном месте.


Пример


Статья «Улучшенные методы обучения GAN» началась с того, что Тим Салиманс разработал несколько идей по улучшению обучения в рамках генерирующей состязательной сети. Мы опишем простейшую из этих идей (которая привела к получению наиболее привлекательных образцов, но не лучшего обучения с неполным контролем).


GAN состоят из генератора и сети дискриминатора. Генератор пытается обмануть дискриминатор, а дискриминатор пытается различить сгенерированные данные и реальные данные. Интуитивно понятно, что генератор, который может обмануть любого дискриминатора, довольно хорош. Но есть трудно исправляемый режим отказа: генератор может «разрушиться», всегда выводя точно один и тот же (вероятно, реалистичный!) Образец.


У Тима была идея предоставить дискриминатору целую мини-серию сэмплов в качестве входных данных, а не только один сэмпл. Таким образом, дискриминатор может сказать, генерирует ли генератор постоянно одно изображение. При обнаружении коллапса градиенты будут отправлены в генератор для устранения проблемы.


Следующим шагом было создание прототипа идеи на MNIST и CIFAR-10. Это потребовало создания прототипа маленькой модели как можно быстрее, запуска ее на реальных данных и проверки результата. После некоторой быстрой итерации Тим получил очень обнадеживающие образцы CIFAR-10 - практически лучшие образцы, которые мы видели в этом наборе данных.


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


Инфраструктура для глубокого обучения ИИ

Модель обучения для создания изображений ImageNet.

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


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


Инфраструктура


Программное обеспечение


Инфраструктура для глубокого обучения ИИ

Пример  кода TensorFlow.


Подавляющее большинство этого исследовательского кода написано на Python, что отражено в  проектах OpenAI с открытым исходным кодом. В основном OpenAI использует TensorFlow (или Theano в особых случаях) для вычислений на GPU; для процессора используют те или Numpy. Исследователи также иногда используют высокоуровневые фреймворки, такие как Keras, поверх TensorFlow.


Как и большая часть сообщества глубокого обучения, OpenAI использует Python 2.7. Обычно они используют Anaconda, которая имеет удобную упаковку для других сложных пакетов, таких как OpenCV, и оптимизацию производительности для некоторых научных библиотек.


Аппаратные средства 

Для идеального пакетного задания удвоение количества узлов в кластере уменьшит время выполнения задания вдвое. К сожалению, при глубоком обучении люди обычно видят очень сублинейные ускорения от многих графических процессоров. Таким образом, для максимальной производительности требуются высокопроизводительные графические процессоры. Мы также используем довольно много ЦП для симуляторов, сред обучения с подкреплением или для небольших моделей (которые не работают на GPU быстрее).


Инфраструктура для глубокого обучения ИИ

Nvidia-smi показывает полностью загруженный Titan Xs.

AWS щедро согласился пожертвовать нам большое количество вычислений. Мы используем их для экземпляров ЦП и для горизонтального масштабирования задач графического процессора. Мы также используем собственные физические серверы, в основном на графических процессорах Titan X. Мы ожидаем, что в будущем у нас будет гибридное облако: полезно экспериментировать с различными графическими процессорами, межсоединениями и другими методами, которые могут стать важными для будущего глубокого обучения.


Инфраструктура для глубокого обучения ИИ

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


Снабжение


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


Инфраструктура для глубокого обучения ИИ

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


Мы используем Terraform для настройки наших облачных ресурсов AWS (экземпляров, сетевых маршрутов, записей DNS и т. Д.). Наши облачные и физические узлы работают под управлением Ubuntu и настроены с помощью Chef. Для более быстрого запуска мы предварительно выпекаем наши кластерные AMI с помощью Packer. Все наши кластеры используют не пересекающиеся диапазоны IP-адресов и соединены через общедоступный Интернет с OpenVPN на пользовательских ноутбуках и strongSwan на физических узлах (которые действуют как клиентские шлюзы AWS).


Мы храним домашние каталоги людей, наборы данных и результаты в NFS (на физическом оборудовании) и EFS / S3 (в AWS).


Оркестровка


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


Мы предоставляем кластер узлов SSH (как с графическими процессорами, так и без них) для специальных экспериментов и запускаем Kubernetes в качестве нашего планировщика кластеров для физических узлов и узлов AWS. Наш кластер охватывает 3 региона AWS - наши рабочие места достаточно загружены, поэтому иногда мы можем ограничить возможности в отдельных регионах.


Kubernetes требует, чтобы каждое задание было контейнером Docker, что дает нам изоляцию зависимостей и моментальный снимок кода. Однако создание нового контейнера Docker может добавить драгоценные дополнительные секунды к циклу итерации исследователя, поэтому мы также предоставляем инструменты для прозрачной отправки кода с ноутбука исследователя в стандартное изображение.


Инфраструктура для глубокого обучения ИИ

Модельные кривые обучения в TensorBoard.

Мы выставляем фланелевую сеть Kubernetes непосредственно на ноутбуки исследователей, предоставляя пользователям беспрепятственный доступ к сети для выполнения своих рабочих мест. Это особенно полезно для доступа к службам мониторинга, таким как TensorBoard. (Наш первоначальный подход, который является более чистым с точки зрения строгой изоляции, требовал, чтобы люди создавали сервис Kubernetes для каждого порта, который они хотели выставить, но мы обнаружили, что он добавил слишком много трений.)


kubernetes-ec2-autoscaler


Наша рабочая нагрузка взрывоопасна и непредсказуема: направление исследований может быстро перейти от экспериментов на одной машине до потребности в 1000 ядер. Например, в течение нескольких недель один эксперимент перешел от интерактивной фазы на одном Titan X к экспериментальной фазе на 60 Titan X и потребовал почти 1600 графических процессоров AWS. Таким образом, наша облачная инфраструктура должна динамически предоставлять узлы Kubernetes.


Узлы Kubernetes легко запускать в группах автоматического масштабирования, но сложнее правильно управлять размером этих групп. После отправки пакетного задания кластер точно знает, какие ресурсы ему нужны, и должен выделять их напрямую. (В отличие от этого, политики масштабирования AWS будут раскручивать новые узлы по частям до тех пор, пока ресурсы не будут исчерпаны, что может занять несколько итераций.) Кроме того, кластеру необходимо опустошить узлы перед их завершением, чтобы избежать потери рабочих мест в полете.


Соблазнительно просто использовать сырой EC2 для больших пакетных заданий, и именно там мы начали. Однако экосистема Kubernetes добавляет довольно большую ценность: инструменты с низким коэффициентом трения, ведение журналов, мониторинг, возможность управлять физическими узлами отдельно от запущенных экземпляров и тому подобное. Правильно сделать автоматическое масштабирование Kubernetes было проще, чем перестроить эту экосистему на сырой EC2.


Мы выпускаем kubernetes-ec2-autoscaler, пакетный менеджер для масштабирования для Kubernetes. Он работает как обычный Pod в Kubernetes и требует только, чтобы ваши рабочие узлы были в группах автоматического масштабирования.


Инфраструктура для глубокого обучения ИИ

Конфигурации запуска для кластера Kubernetes.


Автоскейлер работает путем опроса состояния мастера Kubernetes, в котором содержится все необходимое для вычисления запроса и емкости ресурса кластера. Если есть избыточная емкость, она истощает соответствующие узлы и в конечном итоге завершает их. Если требуется больше ресурсов, он рассчитывает, какие серверы должны быть созданы, и соответственно увеличивает размеры вашей группы автоматического масштабирования (или просто отменяет сброс израсходованных узлов, что позволяет избежать ускорения нового узла).


kubernetes-ec2-autoscaler обрабатывает несколько групп автоматического масштабирования, ресурсы за пределами ЦП (память и графические процессоры) и детальные ограничения для ваших заданий, такие как регион AWS и размер экземпляра. Кроме того, взрывные рабочие нагрузки могут привести к тайм-аутам и ошибкам групп автоматического масштабирования, поскольку (что удивительно!) Даже AWS не имеет бесконечной емкости. В этих случаях kubernetes-ec2-autoscaler обнаруживает ошибку и переполняется во вторичный регион AWS.


Инфраструктура OpenAI направлена на максимизацию производительности труда исследователей глубокого обучения, что позволяет им сосредоточиться на науке.