LLM Router: Styr anropen, sänk kostnaderna 60% [2026]

LLM Router: Styr anropen, sänk kostnaderna 60% [2026]

En LLM-router är ett tunt lager mellan din app och flera språkmodeller som avgör vilken modell som hanterar varje anrop. Den inspekterar anropet (uppgiftstyp, komplexitet, tokenbudget), skickar det vidare till den modell som passar bäst och faller tillbaka på en reserv om modellen felar. Målet: rätt dimensionerade svar till lägsta möjliga tokenkostnad.

Att låta en spjutspetsmodell svara på "vad har ni för returpolicy?" är så här fakturor skenar. AWS mätte alternativet i april 2025: en klassificerar-router som lägger på 0,53 sekunder latens, en semantisk router som lägger på 0,10 sekunder och upp till 30% lägre faktura för routing inom en och samma modellfamilj. Bygger du om samma kalkyl mellan leverantörer med juli 2026:s listpriser, som vi gör nedan, når sänkningen 70%. Det mesta av besparingen kommer från ett enda beslut, fattat innan en enda token genereras.

Viktigaste punkterna

• En LLM-router avgör vilken modell som hanterar varje anrop, baserat på uppgiftstyp, kostnad eller uppmätt kvalitet.
• Det finns fem strategier: regelbaserad, kostnadsmedveten, latensmedveten, semantisk (embeddings) och klassificerar-routing med LLM.
• Regelbaserad routing lägger på ~0 ms och $0; klassificerar-routing lägger på 300-800 ms plus klassificerarens tokenkostnad per anrop.
• Routing kan sänka tokenkostnaderna med upp till 60% när det mesta av den enkla trafiken flyttas till en 10-20x billigare modell.
• En leverantör, under 10 000 anrop om dagen, inget kostnadstryck? Skippa routern. Vanliga fallbacks räcker.

Vad gör en LLM-router egentligen?

En LLM-router kör ett litet beslutssteg före varje modellanrop: läs anropet, poängsätt det mot en routingregel, välj en modell, skicka anropet och försök igen på en fallback om den första modellen felar. Ingenting annat i din app ändras. Du gör fortfarande ett anrop och får ett svar tillbaka.

Anropets livscykel, i ordning:

1. Anropet anländer till routerns endpoint, exakt som det skulle göra till ett modell-API.
2. Analysera. Routern inspekterar prompten: nyckelord, tokenantal, en embedding eller ett klassificerarresultat.
3. Välj. Routingstrategin mappar signalen till en modellnivå (billig, mellan, spjutspets eller lokal).
4. Vidarebefordra. Anropet går till den valda modellen via ett OpenAI-kompatibelt API.
5. Fallback. Vid timeout, hastighetsgräns eller fel försöker anropet igen på nästa nivå i kedjan.

Folk söker efter "llm gateway vs router" eftersom leverantörernas dokumentation suddar ut begreppen. En mening reder ut det: gatewayen är röret; routern är beslutet. De är lager, inte rivaler, och de flesta gateways har en router inbyggd.

Enligt LiteLLM:s dokumentation kör samma proxy som håller dina virtuella nycklar också routern. Jämför du specifikt verktygen på rörets nivå? Vår genomgång av de bästa LLM-gateway-verktygen rankar tio.

Behöver du ens en LLM-router?

De flesta små appar behöver inte det. En router tjänar sitt syfte när trafiken delar upp sig i tydligt olika uppgiftstyper, när tokenfakturan är din största infrastrukturkostnad eller när du kör mer än en leverantör och behöver failover. Under de trösklarna ger vanliga retries plus en fallback-modell dig tillförlitligheten utan den rörliga delen.

Vi säger det rakt på sak, eftersom ingen annan i den här branschen gör det: kör du en leverantör under 10 000 anrop om dagen är en router onödig overhead. Vanliga fallbacks vinner.

Varför så rakt på sak? Varje route är ett påstående ("den här uppgiftsklassen är säker på den billiga modellen") som vittrar när modeller, priser och din produkt förändras. Köp det underhållet bara när besparingen tydligt överstiger det.

De 5 LLM-routingstrategierna (och när du ska använda dem)

