Interview Nvidia's GPU Technology Conference werd vorige week afgesloten en bracht nieuws over de Blackwell-chips van het bedrijf en de veelbesproken wonderen van AI, met alle duur gekochte GPU-hardware die dat met zich meebrengt.

Er heerst zoveel geroezemoes rond het bedrijf dat de aandelenkoers flirt met recordhoogtes, gebaseerd op het idee dat veel creatieve inspanningen sneller, zo niet beter, kunnen worden gedaan met de automatisering die mogelijk wordt gemaakt door machine learning-modellen.

Dat wordt nog getest in de markt.

George Santayana ooit schreef: “Degenen die zich het verleden niet kunnen herinneren, zijn gedoemd het te herhalen.” Het is een zin die vaak herhaald wordt. Toch heeft de herinnering aan dingen uit het verleden AI-modellen niet echt onderscheiden. Ze kunnen zich het verleden herinneren, maar zijn nog steeds veroordeeld om het op verzoek te herhalen, soms ten onrechte.

Toch zweren velen bij almachtige AI, vooral degenen die AI-hardware of clouddiensten verkopen. Onder meer Nvidia zet er flink op in. Zo Het register bracht een kort bezoek aan de GPU-conferentie om te zien waar alle ophef over ging. Het ging zeker niet om de citroenrepen die donderdag in de tentoonstellingshal werden geserveerd, waarvan er vele hun beursintroductie onvoltooid in bakken op de beursvloer beëindigden.

Veel boeiender was een gesprek Het register gehad met Kari Briski, vice-president productmanagement voor AI- en HPC-softwareontwikkelingskits bij Nvidia. Ze leidt het softwareproductbeheer voor de basismodellen, bibliotheken, SDK's en nu microservices van het bedrijf die zich bezighouden met training en gevolgtrekking, zoals de onlangs aangekondigde NIM microservices en de beter gevestigde nemo implementatie raamwerk.

Het register: Hoe gaan bedrijven deze microservices gebruiken – in de cloud, op locatie?

levendig: Dat is eigenlijk het mooie waarom we de NIM's hebben gebouwd. Het is best grappig om 'de NIM's' te zeggen. Maar we zijn deze reis al lang geleden begonnen. We werken al sinds ik begon met inferentie – ik denk dat het TensorRT 1.0 was toen ik in 2016 begon.

In de loop der jaren hebben we onze stapel met gevolgtrekkingen uitgebreid, waarbij we meer hebben geleerd over alle verschillende soorten werklast, te beginnen met computer vision en diepgaande aanbevelingssystemen en spraak, automatische spraakherkenning en spraaksynthese en nu grote taalmodellen. Het is een echt op ontwikkelaars gerichte stapel geweest. En nu bedrijven OpenAI en ChatGPT hebben gezien, begrijpen ze de noodzaak om deze grote taalmodellen naast hun bedrijfsgegevens of in hun bedrijfsapplicaties te laten draaien.

De gemiddelde cloudserviceprovider heeft voor zijn beheerde services honderden technici laten werken aan inferentie- en optimalisatietechnieken. Bedrijven kunnen dat niet. Ze moeten meteen de time-to-value krijgen. Daarom hebben we alles wat we door de jaren heen hebben geleerd, samengevat met TensorRT, grote taalmodellen, onze Triton Inference Server, standaard API en gezondheidscontroles. [Het idee is om] dat allemaal te kunnen inkapselen, zodat je in minder dan vijf minuten van nul naar een groot taalmodel-eindpunt kunt gaan.

[Met betrekking tot on-premise versus cloud datacenter]: veel van onze klanten zijn hybride cloud. Ze hebben de voorkeur gegeven aan computergebruik. Dus in plaats van de gegevens naar een beheerde service te sturen, kunnen ze de microservice dicht bij hun gegevens uitvoeren en deze uitvoeren waar ze maar willen.

Het register: Hoe ziet Nvidia's softwarestack voor AI eruit qua programmeertalen? Is het nog steeds grotendeels CUDA, Python, C en C++? Zoekt u elders meer snelheid en efficiëntie?

