LFM2.5-24B-A2B-DSpark vs LFM2.5-24B-A2B: Moet je de drafter echt koppelen?

Dit is de beslissing in één zin: LFM2.5-24B-A2B-DSpark is een bestand met 327,7 miljoen parameters dat je naast LFM2.5-24B-A2B zet, zodat het 24B-model sneller hetzelfde soort output produceert. Het is geen alternatief voor het model en het is niet iets dat je in plaats daarvan kiest. De enige echte vraag die de twee namen oproepen, is een technische kwestie — koppel je de drafter aan je deployment of laat je hem weg — en het antwoord hangt minder af van de opvallende snelheidswinst van Liquid AI dan van twee getallen die niemand adverteert: hoeveel tokens van de draft op jouw verkeer worden geaccepteerd, en hoeveel gelijktijdigheid je al draait. De gedocumenteerde AI-storingen en agentincidenten achter releases zoals deze zijn verzameld in het OrcaRouter AI Incident Archive waar elke vermelding zijn eigen bronnen, ernst, betrouwbaarheidsgraad en betwistvlag heeft.

Liquid AI heeft geen lanceringsbericht voor de drafter gepubliceerd. De repository werd op 2026-10-19 openbaar met gewichten, een benchmark-CSV en SGLang-lanceringsflags, terwijl de eigen modelkaart van het doelmodel de drafter nog steeds als "coming soon" bestempelt en de documentatiepagina van Liquid over speculatief decoderen alleen de doelmodellen 1.2B, 2.6B, 8B en VL-3B vermeldt. Dit is dus een vergelijking van een uitgeleverd artefact met een uitgeleverd model, geschreven op basis van de repository in plaats van een persbericht — wat betekent dat elk prestatiecijfer hieronder door de leverancier is gerapporteerd en niets ervan onafhankelijk is gereproduceerd.

Wat de opsteller daadwerkelijk verandert, en wat niet

Het mechanisme is dertig seconden waard, omdat het al het andere bepaalt. Het decoderen van een token is geheugenbegrensd: de GPU besteedt het grootste deel van zijn tijd aan het streamen van gewichten naar SRAM, niet aan rekenwerk. Speculatief decoderen profiteert daarvan door een klein model de volgende paar tokens in één keer te laten raden en vervolgens het echte model de hele gok in één forward pass te laten controleren. Als de gok goed was, heb je negen tokens geproduceerd voor ongeveer de kosten van één. Als die slecht was, behoudt het doelmodel zijn eigen token en betaalde je iets extra's.

Wat verandert: tokens per seconde, en de vorm van je GPU-benutting. Wat niet verandert: de gewichten van het model, het contextvenster, het gedrag bij tool-aanroepen, of de prijzen waar het wordt verkocht. LFM2.5-24B-A2B behoudt 24,0B totale parameters met 2,45B actief per token, 40 lagen verdeeld over gegate korte convoluties en grouped-query attention, 64 experts per blok met top-4-routing, een context van 131.072 tokens en een vocabulaire van 128.000 tokens. De drafter voegt vijf attentionlagen toe, een Markov-head met rang 256 en een confidence-head, en hergebruikt de embeddings en LM-head van het doelmodel in plaats van eigen exemplaren mee te dragen.

Eén voorbehoud is tussen de twee releases verschoven en verdient een regel. In augustus stond in Liquid's DSpark-verslag dat de gegenereerde sequentie "bij constructie identiek is aan baseline greedy". De modelkaart van de 24B-drafter zegt daarentegen dat floating-pointverschillen tussen gebatchte verificatie en gewone decoding "andere tekst kunnen opleveren, ook bij greedy sampling". Beide uitspraken zijn verdedigbaar — de eerste klopt in exacte rekenkunde — maar als je evaluatieharness uitvoer byte voor byte vergelijkt, verwacht dan dat die het merkt.

De kostenzijde van het grootboek

De drafter is niet gratis. Hij neemt 655 MB in BF16 op de GPU in beslag (of een 664 MB F16 GGUF op de CPU), zit in dezelfde geheugenpool als het doelmodel, en elke stap die hij voorstelt kost een verificatie-forwardpass over een blok tokens in plaats van over één token. Op een MoE-doelmodel is dat laatste duurder dan het klinkt: het verifiëren van negen tokens activeert meer experts dan het decoderen van één, dus de bytes die per geverifieerd token worden verplaatst gaan omhoog, niet omlaag. Liquid noemde precies dit als de reden dat zijn 8B-drafter slechts 1,18× opleverde op een M4 Max ondanks een sterke acceptatie.

