Optimering af on-device inferens til Apple Silicon

Hybrid Compute på Apple-silicon orkestrerer en opgave mellem intelligens i skyen og en lokal model på Mac'en. Cloud-modeller håndterer forskning og ræsonnement, mens en lokal model arbejder med private filer og apps på Mac'en.

For at denne arbejdsdeling kan føles sømløs, skal lokal inferens holde trit med resten af opgaven. Det kræver en motor, der hurtigt kan behandle promter og opretholde en høj token-genereringshastighed.

Lily, vores lette lokale inferensmotor, er bygget specielt til Apple Silicon og Qwen3.6-35B-A3B med separate optimeringer til prefill og decode. En frittstående demo er offentligt tilgængelig på GitHub.

Introduktion

En almindelig måde at køre LLM'er på en Mac er med MLX, Apples open-source maskinlæringsrammework til Apple-silicon. Dens tilhørende bibliotek, MLX-LM, tilføjer de komponenter, der skal til for at indlæse og generere tekst med en lang række sprogmodeller. Sammen leverer MLX og MLX-LM en standardmæssig, generelt anvendelig stak til lokal LLM-inferens.

Qwen3.6-35B-A3B er en sparsom hybridmodel: den bruger mixture-of-experts (MoE)-routing og kombinerer rekursive tilstande med fast størrelse og fuld opmærksomhed. Disse arkitektoniske valg reducerer mængden af krævede beregninger, men de skaber også uregelmæssige arbejdsbelastninger. Tokens routes til forskellige ekspertvægte, og rekursive tilstande er af sekventiel karakter.

MLX-LM vælger allerede optimerede kerner til inferensfaser og almindelige arbejdsbelastningsformer, men dens genbrugelige operationer skal understøtte mange modelarkitekturer. En motor dedikeret til Qwen kan specialisere sig på model- og runtime-niveau og koordinere kerner, dataflytning og planlægning omkring modellens faste struktur.

Lily implementerer denne specialisering end-to-end i en enkelt proces. En Rust-runtime indlæser model-checkpointet og administrerer session-tilstanden og genereringsløkken, en OpenAI-kompatibel chat-completions-API accepterer anmodninger og streamer tokens, og skræddersyede Metal-kerner eksekverer Qwen-specifikke operationer. Hverken PyTorch eller MLX er i eksekveringsstien.

Udvid

Vi måler prefill- og decode-ydeevne separat. Prefill-throughput indfanger, hvor hurtigt motoren behandler prompten; decode-throughput indfanger, hvor hurtigt den genererer output-tokens.

Vi benchmarker Qwen3.6-35B-A3B på en enkelt MacBook Pro drevet af en M5 Max med en 40-kernet GPU og 128 GB samlet hukommelse. På tværs af ti promptlængder til prefill og ti kontekstlængder til decode, fra 256 til 128K tokens (K = 1.024), leverer motoren i gennemsnit 1,22× MLX-LM's prefill-throughput og 1,32× dens decode-throughput. Ved en prompt på 4K tokens og en decode-kontekst på 4K tokens når den tilpassede motor 5.749,9 prefill-tokens pr. sekund og 186,6 decode-tokens pr. sekund, sammenlignet med 4.737,5 og 140,9 for MLX-LM. På tværs af en session med flere ture akkumuleres disse tidsbesparelser med hvert ekstra modelkald.

Udvid

Dernæst forklarer vi, hvordan Qwens arkitektur skaber modelspecifikke optimeringsmuligheder på Apple-silicon. Derefter gennemgår vi de resulterende ændringer i prefill og decode. Vi dækker også, hvor yderligere optimering holder op med at betale sig, før vi afslutter med en end-to-end-sammenligning med MLX-LM.

Qwen-specifikke optimeringsmuligheder på Apple-silicon

Qwen skaber tre forskellige arbejdsbelastningsformer

