News RISC-V als Grundlage: Raja Koduris neues Start-up will KI-Grafikkarten neu denken

[PCGH-Redaktion]

Nvidias KI-Dominanz erhält einen neuen Gegner von einem Start-up, dessen Gründer so ziemlich bei jedem Nvidia-Konkurrenten angestellt war: Raja Koduri. Sein "Oxmiq Labs" genanntes Unternehmen setzt dabei auf RISC-V.

Was sagt die PCGH-X-Community zu RISC-V als Grundlage: Raja Koduris neues Start-up will KI-Grafikkarten neu denken

Bitte beachten: Thema dieses Kommentar-Threads ist der Inhalt der Meldung. Kritik und allgemeine Fragen zu Online-Artikeln von PC Games Hardware werden hier gemäß der Forenregeln ohne Nachfrage entfernt, sie sind im Feedback-Thread besser aufgehoben.

 

[empy]

Also RISC-V-Kerne als SPUs? Erst klang es ja etwas wie bei Bolt, aber da soll auf den RISC-V-Kernen ja wohl ein OS laufen.

Diese Kerne basieren auf dem erwähnten RISC-V und ermöglichen native Python-Beschleunigung sowie Kompatibilität mit SIMD/CUDA.

"Kompatibilität mit SIMD" liest sich sehr komisch, weil es eigentlich ein ziemlich grundlegendes Konzept ist.

 

[Horst_Koehler]

@Jusuf_Hatic .... Jim Keller ist eine CPU und keine GPU Legende!

 

[nervnicht]

Intressant Raja Koduris macht also was "Neues" und nutzt Risc-V" ....
...Bolt Preist GPU mit Risc-V Unterstützung an und gilt als Betrug!?!
Ist die Verwendung wirklich so unterschiedlich oder nur die Außenwirkung weil Konduris eher ungenau ist!?!?

 

[PCGH_Torsten]

Also RISC-V-Kerne als SPUs? Erst klang es ja etwas wie bei Bolt, aber da soll auf den RISC-V-Kernen ja wohl ein OS laufen.

"Kompatibilität mit SIMD" liest sich sehr komisch, weil es eigentlich ein ziemlich grundlegendes Konzept ist.

