LLM-router: Rut forespørsler, kutt kostnadene 60 % [2026]

LLM-router: Rut forespørsler, kutt kostnadene 60 % [2026]

En LLM-router er et tynt lag mellom appen din og flere språkmodeller som velger hvilken modell som skal håndtere hver forespørsel. Den undersøker forespørselen (oppgavetype, kompleksitet, tokenbudsjett), videresender den til modellen som passer best, og bytter til en reservemodell dersom den første feiler. Målet: svar i riktig størrelse til lavest mulig tokenkostnad.

Å la en frontier-modell betale for å svare på «hva er refusjonspolitikken deres?» er slik regninger blåser opp. AWS målte alternativet i april 2025: en klassifiserer-router som legger til 0,53 sekunder latens, en semantisk router som legger til 0,10 sekunder, og opptil 30 % rabatt på regningen ved ruting innen én modellfamilie. Gjør man det samme regnestykket på tvers av leverandører med listepriser fra juli 2026, slik vi gjør nedenfor, når kuttet 70 %. Mesteparten av besparelsen kommer fra én beslutning, tatt før et eneste token er generert.

Hovedpoeng

• En LLM-router bestemmer hvilken modell som håndterer hver forespørsel, basert på oppgavetype, kostnad eller målt kvalitet.
• Det finnes fem strategier: regelbasert, kostnadsbevisst, latensbevisst, semantisk (embeddings) og LLM-klassifiserer-ruting.
• Regelbasert ruting legger til ca. 0 ms og $0; klassifiserer-ruting legger til 300–800 ms pluss klassifiserer-tokenkostnad per forespørsel.
• Ruting kan kutte tokenforbruket med opptil 60 % når det meste av enkel trafikk flyttes til en modell som er 10–20x billigere.
• Én leverandør, under 10 000 forespørsler om dagen, ikke noe kostnadspress? Hopp over routeren. Enkle reserveløsninger holder.

Hva gjør egentlig en LLM-router?

En LLM-router kjører et lite beslutningssteg før hvert modellkall: les forespørselen, vurder den mot en rutingsregel, velg en modell, send kallet, og prøv igjen på en reserve dersom den første modellen feiler. Ingenting annet i appen din endres. Du sender fortsatt én forespørsel og får ett svar tilbake.

Forespørselens livssyklus, i rekkefølge:

1. Forespørselen ankommer router-endepunktet, nøyaktig slik den ville gjort hos et modell-API.
2. Analyser. Routeren undersøker prompten: nøkkelord, antall token, en embedding eller en klassifiserer-score.
3. Velg. Rutingsstrategien kobler signalet til et modellnivå (billig, mellom, frontier eller lokalt).
4. Videresend. Kallet går til den valgte modellen via et OpenAI-kompatibelt API.
5. Reserve. Ved tidsavbrudd, rate-grense eller feil prøves forespørselen på nytt hos neste nivå i kjeden.

Folk søker på «llm gateway vs router» fordi leverandørenes dokumentasjon visker ut begrepene. Én setning fikser det: gatewayen er røret; routeren er beslutningen. De er lag, ikke rivaler, og de fleste gatewayer har en router innebygd.

Ifølge LiteLLMs dokumentasjon kjører samme proxy som holder de virtuelle nøklene dine også routeren. Sammenligner du spesifikt verktøyene på rørnivå? Oversikten vår over de beste LLM-gateway-verktøyene rangerer ti.

Trenger du i det hele tatt en LLM-router?

De fleste små apper gjør ikke det. En router tjener seg inn når trafikken deler seg i klart ulike oppgavetyper, når tokenregningen er den største infrastrukturkostnaden din, eller når du kjører mer enn én leverandør og trenger failover. Under disse tersklene gir enkle retry-ordninger pluss én reservemodell deg påliteligheten uten den ekstra bevegelige delen.

Vi sier det rett ut, for ingen andre i dette feltet gjør det: kjører du én leverandør med under 10 000 forespørsler om dagen, er en router overhead du ikke trenger. Enkle reserveløsninger vinner.

Hvorfor være så direkte? Hver rute er en påstand («denne oppgaveklassen er trygg på den billige modellen») som eldes etter hvert som modeller, priser og produktet ditt endres. Kjøp den vedlikeholdskostnaden bare når besparelsene klart slår den.

