Avi Baum, CTO at Hailo – Interview Series

Avi Baum, CTO at Hailo, guida la visione tecnologica e l’innovazione del prodotto dell’azienda. In precedenza, ha ricoperto il ruolo di CTO per la connettività wireless presso Texas Instruments, guidando le strategie per i connettori MCUs nei mercati IoT e IIoT, e ha ricoperto ruoli di architettura e leadership senior nelle Forze di difesa israeliane.

Hailo è un’azienda israeliana di AI-chip specializzata in processori edge AI ad alte prestazioni e basso consumo per applicazioni come veicoli autonomi, telecamere intelligenti e robotica, supportata da una suite software completa e da un ecosistema di partner globali.

Può condividere cosa l’ha originariamente attratto nel campo dell’edge AI e come le sue prime esperienze di ingegneria hanno plasmato il suo pensiero sulla progettazione del processore?

La mia carriera mi ha portato in aree di mercati emergenti. Durante il mio periodo presso TI (Texas Instruments), un leader nel settore dei semiconduttori con un’eredità consolidata, ho avuto l’opportunità di guidare la progettazione e l’architettura a livello di sistema, dirigendo il dipartimento di definizione del prodotto e successivamente ricoprendo il ruolo di CTO di questo dipartimento. Ciò mi ha portato a esplorare continuamente le tecnologie emergenti che sono probabili candidate a plasmare il futuro “non troppo lontano”.

Quando abbiamo fondato Hailo nel 2017, era chiaro che l’AI, che aveva iniziato a prosperare nel cloud, aveva anche il potenziale per diventare una tecnologia abilitante per i dispositivi edge. Quindi, abbiamo intrapreso questo percorso.

Mentre l’AI generativa si espande sull’edge, perché TOPS – tera operazioni al secondo – non è più un parametro di riferimento sufficiente per valutare le prestazioni del processore?

TOPS è stato a lungo il parametro di riferimento per valutare l’hardware AI, ma nell’era dell’AI generativa sull’edge, non è più sufficiente. La natura dei modelli classici è quella di tradurre grandi quantità di dati in informazioni significative, quindi la quantità di calcolo necessaria per elaborare i dati in entrata cresce con la quantità di dati che devono essere elaborati. I modelli per questi compiti sono generalmente più piccoli rispetto alla quantità di dati che elaborano, rendendo l’overhead della larghezza di banda attribuito all’accesso ai parametri del modello relativamente trascurabile.

I modelli generativi, tuttavia, sono notevolmente più grandi – nell’ordine dei miliardi di parametri – e in questi casi, la larghezza di banda della memoria diventa un fattore non trascurabile.

Invece di concentrarsi solo su TOPS, è fondamentale valutare come un processore bilancia calcolo e memoria in condizioni del mondo reale. Non si tratta di inseguire il numero più alto; si tratta di ottimizzare l’architettura per i carichi di lavoro che deve gestire.

Perché la larghezza di banda della memoria sta diventando un collo di bottiglia più critico del calcolo nei carichi di lavoro dell’edge AI, in particolare per LLM e VLM?

Per i carichi di lavoro dell’edge AI, in particolare quelli che coinvolgono LLM o VLM, la larghezza di banda della memoria sta rapidamente diventando il collo di bottiglia principale. Questi modelli sono generalmente compresi tra 0,5 e 8 miliardi di parametri, superando la capacità della memoria onboard e richiedendo l’accesso alla memoria off-chip come DRAM. Ciò aumenta notevolmente la domanda di larghezza di banda della memoria. Ad esempio, un modello da 1 miliardo di parametri può consegnare fino a ~40 token al secondo in condizioni ottimali con un’interfaccia LPDDR4X standard, ma mantenere quel tasso con un modello da 4 miliardi di parametri richiede più del quadruplo di quella larghezza di banda. Senza di essa, le prestazioni soffrono, non a causa di limiti di calcolo, ma perché il processore non può alimentare i dati abbastanza rapidamente. Questo squilibrio tra calcolo e memoria è una delle sfide più pressanti nel deploy dell’AI generativa sull’edge. Ciò è ulteriormente amplificato in architetture che calcolano layer per layer, dove i risultati intermedi aumentano anche il traffico di memoria e ulteriormente stressano la larghezza di banda.

