Interview med Nvidia softwarechef Kari Briski

Interview med Nvidia softwarechef Kari Briski

Tidsstempel: 26. marts 2024 kl. 3
Interview med Nvidia-softwarechef Kari Briski PlatoBlockchain Data Intelligence. Lodret søgning. Ai.

Interview Nvidias GPU-teknologikonference sluttede i sidste uge, og bragte bud om virksomhedens Blackwell-chips og AI's meget ballade vidundere med al den dyrt købte GPU-hardware, der indebærer.

Sådan er buzzen omkring virksomheden, at aktiekursen flirter med rekordhøjder, baseret på forestillingen om, at mange kreative bestræbelser kan gøres hurtigere, hvis ikke bedre, med den automatisering, der er muliggjort af maskinlæringsmodeller.

Det bliver stadig testet på markedet.

George Santayana en gang skrev: "De, der ikke kan huske fortiden, er dømt til at gentage den." Det er en sætning, der ofte gentages. Alligevel har erindring om tidligere ting ikke rigtigt adskilt AI-modeller. De kan huske fortiden, men de er stadig dømt til at gentage den efter behov, til tider forkert.

Alligevel sværger mange til almægtig AI, især dem, der sælger AI-hardware eller cloud-tjenester. Det satser blandt andre Nvidia stort på. Så Registret aflagde et kort besøg på GPU-konferencen for at se, hvad balladen gik ud på. Det handlede bestemt ikke om citronbarerne, der blev serveret i udstillingshallen i torsdags, hvoraf mange afsluttede deres første offentlige tilbud ufærdige i udstillingsgulvsspande.

Langt mere engagerende var en samtale Registret haft med Kari Briski, vicepræsident for produktstyring for AI og HPC softwareudviklingssæt hos Nvidia. Hun står i spidsen for softwareproduktstyring for virksomhedens fundamentmodeller, biblioteker, SDK'er og nu mikrotjenester, der beskæftiger sig med træning og inferens, som den nyligt annoncerede Hej M mikrotjenester og de bedre etablerede nemo implementeringsramme.

Registret: Hvordan vil virksomhederne forbruge disse mikrotjenester – i skyen, på stedet?

Briski: Det er faktisk det smukke ved, hvorfor vi byggede NIM'erne. Det er lidt sjovt at sige "NIM'erne." Men vi startede denne rejse for længe siden. Vi har arbejdet med inferens, siden jeg startede – jeg tror, ​​det var TensorRT 1.0, da jeg startede i 2016.

I årenes løb har vi udvidet vores inferensstabel, lært mere om alle forskellige slags arbejdsbyrder, startende med computersyn og dybe anbefalingssystemer og tale, automatisk talegenkendelse og talesyntese og nu store sprogmodeller. Det har været en virkelig udviklerfokuseret stak. Og nu hvor virksomheder [har set] OpenAI og ChatGPT, forstår de behovet for at have disse store sprogmodeller kørende ved siden af ​​deres virksomhedsdata eller i deres virksomhedsapplikationer.

Den gennemsnitlige cloud-tjenesteudbyder, for deres administrerede tjenester, har haft hundredvis af ingeniører, der arbejder med inferens, optimeringsteknikker. Det kan virksomhederne ikke. De skal have tid til værdi med det samme. Det er derfor, vi indkapslede alt, hvad vi har lært gennem årene med TensorRT, store sprogmodeller, vores Triton Inference Server, standard API og sundhedstjek. [Ideen er at være] i stand til at indkapsle alt det, så du kan komme fra nul til et stort sprogmodelslutpunkt på under fem minutter.

[Med hensyn til on-prem versus cloud datacenter] er mange af vores kunder hybrid cloud. De har foretrukket computer. Så i stedet for at sende dataene væk til en administreret tjeneste, kan de køre mikrotjenesten tæt på deres data, og de kan køre den, hvor de vil.

Registret: Hvordan ser Nvidias softwarestak til AI ud med hensyn til programmeringssprog? Er det stadig stort set CUDA, Python, C og C++? Leder du andre steder efter større hastighed og effektivitet?

