Optimalizace odvozování v zařízení pro Apple Silicon

Hybridní výpočty na čipech Apple silicon orchestrují úlohu mezi špičkovou inteligencí v cloudu a lokálním modelem na počítači Mac. Cloudové modely zvládají výzkum a uvažování, zatímco lokální model pracuje se soukromými soubory a aplikacemi v Macu.

Aby toto rozdělení práce působilo plynule, musí lokální odvozování držet krok se zbytkem úlohy. To vyžaduje engine, který dokáže rychle zpracovávat prompty a udržovat vysokou rychlost generování tokenů.

Lily, náš lehký lokální odvozovací stroj, je vytvořen speciálně pro Apple silicon a Qwen3.6-35B-A3B, s oddělenými optimalizacemi pro předvyplnění a dekódování. Samostatné demo je veřejně dostupné na GitHub.

Úvod

Běžným způsobem spouštění velkých jazykových modelů (LLM) na počítači Mac je použití nástroje MLX, což je open-source framework strojového učení od společnosti Apple pro čipy Apple silicon. Jeho doprovodná knihovna MLX-LM přidává komponenty potřebné pro načítání a generování textu s širokou škálou jazykových modelů. Společně poskytují MLX a MLX-LM hotový, univerzální zásobník pro lokální odvozování pomocí LLM.

Qwen3.6-35B-A3B je řídký hybridní model: využívá směrování pomocí směsi expertů (MoE) a kombinuje rekurentní stavy o pevné velikosti s plnou pozorností. Tato architektonická rozhodnutí snižují množství potřebných výpočtů, ale zároveň vytvářejí nepravidelnou pracovní zátěž. Tokeny se směrují na různé váhy expertů a rekurentní stavy mají ze své podstaty sekvenční povahu.

Knihovna MLX-LM již vybírá optimalizovaná jádra pro fáze odvozování a běžné tvary pracovní zátěže, ale její opakovaně použitelné operace musí podporovat mnoho architektur modelů. Engine určený pro model Qwen se může specializovat na úrovni modelu a běhového prostředí a koordinovat jádra, přesun dat a plánování s ohledem na pevnou strukturu modelu.

Lily implementuje tuto specializaci komplexně v jediném procesu. Běhové prostředí v jazyce Rust načítá kontrolní bod modelu a spravuje stav relace a smyčku generování, rozhraní API pro konverzace kompatibilní s OpenAI přijímá požadavky a streamuje tokeny a vlastní jádra Metal provádějí operace specifické pro model Qwen. V cestě provádění se nenachází PyTorch ani MLX.

Zvětšit

Výkon předběžného vyplnění a generování měříme odděleně. Propustnost předběžného vyplnění zachycuje, jak rychle engine zpracovává prompt; propustnost generování zachycuje, jak rychle generuje výstupní tokeny.

Porovnáváme Qwen3.6-35B-A3B na jediném MacBooku Pro s čipem M5 Max, 40jádrovým GPU a 128 GB sjednocené paměti. Při deseti délkách promptů pro prefill a deseti délkách kontextu pro dekódování, od 256 do 128K tokenů (K = 1 024), dosahuje engine v průměru 1,22× průchodnosti MLX-LM při prefillu a 1,32× při dekódování. Při promptu o délce 4K tokenů a dekódovacím kontextu o délce 4K tokenů dosahuje vlastní engine 5 749,9 prefill tokenů za sekundu a 186,6 dekódovacích tokenů za sekundu, ve srovnání s 4 737,5 a 140,9 u MLX-LM. V průběhu vícekrokové relace se tyto časové úspory s každým dalším voláním modelu sčítají.

Zvětšit

Dále vysvětlíme, jak architektura modelu Qwen vytváří optimalizační příležitosti specifické pro model na čipech Apple silicon. Poté projdeme výsledné změny v předběžném vyplnění a generování. Ukážeme si také, kde další optimalizace přestává přínášet výsledky, a na závěr přineseme komplexní srovnání s knihovnou MLX-LM.

Optimalizační příležitosti specifické pro model Qwen na čipech Apple silicon

Qwen vytváří tři odlišné tvary pracovní zátěže