Varje LLM-routingstrategi besvarar en fråga: vilken signal litar du tillräckligt mycket på för att välja modell? Regler litar på nyckelord. Kostnadsrouting litar på tokenbudgeten. Latensrouting litar på en timer. Semantisk routing litar på embeddings. Klassificerarrouting litar på en annan LLM. Avvägningen har alltid samma form: mer signalkvalitet, mer tillagd latens och kostnad per anrop.

Autocomplete ger förslag som "llm routing strategies", "llm task routing", "llm intent routing" och "llm dynamic routing". De mappar till fem mönster:

Ett mönster går genom alla fem: kaskaden, även kallad modellnivåer. Börja billigt och eskalera bara vid fel eller låg konfidens. En supportbot svarar från en modell för $0,25 per miljon tokens; om konfidensen sjunker under 0,7 försöker samma anrop igen på en spjutspetsmodell. Du betalar för intelligens bara när den billiga nivån medger att den kört fast.

För akademiskt djup: ulab-uiucs LLMRouter-bibliotek katalogiserar 16+ forskade routingalgoritmer (KNN, SVM, MLP, matrisfaktorisering, Elo, graf och BERT-stil). Om semantisk routing är ditt val avgör exemplarens embeddings nästan allt; vår guide till de bästa embedding-modellerna täcker vilka som håller måttet på riktiga korpusar.

Hur bygger man en LLM-router i Python?

Du bygger en med ungefär 80 rader vanlig Python mot valfri OpenAI-kompatibel endpoint. Inget ramverk krävs. De fyra routrarna nedan trappar upp i sofistikering: nyckelordsregler, en kostnadströskel, embedding-likhet och en klassificerarmodell med failover. Varje router skriver ut vilken modell den valde, så att du kan se beslutet ske.

Om du har sökt på "how to build an llm router" och bara hittat AWS CDK-stackar och akademiska repon är det här det raka svaret. AWS referensimplementation är solid men fastsvetsad vid Bedrock, Lambda och CDK. Vår kör var som helst OpenAI-klienten pekar: OpenAI, Anthropic via en proxy, Ollama på en laptop, vLLM på en GPU-maskin. Här är routern vi skissar åt kunder först.

Steg 1: Regelbaserad router (nyckelord till modeller)

Nollatensbaslinjen. En regex-tabell bestämmer; allt som inte matchar går till spjutspetsnivån.

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))

Indata: en supportfråga. Beslut: regex-träff på "cancel". Vald modell: gpt-5-mini. Inget API-anrop behövs för att routa det, och därför förblir det standardvalet.

Steg 2: Kostnadsmedveten router (tröskel för tokenbudget)

Samma idé, men signalen är anropets storlek istället för nyckelord. Korta prompter med liten outputbudget går billigt; allt annat går till spjutspetsen.

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? Också ja, eftersom tokenvolym korrelerar med uppgiftens storlek bättre än de flesta tror. Det här är hela strategin bakom flera betalda "cheap llm router"-produkter.

Steg 3: Semantisk router (embeddings mot exempel)

För luddiga användarinmatningar som undviker nyckelord: embedda prompten och jämför den mot inbäddade exempelprompter. Det kluster som ligger närmast tar anropet.

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

Routinganropet kostar en embedding (några hundra tokens) och 50-150 ms. Förberäkna centroiderna vid uppstart, inte per anrop.

Steg 4: LLM-klassificerare med fallback

Den starkaste signalen: en billig modell läser prompten och poängsätter dess svårighet. Det här är strategin AWS mätte till 0,53 sekunder tillagd latens, så vi lindar in den i en fallback-kedja.

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 är hela LLM-router-exemplet: fyra funktioner, en klient, ingen infrastruktur utöver det du redan kör. Produktionshärdning är nästa avsnitt.

Hur mycket sparar LLM-routing egentligen?

AWS mätte routerns overhead till $107,90-$188,90 per månad per 100 000 frågor om dagen, där klassificerarrouting lägger på 0,53 sekunder per anrop och semantisk routing 0,10 sekunder. Besparingssidan överväldigar den overheaden. Vårt räkneexempel nedan, byggt på juli 2026:s listpriser, landar på en 70,7-procentig kostnadssänkning. Haken är trafikmixen: du behöver att de flesta anrop kvalificerar sig för den billiga nivån.

