Hvad er en AI-model? En udviklerguide til LLM, træning, inference og begrænsninger

Hurtigt overblik: Hvad er en AI-model?

En AI-model er en matematisk struktur med en masse parametre, der er trænet på data til at genkende mønstre og lave forudsigelser eller generere output. For dig som udvikler er modellen den lærte kerne, mens AI-værktøjet eller produktet er alt det rundt om: API, UI, logging, sikkerhed og integrationer.

Det er vigtigt at skille tingene ad:

• AI-model: Vægte, arkitektur, parametre og selve beregningen.
• AI-system: Model + kode omkring den (API, køer, databaser, logging osv.).
• Produkt/platform: Chatbot, Copilot, SaaS, IDE-plugin osv., som bruger systemet.

Når du snakker om at “bruge AI”, arbejder du i praksis med alle tre lag på én gang, men de har vidt forskellige krav til design, drift og ansvar.

Hvad er en AI-model – mere præcist?

En AI-model er et parameterbaseret system, der er trænet på data til at lave bestemte opgaver: klassificere, rangere, forudsige eller generere. Den tager et input (tekst, billede, lyd), omsætter det til tal, kører en masse matrixoperationer og returnerer et output, der afspejler mønstrene i træningsdataene.

En model er altså ikke:

• selve chatgrænsefladen
• API-klienten i din kode
• hostingplatformen eller devops-opsætningen

Det er den matematiske “motorblok”, du kan udskifte, uden at resten af systemet nødvendigvis ændrer sig. I kode ender den typisk som et kald til et bibliotek (fx PyTorch/TensorFlow) eller et HTTP-kald til et eksternt endpoint.

Tre typiske typer AI-modeller, du møder:

• Klassifikationsmodeller: fx “spam / ikke spam”, “positiv / negativ tekst”.
• Regressionsmodeller: fx forudsige et tal: pris, sandsynlighed, temperatur.
• Generative modeller: fx skrive tekst, lave billeder, kode eller lyd.

Når folk taler om “AI” lige nu, mener de ofte generative modeller, især store sprogmodeller. Dem kigger vi på nu.

Hvad er en LLM, og hvordan virker den?

En LLM (Large Language Model) er en stor sprogmodel, der er trænet til at forudsige og generere tekst ved at arbejde med tokens og sandsynlige næste ord. Modellen “forstår” ikke tekst som et menneske; den beregner sandsynligheder ud fra mønstre og kontekst i de data, den er trænet på.

Under motorhjelmen kan du tænke en LLM som en avanceret token-maskine med transformer-arkitektur:

Fra input til output: mini-pipelinen

I grove træk ser flowet sådan ud:

• 1. Input: Du sender tekst, fx en prompt, en chat-historik eller kode.
• 2. Tokenisering: Teksten deles i tokens (små tekststykker, typisk orddele eller tegnsekvenser).
• 3. Embeddings: Hvert token bliver til en vektor (en liste tal), som repræsenterer tokenets “betydning” i et matematisk rum.
• 4. Transformer-lag med self-attention: Modellen beregner, hvordan hvert token relaterer sig til de andre i konteksten, og opdaterer repræsentationerne lag for lag.
• 5. Logits: Til sidst producerer modellen et sæt rå scores (logits) for, hvilket næste token der er mest sandsynligt.
• 6. Sampling: Systemet vælger næste token baseret på logits og en samplingsstrategi (fx temperature, top-p).
• 7. Output: Modellen gentager trin 4-6 token for token, indtil svaret er færdigt.

Det hele sker indenfor et context window: et maksimum antal tokens, modellen kan se på én gang (fx nogle tusinde op til hundredtusinder tokens i nyere modeller). Alt udenfor vinduet findes ikke for modellen i den enkelte forespørgsel.

Vigtige begreber for udviklere

