Solucionar problemas de TensorFlow - TPU

En esta guía, junto con las preguntas frecuentes, se ofrece ayuda para solucionar problemas a los usuarios que entrenan modelos de TensorFlow en TPUs de Cloud. Si estás solucionando problemas de entrenamiento de PyTorch o JAX, puedes consultar los documentos de solución de problemas de esos frameworks:

• Solución de problemas de PyTorch - TPU
• Solución de problemas de JAX - TPU

Para obtener más guías generales sobre cómo usar Cloud TPU, consulta los siguientes artículos:

• Guías de inicio rápido de las TPU de Cloud
• Introducción a las TPU de Cloud

Nota: Si no puedes resolver el problema con esta guía, consulta la sección Obtener asistencia para obtener más ayuda.

Información general

Los problemas habituales que se producen con las TPUs de Cloud se clasifican en las siguientes categorías:

1. Problemas para conectarse a la TPU

2. Depurar errores habituales

3. Reducir el uso de memoria

4. Mejorar la velocidad de entrenamiento

5. Depurar las bajadas en la precisión del modelo

Problemas para conectar con el servidor de TPU

En esta sección se describe cómo solucionar problemas en los que TensorFlow deja de responder o muestra un error al conectarse a la TPU. El paso de compilación del gráfico de TPU puede tardar mucho tiempo en modelos grandes, así que deja que la secuencia de comandos se ejecute durante al menos 5 minutos antes de concluir que ha dejado de responder.

El primer paso es verificar si el problema está en el propio servidor o en tu canalización de entrenamiento de TensorFlow. Para ello, ejecuta tu programa de TensorFlow y comprueba que funciona correctamente. Si sigue habiendo problemas de conexión, esto confirma que el problema está en el servidor de TPU. En ese caso, ocurrirá lo siguiente:

1. Ejecuta el siguiente comando para enumerar las TPUs disponibles. Sustituye zone y project-id por tu zona y tu ID de proyecto.

   (vm)$ gcloud compute tpus tpu-vm list --zone zone --project project-id

   Se imprimirá un resultado como el siguiente:

   NAME       ZONE           ACCELERATOR_TYPE  NETWORK_ENDPOINT   NETWORK  RANGE          STATUS
   TPU_NAME   us-central1-b  v2-8              10.240.1.2:8470    default  10.240.1.0  READY

2. Verifica que esta TPU aparezca como READY.

3. Si tu TPU no aparece como READY o sigues teniendo problemas para conectarte, reinicia manualmente el servidor con el siguiente comando:

   (vm)$ gcloud compute tpus tpu-vm stop TPU_NAME && gcloud compute tpus tpu-vm start TPU_NAME

   Este proceso puede tardar varios minutos.

4. Vuelve a ejecutar el comando gcloud compute tpus tpu-vm list y espera a que la TPU esté en el estado READY. Este proceso puede tardar varios minutos.

5. Intenta ejecutar el programa de nuevo.

6. Si sigues teniendo problemas, pide ayuda con uno de los mecanismos descritos en Obtener asistencia.

Si el código se ejecuta correctamente, pero el modelo sigue sin responder, es probable que el problema esté en la canalización de entrenamiento. Para depurar este problema, empieza por sustituir TPUStrategy en tu código por la estrategia predeterminada. Si usas la estrategia predeterminada, el modelo se ejecutará en la CPU (o en la GPU, si está disponible) en lugar de en la TPU siempre que uses strategy.scope() o strategy.run(). Si el modelo se ejecuta en la CPU y no en la TPU, debe haber un problema específico de la TPU. Si sigue sin ejecutarse, lo más recomendable es depurar el problema en la CPU.

Pérdida de la conexión ssh durante el entrenamiento

Es posible que se agote el tiempo de espera de la ssh conexión con la TPU de Cloud durante un entrenamiento de larga duración (sobre todo si usas Cloud Shell). En ese momento, no se mostrará ningún resultado en la consola de la TPU y puede parecer que la TPU ha detenido el entrenamiento. Para evitarlo, ejecuta la sesión de entrenamiento con un multiplexor de terminal o una herramienta de gestión de sesiones, como tmux o screen. De esta forma, la conexión ssh se mantendrá activa independientemente de la duración del entrenamiento.

Depurar errores habituales

En esta sección se describe cómo solucionar los errores habituales que pueden surgir al entrenar modelos en TPUs de Cloud.

No se puede crear una TPU

Al crear una TPU de Cloud, puede que aparezca el siguiente error:

