LLM-router: Rout forespørgsler, skær 60 % af udgifterne [2026]

LLM-router: Rout forespørgsler, skær 60 % af udgifterne [2026]

En LLM-router er et tyndt lag mellem din app og flere sprogmodeller, der vælger, hvilken model der håndterer hver forespørgsel. Den undersøger forespørgslen (opgavetype, kompleksitet, tokenbudget), videresender den til den bedst egnede model og falder tilbage til en reserve, hvis den model fejler. Målet: svar i den rigtige størrelse til den laveste tokenpris.

At lade en frontier-model betale for at svare på »hvad er jeres refusionspolitik?« er sådan, regninger løber løbsk. AWS målte alternativet i april 2025: en klassifikator-router, der lægger 0,53 sekunders latenstid til, en semantisk router, der lægger 0,10 sekunder til, og op til 30 % rabat på regningen for routing inden for én modelfamilie. Genskaber man det regnestykke på tværs af leverandører med listepriser fra juli 2026, som vi gør nedenfor, når besparelsen 70 %. Det meste af besparelsen kommer fra én beslutning, truffet før et eneste token er genereret.

Nøglepointer

• En LLM-router afgør, hvilken model der håndterer hver forespørgsel, baseret på opgavetype, pris eller målt kvalitet.
• Der findes fem strategier: regelbaseret, omkostningsbevidst, latensbevidst, semantisk (embeddings) og LLM-klassifikator-routing.
• Regelbaseret routing tilføjer ca. 0 ms og 0 $; klassifikator-routing tilføjer 300-800 ms plus klassifikator-tokenudgifter pr. forespørgsel.
• Routing kan skære tokenforbruget ned med op til 60 %, når det meste simple trafik flyttes til en 10-20x billigere model.
• Én leverandør, under 10.000 forespørgsler om dagen, intet omkostningspres? Spring routeren over. Simple fallbacks er nok.

Hvad gør en LLM-router helt præcist?

En LLM-router kører et lille beslutningstrin før hvert modelkald: læs forespørgslen, score den mod en routingregel, vælg en model, send kaldet, og prøv igen på en fallback, hvis den første model fejler. Intet andet i din app ændres. Du sender stadig én forespørgsel og får ét svar tilbage.

Forespørgslens livscyklus, i rækkefølge:

1. Forespørgslen ankommer til router-endepunktet, præcis som den ville hos et model-API.
2. Analysér. Routeren undersøger prompten: nøgleord, tokenantal, en embedding eller en klassifikator-score.
3. Vælg. Routingstrategien kortlægger signalet til et modelniveau (billig, mellem, frontier eller lokal).
4. Videresend. Kaldet går til den valgte model via et OpenAI-kompatibelt API.
5. Fallback. Ved timeout, rate limit eller fejl prøves forespørgslen igen på næste niveau i kæden.

Folk søger på »llm gateway vs router«, fordi leverandørernes dokumentation udvisker begreberne. Én sætning løser det: gatewayen er røret; routeren er beslutningen. De er lag, ikke rivaler, og de fleste gateways har en router indbygget.

Ifølge LiteLLMs dokumentation kører den samme proxy, der opbevarer dine virtuelle nøgler, også routeren. Sammenligner du specifikt værktøjerne på rørniveau? Vores oversigt over de bedste LLM-gateway-værktøjer rangerer ti.

Har du overhovedet brug for en LLM-router?

De fleste små apps gør ikke. En router tjener sig hjem, når trafikken deler sig i klart forskellige opgavetyper, når tokenregningen er din største infrastrukturudgift, eller når du kører mere end én leverandør og har brug for failover. Under disse tærskler giver simple retries plus én fallback-model dig pålideligheden uden den ekstra bevægelige del.

Vi siger det ligeud, for ingen andre i dette felt vil: hvis du kører én leverandør med under 10.000 forespørgsler om dagen, er en router overhead, du ikke har brug for. Simple fallbacks vinder.

Hvorfor så direkte? Hver route er en påstand (»denne opgaveklasse er sikker på den billige model«), der ældes, efterhånden som modeller, priser og dit produkt ændrer sig. Køb kun den vedligeholdelsesomkostning, når besparelsen klart slår den.

