Найкращі методи навчання прискорення TensorFlow 1.x на Amazon SageMaker

Сьогодні багато клієнтів використовують TensorFlow для навчання моделей глибокого навчання для їх рейтингу кліків у рекламі та рекомендаціях щодо персоналізації в електронній комерції. Оскільки поведінка їхніх клієнтів змінюється, вони можуть щодня накопичувати великі обсяги нових даних. Ітерація моделі є однією з щоденних завдань спеціалістів із обробки даних, але вони стикаються з проблемою надто тривалого навчання на великих наборах даних.

Amazon SageMaker це повністю керована платформа машинного навчання (ML), яка може допомогти дослідникам даних зосередитися на моделях, а не на інфраструктурі, з вбудованою підтримкою алгоритмів і фреймворків, як-от TensorFlow і PyTorch. SageMaker пропонує гнучкі варіанти розподіленого навчання, які адаптуються до ваших конкретних робочих процесів. Оскільки багатьом дослідникам даних може бракувати досвіду в процесі навчання прискорення, у цій публікації ми покажемо вам фактори, важливі для навчання моделям швидкого глибокого навчання, і найкращі практики навчання прискорення для TensorFlow 1.x на SageMaker. У нас також є зразок коду DeepFM розповсюджене навчання SageMaker на GitHub репо.

Є багато факторів, які слід враховувати, щоб максимізувати використання CPU/GPU під час запуску сценарію TensorFlow на SageMaker, як-от інфраструктура, тип прискорювача, метод розподіленого навчання, метод завантаження даних, навчання змішаної точності тощо.

Ми обговорюємо найкращі практики в таких сферах:

• Прискорення навчання на одному екземплярі
• Прискорення навчання на кількох екземплярах
• Конвеєри даних
• Автоматичне тренування змішаної точності

Прискорення навчання на одному екземплярі

Під час запуску сценарію TensorFlow на одному екземплярі ви можете вибрати серію, оптимізовану комп’ютером, наприклад Обчислювальна хмара Amazon Elastic (Amazon EC2) Серія C5 або серія прискорених обчислень із кількома GPU в одному екземплярі, наприклад p3.8xlarge, p3.16xlarge, p3dn.24xlarge та p4d.24xlarge.

У цьому розділі ми обговорюємо стратегії для кількох ЦП в одному екземплярі та розподілене навчання з кількома ГП в одному екземплярі.

Кілька ЦП в одному екземплярі

У цьому розділі ми обговорюємо ручне налаштування паралелізму операторів на пристроях ЦП, метод башти, TensorFlow MirroredStrategy та Horovod.

Ручне налаштування паралелізму операторів на пристроях ЦП

TensorFlow автоматично вибирає відповідну кількість потоків для розпаралелювання обчислення операції в процесі навчання. Однак ви можете встановити intra_op пул потоків і inter_op параметри паралелізму, надані TensorFlow, і використовуйте змінні середовища MKL-DNN для встановлення прив’язки для потоку ОС. Перегляньте наступний код:

# Set parallelism of intra_op and inter_op
num_cpus = int(os.environ['SM_NUM_CPUS'])
config = tf.ConfigProto(allow_soft_placement=True, device_count={'CPU': num_cpus}, intra_op_parallelism_threads=num_cpus, inter_op_parallelism_threads=num_cpus)
run_config = tf.estimator.RunConfig().replace(session_config = config)

# Use Intel MKL-DNN Setting to accelerate training speed
os.environ["KMP_AFFINITY"]= "verbose,disabled"
os.environ['OMP_NUM_THREADS'] = str(num_cpus)
os.environ['KMP_SETTINGS'] = '1'

Змінна середовища KMP_AFFINITY MKL-DNN встановлено на granularity=fine,compact,1,0 за замовчуванням. Після встановлення як intra, так і inter TensorFlow максимальної кількості vCPU поточного екземпляра, верхня межа використання ЦП майже така ж, як кількість фізичних ядер навчального екземпляра.

