Prácticas recomendadas para el entrenamiento de aceleración de TensorFlow 1.x en Amazon SageMaker

Hoy en día, muchos clientes usan TensorFlow para entrenar modelos de aprendizaje profundo para su tasa de clics en publicidad y recomendaciones de personalización en el comercio electrónico. A medida que cambia el comportamiento de sus clientes, pueden acumular grandes cantidades de datos nuevos todos los días. La iteración de modelos es uno de los trabajos diarios de un científico de datos, pero enfrentan el problema de tomar demasiado tiempo para entrenar en grandes conjuntos de datos.

Amazon SageMaker es una plataforma de aprendizaje automático (ML) completamente administrada que podría ayudar a los científicos de datos a enfocarse en modelos en lugar de infraestructura, con soporte nativo para traer sus propios algoritmos y marcos como TensorFlow y PyTorch. SageMaker ofrece opciones flexibles de capacitación distribuida que se ajustan a sus flujos de trabajo específicos. Debido a que muchos científicos de datos pueden carecer de experiencia en el proceso de entrenamiento de aceleración, en esta publicación le mostramos los factores que importan para el entrenamiento rápido de modelos de aprendizaje profundo y las mejores prácticas de entrenamiento de aceleración para TensorFlow 1.x en SageMaker. También tenemos un código de muestra de Deep FM capacitación distribuida sobre SageMaker en el Repositorio GitHub.

Hay muchos factores que debe considerar para maximizar la utilización de la CPU/GPU cuando ejecuta su script de TensorFlow en SageMaker, como la infraestructura, el tipo de acelerador, el método de entrenamiento distribuido, el método de carga de datos, el entrenamiento de precisión mixto y más.

Discutimos las mejores prácticas en las siguientes áreas:

• Acelere el entrenamiento en una sola instancia
• Acelere el entrenamiento en múltiples instancias
• Canalizaciones de datos
• Entrenamiento de precisión mixto automático

Acelere el entrenamiento en una sola instancia

Al ejecutar su secuencia de comandos de TensorFlow en una sola instancia, puede elegir una serie optimizada para computadora, como la Nube informática elástica de Amazon (Amazon EC2) serie C5, o una serie informática acelerada con múltiples GPU en una sola instancia, como p3.8xlarge, p3.16xlarge, p3dn.24xlarge y p4d.24xlarge.

En esta sección, analizamos las estrategias para varias CPU en una sola instancia y el entrenamiento distribuido con varias GPU en una sola instancia.

Múltiples CPU en una sola instancia

En esta sección, analizamos la configuración manual del paralelismo de los operadores en dispositivos de CPU, el método de la torre, TensorFlow MirroredStrategy y Horovod.

Configuración manual del paralelismo de los operadores en los dispositivos de la CPU

TensorFlow selecciona automáticamente la cantidad adecuada de subprocesos para paralelizar el cálculo de la operación en el proceso de capacitación. Sin embargo, puede configurar el intra_op grupo de hilos y inter_op la configuración de paralelismo proporcionada por TensorFlow y el uso de variables de entorno de MKL-DNN para establecer el enlace para el subproceso del sistema operativo. Ver el siguiente código:

# 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'

La variable de entorno KMP_AFFINITY de MKL-DNN se establece en granularity=fine,compact,1,0 por defecto. Después de establecer intra e inter de TensorFlow en la cantidad máxima de vCPU de la instancia actual, el límite superior de uso de la CPU es casi el mismo que la cantidad de núcleos físicos de la instancia de entrenamiento.

Si configura os.environ["KMP_AFFINITY"]= "verbose,disabled", el subproceso del sistema operativo no está vinculado al hiperproceso de hardware y el uso de la CPU podría exceder la cantidad de núcleos físicos.

