Den dyreste enkeltfejl, vi ser i AI-systemer i produktion, er at bruge én model til alt.
Et team vælger én førende model, f.eks. GPT-5.5, Claude Opus 4.8, eller en tilsvarende model. De bygger deres app omkring den og ender med månedlige regninger på femcifrede beløb. Routing af forskellige forespørgsler til forskellige modelniveauer reducerer typisk en stor del af regningen — i det modellerede eksempel nedenfor omkring 70-75% — og forbedrer ofte latenstiden samtidig.
Det er orkestrering af flere modeller: at bruge den rette model til hver opgave i et system. Det er forskellen mellem AI som hobby og AI i produktion.
Artiklen gennemgår mønstrene, routinglogikken, afvejningerne og en trinvis guide til implementering.
Hvorfor én model ikke er optimal
Modeludbuddet i 2026 kan groft inddeles i niveauer:
Førende ræsonneringsniveauer (tænketilstandene i GPT-5.5, Claude Opus 4.8, Gemini 3.1 Pro samt DeepSeek R1): fremragende til kompleks ræsonnering, dyre ($3-30 pr. million inputtokens og $15-50 output for almindelige førende modeller; særlige pro-niveauer er langt dyrere) og langsommere (typisk 5-30 sekunder).
Førende generelle modeller (GPT-5.5, Claude Sonnet 5, Gemini 3.1 Pro): fremragende til det meste vidensarbejde, moderat dyre ($2-5 pr. million inputtokens og $12-30 pr. million outputtokens) og rimeligt hurtige (2-5 sekunder).
Mellemniveaumodeller (Claude Haiku 4.5, Gemini 3.5 Flash, OpenAI’s mellemniveau): gode til enkle og moderat komplekse opgaver, billige ($1-2.50 pr. million inputtokens og $5-15 pr. million outputtokens) og hurtige (1-2 sekunder).
Små modeller (udbydernes mindste aktuelle niveauer, f.eks. Gemini 3 Flash Preview, samt små open source-modeller): gode til enkle strukturerede opgaver, meget billige ($0.50-1 pr. million inputtokens) og meget hurtige (<1 sekund).
Specialiserede modeller (embedding-, reranking-, visions- og stemmemodeller): optimeret til bestemte opgaver og ofte meget billige, fordi de har et snævert fokus.
(Listepriserne blev kontrolleret 2026-07-07 på udbydernes prissider; kontrollér dem igen, før de citeres.)
En typisk AI-app foretager mange forskellige typer LLM-kald. Hvert kald har sine egne krav:
- Klassificering af brugerens hensigt kræver enkel klassificering og hurtigt svar. En mellemniveaumodel er ideel.
- Udtræk af strukturerede data fra dokumenter kræver pålideligt struktureret output og moderat kompleksitet. Brug mellemniveauet eller en førende generel model.
- Det egentlige svar på en brugerforespørgsel kræver kvalitet og god konteksthåndtering. Brug en førende generel model eller ræsonneringsmodel.
- Opsummering af tidligere samtaler er enkel opsummering. Brug en mellemstor eller lille model.
- Batchbehandling i baggrunden er ikke følsom over for latenstid, men mængden har betydning. Brug en lille model eller en mellemniveaumodel.
Det er spild at bruge en førende model til alle opgaverne. Klassificering, opsummering og ofte struktureret udtræk kræver den ikke. Kun det brugervendte svar får reelt gavn af den.
Omkostningsbesparelserne er reelle
En typisk AI-app til vidensarbejde kan have denne fordeling af forespørgsler:
- 60% af LLM-kaldene: enkel klassificering, udtræk og opsummering. Håndteres bedst af små modeller eller mellemniveaumodeller.
- 30% af kaldene: moderat kompleksitet. Håndteres af mellemniveauet eller en førende generel model.
- 10% af kaldene: kompleks ræsonnering eller det endelige brugersvar. Håndteres af en førende model.
Hvis en førende model bruges til alt, er omkostningen 100% af prisen for dette niveau. Med passende routing bliver fordelingen:
- 60% til prisen for en lille model (1 ud af tredive dele af prisen for en førende model): 2% af den oprindelige omkostning.
- 30% til prisen for en mellemniveaumodel (1 ud af fem dele af prisen for en førende model): 6% af den oprindelige omkostning.
- 10% til prisen for en førende model: 10% af den oprindelige omkostning.
I alt: 18% af den oprindelige omkostning. Det er en reduktion på 82% i alt. På en regning på €10,000/month sparer det €8,200/month.
Tallene afhænger af din trafikprofil, men mønsteret er stabilt: De fleste apps har en blanding af forespørgsler, hvor det gennemsnitlige kald er langt billigere end det dyreste kald. Routing udnytter forskellen.
De grundlæggende orkestreringsmønstre
Nogle mønstre går igen i systemer med flere modeller i produktion:
Mønster 1: Opgavebaseret routing
Forskellige opgavetyper sendes til forskellige modeller. Det er det enkleste mønster.
# Model IDs verified 2026-07-07; SMALL_TIER is your provider's current
# small model — check the live model list rather than hard-coding blindly.
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return "claude-haiku-4-5"
elif task_type == "summarization":
return "claude-haiku-4-5"
elif task_type == "user-facing-response":
return "claude-sonnet-5"
elif task_type == "complex-reasoning":
return "claude-opus-4-8"
Opgaverne klassificeres af den kaldende kode, som ved, hvad den beder om. Routingen er deterministisk og nem at fejlfinde.
Mønster 2: Kompleksitetsbaseret routing
Systemet estimerer kompleksiteten af hver forespørgsel og sender den videre ud fra resultatet.
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"
Kompleksitetsestimatet kan være heuristisk, f.eks. baseret på forespørgslens længde eller registrering af nøgleord, eller modelbaseret, hvor en billig klassifikationsmodel scorer forespørgslen. Mønstret håndterer tilfælde, hvor samme opgavetype varierer i sværhedsgrad.
Mønster 3: Kaskaderouting
Prøv først en billig model. Brug svaret, hvis det er godt; eskalér ellers til en dyrere model.
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)
Det virker, når »acceptabelt« kan registreres ved hjælp af sikkerhedsscorer, validatorer eller en separat LLM til kvalitetskontrol. Mønstret er effektivt: De fleste enkle forespørgsler besvares af den billige model, og kun de svære når den dyre.
Mønster 4: Specialiseret routing
Brug specialiserede modeller til specialiserede opgaver:
- Embeddings: Brug en særskilt embeddingmodel, som er langt billigere end at bruge en chatmodel til embeddings.
- Reranking: Brug en særskilt reranker.
- Vision: Brug en visionsspecialiseret model til billedanalyse.
- Stemme: Brug en stemmemodel til transskription og syntese.
- Kode: Brug en kodespecialiseret model til kodeopgaver.
Specialiserede modeller er som regel hurtigere, billigere og bedre til deres særlige opgave end en generel model, der forsøger at løse den samme opgave.
Mønster 5: Routing mellem udbydere
Brug modeller fra flere udbydere for redundans og bedre forhandlingskraft på priser.
providers = ["openai", "anthropic", "google"]
preferred = "anthropic" # primary
fallback = "openai" # fallback
def call_with_failover(request):
try:
return call(preferred, request)
except (RateLimit, ProviderError):
return call(fallback, request)
Det giver robusthed ved nedbrud og rate limits hos en enkelt udbyder. Det lader dig også udnytte prisændringer: Når en udbyder sænker priserne, kan mere trafik flyttes dertil.
Et realistisk eksempel: AI til kundesupport
Her er et konkret eksempel på, hvordan en AI-løsning til kundesupport kan bruge flere modeller.
Systemet har følgende trin for hver henvendelse:
Trin 1: Klassificér hensigten. Hvad spørger kunden om? (5-10 kategorier.)
Routing: En lille model. Det er en enkel klassifikationsopgave. Omkostning: ~$0.0005 pr. henvendelse (≈500 tokens til priserne for en lille model).
Trin 2: Vurdér hast og stemning. Er kunden frustreret? Haster sagen?
Routing: Den samme lille model. Endnu en enkel klassifikation. Omkostning: ~$0.0005 pr. henvendelse.
Trin 3: Hent relevant viden.
Routing: Embeddingmodel + rerankingmodel. Specialværktøjer til specialopgaver. Omkostning: ~$0.002 pr. henvendelse (reranking udgør størstedelen ved ~$2 pr. 1,000 søgninger).
Trin 4: Afgør, om AI’en kan svare, eller om sagen skal eskaleres til et menneske.
Routing: Claude Haiku 4.5. En lidt mere avanceret klassifikation ud fra den hentede kontekst. Omkostning: ~$0.002 pr. henvendelse (≈2K konteksttokens).
Trin 5 (hvis AI’en kan svare): Udarbejd det brugervendte svar.
Routing: Claude Sonnet 5. Kvaliteten er vigtig her, fordi kunden læser svaret. Omkostning: ~$0.015 pr. henvendelse (≈3K ind/400 ud).
Trin 6 (hvis AI’en ikke kan svare): Udarbejd et resumé til den menneskelige medarbejder.
Routing: En mellemniveaumodel. Et nyttigt resumé, som ikke er kundevendt. Omkostning: ~$0.004 pr. henvendelse.
Trin 7: Kvalitetskontrol. Opfylder svaret vores krav?
Routing: Claude Haiku 4.5 som hurtig evaluator. Omkostning: ~$0.002 pr. henvendelse.
Det er modellerede tal — de antagne tokenmængder vises for hvert trin, så du kan genberegne dem med din egen trafik.
For henvendelser, som AI’en besvarer (f.eks. 70%): ~$0.022 pr. henvendelse. For henvendelser, der eskaleres til mennesker (30%): ~$0.009 pr. henvendelse. Vægtet gennemsnit: ~$0.018 pr. henvendelse.
Hvis hvert trin i stedet brugte et førende ræsonneringsniveau med samme tokenmængder ved ~$5/M input og $25/M output, ville omkostningen være cirka $0.06-0.08 pr. henvendelse. Tilgangen med flere modeller reducerer omkring 70-75% af regningen.
Ved 1,000 henvendelser om dagen svarer det til ~$50/day og cirka $18,000/year i besparelser. Det er væsentligt, men den største driftsmæssige fordel er som regel latenstiden: Den routede pipeline besvarer enkle henvendelser på ét sekund i stedet for tredive.
Routinglogikken
Der findes flere måder at implementere routing på:
Tilgang 1: Fast kodning efter opgavetype
Den enkleste løsning. Du ved, hvilken opgave du kalder, og vælger modellen.
def classify(text):
return openai_client.chat.completions.create(
model=SMALL_TIER, # your provider's current small model
messages=[{"role": "user", "content": f"Classify: {text}"}],
)
def respond(context, query):
return claude_client.messages.create(
model="claude-sonnet-5", # ID verified 2026-07-07
max_tokens=1024,
messages=[{"role": "user", "content": f"Context: {context}\n\nQuery: {query}"}]
)
Fordele: Gennemsigtigt, nemt at fejlfinde og nemt at ændre. Ulemper: Tilpasser sig ikke variationer i kompleksitet inden for en opgavetype.
Tilgang 2: Routermodel
En lille model klassificerer hver forespørgsel og sender den videre.
ROUTER_PROMPT = """
Classify this request as: trivial, moderate, or complex.
Output one word.
Request: {request}
"""
def route(request):
classification = small_model_call(ROUTER_PROMPT.format(request=request))
return MODEL_BY_COMPLEXITY[classification]
Fordele: Tilpasser sig kompleksiteten inden for en kategori. Ulemper: Tilføjer latenstid gennem routerkaldet, skaber endnu et fejlpunkt og kræver finjustering.
Tilgang 3: Embeddingbaseret router
Til forespørgsler, der følger kendte mønstre, kan du bruge embeddinglighed med tidligere eksempler.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
Fordele: Hurtig, fordi det blot er et vektoropslag, og bliver bedre med flere data. Ulemper: Kræver et mærket sæt eksempler.
Tilgang 4: Kaskade
Prøv først den billige løsning, og eskalér efter behov.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
Fordele: Adaptiv og med lav gennemsnitsomkostning. Ulemper: Langsom ved eskalering, fordi der foretages to kald, og kræver pålidelig validering.
I praksis bruger mange produktionssystemer en hybrid: fast routing til de primære opgavetyper og kaskader til bestemte undertyper med stor variation.
Faldgruberne
Her er nogle fejl, du bør undgå:
Faldgrube 1: Omkostningsoptimering, der forringer kvaliteten
Det er nemt at sende alt til små modeller og se omkostningen falde. Det er sværere at opdage, at kvaliteten også er faldet. Knyt altid kvalitetsmåling til ændringer i routingen.
En nyttig disciplin er at A/B-teste i en uge, når en opgave flyttes til en billigere model, og bruge kvalitetsmålinger. Udrul ikke ændringen uden dokumentation for, at kvaliteten blev bevaret.
Faldgrube 2: Overudvikling af routeren
En router, der håndterer 100 opgavetyper med avanceret logik, er sværere at vedligeholde end den routing, den erstatter. Begynd enkelt. Hvis den enkle løsning er 80% så god som den avancerede, skal du vælge den enkle.
Et almindeligt mønster er, at en router på 50 linjer, der håndterer 5-10 opgavetyper, leverer 90% af gevinsten. Derefter falder merudbyttet.
Faldgrube 3: Latenstid ignoreres
Billigere modeller er som regel også hurtigere, hvilket er positivt. Men en kaskade, der først prøver en billig model og derefter en førende model, kan fordoble latenstiden ved svære opgaver. Det har betydning i brugervendte forløb.
Et nyttigt mønster er at vælge en førende model som standard til brugervendte svar, der er følsomme over for latenstid, og acceptere omkostningen. Gem kaskaden til batcharbejde eller asynkront arbejde.
Faldgrube 4: Udbyderfejl håndteres ikke
Når du er afhængig af flere modeller, har du også flere måder at fejle på. En førende model går ned, en rate limit aktiveres, eller en API-nøgle udløber. Routinglogikken har brug for fallback.
Minimumskravet er, at hver primær model har en fallbackmodel fra en anden udbyder. Selv hvis kvaliteten falder ved fallback, forbliver systemet tilgængeligt.
Faldgrube 5: Kvaliteten måles ikke pr. route
Du skal vide, hvilken route der fungerer godt, og hvilken der ikke gør. Det kræver evaluering, helst automatisk.
En nyttig opsætning er at logge den anvendte model, forespørgslen, svaret og om muligt et kvalitetssignal for hvert produktionskald, f.eks. brugerfeedback, efterfølgende målinger eller automatisk evaluering. Saml målingerne pr. route. Opdag kvalitetsdrift, før brugerne klager.
Hvor udviklingen bevæger sig hen
Her er nogle forventede tendenser:
Automatisk routing som tjeneste. Værktøjer som OpenRouter, Helicone, Portkey og andre tilbyder i stigende grad »intelligent routing«, hvor de vælger modellen ud fra konfigurerbare regler. Funktionen forventes at blive langt mere moden.
Større specialisering pr. model. Flere modeller specialiseres i kode, matematik og bestemte fagområder. Routing vil i stigende grad omfatte specialmodeller.
Fortsat faldende omkostninger. Modeller i 2026 er 10x billigere end tilsvarende kvalitet i 2024. Når vi når 2028, kan du forvente endnu en reduktion på 10x. Økonomien i orkestrering af flere modeller vil fortsat blive bedre.
Niveauer på enheden. Telefoner og bærbare computere med lokale AI-funktioner tilbyder et »gratis« niveau til visse forespørgsler. Routinglogik vil i stigende grad omfatte reglen »bliv på enheden, hvis det er muligt«.
Standardiserede API’er på tværs af udbydere. OpenAI-kompatible API’er er allerede udbredt, og det bliver stadig nemmere at skifte udbyder. Forvent mere standardisering, som gør strategier med flere udbydere enklere.
En starttjekliste
Hvis du bygger et system med flere modeller fra bunden eller migrerer fra én model:
-
Kortlæg opgaverne. Hvilke typer LLM-kald foretager din app? Cirka hvor ofte? Cirka hvor dyre er de?
-
Kategorisér efter kompleksitet. Afgør for hver opgavetype, om den er enkel, moderat eller kompleks. Match den med et modelniveau.
-
Byg en router. Begynd med fast, opgavebaseret routing. Undgå overudvikling.
-
Tilføj fallback. Hver primær model bør have en fallback fra en anden udbyder.
-
Mål kvalitet pr. route. Opsæt logning og grundlæggende evaluering. Du skal vide, om kvaliteten holder.
-
Gentag processen. Flyt opgaver til billigere modeller, hvor kvaliteten holder. Flyt dem tilbage til dyrere modeller, hvor kvaliteten svigter. Tilpas løbende.
-
Stop ikke finjusteringen. Modeller ændres, nye lanceres, og priser flytter sig. En routingopsætning kan være optimal i maj 2026 og mindre egnet i november 2026.
Stop med at bruge én model til alt
Orkestrering af flere modeller er en af de ændringer med højest investeringsafkast, du kan foretage i et AI-system i produktion. Udført godt reducerer det omkostningerne med 60-90% og forbedrer ofte kvaliteten, fordi hver opgave bruger en model, der passer til den.
Den tekniske tærskel er lav: Grundlæggende routinglogik kræver nogle få dusin linjer kode. Kravet til disciplin er højere, fordi du løbende skal måle kvaliteten og kontrollere, at routingbeslutningerne holder.
Stop med at bruge én model til alt. Kortlæg opgaverne. Vælg den rette model til hver. Mål resultatet. Gentag. Besparelserne er reelle, og kvalitetsforbedringerne er som regel en bonus.
