Risoluzione dei problemi di TensorFlow - TPU
Questa guida, insieme alle domande frequenti, fornisce assistenza per la risoluzione dei problemi agli utenti che addestrano modelli TensorFlow su Cloud TPU. Se stai risolvendo i problemi di addestramento di PyTorch o JAX, puoi consultare i documenti per la risoluzione dei problemi relativi a questi framework:
Per guide più generali su come utilizzare Cloud TPU, consulta:
Panoramica
I problemi comuni riscontrati con le Cloud TPU rientrano nelle seguenti categorie:
Problemi di connessione al server TPU
Questa sezione descrive come risolvere i problemi in cui TensorFlow smette di rispondere o stampa un errore durante la connessione alla TPU. Il passaggio di compilazione del grafico TPU può richiedere molto tempo per i modelli di grandi dimensioni, quindi lascia che lo script venga eseguito per almeno 5 minuti prima di concludere che ha smesso di rispondere.
Il primo passaggio consiste nel verificare se il problema riguarda il server stesso o la pipeline di addestramento TensorFlow. Per farlo, esegui il programma TensorFlow e verifica che funzioni correttamente. Se i problemi di connessione persistono, è confermato che si tratta di un problema con il server TPU. In questo caso:
Esegui il comando seguente per elencare le TPU disponibili. Sostituisci zone e project-id con la tua zona e il tuo ID progetto.
(vm)$ gcloud compute tpus tpu-vm list --zone zone --project project-id
Viene stampato un output simile al seguente:
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 che questa TPU sia elencata come
READY.Se la tua TPU non è elencata come
READYo se continui ad avere problemi di connessione, riavvia manualmente il server con:(vm)$ gcloud compute tpus tpu-vm stop TPU_NAME && gcloud compute tpus tpu-vm start TPU_NAME
L'operazione potrebbe richiedere diversi minuti.
Esegui di nuovo il comando
gcloud compute tpus tpu-vm liste attendi che la TPU sia nello statoREADY. L'operazione potrebbe richiedere alcuni minuti.Prova a eseguire di nuovo il programma.
Se i problemi persistono, chiedi aiuto utilizzando uno dei meccanismi descritti in Richiedere assistenza.
Se il codice viene eseguito correttamente, ma il modello smette di rispondere,
il problema riguarda probabilmente la pipeline di addestramento.
Per eseguire il debug, inizia sostituendo TPUStrategy nel codice con la strategia predefinita. Quando utilizzi la strategia predefinita, ovunque utilizzi
strategy.scope() o strategy.run(), il modello viene eseguito
sulla CPU (o sulla GPU, se presente) anziché
sulla TPU. Se il modello viene eseguito sulla CPU e non sulla TPU, deve esserci un
problema specifico della TPU. Se ancora non funziona, la best practice è eseguire il debug
del problema sulla CPU.
Perdita della connessione ssh durante l'allenamento
La connessione ssh a Cloud TPU potrebbe scadere durante
un addestramento di lunga durata (in particolare se utilizzi Cloud Shell).
A questo punto, non viene generato alcun output nella console TPU e potrebbe
sembrare che l'addestramento della TPU sia stato interrotto. Per evitare questo problema, esegui la sessione di addestramento con un multiplexer terminale o uno strumento di gestione delle sessioni come tmux o screen. In questo modo, la connessione ssh
rimarrà attiva indipendentemente dalla durata dell'allenamento.
Eseguire il debug degli errori comuni
Questa sezione descrive come risolvere i problemi relativi agli errori comuni che potresti riscontrare durante l'addestramento dei modelli su Cloud TPU.
Impossibile creare una TPU
Quando crei una Cloud TPU, potresti visualizzare il seguente errore:
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."
Si tratta di un problema di autorizzazioni che può essere risolto eseguendo il seguente comando:
gcloud auth login --update-adc
Questo comando aggiorna le Credenziali predefinite dell'applicazione (ADC) e dovrebbe risolvere il problema. Per saperne di più, consulta gcloud auth login.
Forme dinamiche non supportate
Messaggio di errore
ValueError: shape [Shape] must have a fixed size for dimension d that is known at graph construction time.
Framework e configurazioni interessati
Questo messaggio viene visualizzato solo durante la compilazione XLA con TensorFlow.
Dettagli
Per eseguire un modello sulla TPU, Cloud TPU lo compila utilizzando il compilatore XLA. Sebbene questo passaggio di compilazione migliori significativamente la velocità di addestramento e l'utilizzo della memoria, le forme (dimensioni) di tutti i tensori nel grafico devono essere note al momento della compilazione del grafico. Se non è possibile determinare alcuna forma in fase di compilazione, la compilazione della TPU non riesce e viene visualizzato un errore simile a quello mostrato in precedenza.
Un'operazione comune che restituisce una forma dinamica è dataset.batch(batch_size), poiché il numero di campioni rimanenti in un flusso potrebbe essere inferiore alla dimensione del batch. Pertanto, quando esegui l'addestramento sulla TPU, imposta
drop remainder=True per dataset.batch.
In questo modo, vengono potenzialmente eliminati gli ultimi campioni di un file per garantire
che ogni batch abbia una forma statica di batch_size. Ad esempio:
dataset = tf.data.Dataset.range(8)
dataset = dataset.batch(3, drop_remainder=True)
Operazione TensorFlow non disponibile
Messaggio di errore
NotFoundError: No registered 'OpName' OpKernel for XLA_TPU_JIT devices compatible with node
Framework e configurazioni interessati
Questo messaggio può essere visualizzato durante l'addestramento con TensorFlow.
Dettagli
Il modello utilizza un'operazione TensorFlow non disponibile sulla TPU.
Per un elenco delle operazioni disponibili sulla TPU, insieme ai piani per il supporto futuro e suggerimenti per soluzioni alternative, consulta la guida alle operazioni TensorFlow disponibili.
Messaggio di errore di esaurimento della memoria
Messaggio di errore
ResourceExhaustedError: Ran out of memory in memory space hbm; used: YYY; limit: 7.48G.
Framework e configurazioni interessati
Questo messaggio può essere visualizzato durante l'addestramento con TensorFlow, PyTorch o JAX.
Dettagli
Ogni Cloud TPU è composta da otto core TPU. Le TPU v2 hanno 8 GB e le TPU v3 hanno 16 GB di RAM (o HBM, memoria a larghezza di banda elevata). Questa memoria viene utilizzata per archiviare i tensori di peso (variabili), nonché i tensori dei risultati intermedi necessari per il calcolo del gradiente. Se il modello è troppo grande per essere contenuto nella RAM della TPU, l'inizializzazione non va a buon fine e viene stampato il messaggio di errore. Per ulteriore assistenza, consulta la sezione sulla riduzione dell'utilizzo della memoria.
Suggerimenti per ridurre l'utilizzo della memoria:
- Controllare l'eccessivo padding dei tensori
- Utilizza il formato bfloat16
- Se le dimensioni dell'input o del modello sono troppo grandi, potresti utilizzare il parallelismo sperimentale del modello di TensorFlow per risolvere il problema delle dimensioni del modello.
Problemi durante l'interruzione dell'esecuzione
Se TensorFlow rileva un errore durante l'esecuzione della TPU, a volte lo script
sembra smettere di rispondere anziché uscire dalla shell. Se si verifica questo problema,
premi CTRL+C sulla tastiera per attivare un SIGQUIT, che fa sì che
Python esca immediatamente.
Allo stesso modo, la pressione di CTRL+C durante l'esecuzione della TPU non arresta immediatamente TensorFlow, ma attende la fine del ciclo di iterazione corrente per uscire in modo pulito.
Se si verificano nuovi errori durante la riconnessione alla TPU dopo l'uscita in questo modo, reimposta manualmente il server TPU con i comandi:
gcloud compute tpus tpu-vm stop tpu-name --zone=zone gcloud compute tpus tpu-vm start tpu-name --zone=zone
dove tpu-name è tratto dalla prima colonna visualizzata dal comando gcloud compute tpus tpu-vm list e zone è la zona mostrata nella seconda colonna.
Padding eccessivo dei tensori
Possibile causa del problema di memoria
I tensori nella memoria TPU vengono riempiti, ovvero la TPU arrotonda le dimensioni dei tensori archiviati in memoria per eseguire i calcoli in modo più efficiente. Questo riempimento avviene in modo trasparente a livello di hardware e non influisce sui risultati. Tuttavia, in alcuni casi il padding può comportare un aumento significativo dell'utilizzo della memoria e del tempo di esecuzione.
Come ridurre l'utilizzo della memoria
Il software TPU tenta di disporre i tensori in memoria per massimizzare l'efficienza di calcolo e ridurre al minimo il padding. Questo processo di layout della memoria è complesso, tuttavia, per ottenere i risultati migliori, il modello deve rispettare la seguente regola generale. Per ridurre al minimo l'overhead della memoria e massimizzare l'efficienza di calcolo, deve essere soddisfatta una delle seguenti condizioni:
La dimensione totale del batch deve essere un multiplo di 64 (8 per core TPU) e le dimensioni delle funzionalità devono essere un multiplo di 128.
o
La dimensione totale del batch deve essere un multiplo di 1024 (128 per core TPU) e le dimensioni delle funzionalità devono essere un multiplo di 8.
L'utilizzo di una dimensione batch di 1024 e di dimensioni delle funzionalità che siano un multiplo di 128 consente di ottenere la massima efficienza, anche se ciò potrebbe non essere possibile per tutti i modelli. Per chiarezza, "dimensione della funzionalità" si riferisce alla dimensione nascosta di un livello completamente connesso o al numero di canali di output in una convoluzione. Non tutti i livelli possono essere conformi a questa regola, in particolare il primo e l'ultimo livello della rete. Questo non rappresenta un problema ed è previsto che la maggior parte dei modelli richieda un po' di padding.
Riduzione dell'utilizzo della memoria
Se si verifica un errore di esaurimento della memoria durante l'esecuzione del modello sulla TPU, devi adottare misure per ridurre l'utilizzo della memoria del modello.
I modi più efficaci per ridurre l'utilizzo della memoria sono:
- Ridurre il padding eccessivo dei tensori
- Riduci le dimensioni del batch
Dimensioni del batch o del modello troppo grandi
Possibile causa del problema di memoria
Quando si addestra una rete neurale su una CPU, una GPU o una TPU, l'utilizzo della memoria deriva da due posizioni:
- L'utilizzo della memoria è proporzionale al numero di pesi nel modello.
- Memorizzazione delle attivazioni intermedie del progresso in avanti necessarie per calcolare il progresso all'indietro. L'utilizzo della memoria è direttamente proporzionale alla dimensione del batch, alle dimensioni dei livelli e al numero di livelli.
Pertanto, la memoria richiesta da un modello dipende in gran parte dalle dimensioni del batch.
La memoria richiesta da un modello dipende dal numero di livelli della rete.
Il runtime TPU tenta di ottimizzare gli operatori per adattare il modello alla memoria (operazione chiamata rematerializzazione, simile al checkpointing del gradiente), ma non sempre riesce a farlo.
Come ridurre l'utilizzo della memoria
Riduci lentamente le dimensioni del batch fino a quando non rientrano nella memoria, assicurandoti che le dimensioni totali del batch siano un multiplo di 64 (le dimensioni del batch per core devono essere un multiplo di 8). Tieni presente che dimensioni dei batch più grandi sono più efficienti sulla TPU. Una dimensione totale del batch di 1024 (128 per core) è in genere un buon punto di partenza.
Se il modello non può essere eseguito sulla TPU anche con una dimensione batch ridotta (ad esempio 64), prova a ridurre il numero di livelli o le dimensioni dei livelli.
Migliorare la velocità di addestramento
Se il modello è in grado di essere eseguito correttamente sulla TPU, ma la velocità di addestramento è inferiore al previsto, questa sezione descrive diversi modi potenziali per migliorare la velocità. Consulta la guida al rendimento per altri suggerimenti su come migliorare il rendimento dell'addestramento.
Numero insufficiente di passaggi per esecuzione per ciclo di addestramento
Descrizione del problema di rendimento
Il passaggio dell'argomento steps_per_execution a Model.compile controlla
il numero di passaggi di addestramento eseguiti tra i callback host.
Ogni callback host richiede una comunicazione significativa
tra la CPU host del server TPU e il dispositivo TPU, quindi se steps_per_execution
è troppo piccolo, può rallentare l'addestramento.
Come sapere se il tuo modello è interessato
Se un profilo TPU rivela frequenti callback della CPU host tra i passaggi del dispositivo TPU,
l'addestramento può trarre vantaggio da un valore steps_per_execution più elevato.
Come mitigare
Imposta un valore di steps_per_execution maggiore. Tieni presente che
steps_per_execution può essere impostato su un valore elevato, ma ricorda
che la registrazione dei messaggi e il salvataggio di un checkpoint possono avvenire solo dopo
l'esecuzione del numero specificato di passaggi.
Collo di bottiglia dell'elaborazione dell'input
Descrizione del problema di rendimento
Mentre la TPU esegue l'addestramento su un particolare blocco di dati, la funzione di elaborazione dell'input prepara il blocco di dati successivo sulla CPU. Se la funzione di input richiede più tempo rispetto alla funzione del modello, la TPU rimane inattiva mentre la funzione di input recupera i dati.
Come sapere se il tuo modello è interessato
Segui le istruzioni riportate in Cloud TPU Tools: Input Pipeline Analyzer per visualizzare l'analisi della pipeline di input in TensorBoard:

