Perplexity gør Lily åben
Der er et men: De vigtigste detaljer bor i README, Cargo.toml, build-scripts og Metal-kernelkoden. Uden et verificeret link til Perplexitys officielle GitHub-repo kan de ikke krydstjekkes. MarkTechPost er primær kilde og solid som branchemedie, men til en produktionsbeslutning skal kildekoden ses. Nyheden er væsentlig, men endegyldig først, når repository og commit-historik er gennemgået.
Hvad Lily rent faktisk er teknisk
MarkTechPost beskriver Lily som en single-process runtime: et Rust-lag, der loader vægte og styrer genereringsløkken, et minimalt OpenAI-kompatibelt HTTP-endpoint til streaming, og håndskrevne Metal-kernels til selve beregningen. Arkitekturen er enkel: færre lag, mindre overhead, færre CPU-syncs. Det skal dog bekræftes i README og serverkoden—fx stier til API-router, model-loader og kernel-initialisering. En hurtig sanity-check er at søge efter “torch”, “mlx” og “mps” i Cargo.toml og kilde, og se hvordan memory-allocator, command buffers og kernels bindes i praksis.
Snæver specialisering som designgreb
Den snævre målretning muliggør ting, brede frameworks typisk undgår: færre dynamiske runtime-beslutninger, mulighed for at lade router-histogrammer, prefix scans og scatter køre i samme command buffer, og at holde token-valg på GPU’en, så næste trin ikke skal forbi CPU’en. Det er dér, tocifrede procentgevinster kan hentes—hvis tallene holder.
Under motorhjelmen
Når mønstret holdes stramt, spiller små optimeringer sammen: MoE-routing forbliver på GPU’en, man vælger tile-størrelser og simdgroup-layouts, der matcher registertryk og occupancy, og reducerer dermed per-token-ventetid—især i prefill.
Modelstrukturen der former arbejdet
Qwen3.6-35B-A3B beskrives som en MoE-model med 35 mia. parametre og cirka 3 mia. aktiveret per token. Routeren scorer 256 eksperter, vælger otte, plus en “shared expert”. Arkitekturen omtales som 10 lag med fuld opmærksomhed og 30 Gated DeltaNet-lag. Det giver tre tydelige workload-mønstre: ujævne ekspertgrupper, en voksende KV-cache og rekurrens. Det påvirker runtime-design direkte: ujævnhed kræver kernel-balance, den voksende KV-cache gør båndbredde altafgørende i decode (især batch-1), og rekurrens åbner for effektive, register-tunge scans. Design for værstefaldslængder—ikke gennemsnit.
Hukommelse og hardwarekrav
Checkpointet i 4-bit kvantisering angives til 19,4 GB, mens bfloat16-vægte nævnes omkring 70 GB før komprimering. Det matcher, hvad man ofte ser ved groupwise 4-bit, men bør findes i et faktisk checkpoint-manifest eller frigivelsesnoter. MarkTechPost angiver krav om macOS 15+ og mindst 24 GB unified memory i Perplexitys Hybrid Compute, med 32 GB anbefalet. Praktisk set: skal 19,4 GB dele plads med KV-cache og aktiveringer, er 32 GB reelt gulvet.
Konsekvensen er konkret. Mange danske udviklermaskiner ligger på 16–24 GB. Vil man eksperimentere seriøst med store lokale modeller, peger det på 32 eller 64 GB-konfigurationer—også i CI, hvor lange prompts og evals ellers kan løbe tør for memory. Planlæg efter spidsbelastninger, ikke kun modelvægten.
Performance og de lovede gevinster
MarkTechPost refererer speedups mod MLX-LM på en M5 Max med 128 GB: gennemsnitligt 1,23x i prefill og 1,35x i decode ved batch-1, med højere tal i visse kontekster. Ablationer peger på GPU-side routing, kernel-fusion, overlappende passes og bedre cache-tilgang i GQA som kilder til gevinsten. Det er plausibelt, fordi det rammer de rigtige flaskehalse. Men uafhængige benchmarks mangler stadig—gerne med profiler og traced dependencies.
Et vigtigt punkt er afhængighedsstyring, så uafhængige kernels kan overlappe i en concurrent Metal-pass. Kendt i HPC, men kræver disciplin i datastrukturer. Holder det, forklarer det en del af decode-fordelen: batch-1 er båndbredde mod KV-cache, og hver coalesced byte tæller.
API og integration i praksis
En OpenAI-kompatibel chat-completions API gør integration ligetil: peg eksisterende klienter mod localhost og tal samme protokol. Læs dog dokumentationen nøje: hvilke felter er understøttet, findes system- og tool-roller, er streaming chunked, og hvordan håndteres timeouts? Små afvigelser kan give store driftsproblemer.
MarkTechPost nævner en selvstændig demo i pplx-garden-repoet. Den er værdifuld til end-to-end-replikation. Uden verificeret link er det en åben opgave: find stien til server-binær, eksempel-kommandoer, miljøkrav og evt. script til at validere token-for-token output mod en reference. En hurtig sanity-test sparer tid senere.
Hvad det betyder for organisationsarkitektur
Lokal inference på Apple Silicon flytter balancen mellem cloud og edge: lavere latens, data bliver på maskinen, og omkostninger flyttes fra OPEX til CAPEX. Platformteams skal tidligere ind, fordi hardwarevalg (32/64 GB unified memory) bliver en produktbeslutning. Sikkerhed vil spørge ind til logning, modelopdateringer og adgangskontrol—også lokalt.
Tradeoffs og bindinger
Specialisering giver fart, men indsnævrer mulighederne. Lily kører på Apple Silicon/Metal. Skifter man til NVIDIA i morgen, kræver det port af kernels eller et nyt runtime. Det samme gælder modelportabilitet: Qwen3.6-35B-A3B er stærk, men passer den ikke brugssagerne, rammer man en mur.
Driftsmæssigt rykker risikoen tættere på teamet. GPU-kernel-fejl er seje at debugge. Xcode Metal System Trace hjælper—men koster tid. Og uden klar licens for Lily og demo-serveren er det svært at vurdere, om virksomheder frit må modificere og indlejre. Det skal afklares før bred udrulning.
Det der stadig mangler at blive bekræftet
Følgende punkter er ubekræftede uden officiel kode/dokumentation: fravær af PyTorch/MLX i eksekveringsstien, den præcise API-kontrakt og serverens mappestruktur, samt kvantiserings- og kernelimplementeringerne (tile-by-tile rekonstruktion og FP32-akkumulering). Også checkpoint-størrelserne 19,4 GB vs. ~70 GB bfloat16 bør tjekkes mod manifest eller download-side. Endelig mangler et verificeret link til pplx-garden med demoen—gerne med commit-hash.
På modelsiden bør Qwen3.6-35B-A3B’s officielle dokumentation bekræfte tallene: 35B parametre, ~3B aktiveret per token, 256 eksperter med valg af 8 plus en shared, samt 10 fuld-opmærksomhedslag og 30 Gated DeltaNet. MarkTechPost er konsistent, men producentens README er facit. Og hvis Apples Metal 4 begrænser datatyper for tensor-ops, bør den specifikke bfloat16-reference findes frem.
Hvorfor det kan rykke i praksis
En enkel køreplan til projekter: find det officielle repo, læs licensen, kør demoen mod et kort eval-sæt, verificér hukommelsesforbrug ved 4K og 32K kontekst, og mål tokens/sekund i prefill og decode. Brug målinger, ikke mavefornemmelser. Matcher tallene behovet, kan man designe kapacitetsplan og failover—evt. med en cloud-model som bagstopper.
Et par ord om realisme
MLX-økosystemet kan hurtigt svare igen med nye fusioner og overlap—så forskellen udligner sig. Timingen er derfor vigtig: giver et værktøj 20–35% i decode ved batch-1, er der et vindue, hvor det er værd at prøve i egen pipeline, før afstanden muligvis mindskes.
Bundlinjen
Hvis MarkTechPosts detaljer matcher Perplexitys repo, er Lily en seriøs kandidat til lokal inferens af store modeller på Apple Silicon. Valget er tydeligt: snæver specialisering for ydeevne. Gevinsten kan være lavere latens, færre afhængigheder og enklere drift—mod platformslås. Ulemperne er portabilitet, support og licensusikkerhed, som kræver afklaring.
Næste skridt er enkle: find det officielle GitHub-link, læs koden, bekræft arkitekturen, og mål selv. Forskellen mærkes først, når den køres i egne hænder.
