Optimalizácia lokálnej inferencie pre Apple Silicon

Hybridné výpočty na čipoch Apple silicon koordinujú úlohu medzi špičkovou inteligenciou v cloude a lokálnym modelom v počítači Mac. Cloudové modely spracúvajú výskum a uvažovanie, zatiaľ čo lokálny model pracuje so súkromnými súbormi a aplikáciami v Macu.

Aby toto delenie práce pôsobilo plynule, lokálna inferencia musí držať krok so zvyškom úlohy. To si vyžaduje engine, ktorý dokáže rýchlo spracovávať prompty a udržiavať vysokú rýchlosť generovania tokenov.

Lily, náš ľahký lokálny inferenčný engine, je vytvorený špeciálne pre Apple silicon a Qwen3.6-35B-A3B so samostatnými optimalizáciami pre predbežné plnenie (prefill) a dekódovanie. Samostatné demo je verejne dostupné na GitHub.

Úvod

Bežným spôsobom spúšťania veľkých jazykových modelov (LLM) na počítači Mac je použitie MLX, open-source frameworku strojového učenia od spoločnosti Apple pre Apple silicon. Jeho sprievodná knižnica MLX-LM pridáva komponenty potrebné na načítanie a generovanie textu so širokou škálou jazykových modelov. MLX a MLX-LM spoločne poskytujú pripravený, univerzálny zásobník pre lokálnu inferenciu LLM.

Qwen3.6-35B-A3B je riedky hybridný model: využíva smerovanie typu „mixture-of-experts“ (MoE) a kombinuje rekurzívne stavy s pevnou veľkosťou s plnou pozornosťou. Tieto architektonické voľby znižujú množstvo potrebných výpočtov, ale zároveň vytvárajú nepravidelné pracovné zaťaženie. Tokeny sa smerujú k rôznym váham expertov a rekurzívne stavy majú zo svojej podstaty sekvenčný charakter.

MLX-LM už vyberá optimalizované jadrá pre fázy inferencie a bežné tvary pracovného zaťaženia, ale jeho opätovne použiteľné operácie musia podporovať mnohé architektúry modelov. Engine venovaný modelu Qwen sa môže špecializovať na úrovni modelu a modulu runtime a koordinovať jadrá, presun údajov a plánovanie okolo pevnej štruktúry modelu.

Lily implementuje túto špecializáciu end-to-end v jedinom procese. Modul runtime v jazyku Rust načítava kontrolný bod modelu a spravuje stav relácie a slučku generovania, chatovacie rozhranie API kompatibilné s OpenAI prijíma požiadavky a streamuje tokeny a vlastné jadrá Metal vykonávajú operácie špecifické pre Qwen. V ceste vykonávania nie je prítomný PyTorch ani MLX.

Zväčšiť

Výkonnosť predbežného spracovania a dekódovania meriame oddelene. Priepustnosť predbežného spracovania zachytáva, ako rýchlo engine spracúva prompt; priepustnosť dekódovania zachytáva, ako rýchlo generuje výstupné tokeny.

Porovnávame Qwen3.6-35B-A3B na jednom MacBooku Pro s čipom M5 Max, 40-jadrovou GPU a 128 GB zjednotenej pamäte. Naprieč desiatimi dĺžkami promptu pre prefill a desiatimi dĺžkami kontextu pre decode, od 256 do 128K tokenov (K = 1 024), dosahuje engine v priemere 1,22× priepustnosť prefillu MLX-LM a 1,32× jeho priepustnosť pre decode. Pri 4K-tokenovom prompte a 4K-tokenovom dekódovacom kontexte dosahuje vlastný engine 5 749,9 tokenov prefillu za sekundu a 186,6 tokenov pre decode za sekundu, v porovnaní s 4 737,5 a 140,9 pri MLX-LM. V priebehu viackolovej relácie sa tieto úspory času s každým ďalším volaním modelu kumulujú.

Zväčšiť

