Haastattelu Nvidian ohjelmistojohtajan Kari Briskin kanssa

Haastattelu Nvidian ohjelmistojohtajan Kari Briskin kanssa

Aikaleima: 26. maaliskuuta 2024 3
Haastattelu Nvidia-ohjelmiston johtajan Kari Briskin PlatoBlockchain Data Intelligencen kanssa. Pystysuuntainen haku. Ai.

Haastatella Nvidian GPU-teknologiakonferenssi päättyi viime viikolla, ja se toi puheen yrityksen Blackwell-siruista ja AI-ihmeistä sekä kaikista kalliisti ostetuista GPU-laitteistoista.

Yrityksen ympärillä vallitsee sellainen kuhina, että sen osakekurssi flirttailee ennätyskorkeuksien kanssa perustuen käsitykseen, että monia luovia pyrkimyksiä voidaan tehdä nopeammin ellei paremmin koneoppimismallien mahdollistaman automaation avulla.

Sitä testataan edelleen markkinoilla.

George Santayana kerran kirjoitti: "Ne, jotka eivät voi muistaa menneisyyttä, on tuomittu toistamaan sitä." Se on usein toistettu lause. Silti menneiden asioiden muistaminen ei todellakaan ole erottanut tekoälymalleja muista. He voivat muistaa menneisyyden, mutta silti heidät tuomitaan toistamaan sitä pyydettäessä, toisinaan väärin.

Silti monet vannovat kaikkivaltiaan tekoälyyn, erityisesti ne, jotka myyvät tekoälylaitteita tai pilvipalveluita. Muun muassa Nvidia panostaa siihen voimakkaasti. Niin Rekisteri teki lyhyen vierailun GPU-konferenssiin nähdäkseen, mistä meteli johtuu. Kyse ei todellakaan ollut torstaina näyttelyhallissa tarjoiltuista sitruunapatukkaista, joista monet päättivät julkisen tarjouksensa keskeneräisenä näyttelytiloissa.

Paljon kiinnostavampi oli keskustelu Rekisteri oli Nvidian tekoäly- ja HPC-ohjelmistokehityssarjojen tuotehallinnan varatoimitusjohtajan Kari Briskin kanssa. Hän johtaa ohjelmistotuotteiden hallintaa yrityksen perusmalleille, kirjastoille, SDK:ille ja nyt mikropalveluille, jotka käsittelevät koulutusta ja päätelmiä, kuten juuri julkistettu. HIM mikropalvelut ja paremmin vakiintuneet nemo käyttöönoton puitteet.

Rekisteri: Miten yritykset aikovat kuluttaa näitä mikropalveluita – pilvessä, tiloissa?

Briski: Se on itse asiassa se kauneus, miksi rakensimme NIM:t. On jotenkin hassua sanoa "NIMit". Mutta aloitimme tämän matkan kauan sitten. Olemme työskennelleet päätelmien parissa alusta asti – mielestäni se oli TensorRT 1.0, kun aloitin vuoden 2016.

Olemme vuosien varrella kasvattaneet päättelypinoamme ja oppineet lisää kaikista erilaisista työkuormista, alkaen tietokonenäöstä ja syväsuositusjärjestelmistä ja puheesta, automaattisesta puheentunnistuksesta ja puhesynteesistä ja nyt suurista kielimalleista. Se on ollut todella kehittäjäkeskeinen pino. Ja nyt, kun yritykset [näkevät] OpenAI:n ja ChatGPT:n, ne ymmärtävät tarpeen, että nämä suuret kielimallit toimivat yritystietojensa vieressä tai yrityssovelluksissaan.

Keskimääräinen pilvipalveluntarjoaja on käyttänyt satoja insinöörejä, jotka työskentelevät johtopäätösten ja optimointitekniikoiden parissa. Yritykset eivät voi tehdä sitä. Heidän on saatava arvon saavuttamiseen tarvittava aika heti. Siksi kiteytimme kaiken, mitä olemme oppineet vuosien varrella TensorRT:n, suurten kielimallien, Triton Inference Serverin, standardin API:n ja terveystarkastusten avulla. [Ajatuksena on] kyetä kapseloimaan tämä kaikki, jotta pääset nollasta suureen kielimallin päätepisteeseen alle viidessä minuutissa.

[Koskien on-prem vs. pilvipalvelinkeskusta], monet asiakkaistamme ovat hybridipilviä. He ovat suosineet laskemista. Joten sen sijaan, että lähettäisivät tiedot hallittuun palveluun, he voivat käyttää mikropalvelua lähellä tietojaan ja käyttää sitä missä tahansa.

Rekisteri: Miltä Nvidian AI-ohjelmistopino näyttää ohjelmointikielten suhteen? Onko se edelleen suurelta osin CUDA, Python, C ja C++? Etsitkö muualta suurempaa nopeutta ja tehokkuutta?

