On-device har længe været lovet “lige om lidt”. Liquid AI hævder, at det “lidt” er nu. Den 28. maj offentliggjorde de LFM2.5-8B-A1B – en kombination af spars MoE, lang kontekst og værktøjskald – og siger, at den kan køre på almindelig hardware. Tal fra Liquid AI: 8,3 mia. parametre i alt, 1,5 mia. aktive per token, 128K kontekst og en model, der lægger sin tænkevej frem før svaret.
Tager man tallene på ordet, er det et markant løft for lokale assistenter, sensitive dataflows og edge-scenarier. Vi har læst deres tekniske note og dækning hos MarkTechPost, sammenholdt tallene og holdt dem op mod egne erfaringer. Der er substans – og en række praktiske spørgsmål, som ingen produktblog alene kan afklare.
Hurtigt overblik
LFM2.5-8B-A1B er en on-device Mixture-of-Experts-model med 8,3B parametre, hvor 1,5B aktiveres per token (kilde: Liquid AI). Kontekstvinduet er 131.072 tokens (ofte omtalt som 128K). Modellen beskrives som “reasoning-only” – den producerer en eksplicit kæde af overvejelser, inden svaret – og er bygget til tool-calling med tydelige markører i output.
Liquid AI anbefaler temperatur 0,2, top_k 80 og repetition_penalty 1,05. De rapporterer forbedringer på benchmarks mod forgængeren og peger på, at sparsitet gør lokal kørsel realistisk på forbrugshardware. Alle konkrete tal her er fra Liquid AI\/MarkTechPost og bør ses som deres egne målinger, ikke uafhængige tests.
Hvorfor spars MoE gør en forskel
MoE er mange specialiserede “eksperter”, hvor routeren kun aktiverer få per token. Den samlede model kan være stor, men beregningen per token bliver lavere. For LFM2.5-8B-A1B er pointen 1,5B aktive ud af 8,3B i alt – som at hente to specialister ind i stedet for at indkalde hele huset til et kort svar.
I praksis hjælper det på to fronter: mindre compute per token og bedre mulighed for aggressiv kvantisering af inaktive dele uden stor kvalitetsstraf. Teorien er kendt; i drift bliver memory- og cache-håndtering ofte den reelle flaskehals frem for bare FLOPs.
Arkitekturen i korte træk
Ifølge Liquid AI består arkitekturen af 24 lag: 18 double-gated LIV convolution blocks og 6 GQA-lag. Den kombinerer MoE, GQA og gated short convolution blocks. Særligt er samspillet mellem ekspertrouting, konvolutionsblokke til lokal kontekst og GQA for effektiv opmærksomhed ved stor kontekst.
Konteksten er løftet fra 32.768 til 128K tokens siden LFM2-8B-A1B. Vokabularet er øget fra 65.536 til 128.000 for bedre tokenisering af ikke-latinske skriftsprog, med fremhævede gevinster på hindi, thai, vietnamesisk, indonesisk og arabisk. Tokenizeren er udvidet in-place ved at fortsætte BPE-merges fra den gamle, og nye embeddings er initialiseret som gennemsnit af sub-token-dekompositioner, efterfulgt af en kort, totrins tilpasning.
Træningen og hvorfor den betyder noget
Pretraining er skaleret fra 12T til 38T tokens (kilde: Liquid AI). De beskriver en midtraining-fase på 2T tokens ved 32K kontekst med fokus på reasoning, matematik og værktøjsbrug. For at nå 128K nævnes en opjustering af RoPE-basen og yderligere 400B tokens. Budskabet: langkontekst uden kollaps kræver stærkere positionel kodning og målrettet data-eksponering.
På adfærdssiden bruger de RL-trin: preference-optimering for at undgå “doom loops” i lange resonementer og en avg@k-baseret shaping for at sænke hallucinationer og fremme abstention ved usikkerhed. Vi har set tilsvarende effekter i andre modeller; størrelsesordenen skal dog verificeres.
Hvad kræver den af hardware
Liquid AI oplyser, at modellen kan køre under 6 GB hukommelse og fremviser tal som 253 tokens\/sek. på en M5 Max, 146 tokens\/sek. på en Ryzen AI Max+ 395 og cirka 30 tokens\/sek. på en telefon. De tal er ikke uafhængigt valideret og bør betragtes som pejlemærker, ikke facit.
Et enkelt regnestykke for vægt-hukommelse med 1,5B aktive parametre i FP16: 1,5 mia. × 2 byte ≈ 3,0 GB for de aktive lag alene. Dertil kommer aktiveringer og KV-cache. KV-cache skalerer med kontekst; ved 128K bliver den tung. Med 4-bit kvantisering falder vægt-delen til ~0,75 GB for de aktive dele, men cache og aktiveringer kan stadig dominere. For at nærme sig “under 6 GB” kræves typisk aggressiv kvantisering og effektiv cache-håndtering. Vi afventer tredjepartsprofiler.
Latency, throughput og hvem der realistisk kan køre den
En konservativ forventning, baseret på MoE-erfaringer: high-end laptops med nyere Apple Silicon eller stærk x86 med NPU\/GPU kan levere brugbar interaktiv latens; alt fra lavt tocifrede tokens\/sek. til højere tal er realistisk afhængigt af kvantisering og kontekstlængde. Edge-GPU’er i industrien kan mere. Mobiler kan levere beskedne hastigheder – og ~30 tokens\/sek. forudsætter sandsynligvis stram konfiguration og kort kontekst.
Til højthroughput-batch er on-device mindre oplagt. Modellen retter sig mod interaktive eller semi-realtids flows, hvor 128K-kontekst eller tool-calling er afgørende.
Reasoning-only og tool-calling i praksis
Reasoning-only indebærer, at modellen genererer en (evt. synlig) kæde af overvejelser før svaret. Fordelen er mere stabil planlægning og tydeligere fejlpunkter ved opdeling i delopgaver. Ulempen er flere tokens og potentielt synlig usikkerhed, hvis kæden eksponeres ukritisk.
Tool-calling er der, hvor sikkerhed og orkestrering bliver afgørende: autorisation af funktionskald, inputvalidering, sandboxning, logging og en klar rollback-strategi. Vi har set en prototype hos en industrikunde, hvor et uventet tool-kald landede i en planlægningskalender. Småt – men nok til at understrege behovet for stram styring.
Drift og governance kommer til at afgøre slaget
On-device mindsker API-eksponering og kan sænke latens. Til gengæld opstår nye operationelle krav: modelopdateringer på mange enheder, versionsstyring, nøglehåndtering, signering af modelpakker, A\/B-tests, telemetri og cloud-failover. Ét overset håndtag kan stoppe kæden.
I et internt MoE-on-device forsøg så vi to friktioner: routing-scheduler gav uforudsigelig latens, og telemetri fejlede, når enheder var offline i længere perioder (huller i fejlrapporteringen, som driftsteamet missede). Det er her forskellen mellem en pæn demo og en robust produktion viser sig.
Økonomi, der kan mærkes
On-device kan skære variable API-udgifter. Eksempel: 500 brugere × 2.000 tokens\/dag × 20 arbejdsdage = 20 mio. tokens pr. måned. Med en cloud-model til 5 USD pr. mio. input og 25 USD pr. mio. output kan det hurtigt blive en større månedlig post, afhængigt af input\/output-forholdet. Flyttes halvdelen on-device, falder regningen tilsvarende – men der kommer støtteomkostninger på klienter, fx 100–200 kr. pr. enhed pr. måned til drift, patches og overvågning. For nogle cases vinder on-device; for andre gør en god server-side cache det bedre. Det kræver konkret regning.
Privatliv er ikke et prisregnestykke. I sundhed og finans kan on-device være forudsætningen for at komme i gang, fordi data ikke må forlade klinik eller bankens DMZ. Her er 128K-kontekst særligt interessant til lange noter, logfiler og kontrakter – uden at noget forlader bygningen.
Konkurrencebilledet
Anthropic lancerede samtidig Opus 4.8 med markant billigere fast mode i skyen. Markedet deler sig dermed mellem to strategier: gøre cloud radikalt billigere og hurtigere – eller flytte inferens ud på enhederne. Liquid AIs differentiering ligger i on-device MoE, stor kontekst og udvidet vokabular, som især hjælper ikke-latinske sprog. To veje mod samme mål: lav latens og bedre økonomi.
Valget for kunder afhænger af driftskrav og datahjemsted. Med tung governance og lokal dataplacering taler on-device for sig selv. Med global skalerbarhed og central styring kan en billigere cloud-vej være mere lige til. Begge dele kræver seriøse tests.
De uafklarede punkter
Vi mangler uafhængige målinger af latens, energiforbrug og peak-hukommelse på repræsentative enheder. Der er uklarhed om licens og adgang til weights samt fravær af tredjeparts sikkerhedsaudits (jailbreaks og data-leakage). Vi savner også eval-metadata for benchmarks – decoding-indstillinger, hardware og replikationsdetaljer. Uden dem bliver sammenligninger skæve.
Liquid AI nævner bredt økosystem (llama.cpp, MLX, vLLM, SGLang, ONNX, LEAP) og under 6 GB RAM. Det er lovende – men kræver offentlig reproduktion. Skepsis er sund her.
Hvad giver mening at gøre nu
Kør en målrettet PoC. Tag tre repræsentative enheder og mål fire ting: tokens\/sek., energiforbrug pr. 1.000 tokens, peak-hukommelse ved 8K, 32K og 128K kontekst, samt kvalitet på 10 reelle arbejdsopgaver. Brug Liquid AIs anbefalede decoding som baseline. Log alle tool-calls med autorisation og sandbox fra dag ét.
Etabler et letvægts orkestreringslag mellem modellen og jeres systemer: adgangskontrol, auditlog, kvoter og fallback til cloud for lange eller tunge prompts. Det er forskellen mellem en imponerende demo og et system, man tør lade stå alene fredag eftermiddag.
Tre brugsscenarier vi ser som realistiske
En nordisk sundhedsaktør testede en lokal noteassistent til elektroniske journaler, hvor patientdata ikke måtte forlade hospitalets net. Den lange kontekst holdt styr på flere dages udvikling i samme tråd. Gevinsten var tydelig, men governance omkring modelopdatering var bøvlet, indtil signeret opdateringspipeline og staging kom på plads.
En mellemstor industrikunde kørte en edge-model på linjen til at sammenholde sensordata med servicejournaler. On-device sænkede latens for alarmer og undgik dataudtræk til central cloud. Udfordringen var telemetri i offline-perioder; en lokal logbuffer løste huller, når forbindelsen kom igen.
I finans så vi lokal KYC-datarensning på afskærmede klienter. 128K-konteksten hjalp med lange lovtekster og interne retningslinjer i samme kørsel. Tool-calling blev kun tilladt til whitelistrede funktioner med skarp logging – ofte den praktiske forskel mellem en risikovurdering, der passerer, og en der falder.
Antagelser og gennemsigtighed i beregninger
Memory-estimater: FP16 ≈ 2 byte pr. parameter, INT4 ≈ 0,5 byte. Aktiveringer varierer med batch og sekvenslængde; ved store kontekster dominerer KV-cache ofte. Derfor kan en 1,5B-aktiv model have peak-krav væsentligt over vægtstørrelsen. Hvis “under 6 GB” holder bredt, må kvantisering, streaming eller KV-optimering være effektive. Vi vil se reproducerbare profiler.
Latens-tommelfinger: 1,5B aktive parametre i 4-bit med god cache kan give sub-100 ms token-tider på stærke laptops ved kort kontekst. Ved 128K ryger vi op i sekunder, medmindre man chunker eller bruger tool-calls til at afkorte kæden. Her hjælper orkestrering reelt ved at begrænse tænkevejen.
Hvad vi skal have verificeret før produktion
- Latency og tokens\/sek. på tre platforme: ny MacBook, x86 med NPU\/GPU og en edge-enhed uden diskret GPU.
- Energiforbrug pr. 1.000 tokens ved 8K, 32K og 128K kontekst.
- Peak-RAM med FP16, INT8 og INT4 inkl. KV-cache.
- Licens og tilgængelighed af weights, inkl. kommercielle vilkår.
- Sikkerhedstest for jailbreaks, data-leakage og værktøjskald med fejl-IO.
- Reproducerbare benchmark-kørsler med dokumenterede decoding-parametre og hardware.
Hvor efterlader det virksomheder nu
On-device MoE med 1,5B aktive parametre føles for første gang realistisk på klienten – i klart afgrænsede, værdifulde flows. Den lange kontekst og værktøjskald er det væsentlige her, mere end rå sprogkvalitet. Men alt står og falder med governance, opdateringsflow og orkestrering.
Konklusion: Ikke alle skal skynde sig. Men har I følsomme data, realtidskrav eller for dyre API-regninger, så planlæg en stram PoC inden for 4–8 uger. Forskellen viser sig først, når I måler den på jeres egen hardware og jeres egne opgaver.
