Crea perfiles de entornos de Multislice

Los entornos de Cloud TPU Multislice se componen de varias porciones 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 en XProf para ver información sobre la eficacia con la que tu entorno de Multislice utiliza la red DCN. Específicamente, la herramienta de estadísticas de Megascale te permite hacer lo siguiente:

• Cómo ver y comprender el rendimiento de la red entre porciones según los datos recopilados
• Identificar cuellos de botella en el rendimiento
• Optimizar el rendimiento de tu 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 que usas con el perfil en tu framework y utiliza la biblioteca de XProfiler para configurar una instancia de TensorBoard XProf y visualizar tus perfiles. Siempre que tu carga de trabajo se haya ejecutado como una carga de trabajo de Multislice, TensorBoard mostrará la herramienta "Estadísticas de Megascale" para cualquier carga de trabajo de porción múltiple.

Para obtener más detalles 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 porciones de TPU dentro de un entorno de Multislice. 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 completo 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 lo complete con los datos transferidos.
• recv-done: Indica al host que se recibieron los datos.

Nota: El envío real de 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 envían los datos. Del mismo modo, los datos se reciben después de que se completa la operación recv. La operación recv-done se produce después de que se reciben 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 inactividad

Es una medida del tiempo durante el 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 línea de tiempo:

En este ejemplo, el tiempo de inactividad se calcula de la siguiente manera:

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

Aumentar el tiempo de inactividad reduce las posibilidades de que la TPU se detenga para un colectivo. Puedes aumentar el tiempo de inactividad tras elegir otro método de fragmentación.

Duración de la detención

Es la duración promedio del tiempo que el colectivo dedica a las operaciones send, send-done, recv y recv-done. Ten en cuenta que esto no incluye el tiempo dedicado a transmitir datos. Por ejemplo, dada la siguiente línea de tiempo:

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

Duración de detención = t_send + t_send-done + t_recv + t_recv-done

Duración observada

Es la cantidad de tiempo entre las operaciones send y recv-done, incluido el tiempo de envío y recepción de datos. Por ejemplo, dada la siguiente línea de tiempo:

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

Casos

La cantidad de veces que un colectivo se inicia y completa en el transcurso de la duración del 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 coincidente deben ocurrir dentro de la duración de un perfil para incluirse en esta métrica.

Detención total agregada

Es la cantidad total de tiempo que el colectivo detiene una TPU en el transcurso de la duración de un perfil. El tiempo total de detención de la agregación se calcula de la siguiente manera:

Detención total agregada = duración de la detención * casos

Tamaño de los datos transmitidos

Es la cantidad de datos transmitidos por la red para el colectivo en el transcurso de la duración del perfil.

Ancho de banda requerido

Es el ancho de banda necesario para transmitir datos dentro de la inactividad proporcionada. Puedes usar esta métrica para ver la cantidad de colectivos que compiten por el ancho de banda de la red en el transcurso de la duración del perfil. El ancho de banda requerido se calcula de la siguiente manera:

Ancho de banda requerido = tamaño de los datos transmitidos / 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 que se requiere para cada métrica que se muestra en la herramienta de estadísticas colectivas de DCN.

Estadísticas colectivas de DCN	Versión de TensorFlow compatible con el entorno de ejecución de TPU
Tiempo de inactividad	TensorFlow 2.15.0, TensorBoard 2.15.1 y tensorboard-plugin-profile 2.15.0
Duración de la detención	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
Casos	TensorFlow 2.15.0, TensorBoard 2.15.1 y tensorboard-plugin-profile 2.15.0
Detención total agregada	tf-nightly, tb-nightly, tbp-nightly
Tamaño de los datos transmitidos	tf-nightly, tb-nightly, tbp-nightly
Ancho de banda requerido	tf-nightly, tb-nightly, tbp-nightly

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

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

2. Ordena la tabla en la herramienta de estadísticas colectivas de DCN por Detención total agregada en orden descendente.

3. Identifica el nombre del colectivo de DCN que tiene el mayor valor de Detención total agregada. Si la duración total de la detención 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 colectivo de la DCN por la cantidad de núcleos. Hay 8 núcleos por host de TPU v4, por lo que el ancho de banda requerido para una operación colectiva 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, es posible que la red esté congestionada. Para reducir el ancho de banda requerido, intenta cambiar el mecanismo de fragmentación que utilizas. 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 problemas del compilador. Es mejor expandir las operaciones send y recv-done para un colectivo, y permitir la programación de más operaciones de HLO superpuestas. Superponer más operaciones de HLO reduce el tiempo de detención de la TPU.

6. Verifica la duración de las operaciones recv-done en el Visualizador de Cloud Trace para el colectivo de DCN que tiene la mayor cantidad total de detención agregada. 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 recv-done suelen bloquearse en la red para obtener los datos.

7. Si la duración de las operaciones recv-done no es demasiado alta en comparación con el tiempo de inactividad, esto podría indicar un problema de hardware.