googleapiclient.errors.HttpError: < HttpError 403 when requesting https://content-tpu.googleapis.com/v1/projects/{PROJECT}/locations/{ZONE}/nodes/{TPU_NAME}?alt=json returned "Request had insufficient authentication scopes."

Se trata de un problema de permisos que se puede solucionar ejecutando el siguiente comando:

gcloud auth login --update-adc

Este comando actualiza tus credenciales predeterminadas de la aplicación y debería solucionar el problema. Para obtener más información, consulta gcloud auth login.

No se admiten formas dinámicas

Mensaje de error

ValueError: shape [Shape] must have a fixed size for dimension
d that is known at graph construction time.

Frameworks y configuraciones afectados

Este mensaje solo se produce durante la compilación de XLA con TensorFlow.

Detalles

Para ejecutar un modelo en la TPU, TPU de Cloud compila el modelo con el compilador XLA. Aunque este paso de compilación mejora significativamente la velocidad de entrenamiento y el uso de memoria, se deben conocer las formas (tamaños de las dimensiones) de todos los tensores del gráfico en el momento de la compilación. Si no se pueden determinar las formas en tiempo de compilación, la compilación de TPU falla y se muestra un error como el que se ha mostrado anteriormente.

Una operación habitual que devuelve una forma dinámica es dataset.batch(batch_size), ya que el número de muestras que quedan en un flujo puede ser inferior al tamaño del lote. Por lo tanto, cuando entrenes en la TPU, asigna el valor drop remainder=True a dataset.batch. De esta forma, se pueden eliminar las últimas muestras de un archivo para asegurarse de que cada lote tenga una forma estática de batch_size. Por ejemplo:

dataset = tf.data.Dataset.range(8)
dataset = dataset.batch(3, drop_remainder=True)

Operación de TensorFlow no disponible

Mensaje de error

NotFoundError: No registered 'OpName' OpKernel for XLA_TPU_JIT
devices compatible with node

Frameworks y configuraciones afectados

Este mensaje puede aparecer al entrenar con TensorFlow.

Detalles

El modelo usa una operación de TensorFlow que no está disponible en la TPU.

Para ver una lista de las operaciones disponibles en la TPU, así como los planes de asistencia futura y las sugerencias de soluciones alternativas, consulta la guía sobre las operaciones de TensorFlow disponibles.

Mensaje de error de falta de memoria

Mensaje de error

ResourceExhaustedError: Ran out of memory in memory space hbm; used:
YYY; limit: 7.48G.

Frameworks y configuraciones afectados

Este mensaje puede aparecer al entrenar con TensorFlow, PyTorch o JAX.

Detalles

Cada TPU de Cloud consta de ocho núcleos de TPU. Las TPUs de la versión 2 tienen 8 GB de RAM y las de la versión 3, 16 GB de RAM (o HBM, memoria de alto ancho de banda). Esta memoria se usa para almacenar los tensores de peso (variable), así como los tensores de resultados intermedios necesarios para el cálculo del gradiente. Si el modelo es demasiado grande para caber en la RAM de la TPU, la inicialización falla y se imprime el mensaje de error. Para obtener más ayuda, consulta la sección sobre cómo reducir el uso de memoria.

Consejos para reducir el uso de memoria:

• Comprueba si hay un relleno de tensor excesivo.
• Usa el formato bfloat16.
• Si los tamaños de entrada o el modelo son demasiado grandes, puede usar el paralelismo de modelos experimental de TensorFlow para abordar el tamaño del modelo.

Problemas para detener la ejecución

Si TensorFlow detecta un error durante la ejecución de la TPU, a veces parece que la secuencia de comandos deja de responder en lugar de salir al shell. Si esto ocurre, pulsa CTRL+C en el teclado para activar una SIGQUIT, lo que provoca que Python se cierre inmediatamente.

Del mismo modo, al pulsar CTRL+C durante la ejecución de la TPU, no se cierra TensorFlow inmediatamente, sino que espera hasta el final del bucle de iteración actual para salir correctamente.

Si se produce algún error nuevo al volver a conectar con la TPU después de salir de esta forma, reinicia manualmente el servidor de la TPU con los comandos:

gcloud compute tpus tpu-vm stop tpu-name --zone=zone
gcloud compute tpus tpu-vm start tpu-name --zone=zone

donde tpu-name se toma de la primera columna que muestra el comando gcloud compute tpus tpu-vm list y zone es la zona que se muestra en la segunda columna.

Padding de tensor excesivo