Två tabeller. Först, vad routern själv kostar dig per 1 000 anrop:

AWS inlägg från april 2025 är den enda oberoende publicerade mätserien i den här branschen, så vi förankrar oss i den och märker våra utökningar som uppskattningar, inte siffror vi har kört. Bedrock Intelligent Prompt Routing sänkte kostnaden inom familjen med upp till 30%, enligt AWS.

För det andra, räkneexemplet för besparingen som ligger bakom vår rubrik:

Antaganden, markerade: 100 000 anrop per månad; 800 input plus 200 output-tokens per anrop i genomsnitt; en 80% enkel / 20% komplex-fördelning; listpriser från Anthropics prissida och OpenAI:s prissida per juli 2026, med den fullständiga pristabellen i vår LLM API-prisjämförelse. Kalkyl per anrop: Sonnet 4 kostar 800 x $3/M + 200 x $15/M = $0,0054; GPT-5 mini kostar 800 x $0,25/M + 200 x $2/M = $0,0006.

Resultatet är en 70,7-procentig sänkning, och där kommer 60% i vår titel ifrån, med god marginal. Ärliga förbehåll: det här är ett räkneexempel, inte ett benchmark vi har kört. Det antar att din billiga nivå är 10-20x billigare och att 80% av trafiken verkligen kvalificerar sig. Routing inom familjen, AWS scenario, stannar nära 30%. Och routing är en spak bland många; prompt-cachning och trimning betalar sig ofta snabbare, och vår guide till sätt att minska LLM API-kostnader rankar alla tolv.

Routingmönster för produktion

En leksaksrouter väljer en modell. En produktionsrouter försöker igen, balanserar last, cachar upprepningar och isolerar API-nycklar per team. Efter några tusen anrop om dagen, sluta handbygga de sakerna och kör en gateway med inbyggd router.

De fyra mönster som spelar roll:

• Fallback-kedjor. Billig nivå först, spjutspets vid fel eller timeout. Det enskilt mest värdefulla mönstret; det mesta av din tillförlitlighet kommer bara från det här.
• Lastbalansering. Fördela anrop över duplicerade deploymenter eller API-nycklar för att undvika hastighetsgränser per nyckel.
• Svarscachning. Identiska prompter returnerar cachade svar. Supporttrafik upprepar sig mer än du skulle tro; 10-30% träffrekvens är vanligt.
• Virtuella nycklar och budgetar. Utfärda nycklar per team med månadsgränser så att en skenande loop inte kan bränna ner hela fakturan.

Det här ligger nära konfigurationen vi kör på vår staging-agentstack (fil: litellm-router.yaml, monterad i LiteLLM-proxyns container):

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

Varje verktygs plats, med åsikter:

• LiteLLM. Välj om du vill ha självhostat och open source och redan kör Docker. Vår LiteLLM proxy-installationsguide går igenom hela deploymenten, nycklar och budgetar inkluderat.
• OpenRouter. Välj om du vill ha hundratals modeller bakom en nyckel och noll drift. Deras rankingsida fungerar dubbelt som genomströmningsdata.
• Portkey. Välj om företagskrav (SSO, revisionsloggar, efterlevnadsrapporter) styr beslutet.
• Egen kod från det här inlägget. Välj om du ligger under ~50 000 anrop om dagen och vill ha noll ny infrastruktur.

Oavsett vad du väljer jämför genomgången av LLM-gateway-verktyg tio av dem sida vid sida.

Kan man routa mellan lokala modeller och hostade API:er?

Ja, och tokenkalkylen är förförisk: en lokal modell fakturerar $0 per token, så varje anrop som Ollama eller vLLM svarar på är en ren besparing. Avvägningen är latens och kvalitet per watt. Lokalt vinner för volymrika enkla uppgifter på hårdvara du redan äger; det hostade API:et fångar allt som behöver en spjutspetshjärna.

