PAN 2 vs LFM2.5-2.6B-Base: Twee soorten checkpoints die je hoort te fine-tunen

Het eerste dat opvalt aan LFM2.5-2.6B-Base is het woord Base. De checkpoint van 2,69 miljard parameters van Liquid AI is geen model waarmee je chat; het is het voorgetrainde substraat waaruit de post-getrainde LFM2.5-2.6B-varianten worden gemaakt, gepubliceerd zodat anderen hun eigen varianten kunnen maken. PAN 2 is hetzelfde soort object op dertigvoudige schaal: een diffusietransformer met 29 miljard parameters van het Institute of Foundation Models van MBZUAI, gepubliceerd onder Apache-2.0 met trainingsconfiguraties in de repository, bedoeld om aan te passen in plaats van alleen te consumeren. Naast elkaar gezet zien ze er absurd uit — de een is een taalmodel dat je op een laptop kunt draaien, de ander een video-wereldmodel dat vier B300's wil. Maar beide zijn basisartefacten met een licentie eraan verbonden, en voor iedereen wiens daadwerkelijke werk het is om een checkpoint te pakken en het iets te laten doen waarvoor het niet is getraind, is de interessante vergelijking helemaal niet capaciteit. Het is wat elk ervan je geeft om mee te werken, en wat het kost om het ding vast te houden terwijl je erachter komt.

Begin met de licentie, want dat is het enige harde verschil

De eigen code en gewichten van PAN 2 zijn Apache-2.0. De onderdelen van derden — Qwen3.5-9B als tekstencoder, Wan 2.2 als VAE, Diffusers — worden gebruikt onder hun eigen voorwaarden en worden niet door MBZUAI herverdeeld; je downloadt ze van hun auteurs. Dat is een schone, saaie regeling die juridisch goed ligt bij bedrijven, en het is de belangrijkste reden dat een bedrijf met een beoordelingsproces PAN 2 überhaupt kan adopteren.

LFM2.5-2.6B-Base wordt uitgebracht onder de LFM1.0-licentie, die Hugging Face registreert als overig met een link naar het LICENSE-bestand in plaats van een SPDX-identifier. Dat is geen kritiek — de licentie van Liquid staat commercieel gebruik toe tot een omzetdrempel, wat een gangbare en redelijke vorm is voor een open-weights-release — maar het is een andere vorm dan Apache-2.0, en dat verschil is geen detail dat je pas na de fine-tune ontdekt. Als je juridische team een lijst met vooraf goedgekeurde licenties heeft, staat een van deze twee modellen erop en vereist het andere een gesprek.

Die asymmetrie wijst precies de andere kant op dan de parameteraantallen, en het is de moeite waard om daar even bij stil te staan. Het kleine model is het model met de nodige voorwaarden; het enorme model kun je uitbrengen zonder iemand om toestemming te vragen.

Wat een basis-checkpoint je eigenlijk oplevert

LFM2.5-2.6B-Base is een hybride architectuur: dertig lagen, waarvan tweeëntwintig dubbelgegate kort-convolutieblokken en acht grouped-query attention. Die mix is precies de bedoeling van de LFM-lijn — convolutieblokken zijn goedkoop bij lange sequentielengtes en attentionblokken behouden het ophalen — en daarom kan het model een context van 131.072 tokens dragen bij 2,69 miljard parameters. De training liep tot 34 biljoen tokens over een vocabulaire van 128.000 tokens, met dekking voor zestien talen, waaronder Arabisch, Japans, Koreaans, Thai en Vietnamees.

Wat het niet heeft, is enige vorm van post-training. Geen instruction tuning, geen noemenswaardige chat-template, geen safety-alignment. Een basismodel voorspelt het volgende token en dat is alles wat het doet, waardoor het het verkeerde is om te evalueren op een instruction-followingbenchmark en het juiste om te evalueren op hoe snel een LoRA convergeert op jouw domein. Liquid publiceert het post-trained zustermodel afzonderlijk, en het bestaan van GGUF- en ONNX-builds van dat zustermodel is de duidelijkste intentieverklaring: deze familie is bedoeld om te draaien op apparaten die je zelf bezit.

