5 consigli per l'allenamento multi-GPU con Keras

• Gennaio 21, 2018
• Vasilis Vryniotis
• . 1 Commento

Deep Learning (la parola d'ordine preferita della fine del 2010 insieme a blockchain / bitcoin e Data Science / Machine Learning) ci ha permesso di fare cose davvero interessanti negli ultimi anni. A parte i progressi negli algoritmi (che sono certamente basati su idee già note dagli anni '1990 alias "Data Mining era"), le ragioni principali del suo successo possono essere attribuite alla disponibilità di grandi set di dati gratuiti, all'introduzione di librerie open source e l'uso di GPU. In questo post del blog mi concentrerò sugli ultimi due e condividerò con voi alcuni suggerimenti che ho imparato nel modo più duro.

Perché TensorFlow e Keras?

TensorFlow è una libreria Deep Learning molto popolare sviluppata da Google che consente di prototipare reti rapidamente complesse. Viene fornito con molte funzionalità interessanti come la differenziazione automatica (che consente di evitare di stimare / codificare i gradienti delle funzioni di costo) e il supporto GPU (che consente di ottenere facilmente un miglioramento della velocità 200x utilizzando un hardware decente). Inoltre offre un'interfaccia Python che significa che è possibile prototipare rapidamente senza la necessità di scrivere codice C o CUDA. Certamente ci sono molti altri framework che è possibile utilizzare al posto di TensorFlow, come Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK, ecc. Ma tutto si riduce al tuo caso d'uso e alle tue preferenze personali.

Ma perché Keras? Per me usare direttamente TF è come fare Machine Learning con Numpy. Sì, è fattibile e di tanto in tanto devi farlo (specialmente se scrivi livelli / funzioni di perdita personalizzati) ma vuoi davvero scrivere codice che descriva le reti complesse come una serie di operazioni vettoriali (sì, lo so ci sono metodi di livello superiore in TF ma non sono così fighi come Keras)? E se volessi spostarti in un'altra libreria? Bene, probabilmente dovresti riscrivere il codice, il che fa schifo. Ta ta taaa, Keras in soccorso! Keras ti consente di descrivere le tue reti usando concetti di alto livello e di scrivere codice indipendente dal backend, il che significa che puoi eseguire le reti attraverso diverse librerie di deep learning. Poche cose che adoro di Keras è che è ben scritto, ha un'architettura orientata agli oggetti, è facile da contribuire e ha una comunità amichevole. Se ti piace, di 'grazie a Francois Chollet per averlo sviluppato e aperto.

Suggerimenti e suggerimenti per l'allenamento con più GPU

Senza ulteriori indugi, passiamo ad alcuni suggerimenti su come sfruttare al meglio l'allenamento della GPU su Keras e un paio di trucchi da tenere a mente:

1. L'allenamento multi-GPU non è automatico

I modelli di addestramento su GPU che utilizzano Keras e Tensorflow sono fluidi. Se hai una scheda NVIDIA e hai installato CUDA, le librerie la rileveranno automaticamente e la useranno per l'addestramento. Così bello! Ma cosa succede se sei un monello viziato e hai più GPU? Ebbene, sfortunatamente dovrai lavorare un po 'per ottenere un addestramento multi-GPU.

Esistono diversi modi per parallelizzare una rete in base a ciò che si desidera ottenere, ma i due approcci principali sono la parallelizzazione del modello e dei dati. Il primo può aiutarti se il tuo modello è troppo complesso per adattarsi a una singola GPU mentre il secondo aiuta quando vuoi accelerare l'esecuzione. In genere quando le persone parlano di allenamento multi-GPU intendono quest'ultima. In passato era più difficile da raggiungere, ma per fortuna Keras ha recentemente incluso un metodo di utilità chiamato multi_gpu_model che semplifica l'addestramento / le previsioni parallele (attualmente disponibile solo con backend TF). L'idea principale è che il modello venga passato attraverso il metodo e copiato su diverse GPU. L'input originale è suddiviso in blocchi che vengono inviati alle varie GPU e quindi aggregati come un singolo output. Questo metodo può essere utilizzato per ottenere formazione e previsioni parallele, tuttavia tenere presente che per la formazione non si ridimensiona in modo lineare con la quantità di GPU a causa della sincronizzazione richiesta.

