Практика оптимизации распределенного обучения TensorFlow в рекомендательных системах

Глубоко настроенная версия Meituan TensorFlow основана на собственной архитектуре и интерфейсе TensorFlow 1.x и была глубоко оптимизирована по нескольким параметрам, таким как поддержка крупномасштабных разреженных параметров, режим обучения, оптимизация распределенной связи, оптимизация конвейера и оптимизация операторов. и слияние. В сценарии рекомендательной системы распределенная масштабируемость была улучшена более чем в 10 раз, а производительность вычислительной мощности устройства также была значительно улучшена, и она широко используется во внутреннем бизнесе Meituan.Эта статья знакомит с соответствующей оптимизацией и практическими Работа.

1. Предпосылки

TensorFlow(далее именуемый TF) — это платформа глубокого обучения с открытым исходным кодом, запущенная Google, которая широко использовалась в сценарии рекомендательной системы Meituan. Однако официальная версия поддержки TensorFlow сценариев промышленного уровня в настоящее время не особенно совершенна. В процессе массового производства компания Meituan столкнулась со следующими проблемами:

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

Вышеуказанные проблемы связаны не с дизайном TensorFlow, а с базовой реализацией. Учитывая привычки использования большого количества предприятий Meituan и совместимость сообщества, мы основываемся на собственной архитектуре и интерфейсе TensorFlow 1.x, начиная с поддержки крупномасштабных разреженных параметров, режима обучения, оптимизации распределенной связи, оптимизации конвейера. , оптимизация и интеграция операторов и т. д. Для решения основной проблемы этой сцены была выполнена многомерная глубокая настройка.

Прежде всего, с точки зрения возможностей поддержки, новая система в настоящее время может обеспечить почти линейное ускорение сотен миллиардов моделей параметров, распределенное обучение тысяч рабочих и полное обучение за один день с выборочными данными в течение года, а также поддерживает онлайн. способности к обучению. В то же время различные архитектуры и интерфейсы новой системы более удобны, и используются все внутренние бизнес-подразделения Meituan, включая Meituan Takeaway, Meituan Select, Meituan Search, Advertising Platform и Dianping Feeds.В этой статье основное внимание будет уделено работе по оптимизации крупномасштабного распределенного обучения., я надеюсь, что это может помочь или вдохновить вас.

2 Крупномасштабные проблемы оптимизации обучения

2.1 Проблемы, связанные с итерацией бизнеса

С развитием бизнеса Meituan масштаб и сложность модели системы рекомендаций также быстро растут.Удельная производительность выглядит следующим образом:

• тренировочные данные: Обучающая выборка выросла с 10 миллиардов до 100 миллиардов, увеличившись почти в 10 раз.
• Разреженный параметр: число увеличилось почти в 10 раз с сотен до тысяч, общее количество параметров увеличилось с сотен миллионов до десятков миллиардов, рост от 10 до 20 раз.
• Сложность модели: Все более усложняясь, время одношагового расчета модели увеличивается более чем в 10 раз.

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

2.2 Анализ нагрузки на систему

2.2.1 Цепочка инструментов анализа проблем

TensorFlow — это очень большой проект с открытым исходным кодом с миллионами строк кода. Индикаторы мониторинга нативной системы слишком грубы и не поддерживают глобальный мониторинг. Трудно найти какие-то сложные узкие места в производительности. На основе системы мониторинга с открытым исходным кодом CAT[2] от Meituan мы построили детальный канал мониторинга для TensorFlow (как показано на рис. 1 ниже), который может точно определить узкие места в производительности.

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

2.2.2 Анализ нагрузки с точки зрения бизнеса

В сценарии системы рекомендаций мы используем режим асинхронного обучения TensorFlow Parameter Server [3] (называемый PS) для поддержки требований распределенного обучения бизнеса. Какие изменения нагрузки принесут вышеупомянутые бизнес-изменения для этой архитектуры? Как показано на рисунке 3 ниже:

Таким образом, это в основном включает нагрузку на связь, нагрузку на параллелизм PS и нагрузку на вычислительные ресурсы рабочих. Для распределенных систем проблема нагрузки обычно решается горизонтальным масштабированием. Хотя кажется, что проблема может быть решена, по экспериментальным результатам, когда PS расширяется до определенного числа, время одношагового обучения будет увеличиваться, как показано на рисунке 4 ниже:

Основная причина этого результата заключается в следующем: одноэтапное обучение рабочих должно выполняться синхронно со всеми соединениями PS, и для каждого дополнительного PS добавляется N каналов связи, что значительно увеличивает задержку соединения (как показано на рис. 5 ниже). И обучение выполнять миллионы, десятки миллионов шагов обучения. в конечном итоге привести кЗадержка соединения превышает выгоду от одновременного добавления вычислительной мощности PS..