Qwen3.6-35B-A3B indeholder 35 milliarder parametre, men aktiverer kun ca. 3 milliarder for hvert token. En router scorer 256 ekspert-subnetværk og vælger otte ved siden af én delt ekspert, der behandler hvert token. Dette sparsomme MoE-design reducerer beregninger, men producerer uensartet arbejde: eksperter modtager forskellige antal tokens, og hvert token kræver vægte fra en anden kombination af eksperter.

Qwen kombinerer desuden 10 lag med fuld opmærksomhed med 30 Gated DeltaNet-lag. Disse to lagtyper bevarer tidligere information på forskellige måder.

Opmærksomhedslagene bruger grouped-query attention (GQA). Qwen har 16 forespørgselshoveder og to nøgle-værdi-hoveder (KV), hvor otte forespørgselshoveder deler hvert KV-hoved. Deling gør KV-cachen mindre og gør det muligt at genbruge cached data på tværs af forespørgselshoveder. Cachen gemmer stadig nye nøgler og værdier for hvert token, så hvert decode-trin læser flere data, efterhånden som konteksten vokser.

Gated DeltaNet komprimerer i stedet tidligere information til en rekursiv tilstand med fast størrelse. En indlært gate kontrollerer, hvor meget af den eksisterende tilstand der skal bevares, mens en delta-opdatering inkorporerer information fra det aktuelle token. Modellen definerer disse opdateringer rekursivt, så hvert token afhænger af den tilstand, der produceres af det foregående token. Under prefill kan en motor dog evaluere den samme beregning på to måder. Den kan scanne direkte gennem tokens, mens den bærer tilstanden fremad, eller organisere opdateringerne i blokke, der blotlægger flere matrixoperationer og token-niveau-parallelisme. Hvilken tilgang der er hurtigst, afhænger af modeldimensionerne, arbejdsbelastningen og hardwaren.

Sammen skaber disse strukturer tre beregningsmønstre: uensartede ekspertgrupper, opmærksomhed over en voksende cache og en rekurrens af fast størrelse, som kan evalueres direkte eller i blokke.

Apple-silicon tilbyder forskellige veje til forskellige arbejdsbelastninger

Prefill behandler mange prompt-token-aktiveringsrækker på én gang. Den lokale arbejdsbelastning, der overvejes her, dekoder typisk én anmodning ad gangen (batch 1) og behandler én ny række pr. trin. Denne forskel ændrer, hvordan de samme modelvægte bruges. Prefill kan genbruge hver blok af vægte på tværs af hundreder eller tusinder af rækker. Decode kan i det væsentlige ikke, da hvert nyt token kræver endnu en gennemgang af vægtene.

Apple-silicon placerer CPU og GPU bag unified memory, en enkelt fysisk hukommelsespulje, der er tilgængelig for begge. Dette gør det muligt for modellen at forblive resident uden at opretholde en separat GPU-kopi, men det gør ikke dataflytning gratis. Læsning af vægte og mellemliggende værdier forbruger stadig hukommelsesbåndbredde, mens registre og anden on-chip-lagring er hurtigere, men meget mindre.

M5-GPU'en tilbyder også forskellige beregningsveje. Prefills lineære lag bruger generel matrix-matrix-multiplikation (GEMM), som anvender en vægtmatrix på mange rækker på én gang. Kompatible GEMM'er kan bruge Neural Accelerator i hver GPU-kerne gennem Metal 4-tensor-operationer. Batch-1 decode bruger i stedet generel matrix-vektor-multiplikation (GEMV), der anvender de samme vægte på én række. Med lille vægtgenbrug er GEMV primært begrænset af hukommelsesbåndbredde og egner sig bedre til GPU'ens vektor-ALU'er end til Neural Accelerators designet til matrixoperationer med større datagenbrug.

