LFM2.5-24B-A2B-DSpark vs LFM2.5-8B-A1B-DSpark: hetzelfde 328M-bestand, twee zeer verschillende keuzes

Download een van beide bestanden en je krijgt 655.421.522 bytes. LFM2.5-24B-A2B-DSpark en LFM2.5-8B-A1B-DSpark zijn tot op de byte even groot, delen een backbone met vijf lagen, dezelfde rank-256 Markov-head, dezelfde blokgrootte van 9 en dezelfde woordenschat van 128.000 tokens — en geen van beide kan ook maar één prompt beantwoorden, omdat beide conceptmodellen voor speculatief decoderen zijn die alleen bestaan om tokens te raden voor een doelmodel. Wat hen onderscheidt, is niet hun eigen specificatie. Het is tegen welk doelmodel ze zijn getraind, en hoeveel bewijs er is dat de truc daarop werkt. De een heeft gepubliceerde GPU- en MacBook-metingen uit een lanceringsbericht; de ander heeft een GPU-tabel en geen aankondiging. Kiezen tussen beide is daarom helemaal geen vergelijking van modellen — het is een vergelijking van twee weddenschappen, en slechts één ervan is verzilverd. De gedocumenteerde AI-fouten en agentincidenten achter releases zoals deze zijn verzameld in het OrcaRouter AI Incident Archive waarbij elke vermelding eigen bronnen, ernst, betrouwbaarheidsgraad en een betwist-vlag heeft.

De bestanden zijn een tweeling; de taken niet.

Lees de twee config.json-bestanden naast elkaar en bijna elk veld komt overeen: verborgen grootte 2.048, tussenliggende grootte 6.144, SiLU-activatie, 32 attention-heads verdeeld over 8 KV-heads met head-dimensie 64, vijf volledige attention-lagen, blokgrootte 9, enable_confidence_head: true, een standaard Markov-head met rang 256. Het aantal parameters is identiek, waardoor de safetensors-bestanden byte voor byte overeenkomen.

Drie velden verschillen, en elk daarvan is van cruciaal belang.

• Taps op doellagen — de 8B-drafter leest verborgen toestanden uit lagen 2, 6, 10, 14 en 18 van een doelmodel met 24 lagen; de 24B-drafter leest lagen 2, 10, 18, 26 en 34 van een doelmodel met 40 lagen. Dit is het veld dat de bestanden niet-uitwisselbaar maakt.

• Maximale posities — 128.000 voor de 8B-drafter tegenover 131.072 voor de 24B, in lijn met de contextvensters van hun doelmodellen.

• RoPE-theta — 5.000.000 tegenover 10.000.000, bepaald door de positionele encodering van het targetmodel en niet door iets aan de drafter.

Dat laatste paar is het duidelijkste bewijs dat deze checkpoints per doelmodel zijn getraind in plaats van geschaald vanuit een gemeenschappelijke basis. De drafter heeft geen onafhankelijke identiteit: de invoerverdeling is precies zoals de verborgen toestanden van het doelmodel eruitzien, en die veranderen wanneer de architectuur en training van het doelmodel veranderen. Richt de 8B-drafter op het 24B-model en alleen de laagindices maken er al onzin van; zelfs als ze overeenkwamen, zouden de logits die hij getraind was te voorspellen dat niet doen.

Wat elk ervan daadwerkelijk versnelt

De targets verschillen meer van elkaar dan de naamgeving "8B versus 24B" doet vermoeden, en het verschil valt verkeerd uit voor iedereen die ervan uitgaat dat het grotere model de zwaardere opgave op het toestel is.

• Totale en actieve parameters — LFM2.5-8B-A1B heeft 8,3B totaal en 1,5B actief per token; LFM2.5-24B-A2B heeft 24,0B totaal en 2,45B actief.

Diepte — 24 lagen (18 gegate convoluties plus 6 GQA) tegenover 40 lagen (30 convoluties plus 10 GQA).

• Context — 128.000 tokens tegenover 131.072.

• Trainingsbudget — 38T tokens tegenover 36T, dus het kleinere model was niet ondergetraind ten opzichte van het grotere.

• Routering — de 8B gebruikt een MoE met 64 experts en top-4-routering, net als de 24B, dus beide betalen de penalty voor expertactivering die verificatie schaadt.

