Optimering av slutledning på enheten för Apple Silicon

Hybridberäkning på Apple silicon samordnar en uppgift mellan intelligens på gränsen i molnet och en lokal modell på Macen. Molnmodeller hanterar forskning och resonemang, medan en lokal modell arbetar med privata filer och appar på Macen.

För att denna arbetsfördelning ska kännas sömlös måste den lokala inferensen hålla jämna steg med resten av uppgiften. Det kräver en motor som snabbt kan bearbeta prompter och upprätthålla en hög tokengenereringstakt.

Lily, vår lättviktsmotor för lokal slutledning, är byggd specifikt för Apple Silicon och Qwen3.6-35B-A3B, med separata optimeringar för förfyllning och avkodning. En fristående demo finns tillgänglig offentligt på GitHub.

Introduktion

Ett vanligt sätt att köra LLM:er på en Mac är med MLX, Apples maskininlärningsramverk med öppen källkod för Apple silicon. Dess tillhörande bibliotek, MLX-LM, lägger till de komponenter som behövs för att läsa in och generera text med ett brett utbud av språkmodeller. Tillsammans utgör MLX och MLX-LM en färdig, generell stack för lokal LLM-inferens.

Qwen3.6-35B-A3B är en sparsam hybridmodell: den använder mixture-of-experts-routing (MoE) och kombinerar rekursiva tillstånd med fast storlek och fullständig attention. Dessa arkitekturval minskar mängden beräkningar som krävs, men de skapar också oregelbundna arbetsbelastningar. Token dras till olika expertvikter, och rekursiva tillstånd är till sin natur sekventiella.

MLX-LM väljer redan optimerade kärnor för inferensfaser och vanliga arbetsbelastningsformer, men dess återanvändbara operationer måste stödja många modellarkitekturer. En motor som är dedikerad till Qwen kan specialisera sig på modell- och körtidsnivå och koordinera kärnor, dataförflyttningar och schemaläggning kring modellens fasta struktur.

Lily implementerar denna specialisering från ende till ende i en enda process. En Rust-körtid läser in modellkontrollpunkten och hanterar sessionstillståndet och genereringsloopen, ett OpenAI-kompatibelt chat-completions-API accepterar förfrågningar och strömmar token, och anpassade Metal-kärnor exekverar Qwen-specifika operationer. Varken PyTorch eller MLX finns i exekveringsvägen.

Förstora

Vi mäter prestanda för förfyllning och avkodning separat. Förfyllningsgenomströmningen fångar upp hur snabbt motorn bearbetar prompten; avkodningsgenomströmningen fångar upp hur snabbt den genererar utdatatoken.

Vi benchmarkar Qwen3.6-35B-A3B på en enda MacBook Pro utrustad med en M5 Max med en 40-kärnig GPU och 128 GB enhetligt minne. Över tio promptlängder för prefill och tio kontextlängder för decode, från 256 till 128K tokens (K = 1 024), uppnår motorn i genomsnitt 1,22× MLX-LM:s prefill-genomströmning och 1,32× dess decode-genomströmning. Vid en prompt på 4K tokens och en decode-kontext på 4K tokens når den anpassade motorn 5 749,9 prefill-tokens per sekund och 186,6 decode-tokens per sekund, jämfört med 4 737,5 och 140,9 för MLX-LM. Över en flerstegssession ackumuleras dessa tidsbesparingar för varje ytterligare modellanrop.

Förstora

Därefter förklarar vi hur Qwens arkitektur skapar modellspecifika optimeringsmöjligheter på Apple silicon. Sedan går vi igenom de resulterande ändringarna för förfyllning och avkodning. Vi tar också upp var ytterligare optimering slutar löna sig, innan vi avslutar med en jämförelse från ende till ende mot MLX-LM.

Qwen-specifika optimeringsmöjligheter på Apple silicon

Qwen skapar tre distinkta arbetsbelastningsformer

