PAN 2 vs LFM2.5-2.6B-Base: Två typer av checkpoints som är avsedda att finjusteras

Det första man lägger märke till med LFM2.5-2.6B-Base är ordet Base. Liquid AI:s checkpoint med 2,69 miljarder parametrar är inte en modell man chattar med; det är det förtränade substratet som de eftertränade LFM2.5-2.6B-varianterna skapas från, publicerat så att andra kan göra sina egna. PAN 2 är samma typ av objekt i trettio gånger större skala: en diffusionstransformer med 29 miljarder parametrar från MBZUAI:s Institute of Foundation Models, publicerad under Apache-2.0 med träningskonfigurationer i repot, avsedd att anpassas snarare än bara konsumeras. Sida vid sida ser de absurda ut – den ena är en språkmodell som du kan köra på en laptop, den andra en videovärldsmodell som vill ha fyra B300. Men båda är basartefakter med en licens kopplad, och för alla vars faktiska jobb är att ta en checkpoint och få den att göra något den inte tränats för, är den intressanta jämförelsen inte förmåga över huvud taget. Det är vad var och en ger dig att arbeta med, och vad det kostar att hålla den vid liv medan du tar reda på det.

Börja med licensen, eftersom det är den enda svåra skillnaden

PAN 2:s egen kod och egna vikter är Apache-2.0. Tredjepartsdelarna – Qwen3.5-9B som textkodare, Wan 2.2 som VAE, Diffusers – används under deras egna villkor och distribueras inte vidare av MBZUAI; du laddar ner dem från deras upphovsmän. Det är en ren, tråkig och företagsjuridiskt vänlig lösning, och det är huvudanledningen till att ett företag med en granskningsprocess överhuvudtaget kan införa PAN 2.

LFM2.5-2.6B-Base släpps under LFM1.0-licensen, som Hugging Face registrerar som övrigt med en länk till LICENSE-filen i stället för en SPDX-identifierare. Det är ingen kritik – Liquids licens tillåter kommersiell användning upp till ett intäktströskelvärde, vilket är en vanlig och rimlig form för ett open-weights-släpp – men det är en annan form än Apache-2.0, och skillnaden är inte en detalj som du upptäcker efter finjusteringen. Om din juridiska avdelning har en lista över förgodkända licenser står en av dessa två modeller på den och den andra kräver ett samtal.

Den asymmetrin går i motsatt riktning mot parameterantalen, och det är värt att dröja vid. Den lilla modellen är den med förbehåll; den enorma är den du kan släppa utan att fråga någon.

Vad en bascheckpoint faktiskt ger dig

LFM2.5-2.6B-Base är en hybridarkitektur: trettio lager, varav tjugotvå är dubbelgatede kortkonvolutionsblock och åtta är grouped-query-attention. Den mixen är hela poängen med LFM-serien – konvolutionsblock är billiga vid långa sekvenslängder och attentionblock bibehåller återkallning – och det är därför modellen kan hantera en kontext på 131 072 token med 2,69 miljarder parametrar. Träningen kördes till 34 biljoner token över ett ordförråd på 128 000 token, med täckning för sexton språk inklusive arabiska, japanska, koreanska, thailändska och vietnamesiska.

Det den inte har är någon efterträning. Ingen instruktionstuning, ingen chattmall värd namnet, ingen säkerhetsalignering. En basmodell förutsäger nästa token och det är allt den gör, vilket gör den till fel sak att utvärdera på ett benchmark för instruktionsföljning och rätt sak att utvärdera för hur snabbt en LoRA konvergerar på din domän. Liquid publicerar den eftertränade syskonmodellen separat, och förekomsten av GGUF- och ONNX-byggen av den syskonmodellen är det tydligaste uttalandet om avsikt: den här familjen är till för att köras på enheter du äger.

