Optimizacija lokalnog zaključivanja za Apple Silicon
Prilagođeni lokalni motor koji poboljšava protok unosa i dekodiranja.
Hibridno računanje na Apple silicon-u koordiniše zadatak između vrhunske inteligencije u oblaku i lokalnog modela na Mac-u. Modeli u oblaku obrađuju istraživanje i zaključivanje, dok lokalni model radi sa privatnim datotekama i aplikacijama na Mac-u.
Da bi ova podela rada delovala neprimetno, lokalno zaključivanje mora da prati ostatak zadatka. To zahteva motor koji može brzo da obrađuje upite i da održava visoku stopu generisanja tokena.
Lily, naš lagani lokalni motor za zaključivanje, napravljen je posebno za Apple silicon i Qwen3.6-35B-A3B, sa odvojenim optimizacijama za fazu unosa i dekodiranja. Kod motora će uskoro biti otvorenog koda.
Uvod
Uobičajen način pokretanja jezičkih modela velike veličine (LLM) na Mac-u jeste korišćenje okvira MLX, Apple-ovog okvira mašinskog učenja otvorenog koda za Apple silicon. Njegova prateća biblioteka, MLX-LM, dodaje komponente potrebne za učitavanje i generisanje teksta sa širokim spektrom jezičkih modela. Zajedno, MLX i MLX-LM obezbeđuju gotov, svestran stek za lokalno zaključivanje LLM-a.
Model Qwen3.6-35B-A3B je retki hibridni model: koristi usmeravanje mešavine eksperata (MoE) i kombinuje stanja ponavljanja fiksne veličine sa potpunom pažnjom. Ovi arhitektonski izbori smanjuju količinu potrebnog računanja, ali takođe stvaraju nepravilna opterećenja. Tokeni se usmeravaju ka različitim težinama eksperata, a stanja ponavljanja su po prirodi sekvencijalna.
MLX-LM već bira optimizovane kernele za faze zaključivanja i uobičajene oblike radnih opterećenja, ali njegove višekratno iskoristive operacije moraju da podržavaju mnoge arhitekture modela. Motor posvećen Qwen-u može da se specijalizuje na nivou modela i okruženja za izvršavanje, koordinirajući kernele, kretanje podataka i zakazivanje oko fiksne strukture modela.
Lily primenjuje ovu specijalizaciju od kraja do kraja u jednom procesu. Rust okruženje za izvršavanje učitava tačku provere modela i upravlja stanjem sesije i petljom generisanja, API za ćaskanje kompatibilan sa OpenAI prihvata zahteve i prenosi tokene u toku, a prilagođeni Metal kerneli izvršavaju operacije specifične za Qwen. Ni PyTorch ni MLX nisu na putanji izvršavanja.

Performanse unosa i dekodiranja merimo odvojeno. Protok unosa beleži koliko brzo motor obrađuje upit; protok dekodiranja beleži koliko brzo generiše izlazne tokene.
Testirali smo model Qwen3.6-35B-A3B na jednom MacBook Pro računaru sa M5 Max procesorom, opremljenom grafičkom karticom sa 40 jezgara i 128 GB jedinstvene memorije. Kroz deset dužina upita za fazu unosa (prefill) i deset dužina konteksta za dekodiranje, u opsegu od 256 do 128 hiljada tokena (K = 1024), motor ostvaruje prosečnu brzinu unosa od 1,23× u odnosu na MLX-LM, kao i brzinu dekodiranja od 1,35× u odnosu na isti sistem. Pri upitu od 4 hiljade tokena i kontekstu dekodiranja od 4 hiljade tokena, prilagođeni motor dostizanje brzinu od 5749,9 tokena unosa u sekundi i 186,6 tokena dekodiranja u sekundi, u poređenju sa 4737,5 i 140,9 tokena za MLX-LM. Tokom sesije u više koraka, ove uštede u vremenu se akumuliraju sa svakim dodatnim pozivom modela.

