Ответ 1
(Я не знаком с инфраструктурой сервера, но я хорошо знаком с HPC и cuBLAS и cuDNN, библиотеки TF используют для точечных продуктов и сверток на GPU)
Существует несколько проблем, которые могут привести к неутешительному масштабированию производительности с размером партии.
Накладные расходы ввода/вывода, под которыми я подразумеваю сетевые передачи, доступ к диску (для больших данных), сериализацию, десериализацию и аналогичный треск. Эти вещи имеют тенденцию быть линейными по размеру данных.
Чтобы изучить эти накладные расходы, я предлагаю вам развернуть две модели: одну, которая вам действительно нужна, и та, которая тривиальна, но использует один и тот же ввод-вывод, а затем вычитает время, необходимое одному из другого.
Эта разница во времени должна быть похожа на время выполнения сложной модели при ее непосредственном использовании без затрат на ввод-вывод.
Если узкое место находится в I/O, ускорение работы графического процессора является несущественным.
Обратите внимание, что даже если увеличение размера партии ускоряет работу GPU, это может сделать все более медленным, потому что графический процессор теперь должен ждать завершения ввода/вывода всей партии, даже чтобы начать работу.
масштабирование cuDNN: Вещи вроде matmul нуждаются в больших размерах партии для достижения их оптимальной пропускной способности, но свертки с использованием cuDNN могут не быть (по крайней мере, это не был мой опыт, но это может зависеть от версия и арка GPU)
ОЗУ, ОЗУ GPU или ограничениях PCIe с ограничением пропускной способности: Если ваше узкое место в вашей модели находится в любом из них, вероятно, это не принесет больших размеров партии.
Способ проверить это - запустить вашу модель напрямую (возможно, с макетным вводом), сравнить время с вышеупомянутой разницей времени и рассчитать ее как функцию размера партии.
Кстати, согласно руководство по эффективности, можно попытаться использовать макет NCHW, если вы еще этого не сделали. Существуют и другие советы.