Router LLM: rutează cererile, redu costurile cu 60% [2026]

Router LLM: rutează cererile, redu costurile cu 60% [2026]

Un router LLM este un strat subțire între aplicația ta și mai multe modele de limbaj, care alege ce model procesează fiecare cerere. Inspectează cererea (tip de sarcină, complexitate, buget de tokeni), o trimite către modelul potrivit și face failover către o rezervă dacă acel model dă eroare. Scopul: răspunsuri dimensionate corect, la cel mai mic cost per token.

Să plătești un model de frontieră ca să răspundă la „care e politica de rambursare?" e modul în care facturile explodează. AWS a măsurat alternativa în aprilie 2025: un router cu clasificator adaugă 0,53 secunde de latență, un router semantic adaugă 0,10 secunde și până la 30% reducere din factură pentru rutarea în interiorul unei singure familii de modele. Recalculând cu prețurile de listă din iulie 2026, cum facem mai jos, reducerea ajunge la 70%. Cea mai mare parte din economie vine dintr-o singură decizie, luată înainte să se genereze un singur token.

Concluzii cheie

• Un router LLM decide ce model procesează fiecare cerere, pe baza tipului de sarcină, a costului sau a calității măsurate.
• Există cinci strategii: rutare pe reguli, pe cost, pe latență, semantică (embeddinguri) și pe clasificator LLM.
• Rutarea pe reguli adaugă ~0 ms și 0 $; rutarea pe clasificator adaugă 300-800 ms plus costul tokenilor de clasificare per cerere.
• Rutarea poate reduce cheltuielile cu tokenii cu până la 60% când majoritatea traficului simplu trece pe un model de 10-20x mai ieftin.
• Un singur provider, sub 10k cereri pe zi, fără presiune pe costuri? Sari peste router. Fallbackurile simple sunt suficiente.

Ce face concret un router LLM?

Un router LLM rulează un mic pas de decizie înainte de fiecare apel către model: citește cererea, o evaluează în raport cu o regulă de rutare, alege un model, trimite apelul și reîncearcă pe o rezervă dacă primul model dă eroare. Nimic altceva nu se schimbă în aplicația ta. Faci tot o cerere și primești tot un răspuns.

Ciclul de viață al cererii, în ordine:

1. Cererea ajunge la endpointul routerului, exact cum ar ajunge la un API de model.
2. Analiză. Routerul inspectează promptul: cuvinte cheie, număr de tokeni, un embedding sau un scor de clasificator.
3. Selecție. Strategia de rutare mapează acel semnal la un nivel de model (ieftin, mediu, frontieră sau local).
4. Trimitere. Apelul merge către modelul ales printr-un API compatibil OpenAI.
5. Fallback. La timeout, limită de rată sau eroare, cererea se reîncearcă pe nivelul următor din lanț.

Oamenii caută „llm gateway vs router" pentru că documentația vendorilor estompează termenii. O propoziție rezolvă problema: gateway-ul este conducta; routerul este decizia. Sunt straturi, nu rivale, iar majoritatea gateway-urilor înglobează un router în interior.

Conform documentației LiteLLM, același proxy care îți ține cheile virtuale rulează și routerul. Compari instrumentele la nivel de conductă? Clasamentul nostru cu cele mai bune instrumente LLM gateway ierarhizează zece.

Chiar ai nevoie de un router LLM?

Majoritatea aplicațiilor mici nu au. Un router își merită locul când traficul se împarte în tipuri de sarcini clar diferite, când factura de tokeni e cel mai mare cost de infrastructură sau când rulezi mai mulți provideri și ai nevoie de failover. Sub aceste praguri, reîncercările simple plus un model de rezervă îți cumpără fiabilitatea fără piesa mobilă.

O spunem direct, pentru că nimeni altcineva din spațiul ăsta nu o va face: dacă rulezi un singur provider cu sub 10k cereri pe zi, un router e overhead de care nu ai nevoie. Fallbackurile simple câștigă.