De 5 LLM-routingstrategier (og hvornår du bruger hver)

Hver LLM-routingstrategi besvarer ét spørgsmål: hvilket signal stoler du nok på til at vælge en model? Regler stoler på nøgleord. Omkostningsrouting stoler på tokenbudgettet. Latensrouting stoler på et stopur. Semantisk routing stoler på embeddings. Klassifikatorrouting stoler på en anden LLM. Afvejningen er altid den samme: mere signalkvalitet, mere ekstra latenstid og omkostning pr. forespørgsel.

Autofuldførelse viser disse som »llm routing strategies«, »llm task routing«, »llm intent routing« og »llm dynamic routing«. De kortlægges til fem mønstre:

Ét mønster går på tværs af alle fem: kaskaden, også kaldet model tiering. Start billigt og optrap kun ved fejl eller lav konfidens. En supportbot svarer fra en model til 0,25 $ pr. million tokens; hvis konfidensen falder under 0,7, prøves den samme forespørgsel igen på en frontier-model. Du betaler kun for intelligens, når det billige niveau indrømmer, at det sidder fast.

For akademisk dybde katalogiserer ulab-uiucs LLMRouter-bibliotek 16+ forskningsbaserede routingalgoritmer (KNN, SVM, MLP, matrix factorization, Elo, graph og BERT-style). Hvis semantisk routing er dit valg, afgør eksempel-embeddings næsten alt; vores guide til de bedste embedding-modeller dækker, hvilke der holder på reelle korpusser.

Hvordan bygger man en LLM-router i Python?

Man bygger en med cirka 80 linjer almindelig Python mod et hvilket som helst OpenAI-kompatibelt endepunkt. Intet framework nødvendigt. De fire routere nedenfor eskalerer i sofistikering: nøgleordsregler, en omkostningstærskel, embedding-lighed og en klassifikatormodel med failover. Hver eneste printer den model, den valgte, så du kan se beslutningen ske.

Hvis du har søgt på »how to build an llm router« og kun fundet AWS CDK-stakke og akademiske repos, er dette afsnit det klare svar. AWS' referenceimplementering er solid, men svejset fast til Bedrock, Lambda og CDK. Vores kører alle steder, hvor OpenAI-klienten peger hen: OpenAI, Anthropic via en proxy, Ollama på en laptop, vLLM på en GPU-maskine. Her er den router, vi først skitserer for kunder.

Trin 1: Regelbaseret router (nøgleord til modeller)

Nul-latens-baselinjen. Et regex-kort beslutter; alt, der ikke matcher, går til frontier-niveauet.

import re
from openai import OpenAI

client = OpenAI()  # works with OpenAI, Ollama, vLLM, or a LiteLLM proxy

def ask(model: str, prompt: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

ROUTES = [
    (re.compile(r"\b(refund|cancel|invoice|password|hours)\b", re.I), "gpt-5-mini"),
    (re.compile(r"\b(summarize|translate|rewrite)\b", re.I), "gpt-5-mini"),
]
FRONTIER = "gpt-5"

def rule_router(prompt: str) -> str:
    for pattern, model in ROUTES:
        if pattern.search(prompt):
            return model
    return FRONTIER

prompt = "How do I cancel my subscription?"
model = rule_router(prompt)
print(model)  # gpt-5-mini: regex hit on "cancel"
print(ask(model, prompt))

Input: et supportspørgsmål. Beslutning: regex-match på »cancel«. Valgt model: gpt-5-mini. Intet API-kald nødvendigt for at route det, og derfor forbliver det standarden.

Trin 2: Omkostningsbevidst router (tokenbudgettærskel)

Samme idé, men signalet er forespørgslens størrelse i stedet for nøgleord. Korte prompts med små outputbudgetter går billigt; alt andet går frontier.

def cost_router(prompt: str, max_output_tokens: int = 500) -> str:
    word_count = len(prompt.split())
    if word_count < 60 and max_output_tokens <= 300:
        return "gpt-5-mini"  # $0.25 in / $2 out per M tokens
    return "gpt-5"           # $1.25 in / $10 out per M tokens

prompt = "Write a two-line product description for a ceramic mug."
model = cost_router(prompt, max_output_tokens=120)
print(model)  # gpt-5-mini: short prompt, small output budget

Groft? Ja. Effektivt? Også ja, for tokenvolumen korrelerer bedre med opgavestørrelse, end de fleste forventer. Dette er hele strategien bag adskillige betalte »cheap llm router«-produkter.

Trin 3: Semantisk router (embeddings til eksemplarer)

Til uklar brugerinput, der undgår nøgleord: embed prompten og sammenlign den med embeddede eksempelprompts. Den nærmeste klynge ejer forespørgslen.

import numpy as np

EXEMPLARS = {
    "gpt-5-mini": [
        "classify this support ticket into a category",
        "extract the shipping address from this email",
    ],
    "gpt-5": [
        "debug this race condition in our worker pool",
        "design a multi-tenant billing schema",
    ],
}

def embed(texts: list[str]) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in r.data])

