Inkling-Small gør åbne LLM’er mere driftsbare

Thinking Machines Lab har gjort det, de fleste modeludbydere helst vil tale udenom: de har taget en meget stor åben multimodal model og lavet en mindre variant, som næsten holder niveauet på centrale benchmarks. Inkling-Small blev lanceret 30. juli 2026 som en open-weights model under Apache 2.0. Den har 276 milliarder parametre i alt, men bruger kun 12 milliarder aktive parametre pr. token.

Det lyder stadig voldsomt, og det er det også. Men nyheden er ikke, at modellen pludselig kan køre på den gamle ThinkPad. Den kræver stadig GPU-servere, og BF16-varianten kræver ifølge modelkortet mindst 600 GB samlet VRAM. Nyheden er, at en model i denne klasse begynder at ligne noget, platformsteams kan vurdere som drift, licens og kapacitetsplanlægning, ikke kun som forskningsdemo.

Apache 2.0 gør forskellen mindre akademisk

Thinking Machines kalder Inkling-Small en generel multimodal model til tekst, billeder og lyd. Den er bygget til blandt andet coding assistants, tool-use-systemer, chatbots og retrieval augmented generation, altså systemer hvor modellen arbejder oven på egne data og egne værktøjer. Der er også understøttelse af op til 1 million tokens i kontekst, afhængigt af opsætningen.

Det vigtige for virksomheder er licensen. Apache 2.0 er en kendt og relativt enkel licens for kommerciel brug, ændringer og intern distribution. Det betyder ikke, at man bare skal smide modellen ind i produktion uden juridisk gennemgang. Træningsdata, acceptable-use-regler, persondata og sikkerhedsforpligtelser skal stadig vurderes. Men udgangspunktet er langt renere end de mange “åbne” modellicenser, hvor kommerciel brug, omsætning, skala eller bestemte brancher pludselig udløser særvilkår.

Den skelnen bliver mere praktisk for hver måned. Jeg skrev for nylig om GLM-5.2 og presset fra open-weight modeller. Pointen dér var, at capability-gabet til lukkede frontiermodeller bliver mindre. Inkling-Small føjer et andet lag til samme historie: licens og driftsprofil bliver lige så vigtige som rå benchmarkscore.

“Small” betyder stadig serverrum

Navnet er lidt misvisende. Inkling-Small er kun lille i forhold til den oprindelige Inkling-model på 975 milliarder parametre og 41 milliarder aktive parametre. Ifølge modelkortet kræver BF16-checkpointet enten fire NVIDIA B300 GPU’er eller otte H200 GPU’er. Den kvantiserede NVFP4-version sænker kravet til omkring 180 GB samlet VRAM, men det er stadig ikke en almindelig udviklermaskine.

For et dansk SaaS-team betyder det, at selvhosting ikke nødvendigvis er billigere end API. Regnestykket afhænger af belastning, latencykrav, datakrav, compliance og hvor meget man faktisk bruger modellen. Men det er en reel valgmulighed på en anden måde end med trillion-parameter-modeller, der primært giver mening hos hyperscalers eller specialiserede inference-udbydere.

Artificial Analysis placerer Inkling-Small på 40 i deres Intelligence Index mod 41 for Inkling. Thinking Machines rapporterer også 80,2 procent på SWE-bench Verified og 64,7 procent på Terminal Bench 2.1. Benchmarks skal ikke læses som sandhedstavler. De fortæller sjældent, hvordan en model opfører sig på dine supporttickets, dine PDF’er, dine logfiler eller dit kodebase-kaos. Men tallene er gode nok til, at modellen fortjener en plads i en seriøs eval, hvis man allerede undersøger private eller halvprivate LLM-endpoints.

Den praktiske parallel er private LLM-endpoints. Når modellerne kan flyttes tættere på egne data, flytter ansvaret også. Man får mere kontrol over routing, logging og finjustering, men også mere ansvar for overvågning, jailbreak-beskyttelse, outputfiltrering og regressionstest.

Det her er en platformnyhed, ikke bare en modelnyhed

Det mest interessante ved Inkling-Small er tempoet. Den kommer to uger efter den første Inkling-model. Thinking Machines beskriver selv forbedringer i data mix, træningsopskrift, distillation fra den større model og ekstra reinforcement learning for agentic coding. Hvis de kan gentage den proces, er det et tegn på en modelpipeline, hvor nye størrelser og afledte varianter kan produceres hurtigere.

Det er sådan modelmarkedet begynder at ligne almindelig softwaredrift. Ikke én stor model, som alle bruger til alt. Flere modeller med forskellige profiler: en stor model til svære opgaver, en billigere model til hverdagsarbejde, en lokal eller privat model til følsomme data, og et kontrolplan der vælger mellem dem. Den slags arkitektur kræver evals, budgetgrænser, versionsstyring og tydelige fallback-regler. Ellers ender man bare med endnu en sort boks, nu med flere valgmuligheder.

Der er også en sikkerhedsvinkel. Modelkortet siger selv, at Inkling-Small har kendte begrænsninger: hallucinationer, ujævn performance på sprog og domæner, og en tendens til indimellem at følge indirekte skadelige eller rollespilsformulerede prompts. Det er ikke specielt for Inkling-Small. Det er vilkåret for åbne modeller. Men når vægtene kan downloades og ændres, kan udbyderen ikke være eneste sikkerhedslag. Moderation, rate limits, logning, testcases og menneskelig kontrol skal ligge rundt om modellen.

Hvad bør danske IT-teams gøre nu?

Mit råd er ikke at migrere noget vigtigt til Inkling-Small i morgen. Mit råd er at bruge lanceringen som anledning til at stramme sin LLM-arkitektur. Har I en liste over hvilke modeltyper der må bruges til hvilke data? Har I regressionstest for agentopgaver? Ved I hvad en model koster pr. afsluttet arbejdsproces, ikke bare pr. million tokens? Har I en plan for hvad der sker, når en model skifter version eller forsvinder fra en udbyder?

Hvis svaret er nej, er Inkling-Small ikke løsningen. Den er en påmindelse om, at LLM-drift er blevet mere fragmenteret og mere arkitekturtung. De bedste teams kommer ikke til at vælge én model og håbe. De kommer til at bygge en modelportefølje, hvor licens, datakontrol, latency, pris og sikkerhed vægtes eksplicit.

Det er mindre glamourøst end modelrelease-teater. Til gengæld er det sådan, man får AI ud af demoen og ind i produktion uden at miste styringen.