Apple riapre un dibattito hardware: retrospettiva sul reverse engineering del Neural Engine di Apple

Il Neural Engine dell'M1 di Apple è tornato sotto esame, nonostante una pausa di tre anni nel progetto di driver Linux creato per comprenderlo. Retrospectively Reverse-Engineering Apple's Neural Engine documenta perché quell'acceleratore eccellesse nelle reti neurali di prima generazione, ma faccia fatica con gli attuali carichi di lavoro dei transformer.

Eileen Yoon, ex collaboratrice di Asahi Linux, è tornata sul lavoro abbandonato dopo che Apple ha cambiato direzione hardware. L'M5 colloca un Neural Accelerator all'interno di ogni core GPU, mantenendo al contempo un Neural Engine separato a 16 core. Questa combinazione mette in discussione l'idea che un unico acceleratore a funzione fissa debba gestire i crescenti carichi di lavoro di IA generativa di Apple.

Non si tratta solo di un'analisi hardware arrivata in ritardo. L'indagine collega le scelte fatte per le reti neurali convoluzionali del 2017, o CNN, alla risposta di Apple ai moderni modelli linguistici. Le GPU ora mettono sotto pressione il Neural Engine standalone perché i transformer dipendono da una pianificazione flessibile e da un movimento costante della memoria.

Un driver M1 inattivo è diventato un'autopsia hardware

Il nuovo lavoro trasforma un driver Linux incompiuto in un resoconto di ciò che Apple si aspettava originariamente che il machine learning diventasse.

Yoon aveva in precedenza sviluppato un driver Linux ANE in grado di comunicare con il Neural Engine all'interno dei chip M1. Il progetto includeva un modulo kernel, una libreria userspace, test e binding Python. Offriva un percorso alternativo all'astrazione software pubblica di Apple, pur non rendendo l'hardware ampiamente programmabile.

Il progetto è poi rimasto inattivo per tre anni. Yoon scrive che l'ANE sembrava troppo specializzato per giustificare ulteriori lavori sul driver. Aprire la sua interfaccia hardware non avrebbe cambiato quali operazioni il suo datapath fisso potesse eseguire in modo efficiente.

Questa distinzione è importante. Un driver convenzionale può esporre capacità che l'hardware già possiede. Non può trasformare un acceleratore di dataflow progettato per uno scopo specifico in un processore generico.

La retrospettiva architetturale di Yoon pone quindi una domanda diversa rispetto al lavoro originale sul driver. Invece di chiedersi come Linux possa inviare il lavoro, esamina l'array di calcolo, lo scheduler, il sistema di memoria e il modello di esecuzione. Questi componenti rivelano le ipotesi sui carichi di lavoro incorporate nel progetto dell'M1.

L'indagine descrive 16 core di calcolo disposti attorno a un blocco centrale di memoria locale. Ogni core contiene unità parallele multiply-accumulate, o MAC, che moltiplicano gli input e aggiungono i risultati agli accumulatori. Queste operazioni sono alla base delle convoluzioni, della moltiplicazione di matrici e dei prodotti scalari usati dai meccanismi di attenzione.

Le unità MAC non spiegano da sole la specializzazione del Neural Engine. Sia le CNN sia i transformer necessitano di moltiplicazioni e accumuli. La differenza decisiva risiede nel modo in cui pesi e attivazioni raggiungono tali unità, restano disponibili e si muovono attraverso il chip.

Apple ha introdotto il suo primo Neural Engine con A11 Bionic nel 2017. All'epoca, le reti neurali consumer si concentravano sulla classificazione delle immagini, l'analisi facciale e altri carichi di lavoro CNN densi. Quelle reti offrivano forme dei tensori regolari e un riutilizzo prevedibile.

L'M1 ha ereditato questa linea progettuale quando Apple ha portato i propri processori sul Mac. Il suo Neural Engine era ottimizzato per modelli compilati le cui dimensioni e schemi di movimento erano in larga misura noti in anticipo. Tale specializzazione riduceva latenza e consumo energetico per i carichi supportati.

La retrospettiva non sostiene che il Neural Engine dell'M1 non possa eseguire operazioni dei transformer. Sostiene che il dataflow circostante renda inefficienti alcuni schemi dei transformer, in particolare la decodifica autoregressiva. Questo processo genera un token alla volta, rileggendo ripetutamente i pesi del modello e una cache di attenzione in crescita.

