Bygning af maskinlæringsmodeller er en gentagen proces. Ofte rote og rutine, dette er et spil med "hurtigste gennem cyklussen vinder", da jo hurtigere du kan gentage, jo lettere er det at udforske nye teorier og få gode svar. Dette er en af grundene til, at praktisk virksomhedsbrug af AI i dag er domineret af de største virksomheder, som kan kaste enorme ressourcer på problemet.
Rapids er en paraply til flere open source-projekter, inkuberet af Nvidia, der placerer hele behandlingsrørledningen på GPU'en, hvilket eliminerer de I / O-bundet dataoverførsler, samtidig med at hastigheden for hvert af de enkelte trin øges væsentligt. Det giver også et fælles format for dataene, hvilket letter byrden ved udveksling af data mellem forskellige systemer. På brugerniveau efterligner Rapids Python API for at lette overgangen til den pågældende brugerbase.
Tidyverse-kogebogen Rapids økosystemarkitektur
Rapids-projektet sigter mod at replikere for det meste maskinindlæring og dataanalyse-API'er fra Python, men til GPU'er snarere end CPU'er. Dette betyder, at Python-udviklere allerede har alt, hvad de har brug for til at køre på GPU'en uden at skulle lære detaljerne på lavt niveau i CUDA-programmering og parallelle operationer. Pythonistas kan udvikle kode på en ikke-GPU-aktiveret maskine, og kør den derefter med et par tweaks på alle de GPU'er, der er tilgængelige for dem.
Nvidia CUDA-værktøjssættet giver primitiver på lavere niveau til matematiske biblioteker, parallelle algoritmer og grafanalyser. Kernen i arkitekturen er GPU-datarammen, der er baseret på Apache Arrow, der giver en søjleformet datastruktur i hukommelsen, der er programmeringssprog agnostisk. Brugeren interagerer med GPU-datarammen via cuDF og en Pandas-lignende API. Dask, et Python-bibliotek til parallel computing, efterligner Python API'erne opstrøms og arbejder med CUDA-biblioteker til parallel beregning. Tænk på Dask som Spark for Python.
RAPIDS De tre hovedprojekter, cuDF, cuML og cuGraph, er udviklet uafhængigt, men designet til at fungere problemfrit sammen. Broer til det bredere Python-økosystem udvikles også som en del af projektet.
Hurtiginstallation
Installation via Anaconda på en Linux-maskine i AWS var for det meste ligetil og spærrede nogle få hikke på grund af en ændring i afhængigheder i version 0.11. Installation af C / C ++ - bibliotekerne til brug af libcudf var ikke så let, og jeg vil anbefale at holde fast i Python API'er og Conda-installationsprocessen. Rapids inkluderer en Jupyter-notesbog, der også er tilgængelig på Googles gratis Colab, der gør det nemt at komme i gang. Jeg brugte Jupyter notebook version 0.10 til at køre koden på Google Colab, som inkluderer en Nvidia Tesla T4 GPU.
Rapids 'GPU-dataramme
Kernen i enhver datalogi-arbejdsgang er datarammen. Det er her, funktionsteknik sker, og hvor størstedelen af tiden bruges, da dataforskere kæmper for beskidte data. cuDF er Rapids-projektet til en GPU-baseret, Pandas-lignende dataframe. Understøtter cuDF er libcudf, et C ++ - bibliotek, der implementerer primitiver på lavt niveau til import af Apache Arrow-data, udfører elementvis matematik på arrays og udfører sortering, sammenføjning, gruppering efter, reduktion og andre operationer på in-GPU-hukommelsesmatricer. Den grundlæggende datastruktur for libcudf er GPU DataFrame (GDF), som igen er modelleret på Apache Arrow's søjleformede datalager.
RAPIDS Rapids Python-biblioteket præsenterer brugeren for en grænseflade på højere niveau, der ligner datarammer, som dem i Pandas. I mange tilfælde kører Pandas-kode uændret på cuDF. Hvor dette ikke er tilfældet, kræves der normalt kun mindre ændringer.
Brugerdefinerede funktioner i cuDF
Når du er forbi grundlæggende databehandling, er det undertiden nødvendigt at behandle rækker og kolonner med brugerdefinerede funktioner (UDF'er). cuDF giver en PyData-stil API til at skrive kode for at behandle mere kursforarbejdede datastrukturer som arrays, serier og bevægelige vinduer. I øjeblikket understøttes kun numeriske og boolske typer. UDF'er kompileres ved hjælp af Numba JIT-kompilatoren, som bruger et undersæt af LLVM til at kompilere numeriske funktioner til CUDA-maskinkode. Dette resulterer i væsentligt hurtigere køretider på GPU'en.
Strenge i cuDF
Selvom GPU'er er fantastiske til hurtig behandling af floatvektorer, er de typisk ikke blevet brugt til behandling af strengdata, og virkeligheden er, at de fleste data kommer til os i form af strenge. cuStrings er et GPU-strengmanipulationsbibliotek til opdeling, anvendelse af regexes, sammenkædning, udskiftning af tokens osv. i strengearrays. Ligesom andre funktioner i cuDF implementeres det som et C / C ++ - bibliotek (libnvStrings) og indpakket af et Python-lag designet til at efterligne Pandaer. Selvom strengdatatypen ikke er optimeret til udførelse på GPU'er, bør parallel udførelse af koden give en hastighed over CPU-baseret strengmanipulation.
Få data ind eller ud af cuDF
Dataframe I / O håndteres af et dedikeret bibliotek, cuIO. Alle de mest almindelige formater understøttes, herunder pil, ORC, parket, HDF5 og CSV. Hvis du er heldig nok til at køre på DGX-2-hardware, kan du bruge GPU Direct Storage-integration til at flytte data direkte fra højhastighedslagring til GPU uden at involvere CPU'en. Dødelige brugere vil stadig sætte pris på den hastighed, GPU'en giver, når dekomprimering af store datasæt og den tætte integration med Python-økosystemet.
GPU Direct Storage er i øjeblikket i alfa, og når det frigives, vil det være tilgængeligt på de fleste Tesla GPU'er. Du kan oprette en GPU-dataramme fra NumPy-arrays, Pandas DataFrames og PyArrow-tabeller med kun en enkelt kodelinje. Andre projekter kan udveksle data via __cuda_array_interface__ til biblioteker, der falder inden for Numba-økosystemet. DLPack til neurale netværksbiblioteker er også en understøttet grænseflade.
Sandsynligvis den største ulempe ved at bruge cuDF er manglen på interoperabilitet uden for Python. Jeg tror, at fokus på et stærkt fundament af C / C ++ API'er, som Arrow har gjort, ville muliggøre et bredere økosystem og gavne projektet som helhed.
Rapids 'cuML
cuMLs erklærede mål er at være "Pythons Scikit-læring drevet af GPU'er." I teorien betyder det, at du kun skal ændre din importerklæring og måske indstille nogle få af parametrene for at tage højde for forskellene i at køre på en CPU, hvor nogle gange en brute force-tilgang er bedre. Fordelen ved at have en GPU-baseret Scikit-læring er svært at undervurdere. Speedups er betydelige, og dataanalytikere kan være mange gange mere produktive. C ++ API er ikke helt klar til bredt forbrug uden for sine Python-bindinger, men dette forventes at blive bedre.
cuML inkluderer også API'er til at hjælpe med hyperparameter tuning via Dask, et bibliotek til skalering af Python på tværs af flere noder. Mange maskinindlæringsalgoritmer kan effektivt gøres parallelle, og cuML udvikler aktivt både multi-GPU og multi-node, multi-GPU algoritmer.
RAPIDS Rapids 'cuGraph
cuGraph er det tredje medlem af Rapids-økosystemet, og ligesom de andre er cuGraph fuldt integreret med cuDF og cuML. Det tilbyder et godt udvalg af grafalgoritmer, primitiver og hjælpeprogrammer, alle med GPU-accelereret ydelse. Valget af API'er i cuGraph er noget mere omfattende end i andre dele af Rapids, hvor NetworkX, Pregel, GraphBLAS og GQL (Graph Query Language) alle er tilgængelige.
RAPIDS cuGraph er mere som et værktøjssæt i ånden end cuML. Grafteknologi er et hurtigt bevægende rum både i den akademiske verden og industrien. Ved design giver cuGraph således udviklere adgang til C ++ - laget og grafprimitiver, hvilket tilskynder tredjeparter til at udvikle produkter ved hjælp af cuGraph. Flere universiteter har bidraget, og projekter fra Texas A&M (GraphBLAS), Georgia Tech (Hornet) og UC Davis (Gunrock) er blevet "produktiseret" og inkluderet under cuGraph-paraplyen. Hvert projekt giver et andet sæt funktioner, alt GPU-accelereret og alt understøttet af den samme cuDF-dataramme.
NetworkX er Python API målrettet af Rapids-teamet til sin oprindelige grænseflade. Der er en række algoritmer tilgængelige via denne grænseflade. Mens kun siderangering er multi-GPU, arbejder holdet aktivt på multi-GPU-versioner af de andre, hvor det er relevant.
RAPIDS Et af de cuGraph delprojekter, jeg fandt interessant, er cugraphBLAS, et forsøg på at standardisere byggesten til grafalgoritmer på sproget for lineær algebra. Baseret på GraphBLAS (graphblas.org), en brugerdefineret datastruktur designet til sparsomme dynamiske grafer.
Et andet cuGraph-delprojekt, Hornet, giver et systemuafhængigt format til at indeholde grafdata, analogt med den måde, Apache-pilen giver en systemuafhængig måde at behandle datarammer på. Hornet understøtter de fleste af de populære grafformater, herunder SNAP, mtx, metis og kanter.
I overensstemmelse med ånden i at være tæt på Python-samfundet kan Pythons native NetworkX-pakke bruges til undersøgelse af komplekse netværk. Dette inkluderer datastrukturer til grafer og multigrafer, genimplementeret ved hjælp af CUDA-primitiver, så du kan genbruge mange af standardgrafalgoritmerne og udføre netværksstruktur og analysemetoder. De fleste algoritmer er single-GPU, ligesom NetworkX. Ikke desto mindre tilbyder kørsel af dem kun på GPU'en betydelig hastighed, mens arbejdet fortsætter med at flytte til multi-GPU-implementeringer.
På køreplanen for Rapids
I betragtning af den enorme hastighed, som GPU-baseret analyse giver, er der et par nye projekter, der kommer i blandingen i fremtidige versioner.
DLPack og array_interface til dyb læring
Neurale net i flere lag var en af de første arbejdsbelastninger, der blev flyttet til GPU'er, og der findes en betydelig kropsdel til denne maskinlæring. Tidligere var DLPack de facto-standarden for dataudveksling mellem dyb læringsbiblioteker. I dag understøttes array_interface ofte. Rapids understøtter begge dele.
cuSignal
Som de fleste andre projekter hos Rapids er cuSignal en GPU-accelereret version af et eksisterende Python-bibliotek, i dette tilfælde SciPy Signal-biblioteket. Det originale SciPy Signal-bibliotek er baseret på NumPy, som erstattes med dets GPU-accelererede ækvivalent, CuPy i cuSignal. Dette er et godt eksempel på Rapids designfilosofi på arbejdspladsen. Med undtagelse af nogle få tilpassede CUDA-kerner involverer porten til GPU'en for det meste udskiftning af importerklæringen og tilpasning af nogle få funktionsparametre.
At bringe signalbehandling ind i Rapids-folden er et smart træk. Signalbehandling er overalt og har mange umiddelbart nyttige kommercielle applikationer inden for industri og forsvar.
cuSpatial
Rumlige og rumlige tidsmæssige operationer er gode kandidater til GPU-acceleration, og de løser mange virkelige problemer, vi står over for i hverdagen, såsom analyse af trafikmønstre, jordsundhed / kvalitet og oversvømmelsesrisiko. Meget af de data, der indsamles af mobile enheder, inklusive droner, har en geospatial komponent, og rumlig analyse er kernen i Smart City.
Arkitektureret som de andre komponenter, cuSpatial er et C ++ - bibliotek bygget på CUDA-primitiver og Thrust-vektorbehandlingsbiblioteket ved hjælp af cuDF til dataudveksling. Forbrugere af C ++ - biblioteket kan læse punkt-, polyline- og polygondata ved hjælp af en C ++ -læser. Python-brugere har det bedre med at bruge eksisterende Python-pakker som Shapely eller Fiona til at udfylde et NumPy-array og derefter bruge cuSpatial Python API eller konvertere til cuDF-datarammer.
cuxfilter til datavisualisering
Visualisering af data er grundlæggende, både inden for analyse-workflowet og til præsentation eller rapportering af resultater. Men for al den magi, som GPU'er kan arbejde på selve dataene, er det ikke en triviel opgave at få disse data ud til en browser. cuxfilter, inspireret af JavaScript-biblioteket Crossfilter, sigter mod at bygge bro over dette hul ved at give en stak, der gør det muligt for tredjepartsvisualiseringsbiblioteker at vise data i cuDF-dataframes.
Der har været et par iterationer af cuxfilter, da teamet sorterer de bedste arkitektur og stikmønstre. Den seneste iteration udnytter Jupyter-notesbøger, Bokeh-server og PyViz-paneler, mens integrationseksperimenter inkluderer projekter fra Uber, Falcon og PyDeck. Denne komponent er endnu ikke helt klar til prime time, men er beregnet til frigivelse i Rapids 0.13. Der er mange bevægelige dele, og jeg fik ikke eksperimentere med det første hånd, men hvis det lever op til sit løfte, vil dette være en god tilføjelse til Rapids-værktøjssættet.
Skaler op og ud med Dask
Dask distribueres opgaveplanlægning til Python og spiller en lignende rolle for Python, som Apache Spark spiller for Scala. Dask-cuDF er et bibliotek, der leverer partitionerede, GPU-understøttede datarammer. Dask-cuDF fungerer godt, når du planlægger at bruge cuML, eller når du indlæser et datasæt, der er større end GPU-hukommelse eller er spredt over flere filer.
Som et Spark RDD (Resilient Distribueret datasæt) opfører Dask-cuDF-distribueret dataframe sig mest som en lokal, så du kan eksperimentere med din lokale maskine og flytte til en distribueret model, når du skal skalere op. Dask-cuML giver cuML multi-node-funktioner, hvilket gør det til en god mulighed, når du ikke har budgettet til en DGX-arbejdsstation.