Posible causa del problema de memoria

Los tensores de la memoria de la TPU se rellenan, es decir, la TPU redondea los tamaños de los tensores almacenados en la memoria para realizar los cálculos de forma más eficiente. Este relleno se produce de forma transparente a nivel de hardware y no afecta a los resultados. Sin embargo, en algunos casos, el relleno puede provocar un aumento significativo del uso de memoria y del tiempo de ejecución.

Cómo reducir el uso de memoria

El software de TPU intenta colocar los tensores en la memoria para maximizar la eficiencia computacional y minimizar el relleno. Sin embargo, este proceso de diseño de memoria es complejo, por lo que, para obtener los mejores resultados, el modelo debe seguir la siguiente regla general. Para minimizar la sobrecarga de memoria y maximizar la eficiencia computacional, se debe cumplir una de las siguientes condiciones:

• El tamaño total del lote debe ser un múltiplo de 64 (8 por núcleo de TPU) y las dimensiones de las características deben ser un múltiplo de 128.

  o

• El tamaño total del lote debe ser un múltiplo de 1024 (128 por núcleo de TPU) y las dimensiones de las características deben ser un múltiplo de 8.

Si se usa un tamaño de lote de 1024 y dimensiones de características que sean múltiplos de 128, se obtendrá la mejor eficiencia, aunque puede que no sea posible en todos los modelos. Para mayor claridad, "dimensión de la característica" hace referencia al tamaño oculto de una capa totalmente conectada o al número de canales de salida de una convolución. No todas las capas pueden cumplir esta regla, especialmente la primera y la última de la red. Es normal y se espera que la mayoría de los modelos requieran una cantidad de relleno.

Reducir el uso de memoria

Si se produce un error de falta de memoria al ejecutar el modelo en la TPU, debes tomar medidas para reducir el uso de memoria del modelo.

Las formas más eficaces de reducir el uso de memoria son las siguientes:

• Reducir el relleno excesivo de tensores
• Reducir el tamaño del lote

El tamaño del lote o el modelo es demasiado grande

Posible causa del problema de memoria

Cuando se entrena una red neuronal en una CPU, una GPU o una TPU, la memoria se usa en dos lugares:

1. El uso de memoria es proporcional al número de pesos del modelo.
2. Almacena las activaciones intermedias del pase hacia delante necesarias para calcular el pase hacia atrás. El uso de memoria es directamente proporcional al tamaño del lote, al tamaño de las capas y al número de capas.

Por lo tanto, la memoria que necesita un modelo depende en gran medida del tamaño del lote.

La memoria que necesita un modelo depende del número de capas de la red.

El tiempo de ejecución de TPU intenta optimizar los operadores para que el modelo quepa en la memoria (lo que se denomina rematerialización, similar a la creación de puntos de control de gradiente), pero no siempre lo consigue.

Cómo reducir el uso de memoria

Reduce lentamente el tamaño del lote hasta que quepa en la memoria. Asegúrate de que el tamaño total del lote sea un múltiplo de 64 (el tamaño del lote por núcleo debe ser un múltiplo de 8). Ten en cuenta que los tamaños de lote más grandes son más eficientes en la TPU. En general, un tamaño de lote total de 1024 (128 por núcleo) es un buen punto de partida.

Si el modelo no se puede ejecutar en la TPU aunque el tamaño del lote sea pequeño (por ejemplo, 64), prueba a reducir el número de capas o el tamaño de las capas.

Mejorar la velocidad de entrenamiento

Si tu modelo se puede ejecutar correctamente en la TPU, pero la velocidad de entrenamiento es inferior a la esperada, en esta sección se describen varias formas de mejorar la velocidad. Consulta la guía de rendimiento para ver otras sugerencias sobre cómo mejorar el rendimiento del entrenamiento.

Demasiados pocos pasos por ejecución por bucle de entrenamiento

Descripción del problema de rendimiento

Al pasar el argumento steps_per_execution a Model.compile controls el número de pasos de entrenamiento que se ejecutan entre las devoluciones de llamada del host. Cada retrollamada de host requiere una comunicación significativa entre la CPU del host del servidor de TPU y el dispositivo de TPU, por lo que, si steps_per_execution es demasiado pequeño, puede ralentizar el entrenamiento.

Cómo saber si tu modelo se ve afectado

Si un perfil de TPU revela retrollamadas frecuentes de la CPU del host entre los pasos del dispositivo de TPU, tu entrenamiento puede beneficiarse de un valor de steps_per_execution mayor.

