Введение
Благодаря постоянному развитию глубокого обучения в различных областях, таких как оценка рейтинга изображений, языка и рекламы, многие команды начали изучать практику и применение технологии глубокого обучения на уровне бизнеса. С точки зрения оценки CTR рекламы одна за другой появляются новые модели: Wide and Deep[1], DeepCross Network[2], DeepFM[3], xDeepFM[4] и многие блоги Meituan, посвященные глубокому обучению, также представили подробные сведения. . Однако, когда автономная модель должна быть подключена к сети, она столкнется с различными новыми проблемами: может ли производительность автономной модели соответствовать онлайн-требованиям, как вставить оценку модели в исходную инженерную систему и т. д. Только точно понимая структуру глубокого обучения, мы можем лучше развертывать глубокое обучение в Интернете, чтобы быть совместимым с исходной инженерной системой и соответствовать требованиям к онлайн-производительности.
В этой статье сначала представлены бизнес-сценарии и процесс автономного обучения группы роста пользователей платформы Meituan, а затем в основном представлен весь процесс развертывания модели WDL в онлайн-режиме с использованием TensorFlow Serving, а также способы оптимизации производительности онлайн-сервиса с надеждой. вдохновлять всех.
2. Бизнес-сценарии и офлайн-процессы
2.1 Бизнес-сценарий
В сценарии уточнения рекламы для каждого пользователя будет не более сотни отзывов рекламы.Модель оценивает рейтинг кликов пользователя для каждой рекламы на основе характеристик пользователя и релевантных характеристик каждой рекламы, а затем сортирует их. . Из-за ограничения времени ожидания, налагаемого AdExchange на DSP, среднее время отклика нашего модуля сортировки должно контролироваться в пределах 10 мс, а Meituan DSP должен участвовать в торгах в реальном времени в соответствии с предполагаемой частотой кликов, поэтому расчетная производительность модели относительно высока.
2.2 Офлайн-обучение
Что касается автономных данных, мы используем Spark для генерации tfrecord, исходного формата данных TensorFlow[5], чтобы ускорить чтение данных.
С точки зрения модели используется классическая модель Wide and Deep, а функции включают характеристики измерения пользователя, характеристики измерения сцены и характеристики измерения товара. Широкая часть имеет более 80 входных данных для функций, глубокая часть имеет более 60 входных данных для функций, а входной слой Embedding имеет около 600 измерений, за которыми следуют 3 слоя с полными соединениями равной ширины 256. Параметры модели имеют в общей сложности 350 000 параметры, а соответствующий размер файла модели экспорта составляет около 11M.
Что касается автономного обучения, для решения проблем задержки асинхронного обновления и низкой производительности синхронного обновления используется распределенная структура синхронизации TensorFlow + Backup Workers [6].
Что касается распределенного распределения параметров PS, GreedyLoadBalancing используется для распределения параметров в соответствии с предполагаемым размером параметра вместо метода распределения по модулю циклического перебора, который может сбалансировать нагрузку каждого PS.
Что касается вычислительного оборудования, мы обнаружили, что скорость обучения будет выше, если вместо графического процессора используется только центральный процессор, в основном потому, что, хотя производительность вычислений на графическом процессоре может быть улучшена, это увеличивает накладные расходы на передачу данных между процессором и графическим процессором. Когда это не слишком сложно, лучше использовать ЦП.
В то же время мы используем высокоуровневый API Estimator для инкапсуляции чтения данных, распределенного обучения, проверки модели и экспорта модели TensorFlow Serving. Основные преимущества использования оценщика:
- Одномашинное обучение и распределенное обучение можно легко переключать, и нет необходимости модифицировать слишком много кодов при использовании разных устройств: CPU, GPU, TPU.
- Структура Estimator очень понятна, что облегчает общение между разработчиками.
- Новички также могут напрямую использовать некоторые установленные модели Estimator: модель DNN, модель XGBoost, линейную модель и т. д.
3. TensorFlow Serving и оптимизация производительности
3.1 Введение в TensorFlow Serving
TensorFlow Serving — это высокопроизводительная библиотека с открытым исходным кодом для обслуживания моделей машинного обучения, которая может развертывать обученные модели машинного обучения онлайн и использовать gRPC в качестве интерфейса для приема внешних вызовов. TensorFlow Serving поддерживает горячее обновление модели и автоматическое управление версиями модели, что очень гибко.
На следующем рисунке показана вся структура TensorFlow Serving. Клиент будет продолжать отправлять запросы менеджеру, а менеджер будет управлять обновлениями модели в соответствии со стратегией управления версиями и возвращать клиенту последние результаты расчета модели.
Внутренняя платформа данных Meituan предоставляет специализированную службу TensorFlow Serving, которая работает распределенно в кластере через YARN, которая периодически сканирует путь HDFS для проверки версии модели и автоматически обновляет ее. Конечно, каждый локальный компьютер может установить TensorFlow Serving для экспериментов.
В сценарии нашей внешней рекламы каждый раз, когда приходит пользователь, онлайн-реквестер будет преобразовывать пользователя и всю информацию о отозванных 100 рекламных объявлениях в формат ввода модели, а затем отправлять его в TensorFlow Serving as a Batch, после TensorFlow Serving принимает запрос, вычисляет предполагаемое значение CTR и возвращает его запрашивающему.
При развертывании первой версии TensorFlow Serving, когда количество запросов в секунду составляет около 200, для запроса упаковки требуется 5 мс, сетевые накладные расходы должны быть зафиксированы на уровне около 3 мс, только расчет оценки модели занимает 10 мс, а строка TP50 всего процесса составляет около 18 мс, а производительность в онлайне совершенно недостижима. Далее мы подробно представим наш процесс оптимизации производительности.
3.2 Оптимизация производительности
3.2.1 Оптимизация на стороне запроса
Онлайн-оптимизация на стороне запроса в основном предназначена для параллельной обработки сотни рекламных объявлений.Мы используем многопоточность OpenMP для параллельной обработки данных, что снижает производительность времени запроса с 5 мс до примерно 2 мс.
#pragma omp parallel for
for (int i = 0; i < request->ad_feat_size(); ++i) {
tensorflow::Example example;
data_processing();
}
3.2.2 Оптимизация модели сборки OPS
Перед оптимизацией на вход модели поступают необработанные данные в исходном формате. Например, значения характеристик канала могут быть в строковом формате, таком как «канал 1» и «канал 2», а затем выполнять горячую обработку в формате One Hot. модель.
Первоначальная модель использовала большое количество столбцов tf.feature_column высокого порядка для обработки данных и преобразования их в формат One Hot и встраивания. Преимущество использования tf.feature_column заключается в том, что нет необходимости выполнять какую-либо обработку исходных данных при вводе, а многие общие функции можно обрабатывать внутри модели через API feature_column, например: tf.feature_column.bucketized_column можно использовать для группирования tf.feature_column.crossed_column может выполнять пересечение функций по функциям категорий. Но давление обработки признаков находится в модели.
Чтобы дополнительно проанализировать затраты времени на использование feature_column, мы использовали инструмент tf.profiler для анализа затрат времени на весь процесс автономного обучения. Очень удобно использовать tf.profiler во фреймворке Estimator, достаточно добавить одну строчку кода.
with tf.contrib.tfprof.ProfileContext(job_dir + ‘/tmp/train_dir’) as pctx:
estimator = tf.estimator.Estimator(model_fn=get_model_fn(job_dir),
config=run_config,
params=hparams)
На рисунке ниже показано трудоемкое распределение сети при прямом распространении с использованием tf.profiler, видно, что обработка признаков с помощью API feature_column занимает много времени.
Чтобы решить проблему трудоемкой обработки признаков в модели, при обработке автономных данных мы заранее сопоставляем все нативные данные в строковом формате с One Hot и помещаем отношение сопоставления в локальный файл feature_index, а затем поставляем линия Использование онлайн и офлайн. Это эквивалентно исключению процесса вычисления One Hot на стороне модели вместо использования словаря для поиска O(1). В то же время при построении модели используйте более низкоуровневые API с гарантированной производительностью, чтобы заменить высокоуровневые API, такие как feature_column. На рисунке ниже показана доля времени прямого распространения во всем процессе обучения после оптимизации производительности. Видно, что доля прямого распространения, занимающая много времени, значительно снижается.
3.2.3 Оптимизация компиляции XLA, JIT
TensorFlow использует направленный граф потока данных для выражения всего вычислительного процесса, в котором узел представляет операцию (OPS), данные выражаются в форме тензора, а направленные ребра между разными узлами указывают направление потока данных, а весь граф представляет собой направленный поток данных.
XLA (Accelerated Linear Algebra) — это компилятор, оптимизирующий операции линейной алгебры в TensorFlow.Когда включен режим компиляции JIT (Just In Time), используется компилятор XLA. Весь процесс компиляции показан на следующем рисунке:
Во-первых, будет оптимизирован весь граф вычислений TensorFlow, а лишние вычисления в графе будут обрезаны. HLO (High Level Optimizer) создаст исходную операцию HLO из оптимизированного графа вычислений.Компилятор XLA оптимизирует исходную операцию HLO и, наконец, передаст ее LLVM IR для генерации различных машинных кодов в соответствии с различными внутренними устройствами. .
Использование JIT помогает LLVM IR генерировать более эффективный машинный код на основе примитивных операций HLO; в то же время для нескольких объединенных примитивных операций HLO он будет объединен в более эффективную вычислительную операцию. Но JIT-компиляция выполняется во время выполнения кода, что также означает, что при выполнении кода будут дополнительные накладные расходы на компиляцию.
На приведенном выше рисунке показано соотношение затрат времени на различные сетевые структуры и разные размеры пакетов после JIT-компиляции и без JIT-компиляции. Видно, что оптимизация производительности при большем размере пакета очевидна, а изменение количества слоев и количества нейронов мало влияет на оптимизацию JIT-компиляции.
В практических приложениях конкретные эффекты будут различаться в зависимости от структуры сети, параметров модели, аппаратного оборудования и других причин.
3.2.4 Окончательное исполнение
После описанной выше серии оптимизаций производительности время оценки модели сокращается с первоначальных 10 мс до 1,1 мс, а время запроса сокращается с 5 мс до 2 мс. Весь процесс от упаковки и отправки запроса до получения результата занимает около 6 мс.
3.3 Проблема сбоя переключения модели
Путем мониторинга обнаружено, что при обновлении модели будет большое количество тайм-аутов запросов. Как показано на рисунке ниже, каждое обновление вызывает большое количество тайм-аутов запросов, что оказывает большее влияние на систему. С помощью анализа журнала и кода TensorFlow Serving было обнаружено, что проблема тайм-аута в основном связана с двумя аспектами: с одной стороны, потоки для обновления, загрузки моделей и обработки запросов TensorFlow Serving совместно используют пул потоков, что делает невозможным обработку запросов. при переключении моделей; с другой стороны, модель После загрузки граф расчета использует метод ленивой инициализации, который заставляет первый запрос ожидать инициализации графа расчета.
Проблема 1 в основном связана с загрузкой и выгрузкой проблем с конфигурацией пула потоков модели в исходном коде:
uint32 num_load_threads = 0; uint32 num_unload_threads = 0;
Эти два параметра по умолчанию равны 0, что означает, что независимый пул потоков не используется, а Serving Manager работает в том же потоке. Изменение его на 1 может эффективно решить эту проблему.
Основной операцией загрузки модели является RestoreOp, которая включает в себя такие операции, как чтение файлов модели из хранилища, выделение памяти и поиск соответствующих переменных, которые выполняются путем вызова метода run сеанса. По умолчанию все операции сеанса в процессе используют один и тот же пул потоков. Поэтому один и тот же пул потоков используется для операции загрузки и операции обработки запроса на обслуживание в процессе загрузки модели, что приводит к задержке запроса на обслуживание. Решение состоит в том, чтобы настроить несколько пулов потоков с помощью параметров файла конфигурации и указать независимый пул потоков для выполнения операции загрузки при загрузке модели.
Вторая проблема заключается в том, что первый запуск модели занимает много времени.После загрузки модели заранее выполняется операция прогрева, чтобы операция во время запроса не влияла на производительность запроса. Метод использования Warm Up здесь заключается в том, чтобы выбрать тип входных данных в соответствии с сигнатурой, установленной при экспорте модели, а затем создать поддельные входные данные для инициализации модели.
Благодаря оптимизации двух вышеупомянутых аспектов проблема задержки запроса после переключения модели хорошо решена. Как показано на рисунке ниже, при переключении моделей сбой уменьшается с исходных 84 мс до примерно 4 мс.
4. Резюме и перспективы
Эта статья в основном знакомит группу роста пользователей с онлайн-оценкой глубокого обучения на основе Tensorflow Serving, позиционирования, анализа и решения проблем с производительностью; наконец, реализован онлайн-сервис с высокой производительностью, высокой стабильностью и поддержкой различных моделей глубокого обучения. .
После полного автономного обучения и основы онлайн-оценки мы ускорим быструю итерацию стратегии. С точки зрения моделей, мы можем быстро опробовать новые модели и попытаться объединить обучение с подкреплением со ставками; с точки зрения производительности в сочетании с техническими требованиями мы дополнительно изучим оптимизацию графов TensorFlow, основные операторы операций и слияние операций; Функцию оценки TensorFlow Serving можно использовать для анализа моделей, и Google также запустил инструменты «Что, если», основанные на этом, чтобы помочь разработчикам моделей глубоко анализировать модели. Наконец, мы также объединим анализ модели, чтобы повторно изучить данные и функции.
использованная литература
[1] Cheng, H. T., Koc, L., Harmsen, J., Shaked, T., Chandra, T., Aradhye, H., ... & Anil, R. (2016, September). Wide & deep learning for recommender systems. In Proceedings of the 1st Workshop on Deep Learning for Recommender Systems (pp. 7-10). ACM. [2] Wang, R., Fu, B., Fu, G., & Wang, M. (2017, August). Deep & cross network for ad click predictions. In Proceedings of the ADKDD'17 (p. 12). ACM. [3] Guo, H., Tang, R., Ye, Y., Li, Z., & He, X. (2017). Deepfm: a factorization-machine based neural network for ctr prediction. arXiv preprint arXiv:1703.04247. [4] Lian, J., Zhou, X., Zhang, F., Chen, Z., Xie, X., & Sun, G. (2018). xDeepFM: Combining Explicit and Implicit Feature Interactions for Recommender Systems. arXiv preprint arXiv:1803.05170. [5] Abadi, M., Barham, P., Chen, J., Chen, Z., Davis, A., Dean, J., ... & Kudlur, M. (2016, November). TensorFlow: a system for large-scale machine learning. In OSDI (Vol. 16, pp. 265-283). [6] Гоял П., Доллар П., Гиршик Р., Нордхуис П., Весоловски Л., Кирола А., ... и Хе К. (2017 г.) Точная, большая мини-партия SGD: обучающая сеть изображений за 1 час Препринт arXiv arXiv:1706.02677. [7] Neill, R., Drebes, A., Pop, A. (2018). Performance Analysis of Just-in-Time Compilation for Training TensorFlow Multi-Layer Perceptrons.
об авторе
Чжун Да окончил Рочестерский университет по специальности «наука о данных» в 2017 году, затем работал в компании Stentor Technology в районе Калифорнийского залива. Он присоединился к Meituan в 2018 году и в основном отвечает за бизнес-сценарии глубокого обучения и обучения с подкреплением в группа роста пользователей.
Хунцзе присоединилась к Meituan-Dianping в 2015 году. Лидер алгоритмов группы роста пользователей платформы Meituan и бизнес-группы по вину и путешествиям. Раньше он работал в Ali. В основном он занимается увеличением числа активных пользователей платформы Meituan Dianping с помощью машинного обучения. Алгоритм работы такие проекты, как запуск новых проектов, могут эффективно повысить эффективность маркетинга и снизить затраты на маркетинг.
Тинг Вэнь присоединился к Meituan-Dianping в 2015 году. В направлении автономных вычислений Meituan Dianping он занимался планированием ресурсов YARN и созданием вычислительной платформы GPU.
Набор персонала
Meituan DSP является основным бизнес-направлением цифрового маркетинга Meituan в Интернете.Присоединяйтесь к нам, вы можете лично участвовать в создании и оптимизации маркетинговой платформы, которая может охватить сотни миллионов пользователей и направлять их жизненные и развлекательные решения. В то же время вы также столкнетесь с проблемами точного, эффективного и недорогого маркетинга и получите возможность познакомиться с передовой системой алгоритмов искусственного интеллекта и решениями для больших данных в области вычислительной рекламы. Вы будете работать с командой маркетинговых технологий Meituan, чтобы продвигать создание экосистемы управления трафиком и поддерживать постоянное быстрое развитие бизнеса, такого как винные путешествия, еда на вынос, в магазине, такси и финансы. Мы искренне приглашаем вас со страстью, идеями, опытом и умением сражаться бок о бок с нами! Участвовал в реализации системы доставки внешней рекламы Meituan Dianping.На основе крупномасштабных данных о поведении пользователей алгоритм онлайн-рекламы был оптимизирован для повышения DAU, ROI, а также релевантности и эффективности доставки онлайн-рекламы. Добро пожаловать на электронную почту wuhongjie#meituan.com для консультации.