PAN 2 geeft je aanzienlijk meer scaffolding, en op één specifiek punt minder vrijheid. De repository levert trainingsconfigs voor zowel pretraining als supervised fine-tuning — config/pretrain_29B_720p.yaml en config/sft_29B_720p.yaml — en de documentatie zegt dat je hun datapaden naar je eigen latents moet laten wijzen. Het fine-tuningpad bestaat dus. Maar de data die het verwacht is geen tekst. Het zijn videolatents die zijn geannoteerd in een specifiek gestructureerd captionformaat: gebeurtenissen in volgorde, acties gekoppeld aan actoren, camerabeweging, binnen een budget van 1.536 tokens voor de tekstencoder. Als je PAN 2 op je eigen domein wilt fine-tunen, is je eerste project geen trainingsrun. Het is een datapijplijn die je beeldmateriaal naar dat formaat omzet, en de repository geeft je wel een validator maar niet de annotator.

• Rekenkracht om fijn af te stemmen — LFM2.5-2.6B-Base: één GPU, LoRA op een workstation, uren in plaats van weken. PAN 2: een 67,37 GB transformer op BF16 vóór optimizerstatus, plus een 15,87 GB bevroren encoder en een VAE, op video-latenten. Multi-node, en niemand heeft een recept gepubliceerd.

• Gegevens die u moet aanleveren — LFM2.5-2.6B-Base: tekst, in welk formaat uw taak ook gebruikt. PAN 2: video plus gestructureerde bijschriften over de wereldtoestand in het schema van de repository.

• Wat je eruit krijgt — LFM2.5-2.6B-Base: een tekstgenerator, en na post-training een assistent of een agentbeleid. PAN 2: een video van maximaal 20 seconden bij 704×1248 en 24 fps, die het gevolg van een actie laat zien.

• Licentie — LFM2.5-2.6B-Base: LFM1.0, overige, lees het. PAN 2: Apache-2.0 op zijn eigen gewichten.

Op de enige benchmark waarop ze elkaar bijna ontmoeten

Er is een echte overlap, en die is klein genoeg om interessant te zijn. De modelkaart van OpenBMB's MiniCPM5-2B bevat benchmarks waarin LFM2.5-2.6B wordt vergeleken met zijn eigen 2B-model en een reeks andere modellen, en een van de rijen betreft lange context. Op AA-LCR rapporteert OpenBMB 5,3 voor LFM2.5-2.6B tegenover 59,0 voor MiniCPM5-2B. Op NoLiMa 0,7 tegenover 68,1. Op LongBench v2 30,3 tegenover 43,7.

Dat zijn door concurrenten gerapporteerde cijfers op de harness van een concurrent, en de modelkaart die ze publiceert heeft een duidelijk belang bij de vergelijking. Maar de grootte van de kloof bij de twee moeilijkste long-contextprobes is niet iets wat een harnesskeuze wegverklaart, en het is een nuttige correctie op het lezen van "131,072-token context" als een capaciteitsclaim. Een contextvenster is een capaciteit; recall over lange lengtes is een gedrag. Het Base-checkpoint heeft het eerste en, op basis van bewijs van derden, niet veel van het tweede — precies waarom een fine-tune het beoogde gebruik is in plaats van een long-documentassistent direct uit de doos.

PAN 2 heeft geen equivalente kruiscontrole. Niemand buiten MBZUAI heeft het gebenchmarkt, en de cijfers van de modelkaart zelf zijn de enige die bestaan. Dat is een zwakkere bewijspositie dan die van LFM2.5-2.6B-Base, ook al is het model honderd keer duurder om te draaien — een herinnering eraan dat onafhankelijke evaluatie adoptie volgt, en adoptie het vermogen volgt om het ding überhaupt te kunnen draaien.

De kosten van het vasthouden van elk controlepunt

LFM2.5-2.6B-Base heeft ongeveer 2,7 miljard parameters. In BF16 is dat ruim onder de 6 GB aan gewichten, en de GGUF-builds van het nagetrainde zustermodel brengen het zelfs ruim daaronder. Je kunt het resident houden op dezelfde machine als de rest van je stack, het 's nachts fine-tunen en vergeten dat het er is.

PAN 2 is 86,17 GB verdeeld over zestig bestanden, en het getal dat ertoe doet is niet het totaal maar de opbouw. De transformer is 67,37 GB en elke inference-worker houdt een volledige kopie vast — het eigen inferentiescript van de repository draait één worker per GPU, waarbij elke worker elke N-de prompt neemt, omdat er in dat pad geen tensor-parallelle sharding is. Het vLLM-recept is de gesharde optie, en de kop daarvan is dertien seconden 704×1248-video in ongeveer 119 seconden op vier B300's, met classifier-free-guidance-parallelisme over twee ranks en Ulysses-sequentieparallelisme over twee. De standaard is acht H200's. Een sampler met vijftig stappen en guidance bij elke stap betekent honderd forward passes per clip, en dat is het rekenwerk achter elke configuratiekeuze in het recept.

