En transformer på 125 miljoner parametrar spelar piano direkt i telefonen

Utvecklaren Simon Edwardsson släppte den 20 augusti 2026 en gratis iOS-app som heter RollTab. Du spelar några noter på ett MIDI-piano och en modell på 125 miljoner parametrar fortsätter där du slutade. Ingen molnkoppling, inget konto, ingen väntan på en server. Genereringen sker på telefonen med runt 108 noter per sekund på en iPhone 15, vilket är snabbare än någon människa kan spela.

Jämförelsen som ligger närmast är GitHub Copilot. Du skriver några rader, verktyget föreslår resten, du accepterar eller ignorerar. Skillnaden är att musik inte har en grammatik som begränsar nästa steg.

Kod har regler, improvisation har inga

När Copilot föreslår nästa rad finns det en ändlig mängd giltiga fortsättningar. En parentes ska stängas, en variabel måste vara deklarerad, ett semikolon hör hemma på en viss plats. Språket självt sorterar bort de flesta felen innan modellen ens behöver gissa.

Musik fungerar tvärtemot. Efter ett C-mollackord kan nästa not vara nästan vad som helst och flera helt olika fortsättningar kan vara lika bra. Det bryter mot hela idén bakom nästa-token-träning, där modellen belönas för att förutsäga exakt det som stod i träningsdatan. En modell som lär sig att kopiera originalet blir bra på validationsloss och tråkig att lyssna på.

Precis det problemet är dokumenterat i akademisk forskning på symbolisk pianoinlärning. Ett aktuellt exempel är Aria-projektet, som skalar självövervakad representationsinlärning för pianoframföranden, där samma spänning mellan mätbar förlustfunktion och faktisk musikalisk kvalitet återkommer.

Tokeniseringen avgjorde om projektet skulle fungera

Här ligger det tekniskt intressanta och det är också där de flesta försöken gick i väggen. En MIDI-not består av flera saker samtidigt: tonhöjd, anslagsstyrka, när den börjar och när den slutar. Frågan är hur du packar in det i tokens som en transformer kan hantera.

Första ansatsen var eventbaserad tokenisering, där note-on, note-off, tonhöjd och velocity blev separata händelser. Ordförrådet svällde till 16 512 tokens och modellen började drifta, den glömde bort att stänga noter den öppnat. Andra ansatsen låste sekvenserna med en grammatik i stil med NOTE_ON, PITCH, VELOCITY. Driften försvann men varje enskild not krävde runt fyra pass genom transformern, vilket gjorde realtidsgenerering omöjlig.

Lösningen blev att representera hela noten som ett enda token: NOTE(pitch, delta_onset, duration, velocity). Fem kategoriska fält, varje fält med sin egen embedding och den slutliga noten är summan av dem. På utgångssidan finns separata heads för varje fält, plus en liten nästlad avkodare som låter senare fält villkoras på tidigare förutsagda fält. Ett pass, en hel not.

Sustainpedalen finns inte som eget begrepp i modellen. Effekten bakas in i notlängderna redan under preprocessing, vilket är en pragmatisk genväg som sparar både tokens och komplexitet.

Ackord fick också en egen lösning. Flera noter med delta_onset noll, sorterade efter tonhöjd, gör att C-E-G och E-G-C kodar till identisk tokensekvens. Modellen slipper lära sig att samma ackord kan skrivas på sex olika sätt.

Färre men renare MIDI-filer slog större dataset

Projektet tog ungefär ett år och fjorton experimentiterationer. Det som gav mest var inte mer data utan bättre data. Filtreringen sorterade bort allt som inte var rent pianomaterial: patologier i multitrack-filer, filer med för låg notdensitet eller för smal tonomfång, dubbletter identifierade via fingerprints som ignorerar global transponering och jämn tempoförändring.

Träningsdatan filtrerades dessutom på upprepade tonhöjds-n-gram, tonhöjdsentropi, ackordtäthet och långa pauser. Augmenteringen gick åt andra riktningen: transponering, tempoförändring, jitter i duration och velocity och borttagna promptnoter.

Direct Preference Optimization visade sig vara den enskilt viktigaste post-training-tekniken för musikalisk kvalitet.