Model Qwen3.6-35B-A3B obsahuje 35 miliard parametrů, ale pro každý token jich aktivuje jen asi 3 miliardy. Router ohodnocuje 256 podnikovitých podsítí expertů a vybírá osm z nich spolu s jedním sdíleným expertem, který zpracovává každý token. Tento řídký design MoE snižuje výpočetní náročnost, ale vytváří nerovnoměrnou práci: expeři přijímají různý počet tokenů a každý token vyžaduje váhy z jiné kombinace expertů.

Model Qwen rovněž kombinuje 10 vrstev s plnou pozorností a 30 vrstev Gated DeltaNet. Tyto dva typy vrstev uchovávají dřívější informace různými způsoby.

Vrstvy pozornosti využívají pozornost s agrupovanými dotazy (GQA). Qwen má 16 hlaviček dotazů a dvě hlavičky klíč–hodnota (KV), přičemž osm hlaviček dotazů sdílí každou hlavičku KV. Sdílení zmenšuje mezipaměť KV a umožňuje opětovné použití uložených dat napříč hlavičkami dotazů. Mezipaměť přesto ukládá nové klíče a hodnoty pro každý token, takže každý krok generování čte s rostoucím kontextem více dat.

Gated DeltaNet naproti tomu komprimuje dřívější informace do rekurentního stavu o pevné velikosti. Naučená brána řídí, kolik z existujícího stavu se má zachovat, zatímco delta aktualizace začleňuje informace z aktuálního tokenu. Model definuje tyto aktualizace rekurentně, takže každý token závisí na stavu produkovaném předchozím tokenem. Během předběžného vyplnění však může engine vyhodnotit stejný výpočet dvěma způsoby. Může procházet tokeny přímo a přitom nést stav kupředu, nebo reorganizovat aktualizace do bloků, které odhalují více maticových operací a paralelismus na úrovni tokenů. Způsob, který je rychlejší, závisí na rozměrech modelu, pracovní zátěži a hardwaru.

Tyto struktury společně vytvářejí tři výpočetní vzorce: nerovnoměrné skupiny expertů, pozornost nad rostoucí mezipamětí a rekurence pevné velikosti, kterou lze vyhodnocovat přímo nebo po blocích.

Apple silicon poskytuje různé cesty pro různé pracovní zátěže

Předběžné vyplnění zpracovává mnoho řádků aktivací tokenů promptu najednou. Zde zvažovaná lokální pracovní zátěž obvykle dekóduje jeden požadavek najednou (dávka 1) a v každém kroku zpracovává jeden nový řádek. Tento rozdíl mění způsob využití stejných vah modelu. Předběžné vyplnění může znovu použít každý blok vah napříč stovkami nebo tisíci řádků. Generování to z větší části neumí, protože každý nový token vyžaduje další průchod váhami.

Apple silicon umisťuje CPU a GPU za sdílenou paměť – jednotný fyzický paměťový bazén přístupný pro oba. To umožňuje modelu zůstat v paměti bez udržování samostatné kopie pro GPU, ale neznamená to, že přesun dat je zdarma. Čtení vah a mezihodnot stále spotřebovává šířku pásma paměti, zatímco registry a další čipová úložiště jsou sice rychlejší, ale mnohem menší.

GPU M5 také poskytuje odlišné výpočetní cesty. Lineární vrstvy předběžného vyplnění používají obecné násobení matic (GEMM), které aplikuje matici vah na mnoho řádků najednou. Kompatibilní operace GEMM mohou využívat neurální akcelerátor v každém jádru GPU prostřednictvím tenzorových operací Metal 4. Generování v dávce 1 namísto toho používá obecné násobení matice a vektoru (GEMV), které aplikuje stejné váhy na jeden řádek. S malou znovupoužitelností vah je GEMV omezeno hlavně šířkou pásma paměti a lépe se hodí pro vektorové aritmetické logické jednotky (ALU) GPU než pro neurální akcelerátory navržené pro maticové operace s větší znovupoužitelností dat.