De ce suntem atât de direcți? Fiecare rută e o afirmație („această clasă de sarcini e sigură pe modelul ieftin") care se degradează pe măsură ce modelele, prețurile și produsul tău se schimbă. Cumpără acel cost de mentenanță doar când economiile îl depășesc clar.

Cele 5 strategii de rutare LLM (și când să o folosești pe fiecare)

Fiecare strategie de rutare LLM răspunde la o întrebare: ce semnal e suficient de fiabil ca să alegi un model? Regulile se încred în cuvinte cheie. Rutarea pe cost se încrede în bugetul de tokeni. Rutarea pe latență se încrede într-un cronometru. Rutarea semantică se încrede în embeddinguri. Rutarea pe clasificator se încrede într-un alt LLM. Compromisul are mereu aceeași formă: mai multă calitate a semnalului, mai multă latență și cost adăugat per cerere.

Autocompletarea le afișează ca „strategii rutare llm", „rutare sarcini llm", „rutare intenție llm" și „rutare dinamică llm". Ele se mapează pe cinci tipare:

Un tipar traversează toate cinci: cascada, numită și tiering de modele. Începi ieftin și escalezi doar la eșec sau încredere scăzută. Un bot de suport răspunde de pe un model de 0,25 $ per milion de tokeni; dacă încrederea scade sub 0,7, aceeași cerere se reîncearcă pe un model de frontieră. Plătești pentru inteligență doar când nivelul ieftin recunoaște că e blocat.

Pentru profunzime academică, biblioteca LLMRouter de la ulab-uiuc cataloghează peste 16 algoritmi de rutare cercetați (KNN, SVM, MLP, factorizare matricială, Elo, graf, tip BERT). Dacă rutarea semantică e alegerea ta, embeddingurile exemplar decid aproape totul; ghidul nostru despre cele mai bune modele de embedding acoperă care rezistă pe corpusuri reale.

Cum construiești un router LLM în Python?

Îl construiești cu aproximativ 80 de linii de Python simplu, împotriva oricărui endpoint compatibil OpenAI. Fără framework obligatoriu. Cele patru routere de mai jos escaladează în sofisticare: reguli pe cuvinte cheie, un prag de cost, similaritate embedding și un model clasificator cu fallback. Fiecare afișează modelul ales, ca să poți urmări decizia în timp real.

Dacă ai căutat „cum să construiesc un router llm" și ai găsit doar stackuri AWS CDK și repo-uri academice, această secțiune e răspunsul simplu. Implementarea de referință de la AWS e solidă, dar sudată de Bedrock, Lambda și CDK. A noastră rulează oriunde poate indica clientul OpenAI: OpenAI, Anthropic printr-un proxy, Ollama pe un laptop, vLLM pe un server cu GPU. Iată routerul pe care îl schițăm primul pentru clienți.

Pasul 1: Router pe reguli (cuvinte cheie către modele)

Linia de bază cu latență zero. O hartă regex decide; tot ce nu se potrivește merge la nivelul de frontieră.

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

Intrare: o întrebare de suport. Decizie: potrivire regex pe „cancel". Model ales: gpt-5-mini. Nu e nevoie de niciun apel API pentru rutare, de aceea rămâne opțiunea implicită.

Pasul 2: Router pe cost (prag de buget de tokeni)

Aceeași idee, dar semnalul e dimensiunea cererii în loc de cuvinte cheie. Prompturile scurte cu buget mic de ieșire merg pe ieftin; tot restul pe 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

Brut? Da. Eficient? Tot da, pentru că volumul de tokeni corelează cu dimensiunea sarcinii mai bine decât se așteaptă majoritatea. Aceasta e întreaga strategie din spatele mai multor produse plătite de tip „cheap llm router".

Pasul 3: Router semantic (embeddinguri către exemplare)

Pentru intrare vagă de utilizator care ocolește cuvintele cheie, încorporezi promptul și îl compari cu prompturi exemplar deja încorporate. Clusterul cel mai apropiat preia cererea.

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

Apelul de rutare costă un embedding (câteva sute de tokeni) și 50-150 ms. Precompute centroidele la pornire, nu per cerere.

Pasul 4: Router pe clasificator LLM cu fallback

Cel mai puternic semnal: un model ieftin citește promptul și scorifică dificultatea. Aceasta e strategia pe care AWS a măsurat-o la 0,53 secunde latență adăugată, deci o încadrăm într-un lanț de fallback.

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

Acesta e întregul exemplu de router LLM: patru funcții, un client, nicio infrastructură în plus față de ce rulezi deja. Consolidarea pentru producție e secțiunea următoare.

Cât economisești concret cu rutarea LLM?

AWS a măsurat overhead-ul routerului la 107,90-188,90 $ pe lună per 100.000 de întrebări pe zi, cu rutarea pe clasificator adăugând 0,53 secunde per cerere și rutarea semantică 0,10 secunde. Partea de economii depășește masiv acel overhead. Exemplul nostru calculat mai jos, construit pe prețurile de listă din iulie 2026, ajunge la o reducere de 70,7% a cheltuielilor. Condiția e mixul de trafic: ai nevoie ca majoritatea cererilor să se califice pentru nivelul ieftin.

Două tabele. Primul, cât te costă routerul însuși per 1.000 de cereri:

Postarea AWS din aprilie 2025 e singurul set de măsurători publicat independent în acest spațiu, deci ne ancorăm în el și etichetăm extensiile noastre ca estimări, nu cifre pe care le-am rulat. Bedrock Intelligent Prompt Routing a redus costul în familie cu până la 30%, conform AWS.

Al doilea, exemplul calculat de economii care susține titlul nostru:

Ipoteze, etichetate: 100.000 cereri pe lună; 800 tokeni intrare plus 200 ieșire per cerere în medie; împărțire 80% simplu / 20% complex; prețuri de listă de pe pagina de prețuri Anthropic și pagina de prețuri OpenAI din iulie 2026, cu tabelul complet de tarife în comparația noastră de prețuri API LLM. Calcul per cerere: Sonnet 4 costă 800 x 3 $/M + 200 x 15 $/M = 0,0054 $; GPT-5 mini costă 800 x 0,25 $/M + 200 x 2 $/M = 0,0006 $.

Rezultatul e o reducere de 70,7%, de unde vine cifra de 60% din titlu, cu marjă de rezervă. Avertismente oneste: acesta e un exemplu calculat, nu un benchmark pe care l-am rulat. Presupune că nivelul tău ieftin e de 10-20x mai ieftin și că 80% din trafic se califică genuine. Rutarea în familie, scenariul AWS, rămâne aproape de 30%. Iar rutarea e una dintre mai multe pârghii; cachingul și trunchierea prompturilor se recuperează adesea mai repede, iar ghidul nostru despre cum să reduci costurile API LLM ierarhizează toate cele douăsprezece metode.

Tipare de rutare în producție

Un router de jucărie alege un model. Un router de producție și reîncearcă, echilibrează sarcina, cache-uiește repetițiile și izolează cheile API per echipă. Peste câteva mii de cereri pe zi, nu mai construi manual aceste lucruri și rulezi un gateway care înglobează un router.

Cele patru tipare care contează:

• Lanțuri de fallback. Nivelul ieftin primul, frontieră la eroare sau timeout. Tiparul cu cea mai mare valoare; cea mai mare parte a fiabilității vine doar din asta.
• Echilibrare de sarcină. Distribuie apelurile pe implementări duplicate sau chei API ca să eviți limitele de rată per cheie.
• Cache de răspunsuri. Prompturi identice returnează răspunsuri din cache. Traficul de suport se repetă mai mult decât ai crede; rate de hit de 10-30% sunt obișnuite.
• Chei virtuale și bugete. Emiți chei per echipă cu plafoane lunare, ca o buclă scăpată de sub control să nu ardă toată factura.

Aproape de configurația pe care o rulăm pe stackul nostru de agent de staging (fișier: litellm-router.yaml, montat în containerul proxy LiteLLM):

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

Unde se potrivește fiecare instrument, cu opinii:

• LiteLLM. Alege dacă vrei self-hosted și open source și deja rulezi Docker. Ghidul nostru de configurare LiteLLM proxy parcurge tot deploymentul, chei și bugete incluse.
• OpenRouter. Alege dacă vrei sute de modele în spatele unei singure chei și zero operațiuni. Pagina lor de clasamente servește și ca date de throughput.
• Portkey. Alege dacă cerințele enterprise (SSO, jurnale de audit, rapoarte de conformitate) conduc decizia.
• Cod personalizat din acest articol. Alege dacă ai sub ~50k cereri pe zi și vrei zero infrastructură nouă.

Oricare ar fi alegerea, clasamentul instrumentelor LLM gateway compară zece dintre ele față în față.

Poți ruta între modele locale și API-uri găzduite?

Da, iar calculul tokenilor e seducător: un model local facturează 0 $ per token, deci fiecare cerere pe care Ollama sau vLLM o procesează e economie pură. Compromisul e latența și calitatea per watt. Localul câștigă pentru sarcini simple cu volum mare pe hardware pe care deja îl deții; API-ul găzduit prinde tot ce are nevoie de un creier de frontieră.

Mecanica e anticlimactică, și asta e ideea. Ollama expune un endpoint compatibil OpenAI la localhost:11434/v1, iar vLLM servește aceeași formă. Deci fiecare router de mai sus funcționează neschimbat: indici base_url către serverul local, pui qwen3:8b în slotul ieftin și păstrezi gpt-5 ca nivel de fallback. Pentru o cutie de router self-hosted, LiteLLM vine ca imagine Docker, ceea ce e configurația „llm router docker" pe care oamenii o caută.

Două note de onestitate. Un model de 70B pe un A100 servește aproximativ 30-40 tokeni pe secundă; API-urile găzduite bat asta la throughput de vârf, deci rutarea locală se potrivește mai bine traficului de fundal constant decât chat-ului cu utilizatori cu vârfuri. Iar modelele locale de 8B se încurcă în apeluri de instrumente multi-pas, deci păstrează rutele dificile orientate spre cloud. Dacă alegi motorul de servire în sine, vLLM vs SGLang face benchmark pe ambele.

Rutarea alimentează și configurațiile de agent de programare multi-model. Un proxy de tip LiteLLM lasă Claude Code să vorbească cu modele locale și găzduite printr-un singur endpoint; vezi cum să folosești modele diferite în Claude Code pentru cablajul exact.

Cum știi dacă rutarea funcționează?

O măsori, sau ghicești. Jurnalizezi ce model a răspuns la fiecare cerere, scorifici un eșantion de ieșiri în raport cu o grilă și reintroduci scorurile în regulile de rutare. Echipele care sar peste acest pas ajung cu o configurație statică ce putrezește silențios pe măsură ce modelele și prețurile se schimbă sub ea.

Arcul de absolvire rulează reguli, apoi cost, apoi calitate măsurată:

1. Jurnalizezi ruta. Stochezi modelul ales, latența și numărul de tokeni per cerere ca o coloană în trace-urile existente.
2. Scorifici ieșirile săptămânal. Un judecător LLM sau un eșantion uman, pass/fail per clasă de cereri. Cincizeci de ieșiri evaluate per clasă sunt suficiente ca să te orientezi.
3. Reacordezi. Dacă nivelul ieftin trece de 95%+ pe o clasă, lărgești regula ca să prindă mai mult din acel trafic. Dacă scade sub 90%, îngustezi.

Iată linia pe care o repetăm constant clienților: un router pe care nu îl reacordezi niciodată e doar o configurație statică cu latență în plus. Jurnalizezi modelul ales, scorifici ieșirile, reintroduci scorurile.

Această buclă e evaluări plus observabilitate aplicate rutării. Ghidul nostru de evaluări LLM acoperă grilele de scorificare; ghidul de observabilitate AI acoperă unde locuiesc trace-urile.

Încotro se îndreaptă cercetarea în rutare LLM?

Linia academică tratează rutarea ca o problemă de învățare, nu ca un fișier de configurare. LLMRouter de la ulab-uiuc, biblioteca clasată pe primul loc pentru acest cuvânt cheie, implementează peste 16 algoritmi (KNN, SVM, MLP, factorizare matricială, Elo, graf, BERT și routere RL) cu un pipeline de benchmark pe 11 dataseturi. Cea mai citată lucrare recentă, RouteLLM (Ong et al., arXiv:2406.18665), antrenează routere pe date de preferință umană și raportează peste 2x reducere de cost fără pierdere de calitate pe MMLU și MT-Bench. Cea mai nouă direcție: routere pe activări de prefill, linia „prefill is all you need", care citesc activările interne ale unui model în timpul prefill pentru a prezice dificultatea înainte să înceapă generarea. Direcția de mers e către routere care se antrenează singure din datele tale de evaluare, ceea ce e exact bucla de feedback din secțiunea anterioară.

Cum abordează Techsy asta: stackurile de agent pe care le livrăm clienților B2B rulează exact acest tipar, un router pe niveluri de cost cu lanțuri de fallback conectate în gateway, plus reacordare condusă de evaluări. Dacă evaluezi dacă rutarea se potrivește stackului tău, solicită o consultație gratuită și vom mapa mixul tău de trafic împreună.

Despre autor

Mert Batur este Co-Fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri vocale/SDR pentru clienți B2B. Scrie despre stackul de instrumente LLM pe care echipa Techsy îl folosește efectiv în producție. Conectare pe LinkedIn.

Întrebări frecvente

Ce este un router LLM?

Un router LLM este un strat între aplicația ta și mai multe modele de limbaj, care decide ce model procesează fiecare cerere. Verifică tipul de sarcină, dimensiunea sau dificultatea cererii, apoi o trimite către modelul potrivit, cu un fallback dacă acel model eșuează. Gândește-te la el ca la un controlor de trafic pentru apelurile tale API către modele.

Cum funcționează rutarea LLM?

Rutarea LLM funcționează în cinci pași: cererea ajunge, routerul o inspectează (cuvinte cheie, număr de tokeni sau un embedding), o strategie alege un nivel de model, apelul e trimis și un model de rezervă prinde orice eșec. Întreaga decizie se întâmplă înainte ca generarea să înceapă, deci adaugă milisecunde, nu secunde, cu excepția cazului în care un model clasificator face scorificarea.

Un router LLM e același lucru cu un gateway LLM?

Nu. Un gateway e conducta: chei API, limite de rată, bugete și jurnale. Un router e decizia: ce model răspunde. Sunt straturi, nu rivale, iar majoritatea gateway-urilor (LiteLLM, Portkey, OpenRouter) înglobează un router în interior. Poți rula un router fără gateway, dar în producție de obicei le vrei pe ambele împreună.

Rutarea modelelor economisește efectiv bani?

Da, când majoritatea traficului tău se califică pentru un nivel mult mai ieftin. Exemplul nostru calculat mută 80% din cereri de pe un model de 3 $/15 $ per milion de tokeni pe unul de 0,25 $/2 $ și reduce factura cu 70,7%. AWS a raportat până la 30% pentru rutarea în interiorul unei singure familii de modele. Dacă traficul tău e uniform complex, economia tinde spre zero.

Care e cel mai bun router LLM open-source?

Pentru producție, LiteLLM: self-hosted, întreținut activ și combină un gateway cu un router. Pentru algoritmi de nivel academic, LLMRouter de la ulab-uiuc implementează peste 16 strategii de rutare din literatura academică. RouteLLM e cel mai puternic router calitate-per-dolar antrenat pe date de preferință. Majoritatea echipelor ar trebui să înceapă cu LiteLLM și să apeleze la bibliotecile de cercetare doar dacă au nevoie de scorificare personalizată.

Cum construiesc un router LLM în Python?

Începe cu clientul OpenAI și aproximativ 80 de linii de cod: o hartă de reguli de la cuvinte cheie la modele, un prag de cost pe număr de tokeni, similaritate embedding cu prompturi exemplar sau un model clasificator ieftin care scorifică dificultatea. Toate cele patru tipare sunt în secțiunea de construcție de mai sus, funcționale împotriva OpenAI, Ollama sau vLLM fără modificări.

Pot ruta între modele locale și API-uri cloud?

Da. Ollama (localhost:11434/v1) și vLLM expun ambele endpointuri compatibile OpenAI, deci același cod de router indică către un model local pentru trafic ieftin și un API găzduit pentru trafic dificil. Tokenii locali costă 0 $, dar deții hardware-ul și latența. Acesta e tiparul din spatele majorității configurațiilor Claude Code multi-model.

Ce este rutarea semantică?

Rutarea semantică încorporează fiecare prompt primit și îl compară cu prompturi exemplar încorporate, trimițând cererea către modelul care deține clusterul exemplar cel mai apropiat. Gestionează intrare vagă, parafrazată, pe care regulile pe cuvinte cheie o ratează, la un cost de 50-150 ms plus tokeni embedding per cerere. AWS a măsurat-o la 0,10 secunde latență adăugată.

Câtă latență adaugă un router pe clasificator LLM?

AWS a măsurat 0,53 secunde latență adăugată pentru clasificarea asistată de LLM, față de 0,10 secunde pentru rutarea semantică. Rutarea pe reguli și pe cost adaugă aproximativ zero, pentru că sunt căi de cod pur. Dacă produsul tău are un SLA strict de timp de răspuns, preferă reguli, praguri de cost sau embeddinguri și rezervă clasificatorul pentru sarcini offline sau în coadă.

Surse

• Seifi, N. și 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/ (accesat 30 iulie 2026)
• Cod sursă AWS: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (accesat 30 iulie 2026)
• Documentație LiteLLM. https://docs.litellm.ai (accesat 30 iulie 2026)
• Prețuri Anthropic. https://www.anthropic.com/pricing (accesat 30 iulie 2026)
• Prețuri API OpenAI. https://openai.com/api/pricing (accesat 30 iulie 2026)
• LLMRouter ulab-uiuc. https://github.com/ulab-uiuc/LLMRouter (accesat 30 iulie 2026)
• Ong, I. et al. (2024). „RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (accesat 30 iulie 2026)
• Clasamente OpenRouter. https://openrouter.ai/rankings (accesat 30 iulie 2026)