L'attenzione di ML si sposta verso il software

Le nuove architetture di apprendimento automatico (ML) continuano a raccogliere un'enorme quantità di attenzione mentre la corsa continua a fornire le architetture di accelerazione più efficaci per il cloud e l'edge, ma l'attenzione inizia a spostarsi dall'hardware agli strumenti software.

La grande domanda ora è se un'astrazione software alla fine vincerà sui dettagli hardware nel determinare chi saranno i futuri vincitori.

"L'apprendimento automatico è venuto storicamente da un luogo in cui c'era un'enfasi su applicazioni finali specifiche, come il rilevamento di oggetti per il settore automobilistico o la comprensione del linguaggio naturale tramite la voce", ha affermato Sree Harsha Angara, product marketing manager per IoT, informatica e sicurezza presso Infineon. "Ora, il ML ha iniziato a estendersi a diversi tipi di applicazioni, ponendo maggiore enfasi sugli strumenti di progettazione e sui framework software".

I progettisti di sistemi di apprendimento automatico stanno iniziando a richiedere di più dai kit di sviluppo software di apprendimento automatico (SDK) e alcuni fornitori stanno utilizzando il loro software per seppellire i dettagli hardware. Alla fine, un hardware meno ottimale con un buon software potrebbe avere successo su un hardware migliore con meno software.

Siamo stati qui prima
I compilatori e altri strumenti di sviluppo sono stati a lungo dati per scontati dal lato software. Ma quando si trattava di hardware all'inizio degli anni '80, ci si aspettava che i progettisti eseguissero i loro progetti in gran parte manualmente. Anche se questo è cambiato oggi, ci è voluta una strada rocciosa per arrivarci. E il mercato della logica programmabile è stato uno dei primi posti in cui il software di progettazione ha preso piede.

All'inizio, il software PLD serviva semplicemente a eliminare il lavoro intenso. Agli albori dei dispositivi a logica programmabile (PLD), gli ingegneri elaboravano la loro logica e quindi scoprivano quali connessioni erano necessarie negli array programmabili. Questi sarebbero letteralmente scritti a mano in "mappe dei fusibili", che quindi potrebbero essere inseriti nell'apparecchiatura di programmazione per la configurazione fisica di un dispositivo.

Un grande cambiamento è avvenuto con l'introduzione della logica di matrice programmabile, o PAL, di Monolithic Memories. Due cose hanno accelerato l'industria del PLD in generale. Il primo è stato un cambiamento architettonico che ha ridotto i costi e aumentato la velocità. Ma in modo più influente, ha visto la prima versione di un cosiddetto assemblatore PAL, soprannominato PALASM.

Ciò ha eliminato il noioso processo di mappatura delle connessioni. Invece, si potrebbero inserire equazioni booleane, molto più naturali con cui lavorare per gli ingegneri, e lasciare che lo strumento determini i dettagli di programmazione. Ciò ha contribuito a creare un serio punto di svolta nel business.

Alcuni anni dopo, sono apparsi nuovi operatori nel mercato PLD, fornendo una maggiore programmabilità architettonica. C'era sempre stata una logica che tali dispositivi non potevano implementare, quindi la corsa era aperta per trovare le architetture più flessibili che fossero comunque veloci ed economiche.

Una svolta significativa è arrivata quando Altera ha rilasciato la sua nuova architettura con il software di progettazione MAX-PLUS. Gli ingegneri hanno lottato per trovare i confini di ciò che quell'architettura poteva fare e sono rimasti piacevolmente sorpresi. Le equazioni che avrebbero dovuto fallire nella compilazione funzionavano effettivamente, perché il software ora stava facendo molto di più della semplice conversione di equazioni booleane in connessioni. Invece, stava anche trasformando quelle equazioni booleane, tra le altre cose, applicandole Il teorema di DeMorgan convertire le cose che non si possono fare in cose che si possono fare.

Questo è stato un punto di svolta e ha notevolmente aumentato la posta in gioco per il lato software dell'azienda. Per quanto tu possa mettere in evidenza i punti deboli dell'architettura nell'hardware, fintanto che il software ha mascherato quei punti deboli, è stato un argomento perdente.

L'attività fino a quel momento era stata dominata da società di hardware, con AMD in testa (avendo acquisito Monolithic Memories). Ma le aziende di hardware non erano brave a creare software e non gli piaceva farlo. Quindi, invece di lottare con il software, AMD ha esternalizzato il lavoro a una piccola azienda di software. Ciò si è rivelato essere un errore strategico e la società alla fine ha cessato l'attività, vendendo alcune tecnologie alla sussidiaria Vantis appena creata da AMD (che alla fine non ha avuto successo) e alcune a Xilinx, allora un nuovo arrivato sulla scena con i suoi fantasiosi FPGA (che hanno avuto un enorme successo).

