LFM3-1.7B på Ollama: Ett kommando och ett betygskort som delas i två

Vid tidpunkten för skrivandet hade Ollama-sidan för lfm3 varit uppe i ungefär en timme och registrerat 45 nedladdningar. Det är hela dess offentliga användning hittills. Modellen bakom den, LiquidAI/LFM3-1.7B, annonserades en dag tidigare, den 27 oktober 2026, som textmedlemmen i LFM3-familjen byggd på LFM3-1.7B-Base-stommen – tillsammans med vision-, ljud-, omni- och de två beslutsmodellerna som Liquid AI släppte i samma omgång. Det som ändrades den 28 oktober är inte modellen. Det är leveransen: ollama run lfm3 ersätter jakten på en LFM3-kompatibel llama.cpp-build, vilket var vägen på lanseringsdagen.

Anledningen till att det är värt mer än en rad i ändringsloggen är prestandatabellen. LFM3-1.7B står för en av de mest skeva resultattavlorna i småmodellklassen: den slår Qwen3.5-9B – en modell som är mer än fem gånger så stor – inom webbläsarautomatisering, verktygsanrop och instruktionsföljning, och förlorar mot den med tvåsiffrig marginal inom allmän kunskap och långkontextåtervinning. Varje siffra i tabellen är Liquid AI:s egen. Inget av det har ännu reproducerats oberoende.

Vad ändrades egentligen den 28 oktober

Ollama listar fem taggar för lfm3, alla tidsstämplade inom samma timme, alla med en kontextrad på 256K och endast textinmatning. Standardversionen är den som de flesta kommer att hämta.

• lfm3:latest och lfm3:1.7b — 1,7 GB, standardartefakten av Q4-klass, och samma digest under båda namnen

• lfm3:1.7b-mlx-bf16 — 3,5 GB, MLX med full precision för Apple silicon

• lfm3:1.7b-mxfp8 — 2,1 GB, 8-bitars MLX

• lfm3:1.7b-nvfp4 — 1,7 GB, och det här är den man ska läsa noggrant

Den sista taggen har digesten 2012d88e202f – samma artefakt som ligger bakom :latest. Att hämta lfm3:1.7b-nvfp4 via Ollama ger dig inte NVFP4-checkpointen; den riktiga ligger i ett separat repository på Hugging Face, publicerad för GPU-servering snarare än lokal hämtning. Om taggen är en platshållare eller ett misstag vid publiceringen är inget som Ollamas sida dokumenterar. Digestarna går att kontrollera, och de är identiska, vilket är det som spelar roll om du hade räknat med FP4-minnesbesparingar på en laptop.

Själva Ollama-sidan är inte en communityuppladdning. Liquid AI:s modellkort anger Ollama som en av de GGUF-motorer som stöds, bredvid llama.cpp och LM Studio, så detta är den leverantörsangivna vägen som kommer sent, inte en okänd persons bygge. Modellkortstexten på sidan är Liquid:s egen: "LFM3-1.7B är en tri-hybridmodell för lokala agenter och specialiserade applikationer."

Arkitekturen, i de termer som avgör om den passar

LFM3-1.7B har 1,73 miljarder parametrar över 24 lager, och endast sex av dessa lager utför full attention. Tretton är gated kortkonvolutioner med en kärnstorlek på sju, upp från tre i föregående generation, och fem är glidande fönster-attention med ett fönster på 256 token. De flesta token i en lång prompt når aldrig en global attention-matris alls, vilket är där minnesaspekten kommer in.

Liquid lägger en KV-cache på 128K token på 1,6 GB. Samma siffra för Qwen3.5-4B är 4,3 GB och för MiniCPM5-2B är den 5,6 GB. Det gapet, inte parameterantalet, är anledningen till att en 1,7B-modell kan hålla en lång kontext på hårdvara där en 4B-modell inte kan. Två andra siffror är värda att hålla fast vid: 22T förträningstoken och ett avslutande mid-training-steg på 3,5T token som är viktat mot agentiska spår och verktygsanrop. Det sista steget är den tydligaste förklaringen till allt i de två nästa avsnitten.