Cómo mitigar el problema

Asigna a steps_per_execution un valor mayor. Ten en cuenta que steps_per_execution puede tener un valor grande, pero recuerda que los mensajes de registro y el guardado de un punto de control solo pueden producirse después de que se haya ejecutado el número de pasos especificado.

Cuello de botella en el procesamiento de entrada

Descripción del problema de rendimiento

Mientras la TPU entrena con un fragmento de datos concreto, la función de procesamiento de entrada prepara el siguiente fragmento de datos en la CPU. Si tu función de entrada tarda más que la función del modelo, la TPU estará inactiva mientras tu función de entrada recupera los datos.

Cómo saber si tu modelo se ve afectado

Sigue las instrucciones de Herramientas de TPU de Cloud: analizador de la canalización de entrada para ver el análisis de la canalización de entrada en TensorBoard:

En la página de análisis de la canalización de entrada se muestra un resumen claro que indica si el modelo tiene un cuello de botella en el procesamiento de entrada. En la misma página también se muestra el tiempo de ejecución por operación, lo que te permite identificar las operaciones problemáticas.

Cómo mitigar el problema

Hay varias medidas que se pueden tomar al cargar datos con la API Dataset:

1. Almacena tus datos como una colección de estructuras tf.train.Example en archivos TFRecord y cárgalos con TFRecordDataset. Consulta el tutorial de la API Dataset o el tutorial de ResNet para ver ejemplos.
2. Usa dataset.cache() o dataset.prefetch() para almacenar en búfer los datos de entrada. De esta forma, se evita que las ralentizaciones esporádicas en el acceso a los archivos creen un cuello de botella.
3. Especifica el parámetro num_parallel_calls de la función dataset.map() para habilitar las operaciones map() multiproceso. Una heurística para el valor de num_parallel_calls es usar el número de núcleos de CPU disponibles.
4. Realiza un preprocesamiento de datos costoso offline como un coste único, en lugar de incurrir en el coste en cada época de cada entrenamiento.

Todo el procesamiento de las entradas se realiza en las CPUs ubicadas en el servidor de TPU, no en la máquina local, por lo que la velocidad de la máquina local no es un factor determinante.

Tiempos de paso lentos y bajo uso de MXU

Descripción del problema de rendimiento

La TPU de Cloud puede realizar multiplicaciones de matrices y convoluciones a velocidades increíblemente altas. La mayoría de las demás operaciones de TensorFlow tienen implementaciones eficientes en la TPU, pero no son la principal ventaja de la TPU en comparación con otro hardware. Por lo tanto, un modelo debe estar dominado por multiplicaciones de matrices o convoluciones para aprovechar al máximo la TPU.

Cómo saber si tu modelo se ve afectado

En este caso, los síntomas que verás son tiempos de paso lentos junto con una utilización baja de MXU que se muestra cuando perfilas el rendimiento.

Cómo mitigar el problema

Intenta reducir el número de operaciones que no sean multiplicaciones de matrices. Después de reducir el número de multiplicaciones de matrices, vuelve a realizar una prueba comparativa para ver si el rendimiento es aceptable en las TPUs.

Padding de tensor excesivo

Descripción del problema de rendimiento

La TPU rellena los tensores en la memoria para que pueda usar sus unidades computacionales de forma eficiente. El relleno puede aumentar el uso de memoria y de ancho de banda de memoria. Consulta la sección sobre relleno de tensor para obtener ayuda sobre cómo entender y solucionar problemas de relleno de tensor.

Rendimiento lento y uso de memoria bajo

Descripción del problema de rendimiento

Por lo general, si se usan tamaños de lote más grandes, la velocidad de entrenamiento en la TPU será mayor (en términos de muestras por segundo).

Cómo saber si tu modelo se ve afectado

El tamaño de lote de cualquier modelo siempre debe ser de al menos 64 (8 por núcleo de TPU), ya que la TPU siempre rellena los tensores hasta este tamaño. El tamaño de lote ideal para entrenar en la TPU es 1024 (128 por núcleo de TPU), ya que así se eliminan las ineficiencias relacionadas con la transferencia de memoria y el relleno.

Cómo mitigar el problema

La práctica recomendada es usar el tamaño de lote más grande que quepa en la memoria y que sea múltiplo de 64. La forma más sencilla de hacerlo es empezar con 1024 y, si se produce un error de falta de memoria, reducir el tamaño del lote hasta que el modelo se ejecute correctamente. Si cambias el tamaño de lote de un modelo, es posible que tengas que ajustar otros hiperparámetros para conseguir la misma precisión, como la tasa de aprendizaje, pero esto debe evaluarse caso por caso.