Tyto prováděcí cesty nejsou pro Lily jedinečné. MLX funguje nad stejnou sdílenou pamětí a vybírá optimalizovaná maticová a vektorová jádra podle tvaru pracovní zátěže. Implementace modelu Qwen v MLX-LM již seskupuje práci expertů, vyhodnocuje Gated DeltaNet pomocí fúzovaného rekurentního jádra Metal a využívá pozornost zohledňující GQA. Tyto schopnosti představují sdílený výchozí bod pro efektivní odvozování modelu Qwen na čipech Apple silicon.

Optimalizační strategie

Užší záběr enginu Lily umožňuje koordinovat tyto sdílené prováděcí cesty s ohledem na přesnou architekturu a rozměry modelu Qwen. Využívá cesty pro GPU specifické pro jednotlivé fáze, mapuje zatížení expertů, rekurentní zatížení a zatížení pozornosti modelu Qwen tak, aby se minimalizoval přesun dat, a vybírá jádra a rozvržení podle naměřeného tvaru pracovní zátěže. Strategie se skládá ze tří částí:

1. Přizpůsobení cesty GPU fázi odvozování. Použijte provádění orientované na matice, když předběžné vyplnění může znovu použít váhy napříč mnoha řádky, a provádění orientované na vektory, když generování v dávce 1 zpracovává jeden řádek po druhém.
2. Naplánování struktury modelu Qwen na GPU při minimalizaci přesunu dat. Uchovávejte váhy komprimované, dokud se nepoužijí, uspořádejte práci směrovaných expertů bez návratu k CPU, uchovejte stav Gated DeltaNet v čipu během jeho rekurentního průchodu a znovu používejte data KV sdílená prostřednictvím pozornosti s agrupovanými dotazy.
3. Přizpůsobení jader tvaru pracovní zátěže. V rámci každé fáze vyberte velikosti dlaždic, prováděcí rozvržení a cesty pozornosti z dostupného počtu řádků, rozdělení řádků mezi experty, rozměrů operace a aktuální délky kontextu.

Následující sekce tato rozhodnutí vysvětlují. U optimalizací vyhodnocených v porovnatelných ablačních studiích na čipu M5 Max odhadujeme jejich dopad porovnáním jinak identických konfigurací enginu, které se liší pouze zkoumanou optimalizací. Protože tyto experimenty porovnávají verze našeho enginu samy se sebou, vysvětlují spíše mechanismy než rozklad konečných výsledků oproti MLX-LM.

Předběžné vyplnění: opakované použití vah a ponechání směrování na GPU

Předběžné vyplnění vystavuje mnoho řádků tokenů najednou, ale Qwen tyto řádky nerovnoměrně směruje mezi experty a v průběhu sekvence aktualizuje rekurentní stav. Jeho optimalizace spadají do tří skupin: uspořádání práce řídkých expertů kolem směrovaných řádků, ponechání skenu Gated DeltaNet v čipu a rozdělení dlouhých promptů na ohraničené bloky.

Zvětšit

Optimalizace výpočtů řídkých expertů

Dekvantování vah během násobení matic

Kontrolní bod modelu Qwen3.6-35B-A3B využívá skupinovou afinní 4bitovou kvantování. Každá váha je uložena jako 4bitový celočíselný kód, přičemž každá skupina 64 vah sdílí měřítko bfloat16 a zkreslení použité k rekonstrukci jejích hodnot. Tím se model s 35 miliardami parametrů zmenšuje z přibližně 70 GB vah bfloat16 na kontrolní bod o velikosti 19.4 GB, což umožňuje mít model trvale usazený v paměti počítače Mac.

Tenzorová operace Metal 4 používaná pro násobení matic využívá operandy bfloat16 namísto sbalené 4bitové reprezentace. Před násobením musí GPU rekonstruovat váhy ve formátu bfloat16. Optimalizovaný seskupený GEMM v Lily provádí tuto konverzi po malých dlaždicích vah a uchovává výsledek v čipové paměti skupiny vláken pouze po dobu nezbytnou k jeho vynásobení s řádky směrovaných aktivací. Akumulace využívá 32bitovou plovoucí řádovou čárku a výstup je zapsán ve formátu bfloat16. Kompletní rozšířené pole vah se v sdílené paměti nikdy nevytváří.

