LFM2.5-8B-A1B-DSpark versus LFM2.5-2.6B-Base: Het snelheidsdeel versus het ruwe materiaal

Sorteer je de LFM2.5-familie op wat elk checkpoint op zichzelf kan, dan belanden LFM2.5-8B-A1B-DSpark en LFM2.5-2.6B-Base aan tegenovergestelde uiteinden van de lijn — en geen van beide uiteinden kan een vraag beantwoorden. De eerste is een draftmodel met 327,7M parameters dat puur bestaat om Liquid AI's edge-mixture-of-experts-model sneller tokens te laten genereren. De tweede is een ruw voorgetraind checkpoint met 2,69B parameters dat puur bestaat om te worden gefinetuned tot iets anders. Beide werden in augustus 2026 uitgebracht onder Liquid's LFM Open License v1.0, beide zijn op Hugging Face slechts één download verwijderd, en beide zijn extreem makkelijk per ongeluk te pakken — omdat hun namen doen vermoeden dat het twee versies van hetzelfde zijn.

De namen zijn de valstrik. "DSpark" klinkt als het sprankelende nieuwe vlaggenschip van de familie, en "Base" klinkt als de kale standaard die je daadwerkelijk kunt draaien. Geen van beide is waar. De DSpark-checkpoint kan niets zelfstandig beantwoorden — hij stelt alleen tokens voor die de LFM2.5-8B-A1B moet verifiëren. De Base kan ook niets beantwoorden, maar om de tegenovergestelde reden — het is een ongetuned fundament dat tekst voorspelt, maar nooit is nagetraind tot een chat- of agentmodel. Dit is geen rivaliteit; het is een pijplijn. De ene checkpoint staat helemaal aan het einde van een serving-stack, de andere helemaal aan het begin van een trainingsrun.

Twee checkpoints die een naam delen, geen functie.

LFM2.5-8B-A1B-DSpark (uitgebracht op 20 augustus 2026) is een draftmodel voor speculatieve decodering: een vijflaags attention-only netwerk, een blok van negen voorgestelde tokens per stap, en een Markov-head over de woordenschat van 128.000 tokens van het doelmodel. Je laadt het naast de LFM2.5-8B-A1B — een MoE met 8,3B totale parameters en ~1,5B actieve parameters, die al op 28 mei werd uitgebracht — de draft raadt de volgende paar tokens, en het doelmodel verifieert het hele blok in één forward pass, en houdt wat het accepteert. Omdat het doelmodel elk token controleert, is de output onder greedy decoding identiek aan het draaien van de LFM2.5-8B-A1B alleen: "verliesvrij door constructie," in de formulering van Liquid. De draft is een snelheidscomponent, geen brein. Het werd uitgebracht samen met zuster-drafts voor LFM2.5-1.2B-Instruct en LFM2.5-2.6B, elk in Safetensors en GGUF, met ondersteuning vanaf dag één in SGLang en llama.cpp.

{{1}}LFM2.5-2.6B-Base (uitgebracht op 4 augustus 2026){{/1}} is het andere uiteinde van de pijplijn: een fundament met {{2}}2.69B parameters{{/2}} in een hybride stack van 30 lagen — 22 dubbelgepoorte short-convolution-blokken plus 8 grouped-query-attention-blokken — voorgetraind op ongeveer 34 biljoen tokens, met een mid-trainingfase die de context uitbreidt naar 128K. Het heeft geen chat-template, geen instructie-tuning en geen gepubliceerde benchmarks, en Liquid's eigen modelkaart beveelt het alleen aan voor uitgebreide fine-tuning. Het hele doel ervan is om het ruwe materiaal te zijn dat een post-trainingpijplijn in vier fasen — {{3}}twee SFT-rondes, teacher-specialisatie, on-policy-distillatie en daarna agentische reinforcement learning{{/3}} — omvormt tot de tool-calling-agent LFM2.5-2.6B. Zelfde familie, zelfde licentie, zelfde downloadpagina. Hele andere taken.

Naast elkaar: zeven dimensies, twee banen

Omdat de twee controlepunten verschillende functies vervullen, houdt de eerlijke vergelijking de rollen van beide kanten uit elkaar:

• Wat het is — LFM2.5-8B-A1B-DSpark is een 0.3B-conceptmodel voor speculatieve decodering; LFM2.5-2.6B-Base is een 2.69B ruw voorgetraind basismodel.

• Waar het mee draait — de DSpark-draft werkt samen met de LFM2.5-8B-A1B MoE (8,3B totaal, ~1,5B actief per token); de Base draait op zichzelf, maar alleen als niet-afgestelde tekstvoorspelling.

