Creación de perfiles de entornos Multislice

Los entornos Multislice de TPU de Cloud se componen de varios slices de TPU que se comunican a través de la red del centro de datos (DCN). Puedes usar la herramienta de estadísticas de Megascale de XProf para ver información sobre la eficacia con la que tu entorno Multislice utiliza la red DCN. En concreto, la herramienta Estadísticas de Megascale te permite hacer lo siguiente:

• Ver y comprender el rendimiento de la red entre las porciones en función de los datos recogidos
• Identificar cuellos de botella de rendimiento
• Optimizar el rendimiento del modelo

Todas las métricas de la herramienta de estadísticas de Megascale se generan por TPU. Para habilitar esta herramienta, sigue los mismos pasos para capturar el perfil en tu framework y usa la biblioteca XProfiler para configurar una instancia de TensorBoard XProf para ver tus perfiles. Siempre que tu carga de trabajo se haya ejecutado como una carga de trabajo de varios slices, TensorBoard mostrará la herramienta "Estadísticas de megascala" para cualquier carga de trabajo de varios slices.

Para obtener más información sobre la herramienta de estadísticas de Megascale en XProf, consulta la guía de la herramienta de estadísticas de Megascale.

Terminología

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

• send: interrumpe al host para iniciar el acceso directo a memoria (DMA) y proporciona un búfer lleno al host para iniciar la transferencia de datos.
• send-done: indica al host que la transferencia de datos se ha completado.
• recv: proporciona un búfer vacío para que el host lo rellene con los datos transferidos.
• recv-done: indica al host que se han recibido los datos.

Nota: El envío de datos se produce una vez completada la operación send. La operación send-done se produce después de que se hayan enviado los datos. Del mismo modo, los datos se reciben después de que se complete la operación recv. La operación recv-done se produce después de que se hayan recibido los datos.

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

Tiempo de holgura

Medida del tiempo que el colectivo puede enviar y recibir datos. Esto no incluye las operaciones send, send-done, recv ni recv-done. Por ejemplo, dada la siguiente cronología:

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

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

Si aumentas el tiempo de inactividad, se reduce la probabilidad de que la TPU se detenga en un colectivo. Puedes aumentar el tiempo de inactividad eligiendo otro método de fragmentación.

Duración de la parada

Duración media del tiempo que el colectivo dedica a las operaciones de envío, envío completado, recepción y recepción completada. Ten en cuenta que no se incluye el tiempo dedicado a transmitir datos. Por ejemplo, dada la siguiente cronología:

En este ejemplo, la duración del bloqueo se calcula de la siguiente manera:

Duración del bloqueo = t_send + t_send-done + t_recv + t_recv-done

Duración observada

El tiempo transcurrido entre las operaciones send y recv-done, incluido el tiempo de envío y recepción de datos. Por ejemplo, dada la siguiente cronología:

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

Repeticiones

Número de veces que se inicia y se completa un colectivo durante la duración de un perfil. Un colectivo se inicia cuando se produce una operación send y se completa cuando se produce la operación recv-end correspondiente. La operación send y su operación recv-done correspondiente deben producirse en un periodo de duración del perfil para incluirse en esta métrica.

Tiempo total de bloqueo agregado

Tiempo total que un colectivo detiene una TPU durante la duración de un perfil. El tiempo total de espera de la agregación se calcula de la siguiente manera:

Tiempo total de bloqueo agregado = duración del bloqueo * número de veces que se produce

Tamaño de los datos transmitidos

Cantidad de datos transmitidos a través de la red para el colectivo durante la duración del perfil.

Ancho de banda necesario

El ancho de banda necesario para transmitir datos dentro del margen proporcionado. Puedes usar esta métrica para ver el número de colectivos que compiten por el ancho de banda de la 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 los datos transmitidos/tiempo de holgura

Estado de la herramienta

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

Estadísticas colectivas de DCN	Versión de TensorFlow compatible con la versión del entorno de ejecución de TPU
Tiempo de holgura	TensorFlow 2.15.0, TensorBoard 2.15.1 y tensorboard-plugin-profile 2.15.0
Duración de la parada	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
Repeticiones	TensorFlow 2.15.0, TensorBoard 2.15.1 y tensorboard-plugin-profile 2.15.0
Tiempo total de bloqueo agregado	tf-nightly, tb-nightly, tbp-nightly
Tamaño de los datos transmitidos	tf-nightly, tb-nightly, tbp-nightly
Ancho de banda necesario	tf-nightly, tb-nightly, tbp-nightly

Cómo analizar la herramienta Estadísticas colectivas de DCN

1. Ejecuta el servidor de TensorBoard y ve a la pestaña Perfil.

2. En la herramienta de estadísticas colectivas de DCN, ordena la tabla por Total de paradas agregadas en orden descendente.

3. Identifica el nombre colectivo de DCN que tenga el Total agregado de paradas más alto. Si la duración de la inactividad agregada de este colectivo es significativamente alta en comparación con otros, podría indicar que hay un cuello de botella en el colectivo de DCN.

4. Multiplica el ancho de banda necesario del colectivo de DCN por el número de núcleos. Hay 8 núcleos por host de TPU v4, por lo que el ancho de banda necesario para un colectivo es 8 veces el valor mostrado. Si el ancho de banda necesario es mayor que el ancho de banda de red máximo de la TPU, puede que la red esté congestionada. Para reducir el ancho de banda necesario, prueba a cambiar el mecanismo de fragmentación que usas. Para obtener más información sobre los mecanismos de partición, consulta la descripción general de Multislice de TPU de Cloud.

5. Genera un volcado de HLO para determinar si hay algún problema con el compilador. Es mejor distribuir las operaciones send y recv-done de un colectivo para permitir la programación de más operaciones HLO superpuestas. Superponer más operaciones de HLO reduce el tiempo de inactividad de la TPU.

6. Consulta la duración de las operaciones de recv-done en el visor de trazas de la colectividad de DCN que tenga el tiempo de espera total agregado máximo. Si la duración de la transferencia es alta, puede que haya un cuello de botella en el ancho de banda, ya que las operaciones recv-done suelen bloquearse 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 inactividad, podría indicar un problema de hardware.