LFM3-1.7B-Base vs LFM2.5-2.6B-Base: Färre parametrar, färre tokens, mer kontext

Aritmetiken går åt fel håll. LFM3-1.7B-Base, som publicerades den 26 oktober 2026, är 36 % mindre än LFM2.5-2.6B-Base, som Liquid AI släppte den 4 augusti 2026 – 1,73 miljarder parametrar mot 2,69 miljarder. Den tränades också på färre tokens: 22 biljoner mot ungefär 34 biljoner. Enligt de två siffror som branschen vanligtvis använder för att rangordna förtränade modeller borde den nyare checkpointen vara sämre. Liquids påstående är det motsatta, åtminstone för den eftertränade modellen som byggts ovanpå den, och den intressanta frågan för alla som väljer en stomme att finjustera är vilka av dessa skillnader som är verkliga och vilka som är en historia berättad med en benchmarksvit. Att köra jämförelsen bör kosta beräkningskraft, inte ett andra avtal. 0 % påslag OrcaRouter för vidare leverantörernas listpriser med 0 % påslag.

Detta är en jämförelse inom en och samma familj, vilket gör den ovanligt ren. Samma leverantör, samma licensfamilj, samma ordförråd på 128 000 tokens, samma dolda storlek på 2 048, samma bas-till-bas-roll. De två checkpoints skiljer sig åt i arkitektur, datavolym, kontextlängd och mängden efterträning som bakats in i stammen. Nästan allt annat hålls konstant.

Deltat, dimension för dimension

• Parametrar — 1,73B för LFM3-1.7B-Base mot 2,69B för LFM2.5-2.6B-Base. En minskning med 35,7 %, vilket är där raden "35 % färre parametrar" i Liquids lanseringsinlägg kommer ifrån.

• Lager — 24 mot 30. Den nyare modellen är både grundare och smalare.

• Lagerblandning — tretton gattade kortfaltningar, fem attention-block med glidande fönster och sex full-attention-block för LFM3; tjugotvå faltningar och åtta full-attention-block för LFM2.5, utan någon nivå för glidande fönster.

• Attention — sexton query-huvuden och fyra key-value-huvuden i LFM3, jämfört med trettiotvå och åtta i LFM2.5. Båda behåller huvuddimensionen 128 och dold storlek 2 048.

• Feed-forward-bredd — 7 680 för LFM3 mot 10 752 för LFM2.5. Det är här som större delen av parameterreduktionen faktiskt ligger.

• Konvolutionscache — sju för LFM3 mot tre för LFM2.5, med ett tillagt glidande fönster på 256 token.

• Kontext — 262 144 token mot 128 000. Den nyare checkpunkten fördubblar det.

• Förträningstoken — 22 biljoner mot ungefär 34 biljoner, där de sista 3,5 biljonerna i den nyare körningen ägnades åt kurerad mid-training-data inklusive agentiska spår och verktygsanrop.

• Artefakter — LFM3-1.7B-Base levereras endast som BF16-safetensors, på 3,46 GB. LFM2.5-2.6B-Base levereras i Safetensors samt GGUF-, ONNX- och MLX-byggen, körs i kvantiserat skick under 2,5 GB och stöds av Transformers, vLLM, SGLang, llama.cpp och MLX.

Vart parametrarna tog vägen

Minskningen är inte jämnt fördelad, och det spelar roll för den som uppskattar kostnaden för finjustering. Embeddings är bundna i båda modellerna och vokabulären är identisk på 128 000 token, så embeddingmatrisen är oförändrad. Den dolda storleken är oförändrad på 2 048. Besparingarna kommer från tre ställen: sex färre lager, hälften så många attention-huvuden och ett feed-forward-block som är ungefär 29 % smalare.