CENTROIDS = {m: embed(xs).mean(axis=0) for m, xs in EXEMPLARS.items()}

def semantic_router(prompt: str) -> str:
    v = embed([prompt])[0]
    scores = {
        m: float(np.dot(v, c) / (np.linalg.norm(v) * np.linalg.norm(c)))
        for m, c in CENTROIDS.items()
    }
    return max(scores, key=scores.get)

print(semantic_router("pull the tracking number out of this message"))
# gpt-5-mini: closest to the extraction exemplars

Routingkaldet koster én embedding (et par hundrede tokens) og 50-150 ms. Forberegn centroiderne ved opstart, ikke pr. forespørgsel.

Trin 4: LLM-klassifikatorrouter med fallback

Det stærkeste signal: en billig model læser prompten og scorer dens sværhedsgrad. Dette er strategien, AWS målte til 0,53 sekunders ekstra latenstid, så vi pakker den ind i en fallback-kæde.

def classify_router(prompt: str) -> str:
    verdict = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[{"role": "user", "content":
            "Reply HARD or EASY only. Task: " + prompt}],
        max_tokens=5,
    ).choices[0].message.content.strip().upper()
    return "gpt-5" if verdict.startswith("HARD") else "gpt-5-mini"

def route_and_call(prompt: str) -> str:
    model = classify_router(prompt)
    try:
        return ask(model, prompt)
    except Exception:
        backup = "gpt-5-mini" if model == "gpt-5" else "gpt-5"
        return ask(backup, prompt)  # fallback tier catches the failure

print(route_and_call("Prove this greedy algorithm is optimal."))
# classifier says HARD, so gpt-5 answers

Det er hele LLM-router-eksemplet: fire funktioner, én klient, ingen infrastruktur ud over, hvad du allerede kører. Produktionshærdning er næste afsnit.

Hvor meget sparer LLM-routing faktisk?

AWS målte router-overhead til 107,90-188,90 $ pr. måned pr. 100.000 spørgsmål om dagen, hvor klassifikatorrouting tilføjer 0,53 sekunder pr. forespørgsel og semantisk routing 0,10 sekunder. Besparelsessiden overgår langt den overhead. Vores gennemregnede eksempel nedenfor, bygget på listepriser fra juli 2026, lander på en besparelse på 70,7 %. Hagen er trafikblandingen: du skal have de fleste forespørgsler til at kvalificere til det billige niveau.

To tabeller. Først hvad routeren selv koster dig pr. 1.000 forespørgsler:

AWS' opslag fra april 2025 er det eneste uafhængigt publicerede målesæt i dette felt, så vi forankrer os til det og markerer vores udvidelser som estimater, ikke tal vi har kørt. Bedrock Intelligent Prompt Routing skar omkostningerne inden for familien med op til 30 %, ifølge AWS.

For det andet det gennemregnede besparelseseksempel, der understøtter vores overskrift:

