Data Science basata su GPU (NON Deep Learning) con RAPIDS

Nodo di origine: 997659

Data Science basata su GPU (NON Deep Learning) con RAPIDS

Come utilizzare la potenza della tua GPU per la normale scienza dei dati e l'apprendimento automatico anche se non svolgi molto lavoro di deep learning.



Header image
Fonte immaginePixabay (Immagine libera)

Stai cercando una "scienza dei dati basata su GPU"?

 
 
Immagina di essere uno scienziato di dati, un analista aziendale o un ricercatore accademico in Fisica/Economia/Neuroscienze...

fai un sacco di data wrangling, pulizia, test statistici, visualizzazioni regolarmente. Anche tu armeggi con un sacco di modelli lineari adattare i dati e occasionalmente avventurarsi in Foresta casuale. Anche a te piace il clustering grandi set di dati. Suona abbastanza familiare?

Tuttavia, data la natura dei set di dati su cui lavori (per lo più tabulari e strutturati), non ti avventuri così tanto nell'apprendimento profondo. Preferiresti mettere tutte le risorse hardware di cui disponi nelle cose che effettivamente fai quotidianamente, piuttosto che spendere in qualche modello di apprendimento profondo fantasioso. Di nuovo, familiare?

Hai sentito parlare della straordinaria potenza e dell'incredibile velocità di calcolo di Sistemi GPU come quelli di NVidia per tutti i tipi di applicazioni industriali e scientifiche.

E tu continui a pensare - "Cosa c'è per me? Come posso sfruttare questi potenti semiconduttori nel mio flusso di lavoro specifico?? "

Stai cercando data science basata su GPU.

Una delle opzioni migliori (e più veloci) per valutare questo approccio è utilizzare la combinazione di Saturno nuvola + RAPIDEMi spiego in dettaglio...

Le GPU nel folklore AI/ML sono state principalmente per il deep learning

 
 
Mentre l'uso di GPU e calcolo distribuito è ampiamente discusso negli ambienti accademici e aziendali per le attività di base di AI/ML (ad esempio l'esecuzione di un Rete neurale profonda a 1000 strati per la classificazione delle immagini o BERT . da un miliardo di parametri modello di sintesi vocale), hanno trovato una copertura minore quando si tratta della loro utilità per le normali attività di data science e data engineering.

Ciò nonostante, le attività relative ai dati sono il precursore essenziale di qualsiasi carico di lavoro ML in una pipeline di intelligenza artificiale e spesso costituiscono una percentuale maggioritaria del tempo e dello sforzo intellettuale speso da un data scientist o anche da un ingegnere di machine learning. Recentemente, il famoso pioniere dell'IA
Andrew Ng parlato passare da un approccio all'AI incentrato sul modello a uno incentrato sui dati sviluppo degli strumenti. Ciò significa passare molto più tempo con i dati grezzi e preelaborarli prima che un carico di lavoro AI effettivo venga eseguito sulla pipeline.

Quindi, la domanda importante è: Possiamo sfruttare la potenza della GPU e dell'elaborazione distribuita per lavori di elaborazione dati regolari??



Fonte immagine: L'autore ha creato collage da immagini gratuite (Pixabay)

 

Sebbene l'uso delle GPU e del calcolo distribuito sia ampiamente discusso negli ambienti accademici e aziendali per le attività di base di AI/ML, hanno trovato una copertura minore nella loro utilità per le normali attività di data science e data engineering.

Il fantastico ecosistema RAPIDS

 
 
