Рекомендую первые главы книги Константинова "Стратегическое Мышление", там наиболее понятный для меня набор видов мышления. С представленной здесь классификацией не совсем согласен (и не понял, на какой литературе она построена? Питер Сенге?). Процессное мышление - что-то вообще новое для меня.
Ощущение, что всё смешалось - кони, люди. Одни виды мышления судя по статье становятся навыками другого - странно для меня. Нужно определять, по какому признаку мы производим классификацию видов мышления. Это уже не к вашему комментарию, а к статье в целом
Статья для новичков, наверное, полезная. Но есть одна важная ошибка, которой не стоит их учить - pip install keras и дальше импорт из него. keras сейчас полностью мигрировал внутрь tf и правильно вызывать tf.keras и импорты слоёв делать тоже оттуда
Большое спасибо за статью, очень люблю эту тематику. Иногда полезно почитать такие общие статьи для повторения и актуализации информации в голове. Дополню насчет 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% загрузки.
Рекомендую первые главы книги Константинова "Стратегическое Мышление", там наиболее понятный для меня набор видов мышления. С представленной здесь классификацией не совсем согласен (и не понял, на какой литературе она построена? Питер Сенге?). Процессное мышление - что-то вообще новое для меня.
Ощущение, что всё смешалось - кони, люди. Одни виды мышления судя по статье становятся навыками другого - странно для меня. Нужно определять, по какому признаку мы производим классификацию видов мышления. Это уже не к вашему комментарию, а к статье в целом
Статья для новичков, наверное, полезная. Но есть одна важная ошибка, которой не стоит их учить - pip install keras и дальше импорт из него. keras сейчас полностью мигрировал внутрь tf и правильно вызывать tf.keras и импорты слоёв делать тоже оттуда
Большое спасибо за статью, очень люблю эту тематику. Иногда полезно почитать такие общие статьи для повторения и актуализации информации в голове.
Дополню насчет 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? Будет значительно быстрее и сразу отнормировано
Попробуйте добавить 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
Здесь YOLOv3 описан как хороший вариант для бейзлайна по доступности и простоте)
Мерять время по одному прогону одной картинки — это плохая практика, вообще говоря. Особенность устройства TF такова, что необходим первый WarmUp прогон, когда выделиться необходимая память.
Поэтому крайне сомневаюсь в предоставленных цифрах. Попробуй взять среднее по 50 прогонам без учета самого первого — тогда это будет честно :)
Возможно, когда-то напишу сравнительную статью про разные другие бэкенды
Возможно, это наоборот улучшает результат.
У них же так разгружаются линии RAM и кэша.
Плюс оптимальная производительность достигается явно не при 100% загрузки.