Якщо ви встановили os.environ["KMP_AFFINITY"]= "verbose,disabled", потік ОС не прив’язаний до апаратного гіперпотоку, і використання ЦП може перевищувати кількість фізичних ядер.

Що стосується налаштувань внутрішнього паралелізму TensorFlow, внутрішнього паралелізму TensorFlow і кількості потоків MKL-DNN, різні комбінації цих трьох параметрів призводять до різної швидкості навчання. Тому вам потрібно перевірити кожен випадок, щоб знайти найкраще поєднання. Поширеною ситуацією є встановлення трьох параметрів (intra_op_parallelism_threads та inter_op_parallelism_threads для TensorFlow, os.environ['OMP_NUM_THREADS'] для MKL-DNN) до половини кількості vCPU (фізичного ядра) або загальної кількості vCPU.

Баштовий метод

Щоб відтворити модель через графічні процесори, кожен графічний процесор отримує власний екземпляр прямого проходу. Примірник проходу вперед називається a башта. Баштовий метод майже завжди використовується для графічних процесорів. Щоб порівняти швидкість навчання з іншими методами, тут ми також використовуємо метод вежі для нашого процесорного пристрою.

Якщо ви не встановите пристрій процесора вручну, TensorFlow не використовує метод вежі для усереднення градієнтів, тому вам не потрібно масштабувати розмір пакету в таких випадках.

1. Налаштуйте пристрій ЦП вручну:

device_list = []
if manual_CPU_device_set:
		cpu_prefix=’/cpu:’
		for I in range(1, num_cpus):
			devices_list.append(cpu_prefix + str(i))

2. Скористайтесь replicate_model_fn загортати model_fn:

DeepFM = tf.estimator.Estimator(model_fn=tf.contrib.estimator.replicate_model_fn(model_fn, devices=device_list), model_dir=FLAGS.model_dir, params=model_params, config=config)

3. Скористайтесь TowerOptimizer загортати optimizer:

optimizer = tf.contrib.estimator.TowerOptimizer(optimizer)

4. Загорніть ваш model_fn:

with tf.variable_scope(‘deepfm_model’, reuse=tf.AUTO_REUSE)

5. Збільшити розмір пакета до (NUM_CPU – 1).

Давайте подивимося на різницю у використанні процесора з увімкненим режимом башти. На наступному малюнку показано використання ЦП примірником ml.c5.18xlarge із такою конфігурацією:

Немає Tower + дані LibSVM + режим конвеєра + MKL-DNN вимкнути прив'язку + налаштування паралелізму TensorFlow для внутрішнього та внутрішнього паралелізму для максимальної кількості vCPU екземпляра

На наступному малюнку показано використання ЦП примірника ml.c5.18xlarge із такою конфігурацією:

Tower із встановленим пристроєм ЦП + даними LibSVM + режимом каналу + вимкненням прив'язки MKL-DNN + налаштуванням внутрішнього/міжопераційного паралелізму TensorFlow для максимальної кількості vCPU екземпляра

Використання ЦП вище при використанні методу башти, і воно перевищує кількість фізичних ядер.

TensorFlow MirroredStrategy

TensorFlow MirroredStrategy означає синхронне навчання кількох реплік на одній машині. Ця стратегія зазвичай використовується для навчання на одній машині з кількома графічним процесором. Щоб порівняти швидкість навчання з іншим методом, ми використовуємо MirroredStrategy для нашого процесорного пристрою.

Під час використання TensorFlow MirroredStrategy, якщо ви не встановите пристрій ЦП, TensorFlow просто використовує один ЦП як один робочий процес, що є марною тратою ресурсів. Ми рекомендуємо вручну налаштувати пристрій центрального процесора, оскільки це призведе до операції зменшення /CPU:0, Так що /CPU:0 пристрій тут не використовується як репліка. Перегляньте наступний код:

device_list = []
if manual_CPU_device_set:
		cpu_prefix=’/cpu:’
		for I in range(1, num_cpus):
			devices_list.append(cpu_prefix + str(i))