Con respecto a la configuración del paralelismo interno de TensorFlow, el paralelismo interno de TensorFlow y la cantidad de subprocesos MKL-DNN, las diferentes combinaciones de estos tres parámetros dan como resultado diferentes velocidades de entrenamiento. Por lo tanto, debe probar cada caso para encontrar la mejor combinación. Una situación común es establecer los tres parámetros (intra_op_parallelism_threads y inter_op_parallelism_threads para TensorFlow, os.environ['OMP_NUM_THREADS'] para MKL-DNN) a la mitad de la cantidad de vCPU (núcleo físico) o la cantidad total de vCPU.

método de la torre

Para replicar un modelo en GPU, cada GPU obtiene su propia instancia del pase hacia adelante. La instancia del pase hacia adelante se llama torre. El método de la torre casi siempre se usa para dispositivos GPU. Para comparar la velocidad de entrenamiento con otros métodos, aquí también usamos el método de la torre para nuestro dispositivo de CPU.

Si no configura el dispositivo de CPU manualmente, TensorFlow no usa el método de la torre para promediar los gradientes, por lo que no necesita escalar el tamaño del lote en tales casos.

1. Configure el dispositivo de la CPU manualmente:

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. Uso replicate_model_fn envolver 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. Uso TowerOptimizer envolver optimizer:

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

4. Envuelve tu model_fn:

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

5. Escale el tamaño del lote a (NUM_CPU – 1).

Veamos la diferencia de la utilización de la CPU con el modo torre habilitado. La siguiente figura muestra la utilización de CPU de la instancia ml.c5.18xlarge con la siguiente configuración:

Sin torre + datos LibSVM + modo de canalización + MKL-DNN deshabilitar el enlace + ajuste de paralelismo intra/interoperativo de TensorFlow al número máximo de vCPU de la instancia

La siguiente figura muestra la utilización de CPU de la instancia ml.c5.18xlarge con la siguiente configuración:

Torre con dispositivo de CPU configurado + datos LibSVM + modo de canalización + enlace de desactivación de MKL-DNN + ajuste de paralelismo intra/interoperativo de TensorFlow al número máximo de vCPU de la instancia

El uso de la CPU es mayor cuando se utiliza el método de la torre y supera la cantidad de núcleos físicos.

Estrategia reflejada de TensorFlow

TensorFlow MirroredStrategy significa entrenamiento sincrónico en múltiples réplicas en una máquina. Esta estrategia generalmente se usa para entrenar en una máquina con varias GPU. Para comparar la velocidad de entrenamiento con otro método, usamos MirroredStrategy para nuestro dispositivo de CPU.

Cuando usa TensorFlow MirroredStrategy, si no configura el dispositivo de CPU, TensorFlow solo usa una CPU como único trabajador, lo que es una pérdida de recursos. Recomendamos configurar manualmente el dispositivo de la CPU, ya que realizará una operación de reducción en /CPU:0, Por lo que el /CPU:0 el dispositivo no se usa como una réplica aquí. Ver el siguiente código:

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)

Debe escalar el tamaño del lote al usar MirroredStrategy; por ejemplo, escale el tamaño del lote a un múltiplo de la cantidad de dispositivos GPU.

Para la subestrategia cuando configura el dispositivo de CPU, si no configura el cross_device_ops parámetro en tf.distribute.MirroredStrategy(), TensorFlow usa el ReductionToOneDevice subestrategia por defecto. Sin embargo, si establece HierarchicalCopyAllReduce como estrategia secundaria, TensorFlow solo hace el trabajo de reducción en /CPU:0. Cuando usas la API del conjunto de datos de TensorFlow y distribuyes la estrategia en conjunto, se debe devolver el objeto del conjunto de datos en lugar de las características y las etiquetas en función. input_fn.

Por lo general, TensorFlow MirroredStrategy es más lento que el método de la torre en el entrenamiento de la CPU, por lo que no recomendamos usar MirroredStrategy en un solo host con varias CPU.

Horovod