Для этой системы основная трудность оптимизации заключается в следующем:Как оптимизировать распределенные вычисления в условиях ограниченного количества экземпляров PS.

3 практики оптимизации

3.1 Введение в крупномасштабные разреженные параметры

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

Чтобы создать модуль внедрения в собственном TensorFlow, пользователю необходимо сначала создать переменную, достаточную для хранения всех разреженных параметров, а затем изучить внедрение этой переменной. Однако использование Variable for Embedding обучения имеет много недостатков:

• Размер переменной должен быть задан заранее, для сцены в десятки миллиардов миллиардов такая настройка приведет к огромным потерям места;
• Скорость обучения низкая, а пользовательская оптимизация для разреженных моделей невозможна.

Сначала мы решили проблему наличия или отсутствия, используя HashTable вместо Variable, идентификатор разреженного объекта в качестве ключа и Embedding vector в качестве значения. По сравнению с нативным способом использования Variable for Embedding он имеет следующие преимущества:

1. Размер HashTable можно автоматически масштабировать в процессе обучения, избегая избыточного места для хранения, и пользователям не нужно обращать внимание на размер приложения, тем самым снижая стоимость использования.
2. Для решения HashTable был реализован ряд индивидуальных оптимизаций. По сравнению с Variable скорость обучения была значительно улучшена. Оно может обучать сотни миллиардов моделей с хорошей масштабируемостью.
3. Благодаря динамическому масштабированию разреженных параметров мы поддерживаем онлайн-обучение на этой основе.
4. Дизайн API остается совместимым с версией сообщества, и использование почти такое же, как и у родной переменной, а стоимость стыковки чрезвычайно низкая.

Упрощенный вариант реализации на основе архитектуры PS показан на рисунке 6 ниже:

Основной процесс можно условно разделить на следующие этапы:

1. Разреженные идентификаторы функций (обычно мы заранее завершаем работу по унифицированному кодированию) поступают в модуль Embedding. С помощью механизма Send-Recv, созданного TensorFlow, эти разреженные идентификаторы функций вытягиваются на сторону PS, и такие операторы, как Lookup на стороне PS фактически начнется с нижнего слоя Запрос и сборка векторов встраивания в HashTable.
2. Приведенный выше вектор Embedding оттягивается Worker для последующего обучения, а градиенты этой части параметров вычисляются посредством обратного распространения, и эти градиенты далее оттягиваются оптимизатором на стороне PS.
3. Оптимизатор на стороне PS сначала вызывает оператор Find, получает исходный вектор разреженных параметров, соответствующий градиенту, и соответствующие параметры оптимизатора из HashTable, и, наконец, завершает вычисление обновления вектора внедрения и параметров оптимизатора с помощью алгоритма оптимизации, и затем использует оператор Insert.Insert into HashTable.

3.2 Оптимизация балансировки распределенной нагрузки

Эта часть оптимизации является классическим направлением оптимизации распределенных вычислений. Архитектура PS представляет собой типичную «модель ведра»: для завершения одношагового обучения Worker должен взаимодействовать со всеми PS, поэтому баланс между PS очень важен. Однако на практике мы обнаружили, что потребление времени несколькими ПС не сбалансировано.Причины включают не только дисбаланс нагрузки, вызванный простой логикой вырезания графа (Round-Robin) архитектуры TensorFlow PS, но и дисбаланс, вызванный разнородными машинами.

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

В оптимизаторе Adam процесс оптимизации его параметров требует двух бета-версий для участия в расчетах.В реализации собственного TensorFlow эти две бета-версии являются общими для всех Variabl (или HashTable), которые нуждаются в этом оптимизаторе для оптимизации, и будут использоваться совместно с The Первая переменная (лексикографический порядок имен) попадает на один и тот же ПС, что порождает проблему: у каждого оптимизатора есть только одна β_1 и одна β_2, и только на определенной ПС. Следовательно, в процессе оптимизации параметров к PS будут предъявляться гораздо более высокие требования, чем к другим PS, что приведет к тому, что PS станет узким местом в производительности.

Однако, наблюдая за алгоритмом оптимизации Адама, мы видим, что β_1 и β_2 являются константами, а части, выделенные синим цветом, представляют собой относительно независимые вычислительные процессы, и каждый PS может выполняться независимо. Основываясь на этом открытии, метод оптимизации очень интуитивно понятен: мы избыточно создаем параметры β для оптимизатора Adam на каждом PS и вычисляем значения t и альфа локально, чтобы удалить горячие точки PS, вызванные неравномерной нагрузкой.

Улучшение, вызванное этой оптимизацией, является универсальным и имеет очевидный эффект.В бизнес-модели Meituan удаление точки доступа бета-версии может привести к повышению производительности на 9%. Кроме того, из-за избавления от глобальной зависимости от β эта оптимизация также может улучшить масштабируемость архитектуры PS, что принесет лучшее ускорение, чем раньше, при увеличении количества воркеров.

