Захватывающий DeepGramAI Hackathon только что завершился, и я хотел поделиться некоторыми из крутых вещей, которые Джон Хеннинг и я построили в эти выходные! Другие интересные проекты на Хакатоне варьировались от декодера речи до математического, чтения мыслей с данными Keras + EEG и семантического парсера для сегментации изображений.

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

При использовании потребительского оборудования для обработки одного изображения с помощью TensorFlow DeepDream только на центральном процессоре требуется от 45 до 90 секунд, а с использованием графического процессора (GPU) - около 5–30 секунд. Чтобы ускорить обработку изображений до ›15 кадров в секунду, мы сначала проверили влияние различных аппаратных компонентов на производительность DeepDream.

Тестирование DeepDream

Сначала мы сравнили производительность DeepDream при обработке одного изображения с использованием TensorFlow 1.01 на Python (код найден здесь):

  • Модель: Начало, 5 ч.
  • Извлечь слой: mixed4d_3x3_bottleneck_pre_relu
  • Параметры: t_obj_filter = 139, iter_n = 10, step = 1,5, octave_n = 4, octave_scale = 1,4

Наш первоначальный тест проводился на Google Cloud Platform (GCP) с использованием экземпляра n1-standard-2 с 2 ЦП, 8 ГБ памяти и 1 NVIDIA K80 GPU. Во всех тестах использовалась платформа параллельных вычислений NVIDIA CUDA, а также библиотека CUDA® Deep Neural Network (cuDNN). В синих столбцах вы можете видеть, что при использовании только ЦП обработка одного изображения заняла больше 1 минуты. Как и ожидалось, использование графического процессора K80 на экземпляре n1-standard-2 ускоряет обработку. В этой конфигурации обработка одного изображения занимала ~ 30 секунд. Затем мы смогли ускорить эту производительность до менее чем 20 секунд, используя более крупный тип инстанса, n1-standard-4, который поставляется с 4 процессорами, 15 ГБ оперативной памяти и тем же графическим процессором NVIDIA K80.

Затем мы проверили, повысит ли производительность новый компилятор Acceleration Linear Algebra (XLA) TensorFlow. Для этого мы скомпилировали ветку TensorFlow r1.0 из исходного кода с параметрами XLA и CUDA на экземпляре n1-standard-4. Я не был уверен, чего ожидать, и был приятно удивлен тем, что с помощью графического процессора мы смогли обработать изображение за ~ 10 секунд (~ 60% увеличение скорости с XLA).

Нашим последним шагом было использование нашего собственного оборудования с 4 ядрами, 64 ГБ ОЗУ и запуск двух новых видеокарт NVIDIA GPU 1080Ti. Эта установка была построена моими коллегами из Silicon Valley Data Science (SVDS), Paul Ho и Jeff Lam. Я определенно рекомендую вам обратиться к этим волшебникам оборудования, если у вас есть какие-либо вопросы по настройке вашего собственного оборудования с несколькими графическими процессорами! Ниже представлено изображение машины с 3 установленными картами (наш тест проводился с двумя картами 1080Ti с мостом SLI).

Используя наше специальное оборудование с включенным XLA, мы наблюдали обработку отдельных изображений за 6,5 секунд, что является значительным улучшением! В будущем мы планируем повторить наш тест с несколькими графическими процессорами на GCP и Amazon Web Services (AWS), чтобы подтвердить наши выводы на нашем нестандартном оборудовании.

Настройка параметров DeepDream

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

Мы обнаружили, что уменьшение числа итераций и октавы сокращает время обработки при одновременном снижении качества изображения. После 5 итераций и 1 октавы время обработки упало до ~ 2,5 секунд, но функции DeepDream в наших изображениях были заметно менее выразительны. Хотя это ожидалось, мы не обнаружили, что время обработки изменялось на число t_obj_filter. Ниже я привел примеры выходных данных, чтобы продемонстрировать разнообразие изображений, которые можно сгенерировать при сохранении всех параметров, кроме константы t_obj_filter:

Приложение iOS для создания изображений DeepDream

В воскресенье утром во время 48-часового хакатона по глубокому обучению мы поняли, что у нас нет рабочего времени (или квоты GCP) для предоставления экземпляра Google Cloud Platform с 8 графическими процессорами K80 для ускорения обработки изображений для потокового видео. По этой причине мы перешли к созданию небольшого приложения для iOS в качестве конечной точки для обслуживания нашей модели DeepDream на нашем экземпляре n1-standard4 GCP.

Сначала мы изменили наш скрипт Python DeepDream, чтобы включить обслуживание модели. Это было достигнуто путем создания собственного класса Python DeepDream. Этот класс имел функциональные возможности для сохранения начального графика v5 в памяти и выполнения вызовов функций для обработки изображения с заданными параметрами. Ниже приведены скриншоты нашего приложения LiveDream, работающего на моем iPhone SE:

Приложение позволяет выбрать:

  • Фильтр: выбор наших любимых фильтров DeepDream в 4-м слое.
  • Уровень. Итерации DeepDream будет запускать изображение.
  • Детализация: масштаб анализируемого изображения (октавы).

Примеры результатов DeepDream с нашего сервера с поддержкой GCP K80 показаны ниже:

Будущие шаги

Хакатон Deep Learning стал прекрасной возможностью изучить, как ускорить обработку DeepDream, и мы с нетерпением ждем улучшения обработки потокового видео DeepDream в будущем! Вот несколько вещей, над которыми мы продолжим работать:

  • Измените веса с float32 на float16 или int, чтобы уменьшить размер модели.
  • Используйте более ранний начальный слой, чтобы сократить общее количество операций
  • Загрузите больше графических процессоров на одну машину на GCP или AWS
  • Используйте разные модели, такие как SqueezeNet (~ 5 МБ), которые не такие большие, как Inception-5h (~ 48 МБ).

Если у вас есть какие-либо вопросы, как мы проводили тестирование, или предложения по улучшениям, обращайтесь в комментарии или в наш репозиторий GitHub.