Практика платформы машинного обучения Tensorflow+GPU

Обзор

Snowball Toutiao основан на сцене сообщества фондовой биржи и использует типичную структуру потоковой передачи Feeds для распространения пользовательского контента. Перед лицом часто меняющегося фондового рынка необходимо эффективно реализовать связь между пользователями и контентом, пользователями и акциями, пользователями и пользователями, а также обеспечить своевременное и эффективное распространение контента. Команда Snowball Algorithm разработала интеллектуальную систему распределения контента на основе алгоритмов.На этапе Rank используется фреймворк Tensorflow, а для сортировки контента используется ведущая в отрасли модель Wide&Deep. Столкнувшись с таким сложным бизнесом, требующим больших вычислительных ресурсов, необходимо постоянно оптимизировать и улучшать инженерную эффективность.

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

1. Проблемы бизнеса

Snowball Toutiao — типичная система персонализированных рекомендаций, которая опирается на техническую поддержку крупномасштабного хранилища данных и машинного обучения. Архитектура снежного кома показана на рисунке ниже, включая следующие три уровня:

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

Частью обучения модели уровня офлайн-сервиса является сложность рекомендательной системы. Как мы все знаем, модель Wide&Deep, которую мы приняли, относительно сложна и требует интенсивного расчета данных, что создает множество проблем для инженерной группы. В то же время из-за непредсказуемых изменений на фондовом рынке интересы пользователей также часто меняются, и модель ранжирования необходимо постоянно обновлять и корректировать. Как построить здесь систему моделей реального времени и автоматически завершать обучение и обновление модели — тоже проблема, стоящая перед нами. Бизнес-задачи, с которыми сталкивается рекомендательная система Snowball, заключаются в следующем:

Что касается автономного обучения, текущий ежедневный размер данных составляет около 5T, а данные обучения достигают 1 миллиарда образцов.
Пиковая пропускная способность в сети достигает 400 запросов в секунду, а задержка P99 составляет менее 600 мс.
С быстро развивающимся бизнесом объем данных и вычислений по-прежнему быстро растет.

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

2. Технический отбор: ускоренное обучение на GPU

По сравнению с ЦП, ГП может быстрее выполнять операции с матрицами и числами с плавающей запятой. Основная скорость работы графического процессора в 30-100 раз выше, чем у центрального процессора. При обучении разделение труда между ЦП и ГП выглядит следующим образом: ЦП завершает подготовку данных, такую как загрузка данных, извлечение признаков и распределение данных, а ГП завершает расчет модели.

Программирование графического процессора требует предварительной установки драйверов, связанных с Nvdia, и версии Tensorflow для графического процессора. Когда среда готова, пора писать программы для GPU. Писать код GPU для Tensorflow относительно просто, нужно только указать имя устройства для параметра (var) и оператора (op).

Кроме того, Tensorflow официально настраивает обычно используемый Estimator и предоставляет распределитель устройств по умолчанию* со стратегией опроса. Пользователю нужно только указать конфигурацию сеанса (Session) для применения GPU. Если пользователи планируют определять оценщики в соответствии со своими предпочтениями, а также свободно организовывать и назначать параметры и операторы, также очень удобно писать собственные оценщики.

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

После запуска первой версии модели GPU это было далеко не то, что ожидалось. В основном отражается в следующих пунктах:

(1) Скорость обучения слишком низкая, всего 6000 выборок в секунду. Однако обучение только на ЦП может составлять 8000 выборок в секунду.

(2) Коэффициент использования ЦП и ГП низкий. На 58-ядерной машине загрузка процессора составляет менее 20%, а загрузка графического процессора — всего 0-8%, и есть очевидные пики и спады.

Чтобы решить проблему скорости обучения и в полной мере использовать возможности графического процессора, мы пробовали различные оптимизации. Наконец, она была увеличена до 2,1 Вт отсчетов в секунду, что соответствовало текущим требованиям к обучению. Конкретные методы и идеи оптимизации заключаются в следующем.

Во-первых, мы анализируем метод обучения модели после внедрения GPU. Как упоминалось ранее, ЦП отвечает за ввод и преобразование данных, а ГП — за расчет модели. В шаговом расчете он делится на три этапа:

I/O: Необработанные данные считываются в память с жесткого диска или другого постоянного носителя с помощью системного ввода-вывода.
Map: после процесса преобразования (сопоставления) извлечение функций, разбиение данных и другие операции преобразуются в данные функций для использования Tensorflow. Он также включает в себя пакетную обработку, перемешивание и т. д. Преобразование здесь может выполняться только на ЦП, что требует значительных вычислительных ресурсов.
Train: Наконец, введите его в память графического процессора для расчета модели и завершите процесс обучения. Из-за чрезвычайно высокой скорости вычислений GPU узким местом является взаимодействие между CPU и GPU, которое включает планирование, двунаправленное копирование памяти и видеопамяти и т. д.

Здесь оптимизацию можно начать с двух аспектов: подготовка данных и обучение. Трудно подготовить данные, о чем будет сказано позже.