Alla fine, è stato il software a determinare il vincitore. Le funzionalità hardware hanno seguito un modello di salto di qualità e gli strumenti si sono rivelati il ​​fattore di differenziazione.

"La storia è disseminata di straordinarie architetture hardware FPGA che sono tutte inciampate e non esistono più, in parte a causa della mancanza di una toolchain efficace", ha affermato Stuart Clubb, product manager principale di SiemensEDA. "Non importa quanto sia buona una piattaforma hardware se non si dispone del software per sfruttare in modo efficiente ed efficace tale piattaforma".

Un parallelo di apprendimento automatico?
Oggi tutti gli occhi sono puntati sull'intelligenza artificiale e le aziende stanno cercando di trovare la migliore architettura per acceleratori di apprendimento automatico che funzionino nel cloud o all'edge. Mentre le istanze cloud hanno dominato, implementazioni edge — con i loro severi requisiti di potenza e costi — hanno stimolato molta più creatività.

Ma è diventato sempre più difficile comprendere l'impatto delle differenze tra queste architetture. Sembra quasi che le grandi idee siano dietro di noi, con le aziende che spingono e tirano su parametri diversi per trovare un punto debole per prestazioni, potenza e costi.

"Il problema che le persone incontrano è che hanno queste soluzioni hardware e non sono in grado di ottimizzarle o ottenere il livello di utilizzo desiderato", ha affermato Dana McCarty, vicepresidente vendite e marketing, prodotti di inferenza presso Logix flessibile.

L'apprendimento automatico ha sempre avuto un elemento software, poiché l'idea di addestrare e implementare una soluzione di apprendimento automatico non è un'impresa da poco. L'esistenza dei primi framework di apprendimento automatico come Caffe e TensorFlow ha reso le applicazioni di intelligenza artificiale pratiche e accessibili a un numero maggiore di sviluppatori.

Anche così, c'è molto lavoro da fare nella creazione di un progetto completo, specialmente per le applicazioni edge. Vantaggio ha fornito un esempio di utilizzo dell'IA sui dati di test, un'applicazione che è molto meno importante della visione, ad esempio.

"Otteniamo questo grande set di dati non ripulito e ci vorranno diverse settimane per esaminarlo manualmente, applicando manualmente gli strumenti", ha affermato Keith Schaub, vicepresidente della tecnologia e della strategia di Advantest. “Hai centinaia di funzionalità, a volte 1,000 funzionalità o più, e stai cercando di capire le funzionalità più importanti correlate alla tua previsione. Vengono con quelli attraverso metodi di regressione e [analisi delle componenti principali]. E poi hai questo modello statico con 12 funzioni".

E questa è solo l'ingegneria delle funzionalità di alto livello. La parte successiva consiste nel mappare in modo efficiente quel modello su un dispositivo specifico, ed è qui che potrebbe apparire un vantaggio competitivo. "Devi essere in grado di collegare in modo efficiente quel modello al tuo acceleratore e l'azienda in grado di fare questo ponte vincerà", ha affermato Sam Fuller, direttore senior del marketing di Flex Logix.

Mentre i motori basati su cloud possono fare affidamento in gran parte su hardware a virgola mobile completo, gran parte dell'hardware edge consente di risparmiare energia e costi concentrandosi su implementazioni intere. Ciò significa prendere un progetto e i parametri addestrati e quantizzarli, convertendoli da virgola mobile a intero. Ciò introduce alcuni errori, che possono compromettere l'accuratezza dell'inferenza, quindi potrebbe essere necessario riqualificare con il formato intero desiderato. Significativamente, nel tempo, è diventato più facile allenarsi direttamente sugli interi.

Anche la riduzione delle dimensioni e del consumo energetico di questi progetti ha richiesto del lavoro. Si potrebbe esaminare il progetto identificando parametri che erano probabilmente troppo piccoli per essere importanti e poi eliminandoli. In origine si trattava di un processo manuale, che richiedeva una rivalutazione dell'accuratezza per assicurarsi che non fosse stata compromessa troppo gravemente dal processo di potatura.