Ďalej vysvetľujeme, ako architektúra modelu Qwen vytvára optimalizačné príležitosti špecifické pre daný model na čipoch Apple silicon. Následne prejdeme výslednými zmenami v predbežnom spracovaní a dekódovaní. Venujeme sa tiež tomu, kde ďalšia optimalizácia prestáva prinášať úžitok, a na záver uvedieme porovnanie end-to-end s nástrojom MLX-LM.

Optimalizačné príležitosti špecifické pre model Qwen na čipoch Apple silicon

Qwen vytvára tri rôzne tvary pracovného zaťaženia

Qwen3.6-35B-A3B obsahuje 35 miliárd parametrov, ale pre každý token aktivuje iba približne 3 miliardy. Smerovač ohodnotí 256 subsietí expertov a vyberie osem spolu s jedným zdieľaným expertom, ktorý spracúva každý token. Tento dizajn riedkych expertov (MoE) znižuje výpočty, ale vytvára nerovnomernú prácu: experti dostávajú rôzny počet tokenov a každý token vyžaduje váhy z inej kombinácie expertov.

Qwen takisto kombinuje 10 vrstiev s plnou pozornosťou s 30 vrstvami Gated DeltaNet. Tieto dva typy vrstiev uchovávajú predchádzajúce informácie rôznymi spôsobmi.

Vrstvy pozornosti využívajú pozornosť so zoskupenými dopytmi (GQA). Qwen má 16 hláv dopytu a dve hlavy kľúč-hodnota (KV), pričom osem hláv dopytu zdieľa každú KV hlavu. Zdieľanie zmenšuje vyrovnávaciu pamäť KV a umožňuje opätovné použitie uložených údajov medzi hlavami dopytu. Pamäť cache stále ukladá nové kľúče a hodnoty pre každý token, takže každý krok dekódovania číta viac údajov s rastúcim kontextom.

Gated DeltaNet namiesto toho komprimuje predchádzajúce informácie do rekurzívneho stavu s pevnou veľkosťou. Naučená brána kontroluje, koľko z existujúceho stavu sa má zachovať, zatiaľ čo delta aktualizácia začleňuje informácie z aktuálneho tokenu. Model definuje tieto aktualizácie rekurzívne, takže každý token závisí od stavu produkovaného predchádzajúcim tokenom. Počas predbežného spracovania však engine môže vyhodnotiť ten istý výpočet dvoma spôsobmi. Môže priamo prechádzať tokenmi a zároveň prenášať stav dopredu, alebo reorganizovať aktualizácie do blokov, ktoré sprístupňujú viac maticových operácií a paralelozmu na úrovni tokenov. To, ktorý prístup je rýchlejší, závisí od rozmerov modelu, pracovného zaťaženia a hardvéru.

Tieto štruktúry spoločne vytvárajú tri výpočtové vzory: nerovnomerné skupiny expertov, pozornosť voči rastúcej vyrovnávacej pamäti a rekurziu s pevnú veľkosťou, ktorú možno vyhodnocovať priamo alebo po blokoch.

Apple silicon poskytuje rôzne cesty pre rôzne pracovné zaťaženia

Predbežné spracovanie spracúva naraz veľa riadkov aktivácie tokenov promptu. Tu uvažované lokálne pracovné zaťaženie zvyčajne dekóduje jednu požiadavku naraz (dávka 1) a spracúva jeden nový riadok na krok. Tento rozdiel mení spôsob, akým sa používajú rovnaké váhy modelu. Predbežné spracovanie dokáže opätovne použiť každý blok váh naprieč stovkami alebo tisíckami riadkov. Pri dekódovaní to vo veľkej miere nie je možné, pretože každý nový token vyžaduje ďalší prechod cez váhy.

Apple silicon umiestňuje procesor CPU a GPU za zjednotenú pamäť, čo je jediná fyzická pamäťová adresa prístupná pre oba procesory. To umožňuje, aby model zostal rezidentný bez udržiavania samostatnej kópie v GPU, ale neznamená to, že presun údajov je zadarmo. Čítanie váh a medziľahlých hodnôt stále spotrebúva šírku pásma pamäte, zatiaľ čo registre a iné úložiská na čipe sú rýchlejšie, ale oveľa menšie.