2. Оптимизация тренировочной части

Обучающая часть зависит от кода модели, в основном от определения параметров и операторов в Estimator. Вообще говоря, необходимо соблюдать правило: старайтесь накладывать сложные вычисления с плавающей запятой (например, матричные операции) на операции GPU, а параметры и соответствующие операторы определять на одном устройстве, чтобы избежать копирования данных между устройствами.

Поскольку в полностью оптимизированном проекте используется Wide&Deep Estimator, официально предоставленный Tensorflow, эффект оптимизации здесь не очевиден.

3. Оптимизация подготовленной части данных

3.1 Параллелизм

Во-первых, о чем проще всего подумать, это параллелизм. Коэффициент использования ЦП относительно низок, а многоядерность используется не полностью. Рассмотрите возможность использования нескольких потоков для подготовки данных. Как показано ниже:

Чтобы полностью использовать все ЦП, здесь включен набор пулов потоков для подготовки данных. После того, как пакет выборочных данных обрабатывается несколькими потоками, он передается графическому процессору для завершения обучения. После параллельной оптимизации скорость обучения достигает 8000 отсчетов/с, улучшение примерно на 30%, что в основном соответствует скорости обучения чистого процессора.

Однако даже после распараллеливания использование графического процессора не так хорошо, как должно быть. Использование графического процессора всегда показывает случайные скачки, всегда периодически достигая 12%, а затем возвращаясь к 0. Использование ЦП также имеет такое же прерывистое явление, которое, как предполагается, является проблемой режима вычислений, и скорость обучения может быть дополнительно улучшена.

3.2 Подготовка данных

После приведенной выше оптимизации и анализа вычислительного механизма ЦП отвечает за ввод-вывод и извлечение признаков при вычислительной обработке пакета, подготавливает данные для обучения, а затем передает их графическому процессору для вычислений. В этом процессе, если дизайн неправильный, это приведет к тому, что ЦП и ГП будут чередоваться в состояниях простоя. То есть: CPU готовит данные, GPU ждет, затем GPU обучается, CPU ждет и так далее. Общее время обучения будет суммой времени процессора и времени графического процессора.

Поэтому предлагается еще одна точка оптимизации, ЦП подготавливает данные. То есть ЦП непрерывно подготавливает каждый пакет данных, а ГП параллельно выполняет вычисления. Когда ЦП подготавливает пакет данных, а ГП обучается, ЦП продолжает подготовку следующего пакета данных. (Примечание: скорость копирования данных из ЦП в ГП чрезвычайно высока, основной ГП может достигать 20 Гбит/с, и здесь можно не учитывать затраты времени)

Благодаря точке оптимизации подготовки данных скорость обучения увеличена до 9000 выборок в секунду, что составляет улучшение примерно на 10%.

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

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

3.3 Знакомство с TFRecord

Продолжайте анализировать проблему, связанную с высокой загрузкой ЦП, но с неполным использованием графического процессора. Данные обучения в проекте представлены в собственном формате CSV Hive, считываются данные из CSV-файла и генерируются в формате данных, доступном для Tensorflow. В середине также есть некоторые расчеты извлечения признаков, а для повторяющейся конфигурации образцов в проекте существует явление повторного вычисления при извлечении признаков. Поэтому здесь представлен собственный формат Tensorflow TFRecord, файл данных, в котором хранятся извлеченные функции в формате ключа и значения. Перед обучением данные конвертируются в формат TFRecord и сохраняются на жесткий диск. В последующем процессе обучения файл TFRecord считывается напрямую с жесткого диска, чтобы сократить сложные вычисления извлечения признаков.

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

3.4 Сжатие TFRecord

Так как tfrecord — это данные признаков, хранящиеся в формате (ключ, значение), файл имеет относительно большой размер. В проекте размер 100 Вт данных составляет около 4G. Для механического жесткого диска со скоростью 100 Мбит/с максимум 2,5 Вт данных может быть обработано за 1 секунду. Когда возникает проблема с системным вводом-выводом, проще всего подумать о сжатии данных. Здесь наш метод сжатия начинается с двух аспектов.

3.4.1 Сжатие форматов данных

Структура хранения TFRecord по умолчанию может быть показана на следующем рисунке, по одной выборке в строке, выборка включает функции 1-N, и каждая функция организована и хранится по ключу и значению. Например, пример 1, форма хранения — list(kn, v(n,1)). При таком способе хранения дляЗначение ключа повторно сохраняется для каждого образца(k1-kN), так как большинство функций в проекте являются однозначными функциями классификации float или int, особенно когда значение ключа длинное, эти значения ключа занимают более 60% пространства.

Оптимизация: чтобы сохранить удобочитаемость значения ключа, длина ключа не сжимается. Вместо этого применяется комбинированная схема хранения с несколькими образцами. Проект возьмет m за единицу и сохранит m отсчетов вместе. Как показано ниже. Для выборок 1-m слияние сохраняется в строке записей TFRecord в виде list(kn, list(v(n,m))).