3.3 Оптимизация связи

Согласно анализу в главе 2.2, коммуникационное давление в системе также очень велико, и мы в основном выполняем работу по оптимизации коммуникаций на основе RDMA. Прежде всего, давайте кратко представим RDMA, По сравнению с традиционным процессом связи, основанным на стеке протоколов TCP / IP, RDMA имеет преимущества нулевого копирования и обхода ядра, что не только уменьшает задержку сети, но и уменьшает занятость. скорость ЦП, RDMA больше подходит для соответствующего коммуникационного процесса моделей глубокого обучения.

RDMA в основном включает три протокола Infiniband, RoCE (V1, V2), iWARP. В сценарии глубокого обучения в Meituan протокол связи RDMA использует протокол RoCE V2. В настоящее время в области обучения глубокому обучению, особенно в сценариях обучения плотных моделей (NLP, CV и т. д.), RDMA стал стандартом для крупномасштабного распределенного обучения. Однако при обучении крупномасштабных разреженных моделей система с открытым исходным кодом имеет очень ограниченную поддержку RDMA.Коммуникационный модуль TensorFlow Verbs [4] давно не обновлялся, и эффект связи не идеален.У нас есть на основе этого проведена большая работа по благоустройству.

Оптимизированная версия с общедоступным набором данных Click Logs[5] объемом 1 ТБ, моделью DLRM[6] и обучением более 100 сотрудников повысила производительность на 20–40 %. С точки зрения нескольких бизнес-моделей Meituan, реализация коммуникационного уровня, преобразованная TensorFlow Seastar [7], также имеет улучшение скорости от 10% до 60%. А также вернуть нашу работуСообщество.

3.3.1 Оптимизация регистрации памяти

RDMA имеет три метода передачи данных: SEND/RECV, WRITE и READ. Среди них WRITE и READ аналогичны непосредственному чтению и записи отправителем данных в удаленную память, которую получатель не может воспринять. WRITE и READ подходят для пакетной обработки. передача информации. Внутри TensorFlow метод передачи данных на основе RDMA использует режим односторонней связи WRITE.

Когда RDMA передает данные, необходимо заранее освободить пространство памяти и зарегистрировать его на устройстве сетевой карты (процесс регистрации памяти, далее именуемый MR), чтобы сетевая карта могла напрямую управлять этим пространством. Открытие новой памяти и регистрация ее на устройстве — это трудоемкий процесс. На приведенном ниже рисунке 9 показано время, необходимое для привязки памяти разных размеров к устройству сетевой карты, видно, что с увеличением зарегистрированной памяти время, необходимое для привязки MR, быстро увеличивается.

Реализована версия сообщества Tensorflow RDMA, при создании тензоров по-прежнему используется унифицированный BFC Allocator, а все созданные тензоры регистрируются на MR. Как упоминалось выше, привязка регистрации MR имеет накладные расходы на производительность, а высокочастотная регистрация MR на большом пространстве приведет к значительному снижению производительности. Для тензоров в процессе обучения только те тензоры, которые участвуют в межузловой связи, должны выполнять MR, а остальным тензорам не нужно регистрироваться в MR. Таким образом, метод оптимизации относительно прост: мы идентифицируем и управляем этими коммуникационными тензорами и выполняем регистрацию MR только для тех тензоров, которые взаимодействуют между узлами.

3.3.2 Статический распределитель RDMA

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

• PS и Worker в архитектуре PS являются клиент-сервером друг для друга.Здесь в качестве примера взята сторона PS.Когда количество Workers увеличивается до тысяч, количество Workers увеличивается, что приводит к очень высокой частоте регистрации MR на стороне PS, что увеличивает выделение памяти и регистрацию, отнимает много времени.
• Поскольку форма выходного тензора одного и того же оператора может меняться между различными шагами в разреженной сцене, повторное использование созданного MR плохо, что приводит к высокой фрагментации памяти и повторной регистрации накладных расходов MR.

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

Основные идеи дизайна здесь следующие:

1. Хотя форма выходного тензора одного и того же оператора в разреженных сценариях может измениться, общий диапазон изменений можно контролировать.Благодаря мониторингу и анализу можно найти относительно стабильный размер памяти, соответствующий требованиям хранения тензоров между несколькими шагами.
2. Основываясь на приведенной выше информации, мы изменили исходную стратегию применения Tensor (Request) MR.Путем предварительной подачи заявки на большое пространство за один раз и регистрации его на сетевой карте последующее выделение пространства осуществляется через поддерживаемую стратегию распределения. самостоятельно, что значительно снижает частоту подачи заявок на МР, в большинстве случаев требуется только одна заявка на регистрацию МР за весь процесс обучения.
3. Мы ввели простой протокол обмена, чтобы упаковать форму и данные передаваемого тензора вместе и записать их на стороне клиента. Согласно протоколу, клиент анализирует размер тензора и, наконец, считывает данные, что позволяет избежать многократного процесса согласования, вызванного изменением формы тензора в нативной реализации.