Horovod es un marco de capacitación de aprendizaje profundo distribuido para TensorFlow, Keras, PyTorch y Apache MXNet. El objetivo de Horovod es hacer que el aprendizaje profundo distribuido sea rápido y fácil de usar.

Hay un parámetro de distribution en SageMaker Python SDK Estimator API, que puede usar para indicar la capacitación distribuida de Horovod. SageMaker aprovisiona la infraestructura y ejecuta su script con MPI. Ver el siguiente código:

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' 
} 
}

Al elegir una instancia de GPU como ml.p3.8xlarge, debe anclar cada GPU para cada trabajador:

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

Para acelerar la convergencia del modelo, escale la tasa de aprendizaje por el número de trabajadores de acuerdo con la documentación oficial de Horovod. Sin embargo, en proyectos del mundo real, debe escalar la tasa de aprendizaje hasta cierto punto, pero no por la cantidad de trabajadores, lo que da como resultado un mal rendimiento del modelo. Por ejemplo, si la tasa de aprendizaje original es 0.001, escalamos la tasa de aprendizaje a 0.0015, incluso si el número de trabajadores es cuatro o más.

Generalmente, solo el primario (Horovod rango 0) guarda el punto de control y el modelo, así como la operación de evaluación. No necesita escalar el tamaño del lote cuando usa Horovod. Ofertas de SageMaker Modo de tubería transmitir datos desde Servicio de almacenamiento simple de Amazon (Amazon S3) en instancias de entrenamiento. Cuando habilite el modo Pipe, tenga en cuenta que diferentes trabajadores en el mismo host deben usar diferentes canales para evitar errores. Esto se debe a que el primer proceso de trabajo lee los datos del canal/FIFO, y otros procesos de trabajo en la misma instancia se bloquearán porque no pueden leer datos del mismo canal/FIFO, por lo que Horovod no funciona correctamente. Para evitar este problema, configure los canales de acuerdo con la cantidad de trabajadores por instancia. Al menos asegúrese de que diferentes trabajadores en el mismo host consuman diferentes canales; el mismo canal puede ser consumido por trabajadores en un host diferente.

Al usar Horovod, puede encontrar el siguiente error:

“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.”

La posible causa de este problema es que un cierto rango (como el rango 0) funciona más lento o hace más trabajos que otros rangos, y esto hace que otros rangos esperen mucho tiempo. Aunque el rango 0 a veces tiene que hacer más trabajo que otros rangos, debe tenerse en cuenta que el rango 0 no debería hacer mucho durante mucho tiempo. Por ejemplo, para la evaluación del modelo en el conjunto de validación y el guardado de puntos de control durante el entrenamiento, si es inevitable que estas operaciones lleven mucho tiempo, lo que podría causar errores, una solución consiste en permitir que todos los trabajadores hagan el mismo trabajo que el rango 0 (puntos de control ahorro, evaluación, etc.).

La fragmentación de datos es una de las cosas más importantes a considerar cuando se usa el entrenamiento distribuido. Puedes usar TensorFlow dataset.shard() en tu guión. SageMaker también ofrece una función de fragmento de conjunto de datos en el canal de entradas configurando distribution=S3shardbykey en el canal del conjunto de datos. Ver el siguiente código:

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())

La siguiente figura muestra el resultado cuando se usa Horovod (ml.c5.18xlarge, Horovod + LibSVM + configuración intraoperativa e interoperativa predeterminada), que puede comparar con el método de la torre.

Entrenamiento distribuido con múltiples GPU en una sola instancia

Es normal comenzar el entrenamiento distribuido con varias GPU en una sola instancia porque los científicos de datos solo necesitan administrar una instancia y aprovechar la interconexión de alta velocidad entre las GPU. Los trabajos de entrenamiento de SageMaker admiten varios tipos de instancias que tienen varias GPU en una sola instancia, como ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge y ml.p4d.24xlarge. El método es el mismo que el de múltiples CPU en una sola instancia, pero con algunos cambios en el script.