• Tokens: Den enhed du typisk bliver faktureret på ved API-baserede modeller. En sætning kan være alt fra få til mange tokens afhængigt af sproget.
• Embeddings: Talsrepræsentationer af tekst, som du også kan bruge selv, fx med en vector database i en RAG-løsning.
• Self-attention: Mekanismen der gør, at modellen kan vægte forskellige dele af teksten forskelligt. Fx vægter “ikke” højt i “jeg er ikke tilfreds”.
• Logits og sampling: Logits er de rå scores; sampling (temperature, top-p osv.) styrer hvor kreative eller konservative svar du får.
• Context window: Sætter hård grænse for, hvor meget historik, dokumenter og kode du kan have med i én forespørgsel.

Når du for eksempel laver prompt-baseret udvikling eller bruger ChatGPT i dit workflow, arbejder du i praksis med at forme tokens og kontekst. Det går jeg mere praktisk ind i i guiden om prompts og prompt engineering.

Hvordan fungerer træning af en AI-model?

Træning er den fase, hvor en AI-model lærer ved at justere sine parametre på baggrund af data. Det er den tunge og dyre del, hvor modellen opbygger mønstergenkendelse, som du senere bruger i inference.

Konceptuelt kan du se træning som iterativ parameteroptimering:

1. Du starter med en arkitektur (fx en bestemt transformer-størrelse) og tilfældige eller fortrænede vægte.
2. Du fodrer modellen med data (tekst, billeder osv.) og en mål-funktion, fx “forudsig næste token korrekt”.
3. Modellen laver fejl, som måles med en loss-funktion.
4. En optimeringsalgoritme (typisk en variant af gradient descent) justerer vægte og biases en lille smule i retning af mindre fejl.
5. Du gentager det her i mange passeringer over datasættet (epochs), indtil modellen er god nok eller ikke bliver bedre.

I praksis:

• Træning af store LLM’er kræver enorme datasæt og specialiseret hardware (GPU/TPU/NPU).
• Træning kan tage alt fra timer til uger, afhængigt af modelstørrelse, data og setup.
• Valg af data påvirker både kvalitet, bias og hvilke opgaver modellen senere er god til.

Pre-training, fine-tuning og continued training

• Pre-training: Grundtræningen på store generelle datasæt. Det er typisk noget kun de helt store modeludbydere gør selv.
• Fine-tuning: Ekstra træning oven på en færdig foundation model på et (mindre) specialiseret datasæt. Bruges til at tilpasse tonen, domænet eller opførsel.
• Continued training: Når du fortsætter træningen på mere data, fx nye domæner eller sprogvarianter, uden nødvendigvis at lave en hårdt kurateret fine-tuning.

Som “almindelig” udvikler vil du sjældent pre-traine din egen LLM. Din hverdag handler mere om at vælge, om du skal bruge en færdig model via API, lave fine-tuning eller kombinere en generalistmodel med dine egne data via RAG. Den beslutning vender jeg tilbage til i modelstrategi-afsnittet.

Hvad er forskellen på træning og inference?

Træning er den fase, hvor modellen lærer og justerer sine parametre. Inference er den fase, hvor modellen bruger de fastlåste parametre til at svare på nye input. For dig som udvikler er forskellen vigtig, fordi træning typisk er sjælden og dyr, mens inference står for langt størstedelen af de løbende omkostninger.

Du kan tænke det som:

• Træning: bygge og lære en model.
• Inference: kalde modellen i drift.

Sammenligning: træning vs. inference

Tallene for omkostningsfordelingen varierer fra case til case, men i mange virksomheder vil inference fylde langt det meste af AI-regningen over tid. Det er derfor optimeringer som batching, caching og kvantisering pludselig bliver meget interessante.

I praksis betyder forskellen på træning og inference, at du typisk:

• planlægger træning og fine-tuning som projekter med klare start- og sluttidspunkter
• designer inference-endpoints, som skal kunne klare spikes, rate limiting, fejl og skalering i din hverdag

