Распределенный тензорный тренинг Reinpect Модель обнаружения человека

Question

Я работаю над распределенным Tensorflow, в частности, с использованием модели Reinspect с использованием распределенного тензорного потока, приведенного в следующей статье https://github.com/Russell91/TensorBox.

Мы используем межгранусно-асинхронную реализацию параметров распределенного тензорного потока, но результаты очень удивительны. В то время как настольная маркировка, мы пришли к выводу, что Распределенное обучение занимает почти более чем в 2 раза больше времени обучения, чем одно машинное обучение. Любые указания о том, что может происходить и что еще можно попробовать, будут действительно оценены. Спасибо

Примечание: в сообщении есть исправление, мы используем реализацию между графами, а не в графическом исполнении. Извините за ошибку

Answer 1

В общем, я не удивлюсь, если двигаться от реализации одного процесса модели для реализации мульти-машины может привести к замедлению. Из вашего вопроса, это не очевидно, что может быть происходит, но вот несколько общих указателей:

• Если модель имеет большое количество параметров относительно объема вычислений (например, если он в основном выполняет большой матричные умножения, а не свертки), то вы можете обнаружить, что сеть является узким местом. Какова пропускная способность вашего сетевого подключения?

• Есть ли большое количество копий между процессами, возможно, из-за неудачного размещения устройства? Попробуйте собрать и визуализировать график, чтобы узнать, что происходит при запуске вашей модели.

• Вы упомянули, что используете «репликацию в графе», которая является not currently recommended для масштабируемости. Репликация в графе может создать узкое место у единственного мастера, особенно если у вас большой граф модели со многими репликами.

• Используете ли вы один входной конвейер через реплики или несколько входных трубопроводов? Использование одного входного конвейера создало бы узкое место в процессе выполнения входного конвейера. (Тем не менее, с репликацией на основе данных, использование нескольких входных конвейеров также может создать узкое место, так как будет один процесс Python, управляющий вводом-выводом с большим количеством потоков.)

• Или вы используете механизм подачи ? Подача данных намного медленнее, когда она должна пересекать границы процесса, как это было бы в реплицированной настройке. Использование ретрансляции между графами, по крайней мере, устранит узкое место в процессе одного клиента, но для повышения производительности вы должны использовать входной конвейер. (Как Yaroslav observed, кормлению и извлечения больших значений тензора медленнее в распределенной версии, так как данные передаются через RPC. В одном процессе они будут использовать простой memcpy() вместо этого.)

• Сколько процессов вы используете? Как выглядит масштабирующая кривая?Есть ли немедленное замедление при переключении на использование сервера параметров и единственной рабочей копии (по сравнению с одним комбинированным процессом)? Повышается ли производительность или ухудшается производительность, когда вы добавляете больше реплик?

Answer 2

Недавно я смотрел на подобную вещь, и я заметил, что перемещение данных из grpc во время выполнения Python происходит медленнее, чем ожидалось. В частности, рассмотрим следующий шаблон

add_op = params.assign_add(update) 
... 
sess.run(add_op) 

Если add_op лежит в другой процесс, а затем добавляет sess.run шаг декодирования, который происходит со скоростью 50-100 Мбайт/сек.

Вот benchmark и relevant discussion