Beide zijn redeneermodellen die nadenken voordat ze antwoorden, wat hier meer van belang is dan de parameteraantallen. De grootste zwakte van speculatief decoderen is lange, onbeperkte output, en een gedachteketen is precies dat. De leverancierstabellen laten het zien: de rijen met de hoogste acceptatie in beide releases zijn benchmarks met korte antwoorden zoals MBPP en MT-Bench, en de laagste zijn die waarin het model een lang oplossingspad moet verzinnen.

De bewijskloof is het echte verschil

Hier houden de twee releases op vergelijkbaar te zijn. De 8B-drafter is op 2026-08-20 uitgebracht als onderdeel van een volledige familieaankondiging, met metingen op twee heel verschillende machines: één H100 van 80 GB in BF16 via SGLang, en een M4 Max MacBook Pro met FP16 GGUF-gewichten via llama.cpp met experimentele Metal-kernels. Het gemiddelde was 2,54× op de H100, met een piek van 3,18× op MATH-500, en slechts 1,18× op de MacBook — 90 tot 106 tokens per seconde, gemiddeld over vijf datasets.

De 24B-drafter heeft één hardware-rij: één NVIDIA B300 met het FP8-target, BF16-KV-cache, temperatuur 0. Gemiddeld haalt hij 2,38× bij concurrency 1, 2,69× bij concurrency 32 en 1,71× bij concurrency 256 over acht datasets, met een piek van 3,28× op MBPP bij concurrency 32. Er is geen Mac-rij, geen H100-rij en geen aankondigingspost om de weglating te verklaren.

Voor het model waarvan de hele propositie draait om on-device agents — de lanceringspost van Liquid voor de 24B opent met 184 tokens per seconde op een Apple M5 Max — is het ontbrekende MacBook-getal de meest gewichtige leegte in de release. Het 8B-resultaat laat zien waarom het klein zou kunnen zijn: het verifiëren van een blok tokens activeert meer experts dan het decoderen van één token, dus een MoE-doel verplaatst meer gewicht per geaccepteerd token. En acceptatie alleen is niet de voorspeller: de 8B-drafter had daadwerkelijk gemiddeld meer geaccepteerde tokens per stap dan de modelkaart van de 24B vermeldt (6.95 over vijf datasets versus 5.16 over acht) en leverde op een MacBook nog steeds slechts 1.18×. Dat is het punt dat het onthouden waard is — bij de 8B redde sterke acceptatie de on-device doorvoer niet. Aannemen dat de 24B zich anders gedraagt, is een gok zonder getal erachter.

De twee tabellen tegen elkaar aflezen

De kopverhoudingen zijn niet appels met appels te vergelijken en mogen niet van elkaar worden afgetrokken. Andere GPU, andere doelprecisie, andere datasets, andere concurrency-sweeps. Maar twee patronen overleven de mismatch.

Ten eerste is het plafond vergelijkbaar. De beste H100-cel van de 8B was 3,18× op MATH-500 bij batchgrootte 1; de beste B300-cel van de 24B is 3,28× op MBPP bij gelijktijdigheid 32. Drafters van dit ontwerp vallen in dezelfde band van 1,5×–3,3×, ongeacht welk doel ze dienen, wat je zou verwachten wanneer de drafter-architectuur vast blijft en alleen de gewichten veranderen.

Ten tweede, en nuttiger: de ondergrens is waar de doelen uiteenlopen. De zwakste H100-cel van de 8B was GSM8K met 1,29×; de zwakste B300-cel van de 24B bij gelijktijdigheid 256 was LiveCodeBench met 1,34× en AIME met 1,36×. Geen van beide releases levert een geval op waarin speculatie gratis is, en beide leveren gevallen op waarin het nauwelijks het geheugen waard is.

Er is ook een documentatiewijziging tussen de twee kaarten die gemakkelijk over het hoofd wordt gezien en de moeite waard is om te signaleren. Het materiaal uit augustus zei dat de output bij greedy decoding "per constructie" identiek is aan de baseline; de 8B-kaart belooft "exact dezelfde outputs". De 24B-kaart waarschuwt daarentegen dat floating-pointverschillen tussen batched-verificatie en gewone decodering andere tekst kunnen opleveren, ook bij greedy sampling. De latere kaart is de voorzichtigere, en als je byte-level outputdiffs in CI draait, is het de moeite waard om beide als mogelijk niet-identiek te behandelen in plaats van de oudere belofte te vertrouwen.

Welke voor jou relevant is, wordt bepaald door je doel, niet door je budget.