PAN 2 ger dig betydligt mer stödstruktur, och mindre frihet på ett specifikt sätt. Repositoriet levererar träningskonfigurationer för både förträning och övervakad finjustering — config/pretrain_29B_720p.yaml och config/sft_29B_720p.yaml — och dokumentationen säger att du ska peka deras datavägar mot dina egna latenter. Så vägen för finjustering finns. Men data den förväntar sig är inte text. Det är videolatenter annoterade i ett specifikt strukturerat caption-format: händelser i ordning, handlingar knutna till aktörer, kamerarörelse, inom en budget på 1 536 tokens för textkodaren. Om du vill finjustera PAN 2 på din domän är ditt första projekt inte en träningskörning. Det är en datapipeline som omvandlar ditt material till det formatet, och repositoriet ger dig en validerare men inte annoteraren.

• Beräkningskraft för finjustering – LFM2.5-2.6B-Base: en enda GPU, LoRA på en arbetsstation, timmar inte veckor. PAN 2: en transformer på 67,37 GB i BF16 före optimerartillstånd, plus en fryst encoder på 15,87 GB och en VAE, på videolatenter. Flera noder, och ingen har publicerat ett recept.

• Data du måste tillhandahålla — LFM2.5-2.6B-Base: text, i vilket format din uppgift än använder. PAN 2: video plus strukturerade världstillståndsbeskrivningar i repots schema.

• Vad du får ut – LFM2.5-2.6B-Base: en textgenerator och, efter efterträning, en assistent eller en agentpolicy. PAN 2: en video på upp till 20 sekunder i 704×1248 och 24 fps, som visar konsekvensen av en handling.

• Licens — LFM2.5-2.6B-Base: LFM1.0, övrigt, läs den. PAN 2: Apache-2.0 för dess egna vikter.

På det enda benchmark där de nästan möts

Det finns en verklig överlappning, och den är tillräckligt liten för att vara intressant. OpenBMB:s modellkort för MiniCPM5-2B benchmarkar LFM2.5-2.6B mot sin egen 2B-modell och en uppsättning andra, och en av raderna är lång kontext. På AA-LCR rapporterar OpenBMB 5,3 för LFM2.5-2.6B mot 59,0 för MiniCPM5-2B. På NoLiMa, 0,7 mot 68,1. På LongBench v2, 30,3 mot 43,7.

Det här är konkurrentrapporterade siffror från en konkurrents testramverk, och modellkortet som publicerar dem har ett uppenbart intresse i jämförelsen. Men storleken på gapet i de två svåraste långkontextproberna är inte något som valet av testramverk förklarar bort, och det är en användbar korrigering mot att läsa ”131 072-tokenkontext” som ett påstående om förmåga. Ett kontextfönster är en kapacitet; återkallning över långa kontexter är ett beteende. Base-checkpointen har det första och, enligt tredjepartsbelägg, inte särskilt mycket av det andra – vilket är precis varför en fine-tune är det avsedda användningssättet snarare än en långdokumentassistent direkt ur lådan.

PAN 2 har ingen motsvarande korskontroll. Ingen utanför MBZUAI har benchmarkat den, och modellkortets egna siffror är de enda som finns. Det är ett svagare bevisläge än LFM2.5-2.6B-Base, trots att modellen är hundra gånger dyrare att köra — en påminnelse om att oberoende utvärdering följer på adoption, och adoption följer på förmågan att överhuvudtaget kunna köra den.

Kostnaden för att hålla varje kontrollpunkt

LFM2.5-2.6B-Base har cirka 2,7 miljarder parametrar. I BF16 är det bekvämt under 6 GB vikter, och GGUF-byggena av den eftertränade syskonmodellen får den väl under det. Du kan ha den kvar i minnet på samma maskin som resten av din stack, finjustera den över natten och glömma bort att den finns där.

PAN 2 är 86,17 GB fördelat på sextio filer, och det viktiga talet är inte totalen utan hur den är fördelad. Transformern är 67,37 GB och varje inferensarbetare har en fullständig kopia – repots eget inferensskript kör en arbetare per GPU, och var och en tar var N:te prompt, eftersom det inte finns någon tensor-parallell sharding i den vägen. vLLM-receptet är det shardade alternativet, och dess rubrik är tretton sekunder 704×1248-video på cirka 119 sekunder på fyra B300:or med classifier-free-guidance-parallellism över två ranker och Ulysses-sekvensparallellism över två. Standard är åtta H200:or. En femtio-stegs sampler med guidance i varje steg innebär hundra forward-pass per klipp, och det är aritmetiken bakom varje konfigurationsval i receptet.

