LFM3-1.7B vs MiniCPM5-2B: Liquid's 23-tegen-4-scorebord testen

Op 27 oktober 2026 publiceerde Liquid AI een benchmarktabel met 27 rijen waarin LFM3-1.7B tegenover MiniCPM5-2B stond. Liquids model wint 23 van die rijen. MiniCPM5 wint er vier. Die telling ging snel rond, en dat is een probleem, want een aantal overwinningen is wel het minst informatieve dat je uit een tabel kunt halen waarin één leverancier de benchmarks koos, de harness schreef en beide modellen draaide. Dit is een test van wat die 23–4 je eigenlijk vertelt — en het begint met een bekentenis: de vergelijking waarop Liquid stilzwijgend antwoordt, verscheen een dag eerder op deze blog, en daarin werd precies dit argument niet gemaakt. Dat stuk vergeleek de twee basischeckpoints en concludeerde dat geen van beide bruikbare evaluaties had. Hier is de versie met de post-getrainde gewichten aan beide kanten.

MiniCPM5-2B is het 2,52B dense redeneermodel van OpenBMB, begin september 2026 uitgebracht onder Apache 2.0. LFM3-1.7B is het 1,73B tekst- en agentmodel van Liquid AI, uitgebracht op 27 oktober 2026 onder de LFM Open License v1.0. Ze zitten in dezelfde gewichtsklasse, ze concurreren om dezelfde plek op het apparaat, en ze zijn gebouwd voor duidelijk verschillende taken.

Twee leveranciers, twee harnassen, één tabel

De 23–4-telling bestaat alleen omdat Liquid zijn concurrent opnieuw heeft laten draaien. Dat is een legitieme en ongewoon rigoureuze manier van doen voor een lancering — de meeste leveranciers vergelijken met een cijfer van een openbare ranglijst en laten de opzet onvermeld. Maar een concurrent opnieuw laten draaien op je eigen testomgeving levert geen neutraal resultaat op, en de aanwijzing daarvoor zit in de rijen waar dezelfde benchmark op de kaarten van beide leveranciers voorkomt.

Neem BFCL V4. Liquid meet MiniCPM5-2B op 62,65. OpenBMB's eigen modelkaart meldt 66,6. Neem Humanity's Last Exam: Liquid haalt 8,20 voor MiniCPM5, OpenBMB claimt 8,9. Die verschillen zijn klein — binnen vier punten op een schaal van 0–100 — en ze suggereren dat het verschil tussen de testharnassen bescheiden is op gestandaardiseerde benchmarks. Neem nu SWE-bench Verified, waar OpenBMB 46,4 rapporteert voor MiniCPM5-2B en Liquid 43,40 voor LFM3-1.7B. Zet die twee getallen naast elkaar en MiniCPM5 wint. Zet Liquid's eigen MiniCPM5-rij naast Liquid's eigen LFM3-rij en LFM3 wint. Dezelfde benchmark, dezelfde twee modellen, een tegenovergesteld antwoord, omdat de getallen uit verschillende testharnassen kwamen.

Dit is het hele probleem in één voorbeeld. Geen van beide leveranciers heeft de harnessconfiguratie, het retrybeleid of de prompt-scaffolding gepubliceerd. Totdat iemand beide modellen door één harness laat lopen die niet onder diens controle staat, is elke rij tussen leveranciers in deze vergelijking een muntworp vermomd als meting.

Waar de kloof te groot is om ruis van het testharnas te zijn

Sommige rijen laten zich niet wegverklaren. Agentische webnavigatie is het duidelijkst:

• WebArena-Verified — LFM3-1.7B 38,42 versus MiniCPM5-2B 9,11 op de harness van Liquid.

• AutomationBench — 41,29 vs 4,71.

• RULER 128K — 65,56 vs. 37,96.

• BFCL V4 — 71,39 vs 62,65.

Een verschil van vier punten is scaffolding. Een verschil van negenentwintig punten op WebArena-Verified, of een verschil van zevenendertig punten op AutomationBench, is dat niet. Dat zijn verschillen in of het model überhaupt een meerstapsplan bij elkaar kan houden, en ze komen overeen met wat elke leverancier over zichzelf zegt: Liquid bouwde LFM3 rond agentische mid-training met tool-call-traces, en OpenBMB's eigen documentatie bestempelt MiniCPM5 als zwak op lange meerstapstaken en geneigd tot herhaling. Twee onafhankelijke beschrijvingen van dezelfde zwakte, die uit tegengestelde richtingen komen, zijn het sterkste bewijs in deze hele vergelijking.