mirrored_strategy = tf.distribute.MirroredStrategy(devices=devices_list)
	else:
mirrored_strategy = tf.distribute.MirroredStrategy()

# Set strategy to config:
config = tf.estimator.RunConfig(train_distribute=mirrored_strategy,
eval_distribute=mirrored_strategy,
session_config = config)

Під час використання MirroredStrategy потрібно масштабувати розмір партії; наприклад, масштабуйте розмір пакета до кількості пристроїв GPU.

Для підстратегії, коли ви встановлюєте пристрій ЦП, якщо ви не встановлюєте cross_device_ops параметр в tf.distribute.MirroredStrategy(), TensorFlow використовує ReductionToOneDevice підстратегія за замовчуванням. Однак, якщо встановити HierarchicalCopyAllReduce як підстратегія, TensorFlow просто виконує роботу по зменшенню /CPU:0. Коли ви використовуєте API набору даних TensorFlow і стратегію розповсюдження разом, об’єкт набору даних має повертатися замість функцій і міток у функції input_fn.

Зазвичай TensorFlow MirroredStrategy працює повільніше, ніж метод башти для навчання ЦП, тому ми не рекомендуємо використовувати MirroredStrategy на одному хості з кількома ЦП.

Горовод

Горовод це розподілена навчальна структура глибокого навчання для TensorFlow, Keras, PyTorch і Apache MXNet. Мета Horovod — зробити розподілене глибинне навчання швидким і простим у використанні.

Є параметр distribution в SageMaker Python SDK Estimator API, який ви можете використовувати для визначення розподіленого навчання Horovod. SageMaker забезпечує інфраструктуру та запускає ваш сценарій за допомогою MPI. Перегляньте наступний код:

hvd_processes_per_host = 4
distribution = {'mpi': { 
'enabled': True, 
'processes_per_host': hvd_processes_per_host,
'custom_mpi_options': '-verbose --NCCL_DEBUG=INFO -x OMPI_MCA_btl_vader_single_copy_mechanism=none' 
} 
}

Вибираючи екземпляр графічного процесора, наприклад ml.p3.8xlarge, вам потрібно закріпити кожен графічний процесор для кожного робочого елемента:

config = tf.ConfigProto()
config.gpu_options.visible_device_list = str(hvd.local_rank())

Щоб прискорити збіжність моделі, масштабуйте швидкість навчання за кількістю працівників згідно з офіційною документацією Horovod. Однак у реальних проектах вам слід певною мірою масштабувати швидкість навчання, але не за кількістю працівників, що призводить до поганої продуктивності моделі. Наприклад, якщо вихідний рівень навчання становить 0.001, ми масштабуємо рівень навчання до 0.0015, навіть якщо кількість працівників становить чотири або більше.

Як правило, лише основний (Horovod ранг 0) зберігає контрольну точку та модель, а також операцію оцінки. При використанні Horovod вам не потрібно масштабувати розмір партії. Пропозиції SageMaker Трубний режим для потокової передачі даних Служба простого зберігання Amazon (Amazon S3) у навчальні екземпляри. Коли ви вмикаєте режим конвеєра, майте на увазі, що різні робочі особи на одному хості повинні використовувати різні канали, щоб уникнути помилок. Це пояснюється тим, що перший робочий процес читає дані FIFO/каналу, а інші робочі процеси в тому самому екземплярі зависають, оскільки вони не можуть читати дані з того самого FIFO/каналу, тому Horovod не працює належним чином. Щоб уникнути цієї проблеми, встановіть канали відповідно до кількості працівників на екземпляр. Принаймні переконайтеся, що різні працівники на одному хості використовують різні канали; той самий канал може використовуватися працівниками на іншому хості.

Під час використання Horovod ви можете зіткнутися з такою помилкою:

“One or more tensors were submitted to be reduced, gathered or broadcasted by subset of ranks and are waiting for remainder of ranks for more than 60 seconds. This may indicate that different ranks are trying to submit different tensors or that only subset of ranks is submitting tensors, which will cause deadlock.”