V ablační studii běží dekvantování jako samostatná operace: rozšiřuje 4bitové váhy do pole bfloat16 ve sdílené paměti, načež maticové jádro toto pole čte zpět. Při promptu o délce 512 tokenů přemístění dekvantování do seskupeného GEMM zvýšilo propustnost předběžného vyplnění o 77,4 % díky eliminaci tohoto mezilehlého zápisu a čtení.

Ponechání směrování expertů na GPU

Seskupený GEMM vyžaduje, aby řádky aktivací přiřazené každému expertovi byly uloženy pohromadě. Po výběru osmi expertů na token spočítá histogram, kolik přiřazení připadlo na každého experta. Prefixový sken přemění tyto počty na počáteční posuny, krok rozptýlení umístí řádky do jejich skupin expertů a bloková mapa vypíše maticové bloky o pevné velikosti, které musí seskupený GEMM zpracovat.

Optimalizovaná cesta udržuje celou tuto sekvenci v jedné příkazové frontě (seřazené dávce operací GPU) pro každý blok promptu. Aablace se naproti tomu pozastavuje, aby mohl procesor (CPU) zkontrolovat meziprodukty směrování a odeslat další operaci. Ponechání histogramu a prefixového skenování na GPU přidává dvě jádra, ale odstraňuje synchronizaci mezi CPU a GPU uvnitř každé vrstvy MoE.

Při promptu o délce 512 tokenů zvýšilo povolení směrování v paměti GPU celkové předběžné vyplnění o 89 %. To rovněž ukazuje, proč může samotný počet jader zkreslovat: rychlejší trasa spouští více jader, ale uvnitř vrstvy nikdy nečeká na CPU.

Přizpůsobení velikosti dlaždic zatížení expertů

Při promptu o délce 2K tokenů vytváří směrování každého tokenu do osmi z 256 expertů 16 384 přiřazení token–expert neboli průměrně 64 aktivačních řádků na experta. Skutečné rozdělení je nerovnoměrné: někteří expeři obdrží mnoho řádků, zatímco jiní jen málo.

Seskupený GEMM dělí výstup každého experta na dlaždice, což jsou malé obdélníkové bloky výstupu násobení matic. Každá dlaždice je přiřazena jedné skupině vláken GPU. Na GPU s čipy Apple silicon obsahuje skupina vláken jednu nebo více skupin simd, z nichž každá se skládá z 32 vláken, jež provádějí instrukce krok za krokem současně.

Větší dlaždice rozkládají náklady na nastavení do více řádků a vystavují více paralelní práce, ale část velkých dlaždic zůstává nečinná, když expert obdrží jen několik řádků. Velikost dlaždic a počet skupin simd jsou proto propojeny.

Aablační studie fixuje dlaždici na 16 řádků. Oproti této kontrolní verzi zlepšilo povolení dlaždice o velikosti 32 řádků se čtyřmi skupinami simd celkové předběžné vyplnění o 13,2 % při 2K tokenech.

Uchování rekurentního stavu v čipu

Během předběžného vyplnění prohledává každá vrstva Gated DeltaNet prompt v pořadí a zároveň nese svůj rekurentní stav kupředu. S vypnutou rezidencí v registrech používá ablace blokové skenování. Při promptu o délce 2K tokenů tato cesta přesune 256 MiB (mebibajtů) stavu na vrstvu a opakovaně zastavuje spolupracující vlákna na bariérách – v místech synchronizace, kde všechna zúčastněná vlákna musí čekat jedno na druhé.

Rekurentní stav je matice. Optimalizované jádro přiřadí každý sloupec jedné skupině simd. Skupina simd rozdělí sloupec mezi svá vlákna, jednou načte sloupec do jejich registrů a provede stav celým průchodem. Vlákna si vyměňují dílčí výsledky pomocí operací skupiny simd namísto paměti skupiny vláken, což je čipové úložiště sdílené napříč skupinou vláken. Dokončený stav se zapisuje zpět až po dokončení průchodu.

Stav a jeho brána používají 32bitový formát s plovoucí řádovou čárkou, protože malé chyby zaokrouhlování se v sekvenčních aktualizacích sčítají. Aktivace dotazů a klíčů zůstávají ve formátu bfloat16.