Zatim objašnjavamo kako Qwen arhitektura stvara mogućnosti optimizacije specifične za model na Apple silicon-u. Potom prolazimo kroz rezultujuće promene unosa i dekodiranja. Takođe pokrivamo gde dodatna optimizacija prestaje da se isplati, pre nego što zaključimo poređenjem od kraja do kraja sa MLX-LM sistemom.
Mogućnosti optimizacije specifične za Qwen na Apple silicon-u
Qwen kreira tri različita oblika radnog opterećenja
Model Qwen3.6-35B-A3B sadrži 35 milijardi parametara, ali aktivira samo oko 3 milijarde za svaki token. Ruter ocenjuje 256 ekspertskih podnizova i bira osam, uz jedan deljeni ekspert koji obrađuje svaki token. Ovaj dizajn retkog MoE-a smanjuje računanje, ali proizvodi neujednačen rad: eksperti primaju različite brojeve tokena, a svaki token zahteva težine iz različite kombinacije eksperata.
Qwen takođe kombinuje 10 slojeva potpune pažnje sa 30 Gated DeltaNet slojeva. Ova dva tipa slojeva zadržavaju ranije informacije na različite načine.
Slojevi pažnje koriste pažnju sa grupisanim upitima (GQA). Qwen ima 16 glava upita i dve glave ključ-vrednost (KV), pri čemu osam glava upita deli svaku KV glavu. Deljenje čini KV keš manjim i omogućava da se keširani podaci ponovo koriste u različitim glavama upita. Keš i dalje čuva nove ključeve i vrednosti za svaki token, tako da svaki korak dekodiranja čita više podataka kako kontekst raste.
Gated DeltaNet umesto toga kompresuje ranije informacije u rekurentno stanje fiksne veličine. Naučena kapija kontroliše koliko postojećeg stanja treba zadržati, dok delta ažuriranje ugrađuje informacije iz trenutnog tokena. Model definiše ova ažuriranja rekurentno, tako da svaki token zavisi od stanja koje proizvodi prethodni token. Tokom unosa, međutim, motor može da proceni isto izračunavanje na dva načina. Može da skenira direktno kroz tokene dok prenosi stanje napred, ili da reorganizuje ažuriranja u blokove koji izlažu više matričnih operacija i paralelizma na nivou tokena. Koji pristup je brži zavisi od dimenzija modela, radnog opterećenja i hardvera.
Zajedno, ove strukture stvaraju tri računska šablona: neujednačene grupe eksperata, pažnju nad rastućim kešom i ponavljanje fiksne veličine koje se može procenjivati direktno ili u blokovima.
Apple silicon obezbeđuje različite putanje za različita radna opterećenja
Unos obrađuje mnoge redove aktivacije tokena upita odjednom. Lokalno radno opterećenje koje se ovde razmatra obično dekodira jedan zahtev u isto vreme (serija 1) i obrađuje jedan novi red po koraku. Ova razlika menja način na koji se koriste iste težine modela. Unos može da ponovo iskoristi svaki blok težina stotine ili hiljade puta. Dekodiranje uglavnom ne može, pošto svaki novi token zahteva još jedan prolaz kroz težine.
Apple silicon postavlja CPU i GPU iza jedinstvene memorije, jedinog sakupljača fizičke memorije kojem oba mogu da pristupe. Ovo omogućava da model ostane rezidentan bez održavanja zasebne GPU kopije, ali ne čini kretanje podataka besplatnim. Čitanje težina i međuvrednosti i dalje troši memorijski propusni opseg, dok su registri i drugo skladište na čipu brži, ali mnogo manji.
M5 GPU takođe obezbeđuje različite računske putanje. Linearni slojevi unosa koriste opšte množenje matrica-matrica (GEMM), primenjujući matricu težina na mnogo redova odjednom. Kompatibilne GEMM operacije mogu da koriste neuronski akcelerator u svakom GPU jezgru kroz Metal 4 tenzorske operacije. Dekodiranje sa serijom 1 umesto toga koristi opšte množenje matrica-vektora (GEMV), primenjujući iste težine na jedan red. Uz malu ponovnu upotrebu težina, GEMV je ograničen uglavnom propusnim opsegom memorije i bolje odgovara GPU vektorskim aritmetičko-logičkim jedinicama (ALU) nego neuronskim akceleratorima dizajniranim za matrične operacije sa većom ponovnom upotrebom podataka.
Ove putanje izvršavanja nisu jedinstvene za Lily. MLX radi preko iste jedinstvene memorije i bira optimizovane matrične i vektorske kernele u skladu sa oblikom radnog opterećenja. Qwen implementacija u MLX-LM-u već grupiše rad eksperata, procenjuje Gated DeltaNet sa spojenim rekurentnim Metal kernelom i koristi pažnju svesnu GQA-a. Ove mogućnosti su zajednička polazna tačka za efikasno Qwen zaključivanje na Apple silicon-u.
Strategija optimizacije
Uži obim modela Lily omogućava mu da uskladi ove zajedničke putanje izvršavanja sa tačnom arhitekturom i dimenzijama Qwen modela. Koristi GPU putanje specifične za fazu, mapira radna opterećenja Qwen eksperata, ponavljanja i pažnje kako bi minimizovao kretanje podataka, i bira kernele i rasporede na osnovu izmerenog oblika radnog opterećenja. Strategija ima tri dela:
- Uskladite GPU putanju sa fazom zaključivanja. Koristite izvršavanje orijentisano na matrice kada unos može da ponove težine kroz mnoge redove, i izvršavanje orijentisano na vektore kada dekodiranje sa serijom 1 obrađuje jedan po jedan red.
- Mapirajte Qwen strukturu na GPU uz minimizovanje kretanja podataka. Držite težine kompresovanim dok se ne upotrebe, organizujte rad usmerenih eksperata bez vraćanja na CPU, zadržite stanje Gated DeltaNet-a na čipu kroz njegov rekurentni sken i ponovo iskoristite KV podatke koje dele grupisani upiti pažnje.
- Prilagodite kernele obliku radnog opterećenja. Unutar svake faze, izaberite veličine pločica, rasporede izvršavanja i putanje pažnje na osnovu dostupnog broja redova, raspodele redova po ekspertima, dimenzija operacije i trenutne dužine konteksta.
Sledeći odeljci objašnjavaju ove izbore. Za optimizacije procenjene u uparenim ablacijama na M5 Max-u, procenjujemo njihove efekte poređenjem inače identičnih konfiguracija motora koje se razlikuju samo u optimizaciji koja se proučava. Pošto ovi eksperimenti porede verzije našeg motora sa njim samim, oni objašnjavaju mehanizme umesto da rastavljaju konačne rezultate u odnosu na MLX-LM.
Unos: ponovna upotreba težina i zadržavanje usmeravanja na GPU-u
Unos izlaže mnogo redova tokena odjednom, ali Qwen usmerava te redove neujednačeno preko eksperata i ažurira rekurentno stanje kroz sekvencu. Njegove optimizacije spadaju u tri grupe: organizovanje rada retkih eksperata oko usmerenih redova, zadržavanje Gated DeltaNet skeniranja na čipu i deljenje dugačkih upita na ograničene delove.