Qwen3.6-35B-A3B innehåller 35 miljarder parametrar men aktiverar endast cirka 3 miljarder för varje token. En router poängsätter 256 expertsundernet och väljer åtta, vid sidan av en delad expert som bearbetar varje token. Denna glesa MoE-design minskar beräkningar men producerar ojämnt arbete: experter tar emot olika antal token, och varje token kräver vikter från en annan kombination av experter.

Qwen kombinerar dessutom 10 lager med fullständig attention med 30 Gated DeltaNet-lager. Dessa två lagertyper behåller tidigare information på olika sätt.

Attention-lagren använder grouped-query attention (GQA). Qwen har 16 query-huvuden och två key-value-huvuden (KV), där åtta query-huvuden delar på varje KV-huvud. Delning gör KV-cachen mindre och gör att cachade data kan återanvändas över query-huvuden. Cachen lagrar ändå nya nycklar och värden för varje token, så varje avkodningssteg läser mer data i takt med att kontexten växer.

Gated DeltaNet komprimerar i stället tidigare information till ett rekursivt tillstånd med fast storlek. En inlärd grind styr hur mycket av det befintliga tillståndet som ska behållas, medan en delta-uppdatering införlivar information från den aktuella token. Modellen definierar dessa uppdateringar rekursivt, så varje token beror på det tillstånd som producerades av den föregående token. Vid förfyllning kan en motor dock utvärdera samma beräkning på två sätt. Den kan söka igenom token direkt samtidigt som tillståndet förs vidare, eller omorganisera uppdateringarna i block som exponerar fler matrisoperationer och token-nivåparallellism. Vilket tillvägagångssätt som är snabbast beror på modellens dimensioner, arbetsbelastning och hårdvara.

Tillsammans skapar dessa strukturer tre beräkningsmönster: ojämna expertgrupper, attention över ett växande cacheminne och en rekursionscykel med fast storlek som kan utvärderas direkt eller i block.

Apple silicon tillhandahåller olika vägar för olika arbetsbelastningar

Förfyllning bearbetar många prompttokenaktiveringsrader samtidigt. Den lokala arbetsbelastning som beaktas här avkodar typsikt en förfrågan i taget (batch 1) och bearbetar en ny rad per steg. Denna skillnad ändrar hur samma modellvikter används. Förfyllning kan återanvända varje block av vikter över hundratals eller tusentals rader. Avkodning kan till stor del inte göra det, eftersom varje ny token kräver en ny genomkörning av vikterna.

Apple silicon placerar CPU och GPU bakom enhetligt minne, en enda fysisk minnespool som är tillgänglig för båda. Detta gör att modellen kan förbli resident utan att en separat GPU-kopia underhålls, men det gör inte dataförflyttning gratis. Att läsa vikter och mellanliggande värden förbrukar fortfarande minnesbandbredd, medan register och annan on-chip-lagring är snabbare men mycket mindre.

M5-GPUn tillhandahåller också olika beräkningsvägar. Förfyllningens linjära lager använder generell matris-matris-multiplikation (GEMM), där en vikmatris tillämpas på många rader samtidigt. Kompatibla GEMM kan använda Neural Accelerator i varje GPU-kärna genom Metal 4-tensoroperationer. Batch-1-avkodning använder i stället generell matris-vektor-multiplikation (GEMV), där samma vikter tillämpas på en rad. Med lite återanvändning av vikter begränsas GEMV främst av minnesbandbredd och passar bättre för GPU:ns vektor-ALUer (aritmetiskt logiska enheter) än för Neural Accelerators som är utformade för matrisoperationer med större dataåteranvändning.

Dessa exekveringsvägar är inte unika för Lily. MLX arbetar över samma enhetliga minne och väljer optimerade matris- och vektorkärnor beroende på arbetsbelastningens form. MLX-LM:s Qwen-implementering grupperar redan expertarbete, utvärderar Gated DeltaNet med en sammanslagen rekursiv Metal-kärna och använder GQA-medveten attention. Dessa funktioner är den gemensamma startpunkten för effektiv Qwen-inferens på Apple silicon.