{{1}}Er is geen scenario waarin een team op basis van verdienste de een boven de ander kiest. Je draait de 24B omdat je de capaciteit van een 24B-model nodig hebt op een machine die dat aankan — 14,5 GB bij Q4_K_M in GGUF, of één B300 voor de FP8-servingconfiguratie. Je draait de 8B omdat 8,3B totale parameters met 1,5B actief precies is wat in een edge-apparaat of een laptop past, en de drafter herwint een deel van de decodeersnelheid die je hebt opgeofferd door voor klein te kiezen. De drafter is een accessoire bij die eerste beslissing, en die beslissing wordt vrijwel altijd op geheugen en kwaliteit genomen lang voordat speculatie ter sprake komt.{{/1}}

De enige situatie waarin de keuze echt nog openligt, is evaluatie. Als je test of DSpark überhaupt de moeite waard is om in je stack op te nemen, is de 8B-combinatie het goedkopere experiment: die past op één H100, er zijn Mac-cijfers die je met je eigen laptop kunt vergelijken, en de leverancier heeft de faalmodus op het toestel al gedocumenteerd. De 24B-combinatie is het interessantere productie-experiment en het minst gedocumenteerde.

Voor beide is het getal dat de uitkomst bepaalt de acceptatieteller, niet de leverancierstabel. SGLang geeft de acceptatie van speculatief decoderen per verzoek weer; llama.cpp rapporteert draft_n en draft_n_accepted in de timing per antwoord. Voer tien minuten lang je eigen prompts uit en deel. Als de acceptatie dicht bij het gemiddelde van de kaart ligt, loont het draftmodel; als die aan de lage kant ligt, koop je verificatierondes en moet je het loskoppelen — en die conclusie geldt voor beide checkpoints, omdat het mechanisme hetzelfde is.

Geen van beide checkpoints is een model dat je kunt aanroepen.

Dit is het onderdeel waar mensen de mist in gaan die deze namen in een modelcatalogus tegenkomen en aannemen dat het opties op een menu zijn. Het zijn geen endpoints. Geen van beide drafters heeft een prijs per miljoen tokens, geen van beide staat in een API-overzicht en geen van beide zal ooit door een platform dat modellen aanbiedt worden gerouteerd — want de juiste combinatie is een configuratie aan de serverkant, niet een requestparameter.

Liquid AI verkoopt het 24B-target zelf voor $0,10 per miljoen invoertokens, $0,05 voor gecachte tokens en $1,00 per miljoen uitvoertokens, en welke speculatie er achter die prijs schuilt, is onzichtbaar voor de aanroeper. Dat is nu de gewone vorm van de markt: de interessante engineering gebeurt binnen de serving-stack, en wat een ontwikkelaar bereikt, is een tarief en een aantal tokens per seconde. Waar routeringsplatforms hun plek verdienen, is in de vergelijking boven die laag — een kandidaat naast de modellen zetten die hij moet verslaan. OrcaRouter draait één endpoint over meer dan 200 modellen tegen 0% opslag op de lijstprijs van de provider, dus wanneer het tarief van een leverancier verandert, verandert het tarief dat je ziet dezelfde dag, en failover voorkomt dat een kandidaatmodel een single point of failure wordt terwijl je het evalueert. De LFM2.5-familie zit er vandaag niet bij, dus een zelfgehoste 8B of 24B met zijn drafter eraan gekoppeld blijft een lokale deployment; de modellen die het waard zijn om ertegen te testen — Qwen3.6-35B-A3B aan de agentische kant, Gemma 4 26B-A4B aan de efficiëntiekant — zijn de modellen die wij routeren.

Wat een jaar aan DSpark-releases heeft vastgesteld

De familie omvat nu vier teksttargets en één visiontarget, van 1,2B tot 24B, allemaal met hetzelfde drafter-recept: ongeveer 300M parameters, vijf attentionlagen, blok 9, getraind op de eigen hidden states van het target. Die consistentie is de eigenlijke bevinding. Liquid heeft speculatief decoderen veranderd van een onderzoeksproject per model in een productiestap — dezelfde drafter, opnieuw getarget, binnen dagen na elk nieuw model uitgeleverd. Of die stap op jouw hardware de moeite waard is, is een kwestie van je verkeer, en het antwoord verschilt veel sterker per workload dan per welke van deze twee bestanden je downloadt.

Wat de 24B-release aan dat beeld toevoegt, is geen betere ratio. Het is de eerste keer dat een drafter is uitgebracht zonder de begeleidende toelichting — en de eerste keer dat de eigen kaart van de leverancier je in duidelijke taal heeft verteld dat de outputs misschien toch niet bit-identiek zijn.