levendig: We onderzoeken altijd waar ontwikkelaars gebruik van maken. Dat is altijd onze sleutel geweest. Dus sinds ik bij Nvidia begon, heb ik gewerkt aan versnelde wiskundebibliotheken. Eerst moest je in CUDA programmeren om parallellisme te krijgen. En toen hadden we C API's. En we hadden een Python API. Het gaat er dus om het platform te brengen waar de ontwikkelaars ook zijn. Op dit moment willen ontwikkelaars gewoon een heel eenvoudig API-eindpunt bereiken, zoals met een curl-opdracht of een Python-opdracht of iets dergelijks. Het moet dus supereenvoudig zijn, want dat is de plek waar we vandaag de ontwikkelaars ontmoeten.

Het register: CUDA speelt duidelijk een grote rol bij het effectief maken van GPU-berekeningen. Wat doet Nvidia om CUDA vooruit te helpen?

levendig: CUDA is de basis voor al onze GPU's. Het is een CUDA-compatibele, CUDA-programmeerbare GPU. Een paar jaar geleden noemden we het CUDA-X, omdat je deze domeinspecifieke talen had. Dus als u een medische beeldvormingstoepassing heeft, dan heeft u die ook cuCIM. Als je automatische spraakherkenning hebt, heb je aan het einde een CUDA-decoder voor versneld zoeken naar bundels. En dus zijn er al deze specifieke dingen voor elk ander type werklast die door CUDA zijn versneld. We hebben in de loop der jaren al deze gespecialiseerde bibliotheken opgebouwd cuDF en cuML, en cu-dit-en-dat. Al deze CUDA-bibliotheken vormen de basis van wat we door de jaren heen hebben opgebouwd en nu bouwen we daar een beetje bovenop.

Het register: Hoe kijkt Nvidia naar kostenoverwegingen in termen van de manier waarop het zijn software en hardware ontwerpt? Met zoiets als Nvidia AI Enterprise kost het $ 4,500 per GPU per jaar, wat aanzienlijk is.

levendig: Ten eerste hebben we voor kleinere bedrijven altijd de Inception programma. We werken altijd samen met klanten – een gratis proefperiode van 90 dagen, is dit echt waardevol voor u? Is het echt de moeite waard? Om vervolgens uw kosten te verlagen als u daarin koopt, optimaliseren we onze software altijd. Dus als je $ 4,500 per CPU per jaar per licentie zou kopen, en je draait op een A100, en je draait morgen op een H100, dan is het dezelfde prijs – je kosten zijn gedaald [ten opzichte van je doorvoer]. Daarom bouwen we deze optimalisaties en de totale eigendomskosten en prestaties altijd terug in de software.

Als we aan zowel training als gevolgtrekking denken, kost de training iets meer, maar we hebben deze automatische configurators om te kunnen zeggen: 'Hoeveel gegevens heb je? Hoeveel rekenkracht heb je nodig? Hoe lang wil je dat het duurt?” U kunt dus een kleinere footprint van rekenkracht hebben, maar het kan langer duren om uw model te trainen... Wilt u het binnen een week trainen? Of wil je het graag in één dag trainen? En dus kun je die afwegingen maken.

Het register: Is er, in termen van de huidige problemen, iets specifieks dat u zou willen oplossen of is er een technische uitdaging die u zou willen overwinnen?

levendig: Op dit moment is het gebeurtenisgestuurd RAG's [wat een manier is om AI-modellen uit te breiden met gegevens die zijn opgehaald uit een externe bron]. Veel bedrijven denken alleen maar aan de klassieke prompt om een ​​antwoord te genereren. Maar wat we eigenlijk willen doen, is al deze generatieve systemen met retrieval-augmented aan elkaar koppelen. Want als je aan jezelf denkt, en aan een taak die je misschien gedaan wilt hebben: “Oh, ik moet met het databaseteam gaan praten. En dat databaseteam moet met het Tableau-team gaan praten. Ze moeten een dashboard voor me maken”, en al deze dingen moeten gebeuren voordat je de taak daadwerkelijk kunt voltooien. En dus is het een soort gebeurtenisgestuurde RAG. Ik zou niet zeggen dat RAG's met RAG's praten, maar het is in wezen zo: agenten gaan weg en verrichten veel werk en komen terug. En wij staan ​​aan de vooravond daarvan. Dus ik denk dat dit iets is waar ik erg enthousiast over ben om in 2024 te zien.

Het register: Is Nvidia bezig met het dogfooden van zijn eigen AI? Heeft u AI intern nuttig gevonden?