Kortet listar också 16 språk, ett 128K-ordförråd som delas med LFM2.5-8B-A1B, och tänkandet är påslaget som standard – Ollama exponerar det som en kapacitetstagg, inte som en dold flagga. 256K-kontexten är verklig i konfigurationshänseende, men kortet anger KV-siffran endast vid 128K; vid fulla 256K skalar cachen med fönstret, så betrakta den övre delen av intervallet som en datacenterinställning snarare än en laptopinställning.

Där resultaten är starka

Mönstret är konsekvent i alla uppgifter som belönar att göra något med ett verktyg snarare än att veta något om världen. Det här är siffror som leverantören rapporterat, och jämförelseobjekten är de som Liquid AI valde.

• WebArena-Verified — 38,42 för LFM3-1.7B, 3,02 för LFM2.5-2.6B och 28,94 för Qwen3.5-9B

• AutomationBench — 41,29, mot 0,94 för LFM2.5-2.6B och 15,10 för Qwen3.5-9B

• BFCL V4 verktygsanrop — 71,39, jämfört med 55,89 och 62,83 för samma två

• IFBench — 73,03, jämfört med 48,84 för Qwen3.5-9B

• IFEval — 96,66, den högsta i Liquids tabell

• LiveCodeBench v6 — 73,46, bättre än Qwen3.5-9B:s 69,86

Den mest intressanta raden är inte den största. AA-Omniscience är ett benchmark som delvis poängsätts utifrån huruvida en modell avstår från att svara i stället för att gissa, och LFM3-1.7B uppnår 92,93 på icke-hallucination mot 52,59 för Qwen3.5-9B. Dess noggrannhet på samma uppsättning är 7,07. Lästa tillsammans beskriver dessa två siffror en modell som mestadels säger att den inte vet – vilket är en underskattad egenskap hos en agent som är på väg att utföra en åtgärd, och en dålig sådan hos en assistent som förväntas svara på frågor.

Där den förlorar, ibland rejält

Samma tabell, läst åt andra hållet.

• GPQA Diamond — 63,37, mot 80,40 för Qwen3.5-9B och 65,15 för MiniCPM5-2B, en 2B-modell som slår den

• Humanity's Last Exam, inga verktyg — 7,17, mot 16,41 för Qwen3.5-9B

• RULER 128K — 65,56, jämfört med 84,63 för Qwen3.5-4B och 87,11 för Qwen3.5-9B

• AA-LCR långkontextresonemang — 52,83, mot 62,00 för Qwen3.5-9B

• MCP-Atlas — 32,57, jämfört med 41,37 för Qwen3.5-4B och 42,67 för Qwen3.5-9B

• SWE-bench Verified — 43,40, jämfört med 51,20 för Qwen3.5-9B

• Terminal-Bench 2.1 — 12,92, jämfört med 17,98 för Qwen3.5-9B

RULER-raden förtjänar en egen mening: modellen vars huvudsakliga specifikation är ett 256K-fönster är den svagaste modellen för långkontextsökning i sin egen jämförelsetabell, slagen av modeller som utlovar en fjärdedel av den storleken. Ett långt fönster och förmågan att hitta något i det är separata färdigheter, och LFM3-1.7B har köpt den första utan den andra. Den som planerar att använda den på ett stort kodförråd eller ett långt avtal bör testa den raden innan den litar på specifikationsbladet.

MCP-Atlas och SWE-bench-paret är samma lärdom i ett annat register. LFM3-1.7B är bra på att driva ett enda verktyg med ett tydligt kontrakt. Den ligger efter när det gäller det flerstegs- och flerverktygsarbete som agentramverk faktiskt är byggda för, och ännu mer efter när arbetet kräver att man vet vad en kodbas gör.

