LFM3-1.7B-Base vs LFM2.5-2.6B-Base: minder parameters, minder tokens, meer context

De rekensom pakt verkeerd uit. LFM3-1.7B-Base, gepubliceerd op 26 oktober 2026, is 36% kleiner dan LFM2.5-2.6B-Base, dat Liquid AI op 4 augustus 2026 uitbracht — 1,73 miljard parameters tegen 2,69 miljard. Het is ook op minder tokens getraind: 22 biljoen tegen ongeveer 34 biljoen. Volgens de twee getallen die de sector gewoonlijk gebruikt om vooraf getrainde modellen te rangschikken, zou het nieuwere checkpoint slechter moeten zijn. Liquid beweert het omgekeerde, althans voor het post-getrainde model dat erop is gebouwd, en de interessante vraag voor iedereen die een basismodel kiest om te fine-tunen is welke van die verschillen echt zijn en welke een verhaal is dat met een benchmarksuite wordt verteld. Het uitvoeren van de vergelijking zou rekenkracht moeten kosten, niet een tweede contract. 0% opslag OrcaRouter geeft de lijstprijzen van providers door tegen 0% opslag.

Dit is een vergelijking binnen één familie, wat het ongewoon zuiver maakt. Dezelfde leverancier, dezelfde licentiefamilie, dezelfde vocabulaire van 128.000 tokens, dezelfde verborgen grootte van 2.048, dezelfde basis-tot-basisrol. De twee checkpoints verschillen in architectuur, datavolume, contextlengte en de hoeveelheid post-training die in de trunk is ingebakken. Vrijwel al het overige wordt constant gehouden.

De delta, dimensie voor dimensie

• Parameters — 1,73B voor LFM3-1.7B-Base tegen 2,69B voor LFM2.5-2.6B-Base. Een reductie van 35,7%, en daar komt de regel "35% minder parameters" in de launchpost van Liquid vandaan.

• Lagen — 24 tegen 30. Het nieuwere model is zowel ondieper als smaller.

• Laagmix — dertien korte convoluties met gating, vijf sliding-window-attentieblokken en zes volledige-attentieblokken voor LFM3; tweeëntwintig convoluties en acht volledige-attentieblokken voor LFM2.5, zonder sliding-window-niveau.

• Aandacht — zestien query-heads en vier key-value-heads in LFM3, tegenover tweeëndertig en acht in LFM2.5. Beide behouden head-dimensie 128 en verborgen grootte 2.048.

• Feed-forward-breedte — 7.680 voor LFM3 tegenover 10.752 voor LFM2.5. Hier zit het grootste deel van de parameterreductie.

• Convolutiecache — zeven voor LFM3 tegenover drie voor LFM2.5, met een toegevoegd schuifvenster van 256 tokens.

• Context — 262.144 tokens tegenover 128.000. De nieuwere checkpoint verdubbelt dat.

• Pre-trainingstokens — 22 biljoen tegenover ongeveer 34 biljoen, waarbij de laatste 3,5 biljoen van de nieuwere run gewijd is aan samengestelde mid-trainingdata, inclusief agentische traces en tool calls.

• Artefacten — LFM3-1.7B-Base wordt alleen geleverd als BF16-safetensors, 3,46 GB groot. LFM2.5-2.6B-Base wordt geleverd in Safetensors plus GGUF-, ONNX- en MLX-builds, draait gequantiseerd in minder dan 2,5 GB en wordt ondersteund door Transformers, vLLM, SGLang, llama.cpp en MLX.

Waar de parameters naartoe gingen

De reductie is niet gelijkmatig verdeeld, en dat is belangrijk voor iedereen die de kosten van fine-tuning inschat. Embeddings zijn in beide modellen gekoppeld en de vocabulaire is identiek met 128,000 tokens, dus de embeddingmatrix is ongewijzigd. De hidden size is ongewijzigd op 2,048. De besparingen komen van drie plekken: zes minder lagen, half zoveel attention-heads, en een feed-forwardblok dat ongeveer 29% smaller is.