2. Prestare attenzione alle dimensioni del lotto

Quando esegui un allenamento multi-GPU presta attenzione alle dimensioni del batch in quanto ha molteplici effetti su velocità / memoria, convergenza del tuo modello e se non stai attento potresti corrompere i pesi del tuo modello!

Velocità / memoria: Ovviamente più grande è il lotto più veloce è l'allenamento / previsione. Questo perché c'è un sovraccarico nell'inserimento e nella rimozione dei dati dalle GPU, quindi i piccoli lotti hanno più sovraccarico. D'altro canto, maggiore è il batch, maggiore è la memoria necessaria nella GPU. Soprattutto durante l'allenamento, gli input di ciascun layer vengono mantenuti in memoria poiché sono richiesti nella fase di propagazione posteriore, quindi aumentare troppo la dimensione del batch può causare errori di memoria insufficiente.

Convergenza: Se usi Stochastic Gradient Decent (SGD) o alcune delle sue varianti per addestrare il tuo modello, dovresti tenere presente che le dimensioni del batch possono influenzare la capacità della tua rete di convergere e generalizzare. Le dimensioni tipiche dei lotti in molti problemi di visione artificiale sono tra 32-512 esempi. Come Kescar et al per dirla, "È stato osservato in pratica che quando si utilizza un batch più grande (rispetto a 512) si verifica un peggioramento della qualità del modello, misurato dalla sua capacità di generalizzazione". Si noti che altri ottimizzatori diversi hanno proprietà diverse e tecniche di ottimizzazione distribuite specializzate possono aiutare a risolvere il problema. Se sei interessato ai dettagli matematici, ti consiglio di leggere la tesi di Joeri Hermans "Discesa graduale su apprendimento profondo e parallelo".

Corruzione dei pesi: Questo è un brutto dettaglio tecnico che può avere risultati devastanti. Quando si esegue un addestramento multi-GPU, è importante alimentare tutti i GPU con i dati. Può succedere che l'ultimo lotto della tua epoca abbia meno dati di quanto definito (perché la dimensione del tuo set di dati non può essere divisa esattamente per la dimensione del tuo lotto). Ciò potrebbe impedire ad alcune GPU di non ricevere dati durante l'ultimo passaggio. Sfortunatamente alcuni livelli di Keras, in particolare il livello di normalizzazione in lotti, non possono far fronte a quello che porta a valori nan che compaiono nei pesi (media corrente e varianza nel livello BN). Per rendere le cose ancora più cattive, non si osserverà il problema durante l'allenamento (mentre la fase di apprendimento è 1) perché lo strato specifico utilizza la media / varianza del batch nelle stime. Tuttavia durante le previsioni (fase di apprendimento impostata su 0), viene utilizzata la media / varianza corrente che nel nostro caso può diventare nan portando a scarsi risultati. Quindi fatevi un favore e assicuratevi sempre che la dimensione del vostro lotto sia corretta quando si fa un allenamento multi-GPU. Due semplici modi per raggiungere questo obiettivo sono o rifiutando i batch che non corrispondono alla dimensione predefinita o ripetere i record all'interno del batch fino a raggiungere la dimensione predefinita. Infine, tieni presente che in una configurazione multi-GPU, la dimensione del batch dovrebbe essere un multiplo del numero di GPU disponibili sul tuo sistema.

3. Dati GPU La fame, ovvero le CPU, non riesce a tenere il passo con le GPU

