Zephyrnet-Logo

Interview mit Nvidia-Software-Managerin Kari Briski

Datum:

Interview Die GPU-Technologiekonferenz von Nvidia ging letzte Woche zu Ende und brachte Neuigkeiten über die Blackwell-Chips des Unternehmens und die vielgepriesenen Wunder der KI mit all der teuer gekauften GPU-Hardware, die das mit sich bringt.

Die Stimmung rund um das Unternehmen ist so groß, dass sein Aktienkurs mit Rekordhöhen flirtet, basierend auf der Vorstellung, dass viele kreative Unternehmungen durch die durch maschinelle Lernmodelle ermöglichte Automatisierung schneller, wenn nicht sogar besser gemacht werden können.

Das wird noch auf dem Markt getestet.

Einst George Santayana schrieb: „Wer sich nicht an die Vergangenheit erinnern kann, ist dazu verdammt, sie zu wiederholen.“ Es ist ein Satz, der oft wiederholt wird. Doch die Erinnerung an vergangene Dinge zeichnet KI-Modelle nicht wirklich aus. Sie können sich an die Vergangenheit erinnern, sind aber immer noch dazu verdammt, sie auf Verlangen zu wiederholen, manchmal auch falsch.

Dennoch schwören viele auf die allmächtige KI, insbesondere diejenigen, die KI-Hardware oder Cloud-Dienste verkaufen. Unter anderem Nvidia setzt stark darauf. So Das Register machte einen kurzen Besuch bei der GPU-Konferenz, um zu sehen, worum es bei der ganzen Aufregung ging. Dabei ging es sicherlich nicht um die Zitronenriegel, die am Donnerstag in der Ausstellungshalle serviert wurden und von denen viele ihren Börsengang unvollendet in den Ausstellungsbehältern beendeten.

Weitaus spannender war ein Gespräch Das Register mit Kari Briski, Vizepräsidentin des Produktmanagements für KI- und HPC-Softwareentwicklungskits bei Nvidia. Sie leitet das Softwareproduktmanagement für die Basismodelle, Bibliotheken, SDKs und jetzt auch Microservices des Unternehmens, die sich mit Training und Inferenz befassen, wie das kürzlich angekündigte NIM Microservices und die besser etablierten Nemo Bereitstellungsrahmen.

Das Register: Wie werden Unternehmen diese Microservices nutzen – in der Cloud, vor Ort?

briski: Das ist eigentlich das Schöne daran, warum wir die NIMs gebaut haben. Es ist irgendwie lustig, „die NIMs“ zu sagen. Aber wir haben diese Reise schon vor langer Zeit begonnen. Wir beschäftigen uns mit Inferenz, seit ich angefangen habe – ich glaube, als ich 1.0 angefangen habe, war es TensorRT 2016.

Im Laufe der Jahre haben wir unseren Inferenzstapel erweitert und mehr über jede Art von Arbeitslast gelernt, angefangen bei Computer Vision und Deep-Recommendator-Systemen und Sprache, über automatische Spracherkennung und Sprachsynthese bis hin zu großen Sprachmodellen. Es war ein wirklich entwicklerorientierter Stack. Und da Unternehmen nun OpenAI und ChatGPT gesehen haben, verstehen sie die Notwendigkeit, diese großen Sprachmodelle neben ihren Unternehmensdaten oder in ihren Unternehmensanwendungen laufen zu lassen.

Der durchschnittliche Cloud-Dienstleister beschäftigt für seine verwalteten Dienste Hunderte von Ingenieuren, die an Inferenz- und Optimierungstechniken arbeiten. Das können Unternehmen nicht leisten. Sie müssen die Time-to-Value sofort nutzen können. Deshalb haben wir alles, was wir im Laufe der Jahre gelernt haben, mit TensorRT, großen Sprachmodellen, unserem Triton-Inferenzserver, Standard-API und Gesundheitsprüfungen gekapselt. [Die Idee besteht darin,] in der Lage zu sein, all das zu kapseln, sodass Sie in weniger als fünf Minuten von Null zu einem großen Sprachmodell-Endpunkt gelangen können.

[Im Hinblick auf On-Prem- oder Cloud-Rechenzentren] sind viele unserer Kunden Hybrid-Cloud-Kunden. Sie bevorzugen Computer. Anstatt die Daten also an einen verwalteten Dienst zu senden, können sie den Microservice in der Nähe ihrer Daten ausführen und ihn dort ausführen, wo sie möchten.

Das Register: Wie sieht Nvidias Software-Stack für KI in Bezug auf Programmiersprachen aus? Besteht es immer noch größtenteils aus CUDA, Python, C und C++? Suchen Sie anderswo nach mehr Geschwindigkeit und Effizienz?

