Cómo crear 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 de DCN. Específicamente, la herramienta Megascale Stats te permite hacer lo siguiente:

• Cómo ver y comprender el rendimiento de la red entre segmentos según los datos recopilados
• Identifica cuellos de botella en el rendimiento
• Optimiza 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 para capturar el perfil en tu framework y usa la biblioteca de 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 Multislice, TensorBoard mostrará la herramienta "Estadísticas a gran escala" para cualquier carga de trabajo de Multislice.

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 la 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 tiempo 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.

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

Tiempo de holgura

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 holgura se calcula de la siguiente manera:

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

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

Duración del atasco

Es la duración promedio del tiempo que la colectividad dedica a las operaciones de envío, envío completado, recepción y recepción completada. 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 del embotellamiento se calcula de la siguiente manera:

Duración de la 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

Es la cantidad de veces que se inicia y 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 coincidente. 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 un colectivo detiene una TPU durante 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 * Ocurrencias

Tamaño de los datos transmitidos

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

Ancho de banda requerido

Es el ancho de banda necesario para transmitir datos dentro de la holgura proporcionada. Puedes usar esta métrica para ver la cantidad de colectivos que compiten por el ancho de banda de la red durante 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 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 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 tiempo de ejecución de la TPU
Tiempo de holgura	TensorFlow 2.15.0, TensorBoard 2.15.1 y tensorboard-plugin-profile 2.15.0
Duración del atasco	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 Aggregated Total Stall en orden descendente.

3. Identifica el nombre colectivo de la DCN que tiene el mayor valor de Aggregated Total Stall. 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 la 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 la Descripción general de Cloud TPU Multislice.

5. Genera un volcado de HLO para determinar si hay problemas con el 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 inactividad de la TPU.

6. Verifica la duración de las operaciones recv-done en el Visualizador de registros para el colectivo de DCN que tiene la mayor cantidad total de detenciones agregadas. 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 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 holgura, esto podría indicar un problema de hardware.