Het versmallen van het feed-forwardblok is de goedkoopste manier om een transformer te verkleinen, omdat dat blok de meeste parameters in elke laag bevat. Het halveren van de attention heads vermindert zowel de key-value-cache als de gewichten, waardoor een model met een verdubbelde context nog steeds kan worden beschreven als passend in ongeveer 1 GB bij 4-bit. De prijs is capaciteit: een smaller MLP heeft minder ruimte om feitelijke associaties op te slaan, en een kleiner aantal heads geeft het model minder onafhankelijke aandachtspatronen om mee te werken. Het argument van Liquid is dat betere data en een betere laagmix dat ruimschoots compenseren. Dat argument is testbaar, en op het moment van publicatie had niemand buiten het bedrijf het getest.

Waar de context vandaan kwam

Het verdubbelen van de context van 128K naar 256K zonder de aandachtskosten te verdubbelen, vereist dat er niet globaal wordt geattendeerd. De stack van LFM3 doet dat door vijf van zijn vierentwintig lagen een sliding window van 256 tokens te geven en dertien aan convoluties, waardoor slechts zes lagen de volledige sequentie zien. De configuratie bevat ook een partiële rotary-factor van 0,5 op de global-attentionlagen, waarbij rotary-embeddings worden toegepast op de helft van de dimensies van elke head, en een rotary-theta van één miljoen op die lagen tegenover tienduizend op de slidinglagen.

De launchpost van Liquid noemt één concreet getal voor wat dit oplevert: bij 128K tokens is de KV-cache van het tekstmodel 1,6 GB. Voor LFM2.5-2.6B-Base is geen vergelijkbaar cijfer gepubliceerd. De vergelijking is daarom indicatief in plaats van exact — de nieuwere architectuur is ontworpen om een langere context in minder geheugen vast te houden, en het eigen cijfer van de leverancier is de enige beschikbare meting.

Waarom minder tokens de interessante bewering is

Van vierendertig biljoen tokens naar tweeëntwintig biljoen is een vermindering van 35% in pre-training-rekenkracht op dataniveau, en het is de tegenovergestelde richting van de meeste modelgeneraties. Het gebruikelijke verhaal is meer data, meer parameters, een beter model. Liquid's verhaal is minder van beide, met een nieuwe architectuur en een datamix die wetenschappelijke artikelen, code op repositoryniveau, wiskunde en een bredere spreiding van kennisbronnen toevoegt.

De mid-trainingfase van 3,5 biljoen tokens is wat dit checkpoint onderscheidt van een rechtstreekse pretraining. Er wordt gebruikgemaakt van samengestelde data van hogere kwaliteit, met een groter aandeel agentische sporen en tool calls, en in deze fase wordt ook het contextvenster uitgebreid. Die fase is ook de reden dat het basismodel een chatsjabloon heeft: de mid-trainingdata was geformatteerd als gesprekken, met en zonder denksporen.

Niets hiervan kan van buitenaf worden geverifieerd. Tokentellingen zijn zelfgerapporteerd, datamengsels worden niet gepubliceerd en er is geen ablatie die laat zien welke wijziging welke winst opleverde. De bewering is plausibel — datakwaliteit heeft het de afgelopen twee jaar herhaaldelijk gewonnen van ruw volume — maar plausibel is niet gemeten.

Wat een basis-tot-basisvergelijking kan beslechten

Het kan uitsluitsel geven over specificaties, kosten en compatibiliteit, en dat doet deze pagina. Het kan geen uitsluitsel geven over kwaliteit, omdat geen van beide checkpoints een gepubliceerde benchmark heeft. Liquid heeft geen evaluatie gepubliceerd voor LFM2.5-2.6B-Base en ook geen voor LFM3-1.7B-Base. Beide kaarten bevelen het checkpoint aan voor uitgebreide fine-tuning en verwijzen lezers voor chat naar elders.

Het enige kwaliteitsbewijs in de familie is het post-getrainde tweetal. Liquid rapporteert {{1}}LFM3-1.7B{{/1}} met een gemiddelde van 49,37 op zijn eigen suite tegenover 31,55 voor {{2}}LFM2.5-2.6B{{/2}}, waarbij het nieuwere model 35% minder parameters gebruikt. Dat is een groot verschil, en het is een leverancierscijfer gemeten op een door de leverancier gekozen suite, waarbij twee modellen worden vergeleken die zowel in post-training als in trunk verschillen. Het is bewijs dat het LFM3-recept een beter instructmodel oplevert. Het is geen bewijs dat het basischeckpoint een beter startpunt is, omdat de post-training daarbovenop het hele verschil zou kunnen verklaren.