Při promptu o délce 2K tokenů zlepšilo povolení průchodu v registrech celkové předběžné vyplnění o 5,6 %. Expertizy GEMM tvořily přibližně 90 % času předběžného vyplnění. Sekvenční průchod nevystavuje dostatek opakovaně použitelné maticové práce na to, aby mohl těžit z neurálních akcelerátorů.

Omezení dočasné paměti pomocí řezání promptů na bloky

Běhové prostředí zpracovává dlouhý prompt jako posloupnost ohraničených bloků, namísto aby uchovávalo dočasná data pro každý token promptu v paměti najednou. Váhy modelu zůstávají uloženy ve sdílené paměti, zatímco rekurentní stav a mezipaměť KV přenášejí kontext z jednoho bloku do druhého. Žádný dřívější kontext se nezahazuje.

Bez rozdělení na bloky rostou pole dočasných aktivací s celým promptem a konkurují vahám modelu, rekurentnímu stavu a mezipaměti KV o sdílenou paměť. Rozdělení na bloky udržuje aktivní dočasné hodnoty pouze jednoho segmentu současně a před zpracováním dalšího segmentu toto úložiště uvolní nebo znovu použije. To omezuje špičkovou pracovní paměť a umožňuje enginu zpracovávat delší prompty bez změny výstupu modelu.

Předběžné vyplnění po blocích je oblíbené v mnoha enginech a je klíčové pro obsluhu dlouhých vícestranových relací v těchto paměťově omezených prostředích. Celkový čas předběžného vyplnění pro vrstvy pozornosti zůstává kvadratický vzhledem k délce promptu, s určitou dodatečnou režií z opakovaného načítání KV dřívějších bloků.

Generování: minimalizace přesunutých bajtů na token

Generování pro dávku 1 zpracovává vždy jeden nový řádek. S minimálním opakovaným použitím vah závisí jeho propustnost hlavně na tom, kolik bajtů engine přesune pro každý token. Změny v generování spadají do čtyř skupin: optimalizace cesty pro váhy jednoho řádku, ponechání každého kroku na GPU, snížení provozu mezilehlých dat a stavů a efektivní čtení mezipaměti pozornosti.

Zvětšit

Optimalizace cesty pro váhy jednoho řádku

Nástroj MLX již odesílá práci pro jeden řádek do specializovaných maticově-vektorových jader. Protože Lily nepoužívá MLX, musí vlastní běhové prostředí poskytovat stejnou základní strategii. Náš řádkově paralelní GEMV je navržen pro jeden řádek aktivací. Skupina simd spolupracuje na výstupu a současně paralelně čte různé části matice vah.

Ponechání každého kroku generování na GPU

Ponechání předávání tokenů na GPU

Každý krok generování končí výběrem dalšího tokenu; následující krok začíná tímto tokenem jako vstupem. Odeslání výběru do CPU a poté zpět do GPU přidává synchronizační bod ke každému tokenu. Naše běhové prostředí namísto toho střídá dvě příkazové fronty a dva sloty tokenů v paměti GPU. GPU vybírá token s nejvyšším skóre a zapisuje jeho ID přímo do vstupního slotu pro další krok generování, zatímco CPU připravuje následnou práci.

Překrývání nezávislé práce GPU

V jednom zaznamenaném kroku generování v dávce 1 spustilo vygenerování tokenu 795 jader GPU. Jejich závislosti tvořily 555 sekvenčních fází, což některým jádrům umožňovalo běžet současně. Sériový režim provádění Metal nicméně spustil každé jádro v pořadí.

Optimalizovaná cesta generování zaznamenává skutečné datové závislosti v souběžném průchodu Metal. Nezávislé spuštění jader může probíhat současně, pokud to zdroje GPU umožňují. Bariéra se vkládá pouze tehdy, když pozdější práce vyžaduje dřívější výsledek.

Snížení provozu mezilehlých dat a stavů

Samostatná jádra často materializují meziprodukt: jedno jádro zapíše do paměti dočasný výsledek a následující jej čte zpět. Optimalizovaná cesta generování fúzuje čtyři řetězce: vstupní projekce dvou expertů s jejich hradlovanou aktivací; výstupní projekci experta s jeho skórem směrování a výsledkem sdíleného experta; přípravu dotazů a klíčů před pozorností; a rekurentní aktualizaci s její normalizací. Každé fúzované jádro uchovává dočasné hodnoty v registrech namísto jejich odesílání do paměti.