• Zelfstandig gebruik — DSpark produceert zelf niets; het versnelt alleen een doelwit. Base produceert tekst, maar geen nuttig productgedrag — geen instructie-opvolging, geen tool-aanroepen, geen chat-sjabloon.

• Outputkwaliteit — DSpark erft de exacte greedy-output van het doelmodel, omdat elk voorgesteld token wordt geverifieerd; Base heeft per ontwerp nul gepubliceerde benchmarks op welke taak dan ook.

• Snelheid — DSpark voegt een door de leverancier gemeten gemiddelde van 2,54× op een H100 (tot 3,18× op MATH500) en 1,18× op een M4 Max toe aan zijn doelwit, niet gereproduceerd; Base heeft helemaal geen claim over inferentiesnelheid.

• Geheugenvoetafdruk — DSpark voegt ongeveer 0.3GB aan draft-gewichten toe naast het doel; Base is de volledige 2.69B, draaibaar in minder dan 2.5GB, het kleinste serieuze basismodel in de familie.

Formaten en beschikbaarheid — DSpark wordt geleverd in Safetensors en GGUF met ondersteuning voor SGLang en llama.cpp vanaf dag één; Base wordt geleverd in Safetensors plus GGUF, ONNX en MLX en draait op Transformers, vLLM, SGLang, llama.cpp en MLX. Geen van beide wordt vandaag aangeboden door een inference-provider — beide zijn self-host checkpoints.

De enige cijfers in deze wedstrijd kwamen van één laboratorium.

Alle kwantitatieve cijfers hier zijn afkomstig van één leverancier, gemeten op de dag waarop het concept uitkwam en nog niet onafhankelijk gereproduceerd — lees het als veelbelovend, niet als geverifieerd. Liquid mat de LFM2.5-8B-A1B-DSpark met batchgrootte 1, temperatuur 0, op een enkele 80GB H100 in BF16 onder SGLang en op een M4 Max MacBook Pro in FP16 GGUF onder llama.cpp's experimentele Metal-kernels. Op de H100 haalde het paar gemiddeld 2,54× (418 → 1.074 tokens per seconde), met als beste individuele resultaat 3,18× op MATH500 (428 → 1.362 tok/s) en een gemiddelde acceptatie van ongeveer 7 van de 10 voorgestelde tokens. Op de M4 Max haalde hetzelfde paar gemiddeld slechts 1,18× (90 → 106 tok/s) — het on-device randgeval dat Liquid zelf aangaf, omdat het verifiëren van een blok meer experts activeert in de huidige MoE Metal-backend en zorgt voor meer gewichtverkeer over de geheugenbus.

De Base-kant van deze matchup heeft helemaal geen cijfers, en die afwezigheid is zelf de spec. LFM2.5-2.6B-Base was voorgetraind, niet nagetraind; het is nooit geëvalueerd voor chat, toolgebruik of agentgedrag, omdat niemand van plan was het op die manier te gebruiken. De betekenisvolle cijfers zijn architectonisch: 2,69B parameters, 128K context, een tokenizer voor 16 talen, minder dan 2,5GB om te draaien. Je benchmarkt geen fundament; je benchmarkt waartoe je het finetunet.

Er is één familie-ironie die het vermelden waard is voordat je iets beslist. De draft waar dit artikel over gaat — die voor de 8B-A1B — is precies degene die op een laptop het minst oplevert (1,18×), terwijl de zusterdraft voor de 2.6B-familie, die de post-getrainde zuster van deze zelfde Base versnelt, op een M4 Max gemiddeld 2,27× haalt met een reductie van 57% in de function-calling-latentie. Als het apparaat in kwestie een telefoon of laptop is in plaats van een GPU-box, dan leeft het snelheidsverhaal op het 2.6B-pad.

Dus welke download je?

Je hoeft nooit rechtstreeks tussen deze twee te kiezen, want het zijn geen alternatieven — maar je moet wel weten in welke rol je zit:

Als je LFM2.5-8B-A1B draait op GPU's die je zelf bezit en meer tokens per seconde uit dezelfde hardware wilt halen, is de LFM2.5-8B-A1B-DSpark een omkeerbare toevoeging: bouw SGLang of llama.cpp met de DSpark-integraties van 20 augustus, vermeld de draft in het startcommando, houd greedy decoding aan, en de blokgrootte wordt automatisch gelezen uit de config van de draft. Het voordeel is ongeveer 2,5× doorvoer zonder enige verandering in uitvoer; het nadeel is 0,3 GB extra gewichten en een build die nieuw genoeg is om de PR's te bevatten. Verwijder de twee speculatieve vlaggen en je bent terug bij het gewone target.