Vad dessa siffror är, och vad de inte är

Alla siffror ovan kommer från Liquid AI:s egen utvärderingskörning, publicerad i samband med lanseringen. Metodiken finns inte i tillkännagivandet: ingen konfiguration av testriggen per test, ingen uppgift om hur många försök som ingick i medelvärdet, ingen uppgift om huruvida jämförelsemodellerna kördes av Liquid eller citerades från deras egna modellkort. En tabell med 27 rader och en enda ägare är ett argument, inte en mätning.

Det finns ingen LFM3-1.7B-post på Artificial Analysis per den 28 oktober, så det finns ingen tredjepartssiffra att ställa mot leverantörens. Det kommer att ändras, och när det sker blir den mest informativa jämförelsen de agentiska raderna, där leverantörens marginaler är störst och därför mest i behov av en andra åsikt.

En detalj drar åt andra hållet och förtjänar beröm. Liquid tränade en kvantiseringsmedveten destillationscheckpoint specifikt för att återvinna den noggrannhet som Q4_0-kvantisering kostar, och levererar den som en separat GGUF-fil. Att publicera siffrorna för små modeller vid den precision folk faktiskt kommer att köra är mer än vad de flesta leverantörer gör, och det gör 4-bitssiffrorna något mer trovärdiga än en post-hoc-kvantisering skulle göra.

Köra det – och inställningarna som spelar roll

Enradskommandot är ollama run lfm3, och standardvalet på 1,7 GB är rätt utgångspunkt på en 16 GB-maskin. Sidan innehåller också fyra enradiga startkommandon som kopplar in modellen i en befintlig agentharness – ollama launch claude --model lfm3, och samma mönster för OpenCode, Hermes Agent och OpenClaw. Det är det mest användbara på sidan: det innebär att modellen kan släppas in i en agentloop som du redan kör utan att skriva en klient, vilket är en lägre tröskel än vad de flesta lanseringar av lokala modeller klarar.

Två samplingsprofiler finns på kortet och de är inte utbytbara: temperatur 0,1 med top_k 50 och repetitionsstraff 1,1 för chatt, verktygsanvändning, agenter och kodning; temperatur 1,0 med top_p 0,95 och top_k 20 för matematik och naturvetenskap. Att köra agentprofilen på ett matematikproblem är det vanligaste sättet att få den här modellen att se sämre ut än den är.

Om du hämtar GGUF direkt i stället för via Ollama fördelar filstorlekarna sig på ett användbart sätt. Checkpointen QAD Q4_0 är 1,05 GB, marginellt mindre än Q4_K_M på 1,1 GB, och det är den som är tränad att klara kvantisering. Q6_K är 1,43 GB och Q8_0 är 1,85 GB om utrymmet finns; BF16 är 3,47 GB och sällan värt det i den här storleken.

Licensen är LFM Open License v1.0 — till sitt innehåll Apache 2.0, med ett tillägg: kommersiell användning är gratis under 10 miljoner dollar i årliga intäkter och kräver en betald licens vid eller över den nivån. Tröskeln aggregeras över en koncern och följer med finjusteringar, så en omdöpt derivatversion kommer inte undan den. Ideella organisationer och forskningsanvändare är undantagna oavsett intäkter. Om du ligger nära den gränsen bör du läsa licenstexten i stället för en sammanfattning, inklusive denna.

Vad den delade profilen innebär för hur du distribuerar den

En modell som är stark på att följa instruktioner och verktygskontrakt, svag på parametrisk kunskap och långkontextsökning, och tillräckligt billig för att köras på en laptop är inte en allmän assistent. Den är en utförare. Arkitekturen som passar den är en lokal loop – modellen avgör vilket verktyg som ska anropas, formaterar argumenten, följer schemat – medan de kunskapstunga och genuint långkontextuella stegen lämnas över till något större.