Att DPO landar högst upp är logiskt. När det inte finns en korrekt fortsättning fungerar parvisa jämförelser bättre än absoluta poäng. Att fråga en modell ”vilken av dessa två låter bäst” gav mer användbar signal än att be den betygsätta enskilda utsnitt på en skala.

Listan över saker som inte fungerade är minst lika lärorik. Större modeller löste inte upprepningsproblemet av sig själva. Extra lokala hjälpförluster gjorde träningen långsammare utan hörbar vinst. Born-again networks, alltså omträning på modellens egna mjuka prediktioner, gav ingenting här. Mirostat dämpade upprepningarna men gjorde ofta resultatet osammanhängande. Scheduled sampling sänkte validationsloss samtidigt som den faktiska genereringen blev bättre, vilket är ett tydligt tecken på att metriken och upplevelsen dragit isär.

108 noter per sekund kräver att modellen hålls liten

Det är lätt att läsa 125M som ”en liten modell”. Jämför med molnbaserade språkmodeller är den mikroskopisk. Men i förhållande till uppgiften är den lagom och det är den viktiga poängen.

Kravet var enkelt att formulera och svårt att nå: modellen måste generera snabbare än en människa spelar. 108 noter per sekund efter kvantisering och export till CoreML klarar det med marginal. Hade samma arbete skickats till en server hade nätverksfördröjningen ensamt förstört upplevelsen, oavsett hur snabb servern var. Det finns problem där molnet är strukturellt fel plats, inte bara dyrare.

Två andra saker följer av att allt sker lokalt. Ditt spel lämnar aldrig telefonen, vilket gör dataskyddsfrågan trivial. Och batteriet slipper hålla en radiolänk uppe under hela sessionen.

Nästa steg för projektet handlar om att krympa avståndet mellan mediummodellen på 64 miljoner parametrar och den stora på 125 miljoner. Blir de närmare varandra i kvalitet kan appen bli mindre och latensen lägre. Andra idéer på listan är ett planeringssteg innan genereringen och att producera flera fortsättningar parallellt och välja den bästa. Samma sorts tänkande som präglar dagens AI-agenter, där loopen och verktygen betyder mer än modellens storlek.

Elva dagar i App Store-granskning

Distributionen var inte den tekniska delen men tog ändå tid. Första versionen låg elva dagar i granskning innan den godkändes. En uppdatering med fler samplingsstrategier, bland annat top-k, top-p, min-p, XTC, top-h och Mirostat v2, väntade på granskning i slutet av augusti 2026.

Vill du bygga något liknande själv och lägga det på din egen iPhone utan App Store krävs ett betalt Apple Developer-konto. Det är fortfarande den enda vägen till sideloading på iOS.

Projektet publicerades som ett Show HN-inlägg och är ingen kommersiell produkt. Det är värt att komma ihåg när man läser siffrorna: 125 miljoner parametrar och ett års kvällsarbete räckte för att flytta en generativ musikmodell från datacenter till fickan.

FAQ

Behöver jag ett MIDI-piano för att använda appen?

Modellen tar emot MIDI-noter som prompt, så någon form av MIDI-ingång är utgångspunkten. Appen heter RollTab och är gratis på iOS.

Är detta samma teknik som AI som skapar färdiga låtar?

Nej. Modellen är tränad på MIDI, alltså musikaliska händelser som tonhöjd och anslag, inte på ljudvågor. Den producerar noter som sedan spelas upp, inte ett färdigt ljudspår.

Varför fungerar validationsloss så dåligt som kvalitetsmått här?

Därför att det inte finns ett rätt svar. Validationsloss mäter hur nära modellen kommer den exakta fortsättningen i träningsdatan men i improvisation kan tio olika fortsättningar vara lika musikaliska. En modell som får låg loss kan mycket väl ha lärt sig att spela förutsägbart snarare än bra. Det var därför parvisa jämförelser och DPO gav mer än ytterligare loss-optimering.

Är idén med musikalisk autokomplettering ny?

Konceptet är äldre än datorerna. Ryska kompositörer i slutet av 1800-talet spelade ett sällskapsspel där en person började en fras och nästa skulle fortsätta den. Det som är nytt är att mönsterigenkänningen numera går att köra i en telefon.