Daar staat tegenover dat de besparingen groot genoeg zijn om in GPU-uren te meten. Met de eigen B300-cijfers van de leverancier uit benchmarks/b300-fp8.csv, en niets meer te doen dan een miljard outputtokens te delen door de waargenomen doorvoer:

• MATH-500, concurrency 1 — 324 tok/s alleen (857 GPU-uur per miljard tokens) versus 853 tok/s met de drafter (326 GPU-uur). Een 2,63× vermindering van rekentijd.

• MATH-500, gelijktijdigheid 256 — 15.423 tok/s alleen (18,0 GPU-uur) versus 27.579 tok/s met de drafter (10,1 GPU-uur). Een verlaging van 1,79×.

• GSM8K, gelijktijdigheid 256 — 4.491 tok/s alleen (61,9 GPU-uren) versus 9.660 tok/s met de drafter (28,8 GPU-uren). Een besparing van 2,15×.

• {{1}}LiveCodeBench{{/1}}, {{2}}concurrency{{/2}} 256 — 18.812 tok/s alleen (14,8 GPU-uur) versus 25.231 tok/s met de drafter (11,0 GPU-uur). Slechts een reductie van 1,34×, de zwakste cel in de tabel.

Dat zijn doorvoerratio's die naar tijd zijn omgerekend, niet naar geld, omdat het geld afhangt van wat je per GPU-uur betaalt en dit artikel gaat geen tarief verzinnen. Maar de ordening geldt bij elk tarief: het toevoegen van de drafter is twee tot drie uur per tien waard voor reasoning- en codegeneratieverkeer bij lage gelijktijdigheid, en ongeveer een derde daarvan waard bij hoge gelijktijdigheid. Als je 24B-implementatie een single-useragent op een workstation is, is het argument sterk. Als het een verzadigd batch-endpoint is, is het argument reëel maar veel zwakker dan de 2.4×-kop suggereert.

Waar de tekenaar zijn geld waard is, in termen van werkbelasting.

De spreiding over acht datasets in de leverancierstabel is geen ruis; ze valt samen met prompttypen, en die koppeling is het nuttigste onderdeel van de release. De acceptatie varieerde van 6,70 tokens per stap op MBPP tot 4,02 op LiveCodeBench. De datasets met hoge scores zijn degene waarbij de output van het model door de prompt wordt beperkt: korte functies in unit-teststijl, rekenwerk met een controleerbaar pad, meerkeuzeantwoorden. De datasets met lage scores zijn degene waarbij het model een lange, onbeperkte oplossing moet bedenken: programmeerwedstrijdproblemen en wiskunde in AIME-stijl.

Dat is de intuïtie die je moet meenemen in je eigen evaluatie. Een 24B-redeneermodel dat wordt verkocht voor agentisch werk, besteedt het grootste deel van zijn outputtokens aan een chain of thought, wat meer op LiveCodeBench dan op MBPP lijkt. Een model dat wordt gebruikt voor gestructureerde extractie, classificatie met een schema of een vast tool-callformaat, lijkt veel meer op de rijen met hoge acceptatie. Als je workload de eerste is, verwacht dan dat je dichter bij de onderkant van 1,34× dan bij de bovenkant van 3,28× uitkomt. Niemand heeft acceptatie per workload voor deze drafter gepubliceerd, en de acht datasets op de kaart zijn het dichtst bij een richtlijn.

Daartegenover staat: de 24B is een model dat alleen redeneert. Liquid zegt dat het altijd nadenkt voordat het antwoordt — de chat-template voegt automatisch een <think>-tag in. Dat is de slechtst mogelijke vorm voor speculatie, want het redeneergedeelte is precies het lange stuk met lage acceptatie. De drafter zal nog steeds helpen; hij zal het meest helpen bij het uiteindelijke antwoord en het minst bij het deel dat het langst duurt.

Hoe je het op je eigen hardware binnen een middag kunt vaststellen

Je hoeft niets van het bovenstaande te vertrouwen. Beide inferentiepaden bieden de acceptatieteller aan, en dat is het enige getal dat bepaalt of de drafter zichzelf op jouw verkeer terugverdient.