GPU M5 poskytuje aj rôzne výpočtové cesty. Lineárne vrstvy predbežného spracovania využívajú všeobecné násobenie matíc (GEMM), pričom aplikujú maticu váh na veľa riadkov naraz. Kompatibilné operácie GEMM môžu využívať neurónový akcelerátor v každom jadre GPU prostredníctvom tenzorových operácií Metal 4. Dekódovanie s dávkou 1 namiesto toho využíva všeobecné maticovo-vektorové násobenie (GEMV), pričom aplikuje rovnaké váhy na jeden riadok. Pri minimálnom opätovnom použití váh je GEMV obmedzené hlavne šírkou pásma pamäte a lepšie sa hodí pre vektorové aritmeticko-logické jednotky (ALU) GPU než pre neurónové akcelerátory navrhnuté pre maticové operácie s väčším opätovným použitím údajov.

Tieto cesty vykonávania nie sú pre Lily jedinečné. MLX funguje nad rovnakou zjednotenou pamäťou a vyberá optimalizované maticové a vektorové jadrá podľa tvaru pracovného zaťaženia. Implementácia modelu Qwen v MLX-LM už zoskupuje prácu expertov, vyhodnocuje Gated DeltaNet pomocou fúzneho rekurzívneho jadra Metal a využíva pozornosť s ohľadom na GQA. Tieto schopnosti predstavujú spoločný východiskový bod pre efektivitu inferencie modelu Qwen na čipoch Apple silicon.

Optimalizačná stratégia

Užší záber enginu Lily mu umožňuje koordinovať tieto zdieľané cesty vykonávania okolo presnej architektúry a rozmerov modelu Qwen. Využíva cesty GPU špecifické pre jednotlivé fázy, mapuje expertné, rekurzívne pracovné zaťaženie a pracovné zaťaženie pozornosti modelu Qwen tak, aby minimalizoval presuny údajov, a vyberá jadrá a rozloženia na základe nameraného tvaru pracovného zaťaženia. Táto stratégia pozostáva z troch častí:

1. Prispôsobte cestu GPU fáze inferencie. Použite vykonávanie orientované na matice, keď predbežné spracovanie dokáže opätovne použiť váhy naprieč mnohými riadkami, a vykonávanie orientované na vektory, keď dekódovanie s dávkou 1 spracúva jeden riadok naraz.
2. Mapovanie štruktúry modelu Qwen na GPU s minimalizáciou presunov údajov. Ponechajte váhy komprimované, kým sa nepoužijú, usporiadajte prácu smerovaných expertov bez návratu k CPU, uchovávajte stav Gated DeltaNet na čipe počas jeho rekurzívneho prechodu a opätovne používajte údaje KV zdieľané pozornosťou so zoskupenými dopytmi.
3. Prispôsobenie jadier tvaru pracovného zaťaženia. V rámci každej fázy vyberte veľkosti dlaždíc, rozloženia vykonávania a cesty pozornosti na základe dostupného počtu riadkov, distribúcie riadkov medzi expertov, rozmerov operácie a aktuálnej dĺžky kontextu.

Nasledujúce časti vysvetľujú tieto voľby. V prípade optimalizácií vyhodnotených v párových abláciách na čipe M5 Max odhadujeme ich účinky porovnaním inak identických konfigurácií enginu, ktoré sa líšia iba skúmanou optimalizáciou. Keďže tieto experimenty porovnávajú verzie nášho enginu samy so sebou, objasňujú mechanizmy namiesto dekompozície konečných výsledkov oproti MLX-LM.

Predbežné spracovanie: opätovné použitie váh a ponechanie smerovania na GPU

Predbežné spracovanie sprístupňuje veľa riadkov tokenov naraz, ale Qwen tieto riadky smeruje medzi expertov nerovnomerne a aktualizuje rekurzívny stav v celej sekvencii. Jeho optimalizácie možno rozdeliť do troch skupín: usporiadať riedku prácu expertov okolo smerovaných riadkov, ponechať prechod Gated DeltaNet na čipe a rozdeliť dlhé prompty na ohraničené bloky.