Als je je eigen specialist wilt bouwen — een domeinmodel, een assistent voor een specifieke taal, een fine-tune op propriëtaire data — dan is de LFM2.5-2.6B-Base een van de goedkoopste serieuze startpunten in het open-weights-ecosysteem: 2,6B, minder dan 2,5 GB, 128K context, een meertalige tokenizer. De DSpark-checkpoint kan je daar helemaal niet mee helpen, omdat het geen base is.

Als je echt Liquid's on-device agent wilt — tool calling, meerstapstaken — dan wil je geen van deze twee. Je wilt de post-getrainde LFM2.5-2.6B, en je kunt daarna beslissen of je er een eigen draft aan vastmaakt. De Base is ruw materiaal voor mensen die willen trainen; de 8B-A1B-draft is een snelheidsonderdeel voor mensen die de MoE al implementeren. De verkeerde zet is het downloaden van de Base omdat je een snellere agent wilde, of de drafter omdat je een fundament om te trainen wilde.

Waar de twee samenkomen — en waar een router past

Beide checkpoints zijn self-host-verhalen. De draft is een hulpcomponent van de servinglaag die alleen binnen je eigen SGLang- of llama.cpp-stack bestaat; de Base is een trainingsartefact. Geen van beide verschijnt in een gehoste catalogus en geen van beide heeft een vermelde prijs per token. Wat dat in de praktijk betekent, is dat elk pad uiteindelijk naast de gehoste modellen komt te staan die je al aanroept — en die mix is precies wat een routinglaag moet samenbrengen.

Aan de serverkant zijn de kosten-baten van het draftmodel eenvoudig en reëel: 2,5× meer tokens per seconde van dezelfde GPU betekent 2,5× minder tijd en ruwweg 2,5× minder GPU's voor dezelfde werklast, zonder kwaliteitsverlies. Maar die hefboom bestaat alleen als je de inferentie in eigen beheer hebt. Op het moment dat je de 8B-A1B via een API aanroept, houdt de provider de versnelling — en daarmee wordt de API-vergelijking de enige die telt: wat een provider in rekening brengt, en of een prijsverlaging je dezelfde dag bereikt als waarop deze wordt aangekondigd. Dat is precies waar een pass-through-router voor dient: één API voor 200+ modellen, provider-lijstprijzen met 0% opslag doorgegeven, zodat een prijsverlaging van de leverancier direct bij jou live is, plus automatische failover, zodat een latentiepiek van één provider niet jouw latentie wordt. Je kunt ook je eigen self-hosted LFM-stack via hetzelfde endpoint aanbieden; zo test je een gloednieuw draftmodel tegen echt verkeer, zonder een productiepad ervan afhankelijk te maken.

LFM2.5-8B-A1B-DSpark en LFM2.5-2.6B-Base delen een familienaam en tegenovergestelde taken: de ene is een snelheidsonderdeel dat aan de edge-MoE is vastgeschroefd, de andere is het onafgestelde brein waaruit de 2.6B-agent groeit. Geen van beide draait op zichzelf. Kies de drafter om een MoE te versnellen die je al op GPU's draait, kies de Base om een 2.6B-fundament te finetunen tot iets van jezelf, en sla beide over als je een werkende agent wilde — want het enige dat beide checkpoints gemeen hebben, is dat geen van beide op zichzelf iets doet dat je kunt gebruiken.

Veelgestelde vragen

Kan ik LFM2.5-8B-A1B-DSpark op zichzelf draaien?

Nee. Het is een conceptmodel zonder op zichzelf staande output — het stelt kandidaat-tokens voor die het LFM2.5-8B-A1B-doelmodel vervolgens verifieert, dus het bestaat alleen binnen een serving-stack voor speculatieve decodering die is gebouwd op de SGLang- of llama.cpp-integraties van 20 augustus. Het alleen downloaden geeft je niets dat je kunt bevragen.

Is LFM2.5-2.6B-Base het checkpoint dat on-device als agent draait?

Niet ongewijzigd. De Base is de ruwe voorgetrainde basis zonder instructie-afstemming en zonder chattemplate. Het model dat als on-device-agent van Liquid draait, is de nagetrainde LFM2.5-2.6B, die via de viertraps post-trainingpijplijn uit de Base wordt geproduceerd — en, als je het sneller wilt, gekoppeld aan de LFM2.5-2.6B-DSpark-draft.