В частности, в реализации мы представили модуль анализа распределения.В начале обучения мы проанализируем выделенные исторические данные, чтобы получить фактический предварительно разработанный размер MR и размер зарезервированного пространства каждого тензора. Затем мы приостановим процесс обучения и начнем процесс построения Аллокатора, включая создание MR и синхронизацию информации на обоих концах связи. Инфо-карта MR строится с использованием соответствующей информации. Ключом этой карты является уникальная метка тензора передачи (ParsedKey, которая определяется при расчете графа и разрезании графа). Структура Info содержит указатель локального адреса, размер смещения, информация, связанная с ibv_send_wr, и т. д. Затем возобновите обучение, и последующие тензорные передачи могут быть отправлены и получены с использованием статически разработанного MR, что также устраняет необходимость в нескольких процессах согласования из-за изменений формы.

3.3.3 Multi RequestBuffer и балансировка нагрузки CQ

Процесс связи RDMA версии сообщества TensorFlow включает в себя не только процесс отправки и получения вышеуказанных данных Tensor, но также процесс отправки и получения управляющих сообщений, связанных с передачей.Процессы отправки и получения управляющих сообщений также используют ibv_post_send и примитивы ibv_post_recv. В реализации собственного потока управления есть некоторые узкие места, которые ограничивают пропускную способность потока управления во время крупномасштабного обучения, тем самым влияя на эффективность передачи и приема данных. В частности, отражено в:

• Запрос отправляется через один и тот же кусок памяти RequestBuffer, и на этот кусок Buffer опираются множественные запросы Client, что приводит к тому, что информация о потоке управления фактически отправляется последовательно, и следующий Request может быть выполнен только после ожидания Подтверждение информации с противоположного конца.Запись, которая ограничивает пропускную способность отправки запроса.
• На стороне клиента необходимо опросить очередь завершения RDMA, чтобы получить приход запроса и изменение соответствующего состояния. Нативная реализация имеет только одну очередь завершения, и один поток выполняет обработку опроса, что ограничивает эффективность ответов при крупномасштабном распределенном обучении.

В ответ на вышеуказанные проблемы мы внедрили оптимизацию балансировки нагрузки Multi RequestBuffer и CQ, чтобы устранить узкое место в пропускной способности, которое может существовать в каналах отправки запроса и ответа на запрос.

3.3.4 Send-Driven & Rendezvous-Bypass

Учащиеся, знакомые с архитектурой Tensorflow PS, будут знать, что после того, как весь граф вычислений разрезается на сторону Worker и сторону PS, чтобы позволить двум графам вычислений обмениваться данными друг с другом, режим асинхронного обмена данными на основе установлен механизм Rendezvous (точки схождения). Как показано на рисунке 12 ниже:

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

Что касается конкретной реализации, Tensorflow реализует режим обмена данными Recv-Driven. Как показано на рисунке выше, два графа вычислений, расположенные в DeviceA и DeviceB, будут выполняться асинхронно и параллельно.Когда Recv в DeviceB выполняется, запрос RPC будут отправлены на Устройство А. Устройство А направит запрос на Рандеву после получения запроса. Если оно обнаружит, что необходимые данные были созданы и зарегистрированы оператором отправки, оно получит данные локально и вернет их на Устройство Б; производство еще не завершено, запрос Recv от DeviceB регистрируется в Rendezvous.После создания последующего DeviceA оператор Send отправит его, чтобы найти зарегистрированный Recv, инициировать обратный вызов и вернуть данные на DeviceB.

Мы видим, что механизм рандеву элегантно решает проблему обмена данными в случае разных ритмов производитель-потребитель. Однако модель Recv-Driven также представляет две потенциальные проблемы:

• По нашим наблюдениям, в реальной бизнес-модели доля оператора Recv, ожидающего оператора Send в Rendezvous, такая же, как доля оператора Send, ожидающего оператора Recv, в этот момент он может быть отправлен в противоположный конец, но из-за проблемы с реализацией механизма все еще необходимо дождаться прихода оператора Recv, прежде чем извлекать данные обратно, и процесс связи занимает много времени.
• Как точка доступа для обмена данными, Rendezvous не имеет низких внутренних логических издержек.

В ответ на проблемы, упомянутые выше, мы реализовали другой режим обмена данными на RDMA, который называется режимом Send-Driven. По сравнению с режимом Recv-Driven, как следует из названия, оператор Send напрямую записывает данные на сторону Recv, сторона Recv получает данные и регистрирует их в локальном Rendezvous, а оператор Recv напрямую получает данные от локального Рандеву. Конкретный процесс показан на рисунке 13 ниже:

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

