Il successo dell'apprendimento automatico si basa sulla scalabilità

Fornito da Braccio

Steve Roddy è vicepresidente, Machine Learning Group, presso Arm.

Il cambiamento è costante e l'intelligenza artificiale (AI) e l'apprendimento automatico (ML) stanno cambiando tutto, ancora una volta. Per gli sviluppatori che cercano di immettere sul mercato nuovi prodotti e servizi che sfruttano l'IA e il ML, le sfide sono aggravate dal fatto che il panorama tecnologico è ancora in via di sviluppo.

A differenza del tradizionale settore embedded, che mostra una relazione lineare tra la necessità di maggiori prestazioni di elaborazione e il modo in cui vengono utilizzate le prestazioni, c'è una disparità tra AI e ML e le piattaforme hardware su cui funzioneranno: ML è in continua evoluzione.

Visita l'hub dei contenuti

• Apprendimento automatico scalabile

L'allontanamento dal pensiero sequenziale

È probabile che il ML venga utilizzato ovunque, proprio come viene utilizzato oggi il software embedded tradizionale. Tuttavia, a differenza del codice tradizionale, che viene scritto riga per riga in uno schema sequenziale (anche se viene utilizzata la generazione automatica), ML verrà distribuito come modelli, creati da framework che apprendono. I modelli, in un senso molto reale, nasceranno. E come ogni forma di prole, non puoi mai essere veramente sicuro di ciò che otterrai finché non arriverà.

Per gli sviluppatori, quindi, la natura prevedibile del software incorporato scomparirà o cambierà in modo significativo. Sono in fase di sviluppo strumenti che aiutano a prevedere come funzionerà un modello o imporranno determinate restrizioni al modo in cui il modello è formato per conformarsi alla piattaforma, ma questi sono nascenti e non sono in alcun modo una panacea. È probabile che l'adattamento ai vincoli del sistema porti a una perdita di precisione. La natura di ML è che fornisce la precisione necessaria sull'hardware fornito. Ne consegue, quindi, che se l'hardware è in grado di adattarsi si può evitare di compromettere la precisione.

Non esiste una taglia unica per l'apprendimento automatico. Gli ingegneri devono progettare sistemi che offrano prestazioni scalabili e possano modificare il tipo di risorsa di elaborazione che forniscono in base all'attività da svolgere.

Anche il modo in cui un modello si comporta su una piattaforma hardware fissa cambierà. La natura prevedibile del software embedded è stata a lungo un pilastro del design; in effetti, l'idea che le caratteristiche del codice cambieranno dopo che è stato distribuito è materia degli incubi degli ingegneri. I sistemi embedded sono sviluppati all'interno di parametri di prestazione, un involucro basato su potenza, costo, dissipazione del calore, dimensioni, peso e qualsiasi numero di misurabili che possono essere scambiati l'uno contro l'altro per raggiungere gli obiettivi definiti. Questo è essenzialmente il modo in cui lo sviluppo integrato è sempre stato fatto, ma non è il modo in cui sarà fatto in futuro.

La scalabilità è la nuova norma

Al contrario, gli ingegneri dovranno progettare sistemi che offrano prestazioni scalabili, in grado di regolare dinamicamente il tipo di risorsa di elaborazione che forniscono in base all'attività da svolgere. Questo è diverso da ciò con cui gli ingegneri embedded potrebbero sentirsi a proprio agio in questo momento. Da alcuni anni i processori embedded hanno la capacità di variare la frequenza operativa e la tensione di alimentazione in base al carico di lavoro. In sostanza, il core di un processore può funzionare più lentamente quando non è occupato; il ridimensionamento della frequenza di clock principale si traduce direttamente in un minor numero di transistor che si accendono e si spengono al secondo, risparmiando energia. Quando il core ha davvero bisogno di darsi da fare, la frequenza di clock viene aumentata, aumentando il throughput. Esiste una relazione tra tensione di alimentazione e frequenza di clock; riducendo entrambi si amplifica la quantità di energia conservata. Questo tipo di ridimensionamento non sarà sufficiente per fornire la potenza e le prestazioni necessarie nei dispositivi embedded ora sviluppati per eseguire modelli ML.

Questo perché il modo in cui misuriamo le prestazioni cambierà. Al momento, i processori vengono generalmente misurati in termini di operazioni al secondo; ora lo stiamo misurando in teraop, o trilioni di operazioni al secondo (TOPS). L'uso di TOPS per misurare le prestazioni di un processore che esegue le inferenze non avrà molto senso come quando si esegue il codice sequenziale, perché il modo in cui il modello viene eseguito non è direttamente paragonabile al normale software embedded. I processori ML verranno misurati sulla precisione che ottengono quando forniscono un determinato numero di inferenze al secondo per una determinata quantità di potenza. Non abbiamo ancora una metrica standard per questo, ma possiamo dire che semplicemente aumentare la frequenza di clock per raggiungere l'obiettivo di inferenze/i non è garantito e probabilmente ridurrà il budget di potenza, senza migliorare la precisione.

