Deep Learning Inference Benchmark — измеряем скорость работы моделей глубокого обучения
Перед разработчиками встает задача определения производительности железа в задаче исполнения глубоких моделей. Например, хочется решить проблему анализа пола-возраста покупателей, которые заходят в магазин, чтобы в зависимости от этого менять оформление магазина или наполнение товаром. Вы уже знаете какие модели хотите использовать в вашем ПО, но до конца не понятно как выбрать железо. Можно выбрать самый топ и переплачивать как за простаивающие мощности, так и за электроэнергию. Можно взять самый дешевый i3 и потом вдруг окажется, что он может вывезти каскад из нескольких глубоких моделей на 8 камерах. А может быть камера всего одна, и для решения задачи достаточно Raspberry Pi с Movidius Neural Compute Stick? Поэтому хочется иметь инструмент для оценки скорости работы вашего инференса на разном железе, причем еще до начала обучения.
В целом можно выделить три направления работы с глубокими моделями:
Общую схему решения задач с использованием глубокого обучения можно представить следующим образом:
Из лекции курса по современным методам и технологиям глубокого обучения в компьютерном зрении
Как правило, требования по скорости заложены еще на этапе постановки задачи, и хочется еще до начала обучения или дообучения узнать «уложится» или нет предполагаемая модель в доступные для инференса ресурсы. И для решения этой задачи был создан DLI benchmark.
DLI benchmark
В рамках лаборатории ITLab студентами ННГУ им. Н.И.Лобачевского был разработан открытый фреймворк DLI (https://github.com/itlab-vision/dl-benchmark), который позволяет запустить измерение производительности большого количества разных моделей на доступном железе.
Основные требования, которые были заложены на этапе разработки:
Архитектура фреймворка
Схема со страницы проекта
Алгоритм работы DLI-benchmark:
Типы экспериментов
При обработке картинок по одной вычислительное устройство очень часто недогружено. Можно подать два изображения одной пачкой (batch=2), тогда они обработаются быстрее чем два изображения по отдельности. При увеличении размера пачки производительность сначала начнет расти, а потом падать, и определить лучший размер пачки весьма полезно.
В современных фреймворках поддерживается асинхронный режим работы, когда не нужно дожидаться конца обработки предыдущего изображения, можно новую картинку начать обрабатывать сразу после поступления. При использовании асинхронного API в OpenVINO можно создавать реквесты по 1 картинке независимо и при этом получать по прежнему высокую производительность и при этом низкие задержки. Возможность получать высокую производительность, сохраняя при этом низкие задержки, открывает новые возможности для инференса глубоких моделей на многосокетных высокопроизводительных системах.
Метрики производительности
В случае когда мы можем подавать несколько картинок независимо друг от друга (асинхронный запуск на обработку), мы используем другие метрики производительности.
Анализ результатов
В ходе экспериментов мы попробовали бенчмарк на различном оборудовании: CPU i7-7700K, i5-8600K, i3-7100, i7-8700, i3-8100, GPU Intel HD Graphics 630, Intel Neural Compute Stick 2.
Пока опубликовали результаты только для фреймворка OpenVINO. Докеры бенчмарка с Caffe, TensofFlow и PyTorch в разработке.
Для демонстрации примеров работы возьмем модель ResNet-152 — это очень объемная модель, которая решает задачу классификации ImageNet.
На графике ниже представлена время обработки одной пачки картинок в различных режимах. На данном графике по оси X отложено количество потоков процессора, которые были использованы для обработки изображений, а по оси Y — среднее время обработки (или задержка, latency) одной пачки изображений. На этом графике мы видим, что при удвоении использованных потоков скорость обработки увеличивается примерно в два раза — это означает отличную параллеллизацию в обработке изображений. Что важно, параллелизация показывает хорошие результаты и для большой пачки картинок, и для одиночной картинки.
Чтобы посчитать FPS (сколько в среднем картинок в секунду обработает процессор в каждом режиме работы) нужно количество картинок в пачке разделить на время обработки одной пачки. Эти данные мы приведем в таблице ниже.
Взглянув на эти цифры, мы видим, что если мы будем использовать все 6 ядер процессора, что при обработке картинок пачками по 8 штук производительность возрастает на 20% из-за более плотной упаковки вычислений. Но в прикладном ПО не слишком хочется писать дополнительные функции, чтобы собирать картинки в пачки, да и задержки тогда возрастают…
В этом случае нам на помощь приходит асинхронный запуск нескольких картинок на обработку! OpenVINO поддерживает возможность не собирать из картинок большую пачку, а подавать картинки независимо друг от друга не дожидаясь завершения обработки предыдущей. В данном режиме вы задаете в программе количество «стримов» (это не поток процессора; это сущность, которая захватывает один или несколько потоков процессора и обрабатывает в себе картинку), и можете независимо запускать на обработку картинки по мере поступления.
С использованием OpenVINO в асинхронном режиме с размером пачки в 1 картинку мы почти достигаем производительности, полученной в синхронном режиме с размером пачки 8, при этом почти не меняя код запуска моделей.
Хранилища признаков: Сторона данных в конвейерах машинного обучения
Нам нужен обоснованный способ управления состоянием в ML конвейерах, работающих в реальном времени.
Оригинальная статья авторства Sarah Wooders, Peter Schafhalter, and Joey Gonzalez
Восход* Хранилищ Признаков
По мере того как все больше моделей развертывается в современных конвейерах, снова и снова возникает понимание, что данные и их фичаризация** (featurization) важнее всего остального. Последнее поколение систем больших данных масштабировало ML на реальные датасеты, теперь хранилища данных быстро становятся новым рубежом для подключения моделей к данным в реальном времени [1].
Поддержание признаков в актуальном состоянии является критически важным для точности модели, но дорогостоящим и тяжело масштабируемым
Хранилища признаков, как следует из названия, хранят признаки, полученные из необработанных данных, и предоставляют их последующим моделям для обучения и ифнеренса***. Например, в хранилище признаков могут храниться последние несколько страниц, которые просматривал пользователь (т.е. скользящее окно по маршруту переходов по сайту), а также последние предсказанные демографические данные пользователя (т.е. предсказание некоторой модели), которые могут быть ценными признаками для модели таргетинга рекламы.
К сожалению, многие хранилища признаков, создаваемые сегодня, представляют собой Франкенштейнов из систем пакетной обработки, потоковых систем, систем кэширования и систем хранения данных.
В этом посте мы (1) определим, что такое хранилища признаков и как они используются сегодня, (2) выделим некоторые ограничения в дизайне текущего поколения хранилищ признаков и (3) опишем, как инновации в дизайне хранилищ признаков могут изменить промышленное машинное обучение, управляя состоянием в конвейерах обучения и инференса более обоснованным образом.
Предпосылки
Зачем хранилища признаков?
Простой ML конвейер обучает модель на основе статического набора данных, а затем предоставляет модель для ответа на пользовательские запросы об инференсе.
Прогнозы формируются на основе параметров модели и данных запроса.
Однако для того, чтобы адаптироваться к постоянно меняющемуся миру, современные ML конвейеры должны принимать решения, которые зависят от данных в реальном времени [2]. Например, модель, предсказывающая время прибытия, может использовать такие характеристики, как время выполнения недавнего заказа в ресторане, или модель рекомендации контента может учитывать последние клики пользователя. Поэтому обучение и инференс моделей опираются на признаки, получаемые в реальном времени в результате соединения, преобразования и агрегирования входящих потоков данных. Поскольку этап фичаризации может быть дорогостоящим, признаки должны быть предварительно вычислены и закэшированы, чтобы избежать избыточных вычислений и удовлетворить жесткие требования к времени задержки предсказания.
Предсказания также опираются на характеристики, полученные из потоков данных в реальном времени.
Что такое хранилище признаков?
Хранилища признаков используются для хранения и поставки признаков в нескольких частях конвейера, что позволяет проводить совместные вычисления и оптимизацию. Хотя различные хранилища признаков различаются по своей функциональности, они обычно управляют следующим:
Поставкой признаков для удовлетворения различных требований к задержке запросов. Признаки обычно размещаются как в быстром «онлайн хранилище» (для запросов во время инференса), так и в долговечном «офлайн хранилище» (для запросов во время обучения).
Делают признаки совместимыми и дополняемыми. Как только признак определен, его должно быть легко соединить с последующими моделями, получить из него дополнительные признаки или переопределить схему признака или функцию фичаризации.
Поддержание признаков, полученных из данных реального времени. Поддержание таких характеристик требует больших ресурсов, и устаревшие характеристики могут негативно повлиять на эффективность прогнозирования.
Некоторые признаки (например, результаты агрегации по временному окну длиной в 1 минуту) очень чувствительны к устареванию и должны быть сверхсвежими, в то время как другие (например, 30-дневные окна) могут нуждаться только в периодическом пакетном обновлении. Как система, которая взаимодействует как с обновлениями признаков, так и с запросами на их получение, хранилища функций имеют хороший задел на оптимальное соотношение между свежестью, задержкой и стоимостью.
Хранилища признаков сегодня: Вызовы и ограничения
На сегодня уже многие компании имеют внутренние разработки хранилищ данных. Сделано это для того, чтобы признаки были доступны для моделей, развернутых в продуктиве.
В таблице выше примеры использования хранилищ признаков
Сегодня хранилища признаков строятся на базе существующих систем потоковой передачи, пакетной обработки, кэширования и хранения данных. Хотя каждая из этих систем в отдельности решает сложные задачи, их ограничения создают проблемы для хранилищ признаков.
Системы пакетной обработки, такие как Spark, позволяют выполнять сложные запросы к статическим наборам данных, но вносят чрезмерную задержку при поставка признаков и вызывают полный перерасчет при пополнении данных.
Потоковые системы, такие как Flink и Spark Streaming, обеспечивают конвейерные вычисления с низкой задержкой, но оказываются неэффективными, когда требуется поддерживать большое количество состояний. Лямбда-архитектуры объединяют пакетные и потоковые системы, но приводят к дорогостоящим дублирующим вычислениям и сложному обслуживанию как потоковых, так и пакетных кодовых баз.
Потоковые базы данных с материализованными представлениями (materialized views) обладают преимуществами быстрого вычисления и хранения, но их трудно адаптировать к произвольным операциям фичаризации. Их задержки также могут быть слишком высокими для обслуживания предсказаний.
Хранилища в оперативной памяти типа «ключ-значение», такие как Redis, обеспечивают быстрый доступ к признакам, но их обычно сложно последовательно обновлять и дорого масштабировать.
Многие требования к хранилищам признаков можно удовлетворить с помощью комбинации этих систем. Однако полученный в результате конвейер является жестким и трудно оптимизируемым как целое. Например, определение приоритетов задач фичаризации на основе их влияния на общую точность прогнозирования потребует координации между хранилищем данных, принимающим запросы, потоковой системой, передающей обновления в реальном времени, и системой пакетной обработки исторических данных. Вместо того, чтобы неуклюже комбинировать несколько движков вычислений с несколькими базами данных для достижения различных целей по задержке, хранилища признаков должны использовать преимущества своего доступа к входящим событиям и шаблонам запросов для оптимизации задержки, стоимости вычислений и точности прогнозирования централизованным образом.
Будущее хранилищ признаков
Мы считаем, что хранилища признаков могут предложить централизованное управление состояниями для ML конвейеров и имеют большой потенциал для этого:
Управляение жизненным циклом данных (Lineage Management). Хранилища признаков открывают дверь к новой, ориентированной на данные абстракции для разработки и настройки конвейеров машинного обучения. Сложность существующих конвейеров машинного обучения часто затрудняет обеспечение базовой воспроизводимости, применение изменений в конвейере или оптимизацию всего конвейера. Хотя тщательное версионирование и синхронизация могут в определенной степени решить эти проблемы, сложно представить применении этих методов к постоянно меняющимся наборам данных. Ориентированный на данные взгляд на конвейеры (например, рассмотрение конвейеров данных как материализованных представлений) имеет потенциал для введения новых абстракций, которые упростят процесс распространения изменений данных и операторов.
Сквозная оптимизация. Хранилища признаков имеют все шансы обеспечить новую сквозную оптимизацию в конвейерах данных для машинного обучения. Существующие системы производят вычисления либо событиями, либо запросами, что затрудняет планирование задач таким образом, чтобы оптимизировать такие метрик, как производительность прогнозирования и стоимость. Специалисты-практики должны иметь возможность настраивать свои конвейеры для оптимизации затрачиваемых средств (ленивые вычисления/ обновления, приблизительные результаты), задержки выводов (немедленные вычисления) или общей производительности прогнозирования (обновление признаков с наибольшим влиянием).
Масштабируемое управление состоянием. Хранилища признаков требуют масштабируемой поддержки и сохранения состояния в конвейерах ML. Промышленные ML конвейеры, работающие в реальном времени, часто нуждаются в поддержании десятков миллионов характеристик, полученных из множества входящих плотных потоков данных. Наборы признаков могут быть слишком большими, чтобы хранить их в памяти или обновлять при каждом входящем событии из потока, как это по умолчанию делает система обработки потоков, но при этом их необходимо обновлять чаще, чем это позволяет система пакетной обработки.
Заключение
Мы активно изучаем дизайн систем хранилищ признаков, поэтому дайте нам знать, если вы заинтересованы в том, чтобы быть в курсе последних новостей или сотрудничать!
Если вы хотите принять участие в наших исследованиях, не стесняйтесь обращаться по адресу wooders@berkeley.edu.
Заметки
[1] Под «данными реального времени» мы подразумеваем данные, которые необходимо оперативно обрабатывать в режиме реального времени, как в контексте поставки прогнозов в режиме онлайн, так и для поддержания свежести данных для функций.
[2] Обновления данных «реального времени» обычно должны составлять порядка нескольких секунд, но могут варьироваться в зависимости от рабочей нагрузки.
Благодарности
Спасибо Manmeet Gujral, Gaetan Castelein, и Kevin Stumpf из Tecton, а также Joe Hellerstein, Natacha Crooks, Simon Mo, Richard Liaw, и другим членам RISELab за предоставленную обратную связь по этому посту.
Variational Inference — что это такое и с чем это едят?
Недавно пообщался с коллегами о вариационном автоэнкодере и выяснилось что многие даже работающие в Deep Learning знают о вариационном выводе (Variational Inference) и в частности Нижней вариационной границе только по наслышке и не до конца понимают что это такое.
В этой статье я хочу подробно разобрать эти вопросы. Кому интересено, прошу под кат — будет очень интересно.
Что такое вариационный вывод?
Семейство вариационных методов машинного обучения получили свое название от раздела математического анализа «Вариационного исчисления». В этом разделе изучаются задачи поиска экстремумов функционалов (функционал это функция от функций — т.е мы ищем не значения переменных в которых функция достигает своего максимума (минимума), а такую функцию при которой функционал достигает максимума (минимума).
Но возникает вопрос — в машинном обучении мы всегда ищем точку в пространстве параметров (переменных) в которых функция потерь имеет минимальное значение. Т.е это задача классического математического анализа, причем здесь Вариационное исчисление? Вариационное исчисление появляется в момент когда мы преобразуем функцию потерь в другую функцию потерь (зачастую это нижняя вариационная граница) используя методы вариацонного исчисления.
Зачем же нам это нужно? Разве нельзя напрямую оптимизировать функцию потерь? Эти методы нам необходимы когда напрямую получить несмещенную оценку градиента невозможно (либо эта оценка обладает очень высокой дисперсией). Например наша модель задает 
и 
, а нам необходимо вычислить 
. Это как раз, то для чего разрабатывался вариационный автоэнкодер.
Что такое Нижняя вариационная граница (Variational Lower Bound)?
Т.е у любой функции существует бесчетное множество нижних границ. Все ли эти нижние границы одинаковы? Конечно нет. Введем еще одно понятие — невязка (я не нашел устоявшегося термина в русскоязычной литературе, в англоязычных статьях эту величину называют tightness):
Достаточно очевидно, что невязка всегда положительна. Чем меньше невязка — тем лучше.
Вот пример нижней границы с нулевой невязкой:
А вот пример с небольшой, но положительной невязкой:
И наконец, достаточно большая невязка:
Из приведенных выше графиков отчетливо видно что при нулевой невязке максимум функции и максимум нижней границы находятся в одной точке. Т.е если мы хотим найти максимум некоторой функции, мы можем искать максимум нижней границы. В случае если невязка не нулевая, то это не так. И максимум нижней границы может быть очень далеко (по оси х) от искомого максимума. Из графиков видно что чем больше невязка, тем дальше максимумы могут быть друг от друга. В общем случае это неверно, но в большинстве практических случаев эта интуиция работает очень хорошо.
Вариационный автоэнкодер
Сейчас мы разберем пример очень хорошей нижней вариационной границы с потенциально нулевой невязкой (ниже будет понятно почему) — это Вариационный автоэнкодер (Variational Autoencoder).
Наша задача построить генеративную модель и обучить ее методом максимального правдоподобия. Модель будет иметь следующий вид:
где 
— плотность вероятности генерируемых семплов, 
— латентные переменные, 
— плотность вероятности латентной переменной (зачастую некая простая — например многомерное гауссовское распределение с нулевым матожиданием и единичной дисперсией — в общем что-то из чего мы можем легко семплировать), 
— условная плотность семплов при заданном значении латентных переменных, в вариационном автоэнкодере выбирается гауссовское с мат ожиданием и дисперсией зависящими от z.
Зачем нам может понадобиться представлять плотность данных в таком сложном виде? Ответ прост — данные имеют очень сложную функцию плотности и мы просто технически не можем построить модель такой плотности напрямую. Мы надеемся что эту сложную плотность можно хорошо аппроксимировать с помощью двух более простых плотностей и .
Мы хотим максимизировать следующую функцию:
где 
— плотность вероятности данных. Основная проблема в том, что плотность (при достаточно гибких моделях) не удается представить аналитически, а соответственно обучать модель.
Используем формулу Байеса и перепишем нашу функцию в следующем виде:
К сожалению, 
все также сложно посчитать (невозможно взять интеграл аналитически). Но во-первых заметим что выражение под логарифмом не зависит от z, значит можно взять математическое ожидание от логарифма по z от любого распределения и это не изменит значения функции и под знаком логарифма умножить и поделить на это же распределение (формально мы имеем лишь одно условие — данное распределение нигде не должно обращаться в нуль). В итоге мы получим:
заметим что во-первых второе слагаемое — KL дивергенция (а значит всегда положительна):
и во-вторых 
не зависит ни от 
ни от 
. Отсюда следует что,
= \int
где 
— нижняя вариационная граница (Variational Lower Bound) и достигает своего максимума когда 
— т.е распределения совпадают.
Положительность и равенство нулю тогда и только тогда когда распределения совпадают KL-дивергенции доказываются именно вариационными методами — отсюда и название вариационная граница.
Хочу заметить, что использование вариационной нижней границы дает несколько преимуществ. Во-первых дает нам возможность оптимизировать функцию потерь градиентными методами (попробуйте сделать это когда интеграл аналитически не берется) и во-вторых приближает обратное распределение распределением — т.е мы можем не только семплировать данные, но и семплировать латентные переменны. К сожалению, главный недостаток — при недостаточно гибкой модели обратного распределения, т.е когда семейство не содержит — невязка будет положительной и равной:
а это означает что максимум нижней границы и функции потерь скорее всего не совпадают. Кстати, вариационный автоэнкодер примененный для генерации картинок генерирует слишком смазанные изображения, думаю это как раз из-за выбора слишком бедного семейства .
Пример не очень хорошей нижней границы
Сейчас мы рассмотрим пример, где с одной стороны нижняя граница обладает всеми хорошими свойствами (при достаточно гибкой модели невязка будет нулевой), но в свою очередь не дает никакого преимущества перед использованием оригинальной функции потерь. Я считаю, что этот пример является очень показательным и если не делать теоретический анализ можно потратить очень много времени пытаясь обучать модели которые не имеют никакого смысла. Вернее модели имеют смысл, но если мы можем обучить такую модель, то уже проще выбирать из этого же семейства и использовать принцип максимального правдоподобия напрямую.
Итак, мы будем рассматривать точно такую же генеративную модель как и в случае вариационного автоэнкодера:
обучать будем все тем же методом максимального правдоподобия:
Мы все так же надеемся, что 
будет намного «проще» чем .
Только теперь распишем немного по-другому:
используя формулу Дженсена (Jensen) получим:
=\int
Вот именно в этом моменте большинство людей отвечают не задумавшись, что это действительно нижняя граница и можно обучать модель. Это действительно так, но давайте посмотрим на невязку:
откуда (применив формулу Ьайеса два раза):
легко заметить, что:
Давайте посмотрим что будет если мы будем увеличивать нижнюю границу — невязка будет уменьшаться. При достаточно гибкой модели:
казалось бы все отлично — нижняя граница обладает потенциально нулевой невязкой и при достаточно гибкой модели все должно работать. Да это действительно так, только внимательные читатели могут заметить что нулевая невязка достигается когда 
и являются независимыми случайными величинами. и для хорошего результата «сложность» распределения должна быть ничуть не меньше чем . Т.е нижняя граница не дает нам никаких преимуществ.
Выводы
Нижняя вариационная граница — отличный математический инструмент, позволяющий приближенно оптимизировать «неудобные» для обучения функции. Но как и любой другой инструмент нужно очень хорошо понимать его преимущества и недостатки а также использовать очень аккуратно. Мы рассмотрели очень хороший пример — вариационный автоэнкодер, а также пример не очень хорошей нижней границы, при этом проблемы этой нижней границы сложно увидеть без детального математического анализа.
Надеюсь это было хоть немного полезно и интересно.