Questa nuova prospettiva crea la tensione centrale dell'articolo. Apple ha costruito un motore efficiente vincolando il movimento dei dati attorno a un carico di lavoro previsto. L'IA moderna ha cambiato il carico di lavoro dominante più rapidamente di quanto potesse cambiare un'architettura hardware fissa.

Retrospectively Reverse-Engineering Apple's Neural Engine mette in luce il vincolo reale

La limitazione distintiva del Neural Engine dell'M1 non è la capacità aritmetica; è il percorso che i dati devono seguire attorno a tale capacità di calcolo.

Il driver sottoposto a reverse engineering non invia direttamente all'hardware comandi di alto livello come CONV, MATMUL o RELU. Il compilatore di Apple ha già convertito tali operazioni neurali in descrittori di attività prima dell'avvio dell'esecuzione.

Un descrittore di attività è un blocco strutturato di dati di configurazione. Programma gruppi di registri che controllano dimensioni dei tensori, indirizzi di memoria, funzioni di attivazione, dipendenze e trasferimenti di dati. Il driver colloca il descrittore in memoria, indirizza il gestore delle attività verso di esso e attiva un "campanello" hardware.

Dopo l'invio, il Neural Engine controlla il processo fino al completamento. Genera un interrupt al termine dell'attività. Il processore host non dirige ogni singola istruzione matematica mentre l'operazione è in esecuzione.

Yoon conclude che l'ANE non dispone di un set di istruzioni nel senso familiare di CPU o GPU. I suoi descrittori di attività configurano un datapath specifico per il dominio, anziché fornire un programma arbitrario. Ogni descrittore rappresenta un passaggio attraverso quel datapath.

L'attività inizia caricando i registri di configurazione. Blocchi di trasferimento dedicati spostano quindi pesi e attivazioni in input dalla memoria principale a store locali separati. I core di calcolo eseguono riduzioni, il post-processing applica un'attivazione e un altro blocco di trasferimento restituisce il risultato.

Questa sequenza favorisce le operazioni con riutilizzo prevedibile. Una convoluzione può applicare lo stesso insieme compatto di filtri appresi a molte regioni dell'immagine. L'acceleratore può mantenere occupate le sue corsie aritmetiche senza recuperare ripetutamente un nuovo e ampio insieme di pesi.

La decodifica dei transformer modifica questo equilibrio. Ogni nuovo token può richiedere lo streaming attraverso una parte sostanziale dei parametri del modello. L'aritmetica resta riconoscibile, ma il movimento dei dati diventa il costo limitante.

Il layout dell'M1 aggrava il problema perché separa la memoria usata per i pesi dalla memoria locale usata per i tile di attivazione. Yoon identifica circa 1 MiB di memoria kernel e 2 MiB di memoria tile nel progetto. L'indagine sostiene che l'architettura non fosse predisposta per reinterpretare efficientemente come pesi i tensori prodotti localmente.

Era un'ipotesi ragionevole per i modelli presi di mira da Apple nel 2017. L'inferenza CNN tratta generalmente i pesi appresi come kernel fissi e le attivazioni come dati che fluiscono tra i livelli. L'attenzione dei transformer attenua questa distinzione, poiché i valori prodotti durante l'esecuzione possono alimentare successive operazioni matriciali.

Una cache chiave-valore illustra il problema. La cache conserva le rappresentazioni dei token precedenti affinché il modello possa riutilizzarle durante la generazione. Il suo contenuto cresce man mano che la conversazione o il documento si allungano, rendendo sempre più importante un accesso efficiente alla memoria.

Le dimensioni fisse dei tensori non sono l'ostacolo principale. Un'attività compilata può eseguire cicli su una lunghezza della cache variabile e l'overhead di invio dell'attività può restare ridotto. Il problema più difficile è alimentare ripetutamente i dati attraverso percorsi progettati attorno al riutilizzo delle CNN.

Ecco perché le cifre sulle operazioni al secondo offrono un confronto incompleto. Il throughput aritmetico di picco descrive quanto velocemente l'array MAC possa lavorare in condizioni favorevoli. Non rivela con quale frequenza tali unità restino in attesa di pesi, attivazioni o risultati intermedi.

Ricerche indipendenti sono giunte a una conclusione compatibile da una prospettiva diversa. Il paper di ricerca Orion del 2026 descrive 20 vincoli incontrati programmando l'ANE tramite interfacce private. I suoi autori identificano compilazione, layout della memoria e comportamento numerico come ostacoli pratici.