De 5 LLM-rutingsstrategiene (og når du bruker hver)

Hver LLM-rutingsstrategi svarer på ett spørsmål: hvilket signal stoler du nok på til å velge modell? Regler stoler på nøkkelord. Kostnadsruting stoler på tokenbudsjettet. Latensruting stoler på en tidtaker. Semantisk ruting stoler på embeddings. Klassifiserer-ruting stoler på en annen LLM. Avveiningen har alltid samme form: mer signalkvalitet, mer ekstra latens og kostnad per forespørsel.

Autofullføring foreslår disse som «llm routing strategies», «llm task routing», «llm intent routing» og «llm dynamic routing». De tilsvarer fem mønstre:

Ett mønster går igjen i alle fem: kaskaden, også kalt modellagdeling. Start billig og oppskaler bare ved feil eller lav konfidens. En kundestøtte-bot svarer fra en modell til $0,25 per million token; dersom konfidensen faller under 0,7, prøves den samme forespørselen på nytt hos en frontier-modell. Du betaler for intelligens bare når det billige nivået innrømmer at det sitter fast.

For akademisk dybde: ulab-uiucs LLMRouter-bibliotek katalogiserer 16+ forskede rutingsalgoritmer (KNN, SVM, MLP, matrisefaktorisering, Elo, graf og BERT-stil). Hvis semantisk ruting er valget ditt, avgjør eksempel-embeddingene nesten alt; guiden vår om de beste embedding-modellene dekker hvilke som holder mål på reelle korpus.

Hvordan bygger du en LLM-router i Python?

Du bygger en med rundt 80 linjer ren Python mot et hvilket som helst OpenAI-kompatibelt endepunkt. Ingen rammeverk nødvendig. De fire routerne nedenfor trappes opp i sofistikering: nøkkelordregler, en kostnadsterskel, embedding-likhet og en klassifiserermodell med failover. Hver eneste skriver ut modellen den valgte, slik at du kan se beslutningen skje.

Hvis du har søkt «how to build an llm router» og bare funnet AWS CDK-stacker og akademiske repoer, er denne seksjonen det enkle svaret. AWS sin referanseimplementasjon er solid, men sveiset til Bedrock, Lambda og CDK. Vår kjører overalt OpenAI-klienten peker: OpenAI, Anthropic via en proxy, Ollama på en laptop, vLLM på en GPU-boks. Her er routeren vi først skisserer for kunder.

Steg 1: Regelbasert router (nøkkelord til modeller)

Null-latens-grunnlinjen. Et regex-kart bestemmer; alt som ikke matcher, går til frontier-nivået.

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 kundestøttespørsmål. Beslutning: regex-treff på «cancel». Valgt modell: gpt-5-mini. Ingen API-kall trengs for å rute den, og derfor forblir dette standardvalget.

Steg 2: Kostnadsbevisst router (tokenbudsjett-terskel)

Samme idé, men signalet er forespørselens størrelse i stedet for nøkkelord. Korte prompter med lite output-budsjett går billig; alt annet går til 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

Grovt? Ja. Effektivt? Også ja, for tokenvolum korrelerer med oppgavestørrelse bedre enn de fleste forventer. Dette er hele strategien bak flere betalte «cheap llm router»-produkter.

Steg 3: Semantisk router (embeddings mot eksempler)

For uklar brukerinput som unngår nøkkelord: embed prompten og sammenlign den med embeddede eksempelprompter. Den nærmeste klyngen eier forespørselen.

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

Rutingskallet koster én embedding (noen hundre token) og 50–150 ms. Forhåndsberegn sentroidene ved oppstart, ikke per forespørsel.

Steg 4: LLM-klassifiserer-router med reserve

Det sterkeste signalet: en billig modell leser prompten og scorer vanskelighetsgraden. Dette er strategien AWS målte til 0,53 sekunder ekstra latens, så vi pakker den inn i en reservekjede.

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 funksjoner, én klient, ingen infrastruktur utover det du allerede kjører. Produksjonsharding er neste seksjon.

Hvor mye sparer LLM-ruting faktisk?

