Intervju Nvidias GPU-teknologikonferanse ble avsluttet i forrige uke, og ga beskjed om selskapets Blackwell-brikker og AIs mye ballyhoote underverker, med all den dyrt kjøpte GPU-maskinvaren som innebærer.

Slik er buzz rundt selskapet at aksjekursen flørter med rekordhøye nivåer, basert på forestillingen om at mange kreative bestrebelser kan gjøres raskere om ikke bedre med automatiseringen aktivert av maskinlæringsmodeller.

Det testes fortsatt i markedet.

George Santayana en gang skrev: "De som ikke kan huske fortiden er dømt til å gjenta den." Det er en setning som ofte gjentas. Likevel har ikke erindring om tidligere ting skilt AI-modeller fra hverandre. De kan huske fortiden, men de er fortsatt dømt til å gjenta den på forespørsel, til tider feil.

Likevel sverger mange til allmektig AI, spesielt de som selger AI-maskinvare eller skytjenester. Det satser blant annet Nvidia stort på. Så Registeret tok et kort besøk på GPU-konferansen for å se hva alt oppstyret handlet om. Det handlet absolutt ikke om sitronbarene som ble servert i utstillingshallen på torsdag, hvorav mange avsluttet sitt første offentlige tilbud uferdig i utstillingsgulvbinger.

Langt mer engasjerende var en samtale Registeret hatt med Kari Briski, visepresident for produktledelse for AI og HPC programvareutviklingssett hos Nvidia. Hun leder programvareproduktadministrasjon for selskapets grunnmodeller, biblioteker, SDK-er og nå mikrotjenester som omhandler opplæring og slutninger, som den nylig annonserte HIM mikrotjenester og de bedre etablerte nemo rammeverk for distribusjon.

Registeret: Hvordan skal selskaper konsumere disse mikrotjenestene – i skyen, i lokalene?

Briski: Det er faktisk det fine med hvorfor vi bygde NIM-ene. Det er litt morsomt å si «NIMs». Men vi startet denne reisen for lenge siden. Vi har jobbet med inferens siden jeg startet – jeg tror det var TensorRT 1.0 da jeg startet i 2016.

I løpet av årene har vi utvidet slutningsstabelen vår, lært mer om alle slags arbeidsbelastninger, og startet med datasyn og dype anbefalingssystemer og tale, automatisk talegjenkjenning og talesyntese og nå store språkmodeller. Det har vært en virkelig utviklerfokusert stabel. Og nå som bedrifter [har sett] OpenAI og ChatGPT, forstår de behovet for å ha disse store språkmodellene kjørende ved siden av bedriftsdataene eller i bedriftsapplikasjonene deres.

Den gjennomsnittlige skytjenesteleverandøren, for sine administrerte tjenester, har hatt hundrevis av ingeniører som jobber med inferens- og optimaliseringsteknikker. Bedrifter kan ikke gjøre det. De trenger å få tid til verdi med en gang. Det er derfor vi kapslet inn alt vi har lært gjennom årene med TensorRT, store språkmodeller, vår Triton Inference Server, standard API og helsesjekker. [Ideen er å kunne] kapsle inn alt dette slik at du kan komme fra null til et stort endepunkt for språkmodeller på under fem minutter.

[Når det gjelder on-prem versus skydatasenter], er mange av kundene våre hybridsky. De har foretrukket databehandling. Så i stedet for å sende dataene til en administrert tjeneste, kan de kjøre mikrotjenesten nær dataene sine, og de kan kjøre den hvor de vil.

Registeret: Hvordan ser Nvidias programvarestabel for AI ut når det gjelder programmeringsspråk? Er det fortsatt stort sett CUDA, Python, C og C++? Ser du andre steder etter større hastighet og effektivitet?