Mekanismen är antiklimaktisk, och det är poängen. Ollama exponerar en OpenAI-kompatibel endpoint på localhost:11434/v1, och vLLM serverar samma form. Så varje router ovan fungerar oförändrad: peka base_url mot den lokala servern, lägg qwen3:8b i den billiga platsen och behåll gpt-5 som fallback-nivå. För en självhostad routerbox skeppas LiteLLM som en Docker-image, och det är "llm router docker"-upplägget folk söker efter.

Två ärlighetsnoteringar. En 70B-modell på en A100 serverar ungefär 30-40 tokens per sekund; hostade API:er slår det på burstgenomströmning, så lokal routing passar jämn bakgrundstrafik bättre än toppig användarvänd chatt. Och lokala 8B-modeller snubblar på flerstegs verktygsanrop, så håll de svåra rutterna riktade mot molnet. Om du väljer själva serveringsmotorn benchmarkar vLLM vs SGLang de två.

Routing driver också multi-modell-upplägg för kodningsagenter. En LiteLLM-liknande proxy låter Claude Code prata med lokala och hostade modeller via en endpoint; se hur du använder olika modeller i Claude Code för exakt koppling.

Hur vet du om routingen fungerar?

Du mäter den, annars gissar du. Logga vilken modell som svarade på varje anrop, poängsätt ett urval av svaren mot en bedömningsmall och mata tillbaka poängen till routingreglerna. Team som hoppar över det steget hamnar med en statisk konfiguration som tyst ruttnar medan modeller och priser ändras under den.

Examensbanan kör regler, sedan kostnad, sedan uppmätt kvalitet:

1. Logga routen. Spara vald modell, latens och tokenantal per anrop som en kolumn i dina befintliga spår.
2. Poängsätt svar veckovis. En LLM-domare eller ett mänskligt urval, godkänt/underkänt per anropsklass. Femtio betygsatta svar per klass räcker att styra efter.
3. Justera om. Om den billiga nivån klarar 95%+ i en klass, vidga dess regel för att fånga mer av den trafiken. Om den sjunker under 90%, snäva åt.

Här är meningen vi upprepar för kunder: en router du aldrig justerar om är bara en statisk konfiguration med extra latens. Logga vald modell, poängsätt svar, mata tillbaka poängen.

Den loopen är evals plus observerbarhet tillämpat på routing. Vår LLM evals-guide täcker bedömningsmallarna; AI-observerbarhetsguiden täcker var spåren bor.

Vart är forskningen om LLM-routing på väg?

Den akademiska linjen behandlar routing som ett inlärningsproblem, inte en konfigurationsfil. ulab-uiucs LLMRouter, biblioteket som rankas först för det här nyckelordet, implementerar 16+ algoritmer (KNN, SVM, MLP, matrisfaktorisering, Elo, graf, BERT och RL-routrar) med en benchmark-pipeline över 11 dataset. Den mest citerade senaste artikeln, RouteLLM (Ong et al., arXiv:2406.18665), tränar routrar på mänskliga preferensdata och rapporterar över 2x kostnadssänkning utan kvalitetsförlust på MMLU och MT-Bench. Den senaste veckan: prefill-aktiveringsroutrar, "prefill is all you need"-linjen, som läser en modells interna aktiveringar under prefill för att förutsäga svårigheten innan generationen börjar. Färdriktningen är routrar som tränar sig själva från dina eval-data, vilket är exakt feedback-loopen från föregående avsnitt.

Så här tänker Techsy: agentstackarna vi levererar till B2B-kunder kör exakt det här mönstret, en kostnadsnivå-router med fallback-kedjor inkopplade i gatewayen, plus eval-driven omjustering. Om du väger om routing passar din stack, få en kostnadsfri konsultation så kartlägger vi din trafikmix tillsammans.

Vanliga frågor

Vad är en LLM-router?

En LLM-router är ett lager mellan din applikation och flera språkmodeller som avgör vilken modell som hanterar varje anrop. Den kontrollerar anropets uppgiftstyp, storlek eller svårighet och skickar det sedan vidare till den modell som passar bäst, med en fallback om den modellen felar. Tänk dig den som en trafikledare för dina modell-API-anrop.

Hur fungerar LLM-routing?