Optimeringsstrategi

Lilys smalare omfattning gör det möjligt att koordinera dessa delade exekveringsvägar kring Qwens exakta arkitektur och dimensioner. Den använder fasespecifika GPU-vägar, mappar Qwens expert-, rekursions- och attention-arbetsbelastningar för att minimera dataförflyttningar, och väljer kärnor och layouter utifrån den uppmätta arbetsbelastningsformen. Strategin har tre delar:

1. Matcha GPU-vägen till inferensfasen. Använd matrisorienterad exekvering när förfyllning kan återanvända vikter över många rader, och vektororienterad exekvering när batch-1-avkodning bearbetar en rad i taget.
2. Mappa Qwens struktur på GPUn samtidigt som dataförflyttningar minimeras. Håll vikterna komprimerade tills de används, organisera dirigerat expertarbete utan att återvända till CPU:n, behåll Gated DeltaNet-tillståndet on-chip genom dess rekursiva sökning och återanvänd KV-data som delas av grouped-query attention.
3. Anpassa kärnor till arbetsbelastningens form. Välj tile-storlekar, exekveringslayouter och attentionsökvägar inom varje fas baserat på tillgängligt radantal, radernas fördelning över experter, operationens dimensioner och den aktuella kontextlängden.

Följande avsnitt förklarar dessa val. För optimeringar som utvärderats i matchade ablationsstudier på en M5 Max uppskattar vi deras effekter genom att jämföra i övrigt identiska motorkonfigurationer som endast skiljer sig åt i den optimering som studeras. Eftersom dessa experiment jämför versioner av vår motor med sig själv förklarar de mekanismer snarare än att dekomponera slutresultaten mot MLX-LM.

Förfyllning: återanvänd vikter och håll routing på GPUn

Förfyllning exponerar många tokenrader samtidigt, men Qwen dirigerar dessa rader ojämnt över experter och uppdaterar det rekursiva tillståndet genom sekvensen. Dess optimeringar delas in i tre grupper: organisera glesa expertarbeten kring de dirigerade raderna, hålla Gated DeltaNet-sökningen on-chip och dela upp långa prompter i avgränsade stycken.

Förstora

Optimera gles expertberäkning

Dekomprimera vikter under matrismultiplikation

Qwen3.6-35B-A3B-kontrollpunkten använder gruppvis affin 4-bitars kvantisering. Varje vikt lagras som en 4-bitars heltelskod, medan varje grupp om 64 vikter delar en bfloat16-skala och bias som används för att rekonstruera dess värden. Detta reducerar modellen med 35 miljarder parametrar från ungefär 70 GB bfloat16-vikter till en kontrollpunkt på 19,4 GB, vilket gör det praktiskt att hålla modellen resident på Macen.

Den Metal 4-tensoroperation som används för matrismultiplikation konsumerar bfloat16-operander snarare än den packade 4-bitarsrepresentationen. Före multiplikation måste GPUn rekonstruera vikterna i bfloat16. Den optimerade grupperade GEMM i Lily utför denna konvertering en liten vikttile i taget och håller resultatet i trådgruppsminne on-chip precis tillräckligt länge för att multiplicera det med de dirigerade aktiveringsraderna. Ackumulering använder 32-bitars flyttal, och utdata skrivs i bfloat16. Den komplett utökade viktsarrayen skapas aldrig i det enhetliga minnet.

I ablationsstudien körs dekomprimering som en separat operation: den expanderar 4-bitarsvikterna till en bfloat16-array i det enhetliga minnet, varefter matriskärnan läser tillbaka den arrayen. Vid en prompt på 512 token ökade flytten av dekomprimering till den grupperade GEMM genomströmningen för förfyllning från ende till ende med 77,4 % genom att denna mellanliggande skrivning och läsning eliminerades.