método de la torre

El método de torre aquí es casi el mismo que en el entrenamiento multi-CPU. Debe escalar el tamaño del lote de acuerdo con la cantidad de GPU en uso.

Estrategia reflejada de TensorFlow

La subestrategia predeterminada de MirroredStrategy is NcclAllReduce. Debe escalar el tamaño del lote de acuerdo con la cantidad de GPU en uso. Ver el siguiente código:

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

Acelere el entrenamiento en múltiples instancias

El escalado es siempre una opción para mejorar la velocidad de entrenamiento. Cada vez más científicos de datos eligen esta como una opción predeterminada en lo que respecta al entrenamiento distribuido. En esta sección, discutimos estrategias para el entrenamiento distribuido con múltiples hosts.

Múltiples CPU con múltiples instancias

Existen cuatro métodos principales para usar múltiples CPU con múltiples instancias al habilitar el entrenamiento distribuido:

• • Servidor de parámetros sin configurar manualmente el paralelismo de los operadores en los dispositivos de la CPU
  • Servidor de parámetros con ajuste manual del paralelismo de los operadores en los dispositivos de la CPU
  • Servidor de parámetros con torre (configuración manual de dispositivos de CPU y configuración allow_soft_placement=True in tf.ConfigProto)
  • Horovod

Cuando se utiliza un servidor de parámetros en el tf.estimator API, la ruta del punto de control debe ser una ruta compartible como Amazon S3 o la ruta local de Servicio de archivos elásticos de Amazon (Amazon EFS) asignación al contenedor. Para un servidor de parámetros en tf.keras, la ruta del punto de control se puede establecer en la ruta local. Para Horovod, la ruta del punto de control se puede establecer en una ruta local de la instancia de entrenamiento.

Cuando se utiliza un servidor de parámetros y el tf.estimator API con la ruta del punto de control a Amazon S3, si el modelo es bastante grande, es posible que encuentre un error de que el primario está atascado al guardar el punto de control en S3. Puede usar el contenedor integrado de SageMaker TensorFlow 1.15 o TensorFlow 1.15.2 o usar Amazon EFS como la ruta del punto de control del recurso compartido.

Cuando se usa un servidor de parámetros para múltiples hosts, la carga de parámetros en cada proceso del servidor de parámetros puede estar desequilibrada (especialmente cuando hay variables de tabla de incrustación relativamente grandes), lo que podría causar errores. Puede comprobar el tamaño del archivo de cada punto de control del fragmento en Amazon S3 para determinar si los parámetros del servidor de parámetros están equilibrados, ya que cada servidor de parámetros corresponde a un fragmento del archivo de punto de control. Para evitar estos problemas, puede utilizar la función de particionador para intentar que los parámetros de cada servidor de parámetros se distribuyan uniformemente:

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

GPU única con varias instancias

Los trabajos de capacitación de SageMaker admiten instancias que solo tienen una GPU, como las series ml.p3.xlarge, ml.g4dn y ml.g5. Hay dos métodos principales utilizados en este escenario: servidores de parámetros y Horovod.

El método de entrenamiento distribuido del servidor de parámetros integrado de SageMaker consiste en iniciar un proceso de servidor de parámetros y un proceso de trabajo para cada instancia de entrenamiento (cada servidor de parámetros solo es responsable de una parte de los parámetros del modelo), por lo que el valor predeterminado es multimáquina única. Entrenamiento de GPU. El entrenamiento distribuido del servidor de parámetros incorporado de SageMaker es un método de actualización de gradiente asíncrono. Para reducir el impacto de las actualizaciones asincrónicas en la convergencia del entrenamiento, se recomienda reducir la tasa de aprendizaje. Si desea usar todas las GPU en la instancia, debe usar una combinación de servidores de parámetros y el método de torre.

Para Horovod, solo configure processes_per_host=1 en el parámetro de distribución de SageMaker Python Estimator API.