LLM-routing fungerar i fem steg: anropet anländer, routern inspekterar det (nyckelord, tokenantal eller en embedding), en strategi väljer en modellnivå, anropet vidarebefordras och en fallback-modell fångar eventuella fel. Hela beslutet sker innan generationen börjar, så det lägger på millisekunder, inte sekunder, såvida inte en klassificerarmodell gör poängsättningen.

Är en LLM-router samma sak som en LLM-gateway?

Nej. En gateway är röret: API-nycklar, hastighetsgränser, budgetar och loggar. En router är beslutet: vilken modell som svarar. De är lager, inte rivaler, och de flesta gateways (LiteLLM, Portkey, OpenRouter) har en router inbyggd. Du kan köra en router utan en gateway, men i produktion vill du oftast ha båda tillsammans.

Sparar modellrouting verkligen pengar?

Ja, när det mesta av din trafik kvalificerar sig för en mycket billigare nivå. Vårt räkneexempel flyttar 80% av anropen från en modell för $3/$15 per miljon tokens till en för $0,25/$2 och sänker fakturan med 70,7%. AWS rapporterade upp till 30% för routing inom en modellfamilj. Om din trafik är genomgående komplex krymper besparingen mot noll.

Vilken är den bästa open source-LLM-routern?

För produktion, LiteLLM: självhostad, aktivt underhållen och kombinerar en gateway med en router. För algoritmer på forskningsnivå implementerar ulab-uiucs LLMRouter 16+ routingstrategier från den akademiska litteraturen. RouteLLM är den starkaste kvalitet-per-krona-routern tränad på preferensdata. De flesta team bör börja med LiteLLM och ta till forskningsbiblioteken bara om de behöver anpassad poängsättning.

Hur bygger jag en LLM-router i Python?

Börja med OpenAI-klienten och ungefär 80 rader kod: en regeltabell från nyckelord till modeller, en kostnadströskel på tokenantal, embedding-likhet med exempelprompter eller en billig klassificerarmodell som poängsätter svårigheten. Alla fyra mönstren finns i byggavsnittet ovan, körbara mot OpenAI, Ollama eller vLLM utan ändringar.

Kan jag routa mellan lokala modeller och moln-API:er?

Ja. Ollama (localhost:11434/v1) och vLLM exponerar båda OpenAI-kompatibla endpoints, så samma routerkod pekar mot en lokal modell för billig trafik och ett hostat API för tung trafik. Lokala tokens kostar $0, men du äger hårdvaran och latensen. Det här är mönstret bakom de flesta multi-modell-upplägg för Claude Code.

Vad är semantisk routing?

Semantisk routing embeddar varje inkommande prompt och jämför den mot inbäddade exempelprompter, och skickar anropet till den modell som äger det närmaste exempelklustret. Den hanterar luddiga, parafraserade användarinmatningar som nyckelordsregler missar, till en kostnad av 50-150 ms plus embedding-tokens per anrop. AWS mätte den till 0,10 sekunder tillagd latens.

Hur mycket latens lägger en LLM-klassificerarrouter till?

AWS mätte 0,53 sekunder tillagd latens för LLM-assisterad klassificering, mot 0,10 sekunder för semantisk routing. Regelbaserad och kostnadsmedveten routing lägger på ungefär noll, eftersom de är rena kodvägar. Om din produkt har ett snävt svarstids-SLA, föredra regler, kostnadströsklar eller embeddings och reservera klassificeraren för offline- eller köade arbetslaster.

Källor

• Seifi, N. and 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/ (hämtad 30 juli 2026)
• AWS sample code: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (hämtad 30 juli 2026)
• LiteLLM documentation. https://docs.litellm.ai (hämtad 30 juli 2026)
• Anthropic pricing. https://www.anthropic.com/pricing (hämtad 30 juli 2026)
• OpenAI API pricing. https://openai.com/api/pricing (hämtad 30 juli 2026)
• ulab-uiuc LLMRouter. https://github.com/ulab-uiuc/LLMRouter (hämtad 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 (hämtad 30 juli 2026)
• OpenRouter rankings. https://openrouter.ai/rankings (hämtad 30 juli 2026)