Optimizacija računanja retkih eksperata
Dekvantizacija težina tokom množenja matrica
Tačka provere Qwen3.6-35B-A3B koristi grupnu afinu 4-bitnu kvantizaciju. Svaka težina je uskladištena kao 4-bitni celobrojni kod, dok svaka grupa od 64 težine deli bfloat16 skalu i odstupanje koji se koriste za rekonstrukciju njenih vrednosti. Ovo svodi model sa 35 milijardi parametara sa otprilike 70 GB bfloat16 težina na tačku provere od 19,4 GB, što čini praktičnim držanje modela rezidentnim na Mac-u.
Metal 4 tenzorska operacija koja se koristi za množenje matrica troši bfloat16 operande umesto upakovane 4-bitne reprezentacije. Pre množenja, GPU mora da rekonstruiše težine u bfloat16 formatu. Optimizovani grupisani GEMM u Lily-ju obavlja ovu konverziju po jednu malu pločicu težina i drži rezultat u memoriji niti na čipu samo onoliko koliko je potrebno da se pomnoži sa redovima usmerenih aktivacija. Akumulacija koristi 32-bitni pokretni zarez, a izlaz se upisuje u bfloat16 formatu. Kompletan prošireni niz težina se nikada ne kreira u jedinstvenoj memoriji.
U ablaciji, dekvantizacija se pokreće kao zasebna operacija: proširuje 4-bitne težine u bfloat16 niz u jedinstvenoj memoriji, nakon čega matrični kernel čita taj niz nazad. Pri upitu od 512 tokena, premeštanje dekvantizacije u grupisani GEMM povećalo je protok unosa od kraja do kraja za 77,4% eliminacijom ovog međupisivanja i čitanja.
Zadržavanje usmeravanja eksperata na GPU-u
Grupisani GEMM zahteva da redovi aktivacije dodeljeni svakom ekspertu budu uskladišteni zajedno. Nakon izbora osam eksperata po tokenu, histogram broji koliko je dodela otišlo kom ekspertu. Prefiksno skeniranje pretvara te brojeve u početne pomake, korak rasejavanja (scatter) postavlja redove u njihove ekspertske grupe, a mapa blokova navodi matrične blokove fiksne veličine koje grupisani GEMM mora da obradi.
Optimizovana putanja drži celu ovu sekvencu u jednom baferu komandi, uređenoj seriji GPU operacija, za svaki deo upita. Ablacija umesto toga pravi pauzu kako bi CPU mogao da pregleda međurezultate usmeravanja i pošalje sledeću operaciju. Zadržavanje histograma i prefiksnog skeniranja na GPU-u dodaje dva kernela, ali uklanja CPU–GPU sinhronizaciju unutar svakog MoE sloja.
Pri upitu od 512 tokena, omogućavanje usmeravanja rezidentnog na GPU-u povećalo je unos od kraja do kraja za 89%. Ovo takođe pokazuje zašto sam broj kernela može da zavara: brža ruta pokreće više kernela, ali nikada ne čeka CPU unutar sloja.
Usklađivanje veličine pločice sa opterećenjem eksperata
Pri upitu od 2 hiljade tokena, usmeravanje svakog tokena na osam od 256 eksperata daje 16384 dodele token-ekspert, ili prosečno 64 reda aktivacije po ekspertu. Stvarna raspodela je neujednačena: neki eksperti primaju mnogo redova, dok drugi primaju malo.
Grupisani GEMM deli izlaz svakog eksperta na pločice, koje su mali pravougaoni blokovi izlaza množenja matrica. Svaka pločica je dodeljena jednoj GPU nitnoj grupi. Na GPU-ovima Apple silicon-a, nitna grupa sadrži jednu ili više simdgrupa, od kojih se svaka sastoji od 32 niti koje izvršavaju instrukcije u sinhronom koraku.
Veće pločice šire trošak podešavanja na više redova i izlažu više paralelnog rada, ali deo velike pločice ostaje neaktivan kada expert primi samo nekoliko redova. Veličina pločice i broj simdgrupa su stoga povezani.
Ablacija fiksira pločicu na 16 redova. U poređenju sa tom kontrolom, omogućavanje pločice od 32 reda sa četiri simdgrupe poboljšalo je unos od kraja do kraja za 13,2% pri 2 hiljade tokena.
Zadržavanje rekurentnog stanja na čipu
Tokom unosa, svaki Gated DeltaNet sloj skenira upit redom dok prenosi svoje rekurentno stanje napred. Sa onemogućenom rezidentnošću registara, ablacija koristi blokovsko skeniranje. Pri upitu od 2 hiljade tokena, ta putanja premešta 256 MiB (mebibajta) stanja po sloju i više puta zaustavlja niti koje sarađuju na barijerama, tačkama sinhronizacije gde sve uključene niti moraju da čekaju jedna drugu.
Stanje ponavljanja je matrica. Optimizovani kernel dodeljuje svaku kolonu jednoj simdgrupi. Simdgrupa deli kolonu između svojih niti, jednom učitava kolonu u svoje registre i prenosi stanje kroz celo skeniranje. Niti razmenjuju međurezultate kroz operacije simdgrupe umesto memorije niti (threadgroup memory), skladišta na čipu koje se deli između niti u grupi. Dovršeno stanje se upisuje nazad tek nakon skeniranja.
Stanje i njegova kapija koriste 32-bitni format sa pokretnim zarezom jer se male greške zaokruživanja sabiraju kroz sekvencijalna ažuriranja. Aktivacije upita i ključeva ostaju u bfloat16 formatu.
Pri upitu od 2 hiljade tokena, omogućavanje skeniranja rezidentnog u registrima poboljšalo je unos od kraja do kraja za 5,6%. GEMM operacije eksperata činile su oko 90% vremena unosa. Sekvencijalno skeniranje ne izlaže dovoljno višekratno iskoristivog matričnog rada da bi imalo koristi od neuronskih akceleratora (Neural Accelerators).
Ograničavanje privremene memorije deljenjem upita na delove
Okruženje za izvršavanje obrađuje dugačak upit kao niz ograničenih delova umesto da drži privremene podatke za svaki token upita u memoriji odjednom. Težine modela ostaju rezidentne u jedinstvenoj memoriji, dok rekurentno stanje i KV keš prenose kontekst sa jednog dela na sledeći. Nijedan raniji kontekst se ne odbacuje.
Bez deljenja na delove, privremeni nizovi aktivacija rastu sa celim upitom i takmiče se sa težinama modela, rekurentnim stanjem i KV kešom za jedinstvenu memoriju. Deljenje na delove drži aktivnim samo privremene vrednosti jednog segmenta u datom trenutku, a zatim oslobađa ili ponovo koristi to skladište pre obrade sledećeg segmenta. Ovo ograničava vršnu radnu memoriju i omogućava motoru da obrađuje duže upite bez promene izlaza modela.
Unos u delovima (chunked prefill) je popularan u mnogim motorima i ključan je za posluživanje dugačkih putanja u više koraka u ovim okruženjima ograničenim memorijom. Ukupno vreme unosa za slojeve pažnje ostaje kvadratno u odnosu na dužinu upita, uz izvesne dodatne režijske troškove od ponovljenih učitavanja KV keša ranijih delova.
Dekodiranje: minimizovanje broja premeštenih bajtova po tokenu
Dekodiranje sa serijom 1 obrađuje jedan novi red po koraku. Uz malu ponovnu upotrebu težina, njegov protok uglavnom zavisi od toga koliko bajtova motor premešta za svaki token. Promene dekodiranja spadaju u četiri grupe: optimizacija putanje težina sa jednim redom, zadržavanje svakog koraka na GPU-u, smanjenje međuprostornog i državnog saobraćaja, i efikasno čitanje keša pažnje.