Den uppdelningen är det fall där en router förtjänar sin plats, och det är värt att vara precis om vad OrcaRouter gör och inte täcker här. LFM3-1.7B har öppna vikter och körs på din egen hårdvara; den finns inte i vår katalog, och inget i den här artikeln är en API-pitch för den. Det vi tillhandahåller är den andra halvan av uppdelningen: en nyckel över 200-plus hostade modeller för eskaleringssteget, med 0 % påslag på leverantörernas listpriser, automatisk failover när en leverantör försämras, och en routing-DSL som komponerar flera modeller till ett enda anrop. Den praktiska versionen är att den lokala modellen förblir standard för loopen, och att de anrop som behöver faktisk kunskap går ut genom en enda endpoint i stället för en andra SDK och ett andra avtal.

Om du utvärderar modellen i stället för att driftsätta den är failover det billigare sättet att ta reda på om den håller: dirigera en del av trafiken till den, behåll reservlösningen konfigurerad och jämför på dina egna uppgifter i stället för Liquid AIs tabell.

Frågor som lanseringen lämnar öppna

Är Ollama-bygget samma sak som Hugging Face GGUF?

Inte riktigt. Ollamas standard på 1,7 GB är av Q4-klass och motsvarar den generiska GGUF snarare än den kvantiseringsmedvetna checkpointen, som är en separat fil på 1,05 GB på Hugging Face tränad för att återställa Q4_0-noggrannhet. Taggen nvfp4 löser till samma digest som :latest, så den är inte NVFP4-bygget trots namnet. Om kvantiseringskvaliteten spelar roll för din uppgift, hämta QAD-filen och kör den direkt genom llama.cpp.

Kan en bärbar dator använda hela 256K-fönstret?

Sällan. Siffran 1,6 GB cache som Liquid publicerar gäller för 128K, och cachelagringsminnet skalas med fönstret, så den fulla 256K kräver ungefär dubbelt så mycket innan vikterna och körtiden räknas in. På en maskin med 16 GB är ett arbetskontext i intervallet 32K till 64K det realistiska taket; den större fönsterstorleken bör hellre tolkas som ett utrymmesanspråk för serverdriftsättningar än som en kapacitet för bärbara datorer.

Varför skiljer sig agentpoängen och kunskapspoängen så mycket åt?

Eftersom de mäter olika saker, och träningskörningen gynnade den ena. Det sista mellanliggande träningssteget på 3,5T tokens betonade agentiska spår och verktygsanrop, sedan lade efterträningen till övervakad finjustering på 1,75T tokens och förstärkningsinlärning inom verktygsanvändning och strukturerad utdata. Parametrisk kunskap är det en 1,7B-modell har minst utrymme att lagra, och AA-Omniscience-uppdelningen – 7,07 noggrannhet mot 92,93 icke-hallucinering – tyder på att den tränades att avstå snarare än att gissa. Det är ett designval, och det är rätt val för en agent.

Domen

LFM3-1.7B är den första modellen i den här viktklassen där raderna för agentiska benchmarks är anledningen att ladda ner den snarare än en fotnot. Om du bygger en lokal agent som behöver anropa verktyg på ett tillförlitligt sätt, följa ett schema och avstå i stället för att hitta på ett svar, är den nu ett kommando bort och profilen passar uppgiften. Om du behöver en modell som kan saker, hämtar information från ett långt dokument på ett korrekt sätt eller arbetar sig igenom en flerstegsingenjörsuppgift, säger tabellen klart och tydligt att du bör leta någon annanstans — och specifikationen på 256K är den minst trovärdiga raden i den.

Siffran att hålla utkik efter är inte medelvärdet 49,37. Det är huruvida en oberoende körning återskapar de agentiska marginalerna, eftersom det är de raderna där en 1,7B-modell hävdar att den slår en 9B-modell och där en leverantörs eget utvärderingsramverk har störst utrymme att försköna.