Poi c'è la questione di adattare i “kernel” del software per qualsiasi tipo di processore venga utilizzato. Questo è spesso codice bare metal scritto per ogni nodo della rete. Alcune architetture scelgono elementi di elaborazione che si concentrano solo sulle istruzioni comuni utilizzate per l'inferenza. Altri mantengono la "piena programmabilità" in modo che possano essere utilizzati in modo più flessibile oltre l'inferenza.

E se si dispone di un'architettura di flusso di dati, potrebbe essere necessario partizionare l'hardware e assegnare livelli e nodi diversi a regioni diverse.

Queste sono solo alcune delle cose che devono essere gestite per implementare un'applicazione di apprendimento automatico completamente funzionale. Alcuni sono stati manuali, ma la quantità di automazione del software è stata gradualmente aumentata.

La fase successiva: mantenere segreto l'hardware
Nel corso dell'ultimo anno, un cambiamento è diventato visibile nel settore. A conferenze come le conferenze Linley Processor o Hot Chips, le aziende hanno annunciato nuove offerte con maggiori discussioni sul software. E in particolare, in alcuni casi, non parlano dell'hardware sottostante.

Questo, ovviamente, può accadere nei forum pubblici come le conferenze. A volte le aziende divulgano i dettagli solo ai sensi dell'NDA a legittimi potenziali clienti. Ma il tenore delle conversazioni sembra essersi mosso sempre più nella direzione di dire: “Non preoccuparti per i dettagli. Il software se ne occuperà”.

Ciò cambia in modo significativo le discussioni di vendita da una sul tentativo di convincere un potenziale cliente che sottili differenze architettoniche avranno risultati significativi, a una in cui l'esperienza di progettazione fornisce la prova. Riesci a implementare un progetto di prova più rapidamente di quanto non fossi in grado di fare prima? Raggiungi i parametri di prestazione target (costo, velocità, potenza, precisione, ecc.) con un'iterazione manuale minima? È possibile ottenere un'implementazione ottimale con un intervento manuale minimo o nullo?

Se la risposta a tutti questi è sì, allora importa come l'hardware lo ha raggiunto? Se il software è in grado di eseguire rapidamente le trasformazioni necessarie, è importante se le porte sottostanti presentavano una limitazione che richiedeva la trasformazione del software? Se un'altra architettura ha molti più campanelli e fischietti, ma ci vuole molto più sforzo per completare un progetto, vale la pena spendere quelle funzionalità extra?

Le aziende che si affidano ai loro strumenti per parlare scommettono che ai loro clienti non importa davvero cosa c'è sotto il cofano, purché, abbinato a un buon software, possa svolgere il lavoro desiderato e la velocità, la potenza, la precisione e i costi necessari .

La storia si ripeterà con l'apprendimento automatico?
Proprio come le persone, le aziende tendono ad avere personalità. Alcuni sono orientati all'hardware, mentre altri sono orientati al software. Alcuni di entrambi sono chiaramente necessari per qualsiasi offerta di apprendimento automatico, ma sembra che il vantaggio possa spostarsi verso quelli con un orientamento software. Ciò significa mantenere il software in primo piano e al centro come protagonista dell'offerta, non come un cameo fastidioso ma necessario. Significa anche che l'hardware e il software devono essere progettati insieme.

La necessità di un software per bufferizzare i dettagli è probabilmente maggiore con ML rispetto agli FPGA. Anche con gli strumenti, gli FPGA sono progettati da ingegneri hardware. I modelli ML, d'altra parte, sono progettati da data scientist, che sono a molti livelli di distanza dall'hardware. Quindi gli strumenti devono colmare il divario di astrazione.

"Se non parli la loro lingua, non hai alcuna possibilità", ha affermato Nick Ni, direttore del marketing dei prodotti per l'intelligenza artificiale e il software presso Xilinx. “Ogni fornitore parla del supporto TensorFlow e Python perché non hanno altro modo. Che ti piaccia o no, devi supportarlo. Ma per supportare un quadro così elevato, devi fare tutto il resto".

Un altro fallimento nel settore PLD è stato la progettazione di architetture intelligenti solo per scoprire in seguito che il software era estremamente difficile da costruire per questo. I team hardware e software di maggior successo hanno lavorato insieme, con l'hardware modificato secondo necessità per consentire algoritmi software fluidi e potenti.

Fig. 1: L'evoluzione degli strumenti di progettazione, a partire dai progetti manuali e procedendo attraverso l'eliminazione della noia, l'effettiva capacità di manipolare i progetti e, infine, di ottimizzarli. Con le ultime fasi, il co-design hardware/software è fondamentale per il successo. Fonte: Bryon Moyer/Ingegneria dei semiconduttori

