Cómo generar perfiles de entornos multislice

Los entornos de varias porciones de Cloud TPU se componen de varias porciones de pod de TPU que se comunican a través de la red del centro de datos (DCN). Puedes usar la herramienta de estadísticas colectivas de DCN para ver información sobre la eficacia con la que el entorno Multislice utiliza la red de DCN. Específicamente, la herramienta DCN Collective Stats te permite hacer lo siguiente:

• Ver y comprender el rendimiento de la red entre porciones en función de los datos recopilados
• Cómo identificar cuellos de botella en el rendimiento
• Optimiza el rendimiento de tu modelo

Todas las métricas de la herramienta de estadísticas colectivas de DCN se generan por TPU.

Terminología

La herramienta de estadísticas colectivas de DCN muestra métricas que describen la comunicación que se produce entre porciones de TPU dentro de un entorno de varias porciones. Cuando el entorno de ejecución de la TPU inicia la comunicación entre porciones, se usa una serie de operaciones:

send

Interrumpe el host para iniciar el acceso directo a la memoria (DMA) y proporciona un búfer lleno al host para iniciar la transferencia de datos.

send-done

Indica al host que se completó la transferencia de datos.

recv

Proporciona un búfer vacío para que el host complete con los datos transferidos.

recv-done

Indica al host que se recibieron los datos.

Nota: El envío real de los datos se produce después de que se completa la operación send. La operación send-done se produce después de que se enviaron los datos. Del mismo modo, se reciben datos después de que se completa la operación recv. La operación recv-done ocurre después de que se reciben los datos.

Un conjunto se inicia cuando se produce una operación send y se completa cuando se produce la operación recv-done coincidente.

Tiempo de Slack

Es una medida de tiempo que el colectivo puede enviar y recibir datos. Esto no incluye las operaciones send, send-done, recv ni recv-done. Por ejemplo, teniendo en cuenta el siguiente cronograma:

El tiempo de Slack se calcula en este ejemplo de la siguiente manera:

Tiempo de Slack = t₁ + t₂ + t₃

El aumento del tiempo de holgura reduce las posibilidades de detener la TPU para un colectivo. Para aumentar el tiempo de holgura, elige otro método de fragmentación.

Duración del puesto

La duración promedio de tiempo que el colectivo dedica a las operaciones de envío, envío, recuperación y recuperación. Ten en cuenta que esto no incluye el tiempo dedicado a la transmisión de datos. Por ejemplo, teniendo en cuenta el siguiente cronograma:

La duración de los puestos se calcula en este ejemplo de la siguiente manera:

Duración del tiempo de espera = t_send + t_send-done + t_recv + t_rev-done

Duración observada

La cantidad de tiempo entre las operaciones send y recv-done, incluido el tiempo de envío y recepción de datos. Por ejemplo, teniendo en cuenta el siguiente cronograma:

La duración observada se calcula de la siguiente manera:

Duración observada = t_send + t₁ + t_send-done + t₂ + t_recv + t₃ + t_recv-done

Occurrences

La cantidad de veces que se inicia y completa un conjunto durante la duración de un perfil. Un conjunto se inicia cuando se produce una operación send y se completa cuando se produce la operación recv-end coincidente. La operación send y su operación recv-done coincidente deben ocurrir dentro de la duración del perfil para que se incluyan en esta métrica.

Puesto total agregado

Es la cantidad total de tiempo que un colectivo detiene una TPU durante la duración de un perfil. La demora total de agregación se calcula de la siguiente manera:

Suspensión total agregada = duración de la demora * casos

Tamaño de los datos transmitidos

Es la cantidad de datos transmitidos por la red para el grupo durante la duración del perfil.

Ancho de banda necesario

El ancho de banda necesario para transmitir datos dentro del slack proporcionado. Puedes usar esta métrica para ver la cantidad de grupos que compiten por el ancho de banda de red durante la duración del perfil. El ancho de banda necesario se calcula de la siguiente manera:

Ancho de banda necesario = tamaño de transmisión de datos / tiempo de inactividad

Estado de la herramienta

En la siguiente tabla, se muestra la versión de TensorFlow o del entorno de ejecución de TPU necesaria para cada métrica que se muestra en la herramienta de estadísticas colectivas de DCN.

Estadísticas colectivas de DCN	TensorFlow compatible con la versión del entorno de ejecución de TPU
Tiempo de Slack	TensorFlow 2.15.0, TensorBoard 2.15.1 y tensorboard-plugin-profile 2.15.0
Duración del puesto	TensorFlow 2.15.0, TensorBoard 2.15.1 y tensorboard-plugin-profile 2.15.0
Duración observada	TensorFlow 2.15.0, TensorBoard 2.15.1 y tensorboard-plugin-profile 2.15.0
Occurrences	TensorFlow 2.15.0, TensorBoard 2.15.1 y tensorboard-plugin-profile 2.15.0
Puesto total agregado	tf-noche, tb-noche, tbp-noche
Tamaño de los datos transmitidos	tf-noche, tb-noche, tbp-noche
Ancho de banda necesario	tf-noche, tb-noche, tbp-noche

Cómo analizar la herramienta DCN Collective Stats

1. Ejecuta el servidor de TensorBoard y ve a la pestaña Perfil.
2. Ordena la tabla en la herramienta de estadísticas colectivas DCN por Registro total agregado en orden descendente.
3. Identifica el nombre colectivo de DCN que tiene el bloqueo total agregado más alto. Si la duración de inactividad agregada de este colectivo es significativamente alta en comparación con otros, esto podría indicar que hay un cuello de botella en el colectivo de DCN.
4. Multiplica el ancho de banda requerido del conjunto DCN por la cantidad de núcleos. Hay 8 núcleos por cada host de TPU v4, por lo que el ancho de banda necesario para un colectivo es 8 veces el valor que se muestra. Si el ancho de banda requerido es mayor que el ancho de banda máximo de la red de la TPU, esto puede significar que la red está congestionada. Para reducir el ancho de banda requerido, intenta cambiar el mecanismo de fragmentación que usas. Para obtener más información sobre los mecanismos de fragmentación, consulta Descripción general de Cloud TPU Multislice.
5. Genera un volcado de HLO para determinar si hay algún problema del compilador. Es mejor distribuir las operaciones send y recv-done para un colectivo a fin de permitir la programación de más operaciones de HLO superpuestas. La superposición de más operaciones de HLO reduce el tiempo de inactividad de la TPU.
6. Verifica la duración de las operaciones recv-done en el Visor de seguimiento del conjunto de DCN que tiene el bloqueo total máximo agregado. Si la duración de la transferencia es alta, podría haber un cuello de botella en el ancho de banda, ya que las operaciones de recv-done suelen estar bloqueadas en la red para obtener los datos.
7. Si la duración de las operaciones de recv-done no es demasiado alta en comparación con el tiempo de demora, esto podría indicar un problema de hardware.