AWS målte router-overhead til $107,90–$188,90 per måned per 100 000 spørsmål om dagen, der klassifiserer-ruting la til 0,53 sekunder per forespørsel og semantisk ruting 0,10 sekunder. Besparelsessiden dverger den overheaden. Det utregnede eksemplet vårt nedenfor, bygget på listepriser fra juli 2026, lander på en kostnadsreduksjon på 70,7 %. Haken er trafikkmiksen: du trenger at de fleste forespørslene kvalifiserer for det billige nivået.

To tabeller. Først, hva selve routeren koster deg per 1 000 forespørsler:

AWS sitt innlegg fra april 2025 er det eneste uavhengig publiserte målesettet i dette feltet, så vi forankrer oss til det og merker utvidelsene våre som estimater, ikke tall vi har kjørt. Bedrock Intelligent Prompt Routing kuttet kostnadene innen én familie med opptil 30 %, ifølge AWS.

For det andre, det utregnede besparelseseksemplet som underbygger overskriften vår:

Forutsetninger, merket: 100 000 forespørsler per måned; 800 input pluss 200 output-token per forespørsel i gjennomsnitt; en fordeling på 80 % enkelt / 20 % komplekst; listepriser fra Anthropics prisside og OpenAIs prisside per juli 2026, med hele pristabellen i LLM API-prissammenligningen vår. Regnestykke per forespørsel: 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 reduksjon på 70,7 %, og det er derfra de 60 % i tittelen vår kommer, med god margin. Ærlige forbehold: dette er et regneeksempel, ikke en benchmark vi har kjørt. Det forutsetter at det billige nivået ditt er 10–20x billigere, og at 80 % av trafikken faktisk kvalifiserer. Ruting innen én familie, AWS sitt scenario, holder seg nær 30 %. Og ruting er én spak blant mange; prompt-caching og trimming betaler seg ofte raskere, og guiden vår om måter å redusere LLM-API-kostnader på rangerer alle tolv.

Produksjonsrutingsmønstre

En lekeruter velger en modell. En produksjonsrouter prøver også igjen, balanserer last, cacher gjentakelser og isolerer API-nøkler per team. Etter noen tusen forespørsler om dagen bør du slutte å håndlage disse og kjøre en gateway med innebygd router.

De fire mønstrene som betyr noe:

• Reservekjeder. Billig nivå først, frontier ved feil eller tidsavbrudd. Det enkeltstående mønsteret med høyest verdi; det meste av påliteligheten din kommer fra dette alene.
• Lastbalansering. Fordel kall på tvers av dupliserte deploymenter eller API-nøkler for å unngå rate-grenser per nøkkel.
• Svar-caching. Identiske prompter returnerer cachede svar. Kundestøttetrafikk gjentar seg mer enn du skulle tro; treffrater på 10–30 % er vanlige.
• Virtuelle nøkler og budsjetter. Utsted nøkler per team med månedlige tak, slik at én løpsk loop ikke kan brenne ned hele regningen.

Dette er nært configen vi kjører på staging-agentstacken vår (fil: litellm-router.yaml, montert i LiteLLM proxy-kontaineren):

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 verktøy passer, med meninger:

• LiteLLM. Velg hvis du vil ha selvhostet og open source og allerede kjører Docker. LiteLLM proxy-oppsettguiden vår går gjennom hele deployen, inkludert nøkler og budsjetter.
• OpenRouter. Velg hvis du vil ha hundrevis av modeller bak én nøkkel og null drift. Rankingsiden deres fungerer også som gjennomstrømningsdata.
• Portkey. Velg hvis enterprisekrav (SSO, revisjonslogger, compliance-rapporter) styrer beslutningen.
• Egen kode fra dette innlegget. Velg hvis du er under ca. 50 000 forespørsler om dagen og vil ha null ny infrastruktur.

Uansett hva du velger, sammenligner oversikten over LLM-gateway-verktøy ti av dem direkte mot hverandre.

Kan du rute mellom lokale modeller og hostede API-er?

Ja, og tokenregnestykket er forførende: en lokal modell fakturerer $0 per token, så hver forespørsel Ollama eller vLLM svarer på, er ren besparelse. Avveiningen er latens og kvalitet per watt. Lokalt vinner for høyvolums enkle oppgaver på maskinvare du allerede eier; det hostede API-et fanger alt som trenger en frontier-hjerne.