Orion riporta comunque risultati significativi sui transformer. Su un M4 Max, il sistema ha prodotto oltre 170 token al secondo per GPT-2 con 124 milioni di parametri. Ha inoltre addestrato un modello da 110 milioni di parametri per 1.000 passaggi in 22 minuti.

Queste misurazioni mostrano che l'ANE può eseguire carichi di lavoro di modelli linguistici. Non ne dimostrano il primato come destinazione migliore per ogni modello di grandi dimensioni o per ogni fase dell'inferenza. La distinzione tra possibilità tecnica e adeguatezza architetturale resta essenziale.

Il software pubblico di Apple mantiene l'hardware a distanza

Gli sviluppatori possono richiedere il Neural Engine tramite Core ML, ma Apple continua a controllare come i carichi di lavoro vengono compilati, suddivisi e distribuiti.

Apple espone il Neural Engine principalmente tramite Core ML, il suo framework pubblico per distribuire modelli di machine learning. Gli sviluppatori forniscono un modello compatibile, mentre il framework decide se le singole operazioni debbano usare CPU, GPU o Neural Engine.

I controlli delle unità di calcolo di Apple consentono a un'applicazione di permettere combinazioni di tali processori. Uno sviluppatore può consentire ogni unità disponibile o escludere GPU o Neural Engine. L'interfaccia pubblica non offre la programmazione diretta dei descrittori di attività dell'ANE.

Questo modello protegge la portabilità tra i dispositivi Apple. Un'applicazione può descrivere la previsione di cui ha bisogno senza codificare il layout dei registri di una singola generazione di chip. Apple può rivedere compilatori e politiche di pianificazione mantenendo stabile l'interfaccia applicativa.

Il compromesso è la visibilità. Gli sviluppatori non possono fare affidamento su Core ML affinché collochi ogni operazione supportata su uno specifico motore. Né possono ispezionare il programma finale di basso livello con il controllo atteso dalle API di calcolo GPU.

Apple spiega che l'esecuzione di Core ML può usare CPU, GPU e Neural Engine, riducendo al contempo il consumo di memoria e di energia. Questo approccio è appropriato per le applicazioni che cercano un'inferenza efficiente sul dispositivo senza ottimizzazioni specifiche per l'hardware.

È meno soddisfacente per i ricercatori che indagano i limiti architetturali. Un benchmark potrebbe ricorrere a un altro processore, suddividere un grafo tra processori o incontrare trasformazioni del compilatore che oscurano il comportamento dell'hardware sottostante.

Il lavoro di reverse engineering rimuove parte di questa incertezza. Esamina descrittori di attività, scritture nei registri, code, interrupt e percorsi della memoria al di sotto di Core ML. Questa visuale aiuta a distinguere le restrizioni imposte dal software dai vincoli creati dal silicio.

Tuttavia, le interfacce private creano la propria incertezza. Non dispongono delle garanzie pubbliche di compatibilità di Apple e possono cambiare con un aggiornamento del sistema operativo. Il codice di ricerca che funziona oggi potrebbe fallire dopo che cambiano il compilatore, il formato del modello o il servizio runtime.

Questo divario colloca Apple in una posizione insolita. L'azienda distribuisce hardware dedicato al machine learning su telefoni, tablet, Mac e visori. Tuttavia, gli sviluppatori indipendenti hanno un controllo limitato su uno dei blocchi più distintivi all'interno di questi processori.

Per le applicazioni mainstream, questa limitazione può essere una scelta intenzionale di prodotto. Apple ottimizza il dispositivo nel suo complesso e decide dove viene eseguita ogni operazione. La maggior parte degli sviluppatori trae maggiore vantaggio da una distribuzione prevedibile che dall'accesso diretto ai registri.

Gli sviluppatori di IA generativa spesso hanno bisogno dell'opposto. Sperimentano con formati di quantizzazione, kernel di attenzione, layout della cache e operazioni fuse. Confrontano inoltre le prestazioni tra architetture di modelli in rapido cambiamento.

Le GPU consentono questa sperimentazione perché i loro modelli di programmazione espongono capacità di calcolo più generali. Gli sviluppatori possono implementare nuovi kernel senza attendere un percorso del compilatore dedicato. Il prezzo da pagare è una maggiore responsabilità per sincronizzazione, accesso alla memoria e ottimizzazione delle prestazioni.