Zväčšiť

Optimalizácia riedkych výpočtov expertov

Dekvantizácia váh počas maticového násobenia

Kontrolný bod Qwen3.6-35B-A3B využíva skupinovú afinnú 4-bitovú kvantizáciu. Každá váha je uložená ako 4-bitový celočíselný kód, zatiaľ čo každá skupina 64 váh zdieľa mierku a bias formátu bfloat16, ktoré sa používajú na rekonštrukciu jej hodnôt. Tým sa model s 35 miliardami parametrov zmenšuje z približne 70 GB váh bfloat16 na kontrolný bod s veľkosťou 19,4 GB, vďaka čomu je praktické ponechať model rezidentný v počítači Mac.

Tenzorová operácia Metal 4 použitá na maticové násobenie spotrebúva operandy bfloat16 namiesto zbalenej 4-bitovej reprezentácie. Pred násobením musí GPU rekonštruovať váhy vo formáte bfloat16. Optimalizovaný zoskupený GEMM v Lily vykonáva túto konverziu pre jednu malú dlaždicu váh naraz a drží výsledok v pamäti skupiny vlákien na čipe len tak dlho, kým ho vynásobí smerovanými riadkami aktivácie. Akumulácia využíva 32-bitovú plávaciu rádovú čiarku a výstup sa zapisuje vo formáte bfloat16. Kompletné rozšírené pole váh sa v zjednotenej pamäti nikdy nevytvorí.

V ablácii prebieha dekvantizácia ako samostatná operácia: rozširuje 4-bitové váhy do poľa bfloat16 v zjednotenej pamäti, po čom maticové jadro toto pole opäť prečíta. Pri prompte s dĺžkou 512 tokenov presun dekvantizácie do zoskupeného GEMM zvýšil priepustnosť predbežného spracovania end-to-end o 77,4 % elimináciou tohto medziľahlého zápisu a čítania.

Ponechanie smerovania expertov na GPU

Zoskupený GEMM vyžaduje, aby boli riadky aktivácie priradené ku každému expertovi uložené spolu. Po výbere ôsmich expertov na token spočíta histogram, koľko priradení pripadlo na každého experta. Prefixový prechod premení tieto počty na počiatočné posuny, krok rozptylu umiestni riadky do ich skupín expertov a bloková mapa zoznamuje bloky matíc s pevnou veľkosťou, ktoré musí zoskupený GEMM spracovať.

Optimalizovaná cesta udržiava celú túto sekvenciu v jednom príkazovom bufferi, čo je zoradená dávka operácií GPU, pre každý kus promptu. Ablácia namiesto toho pozastaví beh, aby mohol procesor CPU skontrolovať sprostredkovateľské hodnoty smerovania a odoslať ďalšiu operáciu. Ponechanie histogramu a prefixového prechodu na GPU pridáva dve jadrá, ale odstraňuje synchronizáciu medzi CPU a GPU vo vnútri každej vrstvy MoE.

Pri prompte s dĺžkou 512 tokenov zvýšilo povolenie smerovania rezidentného na GPU predbežné spracovanie end-to-end o 89 %. To tiež ukazuje, prečo samotný počet jadier môže byť zavádzajúci: rýchlejšia cesta spúšťa viac jadier, ale nikdy nečaká na procesor CPU vo vnútri vrstvy.

Prispôsobenie veľkosti dlaždice zaťaženiu expertov

Pri prompte s dĺžkou 2K tokenov vytvorí smerovanie každého tokenu do ôsmich z 256 expertov 16 384 priradení tokenu k expertovi, čo predstavuje priemerne 64 riadkov aktivácie na experta. Skutočné rozdelenie je nerovnomerné: niektoré experti dostávajú veľa riadkov, zatiaľ čo iné len málokto.

Zoskupený GEMM delí výstup každého experta na dlaždice, čo sú malé obdĺžnikové bloky výstupu maticového násobenia. Každá dlaždica je priradená jednej skupine vlákien GPU. V GPU čipov Apple silicon obsahuje skupina vlákien jednu alebo viacero skupín SIMD, pričom každá sa skladá z 32 vlákien, ktoré vykonávajú inštrukcie synchrónne (lockstep).

