Назад к основам: переосмысление передового опыта разработки в эпоху облачных вычислений
Мои предыдущие посты были в основном техническими, охватывающими ряд тем по обучению в облаке и расширенной разработке TensorFlow. Это другой пост. Возможно, вы сочтете это скорее выражением мнения.
В течение своей карьеры я редко видел, чтобы напряжение становилось сильнее, чем при обсуждении темы практики разработки программного обеспечения. Даже самый интровертный инженер внезапно оживает. Сверстники, которые в остальном работают в унисон, вступят в жаркие споры. Я работал с ковбойскими программистами и мастерами Scrum, с людьми, которые приняли Agile как образ жизни, и с другими людьми, которые скорее бросят курить, чем участвуют даже в еще одной стендап-встрече, с людьми, которые извлекают выгоду из своей жизни. имена сотрудников и другие лица, которые сочли бы такую практику преступлением, караемым смертной казнью.
По правде говоря, наиболее распространенные методы разработки основаны на твердом здравом смысле. Хотя разработчики могут серьезно относиться к тому, следует ли и как применять Scrum, здравый смысл заключается в том, что современные команды разработчиков должны иметь возможность быстро адаптироваться к меняющейся среде. Хотя конкретные детали могут быть оспорены, для команд разумно принять стиль кодирования, чтобы повысить удобочитаемость и ремонтопригодность кода. Хотя разработка через тестирование может показаться ошеломляющей, введение тестирования на разных уровнях и на разных этапах разработки является здравым смыслом. При работе в команде выполнение непрерывной интеграции, включая автоматическое интеграционное тестирование, является здравым смыслом. Даже лучшие разработчики иногда делают ошибки, и ловить их до того, как они попадут в главный репозиторий и в конечном итоге испортят всем, - это здравый смысл. Проведение коллегиальных обзоров кода является здравым смыслом и может просто предотвратить небольшие упущения, такие как утечка памяти или переполнение типа данных, от разрушения вашей компании.
Never underestimate the capacity of a person, no matter how stupid, to do something genius. More importantly, never underestimate the capacity of a person, no matter how genius, to do something monumentally stupid. --Chaim Rand
Другое утверждение, глубоко укоренившееся в здравом смысле, состоит в том, что наши привычки разработки должны быть адаптированы к деталям проекта, над которым мы работаем, включая команду, сроки и, что немаловажно, среду разработки. Это верно, в частности, при обучении моделей машинного обучения в облаке.
Преимущества Cloud ML
Наблюдается растущая тенденция к обучению моделей машинного обучения в облаке, при этом поставщики облачных услуг развертывают постоянно расширяющиеся услуги практически для любой задачи, связанной с машинным обучением, которую вы можете себе представить. Нетрудно увидеть привлекательность обучения в облаке.
Создание современной инфраструктуры машинного обучения может быть трудным. Во-первых, это аппаратная инфраструктура. Графические процессоры и альтернативные ускорители машинного обучения дороги, и если вы хотите быть в курсе последних и лучших, вам нужно будет регулярно их обновлять. Поскольку вы, возможно, захотите распределить свое обучение по нескольким машинам и, вероятно, захотите проводить более одного обучающего эксперимента одновременно, вам, вероятно, понадобится несколько графических процессоров с различными характеристиками. Для машинного обучения обычно требуется сложная и масштабируемая инфраструктура хранения для хранения постоянно расширяющихся наборов данных, а также сетевая инфраструктура, поддерживающая большой объем трафика между хранилищем данных и обучающими машинами.
Затем есть программная инфраструктура. Чтобы ваше обучение могло работать, потребуется соответствующая настройка BIOS, регулярное обновление драйверов, сложное управление разрешениями доступа и тщательная настройка переменных среды. Обычно вам потребуется длинный список программных пакетов, которые могут иметь конфликтующие зависимости, которые вам нужно будет устранить. Вам может потребоваться Docker или какой-либо другой уровень виртуализации, что создаст целый ряд новых потенциальных проблем.
С другой стороны, когда вы тренируетесь в облаке, жизнь проста. Оборудование, хранилище, сетевая и программная инфраструктуры настроены и готовы к работе. У вас есть широкий выбор графических процессоров (и других ускорителей), а также различные типы и версии программных фреймворков. В облаке вы можете свободно масштабироваться, чтобы проводить столько параллельных экспериментов, сколько душе угодно, а также масштабировать независимые тренировки для параллельной работы на многих ядрах графического процессора (или других ускорителях). Емкость хранилища в облаке практически безгранична, что избавляет вас от головной боли, связанной с постоянно растущими требованиями к хранилищу. Кроме того, облачные предложения часто включают уникальные оптимизации, основанные на их собственном оборудовании или топологии сети. Создание собственной рентабельной инфраструктуры с такой же гибкостью и сложностью, что и в облаке, практически непостижимо для всех, кроме крупнейших организаций, которые уже управляют своими собственными центрами обработки данных. См. Здесь, чтобы узнать больше о преимуществах и проблемах переноса обучения в облако.
Затраты на управление
Хотя стоимость может быть одним из основных факторов, влияющих на использование облачных сервисов машинного обучения, легко увидеть, как без надлежащего управления стоимость также может стать основной ловушкой. Я считаю, что в ДНК каждого разработчика заложена врожденная склонность к самым большим, новейшим, самым быстрым и мощным вычислительным ресурсам. Если мы можем использовать мощный (и дорогой) графический процессор (или другой ускоритель), зачем соглашаться на более дешевый? Если мы можем распределить наше обучение по 1024 ядрам, зачем довольствоваться 8? Если мы можем проводить 1000 экспериментов параллельно, зачем ограничиваться четырьмя? И если мы можем проводить тренировки в течение 20 дней, зачем ограничиваться одним?
Очевидно, что для того, чтобы переход к облаку был успешным, менеджеры должны установить четкую политику в отношении того, как и когда использовать различные облачные сервисы. Следует определить руководящие принципы, включая такие детали, как количество и типы обучающих ресурсов, которые следует использовать, продолжительность сеансов обучения, когда платить полную цену за облачные ресурсы, а когда использовать более дешевые ресурсы с низким приоритетом, такие как точечные экземпляры или вытесняемые виртуальные машины (риск преждевременного завершения задания). Следует отслеживать шаблоны использования и вносить постоянные корректировки для максимальной производительности.
Хотя определение и обеспечение соблюдения таких политик входит в обязанности руководства, мы, разработчики, обязаны адаптировать наши процессы разработки к новой эре инженерии. Нам необходимо скорректировать наши привычки, чтобы максимально использовать облачные ресурсы и минимизировать потери, время простоя и недоиспользование ресурсов.
Привычки развития для повышения продуктивности обучения в облаке
Чтобы добиться максимальной эффективности, я хотел бы предложить 6, здравый смысл, методов разработки, на которые, как я считаю, следует обратить внимание при обучении моделей машинного обучения в облаке.
1. Протестируйте локально перед запуском в облаке.
Как мы все знаем, приложения, которые мы пишем, почти никогда не запускаются так, как мы предполагали, прямо из коробки. Чаще всего мы обращаемся к неопределенной переменной, используем неправильный тип данных, получаем доступ к списку за пределами границ, неправильно используем API и т. Д. Устранение этих недостатков в облаке непродуктивно, отнимает много времени и расточительно. Здравый смысл диктует настройку локальной (на базе ЦП) среды с небольшим подмножеством обучающих данных, в которой вы в максимально возможной степени проверяете, что все работает должным образом.
2. Адаптируйте свои инструменты и методы отладки к облачному обучению.
К сожалению, отладка отказавших приложений в облаке редко сводится к простому запуску предпочитаемой IDE в режиме отладки. В то же время наша способность быстро выявлять и исправлять ошибки в облачных средах может иметь огромное влияние на стоимость и производительность. Здравый смысл требует пересмотра наших процессов отладки и адаптации их к новой парадигме разработки. Необходимо внести изменения в код, чтобы обеспечить быструю воспроизводимость ошибок. Например, сохранение промежуточных контрольных точек модели может сократить время воспроизведения, захват входных тензоров может помочь в определении точной комбинации входных данных и весов, которые привели к ошибке, а также могут помочь специальные флаги отладки для выполнения обучения модели с большей детализацией. определите основную причину проблемы. См. Здесь для получения более подробной информации об эффективной отладке TensorFlow.
3. Проводить непрерывный, всесторонний анализ производительности и оптимизацию.
Чтобы максимально использовать ваши учебные ресурсы, вы должны сделать анализ производительности и оптимизацию неотъемлемой частью вашего процесса разработки. Анализируя скорость, с которой выполняется обучение (измеряемая, например, в итерациях в секунду), и способ, которым мы используем системные ресурсы, мы стремимся определить возможности повышения эффективности и снижения общих затрат. Хотя любой недостаточно используемый обучающий ресурс является потенциальной возможностью для повышения эффективности обучения, это в первую очередь верно для графического процессора (или других ускорителей обучения), как правило, самого дорогого и мощного ресурса в мире. система. Ваша цель должна состоять в том, чтобы попытаться максимально увеличить использование графического процессора.
Типичная стратегия оптимизации производительности включает в себя итеративное выполнение следующих двух шагов, пока вы не будете удовлетворены скоростью обучения и использованием ресурсов:
1. Профилируйте эффективность обучения, чтобы определить узкие места в конвейере и недостаточно используемые ресурсы.
2. Устранение узких мест и повышение эффективности использования ресурсов.
Существует множество различных инструментов и методов для проведения анализа производительности, которые различаются в зависимости от специфики среды разработки. См. Здесь для получения более подробной информации об анализе производительности моделей TensorFlow.
4. Добавьте в код отказоустойчивости.
Представьте, что вы проводите тренировку с высокой степенью распределенности на компьютерах с 32 графическими процессорами в течение двух дней, и только одна из машин выйдет из строя, когда модель, похоже, слилась. Хотя машины также могут выходить из строя в локальной среде обучения, есть две причины, по которым это может быть более серьезной проблемой в облаке. Первое - это более широкое распространение распределенного обучения. Вообще говоря, чем на большем количестве машин мы обучаем, тем более уязвимыми мы становимся к сбоям системы. Вторая причина заключается в том, что одним из наиболее распространенных способов снижения затрат на обучение в облаке является использование низкоприоритетных ресурсов (таких как точечные экземпляры или вытесняемые виртуальные машины), которые склонны к преждевременному запуску. прекращается, если приходит запрос с более высоким приоритетом. Таким образом, введение отказоустойчивости в требования к разработке - это всего лишь здравый смысл.
Первое, что вам следует сделать, это убедиться, что вы периодически делаете снимки (также известные как контрольные точки) своей модели машинного обучения, чтобы в случае преждевременного завершения вы могли возобновить работу с самой последней захваченной модели, а не начинать обучение с нуля. Интервалы для захвата моментальных снимков следует определять путем взвешивания накладных расходов на создание моментального снимка по сравнению с ожидаемым временем обучения, которое вы потеряете в случае сбоя.
Еще одна вещь, которую следует учитывать, - это реализовать механизм восстановления после сбоев отдельных систем без необходимости перезапуска сеанса обучения. Один из способов сделать это в условиях распределенного обучения - использовать Elastic Horovod, который обеспечивает поддержку для динамического масштабирования количества рабочих в зависимости от доступности системы.
5. Выполняйте автоматический мониторинг ваших учебных заданий.
Мониторинг процесса обучения относится к искусству отслеживания различных показателей во время обучения, чтобы оценить, как проходит обучение, и определить, какие гиперпараметры нужно настроить, чтобы улучшить обучение. Хотя мониторинг процесса обучения является важной частью обучения моделям машинного обучения, в целом он особенно важен в облаке, где наша цель - минимизировать потери в максимально возможной степени. Как только мы обнаруживаем неудавшийся тренировочный эксперимент или тренировочную сессию, которая перестала обучаться, наша цель должна заключаться в том, чтобы остановить обучение как можно скорее, чтобы избежать потерь.
Поскольку для нас неразумно отслеживать каждый тренировочный эксперимент в любое время дня, здравый смысл подсказывает, что мы автоматизируем мониторинг везде, где это возможно. Мы можем запрограммировать правила для обнаружения распространенных сбоев обучения, таких как взрывные или исчезающие градиенты, неуменьшение потерь и т. Д., И предпринять соответствующие действия, будь то завершение обучения или корректировка некоторых гиперпараметров.
См. Здесь и здесь для получения дополнительной информации о мониторинге и автоматическом мониторинге в TensorFlow.
6. Адаптируйте передовые методы настройки гиперпараметров
Хотя для успешного обучения обычно требуется настройка гиперпараметров, независимо от места обучения, наше желание минимизировать потери в облаке требует, чтобы мы выполняли эту настройку наиболее экономичным способом. Хотя мы можем согласиться на ручную настройку или настройку поиска по сетке в локальной среде, мы должны стремиться использовать более продвинутые методы в облаке, методы, которые, как было показано, сходятся быстрее и снижают общую стоимость фазы настройки. Опять же, существует ряд решений для настройки гиперпараметров, которые зависят от среды обучения. Постарайтесь выбрать тот, который предлагает поддержку современных, основанных на байесовском алгоритме алгоритма (например, Ray Tune и Amazon SageMaker hyperparameter tuner).
Резюме
Переход к облачным вычислениям - это сдвиг парадигмы, который требует адаптации и ужесточения наших процессов разработки с целью повышения производительности и эффективности. Хотя детали, безусловно, будут меняться от команды к команде и от проекта к проекту, основные принципы - это здравый смысл. Успех в наших руках.
