Intervju Nvidias GPU-teknikkonferens avslutades förra veckan och gav besked om företagets Blackwell-chips och AI:s mycket omtyckta underverk, med all dyrt köpt GPU-hårdvara som innebär.

Sånt är surret runt företaget att aktiekursen flirtar med rekordhöjder, baserat på föreställningen att många kreativa ansträngningar kan göras snabbare om inte bättre med automatiseringen som möjliggörs av maskininlärningsmodeller.

Det testas fortfarande på marknaden.

George Santayana en gång skrev: "De som inte kan minnas det förflutna är dömda att upprepa det." Det är en fras som ofta upprepas. Ändå har minnet av det förflutna inte riktigt särskiljt AI-modeller. De kan minnas det förflutna men de är fortfarande dömda att upprepa det på begäran, ibland felaktigt.

Trots det svär många vid allsmäktig AI, särskilt de som säljer AI-hårdvara eller molntjänster. Det satsar bland andra Nvidia stort på. Så Registret gjorde ett kort besök på GPU-konferensen för att se vad allt väsen handlade om. Det handlade verkligen inte om citronbarerna som serverades i utställningshallen på torsdagen, av vilka många avslutade sitt inledande offentliga erbjudande oavslutat i utställningsgolvskärl.

Mycket mer engagerande var ett samtal Registret haft med Kari Briski, vice vd för produkthantering för AI och HPC mjukvaruutvecklingssatser på Nvidia. Hon leder mjukvaruprodukthantering för företagets grundmodeller, bibliotek, SDK:er och nu mikrotjänster som hanterar utbildning och slutledning, som den nyligen tillkännagivna NIM mikrotjänster och de bättre etablerade nemo implementeringsram.

Registret: Hur kommer företagen att konsumera dessa mikrotjänster – i molnet, på plats?

Briski: Det är faktiskt det fina med varför vi byggde NIM. Det är lite roligt att säga "NIMs." Men vi började den här resan för länge sedan. Vi har arbetat med inferens sedan jag började – jag tror att det var TensorRT 1.0 när jag började 2016.

Under åren har vi utökat vår slutledningsstapel, lärt oss mer om alla olika typer av arbetsbelastning, med början med datorseende och djupa rekommendationssystem och tal, automatisk taligenkänning och talsyntes och nu stora språkmodeller. Det har varit en riktigt utvecklarfokuserad stack. Och nu när företag [har sett] OpenAI och ChatGPT förstår de behovet av att ha dessa stora språkmodeller igång bredvid deras företagsdata eller i deras företagsapplikationer.

Den genomsnittliga molntjänstleverantören, för sina hanterade tjänster, har de haft hundratals ingenjörer som arbetar med slutlednings- och optimeringstekniker. Företag kan inte göra det. De måste få tid till värde direkt. Det är därför vi kapslade in allt vi har lärt oss genom åren med TensorRT, stora språkmodeller, vår Triton Inference Server, standard API och hälsokontroller. [Tanken är att] kunna kapsla in allt så att du kan komma från noll till en stor språkmodellslutpunkt på under fem minuter.

[När det gäller on-prem kontra molndatacenter] är många av våra kunder hybridmoln. De har föredragit beräkning. Så istället för att skicka iväg data till en hanterad tjänst kan de köra mikrotjänsten nära sin data och de kan köra den var de vill.

Registret: Hur ser Nvidias mjukvarustack för AI ut när det gäller programmeringsspråk? Är det fortfarande till stor del CUDA, Python, C och C++? Letar du någon annanstans för högre hastighet och effektivitet?

Briski: Vi utforskar alltid var utvecklare än använder. Det har alltid varit vår nyckel. Så ända sedan jag började på Nvidia har jag arbetat med accelererade matematikbibliotek. Först var man tvungen att programmera i CUDA för att få parallellitet. Och så hade vi C API:er. Och vi hade ett Python API. Så det handlar om att ta plattformen vart utvecklarna än befinner sig. Just nu vill utvecklare bara träffa en riktigt enkel API-slutpunkt, som med ett curl-kommando eller ett Python-kommando eller något liknande. Så det måste vara superenkelt, för det är ungefär där vi möter utvecklarna idag.

Registret: CUDA spelar uppenbarligen en stor roll för att göra GPU-beräkning effektiv. Vad gör Nvidia för att avancera CUDA?

Briski: CUDA är grunden för alla våra GPU:er. Det är en CUDA-aktiverad, CUDA-programmerbar GPU. För några år sedan kallade vi det CUDA-X, eftersom du hade dessa domänspecifika språk. Så om du har en medicinsk bildbehandling [applikation], har du cuCIM. Om du har automatisk taligenkänning har du en CUDA accelererad strålsökningsavkodare i slutet av den. Och så det finns alla dessa specifika saker för alla olika typer av arbetsbelastning som har accelererats av CUDA. Vi har byggt upp alla dessa specialiserade bibliotek under åren som cuDF och cuML, och cu-this-and-that. Alla dessa CUDA-bibliotek är grunden för det vi byggt under åren och nu bygger vi på ett eller annat sätt ovanpå det.

Registret: Hur ser Nvidia på kostnadsöverväganden när det gäller hur det designar sin mjukvara och hårdvara? Med något som Nvidia AI Enterprise är det $4,500 XNUMX per GPU varje år, vilket är avsevärt.

