Soluciona problemas de TensorFlow en la TPU
En esta guía, junto con las Preguntas frecuentes, se proporciona ayuda a los usuarios que entrenan modelos de TensorFlow en Cloud TPU para que puedan solucionar problemas. Si estás intentando solucionar problemas relacionados con el entrenamiento de PyTorch o JAX, puedes consultar los documentos de solución de problemas de esos frameworks:
Para obtener guías más generales sobre cómo usar Cloud TPU, consulta los siguientes vínculos:
Descripción general
Los problemas habituales que se encuentran cuando se usa Cloud TPU se clasifican en las siguientes categorías:
Problemas para establecer la conexión al servidor de la TPU
En esta sección, se describe cómo solucionar problemas en situaciones en las que TensorFlow deja de responder o muestra un error cuando se conecta a la TPU. Ten en cuenta que el paso de compilación de grafos de la TPU puede llevar más tiempo con modelos grandes. No creas que la secuencia de comandos se interrumpió si tarda hasta 5 minutos en ejecutarse.
El primer paso es verificar si el problema es con el servidor o con la canalización de entrenamiento de TensorFlow. Para ello, ejecuta tu programa de TensorFlow y verifica que funcione de forma correcta. Si aún hay problemas de conexión, esto confirma que el problema está relacionado con el servidor de la TPU. En este caso, ocurre lo siguiente:
Ejecuta el siguiente comando para mostrar las TPU disponibles: Reemplaza zone y project-id por tu zona y el ID del proyecto.
(vm)$ gcloud compute tpus tpu-vm list --zone zone --project project-id
Esto muestra una salida como la 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
Verifica que esta TPU aparezca como
READY.Si tu TPU no aparece como
READYo si aún tienes problemas para conectarte, reinicia el servidor de forma manual con el siguiente comando:(vm)$ gcloud compute tpus tpu-vm stop TPU_NAME && gcloud compute tpus tpu-vm start TPU_NAME
Esto puede tardar varios minutos en completarse.
Vuelve a ejecutar el comando
gcloud compute tpus tpu-vm listanterior y espera a que la TPU esté en estadoREADY. Esto podría llevar varios minutos.Vuelve a ejecutar tu programa.
Si los problemas persisten, pide ayuda con uno de los mecanismos que se describen en Obtén asistencia.
Si tu código se ejecuta de forma correcta, pero tu modelo sigue sin responder, es probable que el problema esté relacionado con la canalización de entrenamiento.
Para depurar esto, empieza por reemplazar TPUStrategy en tu código por la estrategia predeterminada. Cuando usas la estrategia predeterminada, cada vez que usas strategy.scope() o strategy.run(), el modelo se ejecuta en la CPU (o en la GPU, si está presente) y no en la TPU. Si el modelo se ejecuta en la CPU y no en la TPU, debe haber un problema específico de la TPU. Si aún no se ejecuta, la práctica recomendada es depurar el problema en la CPU.
Pérdida de conexión ssh durante el entrenamiento
Es posible que se agote el tiempo de espera de tu conexión ssh a la Cloud TPU durante un entrenamiento de larga duración (en especial si usas Cloud Shell).
En ese punto, no hay salida en la consola de la TPU y puede parecer que el entrenamiento se detuvo. Para evitar esto, ejecuta la sesión de entrenamiento con un multiplexor de terminal o una herramienta de administración de sesiones, como tmux o screen. Esto mantendrá activa la conexión de ssh, sin importar la duración del entrenamiento.
Depura los errores comunes
En esta sección, se describe cómo solucionar problemas habituales que puedes encontrar cuando entrenas modelos en Cloud TPU.
No se puede crear una TPU
Cuando creas una Cloud TPU, es posible que veas 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."
Este es un problema de permisos que se puede resolver ejecutando el siguiente comando:
gcloud auth login --update-adc
Este comando actualiza tus credenciales predeterminadas de la aplicación (ADC) y debería resolver el problema. Para obtener más información, consulta gcloud auth login.
Formas dinámicas no compatibles
Mensaje de error
ValueError: shape [Shape] must have a fixed size for dimension d that is known at graph construction time.
Frameworks y configuración afectados
Este mensaje solo aparece durante la compilación de XLA con TensorFlow.
Detalles
Para ejecutar un modelo en la TPU, Cloud TPU compila el modelo con el compilador de XLA. Mientras que el paso de compilación mejora de forma significativa la velocidad de entrenamiento y el uso de memoria, las formas (tamaños de dimensiones) de todos los tensores en el grafo deben conocerse al momento de la compilación del grafo. Si no se pueden determinar algunas formas en el tiempo de compilación, la compilación de la TPU falla con un error como el anterior.
Una operación habitual que devuelve una forma dinámica es dataset.batch(batch_size), ya que el número de muestras restantes en una transmisión puede ser menor que el tamaño del lote. Por lo tanto, cuando entrenes en la TPU, configura drop remainder=True para dataset.batch.
Esto excluye potencialmente las últimas muestras de un archivo para garantizar 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 configuración afectados
Este mensaje puede aparecer cuando se entrena con TensorFlow.
Detalles
El modelo usa una operación de TensorFlow que, por el momento, no se encuentra disponible en la TPU.
Para obtener una lista de operaciones disponibles en la TPU, junto con los planes de asistencia futura y sugerencias para una solución alternativa, consulta la guía de operaciones de TensorFlow disponibles.
Mensaje de error de memoria insuficiente
Mensaje de error
ResourceExhaustedError: Ran out of memory in memory space hbm; used: YYY; limit: 7.48G.
Frameworks y configuración afectados
Este mensaje puede aparecer cuando se entrena con TensorFlow, PyTorch o JAX.
Detalles
Cada Cloud TPU está formada por ocho núcleos. Los modelos v2 tienen 8 GB y los v3 tienen 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 resultado intermedio necesarios en el cálculo de gradientes. Si el modelo es demasiado grande para la RAM de la TPU, falla la inicialización y se imprime el mensaje de error anterior. Consulta la sección sobre cómo reducir el uso de memoria para obtener más ayuda.
Sugerencias para reducir el uso de la memoria:
- Comprueba si hay un relleno excesivo del tensor.
- Usa el formato bfloat16.
- Si los tamaños de entrada o el modelo son demasiado grandes, puedes usar el paralelismo experimental del modelo de TensorFlow para abordar este problema.
Problemas para detener la ejecución
Si TensorFlow encuentra un error durante la ejecución de la TPU, la secuencia de comandos a veces parece interrumpirse en vez de salir de la shell. Si esto sucede, presiona CTRL+C en el teclado para activar un SIGQUIT, lo que hace que Python salga de inmediato.
De manera similar, si presionas CTRL+C durante la ejecución en la TPU, TensorFlow no se desactiva de inmediato; espera hasta que finalice el bucle de iteración actual para cerrarse de forma correcta.
Si surge algún error nuevo cuando vuelves a conectarte después de este cierre, restablece el servidor de la TPU de forma manual con los siguientes comandos:
gcloud compute tpus tpu-vm stop tpu-name --zone=zone gcloud compute tpus tpu-vm start tpu-name --zone=zone
En el ejemplo anterior, 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.
Relleno excesivo del tensor
Causa posible de problema de la memoria
Se rellenan los tensores en la memoria de la TPU, es decir, la TPU redondea los tamaños de los tensores almacenados en la memoria para realizar cálculos de forma más eficaz. Este relleno sucede de manera transparente en el nivel del hardware y no afecta los resultados. No obstante, en ciertos casos el relleno puede provocar un aumento significativo del uso de la memoria y del tiempo de ejecución.
Cómo reducir el uso de la memoria
El software de la TPU intenta distribuir los tensores en la memoria para maximizar la eficiencia del cálculo y minimizar el relleno. El proceso de distribución de la memoria es complejo; sin embargo, para obtener mejores resultados, el modelo debe obedecer la siguiente regla general. Para minimizar la sobrecarga de la memoria y maximizar la eficiencia del cálculo, una de las siguientes condiciones debe ser verdadera:
El tamaño total del lote debe ser un múltiplo de 64 (8 por núcleo de la TPU) y las dimensiones de las funciones deben ser un múltiplo de 128.
o
El tamaño total del lote debe ser un múltiplo de 1,024 (128 por núcleo de la TPU) y las dimensiones de las funciones deben ser un múltiplo de 8.
Se logra una mejor eficiencia con un tamaño de lote de 1,024 y dimensiones de las funciones que sean múltiplos de 128, aunque esto puede no ser posible para todos los modelos. A modo de aclaración, “dimensión de los atributos” se refiere al tamaño oculto de una capa completamente conectada o a la cantidad de canales de salida en una convolución. No todas las capas pueden cumplir con esta regla, especialmente la primera y la última capa de la red. Esto es correcto y se espera que la mayoría de los modelos requieran de cierta cantidad de relleno.
Reduce el uso de memoria
Si encuentras un error de memoria insuficiente cuando ejecutas tu 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 que se describen a continuación:
- Reducir el relleno excesivo del tensor
- Reducir el tamaño del lote
El tamaño del lote o del modelo es demasiado grande
Causa posible de problema de la memoria
Cuando entrenamos una red neuronal en una CPU, una GPU o una TPU, el uso de la memoria proviene de las siguientes dos fuentes:
- El uso de memoria es proporcional a la cantidad de pesos del modelo.
- El modelo almacena las activaciones intermedias de la propagación hacia adelante necesarias para calcular la retropropagación. El uso de la memoria es directamente proporcional al tamaño del lote, a los tamaños de las capas y a las cantidades de capas.
Por lo tanto, la memoria requerida por un modelo depende en gran medida del tamaño del lote.
La memoria que requiere un modelo depende de la cantidad de capas en la red.
El entorno de ejecución de la TPU intenta optimizar los operadores para ajustar el modelo a la memoria (lo que se llama rematerialización, similar al punto de control de las gradientes), pero no siempre puede hacerlo.
Reduce el uso de la memoria
Intenta reducir de a poco el tamaño del lote hasta que se ajuste a la memoria y 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 lotes más grandes son más eficaces en la TPU. Por lo general, un buen punto de partida es un tamaño total de lote de 1,024 (128 por núcleo).
Si no se puede ejecutar el modelo en la TPU incluso con un tamaño de lote pequeño (por ejemplo, 64), intenta reducir la cantidad de capas o sus tamaños.
Mejora la velocidad de entrenamiento
Si se puede ejecutar correctamente el modelo en la TPU, pero la velocidad de entrenamiento es inferior a la esperada, en esta sección se describen varios métodos que pueden mejorar la velocidad. Consulta la guía de rendimiento para obtener otras sugerencias sobre cómo mejorar el rendimiento del entrenamiento.
Muy pocos pasos por ejecución por bucle de entrenamiento
Descripción del problema de rendimiento
Pasar el argumento steps_per_execution a Model.compile controla cuántos pasos de entrenamiento se ejecutan entre las devoluciones de llamada del host.
Cada devolución de llamada del host requiere una comunicación significativa entre la CPU del host del servidor y el dispositivo TPU. Por eso, si steps_per_execution es demasiado pequeño, el entrenamiento puede ralentizarse.
Determina si tu modelo se ve afectado
Si un perfil de la TPU revela devoluciones de llamada frecuentes de la CPU del host entre los pasos del dispositivo, tu entrenamiento puede beneficiarse de un valor de steps_per_execution más grande.
Mitiga el problema
Establece steps_per_execution en un valor mayor. Ten en cuenta que steps_per_execution se puede establecer en un valor grande, pero recuerda que los mensajes de registro y el guardado de un punto de control solo pueden ocurrir después de que se haya ejecutado la cantidad especificada de pasos.
Cuello de botella del procesamiento de entrada
Descripción del problema de rendimiento
Mientras la TPU se entrena con un grupo específico de datos, la función de procesamiento de entrada prepara el siguiente grupo de datos en la CPU. Si tu función de entrada tarda más que la función del modelo, la TPU quedará inactiva mientras tu función de entrada recupera datos.
Determina si tu modelo se ve afectado
Sigue las instrucciones de las Herramientas de Cloud TPU, analizador de canalización de entrada para visualizar el análisis de canalización de entrada en TensorBoard:

La página del análisis de canalización de entrada muestra un resumen claro que indica si tu modelo presenta un cuello de botella en el nivel del procesamiento de entrada. La misma página también muestra el tiempo de ejecución por operación, que te permite identificar las operaciones problemáticas.
Mitiga el problema
Existen varias mitigaciones posibles cuando se cargan datos con la API de Dataset:
- Almacena tus datos como un conjunto de estructuras
tf.train.Exampleen archivosTFRecordy cárgalos conTFRecordDataset. Consulta el instructivo de la API de Dataset o el instructivo de ResNet para ver ejemplos. - Usa
dataset.cache()odataset.prefetch()para almacenar en búfer los datos de entrada. Esto evita que las demoras esporádicas en el acceso a archivos generen un cuello de botella. - Especifica el parámetro
num_parallel_callsde la funcióndataset.map()para habilitar operacionesmap()de subprocesos múltiples. Una heurística para el valor denum_parallel_callses usar la cantidad de núcleos de CPU disponibles. - Realiza el procesamiento previo de los datos costosos sin conexión como un costo único, en vez de que se aplique el costo en cada ciclo de cada entrenamiento.
Todo el procesamiento de entrada se hace en las CPU ubicadas en el servidor de la TPU, no en la máquina local; por lo que la velocidad de la máquina local no es un factor.
Tiempos de pasos lentos y uso bajo de MXU
Descripción del problema de rendimiento
Cloud TPU puede realizar convoluciones y multiplicaciones de matrices a velocidades increíblemente rápidas. La mayoría de las otras operaciones de TensorFlow tienen implementaciones eficientes en la TPU, pero no representan el valor principal de la TPU en comparación con otro hardware. En consecuencia, se debería dominar un modelo mediante las convoluciones o multiplicaciones de matrices para aprovechar la TPU al máximo.
Determina si tu modelo se ve afectado
En este caso, los síntomas que verás son tiempos de pasos lentos junto con un uso bajo de la MXU, que se muestra cuando generas un perfil del rendimiento.
Mitiga el problema
Intenta reducir la cantidad de operaciones que no son multiplicaciones de matrices. Después de reducir la cantidad de multiplicaciones de matrices, vuelve a hacer la comparativa para ver si el rendimiento es aceptable en las TPU.
Relleno excesivo del tensor
Descripción del problema de rendimiento
La TPU rellena los tensores en la memoria para poder usar sus unidades de procesamiento eficientemente. El relleno puede aumentar el uso de la memoria y del ancho de banda de la memoria. Consulta la sección sobre el relleno del tensor para comprender y solucionar los problemas de relleno del tensor.
Baja capacidad de procesamiento y bajo uso de memoria
Descripción del problema de rendimiento
Como regla general, el uso de tamaños de lote más grandes provoca una velocidad de entrenamiento mayor en la TPU, en términos de muestras por segundo.
Determina si tu modelo se ve afectado
El tamaño del lote de cualquier modelo siempre debe ser al menos de 64 (8 por núcleo de la TPU), ya que la TPU siempre rellena los tensores hasta este tamaño. El tamaño de lote ideal durante el entrenamiento en la TPU es de 1,024 (128 por núcleo de la TPU), ya que esto elimina las ineficiencias relacionadas con el relleno y la transferencia de la memoria.
Mitiga el problema
La práctica recomendada es usar el mayor tamaño de lote que se ajuste a la memoria y sea un múltiplo de 64. La manera más sencilla de lograrlo es comenzar con 1,024 y, si esto causa un error de memoria insuficiente, intenta reducir el tamaño del lote hasta que el modelo se ejecute correctamente. Cambiar el tamaño del lote de un modelo puede requerir el ajuste de otros hiperparámetros para lograr la misma exactitud del modelo, como la tasa de aprendizaje; pero esto se debe evaluar caso por caso.
Capas demasiado pequeñas
Descripción del problema de rendimiento
Incluso cuando un modelo está dominado por convoluciones o multiplicaciones de matrices, es posible que la TPU no se ejecute con la eficiencia máxima si los tensores de entrada son pequeños. En comparación con otro hardware, la TPU se ejecuta con mayor eficiencia cuando tanto los lotes como las capas son grandes (por ejemplo, de dimensión >= 512).
Determina si tu modelo se ve afectado
Como regla general, los tamaños de capa menores a 128 son poco eficientes en la TPU, ya que esa es la dimensión integrada en la unidad de multiplicación de matrices. En el caso de capas completamente conectadas, se recomienda un tamaño oculto mínimo de 512 para lograr una alta eficiencia. Ten en cuenta que las capas convolucionales en general no necesitan ser tan grandes como las capas completamente conectadas para lograr un nivel de eficiencia equivalente.
Mitiga el problema
Si el motivo principal de las capas pequeñas en tu modelo es la velocidad de entrenamiento, te recomendamos volver a evaluar tus modelos con capas más grandes en la TPU. Por ejemplo, es posible que el aumento del tamaño de salida de una capa de 256 a 512 solo incremente el tiempo de entrenamiento en un 20%, aunque el modelo tenga un rendimiento de procesamiento 2 veces mayor.
Perfilado del modelo en el nivel de las operaciones
Por lo general, es útil medir el tiempo de ejecución y el uso de memoria en el nivel de las operaciones para identificar los cuellos de botella del rendimiento. Si deseas obtener instrucciones para hacerlo,
consulta la guía Herramientas de Cloud TPU: Visualizador de Cloud Trace.
Depura las degradaciones en la exactitud del modelo
Uno de los objetivos del ecosistema de Cloud TPU es que cualquier modelo que esté en entrenamiento en una CPU o en una GPU obtenga una exactitud muy similar a la que se logra con el entrenamiento en la TPU, tal vez con menos ajustes a los hiperparámetros como el tamaño del lote y la tasa de aprendizaje. En ciertas ocasiones, sin embargo, los usuarios pueden notar una degradación en la precisión cuando entrenan modelos en la TPU. La depuración de estos problemas puede ser muy frustrante debido a la naturaleza aleatoria del entrenamiento de la red neuronal. En esta sección, se proporciona orientación sobre cómo identificar la causa raíz de cualquier degradación en la precisión del modelo cuando se porta un modelo a la TPU.
Comprende la fragmentación de datos (paralelismo de datos)
Uno de los objetivos principales de TensorFlow es que cada operación produzca resultados casi idénticos, ya sea que se ejecute en la CPU, la GPU o la TPU. Existen ciertas excepciones, como las operaciones aleatorias. En general, si encuentras una diferencia significativa entre el resultado de las operaciones no aleatorias en la TPU y en la CPU, infórmalo como un error.
Sin embargo, para la canalización de entrenamiento en conjunto, hay una diferencia significativa entre el entrenamiento en la CPU/GPU y en la TPU. Cuando se entrena en una TPU, TensorFlow hace una fragmentación de datos. Cada Cloud TPU contiene 8 núcleos que operan como unidades de procesamiento independientes. Para cada paso del entrenamiento, cada núcleo recibe un lote de datos, calcula los gradientes de peso, intercambia los gradientes con los otros núcleos y, luego, calcula la actualización del peso. Según la configuración predeterminada, la pérdida se promedia entre todos los núcleos. Pero se puede sumar, para lo cual hay que cambiar el parámetro de CrossShardOptimizer.
Si la pérdida total del modelo se puede calcular como el promedio (o el total) de las pérdidas independientes por muestra, este procedimiento equivale de manera matemática al entrenamiento en un lote grande único.
La operación más común que no es independiente por muestra es la normalización por lotes, que se ejecuta en cada lote por núcleo de forma individual. 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 hace la normalización por lotes de sus propias 16 muestras. En algunos casos, se descubrió que la normalización de lotes pequeños (por ejemplo, inferiores a 32) degrada la exactitud. En una situación ideal, el tamaño total del lote debería ser grande (por ejemplo, de 256 a 1,024). No obstante, si el tamaño del lote es demasiado grande para ajustarse a la memoria, se debe evaluar el efecto de la fragmentación caso por caso.
Depura el entrenamiento de la TPU de varios núcleos
Si tu modelo alcanza efectivamente la misma pérdida en la CPU y en la TPU de núcleo único, es probable que el problema sea uno de los siguientes:
(a) La degradación se debe a la variación aleatoria natural cuando se entrenan 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 (a) es el problema, vuelve a entrenar el modelo completo en la CPU/GPU y en la TPU de varios núcleos con la misma inicialización de peso.
Si estás seguro de que la degradación en la precisión tiene importancia estadística, los problemas más probables relacionados con la fragmentación de datos son los siguientes:
- Si tu modelo usa la normalización por lotes, un tamaño de lote total inferior a 256 (por ejemplo, inferior a 32 por núcleo) puede reducir la precisión.
- Las funciones de pérdida de 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 discriminante por lotes cuando se entrena una red generativa adversaria.
Soluciona problemas de los parámetros de configuración de gcloud
- Problema
gcloud components updatemuestra 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 Google Cloud CLI, debes usar una instalación que no se administre con un administrador de paquetes.
Ejecuta el siguiente comando para quitar la instalación actual de gcloud CLI:
sudo apt-get remove google-cloud-sdk
Sigue las instrucciones para instalar Google Cloud CLI.
- Problema
El comando
gcloud compute tpus tpu-vm ssh TPU_NAME --zone ZONEmuestra 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
Es posible que haya un problema con la propagación de la clave SSH. Intenta mover las claves generadas automáticamente a una ubicación de copia de seguridad para forzar a
gclouda volver a crearlas: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 Cloud TPU compatibles, JAX, PyTorch y TensorFlow, acceden a las TPU con una biblioteca compartida llamada libtpu que está presente en todas las VMs de la TPU. Esta biblioteca incluye el compilador XLA que se usa para compilar programas, el entorno de ejecución de la TPU que se usa para ejecutar los programas compilados y el controlador que permite el acceso de bajo nivel a la TPU.
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 Cloud TPU.
Las siguientes variables de entorno se pueden configurar antes de empezar el entrenamiento para modificar el comportamiento del registro:
- TPU_LOG_DIR: Es el directorio en el que se escriben los registros.
- La ubicación del directorio se establece de forma predeterminada en
/tmp/tpu_logs. El directorio se crea si aún no existe, pero no se crean directorios principales. Si se produce un error cuando se busca o se crea el directorio especificado, se imprimirá un mensaje en stderr, pero no se detendrá el programa y se inhabilitará el registro. Establece el nombre del directorio en "deshabilitado" para inhabilitar por completo el registro en el disco. - TPU_MIN_LOG_LEVEL: Es 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: Es la gravedad mínima que se registrará en stderr, además del disco, si corresponde.
- Las opciones son las mismas que TPU_MIN_LOG_LEVEL. El valor predeterminado es 3.
- TPU_MAX_LOG_SIZE_MB: Es 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. La configuración predeterminada es 1,024.