De rij voor lange context verdient aparte aandacht, want dat is de rij die mensen verkeerd zullen lezen. RULER 128K op 37,96 voor MiniCPM5 is een retrievalscore bij 128K, niet de bewering dat het model bij 128K stopt — MiniCPM5-2B ondersteunt officieel 131.072 tokens. Het betekent dat MiniCPM5 bij die lengte minder vindt van wat je het vraagt te vinden. LFM3 scoort 65,56 bij dezelfde lengte. Als je werklast "zoek in een lang document en geef antwoord" is, dan bepaalt dat verschil de hele beslissing.

De vier rijen die MiniCPM5 wint — en waarom ze ertoe doen

De tabel van Liquid bezorgt MiniCPM5-2B vier overwinningen: τ³-bench op 69,44 tegen 68,01, GPQA Diamond op 65,15 tegen 63,37, HLE op 8,20 tegen 7,17, en AA-Omniscience op 9,13 tegen 7,07. Drie van de vier zijn kennisbenchmarks. De marges bedragen één tot twee punten, wat binnen de ruisvloer van de meeste evaluatiesuites valt.

Maar het patroon is consistent met het ontwerp van MiniCPM5. OpenBMB heeft het getraind als een redeneermodel met een expliciete denkmodus, in een keten die deep-thinking-SFT over 400 miljard tokens uitvoerde en daarna reinforcement learning met gespecialiseerde leerkrachten, alvorens via on-policy-distillatie naar één enkel dense checkpoint te gaan. Dat is een recept dat erop gericht is meer uit opgeslagen kennis per parameter te halen. De training van LFM3 is gericht op tool calls en het naleven van instructies. Dat GPQA Diamond met 1,8 punten naar MiniCPM5 gaat, is geen verrassing; het zijn de twee trainingsfilosofieën die opduiken waar je ze zou verwachten.

De veel interessantere vergelijking is degene die de tabel van Liquid niet kan maken. MiniCPM5-2B heeft een Artificial Analysis Intelligence Index van 12. LFM3-1.7B heeft, op 28 oktober 2026, helemaal geen vermelding bij Artificial Analysis — geen index, geen onafhankelijk gemeten snelheid, geen neutraal latentiecijfer. Dus het model dat 23 van de 27 rijen verliest, is het model met een onafhankelijk datapunt, en het model dat ze wint, is het model dat vraagt om op vertrouwen te worden aangenomen. Die asymmetrie zou zwaarder moeten wegen dan het aantal overwinningen.

De specificaties die echt goed te vergelijken zijn

Waar geen van beide leveranciers de benchmark van de ander uitvoert, zijn de cijfers saai en betrouwbaar:

• Parameters — LFM3-1.7B 1,73B dense versus MiniCPM5-2B 2,52B totaal, 1,98B niet-embedding.

• Lagen — 24 hybride (13 convolutie, 5 sliding-window, 6 globaal) vs 42 standaard transformerlagen met grouped-query attention bij 16 query- en 2 KV-heads.

• Context — 256K vs. 131.072.

• KV-cache bij 128K — 1,6 GB vs 5,6 GB, op basis van Liquid's meting van beide.

• Geheugengebruik bij 4-bit — ongeveer 1 GB vs ongeveer 1,1 GB in praktijkrapporten.

• Vocabulaire — 128K vs 130.560.

• Licentie — LFM Open License v1.0, gratis onder $10M omzet vs Apache 2.0, geen drempel.

De KV-cache-rij is degene die de hardware bepaalt. Een verschil van 3,5× bij dezelfde contextlengte is het verschil tussen een long-context-agent die op een telefoon past en een die dat niet doet. Het verklaart ook waarom LFM3 256K kan bieden waar MiniCPM5 131K biedt: de tri-hybride laagmix is goedkoper per token context, en dat is precies het doel van het bouwen ervan.

Voor sommige teams maakt het licentieverschil meer uit dan het geheugenverschil. Apache 2.0 kent geen omzetdrempel, geen commerciële overeenkomst om over te onderhandelen en geen onduidelijkheid over herdistributie. De LFM Open License is gratis onder $10 miljoen jaarlijkse omzet en vereist daarboven een gesprek. Een startup onder die grens krijgt beide gratis. Een bedrijf erboven krijgt er één gratis en één na een telefoontje, en dat is een echte inkoopkostenpost, ongeacht welk model hoger scoort.