Disse eksekveringsveje er ikke unikke for Lily. MLX opererer over den samme unified memory og vælger optimerede matrix- og vektorkerner i overensstemmelse med arbejdsbelastningens form. MLX-LM's Qwen-implementering grupperer allerede ekspertarbejde, evaluerer Gated DeltaNet med en fusioneret rekursiv Metal-kerne og bruger GQA-bevidst opmærksomhed. Disse funktioner er det delte udgangspunkt for effektiv Qwen-inferens på Apple-silicon.

Optimeringsstrategi

Lilys smallere omfang gør det muligt at koordinere disse delte eksekveringsveje omkring Qwens nøjagtige arkitektur og dimensioner. Den bruger fasespecifikke GPU-veje, mapper Qwens ekspert-, rekursive og opmærksomhedsarbejdsbelastninger for at minimere dataflytning og vælger kerner og layouts fra den målte arbejdsbelastningsform. Strategien har tre dele:

1. Match GPU-stien til inferensfasen. Brug matrix-orienteret eksekvering, når prefill kan genbruge vægte på tværs af mange rækker, og vektor-orienteret eksekvering, når batch-1 decode behandler én række ad gangen.
2. Mapper Qwens struktur på GPU'en, samtidig med at dataflytning minimeres. Hold vægte komprimeret, indtil de bruges, organiser dirigeret ekspertarbejde uden at vende tilbage til CPU'en, beholde Gated DeltaNet-tilstand på chip gennem dens rekursive scanning, og genbrug de KV-data, der deles af grouped-query attention.
3. Tilpas kerner til arbejdsbelastningens form. Vælg inden for hver fase flisestørrelser, eksekveringslayouts og opmærksomhedsveje fra det tilgængelige rækketal, rækkernes fordeling på tværs af eksperter, operationens dimensioner og den aktuelle kontekstlængde.

De følgende afsnit forklarer disse valg. For optimeringer evalueret i matchede ablationer på en M5 Max anslår vi deres effekter ved at sammenligne ellers identiske motorkonfigurationer, der kun adskiller sig på den undersøgte optimering. Fordi disse eksperimenter sammenligner versioner af vores motor med sig selv, forklarer de mekanismer i stedet for at dekomponere de endelige resultater mod MLX-LM.

Prefill: genbrug vægte og hold dirigering på GPU'en

Prefill blotlægger mange token-rækker på én gang, men Qwen dirigerer disse rækker uensartet på tværs af eksperter og opdaterer den rekursive tilstand gennem sekvensen. Dens optimeringer falder i tre grupper: organiser sparsomt ekspertarbejde omkring de dirigerede rækker, hold Gated DeltaNet-scanningen på chip, og opdel lange promter i afgrænsede stykker.

Udvid

Optimer sparsom ekspertberegning

Dequantiser vægte under matrixmultiplikation

Qwen3.6-35B-A3B-checkpointet bruger gruppevis affin 4-bit kvantisering. Hver vægt gemmes som en 4-bit heltalskode, mens hver gruppe på 64 vægte deler en bfloat16-skala og bias, der bruges til at rekonstruere dens værdier. Dette reducerer modellen med 35 milliarder parametre fra ca. 70 GB bfloat16-vægte til et 19,4 GB-checkpoint, hvilket gør det praktisk at holde modellen resident på Mac'en.

Metal 4-tensor-operationen, der bruges til matrixmultiplikation, forbruger bfloat16-operander i stedet for den pakkede 4-bit-repræsentation. Før multiplikation skal GPU'en rekonstruere vægtene i bfloat16. Den optimerede grupperede GEMM i Lily udfører denne konvertering én lille vægtflise ad gangen og holder resultatet i on-chip-trådegruppelager længe nok til at multiplicere det med de dirigerede aktiveringsrækker. Akkumulering bruger 32-bit flydende komma, og outputtet skrives i bfloat16. Det komplette udvidede vægt-array oprettes aldrig i unified memory.