De vigtigste begrænsninger ved AI-modeller

AI-modeller er stærke mønstermaskiner, men de kan hallucinere, arve bias fra data, miste kontekst og give forskellige svar på samme input. I produktion betyder det, at du altid skal supplere modellen med kontrol, evaluering og beskyttende “guardrails”.

Her er nogle af de mest praktiske begrænsninger og, endnu vigtigere, hvad du kan gøre ved dem.

Typiske failure modes og hvad du gør ved dem

Hvis du har bygget systemer, hvor folk “bare” copy-paster modelgenereret kode direkte ind i produktion, har du måske allerede mærket nogle af de her ting på den hårde måde. Jeg har skrevet mere konkret om det i artiklen stop med at copy-paste AI-kode ukritisk.

Observability og evals

For at tage begrænsningerne alvorligt i drift, skal du kunne se, hvad modellen laver. Det betyder:

• logning af input, output og vigtige parametre (modelversion, temperature osv.)
• metrics på fejltyper, latency og cost per token
• evals, hvor du tester modellen på faste sæt af opgaver over tid

Her ligner god AI-drift meget god backend-drift i øvrigt. Hvis du har styr på logging i forvejen, er du godt på vej. Hvis ikke, er guiden om logs og observability et fint sted at starte.

Hvordan vælger du den rigtige modelstrategi?

Den rigtige modelstrategi afhænger af, hvor meget kontrol, latency og datatilgang du har brug for. Groft sagt: brug API, når time-to-value og enkel integration er vigtigst; brug RAG, når du vil koble en generalistmodel til dine egne data; og vælg fine-tuning eller self-hosting, når du har skrappe krav til adfærd, kontrol eller compliance.

Der er to hovedakser i valget:

• Hvordan du tilpasser modellen: ren prompt, RAG eller fine-tuning?
• Hvordan du hoster den: cloud-API, self-hosted (on-prem eller egen cloud) eller edge?

Tilpasning: prompt vs. RAG vs. fine-tuning

I mange projekter er RAG et godt første seriøst skridt, fordi du kan bevare en stabil generalistmodel og “bare” forbedre grounding i dine data. Fine-tuning giver mere dybe ændringer, men koster mere at bygge og vedligeholde.

Deployment: API, self-hosted, cloud, on-prem og edge

Hvis du i forvejen kæmper med at vælge hosting til klassiske webapps, er det samme mønster her – bare med tungere workloads. Der er en gennemgang af hosting-trade-offs i artiklen stop med at kæmpe med hosting, som også er relevant, når inferencen skal leve stabilt.

Beslutningsmatrix: hvad peger i hvilken retning?

Som tommelfingerregel:

• Høj usikkerhed, lille team, blandet brug: Start med cloud-API og god prompt-praksis. Byg noget, folk faktisk bruger.
• Du har mange domænespecifikke dokumenter: Overvej RAG oven på en stabil generalistmodel.
• Du har meget specifikke opgaver og ensartede data: Fine-tuning kan være pengene værd.
• Meget følsomme data eller hårde compliance-krav: Kig i retning af self-hosted eller on-prem.
• Hårde latency-krav eller offline-scenarier: Edge og små modeller med kvantisering bliver relevante.

Uanset strategi skal du tænke på al den velkendte API-infrastruktur: stabil endpoints, timeouts, retries, rate limiting, caching og sikker håndtering af API-nøgler og secrets. AI-delen er “bare” en meget krævende afhængighed i det system, du allerede bygger.

Performance, latency og cost per token i praksis

Performance i AI-systemer handler især om latency, throughput og cost per token. En model kan være teknisk imponerende, men stadig være et dårligt valg, hvis den er for langsom, for dyr eller umulig at skalere under belastning.

Centrale metrics

