SiFive RISC-V core scelti per i nodi di calcolo AI di Google

Il chip biz RISC-V SiFive afferma che i suoi processori vengono utilizzati per gestire i carichi di lavoro dell'IA in una certa misura nei data center di Google.

Secondo SiFive, il processore in questione è la sua Intelligence X280, un design RISC-V multi-core con estensioni vettoriali, ottimizzato per applicazioni AI/ML nel data center. Se combinato con le unità di moltiplicazione della matrice (MXU) prelevate dalle unità di elaborazione tensoriale di Google (TPU), si afferma che ciò offra una maggiore flessibilità per la programmazione dei carichi di lavoro di apprendimento automatico.

In sostanza, i core RV280 per uso generico dell'X64 nel processore eseguono il codice che gestisce il dispositivo e alimenta i calcoli di apprendimento automatico negli MXU di Google come richiesto per completare i lavori. L'X280 include anche la propria unità di matematica vettoriale in grado di gestire operazioni che le unità dell'acceleratore non possono.

SiFive e Google sono stati un po' timidi, forse per ragioni commerciali, su come esattamente questo viene confezionato e utilizzato, anche se a noi sembra che Google abbia inserito le sue unità di accelerazione personalizzate in un system-on-chip X280 multi-core, collegando il blocchi MXU progettati da Google direttamente al complesso centrale RISC-V. Questi chip vengono utilizzati nei data center di Google, negli "host di calcolo AI" secondo SiFive, per accelerare il lavoro di apprendimento automatico.

Immaginiamo che se questi vengono utilizzati nella produzione, questi chip svolgano attività all'interno dei servizi. Notiamo che non è possibile noleggiare questo hardware direttamente su Google Cloud, che offre macchine virtuali ottimizzate per l'intelligenza artificiale basate sulla tradizionale tecnologia x86, Arm, TPU e GPU.

I dettagli sono stati divulgati all'AI Hardware Summit nella Silicon Valley all'inizio di questo mese, in un discorso del co-fondatore di SiFive e architetto capo Krste Asanović e dell'architetto di Google TPU Cliff Young, e in un Post del blog SiFive questa settimana.

Secondo SiFive, ha notato che dopo l'introduzione dell'X280, alcuni clienti hanno iniziato a usarlo come core complementare insieme a un acceleratore, al fine di gestire tutte le attività di pulizia e di elaborazione generiche per le quali l'acceleratore non era progettato.

Molti hanno scoperto che era necessario uno stack software completo per gestire l'acceleratore, afferma il settore dei chip, e i clienti si sono resi conto che avrebbero potuto risolvere questo problema con un complesso di core X280 accanto al loro grande acceleratore, i core della CPU RISC-V che gestiscono tutta la manutenzione e codice operativo, eseguire operazioni matematiche che il grande acceleratore non può e fornire varie altre funzioni. In sostanza, l'X280 può fungere da nodo di gestione per l'acceleratore.

Per capitalizzare su questo, SiFive ha collaborato con clienti come Google per sviluppare ciò che chiama Vector Coprocessor Interface eXtension (VCIX), che consente ai clienti di collegare strettamente un acceleratore direttamente al file di registro vettoriale dell'X280, fornendo prestazioni migliori e maggiori dati larghezza di banda.

Secondo Asanović, il vantaggio è che i clienti possono portare il proprio coprocessore nell'ecosistema RISC-V ed eseguire uno stack software completo e un ambiente di programmazione, con la possibilità di avviare Linux con memoria virtuale completa e supporto coerente con la cache, su un chip contenente un mix di core CPU generici e unità di accelerazione.

Dal punto di vista di Google, voleva concentrarsi sul miglioramento della sua famiglia di tecnologie TPU e non perdere tempo a creare il proprio processore per applicazioni da zero, quindi accoppiare queste funzioni di accelerazione con un processore per uso generico già pronto sembrava il modo giusto andare, secondo Young.

VCIX essenzialmente incolla le MXU ai core RISC-V con bassa latenza, saltando la necessità di trascorrere molti cicli in attesa di trasferire i dati tra CPU e unità di accelerazione tramite memoria, cache o PCIe. Invece, ci è stato detto, sono solo decine di cicli attraverso l'accesso al registro vettoriale. Ciò suggerisce anche che tutto - il complesso CPU RISC-V e gli acceleratori personalizzati - sono tutti sullo stesso die, impacchettato come un sistema su chip.

Il codice dell'applicazione viene eseguito sui core RISC-V generici e qualsiasi lavoro che può essere accelerato dall'MXU viene trasferito tramite VCIX. Secondo Young, ci sono altri vantaggi di questo approccio oltre all'efficienza. Il modello di programmazione è semplificato, risultando in un unico programma con istruzioni scalari, vettoriali e del coprocessore intercalate e consentendo un'unica toolchain software in cui gli sviluppatori possono codificare in C/C++ o in assembler a piacere.

"Con i core per uso generale basati su SiFive VCIX 'ibridati' con Google MXU, puoi costruire una macchina che ti consente di 'avere la tua torta e mangiarla anche tu', sfruttando appieno tutte le prestazioni dell'MXU e la programmabilità di un CPU e le prestazioni vettoriali del processore X280", ha affermato Young.

È probabile che la possibilità di realizzare un chip personalizzato come questo rimanga dominio degli hyperscaler come Google, o di quelli con requisiti di nicchia e tasche profonde, ma dimostra cosa si può ottenere grazie alla flessibilità del modello RISC-V dell'ecosistema aperto .

Quella flessibilità e apertura sembrano essere sufficienti per indurre Google, un sostenitore di lunga data di RISC-V, con i core RV utilizzati in alcuni dei suoi altri prodotti, a utilizzare l'architettura nata invece di inserire i suoi coprocessori personalizzati in chip x86 o Arm -progetti su licenza. ®

PS: Ricorda quando era Google giocherellando con l'utilizzo dell'architettura POWER CPU nei suoi data center?