Изменения кода, необходимые для эксперимента с настраиваемым распределенным двигателем ML

Я прошел это руководство по распределенному tenorflow в рамках эксперимента с ML Engine, и я хочу определить свой собственный пользовательский уровень вместо уровня STANDARD_1, который они используют в своих config.yaml. При использовании tf.estimator.Estimator API требуются ли какие-либо дополнительные изменения кода для создания настраиваемого уровня любого размера? Например, в статье говорится: «Если вы распределите 10 000 пакетов между 10 рабочими узлами, каждый узел будет работать примерно с 1000 пакетами». так что это может означать, что файл config.yaml ниже был бы возможен

trainingInput:
  scaleTier: CUSTOM
  masterType: complex_model_m
  workerType: complex_model_m
  parameterServerType: complex_model_m
  workerCount: 10
  parameterServerCount: 4

Требуются ли какие-либо изменения кода в учебнике по mnist, чтобы использовать эту настраиваемую конфигурацию? Будет ли это возможным распределить количество пакетов X между 10 рабочими, как предлагает учебник? Я покопался в некоторых других примерах ML Engine и обнаружил, что reddit_tft использует распределенное обучение, но, похоже, они определили свои собственные runconfig.cluster_spec в своем пакете тренеров: task.py, даже если они также используют API-интерфейс оценщика. Итак, нужна ли дополнительная настройка? На данный момент я понимаю, что при использовании API-интерфейса оценщика (даже в рамках вашей собственной определенной модели) не должно быть никаких дополнительных изменений.

Изменится ли что-нибудь из этого, если в config.yaml указано использование графических процессоров? В этой статье для API-интерфейса оценщика предлагается «Без кода изменения необходимы, пока ваш ClusterSpec настроен правильно. Если кластер представляет собой смесь процессоров и графических процессоров, сопоставьте имя задания ps с процессорами, а имя рабочего задания - с графическими процессорами ». Однако, поскольку config.yaml конкретно определяет тип машины для серверов параметров и рабочих, я ожидаю, что в ML-Engine ClusterSpec будет правильно настроен на основе файла config.yaml. Однако я не могу найти документацию по ml-движку, подтверждающую, что для использования графических процессоров не требуется никаких изменений.

Наконец, в ML-Engine мне интересно, есть ли какие-либо способы идентифицировать использование различных конфигураций? Строка «Если вы распределите 10 000 пакетов между 10 рабочими узлами, каждый узел будет работать примерно с 1000 пакетами». предполагает, что использование дополнительных воркеров будет примерно линейным, но у меня нет интуиции, как определить, нужны ли дополнительные серверы параметров? Что можно было бы проверить (на облачных или тензорных панелях), чтобы определить, достаточно ли у них количества серверов параметров?


person reese0106    schedule 20.08.2017    source источник


Ответы (1)


необходимы ли какие-либо дополнительные изменения кода для создания настраиваемого уровня любого размера?

Нет; не требуется никаких изменений в образце MNIST, чтобы заставить его работать с другим числом или типом воркеров. Чтобы использовать tf.estimator.Estimator в движке CloudML, ваша программа должна вызывать learn_runner.run, как проиллюстрировано в примерах. При этом структура читает в _3 _ переменные среды и заполняет объект RunConfig соответствующей информацией, например ClusterSpec. Он автоматически будет делать правильные действия на узлах Parameter Server и будет использовать предоставленный оценщик для начала обучения и оценки.

Большая часть волшебства происходит потому, что tf.estimator.Estimator автоматически использует установщик устройств, который правильно распределяет операции. Этот установщик устройства использует информацию о кластере из объекта RunConfig, конструктор которого по умолчанию использует TF_CONFIG для выполнения своих задач (например, здесь). Вы можете увидеть, где используется установщик устройства. .

Все это означает, что вы можете просто изменить свой config.yaml, добавив / удалив воркеров и / или изменив их типы, и в целом все должно работать.

Пример кода с использованием настраиваемой модели model_fn см. В пример census / customestimator.

Тем не менее, обратите внимание, что по мере добавления воркеров вы увеличиваете эффективный размер пакета (это верно независимо от того, используете ли вы tf.estimator). То есть, если ваш batch_size был 50 и вы использовали 10 воркеров, это означает, что каждый воркер обрабатывает пакеты размером 50 для эффективного размера пакета 10 * 50 = 500. Затем, если вы увеличите количество рабочих до 20, ваш эффективный размер партии станет 20 * 50 = 1000. Вы можете обнаружить, что вам, возможно, потребуется соответственно снизить скорость обучения (линейный, как правило, работает хорошо; ref ).

Я покопался в некоторых других примерах ML Engine и обнаружил, что reddit_tft использует распределенное обучение, но, похоже, они определили свой собственный runconfig.cluster_spec в своем пакете тренера: task.pye, хотя они также используют API-интерфейс Estimator. Итак, нужна ли дополнительная настройка?

Никакой дополнительной настройки не требуется. Образец reddit_tft действительно создает собственный экземпляр RunConfig, однако конструктор RunConfig захватывает любые свойства, не заданные явно во время создания экземпляра, с помощью TF_CONFIG. И это делается только для удобства, чтобы выяснить, сколько существует серверов параметров и рабочих.

Изменится ли что-нибудь из этого, если в config.yaml указано использование графических процессоров?

Вам не нужно ничего менять, чтобы использовать tf.estimator.Estimator с графическими процессорами, кроме, возможно, необходимости вручную назначать операции графическому процессору (но это не относится к CloudML Engine); см. эту статью для получения дополнительной информации. Я постараюсь уточнить документацию.

person rhaertel80    schedule 22.08.2017
comment
Я понимаю, что пример MNIST не требует изменения кода. Однако что, если я использую tf.estimator.Estimator и определяю свою собственную model_fn? В вашем ответе постоянно упоминается tf.estimator, и неясно, применимо ли все это также к tf.estimator.Estimator, как спрашивает мой вопрос. В их документации говорится, что главное изменение для работы распределенной версии - это использование переменной окружения TF_CONFIG. Переменная среды создается с помощью gcloud и анализируется для создания ClusterSpec. что, кажется, наводит на мысль о необходимости изменения? - person reese0106; 23.08.2017
comment
Обновлен пост, чтобы он относился к tf.estimator.Estimator. Также добавлена ​​информация о установщиках устройств, так как именно они творят магию и являются потребителями RunConfig, который, в свою очередь, анализирует переменную TF_CONFIG. - person rhaertel80; 23.08.2017