Можливою причиною цієї проблеми є те, що певний ранг (наприклад, ранг 0) працює повільніше або виконує більше завдань, ніж інші ранги, і через це інші ранги чекають тривалий час. Хоча ранг 0 іноді повинен виконувати більше роботи, ніж інші ранги, слід зазначити, що ранг 0 не повинен робити багато протягом тривалого часу. Наприклад, для оцінки моделі набору перевірки та збереження контрольних точок під час навчання, якщо ці операції неминуче займуть багато часу, що може спричинити помилки, один обхідний шлях полягає в тому, щоб дозволити всім працівникам виконувати ту саму роботу, що й ранг 0 (контрольні точки збереження, оцінка тощо).

Розбивка даних — одна з найважливіших речей, яку слід враховувати під час використання розподіленого навчання. Ви можете використовувати TensorFlow dataset.shard() у вашому сценарії. SageMaker також пропонує функцію сегментування набору даних у вхідний канал за допомогою налаштування distribution=S3shardbykey у каналі набору даних. Перегляньте наступний код:

dataset = PipeModeDataset(channel, record_format='TFRecord')

number_host = len(FLAGS.hosts)

if FLAGS.enable_data_multi_path : # If there are multi channels mapping with different S3 path
    if FLAGS.enable_s3_shard == False :
        if number_host > 1:
            index = hvd.rank() // FLAGS.worker_per_host
            dataset = dataset.shard(number_host, index)
else :
    if FLAGS.enable_s3_shard :
        dataset = dataset.shard(FLAGS.worker_per_host, hvd.local_rank())
    else :
        dataset = dataset.shard(hvd.size(), hvd.rank())

На наступному малюнку показано результат під час використання Horovod (ml.c5.18xlarge, Horovod + LibSVM + налаштування внутрішньої та міжопераційної операцій за замовчуванням), які ви можете порівняти з методом башти.

Розподілене навчання з кількома графічними процесорами в одному екземплярі

Починати розподілене навчання з кількома графічними процесорами на одному екземплярі – це нормально, оскільки дослідникам даних потрібно керувати лише одним екземпляром і використовувати переваги високошвидкісного зв’язку між графічним процесором. Навчальні завдання SageMaker підтримують кілька типів екземплярів, які мають кілька GPU в одному екземплярі, наприклад ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge та ml.p4d.24xlarge. Метод такий самий, як і кілька ЦП в одному екземплярі, але з деякими змінами в сценарії.

Баштовий метод

Метод башти тут майже такий самий, як і під час багатопроцесорного навчання. Вам потрібно масштабувати розмір партії відповідно до кількості використовуваних GPU.

TensorFlow MirroredStrategy

Підстратегія за замовчуванням MirroredStrategy is NcclAllReduce. Вам потрібно масштабувати розмір партії відповідно до кількості використовуваних GPU. Перегляньте наступний код:

mirrored_strategy = tf.distribute.MirroredStrategy()
config = tf.estimator.RunConfig(train_distribute=mirrored_strategy,
				eval_distribute=mirrored_strategy)

Прискорення навчання на кількох екземплярах

Масштабування – це завжди можливість покращити швидкість навчання. Все більше науковців обирають це як параметр за замовчуванням для розподіленого навчання. У цьому розділі ми обговорюємо стратегії розподіленого навчання з кількома хостами.

Кілька ЦП з кількома екземплярами

Існує чотири основні методи використання кількох ЦП із кількома екземплярами під час увімкнення розподіленого навчання:

• • Сервер параметрів без ручного налаштування паралелізму операторів на пристроях ЦП
  • Сервер параметрів із ручним налаштуванням паралелізму операторів на пристроях ЦП
  • Сервер параметрів з вежею (налаштування пристроїв CPU вручну та настро allow_soft_placement=True in tf.ConfigProto)
  • Горовод