Forudsætninger, markeret: 100.000 forespørgsler pr. måned; 800 input plus 200 output tokens pr. forespørgsel i gennemsnit; en 80 % simpel / 20 % kompleks fordeling; listepriser fra Anthropics prisside og OpenAI's prisside pr. juli 2026, med den fulde taksttabel i vores LLM API-prissammenligning. Stykregnskab pr. forespørgsel: Sonnet 4 koster 800 x 3 $/M + 200 x 15 $/M = 0,0054 $; GPT-5 mini koster 800 x 0,25 $/M + 200 x 2 $/M = 0,0006 $.

Resultatet er en besparelse på 70,7 %, og det er dér, de 60 % i vores titel kommer fra, med rigelig margin. Ærlige forbehold: dette er et gennemregnet eksempel, ikke et benchmark, vi har kørt. Det antager, at dit billige niveau er 10-20x billigere, og at 80 % af trafikken reelt kvalificerer. Routing inden for familien, AWS' scenarie, bliver nær 30 %. Og routing er ét greb blandt mange; prompt caching og trimning betaler sig ofte hurtigere, og vores guide til måder at reducere LLM API-udgifter rangerer alle tolv.

Routingmønstre i produktion

En legetøjsrouter vælger en model. En produktionsrouter prøver også igen, balancerer load, cacher gentagelser og isolerer API-nøgler pr. team. Når du passerer et par tusinde forespørgsler om dagen, så hold op med at håndbygge dem og kør en gateway, der har en router indbygget.

De fire mønstre, der betyder noget:

• Fallback-kæder. Billigt niveau først, frontier ved fejl eller timeout. Det enkeltmønster med højest værdi; det meste af din pålidelighed kommer fra dette alene.
• Load balancing. Fordel kald på tværs af duplikerede deploymenter eller API-nøgler for at undgå rate limits pr. nøgle.
• Svarcaching. Identiske prompts returnerer cachede svar. Supporttrafik gentager sig mere, end man skulle tro; rammerater på 10-30 % er almindelige.
• Virtuelle nøgler og budgetter. Udsted nøgler pr. team med månedlige lofter, så én løbsk loop ikke kan afbrænde hele regningen.

Dette ligger tæt på den konfiguration, vi kører på vores staging-agentstak (fil: litellm-router.yaml, monteret i LiteLLM proxy-containeren):

model_list:
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5-mini
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-opus-5

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"cheap": ["frontier"]}]
  num_retries: 2
  timeout: 30

Hvor hvert værktøj passer, med holdninger:

• LiteLLM. Vælg hvis du vil self-hoste og open source, og du allerede kører Docker. Vores LiteLLM proxy-opsætningsguide gennemgår den fulde deployment, nøgler og budgetter inkluderet.
• OpenRouter. Vælg hvis du vil have hundredvis af modeller bag én nøgle og nul drift. Deres rangeringsside fungerer også som throughput-data.
• Portkey. Vælg hvis enterprise-krav (SSO, audit logs, compliance-rapporter) driver beslutningen.
• Egen kode fra dette indlæg. Vælg hvis du er under ~50.000 forespørgsler om dagen og vil have nul ny infrastruktur.

Uanset hvad du vælger, sammenligner oversigten over LLM-gateway-værktøjer ti af dem head to head.

Kan du route mellem lokale modeller og hostede API'er?

Ja, og tokenregnskabet er forførende: en lokal model fakturerer 0 $ pr. token, så hver forespørgsel, Ollama eller vLLM besvarer, er ren besparelse. Afvejningen er latenstid og kvalitet pr. watt. Lokalt vinder for simple opgaver med høj volumen på hardware, du allerede ejer; det hostede API fanger alt, der har brug for en frontier-hjerne.

Mekanikken er antiklimaktisk, og det er pointen. Ollama eksponerer et OpenAI-kompatibelt endepunkt på localhost:11434/v1, og vLLM serverer den samme form. Så alle routerne ovenover fungerer uændret: peg base_url mod den lokale server, sæt qwen3:8b i den billige plads, og behold gpt-5 som fallback-niveau. Til en self-hostet routerboks leveres LiteLLM som et Docker-image, hvilket er den »llm router docker«-opsætning, folk søger efter.

