ML - это весело, ML популярно, ML повсюду. Большинство компаний используют либо TensorFlow, либо PyTorch. Есть, например, олдфаги, которые предпочитают кофе. В основном это все о битве Google и Facebook.

Большая часть моего опыта приходится на PyTorch, хотя в большинстве руководств и онлайн-руководств используется TensofFlow (или, надеюсь, голый numpy). В настоящее время в Lalafo (секретная информация, управляемая ИИ) мы развлекаемся с PyTorch. Нет, правда, мы пробовали caffe, это круто, если вы еще не потратили несколько дней на его установку. Более того, PyTorch сейчас 1.0, мы использовали его с версии 0.3, и он был чертовски простым и надежным. Ааа ... может быть, несколько настроек здесь, несколько настроек там. Большинство проблем было легко исправить и не доставило нам никаких проблем. На самом деле гулять по парку.

Здесь я хочу поделиться 5 наиболее распространенными ошибками при использовании PyTorch в продакшене. Думаете об использовании процессора? Многопоточность? Используете больше памяти графического процессора? Мы прошли через это. Теперь позвольте мне направить вас тоже.

Ошибка №1 - Сохранение динамического графика в режиме вывода.

Если вы когда-то использовали TensorFlow, вы, вероятно, знаете о ключевом различии между TF и ​​PT - статическими и динамическими графиками. Было чрезвычайно сложно отлаживать TFlow из-за перестроения графика каждый раз, когда ваша модель менялась. На это ушло время, усилия и ваша надежда. Конечно, сейчас TensorFlow лучше.

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

Вот как это выглядит на практике:

В большинстве случаев вы хотите оптимизировать все вычисления после обучения модели. Если посмотреть на интерфейс фонарика, там много вариантов, особенно в оптимизации. Много путаницы, вызванной eval режимом, detach и no_grad методами. Разрешите пояснить, как они работают. После обучения и развертывания модели вам будут важны следующие вещи: скорость, скорость и исключение CUDA Out of Memory.

Для ускорения работы модели pytorch необходимо перевести ее в режим eval. Он уведомляет все слои об использовании слоев batchnorm и dropout в режиме вывода (просто говоря, что деактивация пропадает). Теперь есть метод detach, который вырезает переменную из своего вычислительного графа. Это полезно, когда вы создаете модель с нуля, но не очень, когда вы хотите повторно использовать State of Art mdoel. Более глобальным решением было бы переход к torch.no_grad контексту, который сокращает потребление памяти, не сохраняя ссылки на графы в результатах. Это экономит память, упрощает вычисления, таким образом, вы получаете больше скорости и меньше памяти. Бинго!

Ошибка № 2 - Не включаются алгоритмы оптимизации cudnn.

В nn.Module можно установить множество логических флагов, о которых вы должны знать, хранящихся в пространстве имен cudnn. Чтобы включить оптимизацию cudnn, используйте cudnn.benchmark = True. Чтобы убедиться, что cudnn действительно ищет оптимальные алгоритмы, включите его, установив cudnn.enabled = True. NVIDIA делает для вас много волшебства с точки зрения оптимизации, от которой вы могли бы извлечь выгоду.

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

Ошибка № 3 - Повторное использование JIT-компиляции

PyTorch предоставляет простой способ оптимизации и повторного использования ваших моделей с разных языков (прочтите Python-To-Cpp). Вы могли бы быть более креативными и внедрить свою модель на других языках, если вы достаточно смелы (я нет, CUDA: Out of memory - мой девиз)

JIT-компиляция позволяет оптимизировать вычислительный граф, если входные данные не меняют форму. Это означает, что ваши данные не слишком сильно различаются (см. Ошибка № 2). JIT - это правильный выбор. Честно говоря, это не имело большого значения по сравнению с no_grad и cudnn, упомянутыми выше, но может. Это только первая версия и имеет огромный потенциал.

Имейте в виду, что это не сработает, если в вашей модели есть conditions, что является обычным случаем в RNN.

Полную документацию можно найти на pytorch.org/docs/stable/jit.

Ошибка №4 - попытка масштабирования с использованием экземпляров ЦП

Графические процессоры дороги, как виртуальные машины в облаке. Даже если вы проверите AWS, один экземпляр будет стоить около 100 долларов в день (самая низкая цена - 0,7 доллара в час). Ссылка: aws.amazon.com/ec2/pricing/on-demand/. Еще одна полезная памятка, которую я использую, - это www.ec2instances.info. Каждый человек, окончивший 3-й класс, может подумать: Хорошо, а что, если я куплю 5 экземпляров ЦП вместо 1 ГП. Каждый, кто пробовал запустить модель NN на CPU, знает, что это тупик. Да, вы можете оптимизировать модель под CPU, но в итоге она все равно будет медленнее, чем модель GPU. Настоятельно рекомендую расслабиться и забыть об этой идее, поверьте мне.

Ошибка №5 - Обработка векторов вместо матриц.

  • cudnn - проверить
  • no_grad - проверить
  • GPU with correct version of CUDA - проверить
  • JIT-compilation - проверить

Все готово, что еще можно сделать?

Пришло время немного математики. Если вы помните, как большая часть NN обучается с использованием так называемых тензоров. С математической точки зрения тензор - это N-мерный массив или полилинейные геометрические векторы. Что вы можете сделать, так это сгруппировать входные данные (если у вас есть такая роскошь) в тензоры или матрицу и ввести их в свою модель. Например, используя массив изображений в качестве матрицы, отправленной в PyTorch. Прирост производительности равен количеству одновременно переданных объектов.

Это очевидное решение, но мало кто на самом деле его использует, поскольку большую часть времени объекты обрабатываются один за другим, и может быть немного сложно настроить такой поток архитектурно. Не волнуйтесь, у вас все получится!

Что дальше?

Определенно есть больше советов о том, как оптимизировать модели в PyTorch. Я буду продолжать публиковать сообщения о нашем опыте использования Facebook kid в дикой природе. Что насчет вас, каковы ваши советы по повышению эффективности вывода?

Первоначально опубликовано на tarasmatsyk.com 18 февраля 2019 г.