Lad os være ærlige. Små sprogmodeller har længe lovet guld og grønne skove på telefonen og i IoT‑boksen, men ofte snublet over virkeligheden. Liquid AI prøver igen med LFM2.5‑230M: en tekst‑kun model på 230 millioner parametre, 32K kontekst og open‑weight checkpoints på Hugging Face. Den har day‑one support i llama.cpp, MLX, vLLM, SGLang og ONNX. Rapporteret throughput er 213 tokens/sek. på en Galaxy S25 Ultra og 42 på en Raspberry Pi 5. Footprint omkring 293–375 MB.
Pointen er smal og bevidst. Det her er ikke en generalist til smalltalk og kreativitet. Den er bygget til dataudtræk og værktøjsstyring i edge‑miljøer: telefoner, robotter og automationsenheder. Timingen er også et signal: mindre cloud, mere agentik tæt på enheden.
Hvorfor det betyder noget nu
On‑device agentik rykker, fordi latenstid, datasuverænitet og pris trækker beslutninger ud mod kanten. Når en model under 400 MB kan parse formularer, følge instruktioner stramt og trigge værktøjskald, kan flere beslutninger tages i feltet. Det gælder i produktion, sundhed og service‑robotik. Mindre netværksafhængighed. Mere kontrol over dataplanen.
Open‑weight frigivelse af både base‑ og instruction‑tuned checkpoints gør det praktisk: download, kvantisér, test på mål‑hardware, finjustér til domænet. Kombinationen af 32K kontekst og CPU‑optimeret layout peger på lange sessioner og simple tool‑loops uden GPU‑krav. Det er dér mange PoC’er ellers knækker.
En teknisk skitse af modellen
LFM2.5‑230M bygger på LFM2‑arkitekturen med 14 lag: otte double‑gated LIV‑konvolutionsblokke og seks grouped‑query‑attention‑blokke. Tekst‑kun, cirka 65.536 tokens i ordforråd, viden‑cutoff midt 2024. Hybridt layout målrettet hurtig CPU‑inferens. Oversat: hukommelsesadgang, attention‑mønstre og kerner er trimmet til cache og SIMD på almindelige CPU’er.
32K kontekst er tungt. GQA sænker dog nøgle‑/værdi‑omkostningen pr. token, og konvolutionslag fanger lokale mønstre uden fuld‑attentions pris. Resultatet er lavere latenstid og mindre hukommelsesforbrug ved inferens, især ved aggressiv kvantisering.
Dag‑1 support og vejen ind i stacken
Support i llama.cpp, MLX, vLLM, SGLang og ONNX på dag ét er ikke pynt. Det sparer uger. Llama.cpp er den lette C++‑runtime til lokal CPU og mobil. MLX er Apples ramme til Apple Silicon. vLLM og SGLang er server‑orienterede med batching, streaming og skaleret betjening. ONNX åbner for bred hardwarestøtte via onnxruntime.
Den typiske integrationsvej i grove træk: Konvertér checkpoint fra Hugging Face. Vælg kvantisering (ofte 4‑bit for ~300–400 MB og lav cache‑tryk). Vælg runtime efter målplatform. Tune decode‑strategi, temperatur og stop‑tokens. Og sæt tool‑definerende JSON i systemprompten, hvis der skal kaldes funktioner.
Ydelse i marken
Footprintet på cirka 293–375 MB matcher en 4‑bit kvantisering af 230M med overhead. Det passer i RAM på moderne telefoner og på de fleste embedded‑boards med 4–8 GB uden at æde hele systemet. Der er dog ubekendte i målingerne: kilden beskriver ikke promptlængde, batchstørrelse, decode‑opsætning eller om tallene er enkeltkørsler eller gennemsnit. Det kan flytte den oplevede latenstid mærkbart.
Hvad modellen ikke gør
Benchmarkprofilen er tydelig. Modellen er stærk på instruktion og dataudtræk, men svagere på bred viden og visse agentiske værktøjsopgaver. På IFEval noteres 71,71. På IFBench 38,40. På CaseReportBench 22,51. Ifølge tallene ligger den foran Qwen3.5‑0.8B og Gemma 3 1B her. Omvendt scorer den 20,25 på MMLU‑Pro, klart under Qwen3.5‑0.8B’s 37,42. Og på τ²‑Bench Telecom er scoren 5,26, hvilket er lavt.
Det er logisk. En lille model kan trimmes hårdt til stram instruktion og struktureret ekstraktion, men kan ikke bære bred verdensviden eller improvisere på tværs af mange domæner. Undgå derfor tung matematik, kodegenerering og kreativ skrivning. Det er ikke dens job.
Fra træning til adfærd
Pre‑training beskrives som 19 billioner tokens, inklusive en 32K kontekst‑udvidelsesfase. Post‑træningen kører i tre trin: SFT med distillation fra LFM2.5‑350M, derefter DPO og til sidst multi‑domæne RL. Distillation lader den større model forme adfærd, som den mindre arver på udvalgte opgaver — især formatnøjagtighed og tool‑skabeloner.
Der er huller. Kilden beskriver ikke datasættets sammensætning, filtrering eller licenser. Heller ikke kvantiseringsniveauer i benchmarkkørslerne. Tag derfor tallene som producentmålinger indtil uafhængige tests bekræfter dem.
To jobprofiler hvor modellen giver mening
Data‑ekstraktion på kanten. Tænk kliniske notater, servicejournaler eller inspektionsrapporter, der skal parses til faste felter. 32K kontekst hjælper, fordi hele dokumentbunken kan med. En 4‑bit build kører på en commodity‑CPU uden GPU, så behandling kan ske lokalt uden per‑token‑regning.
Let agentik med værktøjsstyring. En hjemme‑hub, der oversætter tale til funktionskald. En robot, der vælger færdigheder og ruter parametre videre. Liquid AI peger selv på en Unitree G1 humanoid med NVIDIA Jetson Orin, hvor modellen fungerede som skill‑selection‑lag over SONIC‑færdigheder. Det er et eksempel, ikke en garanti — men det viser latencykravet og den smalle opgaveprofil.
Hvad integration kræver i praksis
Valgene afgør værdien. Først runtime: llama.cpp for let, lokal CPU og mobil. MLX hvis Apple Silicon er standard. vLLM og SGLang ved mange samtidige kald fra en edge‑flåde. ONNX for bred hardware og fleksibilitet.
Dernæst kvantisering. 4‑bit er ofte bedste kompromis for 230M, men værktøjsudfald og numeriske felter kan kræve 5‑ eller 6‑bit. Mål ekstraktionsnøjagtighed, ikke kun tokens/sek. Tjek også memory layout og tråd‑affinitet på CPU — små ting som NUMA‑binding kan ændre latenstid markant.
Implementerings‑checkliste
- Runtimevalg og build: vælg llama.cpp, MLX, vLLM, SGLang eller ONNX efter platform. Verificér kompilator‑flags og CPU‑instruktionssæt.
- Kvantisering: start 4‑bit, A/B‑test 5‑bit på felter med tal og koder. Mål både latency og ekstraktionsfejl.
- Hukommelsesbudget: reserver 1–1,5 GB overhead til context cache og runtime. Test 32K sekvenser for fragmentering.
- Sikkerhed og compliance: læs lfm1.0‑licensen før kommerciel brug. Plan for dataminimering ved lokal behandling.
- Benchmarks on‑prem: reproducer IFEval/IFBench/CaseReportBench med egne prompts. Log decode‑parametre.
- Overvågning i drift: mål fail‑safe‑rate for tool‑kald, timeouts og recovery‑strategier ved lange sessioner.
Risici og ubesvarede spørgsmål
Stabilitet i lange sessioner på edge‑hardware er ikke dokumenteret. 32K kontekst lyder flot, men hukommelsesstøj, termiske begrænsninger og CPU‑throttling kan give udfald efter 10–20 minutters kontinuerlig drift. Stress‑test med realistiske loglængder og hyppige tool‑kald.
Tool‑use‑robusthed er en joker. Den lave score på τ²‑Bench Telecom antyder sårbarhed ved komplekse værktøjskæder eller fejltilstande. Uden fejlkategorier bør applikationslaget stramme skabelonkrav og argument‑validering. Simpel input‑validering og deterministiske fallback‑regler hjælper.
Konkurrenceperspektiv
Over for Qwen3.5‑0.8B og Gemma 3 1B taber LFM2.5‑230M på bred viden og reasoning‑tunge opgaver, men vinder på instruktion og dataudtræk ifølge de indsendte tal. Ikke overraskende: den er mindre og mere fokuseret. Mod LFM2.5‑350M ligger 230M‑udgaven lavere på flere mål, men nærmer sig på instruktion via distillation.
Er opgaven stram ekstraktion med lav latenstid og lille RAM, er 230M‑klassen konkurrencedygtig. Kræves bredt domænekendskab eller multi‑hop ræsonnement, så nej — større checkpoints er bedre, også på kanten, hvis hardware tillader det.
Hvad det ændrer for it‑organisationer
Flyttes agentik ud på enheder, flytter ansvaret med. Mindre cloud‑afhængighed, flere lokale tests. Arbejdsgangen går fra “kald API” til “styr runtime, kvantisering og modelopdatering”. Det kræver DevOps‑vaner tættere på hardwareteamet og kortere iterationer på prompts, tool‑skemaer og sikkerhed.
Support ændrer sig også. Færre serverincidents, flere sager om firmware, varme og strøm — og cache‑størrelser. Overset småting sluger tid. Den gode nyhed: mindre modeller kan opdateres og valideres hurtigere. Skub små forbedringer ugentligt, ikke kvartalsvis.
Hvornår giver det mening at teste
Hvis sub‑sekund‑latenstid for korte tool‑kald på mobil er vigtig, er LFM2.5‑230M værd at prøve. Hvis edge‑enheder skal udtrække strukturerede felter offline, også ja. Start med en PoC med tre KPI’er: latenstid pr. tool‑kald, tokens/sek. ved jeres gennemsnitlige promptlængde og ekstraktionsnøjagtighed på et annoteret sæt. Sæt en fail‑safe‑rate for værktøjsopkald — og hold den i fokus.
Hold også øje med hvor hurtigt modellen glider ved afvigelser. Små modeller er tit pedantiske, men kan stå af, når input går uden for skema. En stram systemprompt, tydelige tool‑definitioner og en robust parser, der ikke stoler blindt på formatet, hjælper.
Kilder og hvad der mangler
Alle tekniske påstande stammer fra MarkTechPosts gennemgang, inklusive parametre, arkitektur, runtime‑support, licens, benchmarks og træningspipeline. Hvor muligt er tal gengivet direkte. Der mangler detaljer om hardwareopsætning for målinger, promptlængder, batchstørrelser og kvantiseringsniveauer. Træningsdatas sammensætning er ikke beskrevet i dybden.
Konklusionen er nøgtern: tallene er konsistente som producentoplysninger, men fortjener eksterne replikationer. Indtil da bør produktionsbeslutninger hvile på egne målinger på mål‑hardware.
Opfølgning værd at forfølge
Næste skridt: felttests på populære telefoner og på Raspberry Pi 5 med reproducerbare scripts. En integrationsguide med eksempler i llama.cpp og ONNX. Og et interview med Liquid AI om tool‑use‑fejltyperne i τ²‑Bench Telecom, så udviklere kan bygge bedre guardrails.
Resten opdages først, når man sidder med det i hænderne.