I ablationen kører dequantisering som en separat operation: den udvider 4-bit-vægtene til et bfloat16-array i unified memory, hvorefter matrix-kernen læser det array tilbage. Ved en prompt på 512 tokens øgede flytning af dequantisering til den grupperede GEMM prefill-throughput end-to-end med 77,4% ved at eliminere denne mellemliggende skrivning og læsning.

Hold ekspertdirigering (routing) på GPU'en

Den grupperede GEMM kræver, at de aktiveringsrækker, der tildeles til hver ekspert, gemmes sammen. Efter valg af otte eksperter pr. token tæller et histogram, hvor mange tildelinger der gik til hver ekspert. En præfiks-scanning omdanner disse tællinger til startforskydninger, et scatter-trin placerer rækker i deres ekspertgrupper, og et bloks-map lister de matriser med fast størrelse, som den grupperede GEMM skal behandle.

Den optimerede sti holder hele denne sekvens i én kommandobuffer, en ordnet batch af GPU-operationer, for hvert promptstykke. En ablation pauser i stedet, så CPU'en kan inspicere de mellemliggende routing-resultater og indsende den næste operation. At holde histogrammet og præfiks-scanningen på GPU'en tilføjer to kerner, men fjerner CPU-GPU-synkronisering inde i hvert MoE-lag.

Ved en prompt på 512 tokens øgede aktivering af GPU-resident routing end-to-end prefill med 89%. Dette viser også, hvorfor selve kerneantallet kan vildlede: den hurtigere rute starter flere kerner, men venter aldrig på CPU'en inde i laget.

Match flisestørrelse med ekspertbelastning

Ved en prompt på 2K tokens producerer dirigering af hvert token til otte af 256 eksperter 16.384 token-ekspert-tildelinger eller et gennemsnit på 64 aktiveringsrækker pr. ekspert. Den faktiske fordeling er uensartet: nogle eksperter modtager mange rækker, mens andre modtager få.

Den grupperede GEMM opdeler hver eksperts output i fliser, som er små rektangulære blokke af en matrixmultiplikations output. Hver flise tildeles til én GPU-trådegruppe. På Apple-silicium-GPU'er indeholder en trådegruppe en eller flere simdgroups, der hver består af 32 tråde, som eksekverer instruktioner synkront.

Større fliser (tiles) fordeler opsætningsomkostninger på flere rækker og blotlægger mere parallelt arbejde, men en del af en stor flise forbliver inaktiv, når en ekspert kun modtager få rækker. Flisestørrelse og simdgroup-antal er derfor koblet sammen.

En ablation fastsætter flisen til 16 rækker. Mod denne kontrol forbedrede aktivering af 32-rækkes-flisen med fire simdgroups end-to-end prefill med 13,2% ved 2K tokens.

Hold rekursiv tilstand på chip

Under prefill scanner hvert Gated DeltaNet-lag prompten i rækkefølge, mens det bærer sin rekursive tilstand fremad. Med register-bopæl deaktiveret bruger ablationen en blokvis scanning. Ved en prompt på 2K tokens flytter den sti 256 MiB (mebibytes) tilstand pr. lag og stopper gentagne gange samarbejdende tråde ved barrierer, som er synkroniseringstidspunkter, hvor alle deltagende tråde skal vente på hinanden.

Den rekursive tilstand er en matrix. Den optimerede kerne tildeler hver kolonne til én simdgroup. Simdgroupen opdelers kolonnen mellem dens tråde, indlæser kolonnen i deres registre én gang og fører tilstanden igennem hele scanningen. Trådene udveksler mellemliggende resultater gennem simdgroup-operationer i stedet for trådegruppelager, som er on-chip-lagring delt på tværs af en trådegruppe. Den færdiggjorte tilstand skrives først tilbage efter scanningen.

Tilstanden og dens gate bruger et 32-bit flydende kommatal-format (floating-point), fordi små afrundingsfejl samler sig på tværs af sekventielle opdateringer. Forespørgsels- og nøgleaktiveringer forbliver i bfloat16.