Fúze také zkracuje graf závislostí: když zmizí mezilehlý zápis, zmizí i bariéra, která chránila jeho spotřebitele.

Efektivní čtení mezipaměti pozornosti

Seskupování čtení z mezipaměti pozornosti

Pozornost čte klíče a hodnoty z mezipaměti KV během každého kroku generování. V ablační studii sousední vlákna GPU ne vždy požadují sousední bajty, což nutí paměťový systém obsluhovat více samostatných transakcí. Povolení seskupených načtení přiměje sousední vlákna požadovat sousední bajty, takže hardware může jejich čtení zkombinovat.

U konfigurace bfloat16 zvýšilo seskupování šířku pásma klíčů z 33,8 na 47,9 GB/s, zvýšilo šířku pásma hodnot ze 42,0 na 61,8 GB/s a zlepšilo celkové generování o 2,1 % při kontextu o velikosti 3 840 tokenů.

Seskupení hlaviček dotazů pro opětovné použití řádků KV

Pozornost s agrupovanými dotazy (GQA) umožňuje, aby osm hlaviček dotazů sdílelo jednu hlavičku klíč–hodnota (KV). V ablační studii běží každá hlavička dotazu v samostatné skupině simd (simdgroup), takže všech osm nezávisle požaduje stejný řádek KV z mezipaměti. Optimalizované jádro seskupuje čtyři hlavičky dotazů do jedné skupiny vláken, která načte každý řádek KV jednou a znovu jej využije napříč čtyřmi výpočty pozornosti. Druhá skupina vláken zpracovává zbývající čtyři hlavičky.

Tato technika, běžně nazývaná seskupování GQA, provádí stejnou aritmetiku a vytváří identické výstupní bajty, přičemž redukuje osm nezávislých požadavků KV na dvě sdílená načtení. Oproti nesbalené ablační studii zlepšila propustnost generování o 23,8 % při kontextu o velikosti 32K tokenů.

Přepínání rozvržení pozornosti u dlouhých kontextů

Každý krok generování ve vrstvě s plnou pozorností prohledává existující mezipaměť KV. Rozvržení s pevnými bloky dělí tuto mezipaměť na stejné části, které může GPU zpracovávat paralelně. Dodatečné plánování se nevyplácí, když je mezipaměť malá, ale rozvržení s pevnými bloky rovnoměrněji vyvažuje práci s tím, jak kontext roste.

U tohoto modelu udržuje běhové prostředí obecnou cestu pozornosti pod 32K tokeny a od 32K tokenů výše používá cestu s pevnými bloky. Přepnutí se uplatní, když má každá hlavička 256 hodnot a osm hlaviček dotazů sdílí hlavičku KV; ostatní tvary zůstávají na obecné cestě. Aablační studie tento přepínač zakazuje a vždy používá obecnou cestu. Povolení trasy s pevnými bloky zlepšilo celkové generování o 7,7 % při 32K, 27,4 % při 64K a 40,2 % při 128K.

Meze další optimalizace

Některé změny zlepšily izolovanou operaci, ale nezlepšily odvozování jako celek.

Spekulativní generování, které využívá menší model k navrhování tokenů, jež má hlavní model ověřit, zpomalilo generování v dávce 1 o 18 %. Ověřování zpracovávalo skupiny o dvou až pěti řádcích, což je pro tento hardware neefektivní tvar, a řádky často vybíraly jiné experty, což zvyšovalo množství načtených dat vah expertů. Zmenšení výstupní slovní zásoby navrhovacího modelu zlepšilo jeho propustnost o 4,7–5,1 %, ale nezrychlilo kompletní spekulativní smyčku. Tento výsledek je specifický pro danou pracovní zátěž: naše dávkované nasazení modelu Qwen na čipech Blackwell využívá spekulativní generování za odlišných podmínek.