Att göra feed-forward-blocket smalare är det billigaste sättet att krympa en transformer, eftersom det blocket innehåller största delen av parametrarna i varje lager. Att halvera antalet attention-huvuden minskar både key-value-cachen och vikterna, vilket är anledningen till att en modell med dubbelt så stor kontext fortfarande kan beskrivas som att den får plats i ungefär 1 GB vid 4-bit. Avvägningen är kapacitet: en smalare MLP har mindre utrymme att lagra faktiska associationer, och ett mindre antal huvuden ger modellen färre oberoende uppmärksamhetsmönster att arbeta med. Liquids argument är att bättre data och en bättre sammansättning av lager mer än väl kompenserar. Det argumentet är testbart, och vid publiceringen hade ingen utanför företaget testat det.

Varifrån kontexten kom

Att fördubbla kontexten från 128K till 256K utan att fördubbla uppmärksamhetskostnaden kräver att man inte använder global uppmärksamhet. LFM3:s stack gör det genom att skicka fem av sina tjugofyra lager till ett glidande fönster på 256 token och tretton till faltningar, vilket lämnar bara sex lager som ser hela sekvensen. Konfigurationen har också en partiell rotary-faktor på 0,5 på de globala uppmärksamhetslagren, vilket tillämpar rotary-inbäddningar på hälften av dimensionerna i varje head, samt en rotary-theta på en miljon på dessa lager mot tiotusen på de glidande.

Liquids lanseringsinlägg ger en konkret siffra på vad detta ger: vid 128K tokens är textmodellens KV-cache 1,6 GB. För LFM2.5-2.6B-Base publiceras ingen motsvarande siffra. Jämförelsen är därför riktningsgivande snarare än exakt – den nyare arkitekturen är utformad för att rymma en längre kontext med mindre minne, och leverantörens egen siffra är det enda tillgängliga mätvärdet.

Varför färre tokens är det intressanta påståendet

Trettiofyra biljoner token ned till tjugotvå biljoner är en minskning av förträningsberäkningen på datanivå med 35 %, och det är motsatt riktning mot de flesta modellgenerationer. Det vanliga narrativet är mer data, fler parametrar, bättre modell. Liquids berättelse är färre av båda, med en ny arkitektur och en datamix som tillför vetenskapliga artiklar, kod på repositorienivå, matematik och en bredare spridning av kunskapskällor.

Det 3,5 biljoner token stora mellanträningssteget är det som skiljer denna checkpoint från en vanlig förträning. Det använder kurerad data av högre kvalitet med en större andel agentiska spår och verktygsanrop, och det är där kontextfönstret utökas. Det steget är också anledningen till att basmodellen har en chattmall: mellanträningsdatan formaterades som konversationer, med och utan tankespår.

Inget av detta kan verifieras utifrån. Tokenantal rapporteras av dem själva, datamixar publiceras inte, och det finns ingen ablation som visar vilken ändring som gav vilken förbättring. Påståendet är rimligt – datakvalitet har gång på gång slagit rå volym under de senaste två åren – men rimligt är inte mätt.

Vad en jämförelse bas för bas kan avgöra

Den kan avgöra specifikationer, kostnad och kompatibilitet, och den här sidan gör det. Den kan inte avgöra kvalitet, eftersom ingen av checkpointarna har ett publicerat benchmark. Liquid publicerade ingen utvärdering för LFM2.5-2.6B-Base och har inte heller publicerat någon för LFM3-1.7B-Base. Båda modellkorten rekommenderar checkpointen för omfattande finjustering och hänvisar läsarna någon annanstans för chatt.

Det enda kvalitetsbeviset i familjen är det eftertränade modellparet. Liquid rapporterar LFM3-1.7B med ett genomsnitt på 49,37 i sin egen testsvit mot 31,55 för LFM2.5-2.6B, där den nyare modellen använder 35 % färre parametrar. Det är en stor skillnad, och det är en leverantörssiffra uppmätt på en leverantörsvald testsvit, som jämför två modeller som skiljer sig åt både i efterträning och i stomme. Det är ett bevis för att LFM3-receptet ger en bättre instruktionsmodell. Det är inte ett bevis för att bascheckpointen är en bättre utgångspunkt, eftersom efterträningen ovanpå den skulle kunna förklara hela skillnaden.