3.4 Оптимизация задержки

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

3.4.1 Агрегация параметров разреженного домена

После включения HashTable для хранения разреженных параметров, соответственно, некоторые вспомогательные параметры также необходимо заменить реализацией HashTable, чтобы во всем графе вычислений было несколько HashTable и большое количество связанных операторов. На практике мы обнаружили, что нужно максимально сократить количество таких операторов, как Lookup/Insert, с одной стороны, чтобы уменьшить нагрузку на PS, а с другой стороны, чтобы уменьшить RPC QPS. Поэтому для общего использования разреженных моделей мы проводим связанную работу по агрегированию.

Взяв оптимизатор Adam в качестве примера, необходимо создать два слота, m и v, для сохранения информации об импульсе в оптимизации.Его форма такая же, как и у Embedding. В родном оптимизаторе эти две переменные создаются отдельно и считываются и записываются при обновлении обратного градиента. Точно так же при использовании схемы HashTable нам нужно создать две отдельные HashTable для одновременного обучения параметров m и v. Затем в прямом и обратном направлении необходимо выполнить поиск и вставку для встраивания, m и v соответственно, и всего требуется три поиска и три вставки.

Точка оптимизации здесь заключается в агрегировании счетчиков Embedding, m, v и низкочастотных фильтров (см. Подсчет HashTable на рис. 14 ниже) в качестве значения HashTable, чтобы можно было агрегировать и выполнять связанные операции с разреженными параметрами. значительно уменьшая количество рабочих частот разреженных параметров, снижает нагрузку на PS.

Эта функция является частью универсального типа оптимизации, функция агрегации после открытия скорости обучения была значительно улучшена, производительность увеличивается с изменением модели и масштаба рабочего, эффект всегда положительный. Во внутренней реальной бизнес-модели миссии США после полимеризации производительность по сравнению с отсутствием агрегации может улучшиться примерно на 45%.

3.4.2 Встраивание оптимизации конвейера

Сборочная линия в промышленном производстве относится к методу производства, при котором каждая производственная единица фокусируется только на обработке определенного сегмента работы для повышения эффективности работы и производительности. В компьютерной области более известно, что конвейер представляет собой метод распараллеливания выполнения нескольких задач с перекрытием. Например, в типичном RISC-процессоре программа пользователя состоит из большого количества инструкций, и выполнение инструкции можно условно разделить на: выборку, декодирование, выполнение, доступ к памяти и обратную запись. Эти ссылки будут использовать различные аппаратные блоки, такие как кэш инструкций, кэш данных, регистры и АЛУ.В каждом цикле инструкций аппаратные блоки этих пяти каналов будут выполняться параллельно, так что аппаратные возможности могут быть более полными. Повышает пропускную способность инструкций процессора. Конвейер инструкций процессора представляет собой сложную и систематизированную базовую технологию, но его идеи также широко используются в распределенных средах глубокого обучения, таких как:

• Если распределенное обучение просто абстрагируется от двух процессов вычислений и связи, большинство основных сред глубокого обучения поддерживают перекрытие связи и вычислений при выполнении DAG вычислительного графа.
• Если глубокое обучение модели просто разделено на прямое и обратное в пределах одного шага из-за сильной зависимости двух, его нельзя эффективно распараллелить.Планирование связи, введенное в BytePS[8], нарушает интервал между итерациями шага.После обновление некоторых параметров предыдущего раунда завершено, прямой расчет следующего раунда может быть запущен заранее, что усиливает перекрытие прямого и обратного направлений в общей перспективе.
• Чтобы решить проблему, когда параметры находятся в основной памяти, а вычисление находится в GPU во время обучения GPU сцены CTR, Baidu AIBox [9] умело планирует различные аппаратные устройства и строит этап подготовки параметров и основное использование ЦП / основной памяти / сетевой карты.На этапе сетевых вычислений GPU / NVLink более высокая пропускная способность обучения достигается за счет двухэтапного перекрытия.

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

Для крупномасштабного обучения разреженной модели основной процесс модели: сначала выполните встраивание разреженных параметров, а затем выполните плотные частичные подсети. Разреженный параметр Embedding выполняется на удаленном PS, который в основном потребляет сетевые ресурсы, а плотная подсеть выполняется на локальном Worker, который в основном потребляет вычислительные ресурсы. Эти две части занимают большую часть времени во всем процессе, и они занимают 40+% и 50+% фактической бизнес-модели Meituan.

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