Ved en prompt på 2K tokens forbedrede aktivering af register-resident scan end-to-end prefill med 5,6%. Ekspert-GEMM'er stod for ca. 90% af prefill-tiden. Den sekventielle scanning blotlægger ikke nok genbrugeligt matrixarbejde til at drage fordel af Neural Accelerators.

Begræns midlertidig hukommelse med prompt-chunking

Runtime'en behandler en lang prompt som en sekvens af afgrænsede stykker i stedet for at beholde midlertidige data for hvert prompt-token i hukommelsen på én gang. Modelvægte forbliver i unified memory, mens den rekursive tilstand og KV-cachen bærer kontekst fra det ene stykke til det næste. Ingen tidligere kontekst kasseres.

Uden chunking vokser midlertidige aktiverings-arrays med hele prompten og konkurrerer med modelvægte, rekursiv tilstand og KV-cachen om unified memory. Chunking holder kun ét segments midlertidige værdier i live ad gangen og frigiver eller genbruger derefter denne lagring før behandling af det næste segment. Dette begrænser den maksimale arbejdshukommelse og gør det muligt for motoren at behandle længere promter uden at ændre modellens output.

Chunked prefill er populært i mange motorer og er afgørende for at betjene lange flertrinssessioner i disse hukommelsesbegrænsede miljøer. Den samlede prefill-tid for opmærksomhedslag forbliver kvadratisk på promptlængden med en vis tilføjet overhead fra gentagne KV-indlæsninger af tidligere stykker.

Decode: minimer de flyttede bytes pr. token

Batch-1 decode behandler én ny række ad gangen. Med lille vægtgenbrug afhænger dens throughput primært af, hvor mange bytes motoren flytter for hvert token. Decode-ændringerne falder i fire grupper: optimer vægtstien med én række, hold hvert trin på GPU'en, reducer mellem- og tilstandstrafik, og læs opmærksomhedscachen effektivt.

Udvid

Optimer vægtstien med én række

MLX udsender allerede en-rækkes-arbejde til specialiserede matrix-vektor-kerner. Da Lily ikke bruger MLX, skal den skræddersyede runtime levere den samme grundlæggende strategi. Vores række-parallelle GEMV er designet til én aktiveringsrække. En simdgroup samarbejder om outputtet, mens den læser forskellige dele af vægtmatricen parallelt.

Hold hvert decode-trin på GPU'en

Hold token-overdragelsen på GPU'en

Hvert decode-trin slutter med at vælge det næste token; det følgende trin begynder med det token som input. At sende valget til CPU'en og derefter tilbage til GPU'en tilføjer et synkroniseringstidspunkt til hvert token. Vores runtime skifter i stedet mellem to kommandobuffere og to GPU-residente token-slots. GPU'en vælger det token med den højeste score og skriver sit token-id direkte ind i inputslotten til det næste decode-trin, mens CPU'en forbereder det efterfølgende arbejde.

Overlap uafhængigt GPU-arbejde

I et registreret batch-1 decode-trin startede generering af et token 795 GPU-kerner. Deres afhængigheder dannede 555 sekventielle faser, hvilket efterlod nogle kerner frie til at køre samtidigt. Metals serielle eksekveringstilstand kørte ikke desto mindre hver kerne i rækkefølge.

Den optimerede decode-sti registrerer de faktiske dataafhængigheder i en concurrent Metal-pasning. Uafhængige kernekørsler kan køre på samme tid, når GPU-ressourcer tillader det. En barriere indsættes kun, når senere arbejde kræver et tidligere resultat.

Reducer mellem- og tilstandstrafik

Separate kerner materialiserer ofte et mellemprodukt: én kerne skriver et midlertidigt resultat til hukommelsen, og den næste læser resultatet tilbage. Den optimerede decode-sti fussionerer fire kæder: de to ekspert-input-projektioner med deres gatede aktivering; ekspert-output-projektionen med dens routingscore og det delte-ekspert-resultat; forespørgsels- og nøgleforberedelse før opmærksomhed; og den rekursive opdatering med dens normalisering. Hver fusioneret kerne holder midlertidige værdier i registre i stedet for at sende dem gennem hukommelsen.