Значение m представляет собой целочисленный делитель batch_size гиперпараметра при обучении, что удобно для слияния данных на последующем этапе подготовки данных. В то же время m является компромиссом между скоростью обучения и пространством.Чем больше m, тем лучше эффект сжатия пространства, но это повлияет на параллелизм этапа подготовки данных и увеличит трудоемкость этапа отображения. Чем меньше m, тем лучше параллелизм и снижается трудоемкость этапа отображения (влияние планирования здесь не рассматривается, см. обсуждение следующего пункта оптимизации), но тем хуже эффект сжатия пространства. Вообще говоря, для batch_size=1000 в проекте значение m равно 100, чтобы получить хороший компромисс.

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

3.4.2 Общее сжатие

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

Внедрив сжатый TFRecord, проблема высокой загрузки ЦП и низкой загрузки ГП была полностью решена. На основе этой оптимизации коэффициент использования графического процессора может быть увеличен примерно до 20%, а скорость обучения выборок может быть увеличена до 1,6 Вт выборок в секунду. Использование жесткого диска падает ниже 15%.

3.5 сначала партия, а затем карта

При использовании различных методов оптимизации есть один очень эффективный момент оптимизации: сначала пакетная обработка, а затем сопоставление.

Давайте сначала рассмотрим традиционный метод.После того, как исходные данные считаны, преобразование карты выполняется одно за другим для завершения преобразования данных, а затем с помощью пакетной операции формируются пакеты обучающих выборок с batch_size в качестве единицы. **Оптимальное место:мы будемПакет разделен на две стадии: партия 1 и партия 2, расположенные до и после карты соответственно. **Операция batch1 предшествует карте, исходные данные интегрируются в пакеты в соответствии с batch_size1, а затем отправляются на карту для завершения преобразования данных (здесь функцию карты необходимо изменить, чтобы она соответствовала пакетным данным), и, наконец, операция batch2 снова интегрирует данные. Формула выбора batch_size выглядит следующим образом:

batch_size = batch_size1 * batch_size2

Эта оптимизация процесса увеличит скорость обучения образцов до 2 Вт образцов в секунду.

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

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

3.6 Сводка по оптимизации

Подводя итог пунктам оптимизации для обучения графическому процессору:

точка оптимизации

Скорость обучения (выборки/сек)

Использование графического процессора

Примечание

никто

6000

7-8%

Подготовьте данные параллельно с несколькими потоками

8000

12%

подготовка данных

9000

12%

Представляем TFRecord

1.6w

20%

Сжать TFRecord

Сначала пакет, а затем карта

2.1w

30%

Количество слоев Wide&Deep в проекте невелико, и GPU не может быть использован полностью.

3.7 Использование проекта

В настоящее время в проекте предусмотрена одномашинная машина с 4 видеокартами GPU, которая может параллельно обучать 4 модели на одной машине, а скорость может достигать 8 Вт выборок в секунду. Улучшена скорость этапа обучения, а ежедневная задача обучения может быть выполнена в течение 5 часов, что соответствует текущему спросу на ежедневное обновление модели.

3. Системная практика: система обучения и прогнозирования модели Model_bus

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

Система Model_bus разделена на три основных модуля:

(1)Служба преобразования функций

Служба преобразования признаков запускается запланированной задачей, загружает исходные обучающие данные из HDFS, завершает извлечение признаков данных, создает сжатую запись TFRecord и загружает ее в HDFS. Поскольку между обучающими данными нет никакой зависимости, служба преобразования признаков здесь может быть построена распределенным образом, чтобы сократить время преобразования. Для дневных данных здесь требуется 1-2 часа.

После загрузки службы преобразования функций в HDFS она отправит сообщение в mq, чтобы уведомить службу обучения модели о начале обучения.

(2)Услуга обучения моделей

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

Когда модель, отвечающая онлайн-требованиям, загружается в HDFS, служба обучения моделей отправляет сообщение в очередь сообщений, чтобы уведомить модель о переходе в онлайн.

(3)Модель онлайн-сервиса

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

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

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

В сценарии персонализированной рекомендации потока Xueqiu Toutiao Feeds команда алгоритма Xueqiu использовала модель Wide&Deep для полной сортировки контента, усиленную графическим процессором, и выполнила ряд оптимизаций, которые значительно повысили скорость обучения модели. Кроме того, построена онлайн-система модели Model_bus, которая автоматически выполняет функции обучения/обновления/онлайн-обслуживания модели и предоставляет соответствующие вспомогательные модули, такие как веб-операции и аварийные сигналы.

Затем команда алгоритма Snowball сосредоточится на создании системы рекомендаций в режиме реального времени, создании хранилища данных в реальном времени и продвижении приложений онлайн-обучения. Что касается обучения модели, мы разрабатываем распределенное обучение на основе Tensorflow для дальнейшего повышения вычислительной мощности.

Набор персонала

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

Должность: Системный инженер рекомендаций/Инженер алгоритмов рекомендаций

Почта:jiaguiyuan@xueqiu.com