Введение
TensorFlow — это система обучения искусственного интеллекта второго поколения, разработанная Google, которая может обрабатывать различные модели алгоритмов глубокого обучения и известна своими мощными функциями и высокой масштабируемостью. TensorFlow является полностью открытым исходным кодом, поэтому его используют многие компании.Однако, когда Meituan Dianping использовала распределенный TensorFlow для обучения моделей WDL, выяснилось, что скорость обучения очень низкая, и его трудно удовлетворить потребностям бизнеса.
После анализа и позиционирования фреймворка TensorFlow и Hadoop было обнаружено, что узкие места производительности возникают в аспектах ввода данных, кластерной сети и распределения вычислительной памяти. Основные причины включают низкую эффективность интерфейса ввода данных TensorFlow, плохую стратегию распределения операторов PS/Worker и необоснованную настройку параметров Hadoop. После настройки вызова интерфейса TensorFlow и оптимизации конфигурации системы производительность обучения модели WDL была улучшена в 10 раз, а распределенное линейное ускорение может достигать 32 рабочих, что в основном соответствует потребностям Meituan Dianping, рекламы и рекомендаций. Сервисы.
срок
TensorFlow — платформа глубокого обучения с открытым исходным кодом, выпущенная Google.
OP — Аббревиатура операции, оператор TensorFlow
PS — сервер параметров сервера параметров
WDL - Wide & Deep Learning, модель алгоритма глубокого обучения, выпущенная Google для сценариев рекомендаций
AFO — сокращение от AI Framework on YARN — структура планирования глубокого обучения, разработанная на основе YARN и поддерживающая такие среды глубокого обучения, как TensorFlow и MXNet.
Введение в распределенную архитектуру TensorFlow
Чтобы решить проблему расчета модели и обновления параметров с массивными параметрами, TensorFlow поддерживает распределенные вычисления. Подобно практике других сред глубокого обучения, распределенный TensorFlow также представляет сервер параметров (Parameter Server, PS) для сохранения и обновления параметров обучения, а обучение модели завершается на рабочем узле.
TensorFlow поддерживает режимы параллели графа (внутри графа) и параллели данных (между графами), а также синхронные и асинхронные обновления. Поскольку in-graph вводит и распределяет данные только на одном узле, что серьезно влияет на скорость параллельного обучения, Inter-graph обычно используется в реальных производственных средах. При синхронном обновлении рабочий узел должен быть главным, чтобы контролировать, все ли рабочие вступают в следующий раунд итерации, и отвечает за вывод контрольных точек. Все воркеры равны при асинхронном обновлении, процесс итерации не контролируется синхронным барьером, а процесс обучения проходит быстрее.
Архитектурный дизайн АФО
TensorFlow — это всего лишь вычислительная среда, без функций управления ресурсами кластера и планирования, а распределенному обучению также не хватает способности отказоустойчивости кластера. Чтобы решить эти проблемы, мы разработали фреймворк AFO на основе YARN для решения этой проблемы. Особенности архитектуры AFO:
- Высокая масштабируемость, PS и Worker являются задачами, а роли можно настраивать
- Отказоустойчивая конструкция на основе конечного автомата
- Предоставляет службу журнала и службу Tensorboard, чтобы облегчить пользователям поиск проблем и отладку моделей.
Описание модуля АФО:
- Мастер приложений: используется для управления ресурсными приложениями для всего кластера TensorFlow и отслеживания состояния задач.
- Дочерний элемент AFO: исполнительный механизм TensorFlow, отвечающий за PS, управление временем выполнения Worker и синхронизацию состояний.
- Сервер истории: управление журналами, созданными в ходе обучения TensorFlow.
- Клиент AFO: Пользовательский клиент
WDL-модель
В рекомендательной системе и сценариях оценки CTR выборочные данные для обучения обычно представляют собой запрос, пользовательскую и контекстную информацию, и система возвращает отсортированный список кандидатов. Основная проблема, стоящая перед рекомендательной системой, заключается в том, как добиться способности памяти и способности модели к обобщению одновременно.Идея, предложенная WDL, состоит в том, чтобы объединить линейные модели (широкие, для памяти) и глубокие нейронные сети (глубокие, для обобщения). ). В качестве примера возьмем модель WDL, используемую в системе рекомендаций Google Play Store в документе.Модель вводит доступ пользователя к журналу магазина приложений, информацию о пользователе и устройстве, оценивает приложение и выводит список «интересных» приложений для Пользователь.
Среди них такие функции, как установленные приложения и приложения для показов, разрежены (в огромном пространстве приложений интересует только небольшая часть пользователя), что соответствует «широкой части» модели, подходит для использования линейного модель; в «глубокой части» части модели разреженные признаки не подходят для обработки нейронной сетью из-за их большой размерности и должны быть встроены для уменьшения размерности и преобразования их в плотные признаки, которые затем объединяются с другими плотные функции и вход в трехслойную глубокую сеть ReLU. Наконец, результаты прогнозирования Wide и Deep взвешиваются и вводятся в функцию логистических потерь (например, Sigmoid). Модель WDL включает вычисление встраивания для разреженных признаков.Соответствующий интерфейс в TensorFlow — tf.embedding_lookup_sparse, но OP, содержащийся в этом интерфейсе, не может быть ускорен GPU и может быть рассчитан только на CPU, поэтому TensorFlow имеет низкую производительность при обработке разреженных признаков. Мало того, мы обнаружили, что распределенный TensorFlow будет вызывать большой объем трафика передачи по сети при выполнении вычислений встраивания, что серьезно влияет на производительность обучения.
Анализ и настройка узких мест производительности
При обучении моделей WDL с помощью TensorFlow мы в основном обнаружили 3 проблемы с производительностью:
- Во время каждого раунда обучения канал ввода данных занимает слишком много времени, и более 60% времени уходит на чтение данных.
- Сетевой трафик, генерируемый во время обучения, высок, занимает много ресурсов пропускной способности сети кластера, и трудно добиться линейного ускорения распределенной производительности.
- Конфигурация параметров Hadoop по умолчанию приводит к тому, что glibc malloc работает медленно, а спин-блокировка ядра, защищающая пул памяти malloc, становится узким местом производительности.
Узкое место входных данных TensorFlow
TensorFlow поддерживает конвейерный ввод обучающих данных. Как показано на рисунке ниже, типичный конвейер входных данных состоит из двух очередей: очередь имен файлов перемешивает набор файлов, а несколько потоков чтения получают имена файлов из этой очереди, считывают обучающие данные, а затем проходят процесс декодирования для поместите данные в очередь примеров, чтобы обучающий поток считывал данные. Многопоточная конструкция Pipeline с несколькими очередями может сделать поток обучения и поток чтения данных параллельными. В идеале очередь Example Queue всегда заполнена данными, и обучающий поток может прочитать следующий пакет данных сразу после завершения раунда обучения. Если очередь примеров всегда «голодает», поток обучения должен будет заблокироваться, ожидая, пока поток чтения вставит достаточно данных в очередь примеров. Используя инструмент временной шкалы TensorFlow, вы можете визуально увидеть процесс вызова OP.
Чтобы использовать временную шкалу, вам нужно добавить следующие строки кода в tf.Session.run():
with tf.Session as sess:
ptions = tf.RunOptions(trace_level=tf.RunOptions.FULL_TRACE)
run_metadata = tf.RunMetadata()
_ = sess.run([train_op, global_step], options=run_options, run_metadata=run_metadata)
if global_step > 1000 && global_step < 1010:
from tensorflow.python.client import timeline
fetched_timeline = timeline.Timeline(run_metadata.step_stats)
chrome_trace = fetched_timeline.generate_chrome_trace_format()
with open('/tmp/timeline_01.json', 'w') as f:
f.write(chrome_trace)
Таким образом, когда глобальный шаг составляет около 1000 раундов, информация о временной шкале этого раунда обучения будет сохранена в файле timeline_01.json, введите chrome://tracing в адресной строке браузера Chrome, а затем загрузите файл, вы можете увидеть результаты графического профилирования. Хронология бизнес-модели показана на рисунке:
Видно, что OP QueueDequeueManyV2 занимает больше всего времени, составляя более 60% от общей задержки. Анализируя исходный код TensorFlow, мы делаем вывод о двух причинах: (1) Поток Reader — это поток Python, на который распространяется глобальная блокировка интерпретаций Python (GIL), и поток Reader не получает достаточного планирования выполнения во время обучения; (2) Функция интерфейса Reader по умолчанию, TFRecordReader.read, считывает только один фрагмент данных за раз.Если размер пакета относительно велик, интерфейс необходимо часто вызывать для чтения данных пакета, а системные накладные расходы высокий; Для первой проблемы решение заключается в использованииИнтерфейс набора данных TensorFlow, этот интерфейс больше не использует потоки Python для чтения данных, а реализован потоками C++, что позволяет избежать проблемы Python GIL. По второму вопросу сообщество предоставляет интерфейс пакетного чтения данных TFRecordReader.read_up_to, в котором каждый раз можно указывать количество считываемых данных. Ставим каждый раз считывать 1000 кусков данных, чтобы частота вызова интерфейса чтения-предложения снизилась с 10000 до 10 раз, а задержка обучения на раунд уменьшилась в 2-3 раза.
Видно, что после настройки QueueDequeueManyV2 занимает всего десять миллисекунд, а задержка обучения на раунд уменьшается с более чем 800 миллисекунд до менее чем 300 миллисекунд.
Узкое место сети кластера
Несмотря на то, что использовалась сетевая карта Mellanox 25G, в процессе обучения WDL мы заметили, что восходящий и нисходящий сетевой трафик на Worker сильно дрожали с амплитудой 2–10 Гбит/с, что было вызвано потерей пакетов из-за полной пропускной способности сети PS. . Поскольку все распределенные параметры обучения сохраняются и обновляются на PS, параметров слишком много, модельная сеть неглубокая, а вычисления выполняются быстро, легко создать ситуацию, когда несколько рабочих играют на одном PS, что приводит к тому, что сеть пропускная способность интерфейса PS ограничена полная. В WDL-модели рекомендательного бизнеса масштаб параметров тензора встраивания составляет десятки миллионов.Интерфейс tf.embedding_lookup_sparse TensorFlow содержит несколько ОП, которые по умолчанию размещаются на PS и Worker. Как показано на рисунке, цвет представляет устройство, и поиск внедрения должен передавать всю переменную внедрения перед различными устройствами, что означает, что каждый раунд итеративного обновления внедрения должен передавать большое количество параметров туда и обратно между PS и рабочий.
Чтобы эффективно уменьшить сетевой трафик, попробуйте выполнить обновление параметров на одном устройстве, т.е.
with tf.device(PS):
do embedding computing
Сообщество предоставляет метод интерфейса, который реализован в соответствии с этой идеей:embedding_lookup_sparse_with_distributed_aggregation интерфейс, этот интерфейс может поместить ОП, используемый при расчете встраивания, на ПС, где находится переменная, преобразовать его в плотный тензор после расчета, а затем отправить его в Worker для продолжения расчета сетевой модели. Как видно из рисунка ниже, OP, участвующие в расчете встраивания, все находятся на PS, а восходящий и нисходящий сетевой трафик тестового воркера также стабилен на нормальном значении 2-3Gpbs.
Узкое место производительности UniqueOP на PS
При использовании распределенного TensorFlow для запуска алгоритма WDL, рекомендованного рекламой, я обнаружил странное явление: производительность алгоритма WDL на AFO составляет всего 1/4 от производительности ручного распределения. Распределение вручную означает, что задания PS и Worker запускаются в кластере отдельно в режиме командной строки, не полагаясь на планирование YARN. Используя Perf для диагностики горячих точек процесса PS, было обнаружено, что многопоточность PS конкурирует за спин-блокировку ядра, а PS в целом тратит 30-50% процессорного времени на спин-блокировку malloc в ядре.
При дальнейшем рассмотрении стека процессов PS обнаруживается, что конкурирующая спин-блокировка ядра исходит из системного вызова, связанного с malloc. Embedding_lookup_sparse WDL будет использовать оператор UniqueOp. TensorFlow поддерживает многопоточность OP. UniqueOp откроет многопоточность при вычислениях и вызовет malloc glibc для обращения к памяти во время выполнения потока. После тестирования и исследования было обнаружено, что Hadoop имеет конфигурацию переменной среды по умолчанию:
export MALLOC_ARENA_MAX="4"
Эта конфигурация означает ограничение количества пулов памяти glibc, которые может использовать процесс, до 4. Это означает, что когда процесс запускает многопоточность для вызова malloc, он будет конкурировать за приложения из 4 пулов памяти, что ограничивает количество параллельных исполнений потоков, вызывающих malloc, до 4. Ознакомьтесь с сообществом HadoopСвязанное обсуждение, основная причина добавления этой конфигурации в начале заключается в том, что обновление glibc приносит функцию многопоточной ARENA, которая может улучшить параллельную производительность malloc, а также увеличить виртуальную память процесса (т.е. VIRT в верхней части результат). YARN управляет виртуальной и физической памятью, используемой деревьями процессов, и деревья процессов, которые превышают лимит, будут уничтожены. После изменения параметра MALLOC_ARENA_MAX по умолчанию на 4 VIRT не сильно увеличится, и общая производительность работы не будет существенно затронута. Однако эта конфигурация по умолчанию оказывает большое влияние на задания глубокого обучения WDL.Мы удалили эту конфигурацию среды, и производительность параллелизма malloc была значительно улучшена. После тестирования среднее время обучения модели WDL снижается до 1/4 от исходного.
Результаты настройки
Примечание. Следующие тесты удаляют конфигурацию Hadoop MALLOC_ARENA_MAX по умолчанию.
Мы провели сравнительный тест до и после настройки производительности бизнес-модели WDL на AFO.Параметры тестовой среды следующие: Модель: Рекомендуемая рекламная модель WDL ОС: CentOS 7.1 Процессор: Xeon E5 2.2G, 40 ядер Графический процессор: Nvidia P40 Диск: Локальный вращающийся диск Сетевая карта: Mellanox 25G (без использования RoCE) Версия TensorFlow: выпуск 1.4 CUDA/cuDNN: 8.0/5.1
Видно, что после настройки производительность обучения улучшается в 2-3 раза, а производительность может достигать линейного ускорения 32 GPU. Это означает, что если используются одни и те же ресурсы, время бизнес-обучения будет меньше или будет сохранено больше ресурсов при определенных требованиях к производительности. Если учитывать фактор оптимизации MALLOC_ARENA_MAX, производительность обучения после настройки улучшается примерно в 10 раз.
Суммировать
Мы используем TensorFlow для обучения модели WDL, чтобы найти некоторые узкие места производительности в системе Целевая настройка может не только значительно ускорить процесс обучения, но и улучшить использование графического процессора, пропускной способности и других ресурсов. В процессе глубокого изучения горячих точек и узких мест системы мы также углубили наше понимание модели бизнес-алгоритма и фреймворка TensorFlow, что имеет значение технических резервов, которые помогут нам в дальнейшем оптимизировать производительность системы. платформу глубокого обучения и лучше предоставлять инженерные технологии для поддержки бизнеса.
об авторе
Чжэн Кун, технический эксперт Meituan Dianping, присоединился к Meituan Dianping в 2015 году и отвечает за исследования и разработку платформы глубокого обучения и платформы Docker.
Набор персонала
Если вы заинтересованы в нашей команде, вы можете следить за нашимистолбец. Мейтуан прокомментировал команду вычислений на GPU, и все таланты могут присоединиться. Пожалуйста, присылайте свое резюме по адресу: zhengkun@meituan.com
исходный адрес:Tickets.WeChat.QQ.com/Yes/bf спросите у TOT In…