При використанні сервера параметрів у tf.estimator API, шлях контрольної точки має бути доступним для спільного використання шляхом, наприклад Amazon S3, або локальним шляхом Служба файлів Amazon Elastic (Amazon EFS) зіставлення з контейнером. Для сервера параметрів у tf.keras, шлях контрольної точки можна встановити на локальний шлях. Для Horovod шлях контрольної точки можна встановити на локальний шлях екземпляра навчання.

При використанні сервера параметрів і tf.estimator API із шляхом контрольної точки до Amazon S3, якщо модель досить велика, ви можете зіткнутися з помилкою основної точки застрягла під час збереження контрольної точки до S3. Ви можете використовувати вбудований контейнер SageMaker TensorFlow 1.15 або TensorFlow 1.15.2 або використовувати Amazon EFS як шлях контрольної точки спільного доступу.

Під час використання сервера параметрів для кількох хостів навантаження параметрів на кожен процес сервера параметрів може бути незбалансованим (особливо, коли є відносно великі змінні таблиці вбудовування), що може спричинити помилки. Ви можете перевірити розмір файлу кожної контрольної точки фрагмента в Amazon S3, щоб визначити, чи збалансовані параметри на сервері параметрів, оскільки кожен сервер параметрів відповідає фрагменту файлу контрольної точки. Щоб уникнути таких проблем, ви можете використати функцію розбиття, щоб спробувати зробити параметри кожного сервера параметрів рівномірно розподіленими:

with tf.variable_scope('deepfm_model', reuse=tf.AUTO_REUSE, partitioner = tf.fixed_size_partitioner(num_shards=len(FLAGS.hosts))):

Один GPU з кількома екземплярами

Навчальні завдання SageMaker підтримують екземпляри, які мають лише один GPU, як-от серії ml.p3.xlarge, ml.g4dn і ml.g5. У цьому сценарії використовуються два основні методи: сервери параметрів і Horovod.

Вбудований метод розподіленого навчання SageMaker на сервері параметрів полягає у запуску процесу сервера параметрів і робочого процесу для кожного екземпляра навчання (кожен сервер параметрів відповідає лише за частину параметрів моделі), тому за замовчуванням є багатомашинне одно- Навчання GPU. Розподілене навчання вбудованого сервера параметрів SageMaker є асинхронним градієнтним методом оновлення. Щоб зменшити вплив асинхронних оновлень на конвергенцію навчання, рекомендується зменшити швидкість навчання. Якщо ви хочете використовувати всі графічні процесори в екземплярі, вам потрібно використовувати комбінацію серверів параметрів і методу вежі.

Для Хоровода просто поставили processes_per_host=1 у параметрі розподілу API SageMaker Python Estimator.

Кілька GPU з кількома екземплярами

Для серверів параметрів і методу башти зміни коду в основному такі ж, як і для методу башти для одного екземпляра з кількома графічними процесорами, і немає необхідності вручну встановлювати пристрої графічного процесора.

Для Horovod встановіть процеси_на_хост у параметрі розподілу на кількість графічних процесорів кожного екземпляра навчання. Якщо ви використовуєте режим конвеєра, кількість робітників на примірник має відповідати кількості каналів.

Конвеєри даних

На додаток до інфраструктури, яку ми обговорювали, є ще одна важлива річ, яку слід враховувати: конвеєр даних. Конвеєр даних стосується того, як ви завантажуєте дані та перетворюєте їх перед подачею в нейронні мережі. CPU використовується для підготовки даних, тоді як GPU використовується для обчислення даних з CPU. Оскільки GPU є дорогим ресурсом, більший час простою GPU є неефективним; хороший конвеєр даних у вашій навчальній роботі може покращити використання GPU та CPU.

Коли ви намагаєтеся оптимізувати свій конвеєр введення даних TensorFlow, враховуйте порядок використання API Набори даних TensorFlow, розмір навчальних даних (багато маленьких файлів або кілька великих файлів), розмір пакету тощо.

Давайте розглянемо взаємодію між GPU і CPU під час навчання. На наступних малюнках порівнюються взаємодії з конвеєром і без нього.

Кращий конвеєр може зменшити час простою GPU. Зверніть увагу на такі поради:

