News

GPU e HPC: Fujitsu vuole risolvere i problemi del mondo (tech) ottimizzando

Dalla big giapponese arrivano due tecnologie mirate a risolvere la carenza mondiale di GPU e l’esigenza del real time di alcune applicazioni critiche che richiedono High Performance Computing. Si punta sull’ottimizzazione step by step, monitorata, per supportare l’innovazione. Focus sulla gestione previsionale e intelligente, per mitigare dipendenze tecnologiche e fragilità della supply chain

Pubblicato il 14 Dic 2023

Immagine di Mia Stendal su Shutterstock

Come per la crisi climatica, e per molte altre crisi, aumenta il numero dei sostenitori dell’approccio adattivo. Si prende atto di carenze, emergenze ed eccessi e si trova una via per gestirli al meglio, oltre a cercare di mitigarli.

È la stessa linea sposata da Fujitsu per andare incontro alle principali esigenze manifestate da quella parte di mondo tecnologico che chiede “tutto e subito”. A volte anche per scopi altamente virtuosi come il design di nuovi farmaci o il monitoraggio dell’ambiente.

Basta GPU per tutto e tutti: solo quando serve

La prima evidenza che Fujitsu si ripromette di contribuire a risolvere è rappresentata dalla carenza di GPU a livello globale. Uno dei numerosi punti deboli del mondo tech che l’AI ha trasformato in emergenza, con la sua spropositata domanda di formazione di modelli generativi.

Attraverso una soluzione dal nome più che auto esplicativo – Adaptive GPU Allocator – l’azienda giapponese mira all’ottimizzazione. L’idea è quella di iniziare a distinguere tra i programmi che richiedono realmente un acceleratore GPU da quelli che possono farne a meno, accontentandosi di una CPU. Il modo per allocare risorse in modo oculato e lungimirante.

Gli step da compiere sono due: prima si prevede l’accelerazione che lo specifico programma necessita, poi si commutano le GPU tra i vari programmi, minimizzando il tempo di elaborazione complessivo.

Questo è possibile grazie a un server di allocazione che, nel frattempo, si occupa anche di misurare le prestazioni del codice durante la sua esecuzione. Una sorta di “check”, per capire se si ottiene un vero guadagno di tempo con l’uso della GPU, oppure le previsioni “ci hanno visto male”. Per valutarlo, nello specifico, si vanno a esaminare i tempi di elaborazione per lo stesso numero di iterazioni di un mini-batch sia sulla GPU che sulla CPU all’inizio dell’addestramento, ricavando il valore dell’ipotetico guadagno di prestazioni legato alla GPU.

Questo server “multi-tasking” di allocazione lavora su mini-batch con scale temporali più lunghe di quelle di un tipico scheduler del sistema operativo. Tale incompatibilità obbliga l’utente, per ora, a sviluppare i propri programmi utilizzando il framework di Fujitsu che fa uso di TensorFlow e PyTorch.

Un HPC che decide real time e regala real time

Sempre di risparmio di tempo si tratta, anche per quanto riguarda la seconda novità annunciata, rivolta in particolare al mondo del High Performance Computing. Dedicata alle applicazioni che necessitano di prestazioni elevate, ma anche in real time, la tecnologia Fujitsu permette di commutare l’esecuzione di più programmi su un sistema HPC alla massima velocità. I casi d’uso citati riguardano lo studio di nuovi farmaci come la simulazione delle dinamiche climatiche, ma in teoria ogni settore ha le proprie “applicazioni frettolose” per cui rivolgersi a Interactive HPC.

Il “segreto” della soluzione presentata sta nel cambio del metodo di comunicazione, da unicast a broadcast. Nel primo caso, quello convenzionale, il controller invia l’istruzione di commutare l’esecuzione del programma a ciascun nodo di un cluster HPC a turno, mentre nel secondo caso ciò avviene in simultanea verso ogni nodo. Un cambio di paradigma che regala forti guadagni di tempo nel completare la commutazione dell’elaborazione: da un paio di secondi si raggiunge il limite di 100 millisecondi in un ambiente HPC a 256 nodi.

Anche in questo caso, in parallelo all’ottimizzazione, è previsto un lavoro di monitoraggio. In particolare, si osserva il numero di job switch per evidenziare l’eventuale differenza nel numero di job switch tra i nodi a causa della perdita di pacchetti. È fondamentale per capire se utilizzare la comunicazione broadcast, tenendo anche conto del grado di miglioramento delle prestazioni generale e del possibile peggioramento delle prestazioni dovuto alla perdita di pacchetti.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati

Articolo 1 di 4