Mekanismen er antiklimaktisk, og det er poenget. Ollama eksponerer et OpenAI-kompatibelt endepunkt på localhost:11434/v1, og vLLM serverer samme form. Så alle routerne ovenfor fungerer uendret: pek base_url mot den lokale serveren, sett qwen3:8b i den billige plassen og behold gpt-5 som reservenivå. For en selvhostet router-boks leveres LiteLLM som et Docker-image, og det er «llm router docker»-oppsettet folk søker etter.

To ærlighetsnotater. En 70B-modell på én A100 serverer omtrent 30–40 token per sekund; hostede API-er slår det på burst-gjennomstrømning, så lokal ruting passer bedre for jevn bakgrunnstrafikk enn for brukervendt chat med trafikktopper. Og lokale 8B-modeller fomler med flertrinns verktøykall, så hold de vanskelige rutene pekt mot skyen. Hvis du velger selve serveringsmotoren, benchmarker vLLM vs SGLang de to.

Ruting driver også kodeagentoppsett med flere modeller. En LiteLLM-stil proxy lar Claude Code snakke med lokale og hostede modeller via ett endepunkt; se hvordan du bruker forskjellige modeller i Claude Code for nøyaktig kobling.

Hvordan vet du om rutingen virker?

Du måler det, eller så gjetter du. Logg hvilken modell som svarte på hver forespørsel, vurder et utvalg av outputene mot en rubrikk og mat scorene tilbake til rutingsreglene. Team som hopper over dette steget, ender med en statisk config som stille råtner mens modeller og priser endres under den.

Modningsløpet kjører regler, så kostnad, så målt kvalitet:

1. Logg ruten. Lagre valgt modell, latens og antall token per forespørsel som én kolonne i de eksisterende tracene dine.
2. Vurder output ukentlig. En LLM-dommer eller et menneskelig utvalg, bestått/ikke bestått per forespørselsklasse. Femti graderte output per klasse er nok å styre etter.
3. Finjuster. Hvis det billige nivået består 95 %+ på en klasse, utvid regelen for å fange mer av den trafikken. Hvis det faller under 90 %, stram inn.

Her er linjen vi gjentar for kunder: en router du aldri finjusterer, er bare en statisk config med ekstra latens. Logg valgt modell, vurder output, mat scorene tilbake.

Den loopen er evalueringer pluss observabilitet brukt på ruting. LLM-evalueringsguiden vår dekker vurderingsrubrikkene; AI-observabilitetsguiden dekker hvor tracene bor.

Hvor er LLM-rutingsforskningen på vei?

Den akademiske linjen behandler ruting som et læringsproblem, ikke en config-fil. ulab-uiucs LLMRouter, biblioteket som rangerer først for dette nøkkelordet, implementerer 16+ algoritmer (KNN, SVM, MLP, matrisefaktorisering, Elo, graf, BERT og RL-routere) med en benchmark-pipeline over 11 datasett. Det mest siterte nyere paperet, RouteLLM (Ong m.fl., arXiv:2406.18665), trener routere på menneskelige preferansedata og rapporterer over 2x kostnadsreduksjon uten kvalitetstap på MMLU og MT-Bench. Den nyeste vendingen: prefill-aktiverings-routere, «prefill is all you need»-linjen, som leser en modells interne aktiveringer under prefill for å forutsi vanskelighetsgrad før genereringen starter. Retningen er routere som trener seg selv fra evalueringsdataene dine, og det er nøyaktig feedback-loopen fra forrige seksjon.

Hvordan Techsy griper dette an: agentstackene vi leverer for B2B-kunder, kjører nøyaktig dette mønsteret, en kostnadsnivå-router med reservekjeder koblet inn i gatewayen, pluss evalueringsdrevet finjustering. Hvis du vurderer om ruting passer for stacken din, få en gratis konsultasjon, så kartlegger vi trafikkmiksen din sammen med deg.

Ofte stilte spørsmål

Hva er en LLM-router?

En LLM-router er et lag mellom applikasjonen din og flere språkmodeller som bestemmer hvilken modell som håndterer hver forespørsel. Den sjekker forespørselens oppgavetype, størrelse eller vanskelighetsgrad og videresender den deretter til modellen som passer best, med en reserve dersom den modellen feiler. Tenk på den som en trafikkontrollør for modell-API-kallene dine.

Hvordan fungerer LLM-ruting?