С точки зрения конкретной реализации, мы разделяем весь граф вычислений на два подграфа, Embedding Graph (EG) и Main Graph (MG), которые выполняются асинхронно и независимо для достижения перекрытия процесса разделения (весь процесс разделения может быть выполнен правильная пользовательская прозрачность). EG в основном охватывает извлечение ключа внедрения из образца, запрос и сборку вектора внедрения и обновление вектора внедрения. MG в основном включает расчет плотной частичной подсети, расчет градиента и частичное обновление плотных параметров.

Взаимодействие между двумя подграфами: EG передает вектор Embedding в MG (с точки зрения MG он считывает значение из плотной переменной); MG передает градиент, соответствующий параметру Embedding, в EG. Выражениями двух вышеупомянутых процессов являются графы вычисленийTensorFlow, Мы используем два потока и два сеанса для одновременного выполнения двух графов вычислений, так что два этапа перекрываются, что обеспечивает большую пропускную способность обучения.

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

1. Слой абстракции под названием Pipeline Dataset представлен в форме, прозрачной для пользователя.Этот слой создается для удовлетворения требований двух расчетных графов EG/MG, работающих в разных ритмах, и поддерживает пользовательскую конфигурацию. Кроме того, чтобы данные во всем конвейере соответствовали друг другу, он также будет отвечать за генерацию и регистрацию глобального идентификатора пакета. Набор данных Pipeline предоставляет два итератора, один для EG и один для MG. Нижняя часть набора данных Pipeline содержит набор данных каждого слоя, встроенного в TensorFlow.
2. Верхний ExchangeManager — это статическая среда обмена данными между сеансами, которая предоставляет возможности регистрации данных и извлечения данных. Причина абстрагирования этого модуля в том, что EG и MG изначально принадлежали одному вычислительному графу, но были разобраны на два графа из-за пайплайна, поэтому нам нужно было наладить механизм межсессионного обмена данными и точно их сопоставить. Он использует глобальный идентификатор партии в качестве внутреннего ключа, а затем управляет данными выборки, вектором внедрения, градиентом внедрения, индексом после уникальности и другими данными и отвечает за управление жизненным циклом этих данных.
3. Средний Embedding Graph запускается отдельным сеансом TF в отдельном потоке.После получения выборочных данных с помощью оператора a выполняется извлечение идентификаторов функций и выполняется запрос разреженных параметров на основе метода HashTable.Результат запроса передается через оператор c.Размещается в ExchangeManager. EG также содержит оператор f для обратного обновления, который получает градиент внедрения и соответствующие ему прямые параметры из ExchangeManager, а затем выполняет логику параметра обновления градиента.
4. Следующий основной график отвечает за расчет фактической плотной подсети.Мы наследуем и реализуем обучаемую EmbeddingVariable.Процесс ее построения (оператор d) найдет соответствующий вектор внедрения из ExchangeManager и инкапсулирует его в EmbeddingVariable для плотной подсеть.. Кроме того, в методе, обратном регистрации EmbeddingVariable, мы добавляем оператор e, чтобы градиент Embedding можно было добавить в ExchangeManager для использования оператором f в EG.

С помощью описанного выше дизайна мы создали управляемый режим обучения параллельного конвейера EG/MG. В целом, источники дохода режима обучения конвейера встраивания:

• В ходе нашего профилирующего анализа нескольких бизнес-моделей мы обнаружили, что соотношение времени EG и MG составляет примерно 3: 7 или 4: 6. Путем распараллеливания этих двух этапов этап внедрения может быть эффективно скрыт, так что сеть MG может быть эффективно скрыта Вычислительная часть почти всегда может начаться немедленно, что значительно ускоряет общую производительность обучения модели.
• При использовании нескольких оптимизаторов (разреженных и неразреженных) в движке TensorFlow возникает проблема многократного построения обратного графа вычислений, что в определенной степени увеличивает количество дополнительных вычислений.Эта проблема решается разделением двух подграфов.
• В процессе реализации ExchangeManager отвечает не только за обмен параметрами встраивания и градиентами, но и за управление повторным использованием метаданных. Например, сохраняются результаты таких операторов, как Unique, что еще больше сокращает количество повторных вычислений.

Кроме того, в дизайне API мы сделали его прозрачным для пользователя, только одна строка кода может открыть функцию конвейера встраивания, а процесс резки EG/MG скрыт от пользователя. В настоящее время в рамках определенного бизнес-тренинга Meituan функция конвейера встраивания может обеспечить повышение производительности на 20–60% в архитектуре ЦП PS (и чем больше масштаб одновременного рабочего процесса, тем выше производительность).

3.5 Одновременная оптимизация PS для одного экземпляра

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

3.5.1 Высокопроизводительная хеш-таблица

В архитектуре PS крупномасштабное обучение разреженной модели предъявляет высокие требования к одновременному чтению и записи HashTable, потому что каждый PS должен выдерживать давление встраивания сотен или даже тысяч рабочих, Здесь мы рассматриваем скорость и стабильность и выбираем tbb: :concurrent_hash_map[10] реализован как базовая таблица HashTable и оборачивает ее в новый оператор TBBConcurrentHashTable. После тестирования в масштабе 100 миллиардов TBBConcurrentHashTable в 3 раза быстрее, чем собственная скорость обучения MutableDenseHashTable.