To ærlighedsnoter. En 70B-model på én A100 serverer cirka 30-40 tokens i sekundet; hostede API'er slår det på burst-throughput, så lokal routing passer bedre til jævn baggrundstrafik end til spidsbelastet brugervendt chat. Og lokale 8B-modeller fejler på flertrins værktøjskald, så hold de svære routes pegende mod skyen. Hvis du vælger selve serving-motoren, benchmarker vLLM vs SGLang de to.

Routing driver også multimodel coding-agent-opsætninger. En LiteLLM-agtig proxy lader Claude Code tale med lokale og hostede modeller via ét endepunkt; se hvordan du bruger forskellige modeller i Claude Code for den præcise kobling.

Hvordan ved du, om routing virker?

Du måler det, ellers gætter du. Log hvilken model der besvarede hver forespørgsel, score et udsnit af outputs mod en rubrik, og feed scorerne tilbage i routingreglerne. Teams, der springer dette trin over, ender med en statisk konfiguration, der stille rådner, mens modeller og priser ændrer sig under den.

Modningskurven kører regler, så omkostning, så målt kvalitet:

1. Log routen. Gem den valgte model, latenstid og tokenantal pr. forespørgsel som én kolonne i dine eksisterende traces.
2. Score outputs ugentligt. En LLM-dommer eller et menneskeligt udsnit, bestået/fejlet pr. forespørgselsklasse. Halvtreds graduerede outputs pr. klasse er nok at styre efter.
3. Genjustér. Hvis det billige niveau består 95 %+ i en klasse, så udvid dets regel til at fange mere af den trafik. Hvis det falder under 90 %, så stram.

Her er den linje, vi bliver ved med at gentage for kunder: en router, du aldrig genjusterer, er bare en statisk konfiguration med ekstra latenstid. Log den valgte model, score outputs, feed scorer tilbage.

Det loop er evals plus observability anvendt på routing. Vores LLM-evals-guide dækker scoringsrubrikkerne; AI-observability-guiden dækker, hvor traces lever.

Hvor er LLM-routingforskningen på vej hen?

Den akademiske linje behandler routing som et læringsproblem, ikke en konfigurationsfil. ulab-uiucs LLMRouter, biblioteket der rangerer først på dette nøgleord, implementerer 16+ algoritmer (KNN, SVM, MLP, matrix factorization, Elo, graph, BERT og RL-routere) med en benchmark-pipeline over 11 datasæt. Det mest citerede nyere paper, RouteLLM (Ong et al., arXiv:2406.18665), træner routere på menneskelige præferencedata og rapporterer over 2x omkostningsreduktion uden kvalitetstab på MMLU og MT-Bench. Det nyeste skud: prefill-aktiveringsroutere, »prefill is all you need«-linjen, som læser en models interne aktiveringer under prefill for at forudsige sværhedsgrad, før genereringen starter. Retningen er routere, der træner sig selv fra dine eval-data, hvilket er præcis feedback-loopet fra forrige afsnit.

Sådan griber Techsy det an: de agentstakke, vi leverer til B2B-kunder, kører præcis dette mønster, en omkostningsniveaurouter med fallback-kæder koblet ind i gatewayen, plus eval-drevet genjustering. Hvis du overvejer, om routing passer til din stak, så få en gratis konsultation, og vi kortlægger din trafikblanding sammen med dig.

Ofte stillede spørgsmål

Hvad er en LLM-router?

En LLM-router er et lag mellem din applikation og flere sprogmodeller, der afgør, hvilken model der håndterer hver forespørgsel. Den tjekker forespørgslens opgavetype, størrelse eller sværhedsgrad og videresender den derefter til den bedst egnede model, med en fallback, hvis den model fejler. Tænk på den som en trafikleder for dine model-API-kald.

Hvordan fungerer LLM-routing?

LLM-routing fungerer i fem trin: forespørgslen ankommer, routeren undersøger den (nøgleord, tokenantal eller en embedding), en strategi vælger et modelniveau, kaldet videresendes, og en fallback-model fanger eventuelle fejl. Hele beslutningen sker, før genereringen starter, så den tilføjer millisekunder, ikke sekunder, medmindre en klassifikatormodel står for scoringen.