Tamaños de capa demasiado pequeños

Descripción del problema de rendimiento

Aunque un modelo esté dominado por multiplicaciones de matrices o convoluciones, es posible que la TPU no funcione con la máxima eficiencia si los tensores de entrada son pequeños. En comparación con otro hardware, la TPU funciona de forma más eficiente cuando tanto el tamaño del lote como el tamaño de las capas son grandes (por ejemplo, la dimensión es igual o superior a 512).

Cómo saber si tu modelo se ve afectado

Por lo general, las capas con un tamaño inferior a 128 no son eficientes en la TPU, ya que 128 es la dimensión integrada de la unidad de multiplicación de matrices de la TPU. En el caso de las capas totalmente conectadas, se recomienda un tamaño oculto mínimo de 512 para conseguir una alta eficiencia. Ten en cuenta que las capas convolucionales no suelen ser tan grandes como las capas totalmente conectadas para alcanzar el mismo nivel de eficiencia.

Cómo mitigar el problema

Si el motivo principal para usar capas pequeñas en tu modelo es la velocidad de entrenamiento, vuelve a medir el rendimiento de tus modelos con capas más grandes en la TPU. Por ejemplo, aumentar el tamaño de salida de una capa de 256 a 512 puede incrementar el tiempo de entrenamiento solo en un 20 %, aunque el modelo realice el doble de cálculos.

Elaboración de perfiles de modelos a nivel de operación

A menudo es útil medir el tiempo de ejecución y el uso de memoria a nivel de operación para identificar cuellos de botella en el rendimiento. Para obtener instrucciones sobre cómo hacerlo,
consulta la guía Herramientas de TPU de Cloud: Trace Viewer.

Depurar las bajadas en la precisión del modelo

Uno de los objetivos del ecosistema de TPU de Cloud es que cualquier modelo que se entrene en una CPU o GPU alcance una precisión muy similar cuando se entrene en la TPU, con pequeños ajustes en los hiperparámetros, como el tamaño del lote y la tasa de aprendizaje. Sin embargo, en ocasiones, los usuarios pueden observar una disminución de la precisión al entrenar modelos en la TPU. Depurar estos problemas puede ser extremadamente frustrante debido a la naturaleza aleatoria del entrenamiento de la red neuronal. En esta sección se explica cómo identificar la causa principal de cualquier descenso en la precisión del modelo al migrar un modelo a la TPU.

Información sobre la fragmentación de datos (paralelismo de datos)

Uno de los objetivos principales de TensorFlow es que cada op produzca resultados casi idénticos, ya sea que se ejecute en la CPU, la GPU o la TPU. Hay ciertas excepciones, como las operaciones aleatorias. Por lo general, si detectas alguna diferencia significativa entre la salida de operaciones no aleatorias en la TPU y la CPU, infórmala como error.

Sin embargo, en el caso de la pipeline de entrenamiento en su conjunto, hay una diferencia significativa entre el entrenamiento en la CPU o la GPU y en la TPU. Cuando se entrena en una TPU, TensorFlow realiza el fragmentación de datos. Cada TPU de Cloud contiene 8 núcleos de TPU que funcionan como unidades de procesamiento independientes. En cada paso del entrenamiento, cada núcleo de TPU recibe un lote de datos, calcula los gradientes de peso, intercambia los gradientes con los demás núcleos de TPU y, a continuación, calcula la actualización del peso. De forma predeterminada, la pérdida se calcula como la media de los núcleos, pero se puede sumar cambiando el parámetro de CrossShardOptimizer.

Si la pérdida total del modelo se puede calcular como la media (o la suma) de las pérdidas independientes por muestra, este procedimiento es matemáticamente equivalente al entrenamiento con un solo lote grande.

La operación más habitual que no es independiente por muestra es la normalización por lote, que se ejecuta en cada lote por núcleo por separado. Por ejemplo, si el tamaño total del lote es 128, el tamaño del lote por núcleo es 16 y cada uno de los 8 núcleos realiza la normalización por lotes en sus propias 16 muestras. En algunos casos, se ha observado que realizar la normalización por lotes en lotes pequeños (por ejemplo, menos de 32) reduce la precisión. En el mejor de los casos, el tamaño total del lote debería ser grande (por ejemplo, de 256 a 1024). Si el tamaño de un lote es demasiado grande para caber en la memoria, el efecto de la fragmentación debe evaluarse caso por caso.