levendig: Eigenlijk gingen we op pad en vorig jaar, aangezien 2023 het jaar van verkenning was, waren er 150 teams binnen Nvidia die ik vond – er hadden er meer kunnen zijn – en we probeerden te zeggen: hoe gebruik je onze tools, wat voor soort van gebruiksscenario's en we begonnen alle lessen te combineren, een soort van duizend bloeiende bloemen, en we combineerden al hun lessen min of meer tot best practices in één repository. Dat is eigenlijk wat we hebben uitgebracht, zoals we het noemen Generatieve AI-voorbeelden op GitHub, omdat we alle best practices op één plek wilden hebben.

Dat is een beetje wat we structureel hebben gedaan. Maar als expliciet voorbeeld: ik denk dat we dit werkelijk geweldige artikel hebben geschreven, genaamd ChipNeMo, en het gaat eigenlijk allemaal om ons EDA- en VLSI-ontwerpteam, en hoe ze het basismodel hebben overgenomen en het hebben getraind op onze eigen gegevens. We hebben onze eigen codeertalen voor VLSI. Dus waren ze copiloten aan het coderen [modellen voor het genereren van open source-codes] om onze eigen taal te kunnen genereren en om de productiviteit te helpen van nieuwe ingenieurs die opkomen en die onze VLSI-ontwerpchip-schrijfcode niet helemaal kennen.

En dat heeft bij iedere klant weerklank gevonden. Dus als je met SAP praat, hebben ze BOP [Backorder Processing], wat een soort eigen SQL voor hun database is. En ik sprak met drie andere klanten die verschillende eigen talen hadden – zelfs SQL heeft honderden dialecten. Het kunnen genereren van code is dus geen gebruiksscenario dat onmiddellijk door RAG kan worden opgelost. Ja, RAG helpt bij het ophalen van documentatie en enkele codefragmenten, maar tenzij het is getraind om de tokens in die taal te genereren, kan het niet zomaar code verzinnen.

Het register: Als je kijkt naar grote taalmodellen en de manier waarop ze aan applicaties worden gekoppeld, denk je dan na over de latentie die dit met zich mee kan brengen en hoe je daarmee om moet gaan? Zijn er momenten waarop het simpelweg hardcoderen van een beslisboom logischer lijkt?

levendig: Je hebt gelijk, als je een bepaalde vraag of prompt stelt, kunnen er, zelfs voor één vraag, al vijf of zeven modellen van start zijn gegaan, zodat je snel kunt herschrijven en vangrails en retriever en herrangschikking kunt krijgen en dan de generator. Daarom is de NIM zo belangrijk, omdat we hebben geoptimaliseerd voor latentie.

Dat is ook de reden waarom we verschillende versies van de basismodellen aanbieden, omdat je misschien een SLM hebt, een klein taalmodel dat beter is voor een bepaalde reeks taken, en dan wil je uiteindelijk het grotere model voor meer nauwkeurigheid. Maar het aan elkaar koppelen van dat alles zodat het in uw latentievenster past, is een probleem dat we in de loop der jaren voor veel hyperscale of beheerde services hebben opgelost. Ze hebben deze latentievensters en als je een vraag stelt of een zoekopdracht uitvoert, gaan ze er vaak op uit om de vraag meerdere keren uit te werken. Ze hebben dus veel racevoorwaarden van "wat is mijn latentievenster voor elk klein deel van de totale respons?" Dus ja, daar kijken we altijd naar.

Wat betreft uw punt over hardcoding: ik heb daar vandaag met een klant over gesproken. We zijn veel verder dan hardcoding … Je zou een dialoogmanager kunnen gebruiken en als-dan-anders. [Maar] het beheren van de duizenden regels is echt onmogelijk. En daarom houden we van dingen als vangrails, omdat vangrails een soort vervanging vormen voor een klassieke dialoogmanager. In plaats van te zeggen: 'Praat niet over honkbal, praat niet over softbal, praat niet over voetbal', en ze allemaal opsomt, kun je gewoon zeggen: 'Praat niet over sport.' En dan weet de LLM wat een sport is. De tijdsbesparing en het later kunnen beheren van die code is zoveel beter. ®

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://go.theregister.com/feed/www.theregister.com/2024/03/26/nvdiai_kari_briski_interview/