Briski: Vi utforsker alltid hvor enn utviklere bruker. Det har alltid vært nøkkelen vår. Så helt siden jeg begynte på Nvidia har jeg jobbet med akselererte matematikkbiblioteker. Først måtte du programmere i CUDA for å få parallellitet. Og så hadde vi C APIer. Og vi hadde et Python API. Så det handler om å ta plattformen uansett hvor utviklerne er. Akkurat nå vil utviklere bare treffe et veldig enkelt API-endepunkt, som med en curl-kommando eller en Python-kommando eller noe lignende. Så det må være superenkelt, for det er på en måte der vi møter utviklerne i dag.

Registeret: CUDA spiller åpenbart en stor rolle i å gjøre GPU-beregning effektiv. Hva gjør Nvidia for å fremme CUDA?

Briski: CUDA er grunnlaget for alle våre GPUer. Det er en CUDA-aktivert, CUDA-programmerbar GPU. For noen år siden kalte vi det CUDA-X, fordi du hadde disse domenespesifikke språkene. Så hvis du har en medisinsk bildediagnostisk [applikasjon], har du cuCIM. Hvis du har automatisk talegjenkjenning, har du en CUDA-akselerert strålesøke-dekoder på slutten av den. Og så det er alle disse spesifikke tingene for hver annen type arbeidsbelastning som har blitt fremskyndet av CUDA. Vi har bygget opp alle disse spesialiserte bibliotekene gjennom årene som cuDF og cuML, og cu-this-and-that. Alle disse CUDA-bibliotekene er grunnlaget for det vi har bygget opp gjennom årene, og nå bygger vi på en måte på toppen av det.

Registeret: Hvordan ser Nvidia på kostnadshensyn når det gjelder måten de designer programvaren og maskinvaren på? Med noe sånt som Nvidia AI Enterprise, er det $4,500 per GPU hvert år, noe som er betydelig.

Briski: For det første, for mindre selskaper har vi alltid Inception program. Vi jobber alltid med kunder – en gratis 90-dagers prøveperiode, er det virkelig verdifullt for deg? Er det virkelig verdt det? Deretter, for å redusere kostnadene dine når du kjøper inn det, optimaliserer vi alltid programvaren vår. Så hvis du kjøpte $4,500 per CPU per år per lisens, og du kjører på en A100, og du kjører på en H100 i morgen, er det samme pris – kostnadene dine har gått ned [i forhold til gjennomstrømmingen din]. Så vi bygger alltid disse optimaliseringene og de totale eierkostnadene og ytelsen tilbake i programvaren.

Når vi tenker på både trening og inferens, tar treningen litt mer, men vi har disse autokonfiguratorene for å kunne si: «Hvor mye data har du? Hvor mye data trenger du? Hvor lang tid vil du at det skal ta?" Så du kan ha et mindre fotavtrykk av databehandling, men det kan bare ta lengre tid å trene modellen din ... Vil du trene den om en uke? Eller vil du trene den på en dag? Og så kan du gjøre disse avveiningene.

Registeret: Når det gjelder aktuelle problemer, er det noe spesielt du ønsker å løse eller er det en teknisk utfordring du vil overvinne?

Briski: Akkurat nå er det hendelsesdrevet RAG-er [som er en måte å utvide AI-modeller med data hentet fra en ekstern kilde]. Mange bedrifter tenker bare på den klassiske oppfordringen om å generere et svar. Men egentlig, det vi ønsker å gjøre er å [kjede] alle disse gjenfinningsforsterkede generative systemene sammen. For hvis du tenker på deg selv, og en oppgave du kanskje ønsker å få gjort: «Å, jeg må snakke med databaseteamet. Og det databaseteamet må snakke med Tableau-teamet. De må lage meg et dashbord,» og alle disse tingene må skje før du faktisk kan fullføre oppgaven. Og så det er en slags hendelsesdrevet RAG. Jeg vil ikke si at RAG-er snakker med RAG-er, men det er i hovedsak det – agenter som drar og utfører mye arbeid og kommer tilbake. Og vi er på vippen av det. Så jeg tror det er noe jeg er veldig spent på å se i 2024.