Mezi další experimenty patřilo omezení spouštění GPU, překrývání celých fází, používání větších dlaždic pro předběžné vyplnění, uplatnění širší fúze, zrychlení routeru a kombinování výstupní procece s výběrem tokenů. Žádná z těchto úprav nezlepšila kompletní smyčku odvozování.

Měření hardwarových limitů rovněž ukázala, že v hlavních operacích předběžného vyplnění a generování zbývá jen malá rezerva. Operace MoE GEMM a GEMV dosáhly 97,9 % a 90,3 % nejvyšších udržitelných rychlostí čtení vah pro jejich přístupové vzorce. Odstranění aritmetiky z řídkého GEMV změnilo propustnost pouze o 0,2 %, což potvrzuje, že omezujícím zdrojem bylo čtení vah, nikoli výpočty. Násobení matic při předběžném vyplnění podobně dosáhlo 93 % teoretického maticového limitu v izolaci a 80–86 % uvnitř testovaných modelů.

Komplexní výkon

Komplexní srovnání načte v obou enginech identické 4bitové bajty kontrolního bodu a spustí jeden požadavek najednou na jednom 40jádrovém čipu M5 Max se 128 GB paměti. V každém kole běží oba enginy ve střídavém pořadí, aby se snížila odchylka způsobená zátěží na pozadí a změnami teploty čipu. Srovnání provádíme s nejrychlejší cestou přímé generace knihovny MLX-LM, nikoli s jejím serverem, takže měření se zaměřuje na provádění modelu, nikoli na režii obsluhy.

Test zahrnuje deset délek promptů pro předběžné vyplnění a deset délek kontextu pro generování, od 256 do 128K tokenů. Propustnost předběžného vyplnění nejprve roste, jak engine rozkládá pevné náklady na nastavení na více tokenů. Předběžné vyplnění dosahuje vrcholu kolem promptu o délce 4K tokenů a poté klesá, protože deset vrstev s plnou pozorností provádí s rostoucím promptem více práce. Generování zůstává u krátkých kontextů téměř ploché a klesá, jakmile se čtení rostoucí mezipaměti KV stane významným. Vlastní engine je rychlejší při každé zaznamenané délce.

Protože specializované provádění může změnit pořadí operací s plovoucí řádovou čárkou, ověřili jsme také číselnou konzistenci s knihovnou MLX-LM. V porovnání s vynuceným učitelem (teacher-forced) oba enginy předpověděly další token ze stejné referenční předpony na každé ze 192 pozic, což zabránilo tomu, aby dřívější rozdíly ovlivnily pozdější vstupy. Perplexita enginu Lily byla pouze o 0,04 % vyšší a vybral stejný token s nejvyšším skóre na 96,35 % testovaných pozic.

Zvětšit

Vytvořeno pro lokální platformu

Apple silicon není zmenšené databázové GPU. Je to kompletní platforma pro lokální odvozování s vlastními hardwarovými a softwarovými charakteristikami. Sdílená paměť poskytuje jedinému uzlu velmi vysoký limit pro to, jak velký model a stav může pojmout. Neurální akcelerátory M5 absorbují hustou maticovou práci při předběžném vyplnění. Vektorové jednotky ALU zpracovávají zbytek s nízkou znovupoužitelností a omezenou šířkou pásma při generování.

Model Qwen přináší další příležitosti pro specializaci: ponechání směrování expertů a rekurentního stavu na GPU, odstranění zbytečných meziproduktů, překrývání nezávislé práce, opětovné použití sdílených dat KV a přizpůsobení jader tvaru pracovní zátěže.

Díky optimalizaci specifické pro model a platformu může jeden Mac efektivně spouštět velký řídký model. Budoucí práce rozšíří pokrytí napříč modely, čipy a pracovními zátěžemi serverů a přemění mechanismy ověřené zde na jedné konfiguraci v obecnější politiku běhového prostředí.

Širším principem je přizpůsobit engine jak architektuře modelu, tak specifickým výpočetním a paměťovým cestám hardwaru. S vývojem špičkových modelů s otevřenými váhami a hardwaru bude vysoce výkonné lokální odvozování stále více záviset na motorech přizpůsobených obojímu namísto těch, které jejich rozdíly abstrakcí skrývají.

Citace

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