Risoluzione dei problemi di TensorFlow - TPU
Questa guida, insieme alle Domande frequenti, fornisce assistenza per la risoluzione dei problemi agli utenti che si occupano di formazione Modelli TensorFlow su Cloud TPU. Se stai risolvendo i problemi il corso di formazione PyTorch o JAX, consulta i documenti per la questi framework:
Per guide più generali sull'utilizzo di Cloud TPU, vedi:
- Le guide rapide per Cloud TPU
- Tutorial MNIST
- Addestramento di modelli ML su TPU (Cloud Tensor Processing Unit)
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 situazioni in cui TensorFlow smette di rispondere o visualizza un errore connessione alla TPU. Il passaggio di compilazione del grafico TPU può richiedere molto tempo di grandi dimensioni, quindi lascia che lo script venga eseguito per almeno 5 minuti prima di concludere non risponde più.
Il primo passaggio consiste nel verificare se il problema riguarda il server stesso o della pipeline di addestramento TensorFlow. A questo scopo, esegui Tutorial MNIST utilizzando l'URL del server TPU e verifica che funzioni correttamente. Se ci sono ancora di connessione con il tutorial MNIST, questo conferma che si tratta di un problema con il server TPU. In questo caso:
Esegui questo comando per elencare le TPU disponibili. Sostituzione di zone in corso... e project-id con l'ID della tua zona e del tuo progetto.
(vm)$ gcloud compute tpus list --zone zone --project project-id
Verrà stampato un output come:
NAME ZONE ACCELERATOR_TYPE NETWORK_ENDPOINT NETWORK RANGE STATUS demo-tpu us-central1-b v2-8 10.240.1.2:8470 default 10.240.1.0 READY
Verifica di trasferire il valore corretto a
--tpu
(demo-tpu
in nell'esempio precedente) e che questa TPU sia elencata comeREADY
.Se la tua TPU non è elencata come
READY
o se i problemi persistono connessione, riavvia manualmente il server con:(vm)$ gcloud compute tpus stop $TPU_SERVER_NAME && gcloud compute tpus start $TPU_SERVER_NAME
Nell'esempio precedente,
$TPU_SERVER_NAME
èdemo-tpu
. L'operazione potrebbe richiedere diversi minuti.Esegui di nuovo il comando
... tpus list
e attendi che la TPU si trovi in StatoREADY
. L'operazione potrebbe richiedere alcuni minuti.Prova a eseguire di nuovo il tutorial MNIST.
Se continui ad avere problemi con l'esecuzione del tutorial MNIST, chiedi aiuto usando uno dei meccanismi descritti in Assistenza.
Se l'esempio MNIST funziona correttamente, ma il modello continua a rispondere,
probabilmente il problema riguarda la pipeline di addestramento.
Per eseguire il debug, inizia sostituendo la TPUStrategy nel codice con il
strategia predefinita. Quando utilizzi la strategia predefinita, ovunque ti trovi
strategy.scope()
o strategy.run()
, il modello viene eseguito
su CPU (o GPU se presente)
sulla TPU. Se il modello viene eseguito sulla CPU e non sulla TPU, deve essere presente
Problema specifico di TPU. Se non viene ancora eseguita, la best practice è eseguire il debug
il problema sulla CPU.
Perdita della connessione a ssh
durante l'addestramento
La connessione di ssh
alla Cloud TPU potrebbe scadere durante
per un addestramento a lunga esecuzione (soprattutto se utilizzi Cloud Shell).
A quel punto, non c'è alcun output nella console TPU
sembra che la TPU abbia interrotto l'addestramento. Per evitare che ciò accada, esegui il comando
sessione di formazione con un multiplexer di terminali o uno strumento di gestione delle sessioni come
come tmux
o screen
. Questa operazione manterrà ssh
attiva a prescindere dalla durata dell'addestramento.
Debug di errori comuni
Questa sezione descrive come risolvere gli errori più comuni che potresti 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 relativo alle autorizzazioni e può essere risolto eseguendo questo comando:
gcloud auth login --update-adc
Questo comando aggiorna le tue credenziali predefinite dell'applicazione (ADC) e dovrebbe risolvere risolvere il problema. Per ulteriori informazioni, 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 compila il modello utilizzando il compilatore XL. Mentre questa fase di compilazione migliora significativamente la velocità di addestramento e la memoria utilizzata, le forme (dimensioni delle dimensioni) di tutti i tensori del grafico al momento della compilazione del grafico. Se non è possibile determinare alcuna forma al momento della compilazione, la compilazione delle TPU non riesce con un errore come 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 a
la dimensione del batch. Pertanto, quando esegui l'addestramento sulla TPU,
drop remainder=True
per dataset.batch
.
Questa operazione potrebbe eliminare gli ultimi campioni da 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, oltre ai piani per il supporto futuro e suggerimenti per soluzioni alternative, consulta la guida per TensorFlow Ops disponibili.
Messaggio di errore di esaurimento 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 è composto da otto core TPU, mentre 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 memorizzare il peso tensori (variabili), così come tensori di risultato intermedi necessari per il gradiente calcolo. Se il modello è troppo grande per essere inserito nella RAM TPU, l'inizializzazione non riesce e il messaggio di errore viene stampato. Consulta la sezione sulla riduzione memoria utilizzata per ulteriore assistenza.
Suggerimenti per ridurre l'utilizzo della memoria:
- Verifica l'eventuale presenza di un tensore di spaziature interne eccessiva
- Utilizza il formato bfloat16
- Se le dimensioni o il modello di input sono troppo grandi, potresti riuscire a utilizzare Parallelismo del modello sperimentale di TensorFlow per gestire le dimensioni del modello.
Problemi di interruzione dell'esecuzione
Se TensorFlow rileva un errore durante l'esecuzione della TPU, lo script
a volte sembra smettere di rispondere invece di uscire dalla shell. In questo caso,
premi CTRL+C
sulla tastiera per attivare SIGQUIT
, il che fa sì
Python per uscire immediatamente.
Allo stesso modo, la pressione di CTRL+C
durante l'esecuzione della TPU non arresta TensorFlow
immediatamente, ma attende fino alla fine del loop di iterazione corrente
uscire in modo pulito.
Se si verificano nuovi errori quando ti riconnetti a dopo aver chiuso la TPU in questo modo, reimposta manualmente il server TPU con i comandi:
gcloud compute tpus stop tpu-name --zone=zone gcloud compute tpus start tpu-name --zone=zone
dove tpu-name viene ricavato dalla prima colonna visualizzata dallo
gcloud compute tpus list
e zone è la zona mostrata
la seconda colonna.
Eccessiva spaziatura interna del tensore
Possibile causa di problemi di memoria
I tensori della memoria TPU sono riempiti, ovvero la TPU arrotonda le dimensioni dei tensori archiviati in memoria per eseguire i calcoli in modo più efficiente. Questa spaziatura interna avviene in modo trasparente livello di hardware e non influisce sui risultati. Tuttavia, in alcuni casi la spaziatura interna può comportare un aumento significativo dell'utilizzo della memoria e dei tempi di esecuzione.
Come ridurre la memoria utilizzata
Il software TPU tenta di disporre i tensori in memoria per massimizzare l'efficienza computazionale e ridurre al minimo la spaziatura interna. Questo processo di layout della memoria è complessa, ma per ottenere i migliori risultati il modello deve rispettare la seguente regola empirica. Per ridurre al minimo l'overhead di memoria e massimizzare l'efficienza di calcolo, deve essere vera una delle seguenti condizioni:
La dimensione totale del batch deve essere un multiplo di 64 (8 per core TPU) e le dimensioni delle caratteristiche 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 caratteristiche devono essere un multiplo di 8.
Utilizzando una dimensione del batch di 1024 e dimensioni delle caratteristiche che sono un multiplo di 128 garantisce l'efficienza migliore, sebbene ciò potrebbe non essere possibile per tutte di machine learning. Per chiarezza, "dimensione della caratteristica" indica la dimensione nascosta di un o il numero di canali di output in una convoluzione. Non tutte possono essere conformi a questa regola, in particolare il primo e l'ultimo strato. della rete. Questo non è un problema e si prevede che la maggior parte dei modelli richieda una quantità di spaziatura interna.
Riduzione della memoria utilizzata
Se si verifica un errore di memoria insufficiente durante l'esecuzione del modello sulla TPU, è necessario adottare delle misure per ridurre la memoria utilizzata dal modello.
I modi più efficaci per ridurre la memoria utilizzata sono:
- Riduci l'eccessiva spaziatura interna del tensore
- Riduci le dimensioni del batch
Dimensione del batch o modello troppo grande
Possibile causa di problemi di memoria
Quando addestra una rete neurale su CPU, GPU o TPU, l'utilizzo della memoria proviene in due posizioni:
- L'utilizzo della memoria è proporzionale al numero di i pesi nel modello.
- Memorizzazione di attivazioni intermedie dal progresso in avanti necessario calcolare il passaggio a ritroso. L'utilizzo della memoria è diretto proporzionale alla dimensione del batch, alle dimensioni dei livelli e al numero di strati.
Di conseguenza, la memoria richiesta da un modello dipende molto dal modello dimensioni.
La memoria richiesta da un modello dipende dal numero di strati in in rete.
Il runtime TPU tenta di ottimizzare gli operatori il modello in memoria (denominato rimaterializzazione, simile a gradiente checkpoint), ma non sempre è possibile.
Come ridurre la memoria utilizzata
Riduci lentamente la dimensione del batch fino a quando non rientra in memoria, assicurandoti che la dimensione totale del batch è un multiplo di 64 (la dimensione del batch per core dovrebbe multiplo di 8). Tieni presente che le dimensioni dei batch più grandi sono più efficienti sul o TPU. Una dimensione totale del batch di 1024 (128 per core) è generalmente un buon inizio punto di accesso.
Se il modello non può essere eseguito sulla TPU anche con un piccolo batch (ad es. 64), prova a ridurre il numero o le dimensioni dei livelli.
Migliorare la velocità di addestramento
Se il modello può essere eseguito correttamente sulla TPU, ma la velocità di addestramento meno del previsto, questa sezione illustra diversi potenziali modi per migliorare la velocità. Consulta la Guida al rendimento per altri suggerimenti su come migliorare le prestazioni della formazione.
Numero insufficiente di passaggi per esecuzione per loop di addestramento
Descrizione del problema di rendimento
Passaggio dell'argomento steps_per_execution
ai controlli Model.compile
il numero di passaggi di addestramento eseguiti tra i callback dell'host.
Ogni callback di 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 capire se il tuo modello è interessato
Se un profilo TPU rivela frequenti callback della CPU host tra i passaggi del dispositivo TPU,
il tuo addestramento potrà trarre vantaggio da un valore steps_per_execution
più ampio.
Come attenuare
Imposta un valore maggiore per steps_per_execution
. Tieni presente che
Il valore di steps_per_execution
può essere impostato su un valore elevato, ma tieni presente che
il logging dei messaggi e il salvataggio di un checkpoint possono avvenire solo dopo
di passaggi sono stati eseguiti.
Collo di bottiglia dell'elaborazione degli input
Descrizione del problema di rendimento
Durante l'addestramento della TPU su un particolare blocco di dati, l'elaborazione di input prepara il blocco successivo di dati sulla CPU. Se il tuo input richiede più tempo della funzione di modello, la TPU è lasciata inattiva mentre la funzione di input recupera i dati.
Come capire se il tuo modello è interessato
Segui le istruzioni in Cloud TPU Tools: Input Pipeline (Strumenti Cloud TPU: pipeline di input) Strumento di analisi per visualizzare analisi della pipeline di input in TensorBoard:
La pagina Analisi della pipeline di input mostra un chiaro riepilogo che mostra se il modello è sottoposto a colli di bottiglia dall'elaborazione degli input. Nella stessa pagina mostra il tempo di esecuzione per operazione, che consente di individuare le operazioni problematiche.
Come attenuare
Esistono diverse possibili mitigazioni per il caricamento dei dati con l'API Dataset
:
- Archivia i dati come raccolta di
tf.train.Example
strutture inTFRecord
file e caricali conTFRecordDataset
. Consulta l'API Dataset tutorial o il Tutorial su ResNet per alcuni esempi. - Utilizza
dataset.cache()
odataset.prefetch()
per eseguire il buffering dei dati di input. In questo modo si impedisce che i rallentamenti sporadici nell'accesso ai file creino un collo di bottiglia. - Specifica il parametro
num_parallel_calls
della funzionedataset.map()
per abilitare le operazionimap()
con multi-thread. Un'euristica per il valorenum_parallel_calls
consiste nell'utilizzare il numero di core CPU disponibili. - Eseguire costose pre-elaborazione dei dati offline come costo una tantum anziché rispetto a dover sostenere il costo in ogni epoca di ogni addestramento.
Tutte le elaborazioni di input vengono eseguite su CPU situate sul server TPU, non della macchina locale, quindi la velocità della macchina locale non è un fattore.
Tempi di passaggio lenti e basso utilizzo di MXU
Descrizione del problema di rendimento
Cloud TPU può eseguire moltiplicazioni e convoluzioni delle matrici a velocità incredibilmente elevate. La maggior parte delle altre operazioni TensorFlow ha implementazioni efficienti sulla TPU, ma non sono le istanze principali rispetto ad altro hardware. Di conseguenza, un modello dovrebbe essere mediante moltiplicazioni matriciali o convoluzioni per sfruttare appieno la TPU.
Come capire se il tuo modello è interessato
I sintomi che vedrete in questo caso sono tempi di passi lenti associati l'utilizzo ridotto di MXU viene mostrato quando profili le prestazioni.
Come attenuare
Prova a ridurre il numero di operazioni che non sono moltiplicazioni matriciali. Dopo aver ridotto il numero di moltiplicazioni matriciali, esegui nuovamente il benchmark per vedere se le prestazioni sono accettabili per le TPU.
Eccessiva spaziatura interna del tensore
Descrizione del problema di rendimento
La TPU protegge i tensori della memoria in modo che la TPU possa usare le sue unità di calcolo in modo efficiente. La spaziatura interna può aumentare l'utilizzo di memoria e memoria e la larghezza di banda. Per assistenza, consulta la sezione sulla spaziatura interna del tensore la comprensione e la risoluzione dei problemi di spaziatura interna dei tensori.
Velocità effettiva lenta e utilizzo ridotto della memoria
Descrizione del problema di rendimento
Come regola generale, l'utilizzo di dimensioni batch più grandi si traduce in una maggiore velocità di addestramento la TPU in termini di campioni al secondo.
Come capire se il tuo modello è interessato
La dimensione del batch di qualsiasi modello deve essere sempre almeno 64 (8 per core TPU), poiché la TPU copre sempre i tensori a queste dimensioni. La dimensione ideale del batch l'addestramento sulla TPU è 1024 (128 per core TPU), poiché ciò elimina inefficienze legate al trasferimento e alla spaziatura interna della memoria.
Come attenuare
La best practice prevede di utilizzare la dimensione del batch più grande che rientra nella memoria multiplo di 64. Il modo più semplice per raggiungere questo obiettivo è iniziare con 1024 e se questo causa un errore di memoria insufficiente, quindi prova a ridurre la dimensione del batch finché dell'esecuzione del modello correttamente. La modifica della dimensione del batch di un modello può richiedere regolando altri iperparametri per ottenere la stessa accuratezza del modello, come il tasso di apprendimento, ma questo deve essere valutato caso per caso.
Dimensioni dei livelli troppo piccole
Descrizione del problema di rendimento
Anche quando un modello è dominato da moltiplicazioni o convoluzioni matriciali, La TPU potrebbe non essere eseguita alla massima efficienza se i tensori di input sono piccoli. Rispetto ad altro hardware, la TPU funziona in modo più efficiente quando sia la dimensione del batch le dimensioni dei livelli sono grandi (ad esempio, dimensione >= 512).
Come capire se il tuo modello è interessato
Come regola generale, le dimensioni dei livelli inferiori a 128 ottengono una scarsa efficienza. sulla TPU, poiché 128 è la dimensione integrata della moltiplicazione della matrice TPU unità. Per i livelli completamente connessi, è consigliata una dimensione nascosta minima di 512 in per ottenere un'elevata efficienza. Tieni presente che gli strati convoluzionali in genere non devono essere grandi quanto gli strati completamente connessi per raggiungere livello.
Come attenuare
Se la motivazione principale per gli strati di piccole dimensioni nel modello è la velocità di addestramento, eseguire nuovamente il benchmarking dei modelli con strati più grandi sulla TPU. Ad esempio, l'aumento della dimensione di output di uno strato da 256 a 512 può il tempo di addestramento del 20% anche se il modello sta eseguendo il doppio molto altro.
Profilazione del modello a livello di operatore
Spesso è utile misurare il tempo di esecuzione a livello di operazione e l'utilizzo della memoria in modo da
per identificare i colli di bottiglia delle prestazioni. Per istruzioni,
consulta la guida Cloud TPU Tools: Trace Viewer.
Debug dei cali nell'accuratezza del modello
Uno degli obiettivi dell'ecosistema Cloud TPU è che qualsiasi modello addestrato su una CPU o una GPU ottiene una precisione molto simile quando viene addestrato sulla TPU, probabilmente con piccole modifiche agli iperparametri. come la dimensione del batch e il tasso di apprendimento. A volte, però, gli utenti possono osservare un peggioramento dell'accuratezza durante l'addestramento dei modelli sulla TPU. Il debug di questo tipo di problemi possono essere estremamente frustranti a causa della natura casuale delle reti neurali addestramento. Questa sezione fornisce indicazioni su come individuare la causa principale di a causa di un calo nell'accuratezza del modello durante la portabilità del modello sulla TPU.
Informazioni sullo sharding dei dati (parallelismo dei dati)
Uno degli obiettivi principali di TensorFlow è che ogni operazione produca quasi risultati identici a prescindere dall'esecuzione su CPU, GPU o TPU. Esistono alcune eccezioni, come operazioni casuali. In generale, se trovi una differenza significativa tra l'output di operazioni non casuali su TPU e CPU, segnalalo come bug.
Tuttavia, per la pipeline di addestramento nel suo insieme, c'è una significativa
differenza tra 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 operano come
le unità di elaborazione. Per ogni passaggio dell'addestramento, ogni core TPU riceve un batch
di dati, calcola i gradienti di peso, scambia i gradienti con
e altri core TPU,
e poi calcola l'aggiornamento del peso. Per impostazione predefinita, la perdita viene calcolata in media
core, ma può essere sommato modificando il parametro di CrossShardOptimizer
.
Se la perdita totale del modello può essere calcolata come la media (o somma) di le 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 è batch normalizzazione, che supera ogni batch per core separatamente. Ad esempio, se la dimensione totale del batch è 128, la dimensione del batch per core è di 16 e ciascuno degli 8 core esegue la normalizzazione del batch su 16 campioni. In alcuni casi, l'esecuzione in batch è stato riscontrato che la normalizzazione in piccoli batch (ad esempio, meno di 32) la precisione è peggiorata. Nello scenario ideale, la dimensione totale del batch essere grande (ad es. da 256 a 1024). Se la dimensione del batch è troppo grande per essere l'effetto dello sharding deve essere valutato caso per caso.
Addestramento deterministico
Un motivo per cui è difficile eseguire il debug delle differenze di accuratezza del modello è che in diversi framework (TensorFlow, PyTorch, JAX), la il software di addestramento utilizza diversi valori di inizializzazione dei pesi e data shuffling ogni volta che viene addestrato un modello. È utile modificare la procedura di addestramento in modo che sia deterministica, in modo che più esecuzioni producano modelli quasi identici. Questa sezione dimostra come eseguire il tutorial MNIST in modo deterministico:
- Genera un file di checkpoint iniziale eseguendo un singolo passaggio sulla CPU. Questo passaggio viene utilizzato per ottenere un'inizializzazione deterministica delle ponderazioni. Inoltre, assicurati di utilizzare un seed casuale fisso per qualsiasi funzione casuale nel modello.
# Run training for 1 step to create an initial checkpoint. python mnist_tpu.py \ --use_tpu=False \ --data_dir=${STORAGE_BUCKET}/data/ \ --model_dir=${STORAGE_BUCKET}/init_output \ --random_seed=12345 \ --iterations=1 --train_steps=1
- Modifica le eventuali funzioni di data shuffling nella funzione di input in modo da utilizzare un seed casuale. Questo è già stato fatto nel tutorial MNIST. Funziona per l'input perché vengono eseguite sempre sulla CPU. Operazioni casuali nel modello potrebbe non essere deterministica tra TPU e CPU. Ogni volta che chiami un'operazione casuale, passa un seed fisso per garantire gli stessi risultati tra le esecuzioni. Ad esempio:
# In the flag definitions
tf.flags.DEFINE_integer("batch_size", None, "Random seed for training")
# In the input_fn
if FLAGS.random_seed is not None:
dataset = dataset.shuffle(seed=FLAGS.random_seed)
-
Esegui due volte lo stesso modello sulla CPU per verificare che l'addestramento sia
deterministici. Tieni presente che l'addestramento deve essere eseguito per un numero ragionevole
passi (ad esempio, 1000), ma non è necessario eseguirla per raggiungere la convergenza.
Poiché l'addestramento della CPU è confrontato con l'addestramento di una TPU single-core, utilizza un dimensione del batch che può adattarsi a un singolo core TPU (in genere, la dimensione completa del batch diviso 8). TensorFlow non garantisce il determinismo bit per bit tra ma la perdita dovrebbe essere molto vicina:
Copia i pesi iniziali
gcloud storage cp ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/cpu_output_1/ --continue-on-error gcloud storage cp ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/cpu_output_2/ --continue-on-error
Gara 1
python mnist_tpu.py \ --use_tpu=False \ --data_dir=${STORAGE_BUCKET}/data/ \ --model_dir=${STORAGE_BUCKET}/cpu_output_1 \ --batch_size=128 \ --random_seed=12345 \ --train_steps=2000 \ --eval_steps=10
Output 1
accuracy = 0.9910644, global_step = 1000, loss = 0.025323588
Gara 2
python mnist_tpu.py \ --use_tpu=False \ --data_dir=${STORAGE_BUCKET}/data/ \ --model_dir=${STORAGE_BUCKET}/cpu_output_1 \ --batch_size=128 \ --random_seed=12345 \ --train_steps=2000 \ --eval_steps=10
Uscita 2
accuracy = 0.9910644, global_step = 1000, loss = 0.025323414
Addestramento con TPU single-core
Dopo aver eseguito il tutorial MNIST in modo deterministico, il passaggio successivo di replicare i risultati di addestramento della CPU sulla TPU, utilizzando un singolo core TPU individuare se il problema è correlato allo sharding dei dati o alla TPU il motore di esecuzione di un'esecuzione.
Ecco come eseguire addestramento e valutazione single-core nel tutorial MNIST:
Usa la stessa inizializzazione delle ponderazioni della CPU
gcloud storage cp ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/tpu_output --continue-on-error
Esegui l'addestramento per 1000 passi
python mnist.py \ --use_tpu=True \ --master=$GRPC_SERVER \ --train_file=${STORAGE_BUCKET}/data/train.tfrecords \ --model_dir=${STORAGE_BUCKET}/tpu_output \ --random_seed=12345 \ --num_shards=1 \ --batch_size=128 \ --train_steps=1000 \ --eval_steps=10
Output
accuracy = 0.9910644, global_step = 1000, loss = 0.02514153
La perdita non corrisponderà esattamente al modello addestrato con CPU, ma dovrebbe essere simile. Se non è molto simile per il tuo modello, è possibile che tu abbia trovato di un bug nel motore di esecuzione della TPU. Prima del giorno l'invio di una segnalazione di bug, controlla quanto segue:
Stai passando
num_shards=1
aTPUConfig
.Non sono presenti operazioni casuali nella funzione del modello, mentre nella funzione della funzione di input sia stato eseguito correttamente.
Stai utilizzando lo stesso file di checkpoint iniziale per l'addestramento di CPU e TPU.
Debug dell'addestramento di TPU multi-core
Se il modello ha la stessa perdita sulla CPU e sulla TPU single-core, è probabile che il problema sia uno dei seguenti:
(a) Il degrado è dovuto alla varianza casuale naturale durante l'addestramento con diverse inizializzazioni.
(b) Il degrado è dovuto a un problema relativo allo sharding dei dati sulla TPU.
Per determinare se (a) è il problema, riaddestra il modello completo su CPU/GPU e TPU multi-core, con la stessa inizializzazione di peso.
Se hai la certezza che il calo dell'accuratezza sia statisticamente significativo, i problemi più probabili relativi allo sharding dei dati sono:
- Se il modello utilizza la normalizzazione del batch, la dimensione totale del batch è inferiore a 256 (ad esempio, meno di 32 per core) potrebbe ridurre l'accuratezza.
- Le funzioni di perdita a livello di batch sono interessate dallo sharding. Tali funzioni di perdita sono in genere abbastanza specializzate. Ad esempio: Karras et al. 2017 utilizza un discriminatore batch durante l'addestramento di una rete avversaria generativa.
Risoluzione dei problemi di configurazione di gcloud
- Problema
gcloud components update
mostra 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 usare
gcloud
, devi usare ungcloud
installazione che non è gestito tramite un gestore di pacchetti. Segui questi passaggi per installagcloud
dal codice sorgente:
sudo apt-get remove google-cloud-sdk curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-311.0.0-linux-x86_64.tar.gz tar -xzf google-cloud-sdk-311.0.0-linux-x86_64.tar.gz ./google-cloud-sdk/install.sh source ~/.bashrc
- Problema
Comando
gcloud compute tpus tpu-vm ssh ${TPU_NAME} --zone ${ZONE}
visualizza 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 esserci un problema con la propagazione della chiave SSH. Prova a spostare chiavi generate automaticamente in una posizione di backup per forzare la nuova creazione di
gcloud
quali: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
accedere alle TPU utilizzando una libreria condivisa denominata libtpu
presente su
in 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.
Le seguenti variabili di ambiente possono essere impostate prima di iniziare l'addestramento
per modificare il comportamento di logging:
- TPU_LOG_DIR: la directory in cui vengono scritti i log
- La posizione della directory è
/tmp/tpu_logs
per impostazione predefinita. La directory è vengono create se non esiste già, ma non vengono create directory padre. Se si verifica un errore durante il rilevamento o la creazione della directory specificata, viene stampato un messaggio su stderr, ma il programma non viene arrestato e il logging è disabilitato. Imposta il nome della directory su "disattivato" a disattivare del tutto il logging su disco. - TPU_MIN_LOG_LEVEL: la gravità minima che verrà registrata sul disco
- Le opzioni 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 opzioni sono le stesse per TPU_MIN_LOG_LEVEL. Il valore predefinito è 3.
- TPU_MAX_LOG_SIZE_MB: le dimensioni massime in megabyte di ogni file di log
- Verrà avviato automaticamente un nuovo file di log quando quello precedente raggiungerà di queste dimensioni. Il valore predefinito è 1024.