Fusion forkorter også afhængighedsgrafen: når en mellemliggende skrivning forsvinder, gør den barriere, der beskyttede dens forbruger, det også.

Læs opmærksomhedscachen effektivt

Sammenflet aflæsninger af opmærksomhedscachen

Opmærksomhed læser nøgler og værdier fra KV-cachen under hvert decode-trin. I ablationen anmoder naborende GPU-tråde ikke altid om naborende bytes, hvilket tvinger hukommelsessystemet til at betjene flere separate transaktioner. Aktivering af sammenflettede indlæsninger gør, at tilstødende tråde anmoder om tilstødende bytes, så hardwaren kan kombinere deres læsninger.

På bfloat16-konfigurationen øgede sammenfletning nøglebåndbredden fra 33,8 til 47,9 GB/s, øgede værdibåndbredden fra 42,0 til 61,8 GB/s og forbedrede end-to-end-decode med 2,1% ved en kontekst på 3.840 tokens.

Pak forespørgselshoveder for at genbruge KV-rækker

Grouped-query attention lader otte forespørgselshoveder dele et enkelt KV-hoved. I ablationen kører hvert forespørgselshoved i en separat simdgroup, så alle otte uafhængigt anmoder om den samme cachedede KV-række. Den optimerede kerne pakker fire forespørgselshoveder ind i én trådegruppe, som indlæser hver KV-række én gang og genbruger den på tværs af fire opmærksomhedsberegninger. En anden trådegruppe håndterer de resterende fire hoveder.

Denne teknik, almindeligvis kaldet GQA-pakning, udfører den samme aritmetik og producerer identiske output-bytes, samtidig med at otte uafhængige KV-anmodninger reduceres til to delte indlæsninger. Mod den upakkede ablation forbedrede den decode-throughput end-to-end med 23,8% ved en kontekst på 32K tokens.

Skift opmærksomhedslayouts ved lange kontekster

Hvert decode-trin i et lag med fuld opmærksomhed scanner den eksisterende KV-cache. Et layout med faste blokke opdeler denne cache i ensartede stykker, som GPU'en kan behandle parallelt. Dens ekstra planlægning er ikke værd at anstrenge sig for, når cachen er lille, men layoutet med faste blokke balancerer arbejdet mere jævnt, efterhånden som konteksten vokser.

For denne model holder runtime'en den generelle opmærksomhedssti under 32K tokens og bruger stien med faste blokke ved 32K eller derover. Skiftet gælder, når hvert hoved har 256 værdier, og otte forespørgselshoveder deler et KV-hoved; andre former forbliver på den generelle sti. En ablation deaktiverer dette skift og bruger altid den generelle sti. Aktivering af ruten med faste blokke forbedrede end-to-end-decode med 7,7% ved 32K, 27,4% ved 64K og 40,2% ved 128K.

Grænser for yderligere optimering

Nogle ændringer forbedrede en isoleret operation, men forbedrede ikke end-to-end-inferensen.

Spekulativ dekodning, som bruger en mindre model til at foreslå tokens, som den fulde model skal verificere, gjorde batch-1 decode 18% langsommere. Verifikation behandlede grupper af to til fem rækker, en ineffektiv form for denne hardware, og rækkerne valgte ofte forskellige eksperter, hvilket øgede mængden af læste ekspertvægtsdata. Reduktion af udgangsordforrådet for 'drafteren' forbedrede 'drafter'-throughput med 4,7–5,1%, men gjorde ikke den komplette spekulative løkke hurtigere. Dette resultat er arbejdsbelastningsspecifikt: vores batch-behandlede Qwen-implementering på Blackwell bruger spekulativ dekodning under andre betingelser.