briski: Wir erkunden ständig, wo Entwickler es verwenden. Das war schon immer unser Schlüssel. Seitdem ich bei Nvidia angefangen habe, arbeite ich an beschleunigten Mathematikbibliotheken. Zuerst musste man in CUDA programmieren, um Parallelität zu erreichen. Und dann hatten wir C-APIs. Und wir hatten eine Python-API. Es geht also darum, die Plattform dorthin zu bringen, wo die Entwickler sind. Im Moment möchten Entwickler lediglich einen wirklich einfachen API-Endpunkt erreichen, beispielsweise mit einem Curl-Befehl oder einem Python-Befehl oder etwas Ähnlichem. Es muss also super einfach sein, denn dort treffen wir heute die Entwickler.

Das Register: CUDA spielt offensichtlich eine große Rolle dabei, GPU-Berechnungen effektiv zu machen. Was unternimmt Nvidia, um CUDA voranzutreiben?

briski: CUDA ist die Grundlage für alle unsere GPUs. Es handelt sich um eine CUDA-fähige, CUDA-programmierbare GPU. Vor ein paar Jahren nannten wir es CUDA-X, weil es diese domänenspezifischen Sprachen gab. Wenn Sie also eine medizinische Bildgebungsanwendung haben, dann haben Sie diese cuCIM. Wenn Sie über eine automatische Spracherkennung verfügen, verfügen Sie am Ende über einen CUDA-Decoder für die beschleunigte Strahlsuche. Und so gibt es all diese spezifischen Dinge für jede Art von Arbeitslast, die durch CUDA beschleunigt wurden. Wir haben all diese Spezialbibliotheken im Laufe der Jahre aufgebaut cuDF und cuML, und cu-dies-und-das. Alle diese CUDA-Bibliotheken bilden die Grundlage für das, was wir im Laufe der Jahre aufgebaut haben, und jetzt bauen wir sozusagen darauf auf.

Das Register: Wie betrachtet Nvidia Kostenaspekte bei der Gestaltung seiner Software und Hardware? Bei etwas wie Nvidia AI Enterprise sind es 4,500 US-Dollar pro GPU pro Jahr, was beträchtlich ist.

briski: Erstens haben wir für kleinere Unternehmen immer das Beginn Programm. Wir arbeiten ständig mit Kunden zusammen – ist eine kostenlose 90-Tage-Testversion für Sie wirklich wertvoll? Lohnt es sich wirklich? Um Ihre Kosten zu senken, wenn Sie sich dafür entscheiden, optimieren wir unsere Software ständig. Wenn Sie also 4,500 US-Dollar pro CPU, Jahr und Lizenz gekauft haben, auf einem A100 laufen und morgen auf einem H100 laufen, ist der Preis derselbe – Ihre Kosten sind gesunken [relativ zu Ihrem Durchsatz]. Deshalb integrieren wir diese Optimierungen sowie die Gesamtbetriebskosten und die Leistung immer wieder in die Software.

Wenn wir sowohl an Training als auch an Inferenz denken, dauert das Training zwar etwas länger, aber wir haben diese automatischen Konfiguratoren, um sagen zu können: „Wie viele Daten haben Sie?“ Wie viel Rechenleistung benötigen Sie? Wie lange soll es dauern?“ Sie können also einen geringeren Rechenbedarf haben, aber das Trainieren Ihres Modells könnte länger dauern … Möchten Sie es in einer Woche trainieren? Oder möchten Sie es an einem Tag trainieren? Und so können Sie diese Kompromisse eingehen.

Das Register: Gibt es im Hinblick auf aktuelle Probleme etwas Besonderes, das Sie lösen möchten, oder gibt es eine technische Herausforderung, die Sie gerne bewältigen möchten?

briski: Im Moment ist es ereignisgesteuert RAGs [das ist eine Möglichkeit, KI-Modelle mit Daten zu erweitern, die von einer externen Quelle abgerufen werden]. Viele Unternehmen denken nur an die klassische Aufforderung, eine Antwort zu generieren. Aber eigentlich wollen wir alle diese durch Abruf erweiterten generativen Systeme miteinander verketten. Denn wenn Sie an sich selbst und eine Aufgabe denken, die Sie vielleicht erledigen möchten: „Oh, ich muss mit dem Datenbankteam reden.“ Und dieses Datenbankteam muss mit dem Tableau-Team sprechen. Sie müssen mir ein Dashboard erstellen“, und all diese Dinge müssen passieren, bevor Sie die Aufgabe tatsächlich erledigen können. Es handelt sich also um eine Art ereignisgesteuertes RAG. Ich würde nicht sagen, dass RAGs mit RAGs reden, aber im Grunde geht es darum, dass Agenten losziehen, eine Menge Arbeit leisten und wieder zurückkommen. Und wir stehen an der Schwelle dazu. Ich denke, das ist etwas, worauf ich mich im Jahr 2024 wirklich freue.