Múltiples GPU con múltiples instancias

Para los servidores de parámetros y el método de la torre, los cambios de código son básicamente los mismos que los del método de la torre para una única instancia con varias GPU, y no es necesario configurar manualmente los dispositivos GPU.

Para Horovod, configure los procesos_por_host en el parámetro de distribución para la cantidad de GPU de cada instancia de entrenamiento. Si usa el modo Pipe, la cantidad de trabajadores por instancia debe coincidir con la cantidad de canales.

Canalizaciones de datos

Además de la infraestructura que hemos discutido, hay otra cosa importante a considerar: la canalización de datos. Una canalización de datos se refiere a cómo carga y transforma los datos antes de que se alimenten a las redes neuronales. La CPU se usa para preparar los datos, mientras que la GPU se usa para calcular los datos de la CPU. Debido a que la GPU es un recurso costoso, más tiempo de inactividad de la GPU es ineficiente; una buena canalización de datos en su trabajo de entrenamiento podría mejorar la utilización de GPU y CPU.

Cuando intente optimizar su canalización de entrada de datos de TensorFlow, considere el orden de API utilizado en Conjuntos de datos de TensorFlow, el tamaño de los datos de entrenamiento (muchos archivos pequeños o varios archivos grandes), el tamaño del lote, etc.

Veamos la interacción entre GPU y CPU durante el entrenamiento. Las siguientes figuras comparan interacciones con y sin canalización.

Una mejor canalización podría reducir el tiempo de inactividad de la GPU. Considere los siguientes consejos:

• Use lógica de función simple en la extracción de características y etiquetas
• Precargar muestras en la memoria
• Reduzca la E/S de disco y la E/S de red innecesarias
• Guarde en caché las características y etiquetas procesadas en la memoria
• Reducir el número de tiempos de replicación entre CPU y GPU
• Haga que diferentes trabajadores se ocupen de diferentes partes del conjunto de datos de capacitación
• Reduzca los tiempos de llamada a la API del conjunto de datos de TensorFlow

TensorFlow proporciona una API de transformación relacionada con formatos de conjuntos de datos, y el orden de la API de transformación en TensorFlow afecta mucho la velocidad de entrenamiento. Se debe probar el mejor orden para llamar a la API del conjunto de datos de TensorFlow. Los siguientes son algunos principios básicos:

• Utilice un mapa vectorizado. Esto significa llamar primero a la API por lotes del conjunto de datos de TensorFlow y luego a la API del mapa del conjunto de datos. La función de análisis personalizada proporcionada en la función de mapa, como decode_tfrecord en el código de ejemplo, analiza un mini lote de datos. Por el contrario, el mapa primero y luego el lote es un mapa escalar, y la función de analizador personalizado procesa solo una muestra.
• Use la API de caché del conjunto de datos de TensorFlow para almacenar en caché características y etiquetas. Coloque la API de caché del conjunto de datos de TensorFlow antes que la API de repetición del conjunto de datos de TensorFlow; de lo contrario, la utilización de RAM aumenta linealmente época tras época. Si el conjunto de datos es tan grande como la memoria RAM, no use la API de caché del conjunto de datos de TensorFlow. Si necesita usar la API de caché del conjunto de datos de TensorFlow y la API aleatoria, considere usar el siguiente orden: crear el objeto del conjunto de datos de TensorFlow -> API de caché -> API aleatoria -> API de lote -> API de mapa -> API de repetición -> API de captación previa.
• Ingrese al tfrecord formato de conjunto de datos más que el formato LibSVM.
• El modo de archivo o el modo de tubería depende del formato de su conjunto de datos y la cantidad de archivos. los tfrecorddataset La API puede establecer num_parallel_reads para leer varios archivos en paralelo y establecer buffer_size para optimizar la lectura de datos, mientras que el pipemodedataset La API no tiene esa configuración. El modo Pipe es más adecuado para situaciones en las que un solo archivo es grande y el número total de archivos es pequeño. Recomendamos usar un trabajo de procesamiento de SageMaker para realizar el trabajo de preprocesamiento, como unir varios archivos en un archivo más grande según las etiquetas, usar un método de muestreo para hacer que el conjunto de datos sea más equilibrado y mezclar el conjunto de datos equilibrado.