In der ausführlichen Meldung scheint die RISC-V-Komponeten nur eine kleine Ergänzung zu einem Beschleuniger mit proprietärer Architektur zu sein – was auch Sinn macht, das RISC-V für reguläre CPU-Aufgaben entwickelt wurde, nicht mit KI-Schwerpunkt. In Anbetracht der versprochenen, extremen Skalierbarkeit bei gleichzeitiger Dezentralisierung von Aufgaben (Buzzwords dürfen bei Koduri nicht fehlen, also ist von "light transport" bis "in memory computing alles dabei, was Rang, Namen und keine Existenz hat), würde ich vermuten, dass man auch ein paar Einheiten zur Bewertung der Ergebnisse oder Organisation des Rests braucht, und dafür einfach auf bestehende IP zurückgreift. Da RISC-V günstiger als ARM sein soll...

 

[Olstyle]

Da RISC-V günstiger als ARM sein soll...

Billiger ja, günstiger nicht unbedingt. Es entfällt ja der Support-Ansprechpartner und das Tooling ist auch noch lange nicht da wo ARM steht.

Der wirklich Interessante Teil hier ist OXPython. CUDA ist ja immernoch das Haupt-Hindernis um von NV los zu kommen.

 

[empy]

In der ausführlichen Meldung scheint die RISC-V-Komponeten nur eine kleine Ergänzung zu einem Beschleuniger mit proprietärer Architektur zu sein – was auch Sinn macht, das RISC-V für reguläre CPU-Aufgaben entwickelt wurde, nicht mit KI-Schwerpunkt.

Naja, es ist ein Befehlssatz. Man könnte die Architektur so aufbauen, dass es im Endeffekt nur noch Ansteuerungseinheiten für SIMD-Einheiten ohne den ganzen ST-Beschleunigungsaufriss sind. Man müsste eventuell nicht mal alle Befehle implementieren, aber ja, dann könnte man auch eigentlich gleich sein eigenes Ding machen.

Billiger ja, günstiger nicht unbedingt. Es entfällt ja der Support-Ansprechpartner und das Tooling ist auch noch lange nicht da wo ARM steht.

Langfristig halte ich es auf jeden Fall für die bessere Option. Mit ARM kommt man da auch nur vom Regen in die Traufe. Seine Position bei RISC-V frühzeitig auszubauen, könnte sich später auch allgemein extrem lohnen. Ich denke, dass es nur eine Frage der Zeit ist, bis große Teile der IT-Landschaft dahin abwandern.

 

[PCGH_Torsten]

Soweit ich es überblicke, gehen die meisten gezielten KI-Beschleuniger-Architekturen (nicht die GPGPU-Beschleuniger von AMD und Nvidia) in eine Richtung, die letztlich Teile der KI-Strukturen in Hardware umsetzen. Man bildet also Kaskaden von Schaltungen, in denen Eingangswerte aus mehreren Quellen mehrere Stufen von gewichteten Verrechnungen durchlaufen. Das dürfte sich über einen "nehme Wert aus Register A und Wert aus Register B, mache was und schreib das in Register C"-Befehlssatz nur schlecht ansteuern lassen. Ganz abgesehen davon, dass eine RISC-V-Teilimplementation als Vorstufe zu einer Custom-SIMD-Einheit genauso wenig von "RISC-V-Kompatibilität" profitieren könnte, wie seinerzeit Larrabee von der Verwandtschaft mit x86-CPUs.

 

[empy]

Naja, die Register hätten ja dann bis zu 512 Bit. Wenn man darauf dann mit FP8 rechnen kann, kann man so mit einem Aufwasch 64 Berechnungen abhandeln und auch in so ein Kaskadenmodell müssten die Daten ja irgendwie rein und irgendwie wieder raus. Mein letzter Stand, der aber schon etwas älter ist, ist, dass es sehr schwer ist, neuronale Netzwerke in Hardware zu gießen, weil man dazu extrem viele Verbindungen braucht, die in Hardware teuer sind. Laut Wikipedia wird in AI-Prozessoren, bzw. den TPUs, aber viel wert auf Datenrate zum Speicher und kleine Datentypen gelegt, was sich mit der Benutzung von HBM und FP4 deckt. Viel Transfers für Berechnungen, die "nahe" beieinander liegen, wird man auch mit Caches entschärfen können.

Aber in diesem Fall ist die Sache ja relativ klar. "Nano Agents" klingt nicht wie etwas, was einen Großteil des Chips ausmachen wird.

 

[PCGH_Torsten]

Der Trick besteht wohl darin, dass man die Daten des neuronalen Modells möglichst nicht hin und her bewegt, sondern einzelne, winzige Anteile, lokal an einem (ebenfalls winzigen) Rechenknoten belässt und dann nur die zu verarbeitenden Daten von Punkt zu Punkt strömen lässt. Um deren Bewegung kommt man ja sowieso nicht herum. Soweit jedenfalls mein oberflächliches Verständnis der NPU-Konzepte von Intel und, soweit dokumentiert, AMD. Kann aber natürlich sein, dass sich das mit Agenten-basierten KIs schon wieder erledigt hat. Herkömmliches SIMD sehe ich bei KI aber nicht am Start – bei mehreren Schichten Quervernetzung die durchzuführende Operation herauszufinden ist aufwendig, die eigentliche Berechnung dann teilweise trivial. 64 Operanden zu suchen, auf die man in einem Rutsch die gleiche Instruktion anwenden kann, müsste kontraproduktiv sein.

 

[BxBender]

oh neee, ich hab doch nur aus Spaß gesagt, ob der Koduri bei der Zeus seine Finger im Spiel hat mit 10facher Leistung einer 5090, und dann kommt keine 3 Tage später dieser Hammer hier, LOL

PS: der Kerl war echt bei S3? das erklärt den S3 Virge (auf Deutsch Würg gesprochen??? ^^) in den 90ern, der die Leistung gegenüber dem Softwaremodus halbiert hat, hätet ichd as gewusst, hätet ich keine 300 DM hingeblättert, was extrem teuer war und nie gebraucht werden konnte, mein Fehlkauf schlechthin, noch ohne PCGH wohlgemerkt

 

[empy]

Der Trick besteht wohl darin, dass man die Daten des neuronalen Modells möglichst nicht hin und her bewegt, sondern einzelne, winzige Anteile, lokal an einem (ebenfalls winzigen) Rechenknoten belässt und dann nur die zu verarbeitenden Daten von Punkt zu Punkt strömen lässt.

Ja, man sollte dafür sorgen, dass die Caches greifen können. Das ist ein allgemeines Problem des verteilten Rechnens, dass halt nicht jeder Knoten gleich schnell auf alle Daten zugreifen kann. Ich glaube man begegnet dem, indem man die Unteraufgaben in ihrer Größe so wählt, dass sie immer lokal ausgeführt werden können.

Herkömmliches SIMD sehe ich bei KI aber nicht am Start – bei mehreren Schichten Quervernetzung die durchzuführende Operation herauszufinden ist aufwendig, die eigentliche Berechnung dann teilweise trivial. 64 Operanden zu suchen, auf die man in einem Rutsch die gleiche Instruktion anwenden kann, müsste kontraproduktiv sein.

Sind die Inputs und Outputs von neuronalen Netzen nicht Vektoren und die einzelnen Schichten und damit die Verbindungen zwischen den "Neuronen" nicht die Gewichtsmatrizen und das ganze wird dann miteinander multipliziert?

 

[PCGH_Torsten]

Ich glaube, es gibt auch abhängige Verknüpfungen. Könnte man natürlich als mehrdimensionale Matrize mit Co-Faktor bezeichnen – aber gibt es SIMD-Befehlssätze, die etwas von der Art "Multipliziere A mit C wenn B = X oder multipliziere A mit D wenn B = Y | Multipliziere E mit G wenn F = Z oder multipliziere E mit H wenn F != Y | ...." am Block ausführen können. Das ist einfach nicht mehr "Single Instruction".

 

[empy]

Ist halt die Frage, ob das nötig wäre. Da es Gewichtsmatrizen sind, kann ein Gewicht halt auch null sein, dann ist die Verbindung halt nichtexistent oder nicht null, dann hat sie halt die entsprechende Stärke. Ich könnte mir da dann eher vorstellen, dass auf diese Art eventuell Bereiche inaktiv bleiben, die man dann auch nicht weiter berechnen muss und man so Rechenzeit sparen kann. So was heißt in der Regel dann "sparse"-irgendwas. So was lohnt sich aber oft auch schon, wenn man es (deutlich) gröber als eine übliche SIMD-Instruktion ausspart und die Randbereiche eben inklusive der unnötigen Berechnungen durch die Rechenwerke jagt. Umgekehrt könnte eine zu feine Detektierung wieder mehr Rechenarbeit kosten als sie spart.

Aber das ist auch nur, was ich dazu denke. Mein Verständnis von neuronalen Netzen ist halt, dass es keine expliziten, harten Bedingungen gibt, das muss aber nicht stimmen. Es könnte aber auch in dem Fall sein, dass das dann nicht auf einzelne Berechnungen, sondern eher ganze Schichten oder so angewendet wird und dann auch wieder spielend grob genug ist, dass SIMD problemlos angewendet werden kann.