Il Neural Engine standalone rappresenta l'altro estremo dello spettro. Il suo compilatore e il percorso dati fisso possono garantire un'esecuzione efficiente quando un modello vi si adatta. Quando il carico di lavoro cambia, la specializzazione diventa un vincolo anziché un vantaggio.

La strategia software di Apple impedisce agli sviluppatori di risolvere direttamente questa tensione. Core ML può nascondere le differenze hardware, ma non può far comportare un sistema di memoria orientato alle CNN come una GPU flessibile. Il reverse engineering mette in luce il confine che il framework normalmente nasconde.

M5 rende la GPU il principale contendente

M5 di Apple non elimina il Neural Engine standalone, ma assegna alla GPU un ruolo più diretto nella roadmap AI dell'azienda.

Apple ha annunciato M5 nell'ottobre 2025 con una GPU a 10 core contenente un Neural Accelerator in ogni core. Il chip ha inoltre mantenuto un Neural Engine migliorato a 16 core. Questo design colloca hardware specializzato per le matrici su entrambi i lati del confronto architetturale.

Secondo l'annuncio del chip M5 di Apple, la nuova GPU offre oltre quattro volte le prestazioni di calcolo AI di picco della GPU M4. Apple ha inoltre portato la larghezza di banda della memoria unificata a 153GB/s, quasi il 30 percento in più rispetto a M4.

Si tratta di misurazioni controllate da Apple e i dettagli del carico di lavoro determinano le prestazioni reali nelle applicazioni. Tuttavia, la posizione dei nuovi acceleratori è più rivelatrice del moltiplicatore riportato nei titoli. Apple li ha inseriti nei core GPU programmabili anziché affidarsi esclusivamente al Neural Engine separato.

La GPU combina l'esecuzione specializzata di matrici con un ambiente già adatto ad algoritmi in evoluzione. Apple afferma che gli sviluppatori possono programmare i Neural Accelerators tramite API tensoriali in Metal 4. Questo offre un percorso pubblico verso carichi di lavoro AI basati su GPU senza esporre il formato privato dei comandi dell'ANE standalone.

Yoon interpreta questo cambiamento come l'inizio della fine per l'NPU standalone, ovvero la neural processing unit. La formulazione è volutamente provocatoria e le decisioni di prodotto di Apple non confermano ancora un effettivo ritiro.

M5 include ancora un Neural Engine separato. Apple lo descrive come più veloce e lo associa a funzioni di sistema, tra cui l'elaborazione delle foto e la generazione di Persona spaziali. Queste attività ricordano i carichi di inferenza delimitati e prevedibili che gli acceleratori dedicati gestiscono bene.

La conclusione più difendibile è più circoscritta. Apple ora considera la GPU una destinazione primaria per carichi di lavoro di IA generativa impegnativi, mentre il Neural Engine mantiene un ruolo nell'inferenza di sistema efficiente.

Questa divisione corrisponde alle prove emerse dal reverse engineering. Una GPU può combinare l'accelerazione delle matrici con operazioni di memoria flessibili, kernel generici e accesso diretto per gli sviluppatori. Una NPU a funzione fissa può ridurre al minimo l'overhead per grafi stabili con modelli di esecuzione noti.

Nessuno dei due design vince in ogni carico di lavoro. Un processore generico dedica area ed energia al supporto della flessibilità che una pipeline fissa evita. Un motore specializzato perde adattabilità quando i modelli richiedono nuovi modelli di movimentazione dei dati.

M5 suggerisce che Apple voglia entrambi. Il suo Neural Engine separato può supportare funzioni on-device consolidate, mentre i GPU Neural Accelerators puntano ai modelli i cui operatori e comportamenti della memoria continuano a cambiare.

Questa strategia ibrida mette anche sotto pressione lo stack software di Apple. Core ML deve scegliere tra processori sempre più capaci. Metal deve offrire agli sviluppatori un controllo sufficiente per sfruttare le nuove unità GPU. Il compilatore deve evitare di spostare dati tra processori così spesso che i costi di trasferimento annullino l'accelerazione.

La pressione, quindi, non riguarda semplicemente Nvidia contro Apple, o macOS contro Linux. È una competizione all'interno del silicio Apple tra efficienza a funzione fissa e accelerazione programmabile.