Briski: Vi udforsker altid, hvor end udviklere bruger. Det har altid været vores nøgle. Så lige siden jeg startede hos Nvidia, har jeg arbejdet på accelererede matematikbiblioteker. Først skulle du programmere i CUDA for at få parallelitet. Og så havde vi C API'er. Og vi havde en Python API. Så det handler om at tage platformen, hvor end udviklerne er. Lige nu vil udviklere bare ramme et virkelig simpelt API-endepunkt, som med en curl-kommando eller en Python-kommando eller noget lignende. Så det skal være super simpelt, for det er sådan set der, vi møder udviklerne i dag.

Registret: CUDA spiller naturligvis en stor rolle i at gøre GPU-beregningen effektiv. Hvad gør Nvidia for at fremme CUDA?

Briski: CUDA er grundlaget for alle vores GPU'er. Det er en CUDA-aktiveret, CUDA-programmerbar GPU. For nogle år siden kaldte vi det CUDA-X, fordi du havde disse domænespecifikke sprog. Så hvis du har en medicinsk billeddiagnostisk [applikation], har du cuCIM. Hvis du har automatisk talegenkendelse, har du en CUDA accelereret strålesøgningsdekoder for enden af ​​den. Og så der er alle disse specifikke ting for hver anden type arbejdsbyrde, som er blevet fremskyndet af CUDA. Vi har opbygget alle disse specialiserede biblioteker gennem årene som cuDF , cuML, og cu-this-and-that. Alle disse CUDA-biblioteker er grundlaget for det, vi har bygget gennem årene, og nu bygger vi på en måde oven på det.

Registret: Hvordan ser Nvidia på omkostningsovervejelser i forhold til den måde, det designer software og hardware på? Med noget som Nvidia AI Enterprise er det $4,500 pr. GPU hvert år, hvilket er betydeligt.

Briski: For det første, for mindre virksomheder har vi altid Inception program. Vi arbejder altid med kunder – en gratis 90-dages prøveperiode, er det virkelig værdifuldt for dig? Er det virkelig det værd? Så for at reducere dine omkostninger, når du køber ind i det, optimerer vi altid vores software. Så hvis du købte $4,500 pr. GPU pr. år pr. licens, og du kører på en A100, og du kører på en H100 i morgen, er det den samme pris - dine omkostninger er faldet [i forhold til din gennemstrømning]. Så vi bygger altid disse optimeringer og de samlede ejeromkostninger og ydeevne tilbage i softwaren.

Når vi tænker på både træning og inferens, tager træningen lidt mere, men vi har disse autokonfiguratorer til at kunne sige: "Hvor meget data har du? Hvor meget computer har du brug for? Hvor lang tid vil du have, at det skal tage?" Så du kan have et mindre fodaftryk af beregning, men det kan bare tage længere tid at træne din model ... Vil du træne den om en uge? Eller vil du gerne træne det på en dag? Og så du kan lave disse afvejninger.

Registret: Med hensyn til aktuelle problemer, er der noget bestemt, du gerne vil løse, eller er der en teknisk udfordring, du gerne vil overvinde?

Briski: Lige nu er det begivenhedsdrevet RAG'er [som er en måde at udvide AI-modeller med data hentet fra en ekstern kilde]. Mange virksomheder tænker bare på den klassiske opfordring til at generere et svar. Men egentlig, det, vi ønsker at gøre, er at [kæde] alle disse genfindingsforstærkede generative systemer sammen. For hvis du tænker på dig selv og en opgave, du måske gerne vil have løst: "Åh, jeg må gå og tale med databaseteamet. Og det databasehold skal tale med Tableau-holdet. De skal lave mig et dashboard,” og alle disse ting skal ske, før du rent faktisk kan fuldføre opgaven. Og så er det en slags begivenhedsdrevet RAG. Jeg vil ikke sige, at RAG'er taler med RAG'er, men det er i bund og grund det – agenter, der tager af sted og udfører en masse arbejde og vender tilbage. Og det er vi på nippet til. Så jeg tror, ​​at det er noget, jeg er virkelig begejstret for at se i 2024.

