Большое спасибо за статью, очень люблю эту тематику. Иногда полезно почитать такие общие статьи для повторения и актуализации информации в голове. Дополню насчет float32 -> float16. К сожалению, на практике после такой конвертации теряется довольно важная часть точности. Она может слабо выражаться в метриках, но иногда после такого сети непригодны для моментальной отправки в прод. Не рекламируюсь ни в коем случае, но вот в своей статье описывал, к чему это иногда ведет -https://habr.com/ru/post/558406/. Желательно даже при таком квантовании использовать Quantization Aware Training, который, благо, реализуется в 1 строчку в TF или PyTorch. Ну и насчет скорости работы - смотря что считать большим ускорением. У нас получилось около 2х к скорости обработки. Учитывая относительную простоту float32 -> float16 получается очень высокий КПД. А вот при квантовании float32 -> int8 нужно потратить довольно много усилий, чтобы это заработало с достаточной точностью. Знаю, что такое часто делают для мобилок в различных GANах и дифьюзерах, т.к. визуальный результат клиента удовлетворяет. А вот если стоит задача детекции, классификации и тд, где наша метрика точности более осязаема - возникают большие проблемы. Ну и тут сложнее с Quantization Aware Training - методики вроде как есть, но это уже не одна строчка и часто ломаются оптимизаторы. Если вы знакомы с хорошими методиками Quantization Aware Training для int8, то поделитесь. Я уже полгода не смотрел новых работ по этой теме
И насчет Pruning - там тоже есть 2 варианта: Post Training и During Training. Первый вариант на моей практике был не очень полезным, без потери точности получалось вырезать лишь малую часть. А вот второй вариант пока руки не дошли попробовать. Подскажите, может был опыт? Очень интересны практические результаты
Попробуйте добавить center_loss - он без перевода в сферические координаты. Должно дать значимый буст в точности работы. Всё таки метрик лернинг на чистом CE не совсем ту задачу решает. Линейное разделение не гарантирует скученность векторов
Мы решили экспериментировать дальше. Вытащили из обученной сети результирующие векторы по всем нашим изображениям, затем искали ближайшие векторы к картинке-запросу.
Правильно ли я понимаю, что вы взяли вектора с предпоследнего слоя классифицирующей сети? Использовали какие-то доп лоссы - sphere-loss или cosine-loss для компактного сбора векторов в гиперпространстве?
А вы везунчик! Я ни разу не получал в простом Colab что-то из T4/P100. Так или иначе, для Pro выделение мощных GPU в приоритете и происходит чаще(о чем написано в официальной документации). В любом случае, несколько коробит такая ситуация, когда скорость обучения твоей сети зависит от воли случая. А про 4vCPU не знал, спасибо за замечание!
Круто, что у тебя есть такой опыт. Думаю, радужность, моего отзыва следуют как раз из недостаточно сложной задачи и окружения. Единственной проблемой для меня стал неподдерживаемый SEPARABLECONV2D, который потратил сравнимо меньше моих нервов. Значит, есть причина ещё раз задуматься о применимости DataSphere для больших проектов
Про формат входных данных хорошее замечание, тоже наблюдали. Насчёт запуска Yolov3 - не знаю, в чем проблема. Мы на этой же версии Trt и yolov3 конвертится без проблем. Опять же, только если проблема в слое Upsample.
Спасибо за вопрос.
TensorRT для float16 inference использует Tensor cores. Да, тут важно говорить как ускорение для 1 потока в 2 раза за счет float16 вычислений, так и про увеличение пропускной способности памяти с особенностями вычислений в tensor cores.
Наш опыт такой — при работе в 1 потоке мы получаем ускорение 2х. Однако, если говорить про многопоточную обработку, то ситуация интереснее. Во float32 на TF мы можем обрабатывать параллельно 2.5 потока видео 30 fps. При переходе на float16 в TensorRT производительность вырастает до 8 потоков 30 fps. Т.е. фактически при полной утилизации tensor cores мы получили увеличение производительности в 3.2 раза — несколько меньше теоретически максимальной. Скорее всего, это связано с тем, что мы обрабатываем потоки с батчем = 1, чтобы не увеличивать latency прихода данных по каждому кадр.
Чекнул. Да, интересное решение, как-то упустил его из виду. Спасибо)
Задача — детектирование автомобилей в одной плоскости. За счёт отсутствия перекрытий и одного масштаба задача сильно упрощается и получается высокий mAp75
Время выполнения кода на ПК составило 0.5с при расчетах на CPU и 2с (!) при расчете на GPU. Судя по логу, проблема то ли в модели, то ли в Tensorflow, но при запуске код пытается выделить много памяти, получая на выходе несколько warnings вида «Allocator (GPU_0_bfc) ran out of memory trying to allocate 2.13GiB with freed_by_count=0.». Это warning а не error, код при этом работает, но гораздо медленнее чем должен был бы.
Мерять время по одному прогону одной картинки — это плохая практика, вообще говоря. Особенность устройства TF такова, что необходим первый WarmUp прогон, когда выделиться необходимая память.
Поэтому крайне сомневаюсь в предоставленных цифрах. Попробуй взять среднее по 50 прогонам без учета самого первого — тогда это будет честно :)
Возможно, это наоборот улучшает результат.
У них же так разгружаются линии RAM и кэша.
Плюс оптимальная производительность достигается явно не при 100% загрузки.
Кстати, это чувствуется при обучении. Если стоят одновременно и карта, и процессор от AMD, то оба оказываются загружены где-то на 50-60%.
Я не смог разобраться точно, в чем дело.
Но вероятно, что из-за этой фичи OPENCL часть ядер создаётся для CPU
Полностью согласен насчёт продакшена.
Считаю, данный подход в большинстве своём актуален в рамках прототипирования на Керасе и вывода моделей на нетипичные вычислительные устройства.
Neural Network Optimization: океан в капле
Большое спасибо за статью, очень люблю эту тематику. Иногда полезно почитать такие общие статьи для повторения и актуализации информации в голове.
Дополню насчет float32 -> float16. К сожалению, на практике после такой конвертации теряется довольно важная часть точности. Она может слабо выражаться в метриках, но иногда после такого сети непригодны для моментальной отправки в прод. Не рекламируюсь ни в коем случае, но вот в своей статье описывал, к чему это иногда ведет -https://habr.com/ru/post/558406/. Желательно даже при таком квантовании использовать Quantization Aware Training, который, благо, реализуется в 1 строчку в TF или PyTorch.
Ну и насчет скорости работы - смотря что считать большим ускорением. У нас получилось около 2х к скорости обработки. Учитывая относительную простоту float32 -> float16 получается очень высокий КПД.
А вот при квантовании float32 -> int8 нужно потратить довольно много усилий, чтобы это заработало с достаточной точностью. Знаю, что такое часто делают для мобилок в различных GANах и дифьюзерах, т.к. визуальный результат клиента удовлетворяет. А вот если стоит задача детекции, классификации и тд, где наша метрика точности более осязаема - возникают большие проблемы. Ну и тут сложнее с Quantization Aware Training - методики вроде как есть, но это уже не одна строчка и часто ломаются оптимизаторы. Если вы знакомы с хорошими методиками Quantization Aware Training для int8, то поделитесь. Я уже полгода не смотрел новых работ по этой теме
И насчет Pruning - там тоже есть 2 варианта: Post Training и During Training. Первый вариант на моей практике был не очень полезным, без потери точности получалось вырезать лишь малую часть. А вот второй вариант пока руки не дошли попробовать. Подскажите, может был опыт? Очень интересны практические результаты
Технология компьютерного зрения с функциями бесконтактного контроля температуры и режима ношения средств защиты
Намного интереснее, как вы решайте задачу в крайних случаях - например в забитых автобусах?
Распознавание номерных знаков. Как все ускорить
Не пробовали вместо YOLOv5+CRAFT использовать одну WPOD-NET? Будет значительно быстрее и сразу отнормировано
Нечего надеть? Computer Vision в помощь
Попробуйте добавить center_loss - он без перевода в сферические координаты. Должно дать значимый буст в точности работы. Всё таки метрик лернинг на чистом CE не совсем ту задачу решает. Линейное разделение не гарантирует скученность векторов
Нечего надеть? Computer Vision в помощь
Правильно ли я понимаю, что вы взяли вектора с предпоследнего слоя классифицирующей сети? Использовали какие-то доп лоссы - sphere-loss или cosine-loss для компактного сбора векторов в гиперпространстве?
ML в облаке: как я попробовал Yandex DataSphere и почему его так непросто сравнить с Google Colab
А вы везунчик! Я ни разу не получал в простом Colab что-то из T4/P100. Так или иначе, для Pro выделение мощных GPU в приоритете и происходит чаще(о чем написано в официальной документации). В любом случае, несколько коробит такая ситуация, когда скорость обучения твоей сети зависит от воли случая. А про 4vCPU не знал, спасибо за замечание!
ML в облаке: как я попробовал Yandex DataSphere и почему его так непросто сравнить с Google Colab
Круто, что у тебя есть такой опыт. Думаю, радужность, моего отзыва следуют как раз из недостаточно сложной задачи и окружения. Единственной проблемой для меня стал неподдерживаемый SEPARABLECONV2D, который потратил сравнимо меньше моих нервов. Значит, есть причина ещё раз задуматься о применимости DataSphere для больших проектов
ML в облаке: как я попробовал Yandex DataSphere и почему его так непросто сравнить с Google Colab
Quantization Aware Training. Или как правильно использовать fp16 inference в TensorRT
Про формат входных данных хорошее замечание, тоже наблюдали. Насчёт запуска Yolov3 - не знаю, в чем проблема. Мы на этой же версии Trt и yolov3 конвертится без проблем. Опять же, только если проблема в слое Upsample.
Quantization Aware Training. Или как правильно использовать fp16 inference в TensorRT
Quantization Aware Training. Или как правильно использовать fp16 inference в TensorRT
TensorRT для float16 inference использует Tensor cores. Да, тут важно говорить как ускорение для 1 потока в 2 раза за счет float16 вычислений, так и про увеличение пропускной способности памяти с особенностями вычислений в tensor cores.
Наш опыт такой — при работе в 1 потоке мы получаем ускорение 2х. Однако, если говорить про многопоточную обработку, то ситуация интереснее. Во float32 на TF мы можем обрабатывать параллельно 2.5 потока видео 30 fps. При переходе на float16 в TensorRT производительность вырастает до 8 потоков 30 fps. Т.е. фактически при полной утилизации tensor cores мы получили увеличение производительности в 3.2 раза — несколько меньше теоретически максимальной. Скорее всего, это связано с тем, что мы обрабатываем потоки с батчем = 1, чтобы не увеличивать latency прихода данных по каждому кадр.
Джедайская техника уменьшения сверточных сетей — pruning
Чекнул. Да, интересное решение, как-то упустил его из виду. Спасибо)
Задача — детектирование автомобилей в одной плоскости. За счёт отсутствия перекрытий и одного масштаба задача сильно упрощается и получается высокий mAp75
Джедайская техника уменьшения сверточных сетей — pruning
Здесь YOLOv3 описан как хороший вариант для бейзлайна по доступности и простоте)
27 вещей, которые я хотел бы узнать заранее, прежде чем начинать программировать
NVIDIA Jetson Nano: тесты и первые впечатления — часть 2, тесты AI
Мерять время по одному прогону одной картинки — это плохая практика, вообще говоря. Особенность устройства TF такова, что необходим первый WarmUp прогон, когда выделиться необходимая память.
Поэтому крайне сомневаюсь в предоставленных цифрах. Попробуй взять среднее по 50 прогонам без учета самого первого — тогда это будет честно :)
Практическое использование нейросетей
Почему не стоит выкидывать Radeon, если ты увлекся машинным обучением?
Возможно, когда-то напишу сравнительную статью про разные другие бэкенды
Почему не стоит выкидывать Radeon, если ты увлекся машинным обучением?
Возможно, это наоборот улучшает результат.
У них же так разгружаются линии RAM и кэша.
Плюс оптимальная производительность достигается явно не при 100% загрузки.
Почему не стоит выкидывать Radeon, если ты увлекся машинным обучением?
Кстати, это чувствуется при обучении. Если стоят одновременно и карта, и процессор от AMD, то оба оказываются загружены где-то на 50-60%.
Я не смог разобраться точно, в чем дело.
Но вероятно, что из-за этой фичи OPENCL часть ядер создаётся для CPU
Почему не стоит выкидывать Radeon, если ты увлекся машинным обучением?
Полностью согласен насчёт продакшена.
Считаю, данный подход в большинстве своём актуален в рамках прототипирования на Керасе и вывода моделей на нетипичные вычислительные устройства.