Väčšie dlaždice rozkladajú náklady na nastavenie na viacero riadkov a umožňujú viac paralelnej práce, ale časť veľkej dlaždice zostáva nečinná, keď expert dostane len niekoľko riadkov. Veľkosť dlaždice a počet skupín SIMD sú preto prepojené.

Ablácia fixuje dlaždicu na 16 riadkov. V porovnaní s touto kontrolnou vzorkou zlepšilo povolenie 32-riadkovej dlaždice so štyrmi skupinami SIMD predbežné spracovanie end-to-end o 13,2 % pri 2K tokenoch.

Ponechanie rekurzívneho stavu na čipe

Počas predbežného spracovania každá vrstva Gated DeltaNet postupne prehľadáva prompt a zároveň prenáša svoj rekurzívny stav dopredu. Pri vypnutej rezidencii v registroch používa ablácia blokové prehľadávanie. Pri prompte s dĺžkou 2K tokenov táto cesta presunie 256 MiB (mebibajtov) stavu na vrstvu a opakovane zastavuje spolupracujúce vlákna na bariérach, čo sú synchronizačné body, kde všetky zúčastnené vlákna musia čakať jedno na druhé.

Rekurzívny stav je matrica. Optimalizované jadro priraďuje každý stĺpec jednej skupine SIMD. Skupina SIMD rozdelí stĺpec medzi svoje vlákna, raz načíta stĺpec do ich registrov a prenáša stav celým prechodom. Vlákna si vymieňajú čiastkové výsledky prostredníctvom operácií skupiny SIMD namiesto pamäte skupiny vlákien, čo je úložisko na čipe zdieľané medzi skupinou vlákien. Dokončený stav sa zapisuje späť až po prechode.

Stav a jeho brána používajú 32-bitový formát s plávacou rádovou čiarkou, pretože malé chyby zaokrúhľovania sa pri sekvenčných aktualizáciách kumulujú. Aktivácie dopytov a kľúčov zostávajú vo formáte bfloat16.

Pri prompte s dĺžkou 2K tokenov zlepšilo povolenie prechodu rezidentného v registri celkové predbežné spracovanie end-to-end o 5,6 %. Expertné operácie GEMM tvorili približne 90 % času predbežného spracovania. Sekvenčný prechod neposkytuje dostatok opätovne použiteľnej maticovej práce na to, aby mohol ťažiť z neurónových akcelerátorov.

Obmedzenie dočasnej pamäte delením promptu na bloky

Modul runtime spracúva dlhý prompt ako sekvenciu ohraničených blokov namiesto toho, aby v pamäti naraz uchovával dočasné údaje pre každý token promptu. Váhy modelu zostávajú v zjednotenej pamäti, zatiaľ čo rekurzívny stav a vyrovnávacia pamäť KV prenášajú kontext z jedného bloku do druhého. Žiadny predchádzajúci kontext sa zahadzuje.

Bez delenia na bloky rastú polia dočasných aktivácií spolu s celým promptom a súťažia s váhami modelu, rekurzívnym stavom a vyrovnávacou pamäťou KV o zjednotenú pamäť. Delenie na bloky udržiava aktívne dočasné hodnoty iba jedného segmentu naraz a pred spracovaním ďalšieho segmentu toto úložisko uvoľní alebo opätovne použije. Tým sa obmedzuje špičková pracovná pamäť a umožňuje enginu spracúvať dlhšie prompty bez zmeny výstupu modelu.

Predbežné spracovanie po blokoch je populárne v mnohých enginoch a je kľúčové pre obsluhu dlhých viackolových konverzácií v týchto prostrediach obmedzených pamäťou. Celkový čas predbežného spracovania pre vrstvy pozornosti zostáva kvadratický vzhľadom na dĺžku promptu, s určitou dodatočnou réžiou z opakovancích načítaní KV starších blokov.