Briski: För det första, för mindre företag har vi alltid Start program. Vi arbetar alltid med kunder – en gratis 90-dagars provperiod, är det verkligen värdefullt för dig? Är det verkligen värt det? Sedan, för att minska dina kostnader när du köper in det, optimerar vi alltid vår programvara. Så om du köpte $4,500 100 per CPU och år och licens, och du kör på en A100 och du kör på en HXNUMX imorgon, är det samma pris – din kostnad har sjunkit [relativt din genomströmning]. Så vi bygger alltid in dessa optimeringar och totala ägandekostnader och prestanda tillbaka i programvaran.

När vi tänker på både träning och slutledning tar utbildningen lite mer, men vi har dessa autokonfiguratorer för att kunna säga, "Hur mycket data har du? Hur mycket beräkning behöver du? Hur lång tid vill du att det ska ta?" Så du kan ha ett mindre fotavtryck av beräkning, men det kan bara ta längre tid att träna din modell ... Vill du träna den på en vecka? Eller vill du träna det på en dag? Och så kan du göra dessa avvägningar.

Registret: När det gäller aktuella problem, är det något speciellt du skulle vilja lösa eller finns det en teknisk utmaning du vill övervinna?

Briski: Just nu är det händelsestyrt RAGS [vilket är ett sätt att utöka AI-modeller med data hämtade från en extern källa]. Många företag tänker bara på den klassiska uppmaningen att generera ett svar. Men egentligen, vad vi vill göra är att [kedja] alla dessa generativa system som har utökats med hämtning tillsammans. För om du tänker på dig och en uppgift som du kanske vill göra: "Åh, jag måste gå och prata med databasteamet. Och det där databasteamet måste gå och prata med Tableau-teamet. De måste göra mig till en instrumentpanel”, och alla dessa saker måste hända innan du faktiskt kan slutföra uppgiften. Och så det är typ den där händelsedrivna RAG-en. Jag skulle inte säga att RAG:er pratar med RAG:er, men det är i huvudsak det – agenter som går iväg och utför mycket arbete och kommer tillbaka. Och vi är på gränsen till det. Så jag tror att det är något jag är väldigt glad över att se 2024.

Registret: Testar Nvidia sin egen AI? Har du funnit AI användbar internt?

Briski: Egentligen gick vi iväg och förra året, eftersom 2023 var utforskningsåret, fanns det 150 team inom Nvidia som jag hittade – det kunde ha varit fler – och vi försökte säga, hur använder du våra verktyg, vilken typ av användningsfall och vi började kombinera alla lärdomar, typ från att tusen blommor blommade, och vi kombinerade typ alla deras lärdomar till bästa praxis i en repo. Det är faktiskt vad vi släppte som vad vi kallar Generativa AI-exempel på GitHub, eftersom vi bara ville ha alla bästa praxis på ett ställe.

Det är ungefär vad vi gjorde strukturellt. Men som ett uttryckligt exempel tror jag att vi skrev detta riktigt bra papper som heter ChipNeMo, och det handlar faktiskt om vårt EDA, VLSI designteam, och hur de tog grundmodellen och de tränade den på vår egen data. Vi har våra egna kodningsspråk för VLSI. Så de kodade copiloter [modeller för generering av öppen källkod] för att kunna generera vårt proprietära språk och för att hjälpa produktiviteten hos nya ingenjörer som kom till som inte riktigt kan vårt VLSI-designchips som skriver kod.

Och det har gett genklang hos varje kund. Så om du pratar med SAP så har de BOP [Backorder Processing], vilket är som en egenutvecklad SQL till deras databas. Och jag pratade med tre andra kunder som hade olika proprietära språk – till och med SQL har hundratals dialekter. Så att kunna generera kod är inte ett användningsfall som omedelbart kan lösas av RAG. Ja, RAG hjälper till att hämta dokumentation och några kodavsnitt, men om den inte är tränad att generera tokens på det språket kan den inte bara skapa kod.

Registret: När du tittar på stora språkmodeller och hur de kedjas ihop med applikationer, tänker du på latensen som kan införa och hur man ska hantera det? Finns det tillfällen då bara hårdkodning av ett beslutsträd verkar vara mer meningsfullt?

Briski: Du har rätt, när du ställer en viss fråga, eller uppmaning, kan det finnas, bara för en fråga, kan det finnas fem eller sju modeller som redan har startat så att du kan få snabb omskrivning och skyddsräcken och retriever och omrangering och sedan generatorn. Det är därför NIM är så viktigt, eftersom vi har optimerat för latens.

Det är också därför vi erbjuder olika versioner av grundmodellerna eftersom du kanske har en SLM, en liten språkmodell som är lite bättre för en viss uppsättning uppgifter, och sedan vill du ha den större modellen för mer precision i slutet. Men sedan är det ett problem som vi har löst under åren för många hyperskala eller hanterade tjänster. De har dessa latensfönster och många gånger när du ställer en fråga eller gör en sökning, går de faktiskt iväg och samlar ut frågan flera gånger. Så de har många tävlingsförhållanden som "vad är mitt latensfönster för varje liten del av det totala svaret?" Så ja, vi tittar alltid på det.

Till din poäng om hårdkodning, jag pratade just med en kund om det idag. Vi är långt bortom hårdkodning ... Du kan använda en dialoghanterare och ha om-då-annat. [Men] att hantera de tusentals reglerna är verkligen, verkligen omöjligt. Och det är därför vi gillar saker som skyddsräcken, eftersom skyddsräcken representerar en sorts ersättning till en klassisk dialogledare. Istället för att säga: "Prata inte om baseboll, prata inte om softball, prata inte om fotboll," och lista dem kan du bara säga, "Prata inte om sport." Och då vet LLM vad en sport är. Tidsbesparingen, och att kunna hantera den koden senare, är så mycket bättre. ®

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://go.theregister.com/feed/www.theregister.com/2024/03/26/nvdiai_kari_briski_interview/