• Використовуйте просту функціональну логіку для вилучення функцій і міток
• Попереднє вибірка зразків у пам'ять
• Зменшіть непотрібний дисковий ввід-вивід і мережевий ввід-вивід
• Кешуйте оброблені функції та мітки в пам’яті
• Зменшіть час реплікації між ЦП і ГП
• Нехай різні працівники мають справу з різними частинами навчального набору даних
• Скоротіть час виклику API набору даних TensorFlow

TensorFlow надає API перетворення, пов’язаний із форматами набору даних, і порядок API перетворення в TensorFlow сильно впливає на швидкість навчання. Необхідно перевірити найкращий порядок виклику API набору даних TensorFlow. Нижче наведено кілька основних принципів.

• Використовуйте векторизовану карту. Це означає, що спочатку викликати пакетний API набору даних TensorFlow, а потім API карти набору даних. Спеціальна функція синтаксичного аналізу, яка надається у функції карти, наприклад decode_tfrecord у зразку коду аналізує міні-пакет даних. Навпаки, map first and then batch — це скалярне відображення, а спеціальна функція аналізатора обробляє лише один зразок.
• Використовуйте API кешу набору даних TensorFlow для кешування функцій і міток. Розмістіть API кешу набору даних TensorFlow перед API повторення набору даних TensorFlow, інакше використання оперативної пам’яті зростатиме лінійно епоха за епохою. Якщо розмір набору даних становить оперативну пам’ять, не використовуйте API кешу набору даних TensorFlow. Якщо вам потрібно використовувати API кешу набору даних TensorFlow і API перемішування, розгляньте такий порядок: створити об’єкт набору даних TensorFlow -> API кешу -> API перемішування -> пакетний API -> API карт -> API повтору -> API попередньої вибірки.
• Використовувати tfrecord формат набору даних більше, ніж формат LibSVM.
• Режим файлу або режим каналу залежить від формату набору даних і кількості файлів. The tfrecorddataset API може встановити num_parallel_reads для одночасного читання кількох файлів і встановлення buffer_size для оптимізації читання даних, тоді як pipemodedataset API не має таких налаштувань. Режим конвеєра більше підходить для ситуацій, коли один файл великий, а загальна кількість файлів невелика. Ми рекомендуємо використовувати завдання обробки SageMaker для виконання попередньої обробки, як-от об’єднання кількох файлів у більший файл відповідно до міток, використання методу вибірки, щоб зробити набір даних більш збалансованим, і перемішування збалансованого набору даних.

Перегляньте наведений нижче зразок коду:

def decode_tfrecord(batch_examples):
        # The feature definition here should BE consistent with LibSVM TO TFRecord process.
        features = tf.parse_example(batch_examples,
                                           features={
                                               "label": tf.FixedLenFeature([], tf.float32),
                                               "ids": tf.FixedLenFeature(dtype=tf.int64, shape=[FLAGS.field_size]),
                                               "values": tf.FixedLenFeature(dtype=tf.float32, shape=[FLAGS.field_size]) 
                                           })
        
        batch_label = features["label"]
        batch_ids = features["ids"]
        batch_values = features["values"]
        
        return {"feat_ids": batch_ids, "feat_vals": batch_values}, batch_label


    def decode_libsvm(line):
        columns = tf.string_split([line], ' ')
        labels = tf.string_to_number(columns.values[0], out_type=tf.float32)
        splits = tf.string_split(columns.values[1:], ':')
        id_vals = tf.reshape(splits.values,splits.dense_shape)
        feat_ids, feat_vals = tf.split(id_vals,num_or_size_splits=2,axis=1)
        feat_ids = tf.string_to_number(feat_ids, out_type=tf.int32)
        feat_vals = tf.string_to_number(feat_vals, out_type=tf.float32)
        return {"feat_ids": feat_ids, "feat_vals": feat_vals}, labels

