Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Risoluzione dei problemi di TensorFlow - TPU

Questa guida, insieme alle domande frequenti, fornisce assistenza per la risoluzione dei problemi agli utenti che stanno addestrando i modelli TensorFlow su Cloud TPU. Se stai risolvendo problemi di formazione su 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, vedi:

Panoramica

I problemi comuni riscontrati con le Cloud TPU rientrano nelle seguenti categorie:

  1. Problemi di connessione alla TPU

  2. Debug degli errori comuni

  3. Ridurre l'utilizzo della memoria

  4. Migliorare la velocità di addestramento

  5. Eseguire il debug dei cali nell'accuratezza del modello

Errore di connessione al server TPU

Questa sezione descrive come risolvere i problemi relativi alle situazioni in cui TensorFlow smette di rispondere o stampa un errore durante la connessione alla TPU. La compilazione del grafico TPU può richiedere molto tempo per i modelli di grandi dimensioni, quindi lascia che lo script venga eseguito per almeno cinque minuti prima di concludere che non risponde più.

Il primo passaggio consiste nel verificare se il problema riguarda il server stesso o la pipeline di addestramento di TensorFlow. A tale scopo, esegui il tutorial MNIST utilizzando l'URL del server TPU e verifica che funzioni correttamente. Se i problemi di connessione con il tutorial MNIST persistono, questo conferma che si tratta di un problema con il server TPU. In questo caso:

  1. Esegui il comando seguente per elencare le TPU disponibili. Sostituisci zone e project-id con la tua zona e l'ID progetto.

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

    Verrà visualizzato 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

  2. Verifica di trasferire il valore corretto a --tpu (demo-tpu nell'esempio sopra) e che la TPU sia elencata come READY.

  3. Se la TPU non è elencata come READY o hai ancora problemi di 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.

  4. Esegui nuovamente il comando ... tpus list sopra riportato e attendi che la TPU si trovi in stato READY. L'operazione potrebbe richiedere alcuni minuti.

  5. Prova a eseguire di nuovo il tutorial MNIST.

  6. Se continui a riscontrare problemi durante l'esecuzione del tutorial MNIST, chiedi assistenza utilizzando uno dei meccanismi descritti in Assistenza.

Se l'esempio MNIST viene eseguito correttamente ma il modello smette di rispondere, è probabile che il problema riguardi la tua pipeline di addestramento. Per eseguire il debug, inizia sostituendo la strategia TPU nel codice con la strategia predefinita. Quando utilizzi la strategia predefinita, ovunque utilizzi strategy.scope() o strategy.run(), il modello viene eseguito su CPU (o GPU se presente) anziché su TPU. Se il modello viene eseguito su CPU e non su TPU, deve esserci un problema specifico della TPU. Se il problema persiste, ti consigliamo di eseguire il debug del problema sulla CPU.

Perdita di ssh connessione durante l'addestramento

La connessione ssh a Cloud TPU potrebbe scadere durante un addestramento a lunga esecuzione (in particolare se utilizzi Cloud Shell). A quel punto, non ci sono output per la console TPU e potrebbe sembrare che l'addestramento sia stato interrotto. Per evitare questo problema, esegui la sessione di addestramento con un multiplexer del terminale o uno strumento di gestione delle sessioni come tmux o screen. La connessione ssh rimarrà attiva indipendentemente dalla durata dell'addestramento.

Debug degli errori comuni

Impossibile creare una TPU

Quando crei una Cloud TPU, potresti visualizzare questo 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."

Questo è un problema di autorizzazioni e può essere risolto eseguendo questo comando:

gcloud auth login --update-adc

Questo comando aggiorna le Credenziali predefinite dell'applicazione (ADC) e dovrebbe risolvere il problema. Per saperne di più, vedi gcloud auth login.

Impossibile utilizzare il file system locale

Messaggio di errore

InvalidArgumentError: Unimplemented: File system scheme '[local]' not implemented

Framework e configurazioni interessati

Questo messaggio può verificarsi durante l'addestramento con TensorFlow utilizzando l'architettura dei nodi TPU.

Dettagli

Tutti i file di input e la directory del modello devono utilizzare un percorso del bucket Cloud Storage (gs://bucket-name/...) e questo bucket deve essere accessibile dal server TPU. Tieni presente che l'elaborazione di tutti i dati e il checkpoint del modello vengono eseguiti sul server TPU, non sulla macchina locale. Per informazioni su come configurare correttamente Cloud Storage per l'utilizzo con TPU, consulta la guida Connessione ai bucket Cloud Storage.

Tipo di dati non supportato

Messaggio di errore

TypeError: DataType is not a supported TPU infeed type.

Framework e configurazioni interessati

Questo messaggio può verificarsi durante l'addestramento con TensorFlow utilizzando l'architettura dei nodi TPU.

Dettagli

Al momento sono supportati solo i tipi di dati tf.float32, tf.int32, tf.bfloat16 e tf.bool. Altri tipi di dati comuni, come tf.uint8, tf.string e tf.int64, devono essere convertiti in uno dei tipi di dati supportati durante la pre-elaborazione dei dati (ovvero nella pipeline tf.data.Dataset).

Guarda un esempio della conversione nella funzione decode_image utilizzata nel addestramento MNIST.

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, TensorFlow compila il modello utilizzando il compilatore XLA. Sebbene questo passaggio di compilazione migliori in modo significativo la velocità di addestramento e l'utilizzo della memoria, le forme (dimensioni della dimensione) di tutti i tensori del grafico devono essere note al momento della compilazione del grafico. Se non è possibile determinare alcuna forma al momento della compilazione, la compilazione TPU non riesce con un errore come quello sopra.

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, durante l'addestramento sulla TPU, imposta drop remainder=True per dataset.batch. Questo elimina potenzialmente gli ultimi esempi 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 che non è attualmente disponibile sulla TPU.

Per un elenco delle operazioni disponibili sulla TPU, insieme ai piani di assistenza futuri e ai suggerimenti per soluzioni alternative, consulta la guida alle operazioni di TensorFlow disponibili.

Messaggio di errore esaurito

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 ponderazione (variabile), nonché i tensori dei risultati intermedi necessari per il calcolo dei gradienti. Se il modello è troppo grande per rientrare nella RAM TPU, l'inizializzazione non riesce e viene visualizzato il messaggio di errore riportato sopra. Per ulteriori informazioni, consulta la sezione sulla riduzione dell'utilizzo della memoria.

Suggerimenti per ridurre l'utilizzo di memoria:

Problemi con l'interruzione dell'esecuzione

Se TensorFlow rileva un errore durante l'esecuzione di TPU, a volte lo script a sua volta smette di rispondere anziché uscire dalla shell. In questo caso, premi CTRL+\ sulla tastiera per attivare SIGQUIT, in modo da uscire immediatamente da Python.

Analogamente, la pressione di CTRL+C durante l'esecuzione di TPU non arresta immediatamente TensorFlow, ma attende invece la fine del loop di iterazione attuale 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 contenente i comandi: 

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

dove tpu-name viene dedotto dalla prima colonna visualizzata dal comando gcloud compute tpus list e zone è la zona mostrata nella seconda colonna.

Spaziatura interna eccessiva del tensore

Possibile causa di un problema di memoria

I Tensor nella memoria TPU sono imbottiti, ovvero la TPU arrotonda le dimensioni dei tensori memorizzati per eseguire i calcoli in modo più efficiente. Questa spaziatura interna avviene in modo trasparente a 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 l'utilizzo della memoria

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 è complesso, tuttavia, per ottenere i migliori risultati, il modello deve rispettare la seguente regola generale. Per ridurre al minimo l'overhead di memoria e massimizzare l'efficienza di calcolo, deve essere verificata una delle seguenti condizioni:

  • La dimensione totale del batch deve essere un multiplo di 64 (8 per core TPU) e le dimensioni della 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 della funzionalità devono essere un multiplo di 8.

L'utilizzo di dimensioni batch 1024 e dimensioni delle caratteristiche che sono un multiplo di 128 consente di ottenere la migliore efficienza, anche se potrebbe non essere possibile per tutti i modelli. Per chiarezza, "dimensione funzionalità" si riferisce alle dimensioni nascoste di un livello completamente collegato o al numero di canali di output in una convoluzione. Non tutti i livelli sono conformi a questa regola, in particolare il primo e l'ultimo della rete. Non è un problema e si prevede che la maggior parte dei modelli richieda una certa spaziatura interna.

Riduzione dell'utilizzo della memoria

Se si verifica un errore di memoria insufficiente quando esegui il modello sulla TPU, devi seguire alcuni passaggi per ridurre l'utilizzo della memoria del modello.

I modi più efficaci per ridurre l'utilizzo della memoria sono:

  • Riduci la spaziatura eccessiva del tensore
  • Ridurre le dimensioni dei batch

Dimensioni del batch o modello troppo grandi

Possibile causa di un problema di memoria

Quando addestra una rete neurale su una CPU, GPU o TPU, l'utilizzo della memoria proviene da due origini:

  1. L'utilizzo della memoria è proporzionale al numero di ponderazioni nel modello.
  2. Memorizzazione delle attivazioni intermedie dal pass in avanti necessario per calcolare il passaggio precedente. L'utilizzo della memoria è direttamente proporzionale alla dimensione del batch, alle dimensioni del livello 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 nella rete.

Il runtime TPU tenta di ottimizzare gli operatori per adattarlo al modello in memoria (chiamato rimaterializzazione, in modo simile al checkpoint gradiente), ma non è sempre in grado di farlo.

Come ridurre l'utilizzo della memoria

Riduci lentamente le dimensioni del batch finché non rientrano nella memoria, assicurandoti che la dimensione totale del batch sia un multiplo di 64 (la dimensione del batch per core deve essere un multiplo di 8). Tieni presente che i batch di dimensioni maggiori 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 un batch di dimensioni ridotte (ad esempio, 64), prova a ridurre il numero di livelli o le dimensioni dei livelli.

Migliorare la velocità di addestramento

Se il tuo modello è in grado di essere eseguito correttamente sulla TPU, ma la velocità di addestramento è inferiore al previsto, in questa sezione vengono descritti diversi modi per migliorare la velocità. Consulta la Guida al rendimento per altri suggerimenti su come migliorare le prestazioni della formazione.

Troppi pochi passaggi per esecuzione per loop di addestramento

Descrizione del problema di rendimento

Il trasferimento dell'argomento steps_per_execution a Model.compile determina il numero di passaggi di addestramento eseguiti tra i callback host. Ogni callback host richiede una comunicazione significativa tra la CPU dell'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 callback frequenti della CPU dell'host tra i passaggi del dispositivo TPU, l'addestramento può trarre vantaggio da un valore steps_per_execution più grande.

Come attenuare

Imposta steps_per_execution su un valore più alto. Tieni presente che steps_per_execution può essere impostato su un valore elevato, ma tieni presente che la registrazione dei messaggi e il salvataggio di un checkpoint possono verificarsi solo dopo che è stato eseguito il numero di passaggi specificato.

collo di bottiglia di elaborazione degli input

Descrizione del problema di rendimento

Durante l'addestramento della TPU su un particolare blocco di dati, la funzione di elaborazione degli input prepara il blocco di dati successivo sulla CPU. Se la funzione di input richiede più tempo rispetto alla funzione del modello, la TPU viene lasciata inattiva mentre la funzione di input recupera i dati.

Come sapere se il tuo modello è interessato

Segui le istruzioni in Cloud TPU Tools: Analyzer della pipeline di input per visualizzare l'analisi della pipeline di input in TensorBoard:

immagine

La pagina di analisi della pipeline di input mostra un riepilogo chiaro, che mostra se il modello è imbottigliato dall'elaborazione degli input. La stessa pagina mostra anche il tempo di esecuzione per operazione, che ti consente di individuare le operazioni problematiche.

Come attenuare

Esistono diverse possibili attenuazioni durante il caricamento dei dati con l'API Dataset:

  1. Archivia i dati come una raccolta di strutture tf.train.Example in TFRecord file e caricali con TFRecordDataset. Per esempi, consulta il tutorial sull'API Dataset o il tutorial di ResNet.
  2. Utilizza dataset.cache() e/o dataset.prefetch() per eseguire il buffering dei dati di input. Questo impedisce che rallentamenti sporadici nell'accesso ai file creando un collo di bottiglia.
  3. Specifica il parametro num_parallel_calls della funzione dataset.map() per abilitare le operazioni map() con più thread. Una semplice euristica per il valore di num_parallel_calls è utilizzare il numero di core CPU disponibili.
  4. Esegui offline l'elaborazione dei dati costosi come costo una tantum, anziché incorrere in costi a ogni epoca di ogni addestramento.

L'intera elaborazione di input viene eseguita su CPU che si trovano sul server TPU, non sulla macchina locale, quindi la velocità della macchina locale non è un fattore determinante.

Tempi di passo lenti e basso utilizzo di MXU

Descrizione del problema di rendimento

Cloud TPU è in grado di 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 la forza principale della TPU rispetto ad altri hardware. Pertanto, un modello dovrebbe essere dominato da moltiplicazioni delle matrici o convoluzioni per sfruttare appieno la TPU.

Come sapere se il tuo modello è interessato

I sintomi che vedi in questo caso sono tempi di passi lenti abbinati a un basso utilizzo di MXU mostrato quando crei un profilo delle prestazioni.

Come attenuare

Cerca di ridurre il numero di operazioni che non sono moltiplicazioni delle matrici. Dopo aver ridotto il numero di moltiplicazioni delle matrici, controlla di nuovo se le prestazioni sono accettabili sulle TPU.

Spaziatura interna eccessiva del tensore

Descrizione del problema di rendimento

I pad dei tensori in memoria della TPU consentono alla TPU di utilizzare le sue unità di calcolo in modo efficiente. La spaziatura interna può aumentare l'utilizzo di memoria e larghezza di banda della memoria. Per informazioni sulla risoluzione e la risoluzione dei problemi relativi alla spaziatura interna del tensore, consulta la sezione sulla riempimento tensore.

Velocità effettiva lenta e basso utilizzo di memoria

Descrizione del problema di rendimento

Come regola generale, l'utilizzo di dimensioni batch più grandi comporta una maggiore velocità di addestramento sulla TPU, in termini di campioni/secondo.

Come sapere se il tuo modello è interessato

La dimensione del batch di qualsiasi modello deve essere sempre pari ad almeno 64 (8 per core TPU), poiché la TPU invia sempre i tensori a queste dimensioni. Le dimensioni batch ideali durante l'addestramento su TPU sono 1024 (128 per core TPU), poiché questo elimina le inefficienze relative al trasferimento e alla spaziatura interna della memoria.

Come attenuare

La best practice prevede l'utilizzo delle dimensioni batch più grandi che rientrano nella memoria ed è un multiplo di 64. Il modo più semplice per ottenere questo risultato è iniziare con 1024 e, se questo causa un errore di memoria insufficiente, prova a ridurre le dimensioni del batch finché il modello non viene eseguito correttamente. La modifica delle dimensioni del batch di un modello può richiedere la regolazione di altri iperparametri per ottenere la stessa precisione del modello, ad esempio la frequenza di apprendimento, ma ciò deve essere valutato caso per caso.

Dimensioni del livello troppo piccole

Descrizione del problema di rendimento

Anche quando un modello è dominato da moltiplicazioni o convoluzioni delle matrici, la CPU potrebbe non funzionare alla massima efficienza se i tensori di input sono piccoli. Rispetto a un altro hardware, la TPU viene eseguita in modo più efficiente quando le dimensioni del batch e del livello sono grandi (ad esempio, dimensione >= 512).

Come sapere se il tuo modello è interessato

Come regola generale, le dimensioni dei livelli inferiori a 128 raggiungono una scarsa efficienza sulla TPU, poiché 128 è la dimensione nativa dell'unità di moltiplicazione delle matrici TPU. Per ottenere livelli completamente connessi, è consigliata una dimensione minima nascosta di 512. Tieni presente che in genere i livelli convoluzionali non devono essere grandi quanto quelli completamente collegati per raggiungere lo stesso livello di efficienza.

Come attenuare

Se la motivazione principale per le dimensioni di strati piccoli nel modello è la velocità di addestramento, imposta nuovamente i modelli con i livelli più grandi sulla TPU. Ad esempio, l'aumento delle dimensioni di output di un livello da 256 a 512 può solo aumentare il tempo di addestramento del 20% anche se il modello esegue il doppio dei calcoli.

Profilazione di modelli a livello di operazione

Spesso è utile misurare il tempo di esecuzione a livello di op e l'utilizzo della memoria per identificare i colli di bottiglia delle prestazioni. Per istruzioni su come eseguire questa operazione,
consulta la guida Cloud TPU Tools: Trace Viewers.

Eseguire il debug dei cali di accuratezza del modello

Uno degli obiettivi dell'ecosistema Cloud TPU è che qualsiasi modello attualmente addestrato su una CPU o GPU ottiene una precisione molto simile quando viene addestrato su TPU, con piccole regolazioni di iperparametri come dimensioni del batch e percentuale di apprendimento. A volte, tuttavia, gli utenti possono notare un degrado di precisione 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 nell'accuratezza del modello durante il trasferimento di un modello alla TPU.

Informazioni sullo sharding dei dati (parallelism dei dati)

Uno degli obiettivi principali di TensorFlow è che ogni operazione dovrebbe produrre risultati quasi identici, sia che vengano eseguiti su CPU, GPU o TPU. Esistono alcune eccezioni a questa regola, ad esempio le operazioni casuali. In generale, se trovi una differenza significativa tra l'output delle operazioni non casuali sulla TPU e sulla CPU, segnalala come bug.

Tuttavia, per la pipeline di addestramento nel suo insieme, esiste una significativa differenza 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 operano come unità di elaborazione indipendenti. Per ogni passaggio dell'addestramento, ogni core TPU riceve un batch di dati, calcola le sfumature di peso, scambia le sfumature con gli altri core TPU, quindi calcola l'aggiornamento delle ponderazioni. Per impostazione predefinita, la perdita viene calcolata in media tra i core, ma può essere sommata modificando il parametro 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 non indipendente per campione è la normalizzazione batch, che viene eseguita separatamente per ogni batch per core. Ad esempio, se le dimensioni totali del batch sono 128, allora la dimensione del batch per core è 16 e ognuno degli 8 core esegue la normalizzazione sui propri 16 campioni. In alcuni casi, l'esecuzione di normalizzazione batch su piccoli batch (ad esempio, meno di 32) è risultata degraffare la precisione. Nello scenario ideale, le dimensioni totali del batch devono essere elevate (ad esempio, da 256 a 1024). Se una dimensione del batch è troppo grande per rientrare nella memoria, l'effetto dello sharding deve essere valutato caso per caso.

Addestramento deterministico

Uno dei motivi per cui è difficile eseguire il debug delle differenze di accuratezza del modello è che, attraverso framework diversi (TensorFlow, PyTorch, JAX), il software di addestramento utilizza un'inizializzazione ponderata e un shuffling dei dati diversi ogni volta che un modello viene addestrato. È 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:

  1. Generare un file di checkpoint iniziale eseguendo un singolo passaggio sulla CPU. Il passaggio viene utilizzato per ottenere l'inizializzazione del peso deterministico. Assicurati inoltre 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
  1. Modifica le funzioni di ordinamento dei dati nella funzione di input per utilizzare un seed casuale. Questa operazione è già stata eseguita nel tutorial MNIST. Questo funziona per le operazioni di elaborazione dei dati di input perché queste vengono sempre eseguite sulla CPU. Le operazioni casuali nella funzione del modello potrebbero non essere deterministiche tra la TPU e la CPU. Ogni volta che chiami un'operazione casuale, trasmetti un seed fisso per assicurarti 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)
  1. Esegui lo stesso modello due volte sulla CPU per verificare che l'addestramento sia deterministico. Tieni presente che la formazione deve essere eseguita per un numero ragionevole di passaggi (ad esempio 1000), ma non deve essere eseguita per convergenza.

    Poiché l'addestramento della CPU è confrontato con un addestramento di un singolo core TPU, utilizza una dimensione batch che può rientrare in un singolo core TPU (in genere la dimensione intera divisa per 8). TensorFlow non garantisce il determinismo bit-per-bit tra le esecuzioni, ma la perdita dovrebbe essere molto simile:

Copia le ponderazioni iniziali

gsutil mkdir ${STORAGE_BUCKET}/cpu_output_1
gsutil cp -f ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/cpu_output_1
gsutil mkdir ${STORAGE_BUCKET}/cpu_output_2
gsutil cp -f ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/cpu_output_2

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

Output 2

accuracy = 0.9910644, global_step = 1000, loss = 0.025323414

Addestramento TPU con core singolo

Dopo aver eseguito il tutorial MNIST in modo deterministico, il passaggio successivo prevede la replica dei risultati addestrati dalla CPU sulla TPU, utilizzando un singolo core TPU per determinare se il problema è correlato allo sharding dei dati o al motore di esecuzione TPU stesso.

Ecco come eseguire l'addestramento e la valutazione del core singolo per il tutorial MNIST:

Usa l'inizializzazione della stessa ponderazione della CPU

gsutil cp -f ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/tpu_output

Esegui allenamento 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 con addestramento della CPU, ma dovrebbe essere vicina. Se non è simile al tuo modello, potrebbe significare che hai trovato un bug nel motore di esecuzione di TPU. Prima di inviare una segnalazione di bug, controlla quanto segue:

  1. Stai passando num_shards=1 a TPUConfig.

  2. Non esistono operazioni casuali nella funzione del modello e tutte le operazioni casuali nella funzione di input vengono avviate correttamente.

  3. Stai utilizzando lo stesso file di checkpoint iniziale per l'addestramento di CPU e TPU.

Debug dell'addestramento multi-core TPU

Se il modello raggiunge la stessa perdita di CPU e TPU single-core, è probabile che il problema sia 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 (a) è il problema, riaddestra il modello completo su CPU/GPU e TPU multi-core utilizzando la stessa inizializzazione, come nell'esempio precedente.

Se hai la certezza che il calo di accuratezza sia statisticamente significativo, i problemi più probabili relativi allo sharding dei dati sono:

  1. Se il modello utilizza la normalizzazione batch, una dimensione totale batch inferiore a 256 (ad esempio, inferiore a 32 per core) potrebbe ridurre la precisione.
  2. Le funzioni di perdita in batch sono influenzate dallo sharding. Queste funzioni di perdita sono in genere abbastanza specializzate. Ad esempio, Karras et al. 2017 usa un discriminatore batch durante l'addestramento di una rete avversariale generativa.

Risoluzione dei problemi delle VM TPU

I seguenti problemi e soluzioni si applicano solo alle configurazioni di VM TPU.

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 utilizzare gcloud con una VM TPU, devi utilizzare un'installazione di gcloud che non sia gestita tramite un gestore di pacchetti. Per installare gcloud 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

Il comando gcloud compute tpus tpu-vm ssh ${TPU_NAME} --zone ${ZONE} mostra 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 di propagazione della chiave SSH. Prova a spostare le chiavi generate automaticamente in una posizione di backup per forzare gcloud a ricrearle:

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 tramite una libreria condivisa denominata libtpu presente 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 le informazioni utili per il debug. Per impostazione predefinita, questi log vengono scritti in /tmp/tpu_logs su ogni VM Cloud TPU. Puoi impostare le seguenti variabili di ambiente prima di iniziare l'addestramento per modificare il comportamento di logging:

TPU_LOG_DIR: la directory in cui vengono scritti i log
Il percorso predefinito della directory è /tmp/tpu_logs. La directory viene creata se non esiste già, ma non vengono create directory padre. Se si verifica un errore durante la ricerca o la creazione della directory specificata, un messaggio viene stampato a stderr, ma il programma non viene interrotto e il logging viene disabilitato. Imposta il nome della directory su "disabled" per disabilitare 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 sullo 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
Viene avviato automaticamente un nuovo file di log quando quello precedente raggiunge approssimativamente questa dimensione. Il valore predefinito è 1024.