Registeret: Tester Nvidia sin egen AI? Har du funnet AI nyttig internt?

Briski: Faktisk, vi gikk av og i fjor, siden 2023 var leteåret, var det 150 team i Nvidia som jeg fant – det kunne ha vært flere – og vi prøvde å si hvordan bruker du verktøyene våre, hva slags av brukstilfeller, og vi begynte å kombinere alle lærdommene, på en måte fra som tusen blomster som blomstrer, og vi kombinerte på en måte all lærdommen deres til beste praksis i en repo. Det er faktisk det vi ga ut som det vi kaller Generative AI-eksempler på GitHub, fordi vi bare ønsket å ha alle de beste praksisene på ett sted.

Det var på en måte det vi gjorde strukturelt. Men som et eksplisitt eksempel tror jeg vi skrev dette virkelig flotte papiret ChipNeMo, og det handler faktisk om vårt EDA, VLSI-designteam, og hvordan de tok grunnlagsmodellen og de trente den på våre proprietære data. Vi har våre egne kodespråk for VLSI. Så de kodet copiloter [modeller for generering av åpen kildekode] for å kunne generere vårt proprietære språk og for å hjelpe produktiviteten til nye ingeniører som ikke helt kan skrivekoden for VLSI-designbrikken vår.

Og det har gitt gjenklang hos hver kunde. Så hvis du snakker med SAP, har de BOP [Backorder Processing], som er som en proprietær SQL til databasen deres. Og jeg snakket med tre andre kunder som hadde forskjellige proprietære språk – til og med SQL har hundrevis av dialekter. Så å kunne gjøre kodegenerering er ikke en brukssak som umiddelbart kan løses av RAG. Ja, RAG hjelper til med å hente dokumentasjon og noen kodebiter, men med mindre den er opplært til å generere tokens på det språket, kan den ikke bare lage kode.

Registeret: Når du ser på store språkmodeller og måten de blir lenket sammen med applikasjoner, tenker du på latensen som kan introdusere og hvordan du skal håndtere det? Er det tider når bare hardkoding av et beslutningstre virker som det ville være mer fornuftig?

Briski: Du har rett, når du stiller et bestemt spørsmål, eller forespørsel, kan det være, bare for ett spørsmål, det kan være fem eller syv modeller allerede startet, slik at du kan få rask omskrivning og rekkverk og retriever og omrangering og deretter generatoren. Det er derfor NIM er så viktig, fordi vi har optimalisert for latens.

Det er også grunnen til at vi tilbyr forskjellige versjoner av grunnmodellene fordi du kanskje har en SLM, en liten språkmodell som er litt bedre for et bestemt sett med oppgaver, og så vil du ha den større modellen for mer nøyaktighet på slutten. Men så er det å lenke alt sammen for å passe inn i ventevinduet ditt et problem som vi har løst opp gjennom årene for mange hyperskalere eller administrerte tjenester. De har disse latensvinduene, og mange ganger når du stiller et spørsmål eller gjør et søk, går de faktisk i gang og samler spørsmålet flere ganger. Så de har mange løpsbetingelser for "hva er latensvinduet mitt for hver liten del av den totale responsen?" Så ja, vi ser alltid på det.

Til poenget ditt om hardkoding, jeg snakket nettopp med en kunde om det i dag. Vi er langt utover hardkoding ... Du kan bruke en dialogleder og ha hvis-så-ellers. [Men] å administrere de tusenvis av regler er virkelig, virkelig umulig. Og det er derfor vi liker ting som rekkverk, fordi rekkverk representerer en slags erstatning for en klassisk dialogleder. I stedet for å si: "Ikke snakk om baseball, ikke snakk om softball, ikke snakk om fotball," og liste dem opp, kan du bare si: "Ikke snakk om sport." Og da vet LLM hva en sport er. Tidsbesparelsen, og å kunne administrere den koden senere, er så mye bedre. ®

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://go.theregister.com/feed/www.theregister.com/2024/03/26/nvdiai_kari_briski_interview/