Questo sarà vero anche per l'apprendimento automatico. Se un trucco hardware intelligente è difficile da sfruttare nel software, probabilmente non verrà mai utilizzato. In definitiva, le offerte di maggior successo saranno probabilmente architetture che si accoppiano bene con i loro strumenti e che hanno perso tutte le funzionalità che non possono essere utilizzate efficacemente dagli strumenti.

"Una delle premesse fondamentali dell'azienda è che le esigenze del software devono guidare la progettazione dell'hardware", ha affermato Nigel Drago, CTO di Quadric.io, alla Linley Processor Conference dello scorso autunno.

Nella stessa conferenza, Ravi Setty, vicepresidente senior di Roviero, ha menzionato il ruolo del software nella definizione dell'architettura dell'azienda. “Abbiamo aggiunto forse il 5% di complessità nell'hardware per ottenere qualcosa come il 90% di semplicità nel compilatore. L'hardware è puramente agnostico rispetto a qualsiasi informazione della rete neurale. È il compilatore che ha tutta la conoscenza. E l'hardware: è solo un motore di esecuzione".

Sebbene il ruolo degli strumenti stia crescendo, non siamo ancora al punto in cui seppelliscono completamente l'hardware. C'è ancora un ricco mix di esplorazione architettonica che deve ancora stabilirsi. Come con molte traiettorie di automazione del design, stiamo entrando nel regno in cui molti progetti saranno realizzabili automaticamente, con modifiche manuali necessarie per ottenere il massimo dall'hardware.

In questa fase del mercato, c'è anche una tensione tra architetture più generalizzate con astrazione del software e architetture appositamente costruite. "Sebbene una soluzione hardware generica basata su software possa offrire una maggiore flessibilità, tali soluzioni spesso perdono rispetto all'hardware specializzato quando una certa dimensione (area, potenza, velocità, costo) è di maggiore importanza", ha osservato Clubb di Siemens EDA.

Questo può creare una sfida per il software destinato a hardware specializzato. "Ogni architettura presenta vantaggi unici ed è ottimizzata per casi d'uso specifici", ha spiegato Anoop Saha, senior manager, strategia e crescita presso Siemens EDA. “Ma la sfida per l'utente rimane: come possono compilare la propria rete su un'architettura hardware specifica? E se sono in grado di farlo, come possono ottimizzarlo per quel particolare hardware e sfruttare i diversi componenti disponibili? Le ottimizzazioni e la flessibilità specifiche dell'hardware devono essere gestite dal software in modo più automatico".

Gli strumenti governano?
In definitiva, quindi, sembra che i vincitori dell'hardware a lungo termine saranno quelli che forniranno la migliore esperienza di progettazione, con solo l'hardware sufficiente per aiutare gli sviluppatori nelle loro decisioni di progettazione. Questo è certamente il modo in cui funzionano gli FPGA oggi. In effetti, in alcuni casi, ci sono cose che l'hardware FPGA può teoricamente fare che il software non consente.

ML sembra seguire un percorso simile. "Le innovazioni nell'hardware che forniscono vantaggi significativi in ​​termini di potenza e velocità si stanno avvolgendo in un framework software o API comune", ha affermato Angara di Infineon. "Ciò significa che forniscono vantaggi significativi nell'esecuzione di ML senza il dolore di software 'non sofisticato'."

Resta da vedere se gli ingegneri smetteranno di pensare all'hardware. “I 'compilatori' di ML possono essere abbastanza intelligenti da indirizzare piattaforme hardware generiche al punto in cui l'hardware non ha molta importanza? Probabilmente no", ha detto Clubb. “La specializzazione hardware ML presenta certamente vantaggi e svantaggi nel bloccare la flessibilità e la riprogrammabilità della soluzione. Architetti inventivi e progettisti hardware dovranno sempre progettare soluzioni più efficaci quando la soluzione generica non soddisfa le esigenze dell'applicazione".

Tuttavia, il ridimensionamento e la maggior parte del mercato possono influire su questo. Quando la sintesi era nuova, c'erano molti ingegneri che pensavano di poter sempre fare un lavoro migliore di uno strumento. Potrebbe essere stato vero, ma è diventato impraticabile quando i progetti sono aumentati, le aspettative di produttività sono aumentate e gli strumenti sono migliorati.

Quindi, mentre l'hardware sarà sempre importante in una certa misura, sembra che a lungo termine, proprio come lo era con la logica programmabile, gli strumenti software potrebbero spesso finire per essere il kingmaker.

Fonte: https://semiengineering.com/ml-focus-shifting-toward-software/