What actually runs: a measurement study of language model placement and decode speed on the Apple Neural Engine
Attraverso uno studio di misurazione rigoroso sul posizionamento dei modelli linguistici e sulla velocità di decodifica sull'Apple Neural Engine, l'autore dimostra che l'espressione computazionale e la codifica dei pesi, piuttosto che l'architettura del modello da sola, dettano la residenza nell'acceleratore e le prestazioni, portando a una procedura di progettazione che privilegia l'efficienza della codifica per ottenere modelli ternari significativamente più piccoli e veloci.
Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
Immagina uno smartphone che cerca di comprendere una conversazione. Per farlo, deve eseguire un enorme cervello digitale, un modello linguistico, proprio sul dispositivo. Affinché questo funzioni fluidamente, il telefono deve utilizzare un processore speciale, ultra-veloce, costruito appositamente per questo tipo di pensiero, piuttosto che il suo cervello principale a uso generale. La sfida è che questo processore speciale è esigente; eseguirà solo certi tipi di calcoli e si rifiuterà di eseguirne altri, anche se questi ultimi sono matematicamente identici. Per anni, gli sviluppatori hanno cercato di indovinare quali calcoli funzioneranno e come renderli veloci, affidandosi spesso a regole empiriche che si sono rivelate errate. Hanno assunto che se un modello fosse stato abbastanza piccolo, sarebbe stato in grado di girare sul processore veloce, o che rendere i numeri più piccoli avrebbe sempre aiutato. Ma nessuno aveva effettivamente osservato il processore per vedere cosa stesse realmente facendo, o misurato esattamente come la dimensione del modello e il modo in cui i suoi numeri vengono memorizzati cambiassero la sua velocità.
Un ricercatore di nome Shahir M A ha deciso di smettere di indovinare e ha iniziato a osservare. Utilizzando un computer Apple con un chip M1, ha costruito una serie di esperimenti per vedere esattamente cosa accade quando un modello linguistico tenta di girare sul processore speciale del telefono, noto come Neural Engine. Non si è limitato a guardare ciò che il software diceva di fare; ha misurato l'elettricità e i dati reali che si muovevano attraverso il chip per vedere cosa stava realmente accadendo. Ha testato decine di modi diversi per costruire la stessa operazione matematica, ha addestrato modelli reali di diverse dimensioni e ha cambiato il modo in cui i numeri all'interno di questi modelli venivano memorizzati, spaziando dalla precisione standard a formati molto compressi a bassa precisione. Il suo obiettivo era semplice: scoprire cosa porti effettivamente un modello sul processore veloce e quanto velocemente può parlare una volta che ci riesce.
La prima cosa che ha scoperto è che il processore non si cura di cosa significhi un calcolo, ma solo di come sia scritto. Ha scoperto che se scrivi un tipo specifico di normalizzazione — un passaggio che aiuta il modello a mantenere stabili i suoi numeri — in un certo modo, il processore lo accetta immediatamente ed esegue al massimo della velocità. Ma se scrivi lo stesso identico passaggio matematico usando un insieme di istruzioni leggermente più complicato, il processore si rifiuta di toccarlo e costringe il telefono a usare il suo cervello più lento e generico. È come se il processore parlasse un particolare dialetto matematico; se usi il dialetto giusto, ascolta, ma se ne usi uno diverso, anche se il significato è lo stesso, se ne va. Questo significa che il modo in cui uno sviluppatore scrive il codice è importante quanto la matematica stessa.
La seconda scoperta, e forse la più sorprendente, è che la dimensione del modello non è l'unica cosa a decidere se può girare sul processore veloce. I ricercatori hanno scoperto che un modello con circa ventisei milioni di parametri, scritto in precisione standard, era troppo piccolo per girare sul processore speciale. Era costretto a girare sul cervello lento, impiegando più di un secondo per generare ogni parola. Tuttavia, quando hanno preso quello stesso modello e hanno compresso i numeri al suo interno per utilizzare meno bit, il processore lo ha improvvisamente accettato. La versione compressa girava sul processore veloce e generava parole in meno di un secondo. In effetti, per i modelli più piccoli, comprimere i numeri era l'unico modo per farli entrare nel processore veloce. Il processore aveva una regola nascosta: non avrebbe eseguito modelli piccoli a meno che non fossero compressi. Questo ribaltava l'assunto comune secondo cui i modelli più grandi sono sempre quelli che hanno bisogno del processore veloce; qui, i piccoli avevano bisogno della compressione per varcare la soglia.
Una volta che il modello era all'interno del processore veloce, la velocità era determinata quasi interamente da quanta informazione doveva essere spostata, non dalla complessità della matematica. I ricercatori hanno misurato il flusso di dati e hanno scoperto che per ogni parola generata dal modello, esso doveva trasmettere l'intero set dei suoi pesi — i numeri che costituiscono la sua conoscenza — attraverso il processore. Questo accadeva per ogni singola parola, indipendentemente da quanto lunga fosse la conversazione. Di conseguenza, la velocità era direttamente legata a quanti bit erano presenti in quei pesi. Un modello con numeri compressi a bassa precisione spostava molta meno informazione ed era quindi molto più veloce. Hanno scoperto che un modello che utilizzava numeri a due bit era quasi tre volte più veloce di un modello con numeri standard, semplicemente perché doveva spostare meno dati. Il tipo di matematica usato dal modello, come se si concentrasse maggiormente sull'attenzione o sulla convoluzione, contava pochissimo per la velocità una volta che era già in esecuzione sul processore. L'unica cosa che contava era la dimensione dei dati in movimento.
I ricercatori hanno concluso che il modo migliore per costruire un modello linguistico per un telefono è partire dalla compressione, non dalla dimensione. Invece di costruire un modello grande e poi cercare di rimpicciolirlo, si dovrebbe scegliere prima il formato più compresso possibile e poi dedicare il budget di memoria disponibile all'aggiunta di più parametri. Hanno scoperto che un modello con venticinque milioni di parametri, utilizzando un tipo specifico di matematica compressa, poteva occupare solo dieci megabyte di spazio e generare parole in circa sei decimi di millisecondo. Era quasi dieci volte più piccolo e tre volte più veloce dei modelli standard non compressi con cui gli sviluppatori di solito iniziano. Lo studio ha dimostrato che la strada per un modello linguistico veloce sul dispositivo non è rendere il modello più grande o più complesso, ma scegliere il modo giusto di scrivere la matematica e il modo giusto di memorizzare i numeri. Misurando l'effettivo flusso di dati, hanno provato che la chiave della velocità non è solo avere un processore veloce, ma sapere esattamente come nutrirlo.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.