3.5.2 HashTable BucketPool

Для крупномасштабного обучения разреженной модели Embedding HashTable столкнется с большим количеством одновременных операций.Благодаря профилированию мы обнаружили, что частые приложения с динамической памятью приведут к большим потерям производительности (даже если у TensorFlow Tensor есть выделенный распределитель памяти). Мы оптимизируем управление памятью HashTable на основе идеи объединения памяти.

Когда HashTable инициализируется, мы сначала создадим два BucketPools для ключа и значения соответственно.Каждый пул сначала выделяет больший фрагмент памяти для резервного копирования.Учитывая, что могут быть сценарии, в которых ключ и значение в HashTable удаляются (например, Онлайн-обучение), память, используемая ключом и значением, удаленными из хеш-таблицы, должна быть восстановлена, поэтому каждый BucketPool также имеет ReuseQueue, ответственный за поддержание восстановленной памяти. Каждый раз, когда ключ и значение вставляются во внутреннюю структуру данных хеш-таблицы, память и выделение ключа и значения объединяются и управляются. Таким образом, затраты на выделение разреженной памяти, возникающие при крупномасштабном разреженном обучении, снижаются, а общая производительность сквозного обучения повышается примерно на 5 %.

3.6 Оптимизация пропускной способности единицы вычислительной мощности

После анализа в Главе 2.2 вычислительная нагрузка Worker также очень высока.Если Worker не оптимизирован, а пропускная способность должна поддерживаться, необходимо масштабировать больше Worker по горизонтали, что приведет к увеличению нагрузки на PS. Для пользователей, если это может повысить производительность при ограниченных вычислительных ресурсах, ценность для бизнеса будет выше. Мы посчитали несколько высокочастотных операторов через CAT и провели специальную оптимизацию. Здесь для совместного использования выбран случай слияния оператора Unique&DynamicPartition.

В архитектуре TensorFlow PS общие параметры, включая вектор Embedding, хранятся на PS и взаимодействуют с Worker через сеть.В процессе запроса Embedding часто задействованы следующие две ссылки:

• Из-за природы разреженных параметров частота повторения идентификатора внедрения, извлекаемого из выборки, часто достигает 70% ~ 90%. Небольшое давление. Поэтому операция Unique обычно выполняется перед запросом.
• В крупномасштабных разреженных сценариях для хранения сотен миллиардов параметров будет совместно размещаться несколько компьютеров PS. Рабочая сторона будет отвечать за разделение запроса запроса в соответствии с установленными правилами маршрутизации.Здесь действие DynamicPartition обычно выполняется перед запросом.

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

• Оператор Unique реализован изначально, и его внутренняя стратегия выделения памяти относительно неэффективна. Выделение памяти выполняется с использованием удвоенного размера входного параметра (Embedding ID), но из-за большого входного параметра и высокой частоты повторения HashTable создается слишком большой и очень разреженной. Почти каждая вставка будет генерировать minor_page_fault, что приведет к снижению производительности HashTable. Мы проверили это с помощью Intel Vtune (см. рис. 18).
• Операторы Unique и Dynamic Partition имеют избыточный обход данных, фактически эти операции могут быть выполнены за один обход данных, что экономит время на переключение оператора и избыточный обход данных.

Подводя итог, HashTable открыл большое количество minor_page_faults, что привело к увеличению времени доступа к памяти.Если HashTable слишком мал, это может привести к расширению. Мы приняли реализацию адаптивного к памяти оператора Unique на основе эвристического алгоритма.Благодаря статистике частоты повторения истории обучения мы можем получить относительно разумный размер HashTable для повышения производительности доступа к памяти; кроме того, конкретная HashTable в Уникальный оператор С точки зрения выбора, после наших различных тестов мы выбрали Robin HashTable для замены реализации в нативном TF.

Кроме того, мы объединили операторы вокруг ссылок Unique и Partition Embedding ID, чтобы упростить реализацию логики. После описанной выше оптимизации единственный оператор Unique может достичь ускорения на 51%, а сквозная производительность реальной модели может быть улучшена примерно на 10%, а общее количество операторов уменьшено на 4%.

В процессе оптимизации ключевых операторов Линь Лифань, Чжан Сянцзе и Гао Мин из Intel оказали большую техническую поддержку, и мы также повторно использовали некоторые их работы по оптимизации.Мы хотели бы выразить нашу глубокую благодарность!

4 Моделирование крупномасштабных разреженных алгоритмов

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