Depurar el entrenamiento de TPUs de varios núcleos

Si tu modelo consigue la misma pérdida en la CPU y en la TPU de un solo núcleo, es probable que el problema sea uno de los siguientes:

a) La degradación se debe a la varianza aleatoria natural al entrenar modelos neuronales con diferentes inicializaciones.

b) La degradación se debe a un problema relacionado con la fragmentación de datos en la TPU.

Para determinar si se trata del problema (a), vuelve a entrenar el modelo completo en la CPU o la GPU y en la TPU multinúcleo con la misma inicialización de peso.

Si tienes la certeza de que la disminución de la precisión es estadísticamente significativa, los problemas más probables relacionados con la fragmentación de datos son los siguientes:

1. Si tu modelo usa la normalización por lotes, un tamaño de lote total inferior a 256 (por ejemplo, menos de 32 por núcleo) podría reducir la precisión.
2. Las funciones de pérdida por lotes se ven afectadas por la fragmentación. Estas funciones de pérdida suelen ser bastante especializadas. Por ejemplo, Karras et al. 2017 usa un discriminador de lote al entrenar una red generativa antagónica.

Solución de problemas de configuración de gcloud

Problema

gcloud components update muestra el siguiente mensaje de error:

ERROR: (gcloud.components.update)
You cannot perform this action because the Cloud SDK component manager is
disabled for this installation.

Solución

Para usar la CLI de Google Cloud, debes usar una instalación que no se gestione a través de un gestor de paquetes.

1. Ejecuta el siguiente comando para eliminar la instalación actual de la CLI de gcloud:

   sudo apt-get remove google-cloud-sdk

2. Sigue las instrucciones para instalar Google Cloud CLI.

Problema

El comando gcloud compute tpus tpu-vm ssh TPU_NAME --zone ZONE muestra el siguiente mensaje de error:

Waiting for SSH key to propagate.
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ERROR: (gcloud.compute.tpus.tpu-vm.ssh) Could not SSH into the instance.  It is possible that your SSH key has not propagated to the instance yet. Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.

Solución

Puede que haya algún problema con la propagación de la clave SSH. Prueba a mover las claves generadas automáticamente a una ubicación de copia de seguridad para forzar a gcloud a que las vuelva a crear:

mv ~/.ssh/google_compute_engine ~/.ssh/old-google_compute_engine
mv ~/.ssh/google_compute_engine.pub ~/.ssh/old-google_compute_engine.pub

Registros de depuración

Los frameworks de TPU de Cloud compatibles, JAX, PyTorch y TensorFlow, acceden a las TPUs mediante una biblioteca compartida llamada libtpu que está presente en todas las VMs de TPU. Esta biblioteca incluye el compilador XLA, que se usa para compilar programas de TPU, el tiempo de ejecución de TPU, que se usa para ejecutar programas compilados, y el controlador de TPU, que usa el tiempo de ejecución para acceder a la TPU a nivel de hardware.

La biblioteca libtpu registra información que puede ser útil para la depuración. De forma predeterminada, estos registros se escriben en /tmp/tpu_logs en cada VM de TPU de Cloud. Puedes definir las siguientes variables de entorno antes de empezar el entrenamiento para modificar el comportamiento de registro:

TPU_LOG_DIR: el directorio en el que se escriben los registros

La ubicación del directorio es /tmp/tpu_logs de forma predeterminada. El directorio se crea si aún no existe, pero no se crea ningún directorio principal. Si se produce un error al buscar o crear el directorio especificado, se imprimirá un mensaje en stderr, pero no se detendrá el programa y se inhabilitará el registro. Asigna el nombre "disabled" al directorio para inhabilitar por completo el registro en disco.

TPU_MIN_LOG_LEVEL: la gravedad mínima que se registrará en el disco.

Las opciones son 0 (INFO), 1 (WARNING), 2 (ERROR) y 3 (FATAL). El valor predeterminado es 0.

TPU_STDERR_LOG_LEVEL: la gravedad mínima que se registrará en stderr, además de en el disco, si procede.

Las opciones son las mismas que en TPU_MIN_LOG_LEVEL. El valor predeterminado es 3.

TPU_MAX_LOG_SIZE_MB: el tamaño máximo en megabytes de cada archivo de registro

Se iniciará automáticamente un nuevo archivo de registro cuando el anterior alcance aproximadamente este tamaño. El valor predeterminado es 1024.