Come dovrebbero ripensare le squadre di prodotto la loro strategia di benchmarking quando progettano per applicazioni edge del mondo reale?

Le squadre di prodotto dovrebbero allontanarsi dal affidarsi a un singolo parametro di prestazione come TOPS e invece adottare una strategia di benchmarking che rifletta le realtà del deploy sull’edge. Ciò inizia con la comprensione del caso d’uso specifico, del carico di lavoro effettivo che il processore deve gestire e dell’identificazione del “punto di lavoro”: l’intersezione dei vincoli di potenza, costo e latenza. Da lì, si tratta di valutare come calcolo e memoria interagiscono in quelle condizioni. Un processore con alto TOPS non consegnerà se la larghezza di banda della memoria è limitata, e più memoria non aiuterà se la capacità di calcolo è insufficiente.

Le squadre dovrebbero valutare se il processore possa sostenere le prestazioni across task come percezione, miglioramento e carichi di lavoro generativi, ognuno con richieste molto diverse. L’obiettivo non è quello di ottimizzare per le specifiche di picco, ma di garantire prestazioni bilanciate in tutta la gamma di casi d’uso previsti in ambienti del mondo reale.

Ciò è uno shift naturale da misure “sterili” a approcci più intricati che riflettono come vengono utilizzate le piattaforme e come vengono valutate – simile a ciò che è accaduto ad altre architetture che sono diventate mainstream (ad esempio, SPEC, Coremark, 3DMark, ecc.).

Come vincoli di potenza e costo influenzano le decisioni di architettura dietro i processori Hailo, in particolare per dispositivi edge orientati al consumatore?

Potenza e costo sono due dei vincoli più determinanti quando si progettano processori AI per dispositivi edge, in particolare in prodotti orientati al consumatore. In dispositivi compatti come sensori IoT o assistenti intelligenti per la casa, i budget di potenza sono stretti e spesso non c’è raffreddamento attivo, quindi l’efficienza energetica diventa critica. Ogni risorsa aggiuntiva di calcolo o memoria aggiunge consumo di potenza e calore, che influisce direttamente sull’usabilità e sulla durata della batteria.

Il costo è altrettanto influente. I dispositivi per il consumatore devono rimanere all’interno di punti di prezzo competitivi, il che significa che il processore può includere solo una certa quantità di TOPS e memoria prima di diventare economicamente non sostenibile. Questi vincoli forzano scelte architettoniche difficili. In Hailo, noi priorizziamo progetti che consegnano il giusto equilibrio di calcolo e memoria per soddisfare le esigenze di applicazioni reali all’interno di un envelope stretto di potenza e costo, garantendo che l’AI edge diventi fattibile, efficiente e scalabile in una vasta gamma di prodotti per il consumatore.

Potrebbe spiegarci come definisce un “punto di lavoro” per un’applicazione e perché ciò è così importante nel deploy dell’AI edge?

Definire il “punto di lavoro” è uno dei passaggi più importanti quando si progetta un sistema. Si riferisce all’intersezione dei vincoli di potenza, costo e latenza che plasmano ciò che è realisticamente raggiungibile in un determinato deploy. A differenza del cloud, dove si può lanciare più calcolo o memoria su un problema, i dispositivi edge operano all’interno di un envelope fisso. Ciò significa che si devono fare scelte deliberate basate sulle esigenze effettive dell’applicazione. Ad esempio, un sensore IoT potrebbe priorizzare l’efficienza energetica rispetto alle prestazioni brute, mentre un sistema autonomo potrebbe richiedere una latenza ultra-bassa indipendentemente dal consumo di potenza. Una volta stabilito il punto di lavoro, si può valutare se il processore abbia il giusto equilibrio di calcolo e memoria per soddisfare quel fabbisogno. Non si tratta di massimizzare le specifiche in ogni direzione; si tratta di garantire prestazioni sostenibili e affidabili nelle condizioni del mondo reale che l’applicazione affronterà.

In generale, il punto di lavoro è dove si desidera che gli indicatori di prestazione chiave siano al loro optimum. Non riuscire a farlo potrebbe risultare in un’operazione subottimale nelle condizioni di utilizzo più tipiche della piattaforma.

Come semplice esempio, si potrebbe rendere un sistema di analisi AI estremamente efficiente quando l’input è a risoluzione molto alta, ma se ciò viene distribuito in sistemi che non raggiungono mai questa risoluzione, tale ottimizzazione è priva di significato.