Dekódovanie: minimalizovať presunuté bajty na jeden token

Dekódovanie s dávkou 1 spracúva jeden nový riadok naraz. Pri minimálnom opätovnom použití váh závisí jeho priepustnosť hlavne od toho, koľko bajtov engine presunie pre každý token. Zmeny pri dekódovaní možno rozdeliť do štyroch skupín: optimalizovať cestu váh s jedným riadkom, ponechať každý krok na GPU, znížiť prevádzku medziľahlých údajov a stavov a efektívne čítať vyrovnávaciu pamäť pozornosti.

Zväčšiť

Optimalizácia cesty váh s jedným riadkom

MLX už odosiela prácu s jedným riadkom špecializovaným maticovo-vektorovým jadrám. Keďže Lily nepoužíva MLX, vlastný modul runtime musí poskytovať rovnakú základnú stratégiu. Naša riadkovo-paralelná operácia GEMV je navrhnutá pre jeden riadok aktivácie. Skupina SIMD spolupracuje na výstupe a súčasne číta rôzne časti matice váh paralelne.

Ponechanie každého kroku dekódovania na GPU

Ponechanie odovzdania tokenu na GPU

Každý krok dekódovania sa končí výberom nasledujúceho tokenu; nasledujúci krok začína týmto tokenom ako vstupom. Odoslanie výberu do CPU a následne späť do GPU pridáva synchronizačný bod ku každému tokenu. Náš modul runtime namiesto toho strieda dva príkazové buffery a dva sloty tokenov rezidentné na GPU. GPU vyberie token s najvyšším skóre a zapíše jeho ID tokenu priamo do vstupného slotu pre nasledujúci krok dekódovania, zatiaľ čo CPU pripravuje nasledujúcu prácu.

Prekrývanie nezávislej práce GPU

V jednom zaznamenanom kroku dekódovania s dávkou 1 spustilo vygenerovanie tokenu 795 jadier GPU. Ich závislosti tvorili 555 sekvenčných fáz, pričom niektoré jadrá mohli bežať súbežne. Režim sériového vykonávania Metal však napriek tomu spustil každé jadro porade.

Optimalizovaná cesta dekódovania zaznamenáva skutočné závislosti údajov v súbežnom prechode Metal. Spustenia nezávislých jadier môžu prebiehať súčasne, keď to prostriedky GPU umožňujú. Bariéra sa vkladá iba vtedy, keď neskoršia práca vyžaduje skorší výsledok.

Zníženie prevádzky medziľahlých údajov a stavov

Samostatné jadrá často vytvárajú medziľahlý výsledok: jedno jadro zapíše do pamäte dočasný výsledok a nasledujúce ho prečíta späť. Optimalizovaná cesta dekódovania spája štyri reťazce: dve vstupné projekcie expertov s ich bránenou aktiváciou; výstupnú projekciu expertov s jej skóre smerovania a výsledkom zdieľaného experta; prípravu dopytu a kľúča pred pozornosťou; a rekurzívnu aktualizáciu s jej normalizáciou. Každé fúzne jadro uchováva dočasné hodnoty v registroch namiesto toho, aby ich posielalo cez pamäť.

Fúzia tiež skracuje graf závislostí: keď zmizne medziľahlý zápis, zmizne aj bariéra, ktorá chránila jeho spotrebiteľa.

Efektívne čítanie vyrovnávacej pamäte pozornosti

Spájanie čítaní z vyrovnávacej pamäte pozornosti

Pozornosť číta kľúče a hodnoty z vyrovnávacej pamäte KV počas každého kroku dekódovania. V ablácii susedné vlákna GPU nie vždy žiadajú susedné bajty, čo núti pamäťový systém obsluhovať viac samostatných transakcií. Povolenie spojených načítaní spôsobuje, že susedné vlákna žiadajú susedné bajty, takže hardvér môže ich čítania skombinovať.

V konfigurácii bfloat16 zvýšilo spájanie (coalescing) šírku pásma pre kľúče z 33,8 na 47,9 GB/s, zvýšilo šírku pásma pre hodnoty zo 42,0 na 61,8 GB/s a zlepšilo celkové dekódovanie end-to-end o 2,1 % pri kontexte 3 840 tokenov.