Er en LLM-router det samme som en LLM-gateway?

Nej. En gateway er røret: API-nøgler, rate limits, budgetter og logfiler. En router er beslutningen: hvilken model der svarer. De er lag, ikke rivaler, og de fleste gateways (LiteLLM, Portkey, OpenRouter) har en router indbygget. Du kan køre en router uden en gateway, men i produktion vil du som regel have begge sammen.

Sparer modelrouting faktisk penge?

Ja, når det meste af din trafik kvalificerer til et meget billigere niveau. Vores gennemregnede eksempel flytter 80 % af forespørgslerne fra en 3 $/15 $-pr.-million-tokens-model til en 0,25 $/2 $-model og skærer regningen med 70,7 %. AWS rapporterede op til 30 % for routing inden for én modelfamilie. Hvis din trafik er ensartet kompleks, skrumper besparelsen mod nul.

Hvad er den bedste open source LLM-router?

Til produktion, LiteLLM: self-hosted, aktivt vedligeholdt, og den kombinerer en gateway med en router. Til algoritmer på forskningsniveau implementerer ulab-uiucs LLMRouter 16+ routingstrategier fra den akademiske litteratur. RouteLLM er den stærkeste kvalitet-pr.-krone-router trænet på præferencedata. De fleste teams bør starte med LiteLLM og kun række ud efter forskningsbibliotekerne, hvis de har brug for custom scoring.

Hvordan bygger jeg en LLM-router i Python?

Start med OpenAI-klienten og cirka 80 linjer kode: et regelkort fra nøgleord til modeller, en omkostningstærskel på tokenantal, embedding-lighed med eksempelprompts eller en billig klassifikatormodel, der scorer sværhedsgrad. Alle fire mønstre er i byggeafsnittet ovenover, kørbare mod OpenAI, Ollama eller vLLM uden ændringer.

Kan jeg route mellem lokale modeller og cloud-API'er?

Ja. Ollama (localhost:11434/v1) og vLLM eksponerer begge OpenAI-kompatible endepunkter, så den samme routerkode peger mod en lokal model for billig trafik og et hostet API for svær trafik. Lokale tokens koster 0 $, men du ejer hardwaren og latenstiden. Dette er mønsteret bag de fleste multimodel Claude Code-opsætninger.

Hvad er semantisk routing?

Semantisk routing embedder hver indkommende prompt og sammenligner den med embeddede eksempelprompts og sender forespørgslen til den model, der ejer den nærmeste eksempelklynge. Den håndterer uklar, omskrevet brugerinput, som nøgleordsregler misser, til en pris af 50-150 ms plus embedding-tokens pr. forespørgsel. AWS målte den til 0,10 sekunders ekstra latenstid.

Hvor meget latenstid tilføjer en LLM-klassifikatorrouter?

AWS målte 0,53 sekunders ekstra latenstid for LLM-assisteret klassifikation mod 0,10 sekunder for semantisk routing. Regelbaseret og omkostningsbevidst routing tilføjer cirka nul, fordi de er rene kodestier. Hvis dit produkt har en stram svartids-SLA, så foretræk regler, omkostningstærskler eller embeddings, og reservér klassifikatoren til offline eller queuede workloads.

Kilder

• Seifi, N. og Chugh, M. (2025-04-09). "Multi-LLM routing strategies for generative AI applications on AWS." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/multi-llm-routing-strategies-for-generative-ai-applications-on-aws/ (tilgået 30. juli 2026)
• AWS sample code: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (tilgået 30. juli 2026)
• LiteLLM documentation. https://docs.litellm.ai (tilgået 30. juli 2026)
• Anthropic pricing. https://www.anthropic.com/pricing (tilgået 30. juli 2026)
• OpenAI API pricing. https://openai.com/api/pricing (tilgået 30. juli 2026)
• ulab-uiuc LLMRouter. https://github.com/ulab-uiuc/LLMRouter (tilgået 30. juli 2026)
• Ong, I. et al. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (tilgået 30. juli 2026)
• OpenRouter rankings. https://openrouter.ai/rankings (tilgået 30. juli 2026)