Optimizacija putanje težina sa jednim redom
MLX već prosleđuje rad sa jednim redom specijalizovanim matrično-vektorskim kernelima. Pošto Lily ne koristi MLX, prilagođeno okruženje za izvršavanje mora da obezbedi istu osnovnu strategiju. Naš redno-paralelni GEMV je dizajniran za jedan red aktivacije. Simdgrupa sarađuje na izlazu dok paralelno čita različite delove matrice težina.
Zadržavanje svakog koraka dekodiranja na GPU-u
Zadržavanje primopredaje tokena na GPU-u
Svaki korak dekodiranja se završava izborom sledećeg tokena; sledeći korak počinje sa tim tokenom kao ulazom. Slanje izbora na CPU, a zatim nazad na GPU dodaje tačku sinhronizacije svakom tokenu. Naše okruženje za izvršavanje umesto toga prelazi između dva bafera komandi i dva slotova tokena rezidentna na GPU-u. GPU bira token sa najvećim skorom i upisuje njegov ID tokena direktno u ulazni slot za sledeći korak dekodiranja, dok CPU priprema naknadni rad.
Preklapanje nezavisnog GPU rada
U jednom zabeleženom koraku dekodiranja sa serijom 1, generisanje tokena pokrenulo je 795 GPU kernela. Njihove zavisnosti su činile 555 sekvencijalnih faza, ostavljajući neke kernele slobodnim za istovremeno pokretanje. Metal-ov serijski režim izvršavanja je ipak pokrenuo svaki kernel redom.
Optimizovana putanja dekodiranja beleži stvarne zavisnosti podataka u konkurentnom Metal prolazu. Pokretanja nezavisnih kernela mogu da se pokrenu u isto vreme kada GPU resursi to dozvoljavaju. Barijera se ubacuje samo kada kasniji rad zahteva raniji rezultat.
Smanjenje međuprostornog i državnog saobraćaja
Odvojeni kerneli često materijalizuju međurezultat: jedan kernel upisuje privremeni rezultat u memoriju, a sledeći čita rezultat nazad. Optimizovana putanja dekodiranja spaja četiri lanca: dve ulazne projekcije eksperata sa njihovom usmerenom aktivacijom; izlaznu projekciju eksperata sa njegovim rezultatom usmeravanja i rezultatom deljenog eksperta; pripremu upita i ključeva pre pažnje; i rekurentno ažuriranje sa njegovom normalizacijom. Svaki spojeni kernel drži privremene vrednosti u registrima umesto da ih šalje kroz memoriju.
Fuzija takođe skraćuje grafikon zavisnosti: kada međupisivanje nestane, nestaje i barijera koja je štitila njegovog potrošača.
Efikasno čitanje keša pažnje
Spajanje čitanja keša pažnje
Pažnja čita ključeve i vrednosti iz KV keša tokom svakog koraka dekodiranja. U ablaciji, susedne GPU niti ne traže uvek susedne bajtove, što primorava memorijski sistem da opslužuje više zasebnih transakcija. Omogućavanje spojenih učitavanja čini da susedne niti traže susedne bajtove kako bi hardver mogao da kombinuje njihova čitanja.
Na bfloat16 konfiguraciji, spajanje je povećalo protok ključeva sa 33,8 na 47,9 GB/s, povećalo protok vrednosti sa 42,0 na 61,8 GB/s i poboljšalo dekodiranje od kraja do kraja za 2,1% pri kontekstu od 3840 tokena.
Pakovanje glava upita radi ponovne upotrebe KV redova
Pažnja sa grupisanim upitima omogućava da osam glava upita deli jednu KV glavu. U ablaciji, svaka glava upita se izvršava u zasebnoj simdgrupi, tako da svih osam nezavisno zahteva isti keširani KV red. Optimizovani kernel pakuje četiri glave upita u jednu nitnu grupu (threadgroup), koja učitava svaki KV red jednom i ponovo ga koristi u četiri izračunavanja pažnje. Druga nitna grupa obrađuje preostale četiri glave.
Ova tehnika, koja se obično naziva GQA pakovanje, obavlja istu aritmetiku i proizvodi identične izlazne bajtove dok svodi osam nezavisnih KV zahteva na dva zajednička učitavanja. U poređenju sa neupakovanom ablacijom, poboljšala je protok dekodiranja od kraja do kraja za 23,8% pri kontekstu od 32 hiljade tokena.
Promena rasporeda pažnje pri dugim kontekstima
Svaki korak dekodiranja u sloju potpune pažnje skenira postojeći KV keš. Raspored sa fiksnim blokovima deli taj keš na jednake delove koje GPU može paralelno da obrađuje. Dodatno zakazivanje nije isplativo kada je keš mali, ali raspored sa fiksnim blokovima ravnomernije balansira rad kako kontekst raste.
Za ovaj model, okruženje za izvršavanje drži opštu putanju pažnje ispod 32 hiljade tokena, a putanju sa fiksnim blokovima koristi na 32 hiljade ili više. Prebacivanje se primenjuje kada svaka glava ima 256 vrednosti i osam glava upita dele KV glavu; drugi oblici ostaju na opštoj putanji. Ablacija onemogućava ovaj prekidač i uvek koristi opštu putanju. Omogućavanje rute sa fiksnim blokovima poboljšalo je dekodiranje od kraja do kraja za 7,7% na 32K, 27,4% na 64K i 40,2% na 128K.
Ograničenja dalje optimizacije
Neke promene su poboljšale izolovanu operaciju, ali nisu poboljšale zaključivanje od kraja do kraja.
Spekulativno dekodiranje, koje koristi manji model za predlaganje tokena koje će pun model da overi, učinilo je dekodiranje sa serijom 1 sporijim za 18%. Overavanje je obrađivalo grupe od dva do pet redova, što je neefikasan oblik za ovaj hardver, a redovi su često birali različite eksperte, povećavajući količinu pročitanih podataka težina eksperata. Smanjenje izlaznog rečnika nacrtača (drafter) poboljšalo je protok nacrtača za 4,7–5,1%, ali nije učinilo kompletnu spekulativnu petlju bržom. Ovaj rezultat je specifičan za radno opterećenje: naše grupno Qwen primenjivanje na Blackwell-u koristi spekulativno dekodiranje pod drugačijim uslovima.
Drugi eksperimenti su obuhvatali smanjenje pokretanja GPU-a, preklapanje celih faza, korišćenje većih pločica unosa, primenu šire fuzije, ubrzavanje rutera i kombinovanje izlazne projekcije sa izborom tokena. Nijedan nije poboljšao kompletnu petlju zaključivanja.
Merenja ograničenja hardvera takođe su pokazala malo preostalog prostora u glavnim operacijama unosa i dekodiranja. MoE GEMM i GEMV operacije dostigle su 97,9% i 90,3% najbržih održivih brzina čitanja težina za njihove šablone pristupa. Uklanjanje aritmetike iz retkog GEMV-a promenilo je protok za samo 0,2%, što potvrđuje da je čitanje težina, a ne računanje, bilo ograničavajući resurs. Množenje matrica u fazi unosa je slično dostiglo 93% teoretskog matričnog ograničenja u izolaciji i 80–86% unutar testiranih modela.
Performanse od kraja do kraja
Poređenje od kraja do kraja učitava identične bajtove tačke provere od 4 bita u oba motora i pokreće jedan po jedan zahtev na jednom M5 Max procesoru sa 40 jezgara i 128 GB. Unutar svakog kruga, dva motora rade na smeni kako bi se smanjilo odstupanje od pozadinskog opterećenja i promena temperature čipa. Upoređujemo sa najbržom putanjom direktne generacije MLX-LM-a, a ne sa njegovim serverom, tako da se merenje fokusira na izvršavanje modela, a ne na režijske troškove posluživanja.
Pregled obuhvata deset dužina upita za unos i deset dužina konteksta za dekodiranje, od 256 do 128 hiljada tokena. Protok unosa prvo raste kako motor širi fiksne troškove podešavanja na više tokena. Unos dostiže vrhunac oko upita od 4 hiljade tokena, a zatim opada zato što deset slojeva potpune pažnje obavlja više posla kako upit raste. Dekodiranje ostaje skoro ravno pri kratkim kontekstima i opada kada čitanje rastućeg KV keša postane značajno. Prilagođeni motor je brži pri svakoj zabeleženoj dužini.
Pošto specijalizovano izvršavanje može da promeni redosled operacija sa pokretnim zarezom, takođe smo proverili numeričku konzistentnost u odnosu na MLX-LM. U poređenju sa prinudnim vođenjem od strane nastavnika (teacher-forced), oba motora su predvidela sledeći token iz istog referentnog prefiksa na svakoj od 192 pozicije, sprečavajući ranije razlike da utiču na kasniji ulaz. Zbunjenost (perplexity) modela Lily bila je samo 0,4% viša, i izabrao je isti najbolje rangirani token na 96,35% testiranih pozicija.