Il Suite RAPIDS di librerie software e API darti — un normale data scientist (e non necessariamente un professionista dell'apprendimento profondo) — l'opzione e la flessibilità per eseguire pipeline di analisi e data science end-to-end interamente su GPU.

Questo progetto open source è stato incubato da Nvidia costruendo strumenti per sfruttare le primitive CUDA. Si concentra in particolare su esponendo il parallelismo della GPU e le funzionalità di velocità di memoria a larghezza di banda elevata attraverso il linguaggio Python intuitivo per la scienza dei dati.

Compiti comuni di preparazione e gestione dei dati sono molto apprezzati nell'ecosistema RAPIDS. Si presta anche una quantità significativa di supporto per distribuzione multi-nodo, multi-GPU ed elaborazione distribuita. Ove possibile, si integra con altre librerie che rendono fuori dalla memoria (vale a dire dimensioni del set di dati maggiori della RAM del singolo computer) elaborazione dei dati facile e accessibile per i singoli scienziati dei dati.



Fonte immagine: Collage creato dall'autore

 

I tre componenti più importanti (e Pythonic) - che sono di particolare interesse per i comuni scienziati dei dati - sono,

  • cupy: Una libreria di array basata su CUDA che sembra e si sente proprio come Numpy, mentre utilizza varie librerie CUDA, ad esempio cuBLAS, cuDNN, cuRand, cuSolver, cuSPARSE, cuFFT e NCCL per sfruttare appieno l'architettura GPU sottostante.
  • CuDF: Questa è una libreria DataFrame GPU per caricare, aggregare, unire, filtrare e manipolare dati con un API simile ai panda. I data engineer e i data scientist possono utilizzarlo per accelerare facilmente i loro flussi di attività utilizzando potenti GPU senza mai imparare i dadi e i bulloni della programmazione CUDA.
  • CuML: questa libreria consente a data scientist, analisti e ricercatori di eseguire algoritmi ML tradizionali/classici e attività di elaborazione associate sfruttando appieno la potenza di una GPU. Naturalmente, questo viene utilizzato principalmente con set di dati tabulari. Pensa a Scikit-learn e a cosa potrebbe fare con tutte quelle centinaia di Cuda e Tensor Core sulla tua scheda GPU! In seguito a ciò, nella maggior parte dei casi, l'API Python di cuML corrisponde a quella di Scikit-learn. Inoltre, cerca di offrire supporto multi-GPU e multi-nodo-GPU by integrandosi con grazia con dask, ovunque possibile, per trarre vantaggio da una vera elaborazione distribuita/cluster computing.


Possiamo sfruttare la potenza della GPU e dell'elaborazione distribuita per lavori di elaborazione dati regolari e apprendimento automatico con dati strutturati?

È diverso dall'usare Apache Spark?

 
 
Potresti chiederti in che modo questa elaborazione dei dati basata su GPU è diversa dall'utilizzo di Apache Spark. In realtà, ci sono alcune sottili differenze e solo di recente, con Spark 3.0, le GPU sono una risorsa mainstream per i carichi di lavoro Spark.

Accelerazione di Apache Spark 3.0 con GPU e RAPIDS | Blog degli sviluppatori NVIDIA
 

Non abbiamo tempo o spazio per discutere le differenze uniche di questo approccio di data science basato su GPU rispetto alle attività Big Data che sono particolarmente adatte per Apache Spark. Ma poniti queste domande e probabilmente capirai la sottile differenza,

"Come data scientist che modella le transazioni economiche e la gestione del portafoglio, voglio risolvere un sistema lineare di equazioni con 100,000 variabili. Uso una libreria di algebra lineare pura o Apache Spark?? "

"Come parte di una pipeline di compressione delle immagini, voglio usare Scomposizione di un valore singolo su una vasta matrice di milioni di voci. Apache Spark è una buona scelta per questo?? "

Le grandi dimensioni del problema non sempre significano ecosistema Apache Spark o Hadoop. Big Computation non è equivalente a Big Data. In qualità di data scientist a tutto tondo, devi conoscerli entrambi per affrontare tutti i tipi di problemi.

RAPIDS si concentra specificamente su esponendo il parallelismo della GPU e le funzionalità di velocità di memoria a larghezza di banda elevata tramite le API Python.

Cosa mostriamo in questo articolo?

 
 

Esempi nitidi solo di CuPy e CuML

 
Quindi, in questo articolo, dimostreremo solo esempi nitidi di CuPy e CuML,

  • come si confrontano (in velocità) con le corrispondenti funzioni/stimatori di Numpy e Scikit-learn
  • come sono importanti le dimensioni dei dati/problema in questo confronto di velocità.

Esempi CuDF in un articolo successivo

 
Sebbene gli esempi di ingegneria dei dati simili all'elaborazione dei dati di Panda siano di grande interesse per molti scienziati dei dati, tratteremo gli esempi di CuDF in un articolo successivo.

Qual è la mia piattaforma hardware basata su GPU?

 
Sto usando un Saturno nuvola Istanza GPU Tesla T4 in quanto occorrono letteralmente 5 minuti di lavoro per avviarsi a risorsa di elaborazione completa e caricata (con librerie DS e AI) sul cloud per tutto il mio lavoro di data science con il loro servizio. Finché non supero le 10 ore di utilizzo di Jupyter Notebook al mese, è gratuito! Se vuoi saperne di più sul loro servizio,

Lancio di Saturn Cloud Hosted: GPU Data Science per tutti!

Il GPU Computing è il futuro della scienza dei dati. Pacchetti come RAPIDS, TensorFlow e PyTorch consentono velocità fulminee...

Oltre ad avere il GPU Tesla T4, è una CPU Intel® Xeon® Platinum 4CL a 8259 core a 2.50 GHz con 16 GB di RAM e 10 GB di disco permanente. Quindi, questa è una configurazione abbastanza normale dal punto di vista della configurazione hardware (disco rigido limitato a causa del livello gratuito) cioè qualsiasi data scientist può avere questo tipo di hardware in suo possesso. L'unico fattore distintivo è la presenza della GPU e l'impostazione corretta di tutte le librerie CUDA e Python in modo che la suite RAPIDS funzioni senza intoppi.


Le grandi dimensioni del problema non sempre significano ecosistema Apache Spark o Hadoop. Big Computation non è equivalente a Big Data. In qualità di data scientist a tutto tondo, devi conoscerli entrambi per affrontare tutti i tipi di problemi.

Risolvere un sistema lineare di equazioni

 
Creiamo sistemi lineari di equazioni di varie dimensioni e utilizziamo il Numpy (e CuPy) linalg.solveroutine per risolverlo con il seguente codice,



E il codice cambia di una singola lettera (in più invocazioni) per l'implementazione di CuPy!



Nota anche come possiamo creare array CuPy da array Numpy come argomenti.

Il risultato è comunque drammatico. CuPy si avvia lentamente oa un ritmo simile a quello di Numpy, ma lo batte perfettamente per problemi di grandi dimensioni (numero di equazioni).



Scomposizione di un valore singolo

 
Successivamente, affrontiamo il problema della scomposizione in valori singolari utilizzando una matrice quadrata generata casualmente (tratta da una distribuzione normale) di dimensioni variabili. Non ripetiamo il blocco di codice qui, ma mostriamo solo il risultato per brevità.



È significativo notare che l'algoritmo CuPy non mostra prestazioni nettamente superiori a quelle dell'algoritmo Numpy in questa classe di problemi. Forse, questo è qualcosa che gli sviluppatori di CuPy dovrebbero prendere per migliorare.

Tornando alla base: Matrix inversione

 
Infine, torniamo alle basi e consideriamo il problema fondamentale dell'inversione di matrice (usato in quasi tutti gli algoritmi di machine learning). Il risultato mostra ancora una volta un guadagno di prestazioni molto favorevole da parte dell'algoritmo CuPy rispetto a quello del pacchetto Numpy.



Affrontare un problema di clustering di mezzi K

 
Successivamente, consideriamo un problema di apprendimento non supervisionato di clustering utilizzando l'algoritmo k-means fin troppo familiare. Qui, stiamo confrontando una funzione CuML con uno stimatore equivalente dal pacchetto Scikit-learn.

Solo per riferimento, ecco il confronto API tra questi due stimatori.



Fonte immagineScikit-learn ed Sito web CuML (progetti open-source)

 

Ecco il risultato per un set di dati con 10 caratteristiche/dimensioni.



Ed ecco il risultato di un altro esperimento con un set di dati di 100 funzionalità.



Chiaramente, sia la dimensione del campione (numero di righe) che la dimensionalità (numero di colonne) erano importanti per il modo in cui l'accelerazione basata su GPU si è comportata in modo superiore.

Problema di regressione lineare fin troppo familiare

 
Chi può ignorare un problema di regressione lineare per il confronto della velocità mentre si occupa di set di dati tabulari? Seguendo la cadenza come prima, variamo la dimensione del problema - questa volta sia il numero di campioni che le dimensioni contemporaneamente - e confrontiamo le prestazioni di CuML LinearRegression stimatore a quello ottenuto dalla scuderia Scikit-learn.

L'asse X nella figura seguente rappresenta la dimensione del problema, da 1,000 campioni/50 funzioni a 20,000 campioni/1000 funzioni.

Anche in questo caso, lo stimatore CuML funziona molto meglio man mano che la complessità del problema (dimensione del campione e dimensionalità) cresce.



Sommario

 
 
Ci siamo concentrati su due dei componenti più fondamentali del framework RAPIDS, che mira a portare la potenza della GPU nelle attività quotidiane di analisi dei dati e apprendimento automatico, anche quando il data scientist non esegue alcuna attività di deep learning.



Fonte immagine: Realizzato dall'autore con immagini di Pixabay gratuite (Link-1Link-2Link-3)

 

Abbiamo usato un Saturno nuvola Istanza basata su Tesla T4 per configurazione facile, gratuita e veloce e ha mostrato alcune caratteristiche delle librerie CuPy e CuML e confronti delle prestazioni di algoritmi ampiamente utilizzati.

  • Non tutti gli algoritmi delle librerie RAPIDS sono di gran lunga superiori, ma la maggior parte lo è.
  • In generale, il guadagno di prestazioni aumenta rapidamente con l'aumentare della complessità del problema (dimensione del campione e dimensionalità)
  • Se disponi di una GPU, prova sempre RAPIDS, confronta e verifica se stai ottenendo prestazioni e rendilo un affidabile cavallo di battaglia della tua pipeline di data science.
  • La modifica del codice è minima, quasi inesistente per il passaggio.

Lascia che la potenza della GPU avvii il tuo flusso di lavoro di analisi e data science.

Puoi controllare l'autore GitHub repository per codice, idee e risorse in machine learning e data science. Se sei, come me, appassionato di AI / machine learning / data science, non esitare aggiungimi su LinkedIn or Seguimi su Twitter.

Grazie a Mel.

 
Originale. Ripubblicato con il permesso.

Correlato:

Fonte: https://www.kdnuggets.com/2021/08/gpu-powered-data-science-deep-learning-rapids.html

Timestamp:

Di più da KDnuggets