What actually runs: a measurement study of language model placement and decode speed on the Apple Neural Engine
Door middel van een rigoureuze meetstudie naar de plaatsing van taalmodellen en de decodeersnelheid op de Apple Neural Engine, demonstreert de auteur dat computationele expressie en gewichtscodering, in plaats van enkel de modelarchitectuur, de verblijfplaats op de accelerator en de prestaties dicteren, wat leidt tot een ontwerpprocedure die prioriteit geeft aan coderingsefficiëntie om aanzienlijk kleinere en snellere ternaire modellen te bereiken.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je een smartphone voor die probeert een gesprek te begrijpen. Om dit te doen, moet de telefoon een massaal digitaal brein, een taalmodel, rechtstreeks op het apparaat draaien. Om dit soepel te laten verlopen, heeft de telefoon een speciale, ultrasnelle processor nodig die speciaal gebouwd is voor dit soort denken, in plaats van zijn algemene doelgerichte hoofdbrein. De uitdaging is dat deze speciale processor kieskeurig is; hij voert alleen bepaalde soorten berekeningen uit en weigert andere uit te voeren, zelfs als die wiskundig identiek zijn. Jarenlang hebben ontwikkelaars geprobeerd te raden welke berekeningen zouden werken en hoe ze snel zouden kunnen zijn, waarbij ze vaak vertrouwden op vuistregels die achteraf fout bleken te zijn. Ze namen aan dat als een model klein genoeg was, het op de snelle processor zou draaien, of dat het kleiner maken van de getallen altijd zou helpen. Maar niemand had de processor echt geobserveerd om te zien wat hij werkelijk aan het doen was, of om precies te meten hoe de grootte van het model en de manier waarop de getallen worden opgeslagen de snelheid veranderden.
Een onderzoeker genaamd Shahir M A besloot te stoppen met gissen en te beginnen met kijken. Met behulp van een Apple-computer met een M1-chip bouwde hij een reeks experimenten om precies te zien wat er gebeurt wanneer een taalmodel probeert te draaien op de speciale processor van de telefoon, de Neural Engine genoemd. Hij keek niet alleen naar wat de software zei dat het zou doen; hij mat de werkelijke elektriciteit en de data die door de chip bewogen om te zien wat er echt gebeurde. Hij testte tientallen verschillende manieren om dezelfde wiskundige operatie op te bouwen, trainde echte modellen van verschillende groottes en veranderde de manier waarop de getallen in die modellen werden opgeslagen, variërend van standaardprecisie tot zeer gecomprimeerde, laag-precisie formaten. Hun doel was simpel: uitzoeken wat een model daadwerkelijk op de snelle processor krijgt en hoe snel het kan spreken zodra het daar is.
Het eerste wat zij ontdekten was dat de processor niet geeft om wat een berekening betekent, maar alleen om hoe deze geschreven is. Ze ontdekten dat als je een specifiek type normalisatie — een stap die helpt de getallen van het model stabiel te houden — op één manier schrijft, de processor het onmiddellijk accepteert en op volle snelheid draait. Maar als je exact dezelfde wiskundige stap schrijft met een iets complexere set instructies, weigert de processor deze aan te raken en dwingt de telefoon om de tragere, algemene doelgerichte hersenen te gebruiken. Het is alsof de processor een specifiek wiskundig dialect spreekt; als je het juiste dialect gebruikt, luistert hij, maar als je een ander dialect gebruikt, zelfs als de betekenis hetzelfde is, loopt hij weg. Dit betekent dat de manier waarop een ontwikkelaar de code schrijft net zo belangrijk is als de wiskunde zelf.
De tweede, en misschien wel meest verrassende, bevinding was dat de grootte van het model niet het enige is dat bepaalt of het op de snelle processor kan draaien. De onderzoekers ontdekten dat een model met ongeveer zesentwintig miljoen parameters, geschreven in standaardprecisie, te klein was om überhaupt op de speciale processor te draaien. Het werd gedwongen om op het trage brein te draaien, waarbij het meer dan een seconde nodig had om elk woord te genereren. Echter, toen ze dat exactezelfde model pakten en de getallen binnenin comprimeerden om minder bits te gebruiken, accepteerde de processor het plotseling. De gecomprimeerde versie draaide op de snelle processor en genereerde woorden in minder dan een seconde. Sterker nog, voor kleinere modellen was het comprimeren van de getallen de enige manier om ze überhaupt op de snelle processor te krijgen. De processor had een verborgen regel: hij zou geen kleine modellen draaien, tenzij ze gecomprimeerd waren. Dit draaide de algemene aanname om dat grotere modellen juist degene zijn die de snelle processor nodig hebben; hier hadden de kleine modellen de compressie nodig om binnen te komen.
Zodra het model zich in de snelle processor bevond, werd de snelheid bijna volledig bepaald door hoeveel data er verplaatst moest worden, niet door hoe complex de wiskunde was. De onderzoekers maten de datastroom en ontdekten dat voor elk woord dat het model genereerde, de volledige set van zijn gewichten — de getallen die zijn kennis vormen — door de processor gestreamd moest worden. Dit gebeurde voor elk afzonderlijk woord, ongeacht hoe lang de conversatie ook duurde. Daarom was de snelheid direct gekoppeld aan hoeveel bits er in die gewichten zaten. Een model met gecomprimeerde, laag-precisie getallen verplaatste veel minder data en was daarom veel sneller. Ze ontdekten dat een model dat twee-bit getallen gebruikte, bijna drie keer sneller was dan een model met standaard getallen, simpelweg omdat het minder data hoefde te verplaatsen. Het type wiskunde dat het model gebruikte, zoals of het zich meer richtte op aandacht (attention) of op convolutie, deed er voor de snelheid nauwelijks toe zodra het model al op de processor draaide. Het enige dat telde, was de omvang van de verplaatste data.
De onderzoekers concludeerden dat de beste manier om een taalmodel voor een telefoon te bouwen, is door te beginnen met de compressie, niet met de grootte. In plaats van een groot model te bouwen en het daarna te proberen te verkleinen, zou men eerst de meest gecomprimeerde format mogelijk moeten kiezen, en vervolgens het beschikbare geheugenbudget gebruiken om meer parameters toe te voegen. Ze ontdekten dat een model met vijfentwintig miljoen parameters, gebruikmakend van een specifiek type gecomprimeerde wiskunde, in slechts tien megabyte aan ruimte paste en woorden in ongeveer zes tienden van een milliseconde genereerde. Dit was bijna tien keer kleiner en drie keer sneller dan de standaard, ongecomprimeerde modellen waar ontwikkelaars meestal mee beginnen. De studie toonde aan dat de weg naar een snel, on-device taalmodel niet gaat over het groter of complexer maken van het model, maar over het kiezen van de juiste manier om de wiskunde te schrijven en de juiste manier om de getallen op te slaan. Door de werkelijke datastroom te meten, bewezen ze dat de sleutel tot snelheid niet alleen het hebben van een snelle processor is, maar weten hoe je deze precies moet voeden.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.