Registret: Dogfooder Nvidia sin egen AI? Har du fundet AI nyttig internt?

Briski: Faktisk gik vi afsted, og sidste år, siden 2023 var udforskningsåret, var der 150 hold i Nvidia, som jeg fandt - der kunne have været flere - og vi prøvede at sige, hvordan bruger du vores værktøjer, hvilken slags af use cases, og vi begyndte at kombinere alle erfaringerne, ligesom tusinde blomster, der blomstrede, og vi kombinerede ligesom alle deres erfaringer til bedste praksis i én repo. Det er faktisk det, vi udgav som det, vi kalder Generative AI-eksempler på GitHub, fordi vi bare ville have alle de bedste praksisser på ét sted.

Det var sådan set det, vi gjorde strukturelt. Men som et eksplicit eksempel, tror jeg, vi skrev dette virkelig gode papir kaldet ChipNeMo, og det handler faktisk om vores EDA, VLSI designteam, og hvordan de tog fundamentmodellen og trænede den på vores proprietære data. Vi har vores egne kodningssprog til VLSI. Så de kodede copiloter [modeller til generering af åben kildekode] for at være i stand til at generere vores proprietære sprog og for at hjælpe produktiviteten hos nye ingeniører, der kom til, som ikke helt kender vores VLSI-designchip-skrivekode.

Og det har givet genlyd hos enhver kunde. Så hvis du taler med SAP, har de ABAP (Advanced Business Application Programming), som er som en proprietær SQL til deres database. Og jeg talte med tre andre kunder, der havde forskellige proprietære sprog – selv SQL har hundredvis af dialekter. Så at være i stand til at lave kodegenerering er ikke en use case, der umiddelbart kan løses af RAG. Ja, RAG hjælper med at hente dokumentation og nogle kodestykker, men medmindre den er trænet til at generere tokens på det sprog, kan den ikke bare lave kode.

Registret: Når du ser på store sprogmodeller og den måde, de bliver kædet sammen med applikationer, tænker du så på den latens, der kan indføres, og hvordan man håndterer det? Er der tidspunkter, hvor blot hårdkodning af et beslutningstræ ser ud til at give mere mening?

Briski: Du har ret, når du stiller et bestemt spørgsmål, eller prompt, kan der være, bare for et spørgsmål, kan der være fem eller syv modeller allerede startet, så du kan få hurtig omskrivning og rækværk og retriever og omrangering og så generatoren. Derfor er NIM så vigtigt, fordi vi har optimeret til latency.

Det er også derfor, vi tilbyder forskellige versioner af fundamentmodellerne, fordi du måske har en SLM, en lille sprogmodel, der er lidt bedre til et bestemt sæt opgaver, og så vil du have den større model for mere nøjagtighed til sidst. Men at sammenkæde det hele, så det passer ind i dit latensvindue, er et problem, som vi har løst gennem årene for mange hyperskalaer eller administrerede tjenester. De har disse latency-vinduer og mange gange, når du stiller et spørgsmål eller laver en søgning, går de faktisk ud og samler spørgsmålet flere gange. Så de har en masse løbsbetingelser med "hvad er mit latensvindue for hver lille del af det samlede svar?" Så ja, det kigger vi altid på.

Til din pointe om hardcoding, jeg har lige talt med en kunde om det i dag. Vi er langt ud over hardcoding ... Du kan bruge en dialog manager og have hvis-så-andet. [Men] at administrere de tusindvis af regler er virkelig, virkelig umuligt. Og derfor kan vi godt lide ting som autoværn, for autoværn repræsenterer en slags erstatning for en klassisk dialogmanager. I stedet for at sige: "Tal ikke om baseball, tal ikke om softball, tal ikke om fodbold," og opremser dem, kan du bare sige: "Snak ikke om sport." Og så ved LLM, hvad en sport er. Tidsbesparelsen og at kunne administrere den kode senere er så meget bedre. ®

Tidsstempel:

Mere fra Registret