Для получения дополнительных галантерейных товаров, пожалуйста, обратите внимание на публичный аккаунт WeChat «AI Frontline» (ID: ai-front)
В интернет-сценарии сотни миллионов пользователей ежедневно генерируют десятки миллиардов пользовательских данных, формируя сверхбольшие обучающие выборки. Как использовать эти данные для обучения лучших моделей и использования этих моделей для обслуживания пользователей, ставит перед платформами машинного обучения большие проблемы. Эти проблемы анализируются ниже с точки зрения сценариев рекомендации веб-страницы/графики/видео, которые далее называются сценариями рекомендаций.
Размер выборки большой. В рекомендуемом сценарии размер ежедневной выборки может достигать десятков миллиардов. Если вам нужно тренироваться на ежемесячной выборке, размер выборки будет исчисляться сотнями миллиардов. Если каждая выборка имеет в среднем 500 собственных значений, размер одной выборки составляет около 5 КБ, а размер ста миллиардов выборок — 500 ТБ. Даже если используются только выборки за одну неделю, размер данных выборки находится на уровне 100 ТБ.
-
Есть много особенностей. Огромный размер выборки позволяет обучать многомерные модели. Чтобы предоставить пользователям более разумные результаты рекомендаций, требуется подробное описание пользователя и рекомендуемых статей/изображений/видео. Каждый бизнес создаст богатую пользовательскую модель, а также будет отмечать статьи/изображения/видео в нескольких измерениях.
Когда система рекомендует, она также будет использовать текущую контекстную информацию пользователя, такую как время, местоположение, ранее просмотренные страницы и т. д. Когда эти функции вводятся в модель, это приводит к быстрому увеличению размера функций. Если вы рассмотрите операции преобразования признаков, такие как кроссовер, размерность модели легко увеличится до сотен миллиардов или даже триллионов.
Требования к эффективности тренировок высокие. Мы имеем дело с десятками терабайт образцов и моделей с 10 миллиардами/100 миллиардами параметров. Бизнесу необходимо в короткие сроки обучить модель с хорошими показателями производительности для быстрой онлайн-проверки. Это предъявляет высокие требования к обучающим возможностям платформ машинного обучения.
В предыдущих пунктах с 1 по 3 предложены проблемы, с которыми сталкивается система обучения сверхкрупномасштабных моделей, но обучение модели — это только важный первый шаг. Окончательная модель должна быть подключена к сети, чтобы предоставлять услуги пользователям, чтобы отражать ее ценность для бизнеса. Для малых и средних моделей машинного обучения в прошлом онлайн-сервис моделей не вызывал особой озабоченности. Однако, когда окончательный файл модели очень большой, даже превышающий размер памяти одной машины, онлайн-сервис модели становится сложной проблемой.
Модель большая, но пользователю нужен миллисекундный отклик. Взяв в качестве примера простейшую модель LR, размер модели с 1 миллиардом признаков также достигнет 12 ГБ (каждый параметр требует 8-байтового ключа и 4-байтового значения с плавающей запятой). В случае моделей DNN также возможны размеры моделей до терабайт. После обучения модель запускается для предоставления пользователям услуг прогнозирования. Чтобы добиться хорошего взаимодействия с пользователем, время отклика службы прогнозирования должно быть порядка 10 мс. Если взять в качестве примера рекомендательный сценарий пользователя мобильного телефона, то время с момента, когда пользователь обновляет страницу на мобильном телефоне, до просмотра результата рекомендации не может превышать 1 с.Вычитая накладные расходы на сетевую связь, время отклика онлайн-сервисов в IDC необходимо контролировать в течение 200 мс. Однако весь рекомендательный процесс состоит как минимум из трех этапов: отзыв, сортировка и контроль отображения. На этапе сортировки необходимо выполнить сращивание признаков и оценку CTR для более чем 200 статей, поэтому общее время оценки моделью CTR для этих 200 статей должно быть в пределах 30 мс. Использование такой крупномасштабной модели для высокопроизводительного прогнозирования с высокой степенью параллелизма также является серьезной проверкой возможностей платформы.
Модель работает в режиме реального времени. Для сценариев информационных рекомендаций опасения пользователей быстро меняются. Системе необходимо скорректировать модель на основе последних данных о поведении пользователей, а затем обновить такую крупномасштабную модель для службы онлайн-прогнозирования в нескольких регионах с максимальной скоростью.
Для решения вышеуказанных задач мы:
1) Разработал вычислительную среду машинного обучения, основанную на архитектуре сервера параметров — Infinite Framework, которая смогла выполнить обучение на уровне десятков миллиардов образцов / десятков миллиардов моделей параметров в течение часа. Infinite framework предоставляет множество алгоритмов машинного обучения, которые могут не только выполнять автономное обучение на основе задач, но также поддерживать 7 * 24 часов онлайн-обучения с потоковыми примерами в качестве входных данных.
2) На основе фреймворка Infinite мы построили автоматизированную систему управления моделями — Infinite Model Management, где модели можно беспрепятственно и эффективно переносить между офлайн-задачами обучения, онлайн-кластерами обучения и онлайн-сервисами прогнозирования, достигая моделей уровня 10 ГБ в пределах уровень минут онлайн.
3) Чтобы улучшить сервис онлайн-прогнозирования больших моделей, мы также разработали высокопроизводительный модуль и сервис прогнозирования — Infinite Prediction Service, который может завершить прогнозирование 100 выборок всего за несколько миллисекунд для модели из десятков ГБ.
Infinite Framework, Infinite Model Management и Infinite Prediction Services вместе составляют основную часть Infinite System. Далее мы подробно познакомим вас с архитектурой и основными компонентами Infinite System.
В таких сценариях, как реклама/рекомендация, процесс производства и использования модели можно условно разделить на несколько этапов:
1.Сбор журнала и генерация выборки. Собирая информацию о поведении пользователя в сети, генерируются образцы, требуемые моделью. Эти образцы можно хранить для автономного обучения или передавать в кластеры онлайн-обучения с использованием потоковых данных.
2.обучение модели. После получения образцов конкретная модель обучается в обучающем кластере. Разработчики получают хорошие модели, настраивая гиперпараметры или структуру модели.
3.Оценка модели. Прежде чем модель будет размещена в онлайн-сервисе, необходимо выполнить некоторую оценку модели.
4.Модель онлайн-прогноза. Infinite System в настоящее время включает в себя обучение модели, оценку модели и онлайн-прогнозирование на вышеуказанных этапах.
Для плавного переноса модели из обучающего кластера в службу онлайн-прогнозирования Infinite System предоставляет функцию управления моделями, которая может автоматически экспортировать новые модели с обучающей машины в службу онлайн-прогнозирования. Компании также могут определять операции оценки моделей в процессе автоматизации моделей, чтобы избежать размещения моделей с плохим эффектом обучения в онлайн-сервисах прогнозирования. Кроме того, когда модель находится в сети, также необходимо проверить, есть ли проблема с онлайн-моделью.
Во время разработки модели настройка гиперпараметров отнимает у разработчиков модели много времени. В сочетании с системой Prajna Infinite System осуществляет мониторинг в реальном времени эффекта обучения модели и предоставляет данные для принятия решений для автоматической настройки параметров. Infinite Systems разрабатывает инструмент автоматической настройки параметров. Алгоритмы также могут реализовывать пользовательские функции автоматической настройки параметров на основе этих данных.
В системе машинного обучения код алгоритма машинного обучения является лишь очень небольшой частью процесса обучения или прогнозирования. Ниже приведена статистика Google о ее системах машинного обучения.
[1 ] Hidden Technical Debt in Machine Learning Systems, Google.
Для выполнения задач машинного обучения требуется большое количество вспомогательных сервисных средств, включая управление данными и их хранение, платформу обучения, систему онлайн-прогнозирования, управление ресурсами и другие модули. Системная архитектура Infinite System выглядит следующим образом:
Диаграмма архитектуры системы
Учебные задачи Infinite System выполняются в системе планирования MIG Prajna для задач машинного и глубокого обучения, а кластер онлайн-обучения и служба онлайн-прогнозирования развернуты в системе Sumeru. И система Prajna, и система Sumeru построены на основе технологии контейнеризации докеров, которая обеспечивает надежную инфраструктуру, гарантирующую быстрое развертывание и расширение бесконечной системы.
Базовая система хранения поддерживает HDFS и распределенное сетевое хранилище ceph. Как обычно используемое распределенное сетевое хранилище, HDFS легко подключается к другим системам анализа данных. Обладая высокой производительностью и гибкими файловыми операциями, Ceph компенсирует неудобства Hdfs в файловых операциях.
Сбор журналов использует маячную систему MIG и взаимодействует с собственной службой обработки потоковых данных для создания обучающих выборок в режиме реального времени.
Благодаря собственной вычислительной платформе Infinite, основанной на архитектуре сервера параметров, Infinite System поддерживает автономное обучение на основе задач и потоковое онлайн-обучение сотен миллиардов моделей. Платформа бесконечных вычислений реализована на C++ для достижения превосходной производительности и поддерживает LR/FM/FFM/DNN и другие модели, обычно используемые в сценариях рекомендаций и поиска.Пользователям нужно только выполнить простую настройку для обучения сверхкрупномасштабной модели.
Для модели с сотнями миллиардов параметров размер модели будет не менее десятков ГБ. Infinite System предоставляет два режима использования модели для службы онлайн-прогнозирования бизнеса:
1) Модель сервисных компонентов. Компонент службы модели включает в себя две основные функции: управление версиями модели и прогнозирование модели. Благодаря глубокой оптимизации управления памятью компонентом службы моделей предприятия могут напрямую загружать и использовать модели до 100G в своих собственных службах прогнозирования.
2) Сервис хранения моделей. Когда размер модели превышает размер, который может храниться на одном компьютере, для управления моделью и предоставления услуг прогнозирования требуется распределенная служба хранения моделей.
Помимо генерации образцов, обучения моделей и модулей онлайн-прогнозирования, это сервис платформы бесконечной системы. Здесь пользователи управляют своими данными, обучающими задачами и моделями.
До сих пор мы кратко представили различные части Бесконечной системы. Позволяет читателям получить общее представление о бесконечной системе. Ниже мы сосредоточимся на инфраструктуре бесконечных вычислений, службах управления моделями и прогнозирования моделей.
Чтобы получить хорошую модель, необходимы как минимум три аспекта: 1. Данные, 2. Модель и алгоритм, 3. Вычислительная среда.
Как упоминалось в предыдущем введении, пользователи Интернета создали для нас большое количество выборочных данных, которые обеспечивают основу данных для изучения хорошей модели. В этом разделе мы сосредоточимся на последних двух частях.
Прежде всего, мы представим широко используемые модели и алгоритмы для рекомендуемых сценариев, а затем выведем требования к вычислительной среде, чтобы реализовать обучение этих моделей, и как среда бесконечных вычислений может удовлетворить эти требования и достичь высоких результатов. обучение модели производительности.
С появлением коммерческих рекомендаций область прогнозирования рейтинга кликов (CTR) привлекла большое внимание исследователей, что привело к появлению множества моделей прогнозирования CTR. Ниже приводится краткое сравнение нескольких репрезентативных моделей в крупномасштабных сценариях. Это LR, FM, DNN соответственно. Для алгоритма GBDT, обычно используемого в рекомендательных сценариях, поскольку он не подходит для ввода крупномасштабных функций, здесь не проводится сравнение.
LR модель
LR — простая и полезная линейная модель. Преимущества: это просто реализовать и очень легко поддерживать выборочный ввод крупномасштабных функций. В практических приложениях он часто может дать хорошие результаты и часто используется в качестве базовой линии. Недостаток: поскольку это линейная модель, требуется много работы по разработке функций, чтобы она работала хорошо. Пересечение признаков и другие операции также напрямую приводят к быстрому расширению пространства признаков модели.
FM-модель
Основываясь на линейной модели LR, FM вводит квадратичный член, который позволяет модели FM автоматически изучать перекрестную связь второго порядка между функциями. Преимущества: автоматическое изучение перекрестных отношений второго порядка, что сокращает часть работы по разработке признаков. Недостаток: чтобы узнать больше, чем перекрестные отношения второго порядка, по-прежнему требуется работа по выбору перекрестных признаков для создания соответствующих выборок.
Модель DNN
С прорывным развитием глубокой нейронной сети (DNN) в области изображения и речи DNN была введена в модель CTR, в надежде изучить сложные отношения между функциями и получить лучшую модель. В прогнозировании CTR входные признаки являются многомерными и разреженными, а полносвязная сеть не может использоваться для прямого обучения.Поэтому сеть, используемая для прогнозирования CTR, обычно принимает структуру слоя встраивания + полносвязный слой. Разреженные объекты преобразуются в низкоразмерные плотные объекты через слой внедрения, а затем вводятся в следующий полносвязный слой. Преимущества: исходные функции можно вводить напрямую, что сокращает работу по выбору перекрестных функций. Недостатки: параметры обучения сложнее, чем LR и FM. Производительность обучения также ниже, чем у LR и FM из-за введения плотных параметров DNN.
[Google 2016] Wide & Deep Learning for Recommender Systems
Выше были кратко представлены три репрезентативные модели.На основе этих трех базовых структур, с помощью различных комбинаций и улучшений, получены структуры моделей, такие как FFM, FNN, DeepFM и DIN. Если вы хотите узнать больше о связанных моделях, обратитесь к ссылкам [3][4].
Исходя из базовой структуры приведенной выше модели, мы можем обобщить характеристики параметров модели CTR:
1) Очень крупномасштабные разреженные входные параметры функции. Входные данные для слоя внедрения LR, FM и DNN являются разреженными, и значение параметра может быть одиночным значением (w в LR) или вектором (w+v в FM и w в слое внедрения).
2) Плотные параметры взаимосвязи. Параметры полносвязного слоя в DNN плотны.
Видно, что вычислительная среда должна поддерживать как разреженные, так и плотные форматы параметров. Кроме того, очень важны в обучении и некоторые статистические признаки (например, количество показов статьи, кликабельность и т. д.). Эти параметры также должны быть легко рассчитаны во время обучения.
В рекомендательном сценарии рекомендуемый контент имеет определенную своевременность.Со сменой хотспотов соответственно будет меняться и фокус пользователя.В результате после применения модели CTR онлайн эффективность предсказания будет снижаться с течением времени. снижается, поэтому модель CTR необходимо своевременно обновлять. В различных сценариях бизнес-приложений эта частота обновления может быть на уровне минут или на уровне дня. Однако переобучение модели с масштабом в десятки миллиардов потребует много времени и вычислительных ресурсов, поэтому для своевременного обновления модели с малыми затратами ресурсов в сценариях рекомендуется онлайн-обучение. Следовательно, вычислительная среда должна поддерживать различные алгоритмы онлайн-обучения. В настоящее время алгоритмы оптимизации, применяемые для онлайн-обучения, в основном включают FTrl, Adagrad и т. д.
В наших целях проектирования системы есть три ключевых аспекта:
1) Сотни миллиардов параметров модели;
2) сотни миллиардов выборочных данных;
3) Высокая производительность.
Как улучшить цели трех вышеперечисленных измерений одновременно, нам необходимо тщательно проанализировать процесс распределенных вычислений. В качестве примера возьмем обычно используемый алгоритм распределенной оптимизации, основанный на градиентном спуске. В процессе использования выборочных данных I для раунда обучения существуют следующие основные этапы:
1) сегментирование данных, при котором все данные разбиваются и распределяются по нескольким машинам;
2) Вычислить g параллельно, а вычислительные узлы на каждой машине вычислить градиент по заданному алгоритму;
3) Агрегировать g и собрать g, рассчитанные на каждой машине;
4) Обновить w, обновить w с помощью g, полученного на предыдущем шаге;
5) Широковещательная передача w для передачи обновленного w на вычислительную машину.
Такая логика обучения эффективно решает проблему объема выборочных данных, распределяя данные по нескольким машинам для расчета. И Hadoop, и Spark используют эту логику для машинного обучения, Spark полностью использует память для хранения промежуточных данных благодаря методу RDD, что значительно повышает производительность обучения. Но при такой логике обучения есть две проблемы:
1) w хранится на одной машине, что ограничивает масштаб моделей, которые может обучить фреймворк.Это может быть только модель, которая может храниться на одной машине.В качестве примера возьмем модель со 128G памяти, модель с 1 миллиард параметров достигнет его предела хранения
2) w транслируется на каждую машину. Из-за метода широковещательной рассылки, когда масштаб модели становится больше, стоимость полосы пропускания, вызванная широковещательной операцией, резко возрастает. В наших тестах обучение модели с миллионом параметров с помощью Spark показало невыносимую производительность.
Приведенная выше логика распределенного обучения является логикой алгоритма градиентного спуска, а алгоритм стохастического градиентного спуска (SGD) широко используется в машинном обучении, особенно в глубоком обучении. Параметры модели обновляются единицами мини-пакетов (128 образцов или даже меньше). Это приводит к резкому увеличению частоты обновления параметров, что приводит к огромному спросу на пропускную способность сети. Следовательно, две вышеуказанные проблемы должны быть решены, прежде чем можно будет проводить обучение модели с сотнями миллиардов параметров. Из этого родилась архитектура сервера параметров.
Базовая структура и схема работы сервера параметров
Он был предложен в 2010 году, и после нескольких лет разработки и эволюции в настоящее время широко используется архитектура сервера параметров третьего поколения. По сравнению с предыдущим процессом Алгоритма 1 сервер параметров имеет два основных отличия:
1) Существует новый сервер ролей, который специально используется для хранения параметров модели в распределенном виде и выполнения расчетов обновления параметров. Это делает размер модели, которую можно обучить, больше не ограничивать объемом памяти одной машины, и в то же время распределяет запросы параметров от нескольких рабочих узлов к нескольким серверам, уменьшая узкие места в сети, вызванные передачей параметров и градиентов на одном компьютере. единый сервер.
2) Способ получения параметров в секции Worker, отвечающей за расчет, — метод pull. Поскольку он не пассивно ожидает широковещательных параметров, метод извлечения позволяет рабочим узлам получать параметры в соответствии с потребностями обучающих данных. Особенно в рекомендательных сценариях выборки очень редкие. Например, модель может иметь 10 миллиардов входных данных признаков, а для конкретной выборки будет только несколько сотен допустимых значений признаков. Таким образом, необходимо только получить параметры, относящиеся к этим нескольким сотням действительных собственных значений, без передачи всей модели.
Короче говоря, в архитектуре сервера параметров несколько серверов разделяют нагрузку по хранению и передаче параметров, а несколько рабочих процессов получают и обновляют параметры по запросу, что снижает требования к сети для передачи параметров и градиентов. Это обеспечивает высокопроизводительное обучение моделей с сотнями миллиардов параметров.
Проведя вышеизложенный анализ, мы пришли к следующим выводам. Сервер параметров может удовлетворить наши требования к дизайну с точки зрения размера модели, количества выборок и производительности обучения.
Сравнение Hadoop/Spark/сервера параметров
Поняв общую архитектуру сервера параметров и ее характеристики, мы возвращаемся к инфраструктуре бесконечных вычислений и продолжаем анализировать проблемы, с которыми сталкивается серверная архитектура с общими параметрами на практике, и наши решения.
При анализе модели и алгоритма мы знаем, что необходимо реализовать передачу и обновление двух типов разреженных и плотных параметров.
1) Очень крупномасштабные разреженные входные параметры функции. Sparse имеет здесь два значения.
Во-первых, возможных параметров модели сотни миллиардов, но поскольку не все признаки могут появиться в обучающих выборках, как правило, не все параметры имеют значения, как правило, только 1/10 параметров итоговой модели могут иметь значения .из. Если используются методы разрежения, это соотношение будет ниже.
Во-вторых, для каждого образца используется очень мало функций. В модели с сотнями миллиардов признаков одна выборка обычно включает всего несколько сотен признаков.
Из приведенного выше анализа видно, что архитектура сервера параметров особенно эффективна при обучении моделей с крупномасштабными разреженными функциями. Потому что, когда рабочий обучает мини-партию образцов, ему нужно получить только параметры, относящиеся к этим образцам.Если каждый образец имеет в среднем 500 признаков, то 100 образцов должны получить только соответствующие параметры не более 50 000 признаков.
2) Плотные параметры взаимосвязи. В отличие от параметров разреженных входных признаков, параметры кросс-отношения имеют относительно небольшой масштаб, но все плотные параметры используются для обучения на каждой выборке. Если предположить, что самый большой слой в полносвязном слое имеет размер 1024*512, то параметр плотности, используемый в каждом расчете, составляет порядка 500 000.
Отсюда видно, что разреженные и плотные параметры во время обучения имеют разные свойства. Разреженные параметры в целом велики, но за сеанс обучения используется только небольшая их часть. Общий размер плотных параметров относительно невелик, но их необходимо использовать в полном объеме для каждой тренировки. Из-за разницы в природе двух типов параметров они естественным образом делятся на структуры данных на основе Kv и на основе матриц.
Далее мы продолжаем анализировать проблемы с производительностью и наши решения на разных этапах обучения.
1) Получение параметров. При обучении практических гипермасштабных моделей сеть часто становится узким местом производительности. Чтобы уменьшить нагрузку на передачу данных по сети, вызванную получением параметров, мы внедрили механизм кэширования параметров. Рабочие не получают последние параметры с сервера для каждого мини-пакета. Однако при распределенном обучении кэширование параметров модели может привести к нарушению правильности обучения. В случае параллелизма данных обучающие данные, используемые каждым вычислительным узлом, различаются.Если несколько тренировок выполняются без синхронного обновления параметров, модель может не сойтись. В области академических исследований это проблема обучения пропускной способности сети и точности обучения модели. Были изучены различные протоколы управления синхронизацией. Наша реализация основана на идее ограниченных различий версий в протоколе ssp [5].Управляя количеством использований кеша, передача по сети, вызванная получением параметров, уменьшается в предпосылке обеспечения правильности обучения.
2) Обновление градиента. После того, как расчет будет завершен, загрузка градиента также будет иметь большой объем данных, которые необходимо передать по сети. Согласно логике расчета градиента модели, все используемые параметры получат соответствующие градиенты. Однако необязательно отправлять ли обновление определенного параметра или каким образом отправлять его на сервер.Этот процесс называется градиентным сжатием. Методы сжатия градиента можно условно разделить на две категории:
1) Градиентное квантование. Квантуйте градиент от примитивных типов, таких как double/float, к двоичным/трехзначным типам, которые могут быть представлены несколькими битами, чтобы уменьшить объем передаваемых данных.
2) Градиентная разреженность. Выбирайте важные градиенты для немедленной загрузки, в то время как менее важные обновления градиентов накапливаются и загружаются позже. Если читатели интересуются этой областью исследований, они могут прочитать ссылки [6][7].
Традиционная технология градиентного сжатия имеет потребление памяти, эквивалентное размеру модели, поэтому она в основном используется при обучении плотных моделей, которые можно хранить на одной машине.Улучшение делает ее пригодной для обучения десятков миллиардов масштабные модели с разреженными параметрами, которые могут уменьшить передачу градиента более чем на 99%, не влияя на эффект обучения.
3) Расчет градиента. В машинном обучении, особенно в процессе глубокого обучения, в процессе вычисления градиента модели будет большое количество операций численного расчета. В дополнение к использованию многопоточного параллельного обучения для полного использования вычислительной мощности нескольких ЦП, мы также используем инструкции параллельных вычислений ЦП, такие как SSE и библиотека линейных вычислений Eigen, для реализации процесса вычисления градиента, в полной мере используя конвейер и Возможности параллельных инструкций чипа ЦП, которые более эффективны, чем простые. Производительность многопоточных параллельных вычислений в 10+ раз выше.
В реальной производственной среде данные хранятся в кластере hdfs, и извлечение данных во время обучения занимает много времени. Благодаря асинхронизации чтения данных чтение данных не влияет на передачу параметров, расчет градиента и процесс обновления обучения. В то же время за счет оптимизации управления памятью и механизма кэширования выборок модуля чтения данных требования к обучению случайности выборок могут быть выполнены с минимальными затратами памяти.
В рекомендательном бизнесе статьи и видеоматериалы быстро обновляются, социальные сети появляются и исчезают в любой момент, а интересы пользователей часто меняются. Для достижения отличного рекомендательного эффекта в модель прогнозирования добавляется много информации о функциях, зависящих от времени, что приводит к своевременному обновлению модели CTR. Infinite System предоставляет полноценный сервис управления моделями.
Основной процесс переноса модели
При управлении очень большими моделями возникают две основные проблемы:
1) Онлайн-производительность модели, вызванная негабаритной моделью. Для модели со 100 миллиардами параметров, если каждый параметр хранится в 4-байтовом формате с плавающей запятой, размер конечной сохраненной модели будет близок к терабайтам. Если вы хотите обновить новую модель для службы онлайн-прогнозирования в нескольких местах на минутном уровне, только из-за производительности передачи данных и анализа файлов, невозможно каждый раз использовать полную модель. К счастью, смена модели в процессе обучения происходит постепенно, а когда модель находится в онлайне, это относительно стабильное состояние, а онлайн-обучение больше связано с тонкой настройкой модели. Поэтому для очень крупномасштабных моделей для управления обычно используется полный + инкрементный подход. Сначала используйте полную модель для загрузки в онлайн-сервис, а затем периодически поэтапно накладывайте отличающиеся части модели на модель онлайн-сервиса.
2) Проблемы управления, вызванные фрагментацией модели. В онлайн-режиме полной + инкрементной модели модель онлайн-сервиса соответствует нескольким файлам модели. Если онлайн-сервис дает сбой и его необходимо восстановить или расширить из-за увеличения объема запросов, для восстановления модели необходимо использовать несколько файлов модели. В некоторых случаях бизнес обнаруживает, что текущая модель неэффективна, и требуется другой набор файлов модели, когда необходимо заменить модель или выполнить откат версии. Кроме того, в отличие от моделей, которые можно хранить на одном компьютере, в среде сервера параметров модели сегментируются и хранятся на разных компьютерах. Чтобы повысить эффективность экспорта модели, несколько серверных узлов будут экспортировать несколько файлов фрагментов модели параллельно. Если предположить, что серверов 100, то файлов сегментов модели будет 100. Привносит проблемы в работу по управлению моделями.
Во избежание возникновения этих проблем при разработке моделей и пользователей, а также для обеспечения стабильной работы системы, Infinite Model Management Service берет на себя всю работу, связанную с управлением моделями. Пользователям нужно только выполнить необходимую настройку, и служба управления моделью автоматически обнаружит новую версию модели, проверит целостность модели, а также передаст и опубликует новую модель в назначенной службе онлайн-прогнозирования. Пользователь полностью защищен от деталей нижнего уровня, таких как полный, инкрементный и сегментированный. На более позднем этапе пользователи также могут настроить метод проверки модели и выполнять запросы на моделирование и другие проверки моделей, которые должны быть запущены, чтобы избежать запуска моделей с плохими результатами и причинения коммерческих потерь.
Использование большой модели с сотнями миллиардов параметров для онлайн-прогнозирования сталкивается со многими проблемами. Давайте проанализируем некоторые из основных проблем и представим наши решения:
1) Проблема с памятью при загрузке модели. При загрузке в память необходимо построить связанные структуры данных, а потребляемый объем памяти будет намного больше, чем размер файла модели. Взяв в качестве примера простейшую модель LR, каждая функция имеет только один параметр модели типа float, а размер файла модели с 1 миллиардом ценных функций составляет около 12 ГБ (каждая функция 8 байтов ключа + 4 байта значения). Для загрузки этой модели с помощью unordered_map из стандартной библиотеки stl требуется более 25 ГБ памяти. Другими словами, накладные расходы памяти будут более чем в 1 раз превышать размер модели, что сильно ограничивает размер модели, которая может храниться на одной машине. Мы реализовали hash_map: tl_hash_map, которая специально оптимизирована для памяти для характеристик разреженных параметров модели. Потребление памяти всего примерно на 20% больше, чем данные модели. Это означает, что tl_hash_map эффективно увеличивает предельный размер моделей, которые могут храниться на одной машине. Взяв в качестве примера машину с памятью 128 ГБ, используя tl_hash_map, максимальный поддерживаемый размер файла модели lr составляет около 100 ГБ, в то время как стандартная unordered_map может поддерживать максимум около 50 ГБ.
2) Проблема производительности модельного сервиса. Чтобы обеспечить хорошее взаимодействие с пользователем, время отклика службы прогнозирования должно быть порядка 10 мс. Если взять в качестве примера рекомендательный сценарий пользователя мобильного телефона, то время от обновления пользователем страницы на мобильном телефоне до просмотра результата рекомендации не может превышать 1 с. После вычета накладных расходов на сетевую связь время отклика онлайн-сервиса в IDC необходимо контролировать в течение 200 мс, и вся рекомендация Процесс состоит как минимум из трех этапов отзыва, сортировки и управления отображением. На этапе сортировки необходимо выполнить сращивание признаков и оценку CTR для более чем 200 статей, поэтому общее время оценки моделью CTR для этих 200 статей должно быть в пределах 30 мс.
С момента отправки запроса службой заказа до завершения запроса существует как минимум два узких места в производительности:
1) Сетевая передача и кодек пакетов запросов. Чтобы спрогнозировать вероятный показатель кликабельности статьи, для каждой статьи необходимо подготовить все образцы функций. Предполагая 500 функций на образец, запрос на 200 статей будет содержать 100 000 функций. Данные всего пакета запроса будут около 1 МБ. Производительность сетевой передачи, а также кодирования и декодирования поставила перед всей инфраструктурой rpc большие проблемы. Мы определяем набор форматов кодирования и декодирования функций для сценариев прогнозирования моделей, что позволяет избежать недостатков производительности существующих инфраструктур rpc в форматах кодирования и декодирования и минимизировать размер данных, которые необходимо передать.
2) Запрос параметров модели и вычислительная производительность. Чтобы выполнить функцию прогнозирования модели, сначала необходимо найти требуемые параметры из модели, а затем завершить расчет прогнозируемого значения. Перед лицом сверхкрупномасштабных моделей первое, что нужно решить, — это проблема хранения моделей. Если модель может храниться на одной машине, то запрос параметров модели можно выполнить локально. Если модель превышает лимит хранилища на одном компьютере, вам необходимо использовать распределенное хранилище для предоставления служб запросов. Рассмотрим приведенный выше пример: для запроса требуются параметры для 100 000 функций, которые хранятся на нескольких машинах. Даже если не учитывать время расчета прогноза, чтобы этот запрос возвращался в течение 30 мс, все узлы, хранящие параметры, должны возвращать результаты в течение 30 мс. Это приведет к феномену барреля.Если какой-либо узел хранения имеет задержку ответа более 30 мс, общее время запроса обязательно превысит 30 мс. Такие системы хранения близки к нулевому допуску для очередей запросов. Однако рекомендуемый сценарий — это сценарий с высокой степенью параллелизма, и служба прогнозирования должна поддерживать десятки тысяч пользовательских запросов в секунду. Компания Infinite Systems разработала набор сервисов прогнозирования распределенных моделей, которые специально оптимизированы для производительности запросов параметров модели с высокой степенью параллелизма в сценариях распределенного прогнозирования, чтобы обеспечить поддержку службы прогнозирования с высокой степенью параллелизма для моделей уровня TB.
С развитием интернет-сервисов все более и более совершенные и специализированные сервисы требуют лучшей поддержки моделей, а сверхкрупномасштабные модели прогнозирования стали основными решениями. Благодаря глубоким исследованиям и оптимизации компания Imeasurable Systems разработала высокопроизводительную вычислительную среду, которая может поддерживать обучение сотен миллиардов моделей параметров, а с помощью услуг управления моделями и прогнозирования моделей реализован весь процесс обучения, управления и онлайн-поддержка сверхбольших моделей. Infinite System поддерживает множество распространенных моделей, таких как LR/FM/FFM/DNN, и фактически использовалась и проверялась в бизнесе браузеров мобильных телефонов, помогая бизнесу добиться значительного улучшения бизнес-показателей. Бесконечная система будет постепенно расширять свои функции, такие как изучаемая технология глубокого обучения на основе графического процессора, чтобы охватить больше существующих бизнес-сценариев и новейшие сценарии приложений ИИ, а также обеспечить мощную системную поддержку для дальнейшего улучшения бизнеса.
Доктор Юань Иттербиум, старший научный сотрудник Tencent Technology Co., Ltd.
использованная литература
[1] Hidden Technical Debt in Machine Learning Systems, Google. In NIPS'15
[2] Wide & Deep Learning for Recommender Systems, Google 2016
[3] Краткое изложение общих алгоритмов расчета кликабельности рекламы https://cloud.tencent.com/developer/article/1005915
[4] Применение глубокого обучения для оценки CTR.Tickets.WeChat.QQ.com/Yes/cmzhchordAMthat…
[5] Solving the stragglerproblem with bounded staleness. In HotOS (2013).
[6] TernGrad: Ternary Gradients to Reduce Communication in Distributed Deep Learning
[7] Deep Gradient Compression: Reducing the Communication Bandwidth for Distributed Training