LLM-ruting fungerer i fem steg: forespørselen ankommer, routeren undersøker den (nøkkelord, antall token eller en embedding), en strategi velger et modellnivå, kallet videresendes, og en reservemodell fanger eventuelle feil. Hele beslutningen skjer før genereringen starter, så den legger til millisekunder, ikke sekunder, med mindre en klassifiserermodell gjør vurderingen.

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

Nei. En gateway er røret: API-nøkler, rate-grenser, budsjetter og logger. En router er beslutningen: hvilken modell som svarer. De er lag, ikke rivaler, og de fleste gatewayer (LiteLLM, Portkey, OpenRouter) har en router innebygd. Du kan kjøre en router uten en gateway, men i produksjon vil du vanligvis ha begge sammen.

Sparer modellruting faktisk penger?

Ja, når det meste av trafikken din kvalifiserer for et mye billigere nivå. Det utregnede eksemplet vårt flytter 80 % av forespørslene fra en modell til $3/$15 per million token til en til $0,25/$2 og kutter regningen med 70,7 %. AWS rapporterte opptil 30 % for ruting innen én modellfamilie. Hvis trafikken din er jevnt over kompleks, krymper besparelsen mot null.

Hva er den beste open source LLM-routeren?

For produksjon: LiteLLM, selvhostet, aktivt vedlikeholdt, og den kombinerer en gateway med en router. For algoritmer på forskningsnivå implementerer ulab-uiucs LLMRouter 16+ rutingsstrategier fra den akademiske litteraturen. RouteLLM er den sterkeste kvalitet-per-krone-routeren trent på preferansedata. De fleste team bør starte med LiteLLM og bare gripe etter forskningsbibliotekene hvis de trenger tilpasset scoring.

Hvordan bygger jeg en LLM-router i Python?

Start med OpenAI-klienten og rundt 80 linjer kode: et regelkart fra nøkkelord til modeller, en kostnadsterskel på antall token, embedding-likhet med eksempelprompter eller en billig klassifiserermodell som scorer vanskelighetsgrad. Alle fire mønstrene finnes i byggeseksjonen ovenfor, kjørbare mot OpenAI, Ollama eller vLLM uten endringer.

Kan jeg rute mellom lokale modeller og sky-API-er?

Ja. Ollama (localhost:11434/v1) og vLLM eksponerer begge OpenAI-kompatible endepunkter, så den samme routerkoden peker mot en lokal modell for enkel trafikk og et hostet API for tung trafikk. Lokale token koster $0, men du eier maskinvaren og latensen. Dette er mønsteret bak de fleste Claude Code-oppsett med flere modeller.

Hva er semantisk ruting?

Semantisk ruting embedder hver innkommende prompt og sammenligner den med embeddede eksempelprompter, og sender forespørselen til modellen som eier den nærmeste eksempelklyngen. Det håndterer uklar, parafrasert brukerinput som nøkkelordregler bommer på, til en kostnad av 50–150 ms pluss embedding-token per forespørsel. AWS målte det til 0,10 sekunder ekstra latens.

Hvor mye latens legger en LLM-klassifiserer-router til?

AWS målte 0,53 sekunder ekstra latens for LLM-assistert klassifisering, mot 0,10 sekunder for semantisk ruting. Regelbasert og kostnadsbevisst ruting legger til omtrent null, fordi de er rene kodestier. Hvis produktet ditt har en stram responstids-SLA, foretrekk regler, kostnadsterskler eller embeddings, og reserver klassifisereren for offline eller købaserte arbeidsmengder.

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/ (besøkt 30. juli 2026)
• AWS eksempelkode: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (besøkt 30. juli 2026)
• LiteLLM-dokumentasjon. https://docs.litellm.ai (besøkt 30. juli 2026)
• Anthropic-priser. https://www.anthropic.com/pricing (besøkt 30. juli 2026)
• OpenAI API-priser. https://openai.com/api/pricing (besøkt 30. juli 2026)
• ulab-uiuc LLMRouter. https://github.com/ulab-uiuc/LLMRouter (besøkt 30. juli 2026)
• Ong, I. m.fl. (2024). «RouteLLM: Learning to Route LLMs with Preference Data.» arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (besøkt 30. juli 2026)
• OpenRouter-rangeringer. https://openrouter.ai/rankings (besøkt 30. juli 2026)