La pagina di analisi della pipeline di input mostra un riepilogo chiaro che indica se il modello è limitato dall'elaborazione dell'input. La stessa pagina mostra anche il tempo di esecuzione per operazione, il che ti consente di individuare le operazioni problematiche.
Come mitigare
Esistono diverse possibili mitigazioni durante il caricamento dei dati con l'API Dataset:
- Archivia i dati come raccolta di strutture
tf.train.Examplein fileTFRecorde caricali conTFRecordDataset. Per esempi, consulta il tutorial sull'API Dataset o il tutorial su ResNet. - Utilizza
dataset.cache()odataset.prefetch()per memorizzare nel buffer i dati di input. In questo modo, i rallentamenti sporadici nell'accesso ai file non creano un collo di bottiglia. - Specifica il parametro
num_parallel_callsdella funzionedataset.map()per attivare le operazionimap()multithread. Un'euristica per il valore dinum_parallel_callsconsiste nell'utilizzare il numero di core della CPU disponibili. - Esegui la pre-elaborazione dei dati offline come costo una tantum, anziché sostenere il costo per ogni epoca di ogni addestramento.
Tutta l'elaborazione dell'input viene eseguita sulle CPU che si trovano sul server TPU, non sulla macchina locale, quindi la velocità della macchina locale non è un fattore.
Tempi di esecuzione lenti e basso utilizzo di MXU
Descrizione del problema di rendimento
La Cloud TPU può eseguire moltiplicazioni e convoluzioni di matrici a velocità incredibilmente elevate. La maggior parte delle altre operazioni TensorFlow dispone di implementazioni efficienti sulla TPU, ma queste non sono il punto di forza principale della TPU rispetto ad altri hardware. Pertanto, un modello deve essere dominato da moltiplicazioni di matrici o convoluzioni per sfruttare appieno la TPU.
Come sapere se il tuo modello è interessato
I sintomi che vedrai in questo caso sono tempi di esecuzione lenti uniti a un basso utilizzo dell'MXU mostrato quando profila le prestazioni.
Come mitigare
Prova a ridurre il numero di operazioni che non sono moltiplicazioni di matrici. Dopo aver ridotto il numero di moltiplicazioni di matrici, esegui nuovamente il benchmark per verificare se le prestazioni sono accettabili sulle TPU.
Padding eccessivo dei tensori
Descrizione del problema di rendimento
La TPU esegue il padding dei tensori in memoria in modo che possa utilizzare le sue unità di calcolo in modo efficiente. Il padding può aumentare l'utilizzo sia della memoria che della larghezza di banda della memoria. Per assistenza nella comprensione e nella risoluzione dei problemi di padding dei tensori, consulta la sezione relativa al padding dei tensori.
Throughput lento e utilizzo di memoria ridotto
Descrizione del problema di rendimento
Come regola generale, l'utilizzo di dimensioni del batch maggiori comporta una maggiore velocità di addestramento sulla TPU, in termini di campioni al secondo.
Come sapere se il tuo modello è interessato
La dimensione del batch di qualsiasi modello deve essere sempre almeno 64 (8 per core TPU), poiché la TPU esegue sempre il padding dei tensori fino a questa dimensione. La dimensione batch ideale per l'addestramento sulla TPU è 1024 (128 per core TPU), poiché in questo modo si eliminano le inefficienze relative al trasferimento e al padding della memoria.
Come mitigare
La best practice è utilizzare la dimensione del batch più grande che rientri nella memoria e che sia un multiplo di 64. Il modo più semplice per farlo è iniziare con 1024 e, se si verifica un errore di memoria insufficiente, prova a ridurre le dimensioni del batch finché il modello non viene eseguito correttamente. La modifica della dimensione del batch di un modello potrebbe richiedere la regolazione di altri iperparametri per ottenere la stessa precisione del modello, ad esempio il tasso di apprendimento, ma ciò deve essere valutato caso per caso.
Dimensioni dei livelli troppo piccole
Descrizione del problema di rendimento
Anche quando un modello è dominato da moltiplicazioni di matrici o convoluzioni, la TPU potrebbe non funzionare alla massima efficienza se i tensori di input sono piccoli. Rispetto ad altri hardware, la TPU funziona in modo più efficiente quando sia la dimensione del batch sia le dimensioni dei livelli sono grandi (ad esempio, dimensione >= 512).
Come sapere se il tuo modello è interessato
Come regola generale, le dimensioni dei livelli inferiori a 128 non garantiscono una buona efficienza sulla TPU, poiché 128 è la dimensione integrata dell'unità di moltiplicazione della matrice della TPU. Per i livelli completamente connessi, si consiglia una dimensione nascosta minima di 512 per ottenere un'elevata efficienza. Tieni presente che i livelli convoluzionali in genere non devono essere grandi quanto i livelli completamente connessi per raggiungere un livello di efficienza uguale.
Come mitigare
Se la motivazione principale per le dimensioni ridotte dei livelli nel tuo modello è la velocità di addestramento, esegui nuovamente il benchmark dei tuoi modelli con livelli più grandi sulla TPU. Ad esempio, l'aumento della dimensione dell'output di un livello da 256 a 512 può aumentare il tempo di addestramento solo del 20%, anche se il modello esegue il doppio dei calcoli.
Profilazione del modello a livello di operazione
Spesso è utile misurare il tempo di esecuzione e l'utilizzo della memoria a livello di operazione per identificare i colli di bottiglia delle prestazioni. Per istruzioni su come eseguire questa operazione,
consulta la guida Strumenti Cloud TPU: Trace Viewer.
Eseguire il debug dei cali di accuratezza del modello
Uno degli obiettivi dell'ecosistema Cloud TPU è che qualsiasi modello addestrato su una CPU o una GPU raggiunga una precisione molto simile quando viene addestrato sulla TPU, con modifiche minime agli iperparametri come la dimensione del batch e il tasso di apprendimento. Occasionalmente, tuttavia, gli utenti possono notare un peggioramento dell'accuratezza durante l'addestramento dei modelli sulla TPU. Il debug di questi problemi può essere estremamente frustrante a causa della natura casuale dell'addestramento della rete neurale. Questa sezione fornisce indicazioni su come individuare la causa principale di eventuali cali di accuratezza del modello durante il porting di un modello sulla TPU.
Informazioni sullo sharding dei dati (parallelismo dei dati)
Uno degli obiettivi principali di TensorFlow è che ogni operazione produca risultati quasi identici, indipendentemente dal fatto che venga eseguita su CPU, GPU o TPU. Esistono alcune eccezioni, come le operazioni casuali. In generale, se riscontri differenze significative tra l'output di operazioni non casuali sulla TPU e sulla CPU, segnalalo come bug.
Tuttavia, per la pipeline di addestramento nel suo complesso, esiste una differenza significativa tra l'addestramento su CPU/GPU e TPU. Durante l'addestramento su una TPU,
TensorFlow esegue lo sharding dei dati.
Ogni Cloud TPU contiene 8 core TPU che funzionano come unità di elaborazione indipendenti. Per ogni passaggio dell'addestramento, ogni core TPU riceve un batch
di dati, calcola i gradienti del peso, li scambia con gli
altri core TPU
e poi calcola l'aggiornamento del peso. Per impostazione predefinita, la perdita viene calcolata in media tra i core, ma può essere sommata modificando il parametro di CrossShardOptimizer.
Se la perdita totale del modello può essere calcolata come la media (o la somma) delle perdite indipendenti per campione, questa procedura è matematicamente equivalente all'addestramento su un singolo batch di grandi dimensioni.
L'operazione più comune che non è indipendente per campione è la normalizzazione batch, che viene eseguita separatamente per ogni batch per core. Ad esempio, se la dimensione totale del batch è 128, la dimensione del batch per core è 16 e ciascuno degli 8 core esegue la normalizzazione batch sui propri 16 campioni. In alcuni casi, è stato riscontrato che l'esecuzione della normalizzazione batch su batch di piccole dimensioni (ad esempio, meno di 32) riduce l'accuratezza. Nello scenario ideale, la dimensione totale del batch dovrebbe essere elevata (ad esempio, da 256 a 1024). Se una dimensione del batch è troppo grande per essere contenuta nella memoria, l'effetto dello sharding deve essere valutato caso per caso.
Debug dell'addestramento TPU multicore
Se il tuo modello raggiunge la stessa perdita sulla CPU e sulla TPU single-core, allora il problema è probabilmente uno dei seguenti:
(a) Il degrado è dovuto alla varianza casuale naturale durante l'addestramento di modelli neurali con inizializzazioni diverse.
(b) Il degrado è dovuto a un problema relativo allo sharding dei dati sulla TPU.
Per determinare se il problema è (a), riaddestra l'intero modello su CPU/GPU e TPU multi-core utilizzando la stessa inizializzazione dei pesi.
Se ritieni che il calo di accuratezza sia statisticamente significativo, i problemi più probabili relativi allo sharding dei dati sono:
- Se il modello utilizza la normalizzazione batch, una dimensione batch totale inferiore a 256 (ad esempio, meno di 32 per core) potrebbe ridurre l'accuratezza.
- Le funzioni di perdita batch-wise sono interessate dallo sharding. Queste funzioni di perdita sono in genere piuttosto specializzate. Ad esempio, Karras et al. 2017 utilizza un discriminatore batch durante l'addestramento di una rete GAN (Generative Adversarial Network).
Risoluzione dei problemi di configurazione di gcloud
- Problema
gcloud components updatemostra il seguente messaggio di errore:
ERROR: (gcloud.components.update) You cannot perform this action because the Cloud SDK component manager is disabled for this installation.
- Soluzione
Per utilizzare Google Cloud CLI, devi utilizzare un'installazione non gestita tramite un gestore di pacchetti.
Esegui questo comando per rimuovere l'installazione attuale di gcloud CLI:
sudo apt-get remove google-cloud-sdk
Segui le istruzioni per installare Google Cloud CLI.
- Problema
Il comando
gcloud compute tpus tpu-vm ssh TPU_NAME --zone ZONEvisualizza il seguente messaggio di errore: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.
- Soluzione
Potrebbe essersi verificato un problema con la propagazione della chiave SSH. Prova a spostare le chiavi generate automaticamente in una posizione di backup per forzare la ricreazione da parte di
gcloud:mv ~/.ssh/google_compute_engine ~/.ssh/old-google_compute_engine mv ~/.ssh/google_compute_engine.pub ~/.ssh/old-google_compute_engine.pub
Log di debug
I framework Cloud TPU supportati, JAX, PyTorch e TensorFlow, accedono alle TPU utilizzando una libreria condivisa chiamata libtpu presente su ogni VM TPU. Questa libreria include il compilatore XLA utilizzato per compilare i programmi TPU, il runtime TPU utilizzato per eseguire i programmi compilati e il driver TPU utilizzato dal runtime per l'accesso di basso livello alla TPU.
La libreria libtpu registra informazioni che possono essere utili per il debug.
Per impostazione predefinita, questi log vengono scritti in /tmp/tpu_logs su ogni VM Cloud TPU.
Prima di iniziare l'addestramento, puoi impostare le seguenti variabili di ambiente
per modificare il comportamento di logging:
- TPU_LOG_DIR: la directory in cui vengono scritti i log
- La posizione della directory è impostata su
/tmp/tpu_logsper impostazione predefinita. La directory viene creata se non esiste già, ma non vengono create directory principali. Se si verifica un errore durante la ricerca o la creazione della directory specificata, viene stampato un messaggio in stderr, ma il programma non si arresta e la registrazione è disattivata. Imposta il nome della directory su "disabled" per disattivare completamente la registrazione su disco. - TPU_MIN_LOG_LEVEL: la gravità minima che verrà registrata su disco
- Le scelte sono 0 (INFO), 1 (WARNING), 2 (ERROR) e 3 (FATAL). Il valore predefinito è 0.
- TPU_STDERR_LOG_LEVEL: la gravità minima che verrà registrata in stderr, oltre al disco, se applicabile
- Le scelte sono le stesse di TPU_MIN_LOG_LEVEL. Il valore predefinito è 3.
- TPU_MAX_LOG_SIZE_MB: la dimensione massima in megabyte di ogni file di log
- Un nuovo file di log verrà avviato automaticamente quando il precedente raggiungerà circa queste dimensioni. Il valore predefinito è 1024.