Håll expertroutingen på GPUn

Den grupperade GEMM kräver att de aktiveringsrader som tilldelats varje expert lagras tillsammans. Efter att ha valt åtta experter per token räknar ett histogram hur många tilldelningar som gick till varje expert. En prefixsökning omvandlar dessa räknare till startförskjutningar, ett spridningssteg placerar rader i sina expertgrupper, och en blockmappning listar de matrisblock med fast storlek som den grupperade GEMM måste bearbeta.

Den optimerade sökvägen håller hela denna sekvens i ett enda kommandobuffert, en ordnad batch av GPU-operationer, för varje promptstycke. En ablationsstudie pausar i stället så att CPU:n kan inspektera routingmellanprodukterna och skicka nästa operation. Att hålla histogrammet och prefixsökningen på GPUn lägger till två kärnor men tar bort CPU-GPU-synkronisering inuti varje MoE-lager.

Vid en prompt på 512 token ökade aktiveringen av GPU-resident routing förfyllningen från ende till ende med 89 %. Detta visar också varför enbart antalet kärnor kan vara vilseledande: den snabbare sökvägen startar fler kärnor men väntar aldrig på CPU:n inuti lagret.

Matcha tile-storlek till expertbelastning

Vid en prompt på 2K token genererar det att dirigera varje token till åtta av 256 experter 16 384 token-expert-tilldelningar, eller ett genomsnitt på 64 aktiveringsrader per expert. Den faktiska fördelningen är ojämn: vissa experter tar emot många rader, medan andra tar emot få.

Den grupperade GEMM delar upp varje experts utdata i tiles, vilket är små rektangulära block av en matrismultiplikations utdata. Varje tile tilldelas till en GPU-trådgrupp. På Apple silicons GPU:er innehåller en trådgrupp en eller flera simdgroups, var och en bestående av 32 trådar som exekverar instruktioner i takt.

Större tile-storlekar sprider ut inställningskostnaden över fler rader och exponerar mer parallellt arbete, men en del av en stor tile förblir inaktiv när en expert endast tar emot ett fåtal rader. Tile-storlek och antal simdgroups är därför sammankopplade.

En ablationsstudie låser tilen till 16 rader. Mot den kontrollen förbättrade aktiveringen av tilen på 32 rader med fyra simdgroups förfyllningen från ende till ende med 13,2 % vid 2K token.

Håll rekursivt tillstånd on-chip

Under förfyllning söker varje Gated DeltaNet-lager igenom prompten i ordning samtidigt som dess rekursiva tillstånd förs vidare. Med registerresidens inaktiverat använder ablationsstudien en blockvis sökning. Vid en prompt på 2K token flyttar den sökvägen 256 MiB (mebibyte) tillstånd per lager och stoppar upprepade gånger samverkande trådar vid barriärer, synkroniseringspunkter där alla deltagande trådar måste vänta på varandra.

Det rekursiva tillståndet är en matris. Den optimerade kärnan tilldelar varje kolumn till en simdgroup. Simdgruppen delar upp kolumnen mellan dess trådar, läser in kolumnen i deras register en gång och för tillståndet vidare genom hela sökningen. Trådarna utbyter mellanliggande resultat genom simdgroup-operationer i stället för trådgruppsminne, det vill säga on-chip-lagring som delas av en trådgrupp. Det färdigställda tillståndet skrivs tillbaka först efter sökningen.

Tillståndet och dess grind använder ett 32-bitars flyttalsformat eftersom små avrundningsfel ackumuleras vid sekventiella uppdateringar. Query- och key-aktiveringar förblir i bfloat16.

Vid en prompt på 2K token förbättrade aktiveringen av den registerresienta sökningen förfyllningen från ende till ende med 5,6 %. Expert-GEMM stod för ungefär 90 % av förfyllningstiden. Den sekventiella sökningen exponerar inte tillräckligt med återanvändbart matrisarbete för att dra nytta av Neural Accelerators.