Så den ärliga kostnadsjämförelsen är inte "6 GB mot 86 GB". Det är "noll marginell kostnad per inferens mot en multi-GPU-nod per två minuters utdata". En finjusterad 2,6B-modell som svarar på en fråga kostar inget mätbart. En finjusterad PAN 2 som renderar ett tjugosekundersklipp kostar en GPU-nod i tre minuter, och du kommer att köra det hundratals gånger innan du vet om finjusteringen fungerade.

Där en router vidrör någon av dessa

Ingen av modellerna är något som ett routinglager kan betjäna. LFM2.5-2.6B-Base är en bascheckpoint utan någon hostad endpoint som är värd att routa till – det är en fil du laddar ner. PAN 2 har ingen hostad endpoint alls, varken från MBZUAI eller någon annan. Om din plan involverar någon av dem, involverar din plan GPU:er.

Anledningen till att ändå nämna routing är att nästan ingen driftsätter en basmodell isolerat. En finjusterad LFM2.5 är en komponent i en applikation som också behöver en allmän resonemangsmotor, och en PAN 2-simulering är ett steg i en pipeline vars första steg är en språkmodell som skriver strukturerade bildtexter. Det omgivande lagret är där ett enda API för över 200 modeller är värt att ha: du behåller den finjusterade checkpointen på din egen hårdvara, routar standardanropen via OrcaRouter till leverantörens listpris med 0 % påslag som förs vidare, och får automatisk failover när en leverantör har en dålig timme. Specifikt för en PAN 2-pipeline är bildtextsteget den elastiska delen – rapporten rangordnar Claude Opus 5.5, GPT-6 Astra, Kimi K3 och Qwen3.8-Flash efter hur stor andel av planerna som slutförs, och Qwen3.8-Flash finns på OrcaRouter, så du kan testa vilken planerare som faktiskt slutför dina planer utan att behöva driftsätta fyra modeller.

Det OrcaRouter inte kommer att göra är att vara värd för någon av checkpointarna. Att påstå något annat skulle vara ett sådant påstående som låter som en funktion men beter sig som en bugg.

Vad basmodellinramningen döljer

Båda dessa utgåvor är i strikt mening ofullbordade. LFM2.5-2.6B-Base saknar avsiktligt instruktionstrimning; PAN 2 har ett avsnitt om begränsningar som säger att ungefär två av tre simulerade planer innehåller minst ett steg som inte genomförs. Ingen av dem är en produkt. Skillnaden är vad ”ofullbordad” betyder i respektive fall.

För {{1}}LFM2.5-2.6B-Base{{/1}} är ofärdigt skick ett stadium i en pipeline som leverantören redan har slutfört nedströms – den eftertränade modellen finns, de kvantiserade byggena finns, och bascheckpointen är publicerad för dem som vill avvika. Gapet är avsiktligt och dokumenterat.

För PAN 2 är ofärdighet tillståndet för hela releasen. Vikterna är publicerade, ramverksstödet landade den 10 november, och det enda som någon offentligt har sagt om det är ett inlägg på två stycken på labbets eget X-konto samma eftermiddag. Dess begränsningar är inte ett designval som överlämnats till nedströmsanvändare; de är öppna problem som teamet namnger offentligt. Om du finjusterar PAN 2 ärver du dessa problem tillsammans med vikterna.

Det är den verkliga jämförelsen, och den mynnar inte ut i en rekommendation mellan de två modellerna eftersom de inte är utbytbara. Den mynnar ut i en fråga om ditt projekt: anpassar du en beprövad komponent, eller bygger du på en forskningsartefakt vars felmoder fortfarande mäts? LFM2.5-2.6B-Base är den första. PAN 2 är den andra, och Apache-2.0-licensen är den enda anledningen till att den andra ens är ett alternativ.