SiFive, l'entreprise de puces RISC-V, affirme que ses processeurs sont utilisés pour gérer dans une certaine mesure les charges de travail de l'IA dans les centres de données de Google.
Selon SiFive, le processeur en question est son Intelligence X280, une conception RISC-V multicœur avec des extensions vectorielles, optimisée pour les applications AI/ML dans le centre de données. Lorsqu'il est combiné avec les unités de multiplication matricielle (MXU) issues des unités de traitement tenseur de Google (TPU), cela est censé offrir une plus grande flexibilité pour la programmation des charges de travail d'apprentissage automatique.
Essentiellement, les cœurs RV280 à usage général du X64 dans le code d'exécution du processeur qui gère l'appareil et alimentent les calculs d'apprentissage automatique dans les MXU de Google selon les besoins pour effectuer les tâches. Le X280 comprend également sa propre unité de calcul vectoriel qui peut gérer des opérations que les unités d'accélérateur ne peuvent pas.
SiFive et Google étaient un peu timides, peut-être pour des raisons commerciales, sur la manière exacte dont cela est emballé et utilisé, bien qu'il nous semble que Google a placé ses unités d'accélération personnalisées dans un système sur puce X280 multicœur, connectant le Le MXU conçu par Google bloque directement le complexe de base RISC-V. Ces puces sont utilisées dans les datacenters de Google, dans des « hôtes de calcul IA » selon SiFive, pour accélérer le travail de machine learning.
Nous imaginons que si elles sont utilisées en production, ces puces gèrent des tâches au sein des services. Nous notons que vous ne pouvez pas louer ce matériel directement sur Google Cloud, qui propose des machines virtuelles optimisées pour l'IA alimentées par les technologies traditionnelles x86, Arm, TPU et GPU.
Les détails ont été divulgués lors du AI Hardware Summit dans la Silicon Valley au début du mois, lors d'une conférence du co-fondateur et architecte en chef de SiFive Krste Asanović et de l'architecte Google TPU Cliff Young, et dans un Article de blog SiFive cette semaine.
Selon SiFive, il a remarqué qu'à la suite de l'introduction du X280, certains clients ont commencé à l'utiliser comme cœur compagnon à côté d'un accélérateur, afin de gérer toutes les tâches d'entretien ménager et de traitement à usage général pour lesquelles l'accélérateur n'était pas conçu.
Beaucoup ont trouvé qu'une pile logicielle complète était nécessaire pour gérer l'accélérateur, selon le secteur des puces, et les clients ont réalisé qu'ils pouvaient résoudre ce problème avec un complexe de cœur X280 à côté de leur grand accélérateur, les cœurs de processeur RISC-V gérant toute la maintenance et code d'opérations, effectuant des opérations mathématiques que le grand accélérateur ne peut pas effectuer et fournissant diverses autres fonctions. Essentiellement, le X280 peut servir de sorte de nœud de gestion pour l'accélérateur.
Pour tirer parti de cela, SiFive a travaillé avec des clients tels que Google pour développer ce qu'il appelle le Vector Coprocessor Interface eXtension (VCIX), qui permet aux clients de lier étroitement un accélérateur directement au fichier de registre vectoriel du X280, offrant des performances accrues et plus de données. bande passante.
Selon Asanović, l'avantage est que les clients peuvent apporter leur propre coprocesseur dans l'écosystème RISC-V et exécuter une pile logicielle complète et un environnement de programmation, avec la possibilité de démarrer Linux avec une mémoire virtuelle complète et une prise en charge cohérente du cache, sur une puce contenant un mélange de cœurs de processeur à usage général et d'unités d'accélération.
Du point de vue de Google, il voulait se concentrer sur l'amélioration de sa famille de technologies TPU, et ne pas perdre de temps à créer son propre processeur d'application à partir de zéro, et donc associer ces fonctions d'accélération avec un processeur à usage général prêt à l'emploi semblait être la bonne façon aller, selon Young.
VCIX colle essentiellement les MXU aux cœurs RISC-V avec une faible latence, évitant ainsi de passer de nombreux cycles à attendre pour faire la navette entre le processeur et l'unité d'accélération via la mémoire, le cache ou le PCIe. Au lieu de cela, nous dit-on, il ne s'agit que de dizaines de cycles d'accès au registre vectoriel. Cela suggère également que tout – le complexe CPU RISC-V et les accélérateurs personnalisés – sont tous sur la même matrice, emballés comme un système sur puce.
Le code d'application s'exécute sur les cœurs RISC-V à usage général, et tout travail pouvant être accéléré par le MXU est transmis via le VCIX. Selon Young, outre l'efficacité, cette approche présente d'autres avantages. Le modèle de programmation est simplifié, ce qui donne un programme unique avec des instructions scalaires, vectorielles et de coprocesseur entrelacées, et permettant une seule chaîne d'outils logiciels où les développeurs peuvent coder en C/C++ ou en assembleur selon leurs préférences.
"Avec les cœurs à usage général basés sur SiFive VCIX" hybrides "avec les MXU de Google, vous pouvez construire une machine qui vous permet" d'avoir votre gâteau et de le manger aussi ", en tirant pleinement parti de toutes les performances du MXU et de la programmabilité d'un général CPU ainsi que les performances vectorielles du processeur X280 », a déclaré Young.
La possibilité de fabriquer une puce personnalisée comme celle-ci restera probablement le domaine des hyperscalers comme Google, ou de ceux qui ont des besoins de niche et des poches profondes, mais cela démontre ce qui peut être réalisé grâce à la flexibilité du modèle RISC-V de l'écosystème ouvert. .
Cette flexibilité et cette ouverture semblent être suffisantes pour inciter Google - un partisan de longue date de RISC-V, avec des cœurs RV utilisés dans certains de ses autres produits - à utiliser l'architecture parvenue au lieu de mettre ses coprocesseurs personnalisés dans des puces x86 ou Arm - dessins sous licence. ®
PS: Rappelez-vous quand Google était jouer avec l'utilisation de l'architecture POWER CPU dans ses centres de données ?