Avgränsa temporärt minne med promptstyckning

Körtiden bearbetar en lång prompt som en sekvens av avgränsade stycken i stället för att behålla temporära data för varje prompttoken i minnet samtidigt. Modellvikterna förblir i det enhetliga minnet, medan det rekursiva tillståndet och KV-cachen för vidare kontext från ett stycke till nästa. Ingen tidigare kontext kasseras.

Utan styckning växer temporära aktiveringsarrayer med hela prompten och konkurrerar med modellvikter, rekursivt tillstånd och KV-cachen om det enhetliga minnet. Styckning håller endast ett segments temporära värden aktiva i taget och släpper eller återanvänder sedan den lagringen innan nästa segment bearbetas. Detta sätter ett tak för det maximala arbetsminnet och gör att motorn kan bearbeta längre prompter utan att modellens utdata ändras.

Styckad förfyllning är populärt i många motorer och är avgörande för att betjäna långa flertursbanor i dessa minnesbegränsade miljöer. Den totala förfyllningstiden för attention-lager förblir kvadratisk i förhållande till promptlängden, med en del extra omkostnader från upprepade KV-inläsningar av tidigare stycken.

Avkodning: minimera antalet flyttade byte per token

Batch-1-avkodning bearbetar en ny rad i taget. Med lite återanvändning av vikter beror dess genomströmning främst på hur många byte motorn flyttar för varje token. Avkodningsändringarna delas in i fyra grupper: optimera viktsökvägen för en enskild rad, hålla varje steg på GPUn, minska trafik för mellanliggande och tillståndsdata, samt läsa attention-cachen effektivt.

Förstora

Optimera viktsökvägen för en enskild rad

MLX skickar redan arbete med en enskild rad till specialiserade matris-vektorkärnor. Eftersom Lily inte använder MLX måste den anpassade körtiden tillhandahålla samma grundläggande strategi. Vår radparallella GEMV är utformad för en aktiveringsrad. En simdgroup samarbetar om utdata samtidigt som den läser olika delar av vikmatrisen parallellt.

Håll varje avkodningssteg på GPUn

Håll token-överlämningen på GPUn

Varje avkodningssteg avslutas med att nästa token väljs ut; det följande steget börjar med den token som indata. Att skicka urvalet till CPU:n och sedan tillbaka till GPUn lägger till en synkroniseringspunkt för varje token. Vår körtid växlar i stället mellan två kommandobuffertar och två GPU-resienta tokenplatser. GPUn väljer den token som har högst poäng och skriver dess token-ID direkt till indataplatsen för nästa avkodningssteg, medan CPU:n förbereder efterföljande arbete.

Överlappa oberoende GPU-arbete

I ett registrerat batch-1-avkodningssteg startade genereringen av en token 795 GPU-kärnor. Deras beroenden bildade 555 sekventiella stadier, vilket gjorde att vissa kärnor kunde köras samtidigt. Metals sekventiella exekveringsläge körde ändå varje kärna i ordning.

Den optimerade avkodningssökvägen registrerar de faktiska databeroendena i ett samtida Metal-pass. Oberoende kärnstartsignaler kan köras samtidigt när GPU-resurser tillåter. En barriär infogas endast när senare arbete kräver ett tidigare resultat.

Minska trafik för mellanliggande och tillståndsdata

Separata kärnor materialiserar ofta en mellanprodukt: en kärna skriver ett temporärt resultat till minnet, och nästa läser tillbaka resultatet. Den optimerade avkodningssökvägen sammansmälter fyra kedjor: de två expertindataprojektionerna med deras grindaktivering; expertutdataprojektionen med dess routingspoäng och resultatet från den delade experten; query- och key-förberedelse före attention; samt den rekursiva uppdateringen med dess normalisering. Varje sammanslagen kärna håller temporära värden i register i stället för att skicka dem genom minnet.