Questa competizione è iniziata molto prima dell'IA generativa. I chip Apple già dividono il lavoro tra CPU, GPU, motori multimediali, processori d'immagine e hardware di sicurezza. La differenza ora è che il design dei modelli AI cambia a un ritmo che rende particolarmente rischiosi i lunghi cicli di pianificazione hardware.

Un blocco dedicato può richiedere anni per essere progettato e convalidato. Le architetture Transformer, le varianti dell'attenzione e le tecniche di quantizzazione possono cambiare nel giro di mesi. Integrare un'accelerazione più adattabile nella GPU riduce il costo di fare previsioni errate.

Il reverse engineering non dimostra che il Neural Engine sia finito

La retrospettiva spiega un disallineamento architetturale, ma non può stabilire il futuro piano di prodotto di Apple né misurare ogni implementazione ANE più recente.

Le scoperte più approfondite riguardano la generazione M1. Da allora Apple ha distribuito diverse famiglie di processori e i dettagli interni possono cambiare senza documentazione pubblica. Le conclusioni sui chip successivi richiedono misurazioni dirette, non somiglianze visive o nomi di marketing.

Yoon riconosce l'incertezza in alcune parti dell'analisi del layout fisico. Le immagini del die possono rivelare i principali blocchi di memoria e strutture di calcolo ripetute, ma non spiegano ogni decisione di instradamento. Alcune conclusioni restano interpretazioni informate.

L'indagine si concentra inoltre sulla struttura hardware anziché su un benchmark applicativo completo. Mostra perché il movimento della memoria dovrebbe limitare determinati carichi di lavoro. Non confronta ogni modello su ANE, GPU e CPU con limiti di potenza identici.

Orion fornisce utili misurazioni più recenti, ma utilizza API private e software di ricerca. I suoi esperimenti con GPT-2 e TinyStories dimostrano accesso e capacità, non un'ampia maturità produttiva per gli attuali modelli linguistici di grandi dimensioni.

Un altro progetto open ha segnalato l'addestramento diretto tramite interfacce private sottoposte a reverse engineering. Le sue misurazioni su M4 collocano il throughput FP16 intorno a 18,6 trilioni di operazioni al secondo e quello INT8 intorno a 35,1 trilioni di operazioni al secondo. Questi dati dipendono dalle configurazioni di convoluzione selezionate e non dovrebbero essere generalizzati a modelli completi.

La maturità del software conta quanto l'hardware. Un compilatore altamente ottimizzato può ristrutturare i grafi, fondere le operazioni e ridurre i trasferimenti. Un driver di ricerca potrebbe esporre correttamente il motore lasciando però inutilizzata gran parte delle prestazioni.

Vale anche il rischio opposto. I microbenchmark di picco possono mantenere occupate le unità aritmetiche in condizioni ideali, nascondendo al contempo i colli di bottiglia dei modelli reali. Latenza end-to-end, uso della memoria, consumo energetico e tempo di compilazione determinano se un acceleratore aiuta un'applicazione.

Apple potrebbe inoltre riprogettare il Neural Engine standalone mantenendone il nome commerciale. Memoria condivisa più ampia, percorsi dati rivisti o nuovi formati dei task potrebbero affrontare le limitazioni riscontrate in M1. L'annuncio di M5 non rivela quel livello di dettaglio.

La sicurezza offre un'altra ragione per un accesso controllato. Apple usa l'hardware del Neural Engine in flussi biometrici protetti. La sua documentazione sulla sicurezza della piattaforma descrive ripristini dello stato e controlli della memoria per un funzionamento sicuro del Neural Engine sui sistemi più recenti.

Questo ruolo non richiede di aprire lo stesso hardware a carichi di lavoro Linux arbitrari. Significa inoltre che la presenza continua del blocco può riflettere un'architettura di sistema che va oltre i modelli linguistici destinati ai consumatori.

L'efficienza energetica resta un altro confronto mancante. La decodifica autoregressiva può funzionare più naturalmente su hardware GPU programmabile, ma un motore dedicato può comunque superarla per attività di visione, audio e classificazione. Apple vende dispositivi alimentati a batteria, nei quali questi risparmi contano.

L'affermazione credibile, dunque, non è che il Neural Engine sia morto. È che le sue ipotesi progettuali originali non coprono più l'intera gamma dei carichi di lavoro AI strategicamente importanti.