De eerlijke kostenvergelijking is dus niet "6 GB versus 86 GB". Het is "nul marginale kosten per inferentie versus een multi-GPU-node per twee minuten output". Een fijn afgestemd 2,6B-model dat een query beantwoordt, kost niets meetbaars. Een fijn afgestemd PAN 2 dat een clip van twintig seconden rendert, kost drie minuten lang een GPU-node, en je zult het honderden keren moeten draaien voordat je weet of de fine-tune heeft gewerkt.

Waar een router een van deze raakt

Geen van beide modellen is iets wat een routeringslaag kan bedienen. LFM2.5-2.6B-Base is een basis-checkpoint zonder gehost endpoint dat de moeite waard is om naartoe te routeren — het is een bestand dat je downloadt. PAN 2 heeft helemaal geen gehost endpoint, niet van MBZUAI en niet van iemand anders. Als je plan een van beide omvat, zijn er GPU's bij betrokken.

De reden om routing toch ter sprake te brengen, is dat bijna niemand een basismodel geïsoleerd inzet. Een fine-tuned LFM2.5 is één component in een applicatie die ook een algemene reasoner nodig heeft, en een PAN 2-simulatie is één fase in een pipeline waarvan de eerste fase een taalmodel is dat gestructureerde captions schrijft. Die omringende laag is waar één API voor meer dan 200 modellen de moeite waard is: je houdt het getunede checkpoint op je eigen hardware, routeert de standaardaanroepen via OrcaRouter tegen de lijstprijs van de provider, met 0% markup die wordt doorgegeven, en krijgt automatische failover wanneer een provider een slecht uur heeft. Voor een PAN 2-pipeline specifiek is de captionfase het elastische deel — het rapport rangschikt Claude Opus 5.5, GPT-6 Astra, Kimi K3 en Qwen3.8-Flash op basis van voltooiing van het volledige plan, en Qwen3.8-Flash staat op OrcaRouter, dus je kunt testen welke planner je plannen daadwerkelijk voltooit zonder vier modellen te hoeven provisioneren.

Wat OrcaRouter niet zal doen, is een van beide checkpoints hosten. Het tegendeel beweren zou het soort claim zijn dat klinkt als een functie en zich gedraagt als een bug.

Wat de framing van het basismodel verbergt

Beide releases zijn, in strikte zin, onvoltooid. LFM2.5-2.6B-Base heeft bewust geen instruction tuning; PAN 2 heeft een sectie met beperkingen die zegt dat ongeveer twee op de drie gesimuleerde plannen minstens één stap bevatten die niet wordt uitgevoerd. Geen van beide is een product. Het verschil is wat 'onvoltooid' in elk geval betekent.

Voor LFM2.5-2.6B-Base is onvoltooid een fase in een pipeline die de leverancier stroomafwaarts al heeft voltooid — het post-getrainde model bestaat, de gekwantiseerde builds bestaan, en het basischeckpoint is gepubliceerd voor mensen die willen afwijken. De kloof is bewust en gedocumenteerd.

Voor PAN 2 is onvoltooid de staat van de hele release. De gewichten staan online, de frameworkondersteuning verscheen op 10 november, en het enige dat iemand er publiekelijk over heeft gezegd, is diezelfde middag een bericht van twee alinea's op het eigen X-account van het lab. De beperkingen ervan zijn geen ontwerpkeuze die aan downstreamgebruikers wordt voorgelegd; het zijn open problemen die het team publiekelijk benoemt. Als je PAN 2 fine-tunet, erf je die problemen samen met de gewichten.

Dat is de echte vergelijking, en die mondt niet uit in een aanbeveling tussen de twee modellen, omdat ze geen substituten zijn. Ze mondt uit in een vraag over je project: pas je een beproefd component aan, of bouw je voort op een onderzoeksartefact waarvan de faalmodi nog worden gemeten? LFM2.5-2.6B-Base is het eerste. PAN 2 is het tweede, en de Apache-2.0-licentie is de enige reden dat het tweede überhaupt een optie is.