Sammanslagning förkortar också beroendegrafen: när en mellanliggande skrivning försvinner gör även den barriär som skyddade dess konsument det.

Läs attention-cachen effektivt

Sammanfoga läsningar från attention-cachen

Attention läser nycklar och värden från KV-cachen under varje avkodningssteg. I ablationsstudien begär inte alltid intilliggande GPU-trådar intilliggande byte, vilket tvingar minnessystemet att betjäna fler separata transaktioner. Att aktivera sammanfogade inläsningar gör att intilliggande trådar begär intilliggande byte så att hårdvaran kan kombinera deras läsningar.

På bfloat16-konfigurationen ökade sammanslagning nyckelbandbredden från 33,8 till 47,9 GB/s, ökade värdebandbredden från 42,0 till 61,8 GB/s och förbättrade avkodningen från ende till ende med 2,1 % vid en kontext på 3 840 token.

Packa query-huvuden för att återanvända KV-rader

Grouped-query attention låter åtta query-huvuden dela på ett KV-huvud. I ablationsstudien körs varje query-huvud i en separat simdgroup, så alla åtta begär oberoende av varandra samma cachade KV-rad. Den optimerade kärnan packar fyra query-huvuden i en trådgrupp, som läser in varje KV-rad en gång och återanvänder den över fyra attention-beräkningar. En andra trådgrupp hanterar de återstående fyra huvudena.

Denna teknik, som ofta kallas GQA-packning, utför samma aritmetik och producerar identiska utdatabyte samtidigt som den minskar åtta oberoende KV-förfrågningar till två delade inläsningar. Mot den opackade ablationsstudien förbättrade den avkodningsgenomströmningen från ende till ende med 23,8 % vid en kontext på 32K token.

Växla attention-layouter vid långa kontexter

Varje avkodningssteg i ett lager med fullständig attention söker igenom det befintliga KV-cachen. En layout med fasta block delar upp cachen i lika stora delar som GPUn kan bearbeta parallellt. Dess extra schemaläggning är inte värd besväret när cachen är liten, men layouten med fasta block balanserar arbetet jämnare i takt med att kontexten växer.

För denna modell håller körtiden den generella attentionsökvägen under 32K token och använder den fasta blockvägen vid 32K eller längre. Växlingen tillämpas när varje huvud har 256 värden och åtta query-huvuden delar på ett KV-huvud; andra former förblir på den generella sökvägen. En ablationsstudie inaktiverar denna växling och använder alltid den generella sökvägen. Att aktivera den fasta blockvägen förbättrade avkodningen från ende till ende med 7,7 % vid 32K, 27,4 % vid 64K och 40,2 % vid 128K.

Gränser för ytterligare optimering

Vissa ändringar förbättrade en isolerad operation men förbättrade inte inferensen från ende till ende.

Spekulativ avkodning, som använder en mindre modell för att föreslå token för hela modellen att verifiera, gjorde batch-1-avkodning 18 % långsammare. Verifieringen bearbetade grupper om två till fem rader, en ineffektiv form för denna hårdvara, och raderna valde ofta olika experter, vilket ökade mängden lästa expertviktsdata. Att minska utdatavokabuläret för utkastmodellen förbättrade utkastmodellens genomströmning med 4,7–5,1 %, men gjorde inte den kompletta spekulativa loopen snabbare. Detta resultat är arbetsbelastningsspecifikt: vår batchade Qwen-distribution på Blackwell använder spekulativ avkodning under andra förhållanden.

Andra experiment inkluderade att minska GPU-startsignaler, överlappa hela faser, använda större förfyllningstiles, tillämpa bredare sammanslagning, accelerera routern och kombinera utdata-projektionen med token-val. Ingen av dem förbättrade den kompletta inferensloopen.