Migreringsanteckningar för alla som använder LFM2.5

De två kontrollpunkterna delar vokabulärstorlek, dold storlek och tokenizerfamilj, vilket får migreringen att verka enklare än den är. De delar inte modelleringskod: LFM2.5 laddas som Lfm2ForCausalLM och LFM3 som Lfm3ForCausalLM, båda via anpassad kod med trust_remote_code=True. Ett träningsskript skrivet för den ena kommer inte att ladda den andra utan att ändra modellklassen, och chattmallarna skiljer sig i hanteringen av tankespår.

Den större operativa skillnaden är paketeringen. LFM2.5-2.6B-Base har GGUF-, ONNX- och MLX-byggen och körs under llama.cpp, vLLM, SGLang, Transformers och MLX. LFM3-1.7B-Base levereras som en enda BF16-safetensors-fil; de kvantiserade och plattformsoberoende byggena finns för den eftertränade LFM3-1.7B, inte för bascheckpointen. Om din pipeline är beroende av en GGUF-artefakt konverterar du den själv och validerar resultatet.

Stödet för finjustering är motvikten. LFM3-1.7B-Base länkar TRL-notebooks för övervakad finjustering och fortsatt förträning, och dokumentationen täcker vägen därifrån. Den mindre checkpointen, 256K-kontexten och den agentiska mellanträningen syftar alla på precis den typ av domänanpassning som dessa notebooks demonstrerar.

Vilken trunk ska man utgå från?

Utgå från LFM3-1.7B-Base om du börjar en ny finjustering, din uppgift drar nytta av lång kontext, och du kan arbeta i BF16 med Transformers eller konvertera vikterna själv. Parameterminskningen på 35 % är riktiga pengar i en träningskörning på en enda GPU, den dubblade kontexten är en verklig förändring av kapaciteten, och chattmallen förkortar den övervakade fasen.

Stanna kvar på LFM2.5-2.6B-Base om du redan har en fungerande pipeline, är beroende av en GGUF- eller ONNX-artefakt, eller behöver en checkpoint med ett års communityverktyg bakom sig. Den nyare modellen är tre dagar gammal. Dess instruct-syskon har kvantiserade byggen och stöd från dag ett i vLLM, SGLang, llama.cpp, Ollama, LM Studio, MLX och ONNX Runtime, men bascheckpointen har det inte, och den luckan är det praktiska priset för att vara tidig.

Om du är osäker bör du köra experimentet i stället för att läsa marknadsföringen. Ta en liten del av dina egna data, kör samma recept för fortsatt förträning mot båda trunkarna under samma antal steg och utvärdera på ett avsatt utvärderingsset som du skapade innan du började. Det handlar om några GPU-timmar och besvarar en fråga som ingen leverantörstabell kan besvara. När de två finjusteringarna finns, placera båda bakom en och samma slutpunkt: OrcaRouters routing-DSL kan dela upp trafiken mellan dem, och automatisk failover innebär att ett dåligt experiment inte blir en dålig produktionsdag. Plattformen förmedlar leverantörernas listpriser vidare med 0 % påslag, så kostnaden för att köra testet är kostnaden för beräkningskraften, inte ett andra avtal.

Siffran att hålla koll på

Det påstående som skulle avgöra saken är inte ännu ett genomsnitt. Det är en basmodellsutvärdering – vilken basmodellsutvärdering som helst – publicerad av Liquid eller av en tredje part, som jämför LFM3-1.7B-Base och LFM2.5-2.6B-Base efter ett identiskt finjusteringsrecept. Tills en sådan finns är generationsskillnaden dokumenterad i arkitekturen och konfigurationen, rimlig utifrån tokenantalen och obevisad där det spelar roll. Den nyare checkpointen är mindre, har längre kontext och är bättre paketerad för träning. Huruvida den är bättre är en fråga som repot inte besvarar.