Das Register: Verfügt Nvidia über seine eigene KI? Fanden Sie KI intern nützlich?

briski: Eigentlich sind wir losgefahren und letztes Jahr, da 2023 das Jahr der Erkundung war, gab es 150 Teams innerhalb von Nvidia, die ich gefunden habe – es hätten mehr sein können – und wir haben versucht zu sagen, wie nutzen Sie unsere Tools, welche Art? von Anwendungsfällen und wir begannen, alle Erkenntnisse zu kombinieren, sozusagen aus tausend blühenden Blumen, und wir haben alle ihre Erkenntnisse zu Best Practices in einem Repo zusammengefasst. Das ist eigentlich das, was wir als das veröffentlicht haben, was wir nennen Beispiele für generative KI auf GitHub, weil wir einfach alle Best Practices an einem Ort haben wollten.

So haben wir es strukturell gemacht. Aber als explizites Beispiel denke ich, dass wir diesen wirklich großartigen Artikel mit dem Titel geschrieben haben ChipNeMo, und eigentlich dreht sich alles um unser EDA- und VLSI-Designteam und darum, wie sie das Basismodell übernommen und es anhand unserer proprietären Daten trainiert haben. Wir haben unsere eigenen Codierungssprachen für VLSI. Sie programmierten also Copiloten [Open-Source-Code-Generierungsmodelle], um unsere proprietäre Sprache generieren zu können und die Produktivität neuer Ingenieure zu steigern, die unseren VLSI-Design-Chip-Schreibcode noch nicht ganz kennen.

Und das hat bei jedem Kunden Anklang gefunden. Wenn Sie also mit SAP sprechen, verfügen sie über BOP (Backorder Processing), das wie ein proprietäres SQL für ihre Datenbank ist. Und ich habe mit drei anderen Kunden gesprochen, die unterschiedliche proprietäre Sprachen hatten – sogar SQL hat Hunderte von Dialekten. Daher ist die Fähigkeit zur Codegenerierung kein Anwendungsfall, der von RAG sofort gelöst werden kann. Ja, RAG hilft beim Abrufen der Dokumentation und einiger Codeausschnitte, aber wenn es nicht darauf trainiert ist, die Token in dieser Sprache zu generieren, kann es nicht einfach Code erstellen.

Das Register: Denken Sie beim Betrachten großer Sprachmodelle und der Art und Weise, wie sie mit Anwendungen verkettet werden, über die möglicherweise auftretende Latenz nach und wie Sie damit umgehen können? Gibt es Zeiten, in denen es sinnvoller erscheint, einen Entscheidungsbaum einfach fest zu codieren?

briski: Sie haben Recht, wenn Sie eine bestimmte Frage oder Eingabeaufforderung stellen, könnte es, auch nur für eine Frage, bereits fünf oder sieben Modelle geben, sodass Sie eine sofortige Neuformulierung und Leitplanken sowie eine Neubewertung und Neubewertung erhalten und dann der Generator. Deshalb ist das NIM so wichtig, weil wir es auf Latenz optimiert haben.

Aus diesem Grund bieten wir auch verschiedene Versionen der Basismodelle an, da Sie möglicherweise ein SLM haben, ein kleines Sprachmodell, das für eine bestimmte Aufgabengruppe besser geeignet ist, und am Ende das größere Modell für mehr Genauigkeit benötigen. Aber dann alles so zu verketten, dass es in Ihr Latenzfenster passt, ist ein Problem, das wir im Laufe der Jahre für viele Hyperscale- oder Managed Services gelöst haben. Sie haben diese Latenzfenster und oft, wenn Sie eine Frage stellen oder eine Suche durchführen, gehen sie tatsächlich los und verteilen die Frage mehrmals. Sie haben also viele Wettlaufbedingungen: „Wie groß ist mein Latenzfenster für jeden kleinen Teil der Gesamtantwort?“ Also ja, wir schauen uns das immer an.

Zu Ihrem Punkt zur Hardcodierung: Ich habe heute gerade mit einem Kunden darüber gesprochen. Wir gehen weit über die Hardcodierung hinaus … Sie könnten einen Dialogmanager verwenden und „Wenn-dann-sonst“ haben. [Aber] die Verwaltung der Tausenden von Regeln ist wirklich, wirklich unmöglich. Und deshalb mögen wir Dinge wie Leitplanken, weil Leitplanken eine Art Ersatz für einen klassischen Dialogmanager darstellen. Anstatt zu sagen: „Sprich nicht über Baseball, sprich nicht über Softball, sprich nicht über Fußball“ und sie aufzulisten, kannst du einfach sagen: „Sprich nicht über Sport.“ Und dann weiß der LLM, was ein Sport ist. Die Zeitersparnis und die spätere Verwaltung des Codes sind viel besser. ®

spot_img

Neueste Intelligenz

spot_img