Briski: Tutkimme jatkuvasti, missä kehittäjät käyttävät. Se on aina ollut avaimemme. Joten siitä lähtien, kun aloitin Nvidiassa, olen työskennellyt nopeutetun matematiikan kirjastojen parissa. Ensin piti ohjelmoida CUDA:lla saadaksesi yhdensuuntaisuuden. Ja sitten meillä oli C API:t. Ja meillä oli Python API. Kyse on siis alustan viemisestä sinne, missä kehittäjät ovat. Tällä hetkellä kehittäjät haluavat vain osua todella yksinkertaiseen API-päätepisteeseen, kuten curl-komennolla tai Python-komennolla tai vastaavalla. Joten sen on oltava erittäin yksinkertaista, koska siellä tapaamme kehittäjät tänään.

Rekisteri: CUDAlla on ilmeisesti valtava rooli GPU-laskennan tehostamisessa. Mitä Nvidia tekee edistääkseen CUDAa?

Briski: CUDA on kaikkien grafiikkasuorittimiemme perusta. Se on CUDA-yhteensopiva, CUDA-ohjelmoitava GPU. Muutama vuosi sitten kutsuimme sitä CUDA-X:ksi, koska sinulla oli nämä verkkotunnuskohtaiset kielet. Joten jos sinulla on lääketieteellinen kuvantaminen [sovellus], sinulla on cuCIM. Jos sinulla on automaattinen puheentunnistus, sen lopussa on CUDA-kiihdytetty säteenhakudekooderi. Ja niin siellä on kaikki nämä erityiset asiat jokaiseen työtaakkaan, joita CUDA on nopeuttanut. Olemme rakentaneet kaikkia näitä erikoiskirjastoja vuosien varrella, kuten cuDF ja cuML, ja cu-this-and-th. Kaikki nämä CUDA-kirjastot ovat perusta sille, mitä olemme rakentaneet vuosien varrella, ja nyt rakennamme sen päälle.

Rekisteri: Miten Nvidia suhtautuu kustannusnäkökohtiin suunniteltaessa ohjelmistoaan ja laitteistoaan? Nvidia AI Enterprisen kaltaisella tavalla se on 4,500 XNUMX dollaria GPU:ta kohti vuodessa, mikä on huomattavaa.

Briski: Ensinnäkin pienemmille yrityksille, meillä on aina Alku ohjelmoida. Työskentelemme jatkuvasti asiakkaiden kanssa – ilmainen 90 päivän kokeilu, onko se todella arvokasta sinulle? Onko se todella sen arvoista? Tämän jälkeen optimoimme ohjelmistomme aina, jotta voit vähentää kustannuksiasi ostaessasi sitä. Joten jos ostat 4,500 100 dollaria GPU:ta kohti vuodessa per lisenssi ja käytät A100:aa ja käytät huomenna HXNUMX:aa, hinta on sama – kustannukset ovat laskeneet [suhteessa suoritustehoon]. Joten rakennamme aina nämä optimoinnit ja kokonaiskustannukset sekä suorituskyvyn takaisin ohjelmistoon.

Kun ajattelemme sekä koulutusta että päätelmiä, koulutus kestää hieman enemmän, mutta meillä on nämä automaattiset konfiguraattorit, jotta voimme sanoa: "Kuinka paljon tietoa sinulla on? Kuinka paljon laskentaa tarvitset? Kuinka kauan haluat sen kestävän?" Joten sinulla voi olla pienempi laskennallinen jalanjälki, mutta mallisi kouluttaminen voi kestää kauemmin… Haluatko harjoitella sen viikossa? Vai haluaisitko harjoitella sitä päivässä? Ja niin voit tehdä kompromisseja.

Rekisteri: Mitä tulee nykyisiin ongelmiin, onko jotain erityistä, jonka haluaisit ratkaista, vai onko jokin tekninen haaste, jonka haluaisit voittaa?

Briski: Tällä hetkellä se on tapahtumalähtöistä Lumput [joka on tapa täydentää tekoälymalleja ulkoisesta lähteestä haetuilla tiedoilla]. Monet yritykset ajattelevat vain klassista vastausta. Mutta todella, se, mitä haluamme tehdä, on [ketjuttaa] kaikki nämä haulla täydennetyt generatiiviset järjestelmät yhdessä. Koska jos ajattelet sinua ja tehtävää, jonka saatat haluta tehdä: "Voi, minun täytyy mennä puhumaan tietokantatiimille. Ja sen tietokantaryhmän on mentävä puhumaan Tableau-tiimille. Heidän täytyy tehdä minusta kojelauta”, ja kaikkien näiden asioiden on tapahduttava ennen kuin voit suorittaa tehtävän. Joten se on tavallaan tapahtumavetoinen RAG. En sanoisi, että RAG:t keskustelevat RAG:iden kanssa, mutta se on periaatteessa sitä – agentit lähtevät liikkeelle ja tekevät paljon työtä ja tulevat takaisin. Ja olemme sen kynnyksellä. Joten luulen, että olen todella innoissani nähdessäni sen vuonna 2024.