In genere la parte più costosa durante l'addestramento / previsione delle reti profonde è la stima che si verifica sulle GPU. I dati vengono preelaborati nelle CPU in background e vengono inviati periodicamente alle GPU. Tuttavia, non bisogna sottovalutare la velocità con cui le GPU sono veloci; può succedere che se la tua rete è troppo superficiale o la fase di preelaborazione è troppo complessa per cui le tue CPU non riescono a tenere il passo con le tue GPU o in altre parole non forniscono loro dati abbastanza rapidamente. Ciò può portare a un basso utilizzo della GPU che si traduce in spreco di denaro / risorse.

Keras esegue in genere le stime dei batch in parallelo, tuttavia a causa del GIL (Global Interpreter Lock) di Python non è possibile ottenere un vero multi-threading in Python. Esistono due soluzioni per questo: utilizzare più processi (si noti che ci sono molti trucchi in questo che non tratterò qui) o mantenere semplice la fase di preelaborazione. In passato ho inviato una richiesta pull su Keras per alleviare alcuni degli sforzi inutili che stavamo mettendo sulle CPU durante la preelaborazione delle immagini, quindi la maggior parte degli utenti non dovrebbe essere interessata se usano i generatori standard. Se hai generatori personalizzati, prova a inviare quanta più logica possibile alle librerie C come Numpy perché alcuni di questi metodi in realtà rilasciare il GIL ciò significa che è possibile aumentare il grado di parallelizzazione. Un buon modo per rilevare se stai affrontando la fame di dati GPU è monitorare l'utilizzo della GPU, tuttavia tieni presente che questo non è l'unico motivo per osservare che (la sincronizzazione che si verifica durante l'addestramento su più GPU è anche la causa di un basso utilizzo ). In genere la fame di dati GPU può essere rilevata osservando esplosioni di GPU seguite da lunghe pause senza utilizzo. In passato ho creato un'estensione per Dstat che può aiutarti a misurare l'utilizzo della GPU, quindi dai un'occhiata al post del blog originale.

4. Salvataggio dei modelli paralleli

Supponiamo che tu abbia usato il metodo mutli_gpu_model per parallelizzare il tuo modello, l'addestramento è terminato e ora vuoi persistere nei suoi pesi. La cattiva notizia è che non puoi semplicemente chiamare save () su di esso. Attualmente Keras ha una limitazione che non te lo consente salva un modello parallelo. Ci sono 2 modi per aggirare questo: o chiamare il save () sul riferimento del modello originale (i pesi verranno aggiornati automaticamente) o è necessario serializzare il modello tagliando la versione in parallelo e ripulendo tutte le connessioni non necessarie. La prima opzione è molto più semplice, ma in futuro ho intenzione di open-source un metodo serialize () che esegue quest'ultima.

5. Il conteggio delle GPU disponibili ha un brutto effetto collaterale

Sfortunatamente al momento, c'è un brutto effetto collaterale sul metodo tensorflow.python.client.device_lib.list_local_devices () che provoca la creazione di una nuova sessione TensorFlow e l'inizializzazione di tutte le GPU disponibili sul sistema. Ciò può portare a risultati imprevisti come la visualizzazione di più GPU rispetto a quelle specificate o l'inizializzazione prematura di nuove sessioni (puoi leggere tutti i dettagli su questo pull-Richiesta). Per evitare sorprese simili, ti consigliamo di utilizzare il metodo K.get_session (). List_devices () di Keras, che ti restituirà tutte le GPU attualmente registrate nella sessione. Ultimo ma non meno importante, tieni presente che chiamare il metodo list_devices () è in qualche modo costoso, quindi se sei solo interessato al numero di GPU disponibili chiama il metodo una volta e memorizza il loro numero su una variabile locale.

Questo è tutto! Spero che tu abbia trovato utile questo elenco. Se hai trovato altri suggerimenti / suggerimenti per l'allenamento della GPU su Keras, condividili di seguito nei commenti. 🙂