SiFive RISC-V-Kerne für Google-KI-Rechenknoten ausgewählt

RISC-V-Chip-Biz SiFive sagt, dass seine Prozessoren bis zu einem gewissen Grad zur Verwaltung von KI-Arbeitslasten in Google-Rechenzentren verwendet werden.

Laut SiFive ist der fragliche Prozessor seine Intelligenz X280, ein Multicore-RISC-V-Design mit Vektorerweiterungen, optimiert für KI/ML-Anwendungen im Rechenzentrum. In Kombination mit den Matrix Multiplication Units (MXU) aus Googles Tensor Processing Units (TPU), soll dies eine größere Flexibilität für die Programmierung von Workloads für maschinelles Lernen bieten.

Im Wesentlichen führen die Allzweck-RV280-Kerne des X64 im Prozessor Code aus, der das Gerät verwaltet, und speisen maschinelle Lernberechnungen in die MXUs von Google ein, um Jobs abzuschließen. Der X280 enthält auch eine eigene Vektor-Recheneinheit, die Operationen verarbeiten kann, die die Beschleunigereinheiten nicht können.

SiFive und Google waren ein wenig schüchtern, vielleicht aus kommerziellen Gründen, was die genaue Verpackung und Verwendung betrifft, obwohl es für uns so klingt, als hätte Google seine benutzerdefinierten Beschleunigungseinheiten in ein Multi-Core-X280-System-on-Chip platziert, das die Verbindung herstellt Von Google entworfene MXU-Blöcke direkt zum RISC-V-Kernkomplex. Diese Chips werden in den Rechenzentren von Google, laut SiFive in „KI-Rechenhosts“, verwendet, um die Arbeit mit maschinellem Lernen zu beschleunigen.

Wir stellen uns vor, wenn diese in der Produktion eingesetzt werden, übernehmen diese Chips Aufgaben innerhalb von Dienstleistungen. Wir weisen darauf hin, dass Sie diese Hardware nicht direkt bei Google Cloud mieten können, die KI-optimierte virtuelle Maschinen bietet, die auf herkömmlicher x86-, Arm-, TPU- und GPU-Technologie basieren.

Die Details wurden Anfang dieses Monats auf dem AI Hardware Summit im Silicon Valley in einem Vortrag von SiFive-Mitbegründer und Chefarchitekt Krste Asanović und Google TPU-Architekt Cliff Young sowie in a SiFive-Blogbeitrag diese Woche.

Laut SiFive ist aufgefallen, dass einige Kunden nach der Einführung des X280 damit begonnen haben, ihn als Begleitkern neben einem Beschleuniger zu verwenden, um alle Haushalts- und allgemeinen Verarbeitungsaufgaben zu erledigen, für die der Beschleuniger nicht ausgelegt war.

Viele stellten fest, dass für die Verwaltung des Beschleunigers ein voll ausgestatteter Software-Stack erforderlich war, sagt das Chip-Biz, und die Kunden erkannten, dass sie dies mit einem X280-Kernkomplex neben ihrem großen Beschleuniger lösen konnten, wobei die RISC-V-CPU-Kerne die gesamte Wartung übernehmen und Operationscode, führt mathematische Operationen aus, die der große Beschleuniger nicht kann, und bietet verschiedene andere Funktionen. Im Wesentlichen kann das X280 als eine Art Verwaltungsknoten für den Beschleuniger dienen.

Um davon zu profitieren, hat SiFive mit Kunden wie Google zusammengearbeitet, um die so genannte Vector Coprocessor Interface eXtension (VCIX) zu entwickeln, die es Kunden ermöglicht, einen Beschleuniger direkt mit der Vektorregisterdatei des X280 zu verknüpfen, was eine höhere Leistung und mehr Daten bietet Bandbreite.

Laut Asanović besteht der Vorteil darin, dass Kunden ihren eigenen Coprozessor in das RISC-V-Ökosystem einbringen und einen vollständigen Software-Stack und eine Programmierumgebung ausführen können, mit der Möglichkeit, Linux mit vollem virtuellen Speicher und kohärenter Cache-Unterstützung auf einem Chip zu booten, der a Mischung aus Allzweck-CPU-Kernen und Beschleunigungseinheiten.

Aus Sicht von Google wollte es sich auf die Verbesserung seiner Familie von TPU-Technologien konzentrieren und keine Zeit damit verschwenden, einen eigenen Anwendungsprozessor von Grund auf neu zu entwickeln, und daher schien es der richtige Weg zu sein, diese Beschleunigungsfunktionen mit einem vorgefertigten Allzweckprozessor zu kombinieren zu gehen, laut Young.

VCIX klebt die MXUs im Wesentlichen mit geringer Latenz an die RISC-V-Kerne und überspringt die Notwendigkeit, viele Zyklen damit zu verbringen, darauf zu warten, Daten zwischen CPU und Beschleunigungseinheit über Speicher, Cache oder PCIe zu transferieren. Stattdessen wird uns gesagt, dass es nur Dutzende von Zyklen durch den Vektorregisterzugriff sind. Das deutet auch darauf hin, dass sich alles – der RISC-V-CPU-Komplex und die benutzerdefinierten Beschleuniger – alle auf demselben Chip befinden und als System-on-Chip verpackt sind.

Der Anwendungscode läuft auf den Allzweck-RISC-V-Kernen, und alle Arbeiten, die durch die MXU beschleunigt werden können, werden über den VCIX geleitet. Laut Young gibt es neben der Effizienz noch weitere Vorteile dieses Ansatzes. Das Programmiermodell wird vereinfacht, was zu einem einzigen Programm mit verschachtelten Skalar-, Vektor- und Coprozessoranweisungen führt und eine einzige Software-Toolkette ermöglicht, in der Entwickler je nach Wunsch in C/C++ oder Assembler programmieren können.

„Mit SiFive VCIX-basierten Mehrzweckkernen, die mit Google MXUs ‚hybridisiert‘ sind, können Sie eine Maschine bauen, mit der Sie ‚Ihren Kuchen haben und ihn auch essen‘ können, wobei Sie die gesamte Leistung der MXU und die Programmierbarkeit eines Generals voll ausnutzen CPU sowie die Vektorleistung des X280-Prozessors“, sagte Young.

Die Fähigkeit, einen solchen benutzerdefinierten Chip herzustellen, wird wahrscheinlich die Domäne von Hyperscalern wie Google oder solchen mit Nischenanforderungen und tiefen Taschen bleiben, aber es zeigt, was dank der Flexibilität des offenen Ökosystems RISC-V-Modell erreicht werden kann .

Diese Flexibilität und Offenheit scheint auszureichen, um Google – einen langjährigen Befürworter von RISC-V mit RV-Kernen, die in einigen seiner anderen Produkte verwendet werden – dazu zu verleiten, die Upstart-Architektur zu verwenden, anstatt seine benutzerdefinierten Coprozessoren in x86-Chips oder Arm zu stecken -lizenzierte Designs. ®

PS: Denken Sie daran, als Google war Toying mit der Verwendung der POWER-CPU-Architektur in seinen Rechenzentren?