Ecosysteemondersteuning is het punt waarop MiniCPM5 nog steeds vooroploopt.

Beide families boden op dag één al brede runtime-ondersteuning, dus die kloof is kleiner dan een jaar geleden. LFM3 vermeldt vLLM, SGLang, Transformers, llama.cpp, MLX, ONNX, Ollama en LM Studio, met builds voor BF16, FP8, NVFP4, GGUF, MLX en ONNX. MiniCPM5-2B vermeldt dezelfde runtimes plus GPTQ en DSpark, een conceptmodel voor speculatief decoderen dat met het hoofdcheckpoint samenwerkt.

Het praktische verschil is volwassenheid, niet beschikbaarheid. MiniCPM5-2B is sinds begin september te downloaden, wat neerkomt op {{1}}zeven weken aan communitybugmeldingen, kwantiseringsexperimenten en frameworkpatches waar LFM3 niet over beschikte{{/1}}. Een model dat gisteren is vrijgegeven, zal ruwe kantjes hebben in de GGUF-conversie en de Ollama-verpakking. Dat is geen kritiek op Liquid; zo ziet dag één eruit. Als je het model deze week in productie nodig hebt, is zeven weken waarin anderen eerst tegen de problemen aanliepen iets waard.

Hoe je moet beslissen, en waar een router zijn plek verdient

Geen van beide modellen staat in de OrcaRouter-catalogus — beide zijn open weights die je zelf draait, en dat zeggen we liever ronduit dan iets anders te suggereren. De router doet ertoe op de grens. De eerlijke manier om deze evaluatie uit te voeren is beide modellen achter één endpoint te plaatsen en er echt verkeer naartoe te sturen, en de eerlijke manier om een van beide in productie te draaien is niet een 2B-model het enige te laten zijn dat kan antwoorden.

Daar is automatische failover voor bedoeld. Stuur een verzoek naar LFM3-1.7B, laat het de toolaanroep of de extractie afhandelen waarvoor het is getraind, en val terug op een gehost model wanneer blijkt dat de taak meer stappen nodig heeft dan een 2B-model aankan. Omdat OrcaRouter de lijstprijs van de provider tegen 0% opslag doorgeeft, kost het dure pad alleen wat de provider rekent wanneer het daadwerkelijk wordt gebruikt — de besparing van het routeren naar een klein lokaal model wordt niet opgegeten door de router. De routing-DSL laat je dat als regel uitdrukken in plaats van als een herschrijving: eerst de specialist, de generalist bij falen of bij een betrouwbaarheidsdrempel.

Model融合 is hier de onderbenutte optie. Wanneer twee 2B-modellen het oneens zijn over een classificatie, is het vaak goedkoper om beide te laten antwoorden en de uitkomsten af te stemmen dan om op te schalen naar een 27B-model, en het percentage onenigheid is op zichzelf een nuttig signaal over welke inputs moeilijk zijn. Met een ongeverifieerd model aan één kant van je pipeline is dat soort kruiscontrole goedkoper dan vertrouwen op een leverancierstabel.

Wat zou het beslechten?

Over dertig dagen zou iemand LFM3-1.7B en MiniCPM5-2B via één harness moeten publiceren, waarbij de configuratie samen met de resultaten wordt gecommit. Als LFM3 ergens in de buurt van 38 blijft op WebArena-Verified en 65 op RULER 128K, zal de 23–4-telling bij benadering juist zijn geweest, maar om de verkeerde redenen, en is de agentische kloof echt. Als het richting de cijfers van MiniCPM5 zakt, dan mat de lanceringstabel scaffolding.

Tot die tijd is de verdedigbare positie enger dan de marketing van beide leveranciers. Als je workload meerstaps is, tool-calling of lange documenten omvat, is LFM3-1.7B de betere keuze, en door het geheugenvoordeel is het de enige van de twee die op beperkte hardware past met nog ruimte over. Als je workload kennisretrieval of single-turn reasoning is, of als je een ondubbelzinnige licentie nodig hebt en een model met een onafhankelijke score eraan verbonden, is MiniCPM5-2B de veiligere keuze, en de vier rijen die het wint wijzen precies in die richting. De 23–4-telling is niet zozeer fout als wel onverdiend — en het aantal modellen in een lanceringstabel is niet hetzelfde als een resultaat.