Herramienta de estadísticas de Megascale

Puedes usar la herramienta Megascale Stats para analizar el rendimiento de la comunicación entre porciones de las cargas de trabajo que abarcan varias porciones de TPU que se comunican a través de la red del centro de datos (DCN).

Todas las métricas que se muestran en la herramienta de estadísticas de Megascale se generan por TPU.

Plataformas compatibles

La herramienta de estadísticas de Megascale solo es compatible con las TPU.

La herramienta muestra métricas relacionadas con la comunicación entre las porciones de TPU, que incluyen las siguientes 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.

Un colectivo se inicia con una operación send y se completa con la operación recv-done correspondiente. El envío real de datos se produce después de que se completa la operación de envío. 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.

Componentes de la interfaz

La herramienta muestra una tabla con las siguientes columnas, con una fila para cada operación colectiva analizada:

  • Nombre del colectivo de DCN: Lo asigna XLA.
  • Nombre de la operación de recv: Es el nombre de la operación recv-done de la TPU. Esto proporciona una forma sencilla de buscar en el lector de seguimiento las operaciones colectivas de TPU correspondientes.
  • Nombre de la operación de envío: Es el nombre de la operación de la TPU send.
  • Tiempo de holgura: Se define como el tiempo independiente de la red que tiene el colectivo para transmitir los datos. Es una medida del tiempo que el colectivo tiene disponible para enviar y recibir datos, sin incluir las operaciones send, send-done, recv ni recv-done. Aumentar el tiempo de inactividad reduce las posibilidades de que la TPU se detenga para un colectivo. Por ejemplo, dada la siguiente línea de tiempo:

Cronograma que muestra el tiempo de holgura

Slack time is calculated in this example as:

Slack time = t<sub>1</sub> + t<sub>2</sub> + t<sub>3</sub>
  • Duración observada: Es la duración observada para cada colectivo. Se calcula como el intervalo entre el inicio de la operación send y el final de la operación recv-done correspondiente, incluido el tiempo dedicado al envío y la recepción de datos. Por ejemplo, dada la siguiente línea de tiempo:

Cronograma que muestra la duración observada

Observed duration is calculated as:

Observed duration = t<sub>send</sub> + t<sub>1</sub> + t<sub>send-done</sub> + t<sub>2</sub> + t<sub>recv</sub> + t<sub>3</sub> + t<sub>recv-done</sub>
  • Duración de la detención: Es la duración del tiempo que el colectivo detiene la TPU. Esta es la duración total del tiempo que la colectividad dedica a las operaciones send, send-done, recv y recv-done, sin incluir el tiempo dedicado a transmitir datos. Por ejemplo, dada la siguiente línea de tiempo:

Cronograma que muestra la duración de la detención

Stall duration is calculated in this example as:

Stall duration = t<sub>send</sub> + t<sub>send-done</sub> + t<sub>recv</sub> + t<sub>recv-done</sub>
  • Ocurrencias: Es la cantidad total de veces que un colectivo se inicia y completa en el transcurso de la duración de un perfil. La operación send y su operación recv-done coincidente deben ocurrir dentro de la duración del perfil para incluirse en esta métrica.
  • Detención total agregada: Es la cantidad total de tiempo que el 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 * casos
  • Tamaño de los datos transmitidos: Es la cantidad de datos que se transmiten por la red para el colectivo, calculada en función de la forma de la operación de XLA.
  • Ancho de banda requerido: Es el ancho de banda necesario para transmitir los 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 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 inactividad

Cómo analizar los datos de la herramienta de estadísticas de Megascale

Para analizar los datos que se presentan en la herramienta, haz lo siguiente:

  1. Ordena la tabla por Aggregated Total Stall de forma descendente.
  2. Identifica el nombre del colectivo de DCN con el valor de Aggregated Total Stall más alto. Un valor significativamente alto en comparación con otros puede indicar un cuello de botella.
  3. Multiplica el Required Bandwidth del colectivo de la DCN por la cantidad de núcleos (p.ej., 8 por host de TPU v4). Si este valor es mayor que el ancho de banda máximo de la red de la TPU, es posible que la red esté congestionada. Intenta cambiar el mecanismo de fragmentación para reducir el ancho de banda requerido.
  4. Genera un volcado de HLO para verificar si hay problemas del compilador. Expandir las operaciones send y recv-done puede permitir programar más operaciones de HLO superpuestas y reducir el tiempo de detención de la TPU.
  5. Verifica la duración de las operaciones recv-done en el Visualizador de Cloud Trace para el colectivo con la mayor cantidad total de detención agregada. Una duración de transferencia alta podría indicar un cuello de botella en el ancho de banda, ya que las operaciones recv-done suelen bloquearse en la red.
  6. 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.