Å bygge maskinlæringsmodeller er en repeterende prosess. Ofte rot og rutine, dette er et spill med "raskeste gjennom syklusen vinner", ettersom jo raskere du kan gjenta, jo lettere er det å utforske nye teorier og få gode svar. Dette er en av grunnene til at praktisk bruk av AI i dag domineres av de største bedriftene, noe som kan kaste enorme ressurser på problemet.
Rapids er en paraply for flere åpen kildekode-prosjekter, inkubert av Nvidia, som setter hele prosesseringsrørledningen på GPUen, og eliminerer de I / O-bundne dataoverføringene, samtidig som hastigheten på hvert enkelt trinn økes betydelig. Det gir også et vanlig format for dataene, noe som letter byrden ved å utveksle data mellom forskjellige systemer. På brukernivå etterligner Rapids Python API for å lette overgangen for den brukerbasen.
Tidyverse Cookbook Rapids økosystemarkitektur
Rapids-prosjektet har som mål å replikere, for det meste, maskinlærings- og dataanalyse-API-ene til Python, men for GPUer i stedet for CPUer. Dette betyr at Python-utviklere allerede har alt de trenger for å kjøre på GPU-en, uten å måtte lære detaljer om lavt nivå av CUDA-programmering og parallelle operasjoner. Pythonistas kan utvikle kode på en ikke-GPU-aktivert maskin, og kjør den med noen få justeringer på alle GPUene som er tilgjengelige for dem.
Nvidia CUDA-verktøykassen gir primitiver på lavere nivå for mattebiblioteker, parallelle algoritmer og grafanalyse. I hjertet av arkitekturen er GPU-datarammen, basert på Apache Arrow, som gir en søyle, datastruktur i minnet som er programmeringsspråk agnostisk. Brukeren samhandler med GPU-datarammen via cuDF og et Pandas-lignende API. Dask, et Python-bibliotek for parallell databehandling, etterligner oppstrøms Python APIer og jobber med CUDA-biblioteker for parallell beregning. Tenk på Dask som Spark for Python.
RAPIDS De tre hovedprosjektene, cuDF, cuML og cuGraph, er utviklet uavhengig, men designet for å fungere sømløst sammen. Broer til det bredere Python-økosystemet blir også utviklet som en del av prosjektet.
Rapids installasjon
Installasjon via Anaconda på en Linux-maskin i AWS var stort sett grei, og sperret noen få hikke på grunn av endring i avhengigheter i versjon 0.11. Installering av C / C ++ -bibliotekene for å bruke libcudf var ikke så enkelt, og jeg vil anbefale å holde deg til Python API-er og Conda-installasjonsprosessen. Rapids inkluderer en Jupyter-notatbok, også tilgjengelig på Googles gratis Colab, som gjør det enkelt å komme i gang. Jeg brukte Jupyter-notatbokversjonen 0.10 for å kjøre koden på Google Colab, som inkluderer en Nvidia Tesla T4 GPU.
Rapids GPU-dataramme
Kjernen i enhver datavitenskaplig arbeidsflyt er datarammen. Dette er hvor funksjonsteknikk skjer, og hvor mesteparten av tiden blir brukt, da dataforskere bryter skitne data. cuDF er Rapids-prosjektet for en GPU-basert, Pandas-lignende dataramme. Underbygging av cuDF er libcudf, et C ++ - bibliotek som implementerer primitiver på lavt nivå for å importere Apache Arrow-data, utføre elementvis matematikk på matriser og utføre sortering, sammenføyning, gruppering etter, reduksjon og andre operasjoner på minne-matriser i GPU. Den grunnleggende datastrukturen til libcudf er GPU DataFrame (GDF), som igjen er modellert på Apache Arrow sin søyle datalager.
RAPIDS Rapids Python-biblioteket presenterer brukeren et grensesnitt på høyere nivå som ligner datarammer, som de i Pandas. I mange tilfeller kjører Pandas-kode uendret på cuDF. Der dette ikke er tilfelle, kreves vanligvis bare mindre endringer.
Brukerdefinerte funksjoner i cuDF
Når du er forbi grunnleggende databehandling, er det noen ganger nødvendig å behandle rader og kolonner med brukerdefinerte funksjoner (UDFer). cuDF gir et PyData-stil-API for å skrive kode for å behandle mer kurskornede datastrukturer som matriser, serier og bevegelige vinduer. Foreløpig støttes bare numeriske og boolske typer. UDF-er kompileres ved hjelp av Numba JIT-kompilatoren, som bruker en delmengde av LLVM for å kompilere numeriske funksjoner til CUDA-maskinkode. Dette resulterer i betydelig raskere kjøretider på GPU.
Strenger i cuDF
Selv om GPU-er er fantastiske for rask behandling av flytevektorer, har de vanligvis ikke blitt brukt til behandling av strengdata, og realiteten er at de fleste data kommer til oss i form av strenger. cuStrings er et GPU-manipuleringsbibliotek for splitting, bruk av regexer, sammenkobling, erstatning av tokens osv. i strengstrenger. Som andre funksjoner i cuDF, er den implementert som et C / C ++ - bibliotek (libnvStrings) og pakket inn av et Python-lag designet for å etterligne Pandas. Selv om strengens datatype ikke er optimalisert for kjøring på GPUer, bør parallell kjøring av koden gi en hastighet over CPU-basert strengmanipulering.
Få data inn eller ut av cuDF
Dataframe I / O håndteres av et dedikert bibliotek, cuIO. Alle de vanligste formatene støttes, inkludert Arrow, ORC, Parkett, HDF5 og CSV. Hvis du er heldig nok til å kjøre på DGX-2-maskinvare, kan du bruke GPU Direct Storage-integrering til å flytte data direkte fra høyhastighetslagring til GPU uten å involvere CPU. Dødelige brukere vil fremdeles sette pris på hastigheten GPU gir når dekomprimerer store datasett, og den tette integrasjonen med Python-økosystemet.
GPU Direct Storage er for øyeblikket i alfa, og når den blir utgitt, vil den være tilgjengelig på de fleste Tesla GPUer. Du kan opprette en GPU-dataramme fra NumPy-matriser, Pandas DataFrames og PyArrow-tabeller med bare en enkelt kodelinje. Andre prosjekter kan utveksle data via __cuda_array_interface__ for biblioteker som faller inn under Numba-økosystemet. DLPack for nevrale nettverksbiblioteker er også et støttet grensesnitt.
Sannsynligvis den største ulempen med å bruke cuDF er mangelen på interoperabilitet utenfor Python. Jeg tror et fokus på et sterkt fundament av C / C ++ APIer, slik Arrow har gjort, ville muliggjøre et bredere økosystem og være til fordel for prosjektet som helhet.
Rapids ’cuML
cuMLs uttalte mål er å være "Pythons Scikit-learning drevet av GPUer." I teorien betyr dette at du bare trenger å endre importoppgaven din og kanskje stille noen av parametrene for å ta hensyn til forskjellene i å kjøre på en CPU, der noen ganger er en brute force-tilnærming bedre. Fordelen med å ha en GPU-basert Scikit-læring er vanskelig å undervurdere. Hastighetene er betydelige, og dataanalytikere kan være mange ganger mer produktive. C ++ API er ikke helt klar for bredt forbruk utenfor Python-bindinger, men dette forventes å bli bedre.
cuML inkluderer også APIer for å hjelpe til med innstilling av hyperparameter via Dask, et bibliotek for skalering av Python på tvers av flere noder. Mange maskinlæringsalgoritmer kan effektivt gjøres parallelle, og cuML utvikler aktivt både multi-GPU og multi-node, multi-GPU algoritmer.
RAPIDS Rapids ’cuGraph
cuGraph er det tredje medlemmet av Rapids-økosystemet, og som de andre er cuGraph fullt integrert med cuDF og cuML. Det tilbyr et godt utvalg av grafalgoritmer, primitiver og verktøy, alt med GPU-akselerert ytelse. Valget av APIer i cuGraph er noe mer omfattende enn i andre deler av Rapids, med NetworkX, Pregel, GraphBLAS og GQL (Graph Query Language) alle tilgjengelige.
RAPIDS cuGraph er mer som et verktøysett i ånd enn cuML. Grafteknologi er et raskt bevegelig rom både i akademia og industri. Dermed gir cuGraph utviklere tilgang til C ++ -laget og grafprimitiver etter design, og oppfordrer tredjeparter til å utvikle produkter ved hjelp av cuGraph. Flere universiteter har bidratt, og prosjekter fra Texas A&M (GraphBLAS), Georgia Tech (Hornet) og UC Davis (Gunrock) har blitt "produktisert" og inkludert under cuGraph-paraplyen. Hvert prosjekt gir et annet sett med funksjoner, alt GPU-akselerert, og alt støttet av samme cuDF-dataramme.
NetworkX er Python API målrettet av Rapids-teamet for sitt opprinnelige grensesnitt. Det er en rekke algoritmer tilgjengelig via det grensesnittet. Mens bare siderangering er multi-GPU, jobber teamet aktivt med multi-GPU-versjoner av de andre, der det er aktuelt.
RAPIDS Et av cuGraph-delprosjektene jeg syntes var interessant er cugraphBLAS, et forsøk på å standardisere byggesteiner for grafalgoritmer på språket for lineær algebra. Basert på GraphBLAS (graphblas.org), en tilpasset datastruktur designet for sparsom dynamisk behandling av grafer.
Et annet cuGraph-delprosjekt, Hornet, gir et systemuavhengig format for å inneholde grafdata, analogt med måten Apache-pilen gir en systemuavhengig måte å behandle datarammer på. Hornet støtter de fleste av de populære grafformatene, inkludert SNAP, mtx, metis og kanter.
I tråd med ånden til å være nær Pythonsamfunnet, kan Pythons opprinnelige NetworkX-pakke brukes til å studere komplekse nettverk. Dette inkluderer datastrukturer for grafer og flergrafer, reimplementert ved bruk av CUDA-primitiver, slik at du kan gjenbruke mange av standardgrafalgoritmene og utføre nettverksstruktur og analysetiltak. De fleste algoritmer er single-GPU, som NetworkX. Likevel, å kjøre dem på GPU alene gir betydelig hastighet, mens arbeidet fortsetter å flytte til multi-GPU-implementeringer.
På veikartet Rapids
Gitt den enorme hastigheten som GPU-basert analyse gir, er det noen få nye prosjekter som kommer inn i blandingen i fremtidige versjoner.
DLPack og array_interface for dyp læring
Nevriske nettverk i flere lag var en av de første arbeidsmengdene som ble flyttet til GPUer, og det er en betydelig mengde kode for denne maskinlæringsbruken. Tidligere var DLPack de facto-standarden for datautveksling mellom dype læringsbiblioteker. I dag støttes ofte array_interface. Rapids støtter begge deler.
cuSignal
Som de fleste andre prosjekter på Rapids, er cuSignal en GPU-akselerert versjon av et eksisterende Python-bibliotek, i dette tilfellet SciPy Signal-biblioteket. Det originale SciPy Signal-biblioteket er basert på NumPy, som erstattes med GPU-akselerert ekvivalent, CuPy in cuSignal. Dette er et godt eksempel på Rapids designfilosofi på jobben. Med unntak av noen få tilpassede CUDA-kjerner, innebærer porten til GPU for det meste å erstatte importerklæringen og tilpasse noen få funksjonsparametere.
Å bringe signalbehandling inn i Rapids-brettet er et smart trekk. Signalbehandling er overalt og har mange umiddelbart nyttige kommersielle applikasjoner innen industri og forsvar.
cuSpatial
Romlig og spatiotemporal drift er gode kandidater for GPU-akselerasjon, og de løser mange virkelige problemer vi møter i hverdagen, for eksempel å analysere trafikkmønstre, jordhelse / -kvalitet og flomrisiko. Mye av dataene som samles inn av mobile enheter, inkludert droner, har en geospatial komponent, og romlig analyse er kjernen i Smart City.
Arkitekturert som de andre komponentene, cuSpatial er et C ++ - bibliotek bygget på CUDA-primitiver og Thrust-vektorbehandlingsbiblioteket, ved hjelp av cuDF for datautveksling. Forbrukere av C ++ - biblioteket kan lese punkt-, polyline- og polygondata ved hjelp av en C ++ -leser. Python-brukere har det bedre å bruke eksisterende Python-pakker som Shapely eller Fiona for å fylle et NumPy-array, og deretter bruke cuSpatial Python API eller konvertere til cuDF-datarammer.
cuxfilter for datavisualisering
Visualisering av data er grunnleggende, både i analysen arbeidsflyten og for presentasjon eller rapportering av resultater. Likevel, for all den magien som GPU-er kan jobbe med selve dataene, er det ikke en triviell oppgave å få dataene ut til en nettleser. cuxfilter, inspirert av Crossfilter JavaScript-biblioteket, tar sikte på å bygge bro over gapet ved å tilby en stabel som gjør det mulig for tredjeparts visualiseringsbiblioteker å vise data i cuDF-datarammer.
Det har vært noen iterasjoner av cuxfilter ettersom teamet sorterer ut de beste arkitektur- og kontaktmønstrene. Den siste iterasjonen bruker Jupyter-notatbøker, Bokeh-server og PyViz-paneler, mens integrasjonseksperimenter inkluderer prosjekter fra Uber, Falcon og PyDeck. Denne komponenten er ikke helt klar for beste sendetid ennå, men er planlagt for utgivelse i Rapids 0.13. Det er mange bevegelige deler, og jeg fikk ikke eksperimentere med det førstehånds, men hvis det lever opp til sitt løfte, vil dette være et flott tillegg til Rapids-verktøysettet.
Skaler opp og ut med Dask
Dask distribueres oppgaveplanlegger for Python, og spiller en lignende rolle for Python som Apache Spark spiller for Scala. Dask-cuDF er et bibliotek som gir partisjonerte, GPU-støttede datarammer. Dask-cuDF fungerer bra når du planlegger å bruke cuML eller når du laster inn et datasett som er større enn GPU-minne eller er spredt over flere filer.
I likhet med et Spark RDD (Resilient Distributed Dataset) oppfører Dask-cuDF-distribuert dataramme seg som en lokal, slik at du kan eksperimentere med din lokale maskin og flytte til en distribuert modell når du trenger å skalere opp. Dask-cuML gir cuML-muligheter for flere noder, noe som gjør det til et godt alternativ når du ikke har budsjett for en DGX-arbeidsstasjon.