Con video, audio e linguaggio spesso mescolati in dispositivi moderni, come si approccia all’ottimizzazione across modelli multimodali?

I modelli multimodali richiedono un equilibrio attento di risorse di calcolo e memoria. Ogni modalità stressa il sistema in modo diverso: il video è intensivo in termini di calcolo a causa della risoluzione e dei frame rate elevati, mentre il linguaggio e l’audio sono più compatti ma pongono richieste più elevate in termini di larghezza di banda della memoria. In applicazioni come l’elaborazione linguaggio-visione, tale suddivisione diventa chiara (anche se ciò non è una garanzia ma uno scenario tipico): l’elaborazione del video spinge il calcolo, mentre il modello linguistico può rapidamente raggiungere i colli di bottiglia della memoria.

Ci avviciniamo all’ottimizzazione guardando come questi carichi di lavoro interagiscono lungo la pipeline e assicurandoci che il processore sia progettato per supportarli simultaneamente, senza far sì che una modalità comprometta le prestazioni di un’altra.

Come l’aumento delle dimensioni del modello sull’edge complica la latenza e il consumo di potenza, e quale ruolo gioca l’architettura a livello di sistema nel risolvere ciò?

Man mano che le dimensioni del modello aumentano sull’edge, la latenza e il consumo di potenza diventano più difficili da gestire. Modelli più grandi si affidano maggiormente alla memoria off-chip, il che aumenta sia il consumo energetico che il ritardo, specialmente quando la larghezza di banda della memoria diventa un collo di bottiglia. Ad esempio, scalare da un modello da 1 miliardo di parametri a uno da 4 miliardi di parametri richiederebbe più del quadruplo della larghezza di banda per mantenere le stesse prestazioni – ma nella pratica, le prestazioni non scalano linearmente a causa dei vincoli di larghezza di banda e di sistema.

Non si tratta solo di avere alto TOPS o grande memoria; si tratta di come queste componenti interagiscono. Una progettazione bilanciata garantisce che calcolo, memoria e larghezza di banda lavorino insieme in modo efficiente, evitando che una risorsa limiti l’intero sistema.

Come Hailo progetta per il future-proofing – considerando quanto rapidamente i modelli AI, i carichi di lavoro e i requisiti di deploy stanno evolvendo?

Il future-proofing nell’AI edge significa progettare processori che possano gestire una vasta gamma di carichi di lavoro in evoluzione. In Hailo, ci concentriamo su architetture bilanciate che non sono adattate solo a un compito ma possono supportare tutto, dalle funzioni percettive come la rilevazione di oggetti ai modelli generativi come VLM. Ogni tipo di carico di lavoro stressa il calcolo e la memoria in modo diverso, quindi progettiamo per la flessibilità, evitando i colli di bottiglia quando si passa tra loro. Consideriamo anche i limiti reali di potenza, costo e latenza attraverso le applicazioni. Priorizzando la diversità dei carichi di lavoro e l’equilibrio delle risorse, ci impegniamo a supportare la prossima generazione di deploy dell’AI edge in uso sia consumer che industriali.

Tuttavia, una sola dimensione non può adattarsi a tutto, e il portfolio mira a specifiche applicazioni e cerca di rientrare nel budget disponibile, ad esempio, di potenza, fattore di forma, e ciò definisce un “punto di lavoro”.

Quale ruolo gioca l’ecosistema degli sviluppatori nel massimizzare il valore di un processore, e come assicurate che le squadre possano sfruttare appieno le capacità di Hailo?

Come dispositivo programmabile, è essenziale avere strumenti facili da usare per gli sviluppatori per esercitare il potenziale del processore, accorciare il percorso verso il deploy e abilitare nuovi casi d’uso. Fornendo un ambiente ben supportato intorno ai nostri processori, aiutiamo le squadre a portare le applicazioni AI alla vita in una gamma di casi d’uso.

Qual consiglio darebbe agli ingegneri o ai CTO che scelgono il loro primo acceleratore AI per un prodotto next-gen costruito oggi?

Con le condizioni mature, credo che ci sia un grande potenziale di innovazione, che ci consente di tradurre l’immaginazione in prodotti reali. In un ambiente in rapida evoluzione, scegliere un acceleratore che consenta un ciclo di concept-to-deployment rapido è critico.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Hailo.