Il percorso per l'inferenza è disseminato di variabili

Come mai? Il motivo risiede nel modo in cui funzionano i modelli ML. Con molti livelli di probabilità da attraversare, ci sono altrettante variabili che possono cambiare il percorso attraverso quei livelli. Il mondo reale avrà un impatto molto maggiore sul modo in cui i modelli ML vengono eseguiti, con una variabilità molto maggiore rispetto al codice embedded sequenziale lineare. Prendi come esempio l'elaborazione del linguaggio naturale e il riconoscimento vocale: la voce e la cadenza dell'oratore giocheranno un ruolo nell'efficacia del modello, tuttavia potrebbe esserci anche un'interazione tra questi parametri che si traduce in un'esperienza diversa in varie condizioni. Il semplice aumento della velocità del processore in questo caso potrebbe non restituire il risultato desiderato.

Inoltre, una delle caratteristiche distintive del ML è la sua capacità di apprendere. Anche se l'apprendimento per rinforzo non viene applicato nel dispositivo stesso, è comunque possibile che i dati vengano restituiti a un mainframe in cui il modello potrebbe essere ottimizzato in base ai risultati osservati. Anche senza questo feedback è probabile che il modello venga migliorato nel tempo, semplicemente a causa del modo in cui il ML si sta ancora evolvendo. Ciò comporterebbe la creazione e l'implementazione di un nuovo modello (utilizzando ad esempio aggiornamenti over-the-air), che avrà quindi requisiti di elaborazione potenzialmente completamente diversi, funzionando in modo diverso a condizioni identiche o simili.

La natura mutevole dei modelli ML significa che, mentre le attuali architetture CPU possono essere e vengono utilizzate per ML, le architetture odierne quasi certamente non possono fornire il modo più ottimale per eseguirle. Sì, i modelli possono essere eseguiti su CPU utilizzando tutte le consuete funzionalità ALU presenti nella maggior parte dei processori. Possono anche trarre vantaggio da architetture altamente parallele che presentano un numero enorme di istanze multiple di queste funzionalità, come le GPU, ma è già chiaro che le GPU non sono il modo migliore per eseguire modelli ML. In effetti, abbiamo già esempi di unità di elaborazione neurale e l'industria dei semiconduttori è al lavoro per sviluppare architetture completamente nuove per eseguire modelli ML in modo più efficiente. Ad un certo punto, l'hardware o il software vengono riparati per consentire all'altro di andare avanti. Il modo giusto per affrontare questo problema è impegnarsi in un framework software comune che può essere utilizzato su piattaforme hardware compatibili ma scalabili, in modo che entrambe si evolvano insieme.

Architetture eterogenee flessibili

In questo modo, la scalabilità necessaria per supportare l'IA e il machine learning può essere estesa dal core della rete fino all'edge, senza bloccare l'architettura su una piattaforma fissa. Project Trillium è la piattaforma di elaborazione ML eterogenea di Arm composta da core e software. Arm sta espandendo il progetto Trillium per affrontare il ML in ogni punto della rete. La piattaforma software comune qui sono le librerie software per reti neurali Arm, Arm NN, che possono essere eseguite su piattaforme di processori Arm e sono anche compatibili con i principali framework di reti neurali di terze parti. L'hardware include i processori GPU Arm Cortex-A e Arm Mali esistenti che vengono migliorati per AI e ML, nonché processori completamente nuovi per l'accelerazione ML.

In termini di scalabilità, ML può essere eseguito e funziona su processori piccoli e con risorse limitate nella classe Cortex-M e ricchi di funzionalità come le GPU Mali. Tuttavia, è necessaria una vera scalabilità per soddisfare tutte le esigenze del ML dal core all'edge, ed è qui che entra in gioco il prossimo passo nell'evoluzione del processore. Le unità di elaborazione neurale, o NPU, rappresentano la nuova generazione di architettura del processore che supporterà il ML in più applicazioni.

Solo Arm offre questo livello di scalabilità nel panorama ML. La scelta di architetture scalabili che possono essere composte da MCU, CPU, GPU e NPU aiuterà piattaforme hardware a prova di futuro contro nuove applicazioni software che non sono state nemmeno concepite.

Ci sono molte incognite, in termini di quali modelli ML creeremo in futuro, quanta potenza di calcolo avranno bisogno per fornire la precisione desiderata, quanto velocemente gli informatici saranno in grado di migliorare i modelli in modo da aver bisogno di meno energia: tutto di queste considerazioni hanno un impatto diretto sull'hardware sottostante. L'unica cosa che sappiamo è che soddisfare le mutevoli aspettative degli utenti finali richiede una piattaforma flessibile e scalabile.

nascondere