Как Мы Запускали Программу Deep Learning

Хабр, здравствуйте.

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

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

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

Microsoft Azure серии N

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

Примерно в то же время Microsoft Azure объявила, что их платформа появилась в формате предварительного просмотра виртуальных машин GPU .

Для нас это была хорошая новость, потому что на нашем основная программа Согласно большим данным, Microsoft является инфраструктурным партнером.

Идея была не создавать зоопарк, а в конце ноября просто использовать их готовое решение (не превью).

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

Мы столкнулись с тем, что нам срочно нужно было искать что-то другое.

IBM Блюмикс

Чуть позже нам удалось быстро договориться о сотрудничестве в этой области с облачной платформой на базе IBM Bluemix Infrastructure (ранее Softlayer), и IBM стала нашим инфраструктурным партнером в этой программе.

Увы, не обошлось и без подводных камней.

Впервые на ходу мы познакомились с возможностями IBM Bluemix. Изначально мы ожидали, что получим готовые виртуальные машины с графическими процессорами для каждого из участников.

Но так как на Bluemix графические процессоры доступны только в Bare-metal серверах (выделенных физических серверах), которые можно заказать комплектом в нужной конфигурации и получить уже через несколько часов, то в итоге мы получили мощный физический сервер на платформе Supermicro с два процессора Intel Xeon E5 -2690v3, 128 ГБ памяти и с двумя картами NVIDIA Tesla M60 (каждая карта имеет 2 чипа GM204GL поколения Maxwell и 16 ГБ видеопамяти), на которых может быть предустановлен гипервизор по вашему выбору (VMware, Xen или Hyper-V), что тоже очень неплохо! Нам оставалось только разбить это шустрое железо на необходимое количество виртуальных машин и всё.

Но мы не планировали этот этап с самого начала.

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

Для выполнения практической работы участникам нашей программы требовались виртуальные машины с графическими процессорами с поддержкой NVIDIA CUDA и ОС на базе GNU/Linux (чаще всего для наших задач мы используем Ubuntu 14.04 LTS, так как это простая в использовании и достаточно простая система).

распространение при хорошей поддержке сообщества).

Соответственно, в первую очередь необходимо было выбрать платформу виртуализации, которая бы поддерживала либо «проброс» видеокарт в гостевую Linux-систему, либо (что более интересно) поддержку виртуальных графических процессоров для гостевых ОС.

Прежде всего, мы решили рассматривать VMware Vsphere 6 как одно из лидирующих решений на этом рынке.

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

VMware заявляет о поддержке технологии GRID Virtual GPU (vGPU), то есть есть возможность разделить одно ядро видеоадаптера на несколько виртуальных и подключить такой GPU к гостевой системе.

Все достаточно подробно описано в соответствующий документ от Нвидиа.

Эта технология в основном ориентирована на использование в VDI-решениях, требующих ускорения 3D-графики для гостевых систем на базе Windows, что в нашем случае не очень подходит. Если изучить документ от NVidia более детально, то вы узнаете, что при использовании vGPU существует понятие профилей vGPU, то есть, по сути, на сколько vGPU можно разделить одно ядро видеоускорителя.

Профиль vGPU определяет объем выделяемой видеопамяти, максимальное количество поддерживаемых дисплеев и т. д. Таким образом, используя разные профили, можно разбить NVidia Tesla M60 на количество виртуальных машин от 1 до 32. Интересно.

НО! Если вы прочитаете документ еще более подробно, то обнаружите, что поддержка CUDA в гостевых системах Linux доступна только с профилем GRID M60-8Q, который, по сути, представляет собой просто пересылку одного из чипов графического процессора Tesla M60 (помните, что М60 состоит из 2-х микросхем) в одну виртуальную машину.

В результате в любом случае, имея 2 карты Tesla M60 для работы с CUDA, можно получить максимум 4 виртуальные машины для гостевой ОС Linux. Также стоит отметить, что для работы с vGPU требуется дополнительная лицензия от NVidia ( основы здесь ) и для получения драйверов для гипервизора и гостевых систем необходимо получить эти лицензии.

Кроме того, для драйверов в гостевых системах требуется сервер лицензий NVidia, который необходимо устанавливать самостоятельно и поддерживается только операционными системами Windows. Кроме того, vGPU поддерживается только в версии Vsphere 6 Enterprise Plus, которую мы и использовали.

В результате было решено отказаться от vGPU и просто «пробрасывать» видеокарты в гостевые системы, таким образом можно получить 4 виртуальные машины, каждая из которых будет иметь доступ к одному чипу Tesla M60 с 8 ГБ видеопамяти.

vSphere поддерживает PCI-Passthrough, поэтому проблем быть не должно, но они все же появились.

Карты Tesla настроены для передачи в виртуальные машины.

Устройство PCI было добавлено к одной из машин, но при запуске машины появилась ошибка «Идентификатор транзитного устройства PCI недействителен».

Оказалось, что эта проблема проявляется только в веб-интерфейсе vSphere. Если использовать Windows-клиент и снова добавить устройство, то этой проблемы не возникает, а появляется другая, более общая, что-то вроде «запуск ВМ… общая ошибка».

Немного изучив причину возникновения ошибки, мы попробовали различные варианты:

Проверил, включен ли VT-in
Включен ли IOMMU?
Попробовал добавить в файл .
vmx: -firmware="efi" -pciPassthru.use64bitMMIO="ИСТИНА" -efi.legacyBoot.enabled="ИСТИНА" -efi.bootOrder="legacy"

Но все напрасно.

PCI Passthrough нам не помог.