• Latency: Tiden fra forespørgsel til første byte/fuldt svar. Brugerne mærker hver ekstra 100 ms, især i interaktive flows.
• Throughput: Hvor mange forespørgsler eller tokens du kan håndtere per tidsenhed.
• Cost per token: En praktisk måde at regne på økonomi for API-baserede modeller. Det afgør, om en feature er bæredygtig ved fx 10.000 eller 1 mio. kald.

De her ting påvirkes blandt andet af:

• Modelstørrelse: Flere parametre giver typisk bedre kvalitet, men højere latency og cost.
• Context window: Lange prompts og store bilag koster tokens og dermed penge og tid.
• Hardware: GPU/TPU/NPU og deres rå regnekraft (ofte angivet i TOPS, tera operations per second).
• Optimering: Kvantisering (lavere præcision), batching, caching og god model serving.

Hvad du konkret kan gøre

• Skær unødvendig kontekst fra: Lang prompt-historik og overdrevent mange dokumenter dræber både latency og budget.
• Cache svar, hvor det giver mening: Men husk at cachen kan lyve, som gennemgået i artiklen om caching-faldgruber.
• Batch kald: Hvis du alligevel skal lave mange lignende forespørgsler, kan batching ofte spare både tid og penge.
• Monitorér cost per token: Sæt alarmer, når forbrug eller gennemsnitlige tokens per kald stikker af.
• Brug passende modeller til opgaven: En mindre model kan være helt fin til simple klassifikationer, i stedet for at fyre en gigant-LLM af hver gang.

Alt det her hænger sammen med klassisk API-robusthed. Hvis du savner en praktisk gennemgang af at bygge et endpoint, der ikke vælter ved første request, er guiden om et lille Express API et godt teknisk sidestep.

Juridiske og dataetiske risici du skal kende

Når du træner, finetuner eller fodrer en model med dine egne data, skal du altid tænke i datakilder, licenser, personoplysninger og dokumentation. Compliance er ikke noget, du kan tape udenpå til sidst; det skal med i designet.

Nogle nøglepunkter:

• Ophavsret og licenser: Må du overhovedet træne eller indekserer det datasæt, du bruger? Gælder der licensbegrænsninger?
• Personoplysninger: Indeholder dine trænings- eller RAG-data persondata, og hvordan håndterer du GDPR (samtykke, formål, sletning osv.)?
• Anonymisering/pseudonymisering: Kan du fjerne direkte identifikatorer, før data rammer modellen?
• Dokumentation: Kan du forklare, hvilke datakilder modellen bygger på, hvis nogen spørger senere?

Det her er et felt, hvor lovgivning (fx GDPR og den kommende EU AI Act) udvikler sig løbende. Som udvikler behøver du ikke være jurist, men du gør dig selv en tjeneste ved at designe systemet, så det er nemt at vise, hvor data kommer fra, og hvad modellen faktisk får lov at se.

Næste skridt: Fra forståelse til praksis

Hvis vi samler det hele, arbejder du groft sagt med denne kæde, når du bygger AI ind i et system:

• vælge og forstå modellen (LLM eller anden arkitektur)
• beslutte tilpasningsstrategi (prompt, RAG, fine-tuning)
• vælge deployment-model (API, self-hosted, on-prem, edge)
• designe for performance, latency og cost per token
• håndtere begrænsninger og failure modes med guardrails, evals og observability
• sikre sikkerhed og compliance omkring data og secrets

Hvis du vil arbejde mere praktisk med LLM’er, er to naturlige næste skridt:

• øve dig i at skrive mere præcise prompts, fx med udgangspunkt i guiden om prompts
• bygge en lille service, hvor en model hjælper dig som medprogrammør, uden at du ender som passager i eget repo. Der er konkrete ideer og faldgruber i artiklen om AI som medprogrammør

Resten er egentlig “bare” det, du allerede kender: god softwarearkitektur, klare grænser mellem komponenter og en sund skepsis, når noget virker for magisk.