Start op SGLang het doelmodel met de drafter eraan gekoppeld, blokgrootte 9 en tien drafttokens, en lees vervolgens de speculatieve-decoderingstatistieken die de server per verzoek rapporteert. De acceptatiegraad in de leverancierstabel ligt tussen 0,33 en 0,65, afhankelijk van de dataset; een run die ruim onder de relevante rij uitkomt, betekent dat de drafter verkeerd gokt en dat je betaalt voor verificatie zonder de versnelling te behalen. Op llama.cpp met de F16 GGUF-sidecar bevatten de timings per antwoord draft_n en draft_n_accepted rechtstreeks. Deel de een door de ander.

Twee operationele details kosten je een uur als je ze mist. De SGLang-server heeft een build nodig die het op 2026-08-31 gemergede LFM2-MoE DSpark-pad bevat — op alles wat ouder is, is de drafter-architectuur simpelweg onbekend. En de blokgrootte is een eigenschap van de checkpoint, geen vrije parameter: llama.cpp begrenst --spec-draft-n-max tot de metadatawaarde van 9 in de sidecar, dus om 12 vragen levert niets op.

De vraag die deze vergelijking niet kan beantwoorden

Er is een versie van "moet ik de drafter koppelen" die niets met GPU's te maken heeft, en dat is de versie waar de meeste teams daadwerkelijk mee te maken krijgen. Als je LFM2.5-24B-A2B via een gehoste API aanroept, is de beslissing over de drafter niet aan jou. De servingstack koppelt al dan niet een speculatieve decoder; je ziet een aantal tokens per seconde en een prijs, en beide zijn upstream bepaald. De eigen Console van Liquid vermeldt de 24B tegen $0,10 per miljoen inputtokens, $0,05 voor gecachte input en $1,00 per miljoen output — een gepubliceerd tarief dat al weerspiegelt welk decodeerpad zij gebruiken, en dat zonder kennisgeving kan veranderen.

Dat is precies het punt waarop routering helpt in plaats van complicaties op te leveren. Een gehoste aanroep en een self-hosted deployment zijn niet zozeer concurrerende plannen als wel twee standen van dezelfde kostenknop: self-hosting plus de drafter minimaliseert de kosten per token als je volume de GPU bezig houdt, en een gehost endpoint minimaliseert het werk om een antwoord te krijgen. OrcaRouter is gebouwd voor het tweede — één sleutel voor meer dan 200 modellen tegen 0% opslag op de lijstprijs van de provider, zodat een prijswijziging van een leverancier dezelfde dag aan onze kant zichtbaar is, met automatische failover als een provider verslechtert en een routing-DSL om verkeer te splitsen in plaats van één backend hard te coderen. Wij bieden de LFM2.5-familie momenteel niet aan, dus voor dit specifieke model betekent de gehoste kant Liquid's eigen API of je eigen GPU's; de vergelijking die de moeite waard is, is met de modellen die we wél aanbieden, zoals Qwen3.6-35B-A3B — het model waarmee Liquid benchmarkt op agentische taken — of Gemma 4 26B-A4B.

Dus: toevoegen of niet

Koppel het als je LFM2.5-24B-A2B zelf serveert bij bescheiden concurrency, vooral voor gestructureerde of extractieachtige output, en als je 655 MB extra ruimte naast het doelmodel hebt. Volgens de cijfers van de leverancier halveer je je decodeertijd daar ongeveer of breng je die terug tot een derde, en het nadeel is beperkt: een slechte drafter kost een verificatieronde, geen fout antwoord.

Laat het achterwege als je endpoint al verzadigd is in de honderden, als je output uit lange vrijvormige redeneringen bestaat, of als je Apple Silicon-cijfers nodig hebt voordat je de knoop doorhakt — de kaart heeft die niet, en de dichtstbijzijnde analoog uit dezelfde familie haalde 1,18× op een MacBook. En laat het uiteraard achterwege als je het model helemaal niet draait: een drafter is een optimalisatie voor een deployment, en er valt niets te optimaliseren totdat de deployment bestaat.

Wat de rest zou beslechten, is een bericht van de leverancier en een meting op een Mac. Geen van beide bestaat op 2026-10-21, wat een vreemde situatie is voor een release waarvan de gewichten al downloadbaar zijn — en, voor iedereen die zelf de acceptatieteller wil draaien, een ongewoon goedkope kans om het eerste onafhankelijke cijfer op het bord te zijn.