if FLAGS.pipe_mode == 0:
        dataset = tf.data.TFRecordDataset(filenames)
    else :
        # Enter Pipe mode
        dataset = PipeModeDataset(channel, record_format='TFRecord')
        
    if FLAGS.enable_s3_shard == False:
        host_rank = FLAGS.hosts.index(FLAGS.current_host)
        number_host = len(FLAGS.hosts)
        dataset = dataset.shard(number_host, host_rank)
    
    dataset = dataset.batch(batch_size, drop_remainder=True) # Batch size to use
    dataset = dataset.map(decode_tfrecord,
                          num_parallel_calls=tf.data.experimental.AUTOTUNE) 

    if num_epochs > 1:
        dataset = dataset.repeat(num_epochs)
    dataset = dataset.prefetch(buffer_size=tf.data.experimental.AUTOTUNE)

Для навчання на екземплярах ЦП, встановлення паралелізму intra op, inter op, а змінна середовища MKL-DNN є хорошою відправною точкою.

Автоматичне тренування змішаної точності

Останнє, що ми обговорюємо, це автоматичне навчання змішаної точності, яке може прискорити швидкість і призвести до продуктивності моделі. На момент написання цієї статті графічний процесор Nvidia V100 (примірник P3) і A100 (примірник P4dn) підтримують ядро ​​Tensor. Ви можете ввімкнути змішане навчання точності в TensorFlow, використовуючи такі типи екземплярів. Починаючи з версії 1.14, TensorFlow підтримує автоматичне змішане навчання точності. Ви можете використовувати наступний оператор, щоб обгорнути свій оригінальний оптимізатор:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

Якщо модель невелика, а використання GPU низьке, автоматичне навчання змішаної точності не має переваги. Якщо модель велика, автоматичне тренування змішаної точності може прискорити швидкість навчання.

Висновок

Коли ви починаєте навчання моделі глибокого навчання в SageMaker, зверніть увагу на такі поради, щоб досягти швидшої швидкості навчання:

• Спершу спробуйте метод із одним екземпляром із кількома ЦП або одним екземпляром із одним графічним процесором. Якщо використання CPU/GPU дуже високе (наприклад, понад 90%), перейдіть до наступного кроку.
• Спробуйте більше ЦП на одному хості або більше графічних процесорів на одному хості. Якщо завантаження наближається до максимального завантаження процесорів або графічних процесорів, переходьте до наступного кроку.
• Спробуйте кілька процесорів або кілька графічних процесорів з кількома хостами.
• Вам потрібно змінити коди під час використання серверів параметрів або Horovod. Модифікація коду не однакова для API на основі сеансу TensorFlow, tf.estimator API та tf.keras API. Сервер параметрів або Horovod може показувати різну швидкість навчання в різних навчальних випадках і завданнях, тому спробуйте обидва методи, якщо у вас є час і бюджет, щоб визначити найкращий.

Майте на увазі наступну пораду:

• Перевірте використання перед масштабуванням, оптимізуйте конвеєр даних і зробіть перекриття ЦП і ГП на часовій шкалі.
• Спочатку збільште масштаб, а потім зменшіть масштаб.
• Якщо ви не можете підвищити використання GPU після всіх методів, спробуйте CPU. Є багато випадків (особливо для моделі рейтингу рейтингу кліків), коли загальний час навчання інсталяції CPU коротший і економічніший, ніж навчання інстанції GPU.

У нас також є зразок коду в GitHub репо, де ми показуємо два зразки розподіленого навчання DeepFM на SageMaker. Один — це сервер параметрів TensorFlow на екземплярах CPU, інший — Horovod на екземплярах GPU.

Про авторів

Юхуй Лян є старшим архітектором рішень машинного навчання. Він зосереджений на просуванні та застосуванні машинного навчання та бере активну участь у багатьох проектах машинного навчання клієнтів. Він має багатий досвід розподіленого навчання глибокого навчання, систем рекомендацій і обчислювальної реклами.

Шишуай Ван є старшим архітектором рішень машинного навчання. Він працює з клієнтами AWS, щоб допомогти їм запровадити машинне навчання у великих масштабах. Йому подобається дивитися фільми і подорожувати по світу.