Andre eksperimenter omfattede reduktion af GPU-starter, overlappende hele faser, brug af større prefill-fliser, anvendelse af bredere fusion, acceleration af routeren og kombination af output-projektionen med token-valg. Ingen af delene forbedrede den komplette inferensløkke.

Målinger af hardwaregrænserne viste også lille resterende plads i de vigtigste prefill- og decode-operationer. MoE GEMM'er og GEMV'er nåede 97,9% og 90,3% af de hurtigste vedvarende vægtlæsningsrater for deres adgangsmønstre. Fjernelse af aritmetik fra den sparsomme GEMV ændrede kun throughput med 0,2%, hvilket bekræfter, at vægtlæsninger snarere end beregning var den begrænsende ressource. Prefills matrixmultiplikation nåede på samme måde 93% af den teoretiske matrixgrænse i isolation og 80–86% inde i de testede modeller.

End-to-end-ydeevne

End-to-end-sammenligningen indlæser identiske 4-bit checkpoint-bytes i begge motorer og kører én anmodning ad gangen på én 40-core, 128 GB M5 Max. Inden for hver runde kører de to motorer i skiftende rækkefølge for at reducere bias fra baggrundsbelastning og ændringer i chiptemperatur. Vi sammenligner med MLX-LMs hurtigste direkte genereringssti, ikke dens server, så målingen fokuserer på modeleksekvering frem for serveringsoverhead.

Søgningen dækker ti promptlængder til prefill og ti kontekstlængder til decode, fra 256 til 128K tokens. Prefill-throughput stiger først, efterhånden som motoren fordeler faste opsætningsomkostninger på flere tokens. Prefill når sit højdepunkt omkring en prompt på 4K tokens og falder derefter, fordi de ti lag med fuld opmærksomhed udfører mere arbejde, efterhånden som prompten vokser. Decode forbliver næsten flad ved korte kontekster og falder, når læsning af den voksende KV-cache bliver betydelig. Den skræddersyede motor er hurtigere ved alle registrerede længder.

Da specialiseret eksekvering kan ændre rækkefølgen af operationer med flydende komma, kontrollerede vi også numerisk konsistens mod MLX-LM. I en teacher-forced-sammenligning forudsagde begge motorer det næste token ud fra det samme referencepræfiks ved hver af 192 positioner, hvilket forhindrede tidligere forskelle i at påvirke senere inputs. Lilys perplexity var kun 0,04% højere, og den valgte det samme højest rangerede token ved 96,35% af de testede positioner.

Udvid

Bygget til den lokale platform

Apple-silicon er ikke en mindre datacenter-GPU. Det er en komplet lokal inferensplatform med sine egne hardware- og softwarespecifikationer. Unified memory giver en enkelt node en meget høj grænse for, hvor meget model og tilstand den kan indeholde. M5 Neural Accelerators opsluger det tætte matrixarbejde i prefill. Vektor-ALU'erne håndterer den båndbreddebundne rest med lavt genbrug i decode.

Qwen tilføjer yderligere muligheder for specialisering: hold ekspertdirigering og rekursiv tilstand på GPU'en, eliminer unødvendige mellemprodukter, overlap uafhængigt arbejde, genbrug delte KV-data, og tilpas kerner til arbejdsbelastningens form.

Med model- og platformsspesifik optimering kan én Mac køre en stor sparsom model effektivt. Fremtidigt arbejde vil udvide dækningen på tværs af modeller, chips og serveringsarbejdsbelastninger og omdanne de mekanismer, der er valideret her på én konfiguration, til en mere generel runtime-politik.

Det bredere princip er at matche motoren til både modellens arkitektur og hardwarens specifikke beregnings- og hukommelsesveje. I takt med at modne open-weight-modeller og hardware udvikler sig, vil lokal inferens med høj ydeevne i stigende grad afhænge af motorer, der er skræddersyet til begge frem for dem, der abstraherer deres forskelle væk.

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}
}