Zbaľovanie hláv dopytu na opätovné použitie riadkov KV

Pozornosť so zoskupenými dopytmi (GQA) umožňuje ôsmim hlavám dopytu zdieľať jednu KV hlavu. V ablácii sa každá hlava dopytu spúšťa v samostatnej skupine SIMD (simdgroup), takže všetkých osem nezávisle žiada ten istý riadok vyrovnávacej pamäte KV. Optimalizované jadro zbaľuje štyri hlavy dopytu do jednej skupiny vlákien (threadgroup), ktorá načíta každý KV riadok raz a opätovne ho využíva pri štyroch výpočtoch pozornosti. Druhá skupina vlákien spracováva zvyšné štyri hlavy.

Táto technika, často nazývaná zbaľovanie GQA, vykonáva rovnakú aritmetiku a vytvára identické výstupné bajty, pričom redukuje osem nezávislých požiadaviek KV na dve zdieľané načítania. Oproti nezbalenej ablácii zlepšila priepustnosť dekódovania end-to-end o 23,8 % pri kontexte s dĺžkou 32K tokenov.

Prepínanie rozložení pozornosti pri dlhých kontextoch

Každý krok dekódovania vo vrstve s plnou pozornosťou prehľadáva existujúcu vyrovnávaciu pamäť KV. Rozloženie s pevnými blokmi delí túto vyrovnávaciu pamäť na rovnaké časti, ktoré môže GPU spracovávať paralelne. Dodatočné plánovanie nie je opodstatnené, keď je vyrovnávacia pamäť malá, ale rozloženie s pevnými blokmi rovnomernejšie vyvažuje prácu s rastúcim kontextom.

Pre tento model udržiava modul runtime všeobecnú cestu pozornosti pod 32K tokenmi a cestu s pevnými blokmi používa pri 32K alebo dlhších tokenoch. Prepnutie sa uplatní, keď má každá hlava 256 hodnôt a osem hláv dopytu zdieľa KV hlavu; ostatné tvary zostávajú na všeobecnej ceste. Ablácia toto prepínanie zakazuje a vždy používa všeobecnú cestu. Povolenie trasy s pevnými blokmi zlepšilo celkové dekódovanie end-to-end o 7,7 % pri 32K, 27,4 % pri 64K a 40,2 % pri 128K.

Hranice ďalšej optimalizácie

Niektoré zmeny zlepšili izolovanú operáciu, ale nezlepšili inferenciu end-to-end.

Škulatívne dekódovanie, ktoré používa menší model na navrhovanie tokenov, ktoré má plný model overiť, spomalilo dekódovanie s dávkou 1 o 18 %. Overovanie spracúvalo skupiny dvoch až piatich riadkov, čo je neefektívny tvar pre tento hardvér, a riadky často vyberali rôznych expertov, čím sa zvyšovalo množstvo načítaných údajov váh expertov. Zníženie výstupnej slovnej zásoby návrhára zlepšilo jeho priepustnosť o 4,7–5,1 %, ale nezrýchlilo kompletnú škulatívnu slučku. Tento výsledok závisí od pracovného zaťaženia: naše dávkové nasadenie modelu Qwen na čipoch Blackwell využíva škulatívne dekódovanie za iných podmienok.

Medzi ďalšie experimenty patrilo zníženie počtu spustení GPU, prekrývanie celých fáz, použitie väčších dlaždíc predbežného spracovania, aplikácia širšieho zlučovania, zrýchlenie smerovača a kombinovanie výstupnej projekcie s výberom tokenu. Žiadne z nich nezlepšilo kompletnú inferenčnú slučku.