Questa distinzione mantiene Retrospectively Reverse-Engineering Apple's Neural Engine ancorato alle prove. Il progetto illumina un bivio architetturale, mentre le versioni dei prodotti Apple determineranno fino a che punto l'azienda seguirà ciascuna strada.

Tre segnali mostreranno quale architettura vince

Le prossime API, i benchmark e i layout dei chip Apple riveleranno se il Neural Engine M1 fosse un modello durevole o un ramo specializzato.

Il primo segnale è l'accesso degli sviluppatori ai Neural Accelerators della GPU M5. Metal 4 deve esporre utili operazioni tensoriali senza nascondere così tanta pianificazione da lasciare i ricercatori davanti a un'altra scatola nera.

Strumenti funzionanti rafforzeranno l'ipotesi che Apple abbia scelto l'accelerazione GPU programmabile per modelli in rapida evoluzione. API limitate o supporto ristretto degli operatori indebolirebbero tale interpretazione e conserverebbero un ruolo più ampio per l'hardware gestito da Core ML.

Il secondo segnale sono le prestazioni end-to-end su carichi di lavoro Transformer rappresentativi. Confronti utili devono includere elaborazione dei prompt, generazione di token, comportamento della memoria con contesti lunghi, consumo energetico e tempo di caricamento del modello.

I soli microbenchmark non risolveranno la questione. Un processore può primeggiare nel throughput delle matrici, perdendo però tempo nei trasferimenti dei pesi, nello spostamento della cache o nella compilazione del grafo. Le misurazioni dovrebbero inoltre identificare quale unità di calcolo abbia eseguito ciascuna operazione.

I risultati delle applicazioni M5 saranno particolarmente importanti. Modelli linguistici locali e software di diffusione possono testare i nuovi acceleratori GPU con i carichi di lavoro che Apple ha esplicitamente evidenziato. Miglioramenti costanti convaliderebbero la scelta di spostarsi verso l'accelerazione all'interno di core programmabili.

Il terzo segnale è l'architettura del prossimo Neural Engine standalone di Apple. Apple può mantenere l'etichetta a 16 core modificando sotto di essa dimensione della memoria, interconnessioni, pianificazione e precisioni supportate.

Un sistema di memoria locale riprogettato metterebbe in discussione l'idea che il blocco standalone si stia avvicinando alla fine. Cambiamenti minimi, uniti a investimenti GPU maggiori, sosterrebbero l'interpretazione di Yoon.

I progressi di Linux offrono un percorso di verifica secondario. La comunità Asahi vanta una vasta esperienza nella documentazione del silicio Apple attraverso osservazione e sperimentazione clean-room. Il suo lavoro di reverse engineering ha già prodotto driver open per altri blocchi non documentati.

Un driver ANE utilizzabile consentirebbe ai ricercatori di confrontare le scelte di Core ML con l'invio diretto dei task. Potrebbe inoltre rivelare se compilatori alternativi riescano a recuperare prestazioni che il framework pubblico di Apple lascia inaccessibili.

Tuttavia, il supporto Linux non dovrebbe essere scambiato per il principale risultato commerciale. Il driver conta perché trasforma il comportamento di hardware nascosto in prove verificabili. I dispositivi, i framework e i carichi di lavoro di Apple determineranno il futuro dell'architettura.

Gli sviluppatori dovrebbero osservare dove Apple colloca la nuova programmabilità pubblica. Dovrebbero inoltre separare il throughput teorico dalle prestazioni complete dell'applicazione. Il processore con il numero più alto nei titoli non è necessariamente quello che sposta i dati del modello in modo efficiente.

I team che conducono indagini tecniche simili hanno bisogno di una registrazione duratura di esperimenti, risultati sui registri, benchmark e ipotesi scartate. Una base di conoscenza ingegneristica ricercabile può mantenere queste prove collegate man mano che strumenti e generazioni di chip cambiano.

Retrospectively Reverse-Engineering Apple's Neural Engine cattura infine un raro momento in cui il vecchio silicio spiega una nuova strategia. M1 mostra i benefici e i costi di incorporare ipotesi sulle CNN nell'hardware. M5 mostra Apple aggiungere flessibilità senza abbandonare immediatamente la specializzazione.

La prossima domanda è concreta: i futuri chip Apple espanderanno l'accelerazione GPU programmabile lasciando il Neural Engine a compiti di sistema stabili, oppure Apple ricostruirà il blocco standalone per i Transformer? Osservate le API e il comportamento della memoria, non soltanto il dato TOPS.