На системном уровне обучение крупномасштабной разреженной модели с крупномасштабным количеством топ-100 млрд выборок приведет к значительному снижению эффективности итерации обучения, а одиночный эксперимент увеличился до недели. Учебная группа платформы машинного обучения миссии США, в дополнение к оптимизации вышеупомянутой структуры Tensorflow, специальной оптимизации для бизнес-моделей, общей оптимизации пропускной способности в 8–10 раз (если можно дополнительно ускорить больше вычислительных ресурсов), значительно повысить эффективность итеративного бизнеса, помогая рекламный бизнес на вынос добился более очевидного улучшения.

5 Резюме и перспективы

TensorFlow широко используется в крупномасштабных рекомендательных системах, но отсутствие крупномасштабных разреженных крупномасштабных распределенных возможностей обучения сдерживает развитие бизнеса. Основанный на собственной архитектуре TensorFlow, Meituan поддерживает крупномасштабные разреженные возможности и был глубоко оптимизирован с разных точек зрения для достижения эффективного распределенного обучения с сотнями миллиардов параметров и сотнями миллиардов образцов и широко использовался в Мейтуан. . Сообщество TensorFlow также столкнулось с отсутствием таких ключевых возможностей.Сообщество официально создало SIG Recommenders[11] в 2020 году для решения таких проблем путем совместного создания сообщества.Meituan также будет активно участвовать в сообществе в будущем. .

Обучение модели сценария рекомендательной системы Meituan в настоящее время в основном выполняется на ЦП, но с развитием бизнеса некоторые модели становятся все более и более сложными, и сложно оптимизировать ЦП на ЦП (оптимизированный рабочий ЦП использование составляет 90%).%выше). В последние годы вычислительная мощность графического процессора резко возросла.Новое поколение графического процессора NVIDIA A100 имеет вычислительную мощность 156 TFLOPS (тензорные ядра TF32), 80 ГБ памяти и пропускную способность 600 ГБ/с между картами. Для нагрузки таких сложных моделей мы разработали распределенную тренировочную архитектуру следующего поколения на основе архитектуры графического процессора A100.После предварительной оптимизации мы также добились хороших результатов в рекомендательной модели бизнеса с большим трафиком в Meituan, и мы еще дальше Во время оптимизации мы поделимся им позже, так что следите за обновлениями.

6 Об авторе

• Yifan, Jiaheng, Zhengshao, Pengpeng, Yongyu, Zhengyang, Huang Jun и т. д. из базовой платформы исследований и разработок Meituan и группы обучения платформе машинного обучения в основном отвечают за оптимизацию производительности и производительность распределенной обучающей системы машинного обучения Meituan. .
• Хайтао из группы стратегии рекламы Meituan Food Delivery в основном отвечает за исследование алгоритмов и реализацию стратегии рекламного бизнеса Meituan Food Delivery.

7 Информация о наборе

Платформа машинного обучения Meituan постоянно набирает большое количество вакансий, как в социальных сетях, так и в школах (приглашаем представить нашу позицию Beidou по найму в школу: инфраструктура платформы машинного обучения Meituan), координирует Пекин / Шанхай и создает многопрофильную компанию. машинное обучение Платформа, помогающая всем лучше питаться и лучше жить. Резюме можно отправлять по адресу:huangjun03@meituan.com.

8 Справочная информация

• [1] Уууу. Usenix.org/system/file…
• [2] GitHub.com/comments/rubbing…
• [3] Уууу. Usenix.org/system/file…
• [4] GitHub.com/tensorflow/…
• [5] labs.следующий день special.com/2013/12/Dow…
• [6] АР Вест V.org/ABS/1906.00…
• [7] GitHub.com/tensorflow/…
• [8] GitHub.com/byte dance/no…
• [9] research.Baidu.com/public/up…
• [10] GitHub.com/один двойной API/…
• [11] GitHub.com/tensorflow/…

Подробнее Коллекции технических статей из технической команды Meituan

внешний интерфейс | алгоритм | задняя часть | данные | Безопасность | Эксплуатация и техническое обслуживание | iOS | Android | контрольная работа

|Ответьте на ключевые слова, такие как [акции 2020 г.], [акции 2019 г.], [акции 2018 г.], [акции 2017 г.] в диалоговом окне строки меню общедоступной учетной записи, и вы сможете просмотреть коллекцию технических статей технической группы Meituan в течение годы.

| Эта статья подготовлена ​​технической командой Meituan, авторские права принадлежат Meituan. Добро пожаловать на перепечатку или использование содержимого этой статьи в некоммерческих целях, таких как обмен и общение, пожалуйста, укажите «Содержимое воспроизводится технической командой Meituan». Эта статья не может быть воспроизведена или использована в коммерческих целях без разрешения. Для любой коммерческой деятельности, пожалуйста, отправьте электронное письмо по адресуtech@meituan.comПодать заявку на авторизацию.