Merania hardvérových limitov tiež ukázali, že v hlavných operáciách predbežného spracovania a dekódovania zostáva len málo voľnej rezervy. MoE GEMM dosiahli 97,9 % a 90,3 % najrýchlejších trvalých rýchlostí čítania váh pre ich vzorce prístupu. Odstránenie aritmetiky z riedkej operácie GEMV zmenilo priepustnosť iba o 0,2 %, čo potvrdzuje, že obmedzujúcim zdrojom bolo čítanie váh, nie výpočty. Maticové násobenie pri predbežnom spracovaní podobne dosiahlo 93 % teoretického maticového limitu samostatne a 80–86 % v testovaných modeloch.

Výkonnosť end-to-end

Porovnanie end-to-end načítava identické 4-bitové bajty kontrolného bodu v oboch enginoch a spúšťa jednu požiadavku naraz na jednom 40-jadrovom čipe M5 Max so 128 GB pamäte. V každom kole bežia oba enginy v striedavom poradí, aby sa znížilo skreslenie spôsobené záťažou na pozadí a zmenami teploty čipu. Porovnávame s najrýchlejšou cestou priamej generácie v MLX-LM, nie s jeho serverom, takže meranie sa zameriava na vykonávanie modelu namiesto réžie servera.

Sada testov zahŕňa desať dĺžok promptu pre predbežné spracovanie a desať dĺžok kontextu pre dekódovanie, v rozsahu od 256 do 128K tokenov. Priepustnosť predbežného spracovania najprv stúpa, keď engine rozkladá fixné náklady na nastavenie na viac tokenov. Predbežné spracovanie dosahuje vrchol pri prompte okolo 4K tokenov a potom klesá, pretože desať vrstiev s plnou pozornosťou vykonáva viac práce s rastúcim promptom. Dekódovanie zostáva pri krátkych kontextoch takmer ploché a klesá, akonáhle sa čítanie rastúcej vyrovnávacej pamäte KV stane významným. Vlastný engine je rýchlejší pri každej zaznamenanej dĺžke.

Keďže špecializované vykonávanie môže zmeniť poradie operácií s plávacou rádovou čiarkou, skontrolovali sme aj numerickú konzistenciu s MLX-LM. V porovnaní s vynúteným učiteľom (teacher-forced) oba enginy predpovedali nasledujúci token z tej istej referenčnej predpony na každej z 192 pozícií, čím sa zabránilo tomu, aby predchádzajúce rozdiely ovplyvnili neskoršie vstupy. Perplexita enginu Lily bola iba o 0,04 % vyššia a vybral rovnaký token s najvyšším skóre na 96,35 % testovaných pozícií.

Zväčšiť

Vytvorené pre lokálnu platformu

Apple silicon nie je menšie dátacentrové GPU. Ide o kompletnú lokálnu inferenčnú platformu s vlastnými hardvérovými a softvérovými charakteristikami. Zjednotená pamäť poskytuje jedinému uzlu veľmi vysoký strop pre množstvo modelu a stavu, ktoré dokáže uniesť. Neurónové akcelerátory M5 absorbujú prácu s hustými maticami pri predbežnom spracovaní. Vektorové ALU jednotky spracúvajú zvyšok pri dekódovaní, ktorý je obmedzený šírkou pásma a má nízku mieru opätovného použitia.

Qwen prináša ďalšie príležitosti na špecializáciu: ponechať smerovanie expertov a rekurzívny stav na GPU, eliminovať zbytočné medziľahlé výsledky, prekrývať nezávislú prácu, opätovne používať zdieľané údaje KV a prispôsobiť jadrá tvaru pracovného zaťaženia.

Vďaka optimalizácii špecifickej pre model a platformu môže jeden Mac efektívne spúšťať veľký riedky model. Budúca práca rozšíri pokrytie naprieč modelmi, čipmi a inferenčnými úlohami a premení tu overené mechanizmy z jednej konfigurácie na všeobecnejšie pravidlá modulu runtime.

Širšou zásadou je prispôsobiť engine architektúre modelu aj špecifickým výpočtovým a pamäťovým cestám hardvéru. S vývojom špičkových modelov s otvorenými váhami a hardvéru bude vysokovýkonná lokálna inferencia čoraz viac závisieť od enginov prispôsobených obom týmto aspektom, a nie od takých, ktoré ich rozdiely iba abstrahujú.

Citácia

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