Mätningar av hårdvarugränserna visade också på lite återstående utrymme i de huvudsakliga förfyllnings- och avkodningsoperationerna. MoE GEMM och GEMV nådde 97,9 % och 90,3 % av de snabbaste ihållande viktningshastigheterna för sina åtkomstmönster. Att ta bort aritmetik från den glesa GEMV ändrade genomströmningen med endast 0,2 %, vilket bekräftar att läsning av vikter snarare än beräkningar var den begränsande resursen. Förfyllningens matrismultiplikation nådde på liknande sätt 93 % av den teoretiska matrisgränsen isolerat och 80–86 % inuti de testade modellerna.

Prestanda från ende till ende

Jämförelsen från ende till ende läser in identiska 4-bitars kontrollpunktsbyte i båda motorerna och kör en förfrågan i taget på en 40-kärnig, 128 GB M5 Max. Inom varje omgång körs de två motorerna i alternerande ordning för att minska bias från bakgrundsbelastning och förändringar i chippets temperatur. Vi jämför mot MLX-LM:s snabbaste direkta genereringsväg, inte dess server, så mätningen fokuserar på modellexekvering snarare än serveringsomkostnader.

Genomsökningen omfattar tio promptlängder för förfyllning och tio kontextlängder för avkodning, från 256 till 128K token. Förfyllningsgenomströmningen stiger först när motorn sprider ut fasta inställningskostnader över fler token. Förfyllningen når sin topp runt en prompt på 4K token och sjunker sedan eftersom de tio lagren med fullständig attention utför mer arbete i takt med att prompten växer. Avkodningen förblir nästan platt vid korta kontexter och sjunker när läsningen av det växande KV-cachen blir betydande. Den anpassade motorn är snabbare vid varje registrerad längd.

Eftersom specialiserad exekvering kan ändra ordningen på flyttalsoperationer kontrollerade vi även den numeriska konsekvensen mot MLX-LM. I en teacher-forced-jämförelse förutsade båda motorerna nästa token från samma referensprefix vid var och en av 192 positioner, vilket förhindrade att tidigare skillnader påverkade senare indata. Lilys perplexitet var endast 0,04 % högre, och den valde samma högst rankade token vid 96,35 % av de testade positionerna.

Förstora

Byggd för den lokala plattformen

Apple silicon är inte en mindre datacenter-GPU. Det är en komplett lokal inferensplattform med egna hårdvaru- och mjukvaruegenskaper. Det enhetliga minnet ger en enskild nod ett mycket högt tak för hur mycket modell och tillstånd den kan rymma. M5 Neural Accelerators absorberar det täta matrisarbetet vid förfyllning. Vektor-ALUerna hanterar den bandbreddsbundna återstoden med låg återanvändning vid avkodning.

Qwen tillför ytterligare möjligheter till specialisering: håll expertrouting och rekursivt tillstånd på GPUn, eliminera onödiga mellanprodukter, överlappa oberoende arbete, återanvänd delad KV-data och anpassa kärnor till arbetsbelastningens form.

Med modell- och plattformsspecifik optimering kan en Mac köra en stor, gles modell effektivt. Framtida arbete kommer att bredda täckningen över modeller, chip och serveringsarbetsbelastningar, och omvandla de mekanismer som validerats här på en konfiguration till en mer generell körtidspolicy.

Den bredare principen är att matcha motorn till både modellens arkitektur och hårdvaruns specifika beräknings- och minnesvägar. Allt eftersom öppna modellvikter på gränsen och hårdvara utvecklas kommer högpresterande lokal inferens i allt högre grad att bero på motorer som skräddarsys för båda snarare än sådana som abstraherar bort deras skillnader.

Citering

@online{perplexity2026OptimizingOnDeviceInferenceForAppleSilicon,
  author = {{Perplexity} and Yibo Wu and Lequn Chen and Kevin Hu and Phi Hoang and Claire Beamer and Jeremy Yang and Denis Yarats},
  title = {{Optimizing on-device inference for Apple Silicon}},
  date = {2026-09-01},
  url = {https://www.perplexity.ai/hub/blog/optimizing-on-device-inference-for-apple-silicon}
}