Napravljeno za lokalnu platformu
Apple silicon nije manji GPU u data centru. To je kompletna lokalna platforma za zaključivanje sa sopstvenim hardverskim i softverskim karakteristikama. Jedinstvena memorija daje jednom čvoru veoma visoku granicu u pogledu toga koliko modela i stanja može da uskladišti. M5 neuronski akceleratori apsorbuju gust matrični rad u fazi unosa. Vektorske ALU jedinice obrađuju ostatak sa ograničenim propusnim opsegom i niskom višekratnom upotrebom u dekodiranju.
Qwen dodaje dalje mogućnosti za specijalizaciju: zadržavanje usmeravanja eksperata i rekurentnog stanja na GPU-u, uklanjanje nepotrebnih međurezultata, preklapanje nezavisnog rada, ponovna upotreba deljenih KV podataka i prilagođavanje kernela obliku radnog opterećenja.
Sa optimizacijom specifičnom za model i platformu, jedan Mac može efikasno da pokreće veliki retki model. Budući rad će proširiti pokrivenost na različite modele, čipove i radna opterećenja posluživanja, i pretvoriti mehanizme koji su ovde potvrđeni na jednoj konfiguraciji u opštiju politiku okruženja za izvršavanje.
Širi princip je da se motor uskladi i sa arhitekturom modela i sa specifičnim računskim i memorijskim putanjama hardvera. Kako se modeli sa otvorenim tegovima i hardver razvijaju, lokalno zaključivanje visokih performansi sve više će zavisi od motora prilagođenih objema stranama umesto onih koji apstrahuju njihove razlike.