Учитывая, что времени у нас оставалось все меньше и меньше, мы решили прекратить исследования и попробовать Citrix XenServer. Этот гипервизор широко используется для решений VDI. К счастью, из панели управления SoftLayer можно одним щелчком мыши переустановить гипервизор и выбрать XenServer. Стоит отметить, что его автоматическая установка и настройка заняли приличное для платформы Bluemix время (около 8 часов в нашем случае).

Поэтому важно выделить необходимое время для этой процедуры.

Остальная часть истории была довольно скучной; все заработало почти сразу из коробки.

В этом случае была доступна та же опция с режимом Passthrough. Каждый из 4-х чипов GM204GL от двух адаптеров Testa M60 был проброшен в отдельную виртуальную машину, настроена виртуальная сеть, установлены стандартные драйвера NVidia для Tesla M60 под Linux и все запустилось.

Для настройки XenServer удобно использовать Citrix XenCenter; вот как выглядят перенаправленные видеокарты в графическом интерфейсе:

Как мы запускали программу Deep Learning

Так администратор через утилиту nvidia-smi может наблюдать, что процесс Python (участники использовали библиотеки Keras и Caffe) использует большую часть памяти GPU.

Как мы запускали программу Deep Learning

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

В итоге ребята неделю тренировались на g2.2xlarge экземплярах платформы AWS, так как мы не могли себе позволить остаться без необходимого оборудования, и решили дать участникам нарезанные виртуальные машины IBM Bluemix еще на неделю после завершение программы в качестве бонуса, чтобы они могли решать проблемы, связанные с глубоким обучением.

Сравнение AWS и IBM Bluemix

Мы решили сравнить, какое решение эффективнее с точки зрения производительности и стоимости содержания автопарка.

Давайте посчитаем, сколько, например, будут стоить оба варианта, если инфраструктура будет использоваться две недели при 16 участниках.

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

AWS: 0,65 доллара США * 24 часа * 15 дней * 16 участников = 3744 доллара США.

IBM Bluemix: 2961,1 долл.

США в месяц / 2 (2 недели) * 4 = 5 922,2 долл.

США (сервер с 2xM60) ссылка на конфигурацию Или взять эквивалент, близкий к g2.2xlarge: 2096,40 $/месяц / 2(2 недели) * 4 = 4192,8 $ (сервер с 2xK2 (GK104) GPU — аналог AWS) ссылка на конфигурацию В нашей версии разница в деньгах существенная – почти 2 тысячи долларов.

При использовании более современного графического процессора, но производительность во втором случае выше: AWS: 1 графический процессор, 8 ядер, 15 ГБ ОЗУ (GK 104 на базе GRID K520) IBM: 1 графический процессор, 12 ядер, 32 ГБ оперативной памяти (GM 204 на базе M60) Больше ядер, больше памяти, более современный графический процессор нового поколения и еще более высокая производительность.

Мы провели небольшой тест, обучив сеть ЛеНет , распознавая рукописные цифры, используя Caffe на протяжении 10 тысяч итераций.

На виртуальной машине AWS это заняло 45,5 секунды, на виртуальной машине IBM — 26,73 секунды, то есть в 1,7 раза быстрее.

В течение более длительного периода времени это может быть более значительным: 24 часа против 14 часов.

Или за две недели это сэкономило бы 6 дней, которые можно было бы потратить на изучение чего-то другого.

Коллеги из IBM поделились еще одним вариантом использования — потоковой передачей видео.

AWS использовала те же 16 машин g2.2xlarge, а у IBM был только один сервер 2xM-60 для гостевых виртуальных машин Windows. Они были сопоставимы по производительности и обслуживали одинаковое количество видеопотоков.

За те же 2 недели стоимость в IBM составит $1422,72, что более чем на $2000 дешевле конфигурации в AWS. Итак, в зависимости от ваших задач, вам может оказаться более выгодной та или иная конфигурация.

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

Также важно отметить, что графические процессоры поколения Maxwell в настоящее время доступны только на платформе Bluemix. На момент написания статьи у них не было аналогов на других публичных облачных платформах.

Если да, то прямая ссылка на конфигуратор здесь.

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

эти сервисы представляют собой совершенно другой подход. IBM Bluemix больше фокусируется на предоставлении инфраструктурных услуг (Softlayer) и в то же время предлагает своим клиентам услуги Bluemix PaaS (аналитика, большие данные, виртуальные контейнеры и т. д.).

AWS ориентирован на виртуальные сервисы и PaaS на базе гипервизора KVM, а Azure, в свою очередь, ориентирован на весь стек Microsoft. Очевидно, что сравнивать цены на определенные решения от разных поставщиков не совсем справедливо; нужно понимать, что вы получаете за эту цену! Например, если вникнуть в детали и изучить документацию, то окажется, что AWS и Azure берут с клиента деньги за каждое обращение в техподдержку, IBM Bluemix — нет. Если ваши сервисы расположены в разных географически разнесенных дата-центрах, то в случае с Azure и AWS клиент платит за трафик внутри сети дата-центра, а в IBM Bluemix трафик внутри сети для клиентов бесплатен и т. д. Вы можете найдете еще много нюансов в функциональной, практической и юридической плоскости.

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

Результат

Суть в том, что, несмотря на все трудности, с которыми мы столкнулись, первый запуск программы Deep Learning можно считать успешным.

По итогам нашего опроса мы получили следующие результаты: 1. Насколько ваши ожидания от курса совпали с реальностью? По шкале от 1 до 10: 1 - ожидания оправдались не полностью, 10 - курс превзошёл все мои ожидания.

Как мы запускали программу Deep Learning

2. Какой основной результат вы получили от программы?

3. Как вы планируете применять полученные знания и навыки?

4. Насколько вам понравился формат программы: 2 очных дня с лабораторными работами?

Как мы запускали программу Deep Learning

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

На основании этих данных мы считаем первый запуск программы Deep Learning успешным.