Migratienotities voor iedereen op LFM2.5

De twee checkpoints delen een vocabulairegrootte, een verborgen grootte en een tokenizerfamilie, waardoor migratie eenvoudiger lijkt dan het is. Ze delen geen modelleercode: LFM2.5 laadt als Lfm2ForCausalLM en LFM3 als Lfm3ForCausalLM, beide via aangepaste code met trust_remote_code=True. Een trainingsscript dat voor de ene is geschreven, laadt de andere niet zonder de modelklasse te wijzigen, en de chattemplates verschillen in hun omgang met thinking-traces.

Het grotere operationele verschil is de verpakking. LFM2.5-2.6B-Base heeft GGUF-, ONNX- en MLX-builds en draait onder llama.cpp, vLLM, SGLang, Transformers en MLX. LFM3-1.7B-Base wordt geleverd als één enkel BF16-safetensorsbestand; de gequantiseerde en platformonafhankelijke builds bestaan voor de nagetrainde LFM3-1.7B, niet voor het basis-checkpoint. Als je pipeline afhankelijk is van een GGUF-artifact, converteer je het zelf en valideer je het resultaat.

Ondersteuning voor fine-tuning is het tegenwicht. LFM3-1.7B-Base linkt naar TRL-notebooks voor supervised fine-tuning en voortgezette pre-training, en de documentatie behandelt het traject vanaf daar. Het kleinere checkpoint, de 256K-context en de agentic mid-training zijn allemaal precies gericht op het soort domeinaanpassing dat die notebooks demonstreren.

Vanuit welke trunk moet ik beginnen?

Begin met LFM3-1.7B-Base als je een nieuwe fine-tune start, je taak baat heeft bij een lange context, en je met Transformers in BF16 kunt werken of de gewichten zelf kunt converteren. De parameterreductie van 35% is echt geld bij een training op één GPU, de verdubbelde context is een echte verandering in capaciteit, en het chatsjabloon verkort de gesuperviseerde fase.

Blijf op LFM2.5-2.6B-Base als je al een werkende pipeline hebt, afhankelijk bent van een GGUF- of ONNX-artefact, of een checkpoint nodig hebt waar een jaar aan community-tooling achter zit. Het nieuwere model is drie dagen oud. Het instruct-model daarnaast heeft gequantiseerde builds en ondersteuning vanaf dag één in vLLM, SGLang, llama.cpp, Ollama, LM Studio, MLX en ONNX Runtime, maar het base-checkpoint niet, en dat gat is de praktische prijs van er vroeg bij zijn.

Als je twijfelt, voer het experiment uit in plaats van de marketing te lezen. Neem een kleine selectie van je eigen data, voer hetzelfde continued-pre-training-recept uit tegen beide trunks voor hetzelfde aantal stappen, en evalueer op een hold-outset die je hebt samengesteld voordat je begon. Dat kost een paar GPU-uren en het beantwoordt een vraag die geen enkele leverancierstabel kan beantwoorden. Wanneer de twee fine-tunes bestaan, zet je beide achter één endpoint: OrcaRouter's routing-DSL kan het verkeer tussen beide verdelen, en automatische failover betekent dat een slecht experiment geen slechte productiedag wordt. Het platform geeft de lijstprijzen van providers door tegen 0% markup, dus de kosten van het uitvoeren van de test zijn de kosten van de rekenkracht, niet die van een tweede contract.

Het getal om in de gaten te houden

De claim die dit zou beslechten, is niet nog een gemiddelde. Het is een base-model-evaluatie — elke base-model-evaluatie — gepubliceerd door Liquid of door een derde partij, waarin LFM3-1.7B-Base en LFM2.5-2.6B-Base worden vergeleken na een identiek fine-tuningrecept. Tot die bestaat, is het generatieverschil gedocumenteerd in de architectuur en de config, aannemelijk in de tokentellingen, en onbewezen waar het ertoe doet. Het nieuwere checkpoint is kleiner, heeft een langere context en is beter verpakt voor training. Of het beter is, is een vraag die de repository niet beantwoordt.