Rekisteri: Onko Nvidia dogfoodista omaa tekoälyään? Oletko kokenut tekoälyn hyödylliseksi sisäisesti?

Briski: Itse asiassa lähdimme ja viime vuonna, koska vuosi 2023 oli tutkimusten vuosi, löysin Nvidiassa 150 tiimiä – niitä olisi voinut olla enemmänkin – ja yritimme sanoa, miten käytät työkalujamme, millaisia käyttötapauksia ja aloimme yhdistää kaikki oppimiset, ikään kuin tuhannen kukan kukkimisesta, ja tavallaan yhdistämme kaikki heidän oppimisensa parhaiksi käytännöiksi yhdeksi repoksi. Se on itse asiassa se, mitä me julkaisimme Esimerkkejä generatiivisista tekoälyistä GitHubissa, koska halusimme vain saada kaikki parhaat käytännöt yhteen paikkaan.

Näin teimme rakenteellisesti. Mutta selkeänä esimerkkinä, luulen, että kirjoitimme tämän todella hienon paperin nimeltä ChipNeMo, ja itse asiassa kyse on EDA:n, VLSI:n suunnittelutiimistämme ja siitä, kuinka he ottivat perustan mallin ja kouluttivat sen omistamamme datamme perusteella. Meillä on omat koodauskielet VLSI:lle. Joten he koodasivat copilotteja [avoimen lähdekoodin sukupolven mallit] pystyäkseen luomaan omaa kieltämme ja auttamaan uusien insinöörien tuottavuutta, jotka eivät täysin tiedä VLSI-suunnittelupiirin kirjoituskoodiamme.

Ja se on resonoinut jokaisen asiakkaan keskuudessa. Joten jos puhut SAP:lle, heillä on ABAP (Advanced Business Application Programming), joka on kuin oma SQL heidän tietokannassaan. Ja puhuin kolmen muun asiakkaan kanssa, joilla oli eri kielet – jopa SQL:ssä on kuin satoja murteita. Joten koodin luominen ei ole käyttötapaus, jonka RAG ratkaisee välittömästi. Kyllä, RAG auttaa hakemaan dokumentaatiota ja joitakin koodinpätkiä, mutta ellei sitä ole koulutettu luomaan tunnuksia kyseisellä kielellä, se ei voi vain muodostaa koodia.

Rekisteri: Kun tarkastelet suuria kielimalleja ja tapaa, jolla ne ketjutetaan yhteen sovellusten kanssa, mietitkö mahdollisesti aiheuttamaa latenssia ja kuinka käsitellä sitä? Onko joskus aikoja, jolloin päätöspuun pelkkä kovakoodaus tuntuu järkevämmältä?

Briski: Olet oikeassa, kun kysyt tietyn kysymyksen tai kehotteen, voi olla, jopa yhden kysymyksen kohdalla, viisi tai seitsemän mallia voi olla jo aloitettu, jotta voit saada nopean uudelleenkirjoituksen ja suojakaiteet, noutajan ja uudelleen sijoituksen ja sitten generaattori. Siksi NIM on niin tärkeä, koska olemme optimoineet latenssin.

Siksi tarjoamme myös erilaisia ​​versioita perusmalleista, koska sinulla saattaa olla SLM, pieni kielimalli, joka on tavallaan parempi tietylle tehtäväryhmälle, ja sitten haluat suuremman mallin lisäämään tarkkuutta lopussa. Mutta sitten tämän kaiken ketjuttaminen viiveikkunaan mahtumiseksi on ongelma, jota olemme ratkaisseet vuosien varrella monien hyperskaalautuvien tai hallittujen palveluiden osalta. Heillä on nämä latenssiikkunat, ja usein, kun kysyt kysymyksen tai teet haun, he itse asiassa lähtevät pois ja käsittelevät kysymyksen useita kertoja. Joten heillä on paljon kilpailuehtoja "mikä on minun latenssiikkunani jokaiselle pienelle osalle kokonaisvastausta?" Joten kyllä, katsomme sitä aina.

Kovakoodaukseen liittyen, puhuin siitä tänään erään asiakkaan kanssa. Olemme paljon pidemmälle kuin kovakoodausta… Voit käyttää dialoginhallintaa ja jos-niin-muuta. [Mutta] tuhansien sääntöjen hallitseminen on todella, todella mahdotonta. Ja siksi pidämme kaiteista, koska suojakaiteet ovat eräänlainen korvaaminen klassiselle dialogin johtajalle. Sen sijaan, että sanoisit: "Älä puhu baseballista, älä puhu softballista, älä puhu jalkapallosta" ja luettele ne, voit sanoa vain: "Älä puhu urheilusta." Ja sitten LLM tietää, mitä urheilu on. Ajansäästö ja koodin hallinta myöhemmin ovat paljon parempia. ®

Aikaleima:

Lisää aiheesta Rekisteri