Når man bygger rigtige AI-produkter i 2026, spørger man ikke længere: “Skal jeg bruge OpenAI eller Anthropic?” Den ramme er to år forældet. I træffer snesevis af beslutninger på tværs af en lagdelt stack, og de fleste betyder noget.
Denne artikel giver en praktiserende arkitekts blik på LLM-stacken i 2026 — indholdet i hvert lag, de afvejninger I foretager, og feltets retning. Det er den artikel, vi selv ville have ønsket, før vi begik alle de fejl, der kunne have været undgået.
Lagene
Stacken ser omtrent sådan ud:
┌────────────────────────────────────┐
│ Application Layer │ Your product / agent / workflow
├────────────────────────────────────┤
│ Orchestration / Frameworks │ LangGraph, CrewAI, custom, direct
├────────────────────────────────────┤
│ Prompt + Context Management │ Prompt templates, context engineering
├────────────────────────────────────┤
│ Retrieval / Memory │ RAG, vector stores, structured memory
├────────────────────────────────────┤
│ Tool / MCP Layer │ Tool calling, MCP servers, function APIs
├────────────────────────────────────┤
│ Model Layer │ Specific model selection, routing
├────────────────────────────────────┤
│ Inference Layer │ Hosted APIs, self-hosted, edge
├────────────────────────────────────┤
│ Observability / Evals │ Logging, tracing, eval suites
└────────────────────────────────────┘
Hvert lag har flere brugbare muligheder. Valget i ét lag begrænser mulighederne i andre. Tidlige beslutninger hænger ved — modelvalget påvirker inferensvalget, som påvirker orkestreringen.
Vi gennemgår hvert lag.
Lag 1: Modellaget
I 2026 grupperer modellerne sig i omtrentlige niveauer. Valget mellem dem er systemets vigtigste beslutning for hvert kald.
Flagskibsmodeller til ræsonnement. Tænketilstandene i de aktuelle flagskibe — GPT-5.5 med reasoning, Claude Opus 4.8 med adaptive thinking og Gemini 3.1 Pro thinking — samt dedikerede ræsonnementsmodeller som DeepSeek R1. Fremragende til flertrinsproblemer, matematik, kode og kompleks analyse. Dyre ($3-30 pr. million inputtokens, væsentligt mere for output) og langsommere (5-60 sekunder). Brug dem, når kvaliteten af ræsonnementet er flaskehalsen.
Generelle flagskibsmodeller. GPT-5.5, Claude Sonnet 5, og Gemini 3.1 Pro. Fremragende til det meste vidensarbejde, hurtige (2-5 sekunder) og moderat dyre ($2-5 pr. million inputtokens). Standardvalget til brugervendte svar af høj kvalitet.
Mellemklassemodeller. Claude Haiku 4.5, Gemini 3.5 Flash og OpenAI’s mellemklasse. Gode til enkle og moderat krævende opgaver, hurtige (1-2 sekunder) og billige ($1-2.50 pr. million inputtokens). Bruges intensivt i produktion til klassifikation, udtræk og enkel generering.
Små/billige modeller. Udbydernes mindste aktuelle niveauer, f.eks. Gemini 3 Flash Preview, og små open source-modeller. Tilstrækkelige til smalle, strukturerede opgaver. Meget billige ($0.50-1 pr. million inputtokens) og meget hurtige (<1 sekund). Brug dem til routing, scoring og batchbehandling.
(Listepriser kontrolleret 2026-07-07 på udbydernes prissider; niveauerne ændrer sig — kontrollér igen, før I citerer dem.)
Specialiserede modeller. Modeller til embeddings, reranking, billeder, tale og kode. De er billigere end generelle modeller til deres konkrete opgave og som regel bedre. Overvej dem altid til den relevante opgave.
Open source-fronten. Llama 4, DeepSeek V3/R2, Qwen 3, og Mistral Large. De hostes hos inferensudbydere som Groq, Together og Fireworks eller hos jer selv. Pris og kvalitet konkurrerer med lukkede frontmodeller til mange opgaver, men halter på nogle områder, især langvarigt ræsonnement.
Konsekvenserne er:
- Én model passer ikke til alle kald i systemet. Routing er nødvendigt af hensyn til omkostningerne (se Lag 1).
- Fronten flytter sig hvert kvartal. Byg til modelskift, ikke fastlåsning.
- Open source er nu reelt anvendeligt til mange produktionsformål, ikke kun forsøg.
Lag 2: Inferenslaget
Hvor kører modellen faktisk?
Lukkede API-udbydere — OpenAI, Anthropic og Google. Den hurtigste vej til drift, de bedste modeller og størst pålidelighed. I betaler en merpris og accepterer deres data- og sikkerhedsmodel.
Inferensudbydere til open source — Groq, Together AI, Fireworks og Replicate. De kører åbne modeller med forskellige optimeringer. Ofte langt hurtigere end egen hosting og med konkurrencedygtige priser. (Markedet konsolideres hurtigt — flere udbydere fra 2024 findes ikke længere; kontrollér enhver leverandør før binding.)
Cloud-native — AWS Bedrock, Azure OpenAI og Google Vertex. Indpakker lukkede og åbne modeller i jeres clouds autentificering, fakturering og compliance. Nødvendigt i mange virksomhedsmiljøer.
Egen hosting — vLLM, TGI, SGLang og LMDeploy på egne GPU’er. Laveste pris pr. token ved stor skala, men størst driftskompleksitet. Normalt først relevant, når inferensudgiften ligger højt i det encifrede antal tusinde euro om måneden; se break-even-beregningen i artiklen om egen kontra ekstern hosting.
Edge/på enheden — Apple Intelligence, MediaPipe, ONNX og GGUF-modeller via Ollama eller llama.cpp. Gratis pr. kald, men med begrænset modelkapacitet. Stadig mere anvendeligt til smalle opgaver.
Afvejningerne:
- Svartid betyder noget: Taleagenter og samtale-UX kræver hurtig første token. Groq, Cerebras og kørsel på enheden fører her.
- Gennemløb betyder noget ved batch: Millioner af poster kræver højt gennemløb, ikke lav svartid.
- Compliance betyder noget: GDPR, HIPAA og SOC 2 afgør ofte, hvilke udbydere og regioner I kan bruge.
- Leverandørrisiko betyder noget: Én udbyder er et enkelt fejlpunkt. Flere udbydere er god praksis.
Et almindeligt mønster i 2026 er hostede lukkede modeller til brugervendte krav om højeste kvalitet, hostet open source til billigt arbejde i stor mængde og kørsel på enheden til smalle, svartidsfølsomme funktioner. Host kun selv, når skala og økonomi opvejer driftsbyrden.
Lag 3: Værktøjer og MCP
LLM’er kan ikke meget alene. De bliver nyttige, når de kan kalde funktioner, der giver adgang til data, API’er og handlinger.
Indbygget funktionskald. Alle større modeller understøtter et struktureret API til funktionskald. I definerer funktioner med JSON-skemaer; modellen vælger kaldet; I udfører det og returnerer resultatet.
MCP (Model Context Protocol). En standardiseret protokol, introduceret af Anthropic og nu bredt anvendt af blandt andre OpenAI og Cursor, til værktøjsservere. En MCP-server eksponerer værktøjer; en MCP-klient, f.eks. en LLM-agent, forbinder og bruger dem. Det adskiller værktøjsimplementeringen fra den enkelte model.
Direkte integrationer. Til specifikke anvendelser med stor volumen, f.eks. et bestemt CRM-system eller en database, er en direkte adapter ofte lettere end en generisk MCP-server.
Tendensen i 2026 er tydelig: MCP vinder som standard. Ny værktøjsudvikling bør som udgangspunkt målrette MCP. Direkte integrationer er fortsat nyttige på ydelseskritiske stier.
Nogle praktiske realiteter:
- Værktøjsbeskrivelser er afgørende. Et dårligt beskrevet værktøj bliver brugt forkert. Skriv docstrings som prompts.
- Antallet af værktøjer betyder noget. Modeller med 50+ tilgængelige værktøjer klarer sig dårligere end modeller med 5-10 relevante værktøjer. Kuratér hårdt.
- Fejlhåndtering betyder noget. Værktøjsfejl skal formidles struktureret, så modellen kan tilpasse sig.
- Autorisation er vanskelig. Et flerbrugersystem med forskellige tilladelser er ikke trivielt. Lad ikke LLM’en træffe autorisationsbeslutninger; gør det i wrapperen omkring værktøjet.
Lag 4: Hentning og hukommelse
LLM’er har brug for data, de ikke er trænet på. Det er hentningslaget.
Vektordatabaser. Pinecone, Weaviate, Qdrant, Chroma, PostgreSQL med pgvector og Turbopuffer. Gemmer embeddings og leverer nearest-neighbor-forespørgsler. Modent og velkendt; standarden for semantisk hentning.
Hybridsøgning. Kombinerer vektorsøgning med traditionel BM25-søgeordssøgning og fanger både semantiske og leksikalske match. Brug Reciprocal Rank Fusion til kombinationen. Værktøjer: Elasticsearch, OpenSearch og Vespa.
Vidensgrafer. Neo4j, Memgraph og specialbyggede triple stores. Til data med rige relationer. Bruges i graph-RAG-arkitekturer. Mere arbejde, men ofte højere kvalitet i relationsrige domæner.
Specialiserede RAG-platforme. LlamaIndex, som nu er modent, LangChains RAG-abstraktioner og Haystack. Rammeværk på højere niveau til almindelige mønstre.
Reranking. Cohere Rerank, Voyage og specialbyggede cross-encoders. Efter første hentning rangeres de bedste kandidater igen med en dyrere model. Forbedrer som regel hentningskvaliteten 2-3x.
Hukommelse. Til agenter og samtaler: strukturerede hukommelseslag som Mem0, Letta, tidligere MemGPT, eller egne løsninger. Skeln mellem kort sigt (aktuel samtale), mellemlang sigt (seneste emner) og lang sigt (varige fakta om bruger eller konto).
Det arkitektoniske spørgsmål er, hvor laget skal ligge:
- I applikationen: LLM-kaldet indpakkes i hentningslogik skrevet af jeres team.
- I MCP-laget: Hentning eksponeres som værktøjer.
- Som en tjeneste: En dedikeret hentningstjeneste, som applikationerne kalder.
I monolitiske systemer med ét produkt er applikationen fin. I organisationer med flere produkter betaler det sig at behandle hentning som en tjeneste med ensartet kvalitet og politik.
Lag 5: Prompt- og kontekstdesign
Når vi når 2026, er “prompt engineering” stort set blevet synonymt med “context engineering” — styring af det, der kommer i kontekstvinduet ved hvert kald.
Komponenterne:
Prompts. Ofte skabeloner med variabler. Gemmes i versionsstyring, testes med evalueringssuiter og behandles som kode.
Promptstyring. Værktøjer som Promptfoo, Langfuse og PromptLayer eller interne systemer. Versionsstyring, A/B-test og tilbagerulning. (Helicone og lignende LLM-proxyer hører til observerbarhedslaget nedenfor, ikke her — kategorierne blandes let sammen.)
Kontekststrategi. Beslutninger om indholdet i hvert kald:
- Systemprompten, som er stabil og definerer adfærd.
- Hentet viden, som er dynamisk og kommer fra RAG.
- Samtalehistorik, som styres og ofte opsummeres, når den bliver lang.
- Few-shot-eksempler, som vælges dynamisk ud fra forespørgslen.
- Værktøjsbeskrivelser, filtreret til kun relevante værktøjer.
- Brugerens aktuelle forespørgsel.
Kontekstkomprimering. Når konteksten bliver lang, forringes modellen. Opsummér ældre beskeder, udtræk nøglefakta til struktureret hukommelse, og fjern irrelevant indhold. Det er et aktivt forskningsområde.
Brug af lang kontekst. Vinduer med 1M tokens er standard i aktuelle flagskibe som Claude, GPT-5.5, og Gemini. De virker, men “context rot” er reelt — kvaliteten falder på lange input, selv når modellen teknisk understøtter dem. Brug lang kontekst med omtanke; indsæt ikke alt, blot fordi I kan.
Lag 6: Orkestrering
Hvordan koordinerer I flertrinsarbejdsgange og agenter?
Direkte API. Skriv selv løkken i Python eller TypeScript. Bedst til enkle tilfælde og til at forstå, hvad der faktisk sker.
LangChain/LangGraph. Bredt anvendt. LangGraph, en tilstandsmaskine til agenter, er blevet væsentligt mere modent. Tunge abstraktioner og en læringskurve, men stor styrke.
CrewAI. Multi-agent-rammeværk med fokus på rollebaserede agenter. Lettere at begynde med end LangGraph, men mindre fleksibelt.
LlamaIndex-agenter. Særligt stærke til RAG-tunge arbejdsgange.
OpenAI Agents SDK. Enklere, mere holdningspræget og optimeret til OpenAI-modeller.
Anthropic Claude SDK. Tilsvarende, men optimeret til Claude.
Specialbygget. Modne teams med produktionsagenter vælger ofte egen orkestrering. Rammeværk pålægger en pris i abstraktion, fejlsøgning og versionsændringer, som kan overstige gevinsten.
Et mønster i 2026 er at bygge prototypen i et rammeværk og omskrive den til egen kode til produktion. Rammeværket hjælper jer med at opdage mønstrene; når de er kendt, er direkte kode enklere og mere pålidelig.
Lag 7: Observerbarhed
Seriøse LLM-applikationer kræver observerbarhed. Alle produktionssystemer har brug for:
Tracing. Registrér hvert LLM-kald: tidsstempel, model, input, output, svartid, pris og succes eller fejl. Brug træer til flertrinsspor.
Omkostningssporing. Pr. kald, funktion og bruger. Udgifterne er store og uden naturligt loft; uden sporing opdager I dem først ved månedens udgang.
Kvalitetsovervågning. Automatiske kvalitetstjek af en stikprøve af produktionstrafikken. Alarmer ved kvalitetsfald.
Registrering af brugerfeedback. Tommel op/ned, eksplicit feedback og indirekte signaler som gentagelsesfrekvens og afbrydelser.
Fejlsøgning. Når noget går galt, skal hele kaldskæden være synlig. En fejlet agentkørsel har mange mulige fejlpunkter.
Værktøjer: LangSmith, Helicone, Arize, Phoenix, Braintrust, Weights & Biases og Datadog LLM Observability. De har forskellige styrker; vælg ét tidligt, og hold fast.
Til små teams giver selv en enkel Postgres-tabel med én række pr. LLM-kald 80% af det nødvendige. Skift til et værktøj, når skala eller funktionskrav berettiger det.
Lag 8: Evalueringer
Det vigtigste lag i seriøs produktion.
Offlineevalueringer. Et defineret datasæt, forventede output og scoring. Køres før ændringer udrulles og opdager regressioner. Det er behandlet grundigt på mellemniveauet.
Onlineevalueringer. En stikprøve af produktionstrafikken scores automatisk med en LLM som dommer eller via brugersignaler. Opdager drift.
Evalueringer før udrulning. Før en prompt- eller modelændring går i produktion, køres og gennemgås evalueringssuiten. Den bliver en del af CI.
Evalueringstaksonomi. Forskellige evalueringer til forskellige formål:
- Adfærd: Gør systemet det forventede?
- Sikkerhed: Afviser det det, vi ønsker afvist?
- Kvalitet: Hvor godt er outputtet?
- Robusthed: Hvordan håndterer det fjendtlige input?
- Pris/svartid: Holder vi budgettet?
Værktøjer: Promptfoo, Braintrust, LangSmith og egne suiter. De har alle en plads; Promptfoo er lettest at begynde med.
Lag 9: Applikationslaget
Her bor jeres konkrete produkt. Beslutningerne:
Agent kontra arbejdsgang. Agenter, altså en LLM i en løkke med værktøjer, er kraftfulde, men sværere at gøre pålidelige. Arbejdsgange med en fast sekvens af LLM-kald er lettere og ofte tilstrækkelige. Vælg arbejdsgange som standard; brug kun agenter, når fleksibiliteten reelt er nødvendig.
Synkron kontra asynkron. Brugervendt i realtid, batch i baggrunden eller streaming? Det påvirker model, infrastruktur og UX.
Enkeltkunde kontra flerbruger. Krav om isolation af kundedata driver væsentlige arkitekturbeslutninger.
Lokalt kontra cloud. Compliance, sikkerhed eller pris kan kræve lokal drift. Driftskompleksiteten er langt større.
Grænsetilfælde. Hallucinationer, promptinjektion og misbrug. Produktionssystemer kræver værn. Udgiv ikke uden dem.
De vigtige afvejninger
Nogle afvejninger bør være eksplicitte:
Kvalitet kontra pris kontra svartid
Den grundlæggende trekant. I kan normalt optimere to; den tredje bliver dårligere.
- Høj kvalitet + lav svartid = dyrt.
- Lav pris + lav svartid = lavere kvalitet.
- Høj kvalitet + lav pris = høj svartid, f.eks. batchbehandling eller ræsonnementsmodeller.
Vælg prioriteringer pr. opgave. Forsøg ikke at optimere alle tre; det giver middelmådighed i alle.
Byg kontra køb
Hvert lag kan bygges eller købes.
- Byg: mere kontrol, mere vedligeholdelse, højere omkostning i ingeniørtid og differentierende egenskaber.
- Køb: hurtigere start, mindre kontrol, løbende leverandørrisiko og udlicitering af generiske egenskaber.
En god tommelfingerregel er at købe standardlagene som vektorlagring og grundlæggende observerbarhed og bygge de differentierende lag som jeres orkestrering, prompts og evalueringer. Det modsatte er en almindelig fejl.
Open source kontra lukket
Virkeligheden i 2026 er, at open source-modeller konkurrerer på mange opgaver. Til nogle er de bedre, hurtigere eller billigere; ved langvarigt ræsonnement fører de lukkede frontmodeller stadig.
Beslutningsfaktorerne:
- Kvalitetskrav. Ved den absolutte front vinder lukkede modeller stadig.
- Pris i stor skala. Open source med egen hosting bliver billigt ved stor volumen.
- Databeskyttelse/compliance. Egen hosting i egen infrastruktur kræves ofte til følsomme data.
- Tilpasning. Finjustering og specialtræning kræver open source.
- Driftskapacitet. Lukkede API’er er driftsmæssigt enkle; egen hosting kræver betydeligt arbejde.
De fleste produktionssystemer i 2026 er hybride — lukkede modeller til nogle kald og åbne til andre, valgt pr. kald.
Svartid kontra ræsonnementsdybde
Ræsonnementsniveauer som GPT-5.5 thinking og Claude med adaptive thinking bytter svartid for kvalitet på svære problemer. Nogle gange er det værdifuldt; andre gange kan brugeren ikke vente 30 sekunder.
Et mønster er at sende enkle forespørgsler til hurtige modeller og svære til ræsonnementsmodeller. Lad en router, en lille model eller heuristik, vælge.
Lang kontekst kontra RAG
I kan lægge konteksten direkte i modellen med et vindue på en million tokens eller hente relevante bidder med RAG.
- Lang kontekst: enklere og uden hentningsinfrastruktur, men dyr pr. kald og udsat for “context rot”.
- RAG: billigere pr. kald og mere opsætning; hentningskvalitet er sit eget tekniske problem.
Det modne svar i 2026 er normalt RAG i produktion og lang kontekst til prototyper, særlige engangsopgaver eller tilfælde, hvor dårlig hentning ødelægger resultatet.
Agenter kontra arbejdsgange
Som ovenfor: Vælg arbejdsgange som standard, og brug agenter, når fleksibiliteten reelt er nødvendig. Mange “agentsystemer” burde være arbejdsgange.
En referencearkitektur for 2026
Et typisk produktionssystem til et mellemstort SaaS-produkt med AI-funktioner:
User → Application (React/Next.js)
↓
API gateway / auth
↓
LLM Service (your wrapper)
↓
Router (small model or heuristic)
├→ Simple tasks: a mid-tier model (Claude Haiku 4.5 class)
├→ Standard tasks: Claude Sonnet 5 or GPT-5.5
├→ Hard tasks: Claude Opus 4.8 or a reasoning tier
└→ Special: vision/voice/embedding specialists
↓
Tool layer (MCP servers + direct integrations)
↓
Retrieval layer (Pinecone + hybrid + reranker)
↓
Observability (Helicone or LangSmith)
↓
Eval suite (Promptfoo, runs in CI)
Pris pr. aktiv bruger om måneden: typisk €1-10 afhængigt af brugsintensitet. Udviklingsindsats: 6-12 uger for et erfarent team. Driftsomkostning: lav til moderat afhængigt af trafik.
Det, der ofte går galt
Tilbagevendende fejlmønstre:
Mønster 1: Én model til alt. Overforbrug og kvalitetsproblemer. Løsning: routing.
Mønster 2: Ingen observerbarhed. Kan ikke fejlsøge, måle eller forbedre. Løsning: instrumentér tidligt.
Mønster 3: Ingen evalueringer. Kvaliteten driver ubemærket. Løsning: evalueringer fra første dag.
Mønster 4: Fastlåsning til rammeværk. Fejlsøgning i LangChain eller CrewAI bliver et fuldtidsjob. Løsning: Brug kun rammeværk, når de sparer mere, end de koster. Omskriv til direkte kode, når mønstrene er klare.
Mønster 5: Bygning af infrastruktur, der burde købes. En egen vektordatabase eller observerbarhedsløsning er sandsynligvis spildtid. Køb standardlagene.
Mønster 6: Køb af infrastruktur, der burde bygges. Udlicitering af jeres prompts eller evalueringer. De er jeres konkurrencefordel; ej dem.
Mønster 7: Ignorering af promptinjektion. Et produktionssystem uden rensning af brugerleveret indhold indebærer stor risiko. Afbød den tidligt.
Mønster 8: Tillid til agenter i forløb med store konsekvenser. En LangGraph-agent, der godkender refunderinger uden menneskelig kontrol, vil til sidst fejle. Tilføj human-in-the-loop ved væsentlige handlinger.
Mønster 9: Optimering af det forkerte. Optimering af inferensprisen, når ingeniørtid dominerer totalprisen, eller af svartid, som brugerne ikke bemærker. Mål det, der faktisk betyder noget.
Mønster 10: Ingen plan for flere udbydere. Når, ikke hvis, hovedudbyderen har nedetid, er I nede. Konfigurér en reserve.
Tre daterede væddemål (kontrollér igen midt i 2027)
Forudsigelser er billige; daterede og falsificerbare forudsigelser er det ikke. Her er tre, vi offentligt accepterer at tage fejl om:
-
EU-hostet inferens når praktisk prisparitet for mellemklassemodeller midt i 2027. Suveræn EU-kapacitet kommer hurtigt online, og merprisen over endpoints i USA er faldet. Ved paritet skifter vores standardanbefaling til GDPR-følsomme arbejdsgange fra “hybrid med redigering” til “EU-hostet som standard”. Konfidens: moderat.
-
Rammeværkslaget konsolideres fortsat; protokollaget vinder fortsat. I de seneste 18 måneder har Microsoft samlet sine to agentrammeværk, og OpenAI har ført sit selvstændige browseragentprodukt tilbage i ChatGPT, mens MCP er gået fra annoncering til standard på tværs af udbydere. Vi lægger integrationsarbejdet i protokoller som MCP og strukturerede output og holder orkestreringsrammeværket udskifteligt. Konfidens: høj.
-
Routing med små modeller går fra optimering til standardarkitektur. Hvis flagskibspriserne består, mens små niveauer forbedres, vil “flagskib til alt” lyde som “bare metal til alt” for en cloudingeniør. Konfidens: høj for prisfølsomme SMV’er.
Det, vi bevidst ikke forudsiger, er modelrangeringer. Enhver konkret rangering her ville være forældet før sidens næste gennemgang.
Få arkitekturen på plads
LLM-stacken i 2026 er reel og lagdelt, og valgene betyder noget. De teams, der lykkes:
- Forstår hele stacken, ikke kun egne dele.
- Foretager eksplicitte afvejninger mellem kvalitet, pris og svartid pr. kald.
- Bygger det differentierende og køber resten.
- Instrumenterer fra første dag med observerbarhed og evalueringer.
- Bevarer fleksibilitet på tværs af modeller og udbydere.
De teams, der mislykkes, har valgt én leverandør, hardkodet dens API, aldrig instrumenteret eller målt og står nu med et dyrt, skrøbeligt system, der er umuligt at forbedre.
Få arkitekturen på plads. Alt andet bliver lettere.