Consulte el siguiente ejemplo de código:

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)

Para entrenar en instancias de CPU, establecer el paralelismo de intra op, inter op, y la variable de entorno de MKL-DNN es un buen punto de partida.

Entrenamiento de precisión mixto automático

Lo último que discutimos es el entrenamiento automático de precisión mixta, que puede acelerar la velocidad y dar como resultado el rendimiento del modelo. Al momento de escribir este artículo, la GPU Nvidia V100 (instancia P3) y A100 (instancia P4dn) son compatibles con el núcleo Tensor. Puedes habilitar el entrenamiento de precisión mixto en TensorFlow cuando usas esos tipos de instancias. A partir de la versión 1.14, TensorFlow admitió el entrenamiento automático de precisión mixta. Puede usar la siguiente declaración para envolver su optimizador original:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

Si el modelo es pequeño y la utilización de la GPU es baja, no hay ninguna ventaja en el entrenamiento automático de precisión mixta. Si el modelo es grande, el entrenamiento de precisión mixto automático puede acelerar la velocidad de entrenamiento.

Conclusión

Cuando comience la capacitación de su modelo de aprendizaje profundo en SageMaker, tenga en cuenta los siguientes consejos para lograr una velocidad de capacitación más rápida:

• Pruebe primero el método de varias CPU y una sola instancia o el método de una sola GPU y una sola instancia. Si la utilización de CPU/GPU es muy alta (por ejemplo, más del 90 %), avance al siguiente paso.
• Pruebe más CPU en un solo host o más GPU en un solo host. Si la utilización está cerca de la utilización máxima de CPU o GPU, avance al siguiente paso.
• Pruebe varias CPU o varias GPU con varios hosts.
• Debe modificar los códigos cuando utilice servidores de parámetros u Horovod. La modificación del código no es la misma para la API basada en sesión de TensorFlow, tf.estimator API y tf.keras API. Un servidor de parámetros u Horovod puede mostrar diferentes velocidades de entrenamiento en diferentes casos y tareas de entrenamiento, así que pruebe ambos métodos si tiene el tiempo y el presupuesto para determinar cuál es el mejor.

Ten en cuenta los siguientes consejos:

• Verifique la utilización antes de escalar, optimice su flujo de datos y haga que la CPU y la GPU se superpongan en la línea de tiempo.
• Primero escalar hacia arriba, luego escalar hacia afuera.
• Si no puede aumentar su uso de GPU después de todos los métodos, pruebe con CPU. Hay muchos casos (especialmente para el modelo de clasificación de la tasa de clics) en los que el tiempo total de capacitación de instancias de CPU es más corto y más rentable que el de instancias de GPU.

También tenemos un ejemplo de código en el Repositorio GitHub, donde mostramos dos ejemplos de capacitación distribuida de DeepFM en SageMaker. Uno es un servidor de parámetros TensorFlow en instancias de CPU, el otro es Horovod en instancias de GPU.

Acerca de los autores

yuhui liang es Arquitecto Sr. de Soluciones de Aprendizaje Automático. Está enfocado en la promoción y aplicación del aprendizaje automático y está profundamente involucrado en los proyectos de aprendizaje automático de muchos clientes. Tiene una rica experiencia en capacitación distribuida de aprendizaje profundo, sistemas de recomendación y publicidad computacional.

Shishuai Wang es Arquitecto Sr. de Soluciones de Aprendizaje Automático. Trabaja con los clientes de AWS para ayudarlos a adoptar el aprendizaje automático a gran escala. Le gusta ver películas y viajar por el mundo.