Routeur LLM : aiguillez les requêtes, réduisez les coûts de 60 % [2026]

Routeur LLM : aiguillez les requêtes, réduisez les coûts de 60 % [2026]

Un routeur LLM est une couche fine, intercalée entre votre application et plusieurs modèles de langage, qui décide quel modèle traite chaque requête. Il inspecte la requête (type de tâche, complexité, budget de tokens), la transmet au modèle le mieux adapté et bascule sur un modèle de secours si le premier échoue. L'objectif : des réponses calibrées, au coût en tokens le plus bas.

Payer un modèle frontier pour répondre à « quelle est votre politique de remboursement ? », voilà comment les factures explosent. AWS a mesuré l'alternative en avril 2025 : un routeur à classifieur ajoute 0,53 seconde de latence, un routeur sémantique 0,10 seconde, et jusqu'à 30 % d'économie sur la facture pour un routage à l'intérieur d'une même famille de modèles. Refaites le calcul entre fournisseurs avec les prix publics de juillet 2026, comme nous le faisons plus bas, et la réduction atteint 70 %. L'essentiel de l'économie tient à une seule décision, prise avant même qu'un token soit généré.

Ce qu'il faut retenir

• Un routeur LLM décide quel modèle traite chaque requête, selon le type de tâche, le coût ou une qualité mesurée.
• Il existe cinq stratégies : routage par règles, par coût, par latence, sémantique (embeddings) et par classifieur LLM.
• Le routage par règles ajoute ~0 ms et 0 $ ; le routage par classifieur ajoute 300 à 800 ms plus le coût en tokens du classifieur, par requête.
• Le routage peut réduire la dépense en tokens jusqu'à 60 % quand l'essentiel du trafic simple part vers un modèle 10 à 20 fois moins cher.
• Un seul fournisseur, moins de 10 000 requêtes par jour, aucune pression sur les coûts ? Passez votre chemin. De simples fallbacks suffisent.

Que fait concrètement un routeur LLM ?

Un routeur LLM exécute une petite étape de décision avant chaque appel de modèle : lire la requête, l'évaluer au regard d'une règle de routage, choisir un modèle, envoyer l'appel, et retenter sur un modèle de secours si le premier échoue. Rien d'autre ne change dans votre application. Vous envoyez toujours une requête et recevez une réponse.

Le cycle de vie d'une requête, dans l'ordre :

1. La requête arrive sur l'endpoint du routeur, exactement comme sur une API de modèle.
2. Analyse. Le routeur inspecte le prompt : mots-clés, nombre de tokens, embedding ou score de classifieur.
3. Sélection. La stratégie de routage associe ce signal à un niveau de modèle (économique, intermédiaire, frontier ou local).
4. Transmission. L'appel part vers le modèle choisi via une API compatible OpenAI.
5. Fallback. En cas de timeout, de rate limit ou d'erreur, la requête est retentée sur le niveau suivant de la chaîne.

Les gens cherchent « llm gateway vs router » parce que les documentations des éditeurs entretiennent la confusion. Une phrase suffit à trancher : la gateway est le tuyau, le routeur est la décision. Ce sont des couches, pas des rivales, et la plupart des gateways embarquent un routeur.

D'après la documentation de LiteLLM, le même proxy qui héberge vos clés virtuelles exécute aussi le routeur. Vous comparez spécifiquement les outils de niveau tuyau ? Notre comparatif des meilleurs outils de gateway LLM en classe dix.

Avez-vous seulement besoin d'un routeur LLM ?

La plupart des petites applications, non. Un routeur rentabilise sa place quand le trafic se divise en types de tâches nettement distincts, quand la facture de tokens est votre premier poste d'infrastructure, ou quand vous utilisez plusieurs fournisseurs et avez besoin d'un failover. Sous ces seuils, de simples tentatives plus un modèle de secours vous offrent la fiabilité sans la pièce mobile en plus.

Disons-le franchement, parce que personne d'autre ne le dira dans ce domaine : si vous n'utilisez qu'un seul fournisseur sous les 10 000 requêtes par jour, un routeur est une surcouche dont vous n'avez pas besoin. Les fallbacks simples gagnent.

Pourquoi tant de franchise ? Chaque route est une affirmation (« cette classe de tâches tourne sans risque sur le modèle économique ») qui se dégrade à mesure que les modèles, les prix et votre produit changent. N'acceptez ce coût de maintenance que si les économies le dépassent clairement.

Les 5 stratégies de routage LLM (et quand utiliser chacune)

Toute stratégie de routage LLM répond à une seule question : à quel signal faites-vous assez confiance pour choisir un modèle ? Les règles font confiance aux mots-clés. Le routage par coût fait confiance au budget de tokens. Le routage par latence fait confiance à un chronomètre. Le routage sémantique fait confiance aux embeddings. Le routage par classifieur fait confiance à un autre LLM. Le compromis a toujours la même forme : plus de qualité de signal, plus de latence et de coût ajoutés par requête.

L'autocomplétion les fait remonter sous forme de « llm routing strategies », « llm task routing », « llm intent routing » et « llm dynamic routing ». Elles se ramènent à cinq schémas :

Un schéma traverse les cinq : la cascade, aussi appelée model tiering. Commencez économique et ne montez en gamme qu'en cas d'échec ou de confiance faible. Un bot de support répond depuis un modèle à 0,25 $ le million de tokens ; si sa confiance passe sous 0,7, la même requête est retentée sur un modèle frontier. Vous ne payez l'intelligence que lorsque le niveau économique admet qu'il bloque.

Pour la profondeur académique, la bibliothèque LLMRouter d'ulab-uiuc recense plus de 16 algorithmes de routage issus de la recherche (KNN, SVM, MLP, factorisation de matrices, Elo, graphes, et de type BERT). Si vous choisissez le routage sémantique, les embeddings exemplaires décident de presque tout ; notre guide des meilleurs modèles d'embedding détaille ceux qui tiennent la route sur de vrais corpus.

Comment construire un routeur LLM en Python ?

Il vous faut environ 80 lignes de Python simple, face à n'importe quel endpoint compatible OpenAI. Aucun framework requis. Les quatre routeurs ci-dessous montent en sophistication : règles de mots-clés, seuil de coût, similarité d'embeddings, puis modèle classifieur avec failover. Chacun affiche le modèle qu'il a choisi, pour que vous puissiez voir la décision se prendre.

Si vous avez cherché « how to build an llm router » et n'avez trouvé que des stacks AWS CDK et des dépôts académiques, cette section est la réponse simple. L'implémentation de référence d'AWS est solide, mais soudée à Bedrock, Lambda et CDK. La nôtre tourne partout où le client OpenAI pointe : OpenAI, Anthropic via un proxy, Ollama sur un laptop, vLLM sur une machine GPU. Voici le routeur que nous esquissons d'abord pour nos clients.

Étape 1 : routeur par règles (des mots-clés aux modèles)

La référence zéro latence. Une table de regex décide ; tout ce qui ne correspond à rien part vers le niveau 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))

Entrée : une question de support. Décision : correspondance regex sur « cancel ». Modèle choisi : gpt-5-mini. Aucun appel API n'est nécessaire pour le router, c'est pourquoi cela reste le choix par défaut.

Étape 2 : routeur par coût (seuil de budget de tokens)

Même idée, mais le signal est la taille de la requête plutôt que les mots-clés. Les prompts courts avec un petit budget de sortie partent sur l'économique ; tout le reste va au 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

Rudimentaire ? Oui. Efficace ? Oui aussi, car le volume de tokens corrèle avec la taille de la tâche mieux que la plupart des gens ne l'imaginent. C'est toute la stratégie derrière plusieurs produits payants de « cheap llm router ».

Étape 3 : routeur sémantique (des embeddings aux exemplaires)

Pour les entrées utilisateur floues qui esquivent les mots-clés, calculez l'embedding du prompt et comparez-le à ceux de prompts exemplaires. Le cluster le plus proche remporte la requête.

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

L'appel de routage coûte un embedding (quelques centaines de tokens) et 50 à 150 ms. Précalculez les centroïdes au démarrage, pas à chaque requête.

Étape 4 : routeur à classifieur LLM avec fallback

Le signal le plus fort : un modèle économique lit le prompt et note sa difficulté. C'est la stratégie qu'AWS a mesurée à 0,53 seconde de latence ajoutée, nous l'enveloppons donc dans une chaîne 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

Voilà tout l'exemple de routeur LLM : quatre fonctions, un client, aucune infrastructure au-delà de ce que vous faites déjà tourner. Le durcissement pour la production, c'est la section suivante.

Combien le routage LLM fait-il vraiment économiser ?

AWS a mesuré le surcoût du routeur entre 107,90 $ et 188,90 $ par mois pour 100 000 questions par jour, le routage par classifieur ajoutant 0,53 seconde par requête et le routage sémantique 0,10 seconde. Le côté économies écrase ce surcoût. Notre exemple chiffré ci-dessous, bâti sur les prix publics de juillet 2026, aboutit à une réduction de dépense de 70,7 %. Le piège, c'est la composition du trafic : il faut que la majorité des requêtes soient éligibles au niveau économique.

Deux tableaux. D'abord, ce que le routeur lui-même vous coûte pour 1 000 requêtes :

Le billet d'AWS d'avril 2025 est le seul jeu de mesures publié de façon indépendante dans ce domaine, nous nous y ancrons donc et qualifions nos extensions d'estimations, pas de chiffres que nous avons mesurés. Selon AWS, Bedrock Intelligent Prompt Routing réduit le coût intra-famille jusqu'à 30 %.

Ensuite, l'exemple chiffré qui étaye notre titre :

Hypothèses, étiquetées : 100 000 requêtes par mois ; 800 tokens d'entrée plus 200 de sortie par requête en moyenne ; une répartition 80 % simple / 20 % complexe ; les prix publics de la page de tarifs d'Anthropic et de la page de tarifs d'OpenAI en juillet 2026, avec la table complète des tarifs dans notre comparaison des prix d'API LLM. Calcul par requête : Sonnet 4 coûte 800 x 3 $/M + 200 x 15 $/M = 0,0054 $ ; GPT-5 mini coûte 800 x 0,25 $/M + 200 x 2 $/M = 0,0006 $.

Le résultat est une réduction de 70,7 %, d'où vient le 60 % de notre titre, avec de la marge. Avertissements honnêtes : c'est un exemple chiffré, pas un benchmark que nous avons mené. Il suppose que votre niveau économique est 10 à 20 fois moins cher et que 80 % du trafic est réellement éligible. Le routage intra-famille, le scénario d'AWS, reste proche de 30 %. Et le routage n'est qu'un levier parmi d'autres ; le caching et l'élagage de prompts sont souvent plus vite rentabilisés, et notre guide des méthodes pour réduire les coûts d'API LLM les classe toutes les douze.

Les schémas de routage en production

Un routeur jouet choisit un modèle. Un routeur de production retente aussi, équilibre la charge, met en cache les répétitions et isole les clés API par équipe. Au-delà de quelques milliers de requêtes par jour, cessez de les fabriquer à la main et faites tourner une gateway qui embarque un routeur.

Les quatre schémas qui comptent :

• Chaînes de fallback. Niveau économique d'abord, frontier en cas d'erreur ou de timeout. Le schéma à plus forte valeur à lui seul ; l'essentiel de votre fiabilité vient de là.
• Équilibrage de charge. Répartissez les appels entre des déploiements ou des clés API en double pour éviter les rate limits par clé.
• Cache de réponses. Des prompts identiques renvoient des réponses en cache. Le trafic de support se répète plus que vous ne le croyez ; des taux de hit de 10 à 30 % sont courants.
• Clés virtuelles et budgets. Émettez des clés par équipe avec des plafonds mensuels pour qu'une boucle emballée ne puisse pas brûler toute la facture.

Voici, à peu de chose près, la config que nous faisons tourner sur notre stack d'agents de staging (fichier : litellm-router.yaml, monté dans le conteneur du 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

Où se place chaque outil, avec nos avis :

• LiteLLM. Choisissez-le si vous voulez de l'auto-hébergé et de l'open source et que vous faites déjà tourner Docker. Notre guide de configuration du proxy LiteLLM couvre le déploiement complet, clés et budgets inclus.
• OpenRouter. Choisissez-le si vous voulez des centaines de modèles derrière une seule clé et zéro opération. Leur page de classements sert aussi de donnée de débit.
• Portkey. Choisissez-le si les exigences d'entreprise (SSO, journaux d'audit, rapports de conformité) dictent la décision.
• Le code maison de cet article. Choisissez-le si vous êtes sous ~50 000 requêtes par jour et voulez zéro nouvelle infrastructure.

Quel que soit votre choix, le comparatif des outils de gateway LLM en confronte dix face à face.

Peut-on router entre modèles locaux et API hébergées ?

Oui, et le calcul en tokens est séduisant : un modèle local facture 0 $ par token, donc chaque requête à laquelle Ollama ou vLLM répond est une économie pure. Le compromis, c'est la latence et la qualité par watt. Le local gagne pour les tâches simples à gros volume sur du matériel que vous possédez déjà ; l'API hébergée rattrape tout ce qui exige un cerveau frontier.

La mécanique est décevante de simplicité, et c'est le but. Ollama expose un endpoint compatible OpenAI sur localhost:11434/v1, et vLLM sert la même forme. Donc tous les routeurs ci-dessus fonctionnent sans modification : pointez base_url vers le serveur local, mettez qwen3:8b dans le créneau économique et gardez gpt-5 comme niveau de fallback. Pour une machine de routage auto-hébergée, LiteLLM est livré en image Docker, c'est la configuration « llm router docker » que les gens cherchent.

Deux notes d'honnêteté. Un modèle 70B sur une seule A100 sert environ 30 à 40 tokens par seconde ; les API hébergées font mieux en débit de pointe, le routage local convient donc mieux à un trafic de fond régulier qu'à un chat utilisateur en pics. Et les modèles locaux de 8B trébuchent sur les appels d'outils multi-étapes, gardez donc les routes difficiles orientées vers le cloud. Si vous choisissez le moteur de serving lui-même, vLLM vs SGLang benchmarke les deux.

Le routage alimente aussi les configurations d'agents de code multi-modèles. Un proxy de type LiteLLM permet à Claude Code de parler à des modèles locaux et hébergés via un seul endpoint ; voyez comment utiliser différents modèles dans Claude Code pour le câblage exact.

Comment savoir si le routage fonctionne ?

Vous le mesurez, ou vous devinez. Journalisez quel modèle a répondu à chaque requête, notez un échantillon de sorties contre une grille, et réinjectez les notes dans les règles de routage. Les équipes qui sautent cette étape se retrouvent avec une config statique qui pourrit silencieusement à mesure que les modèles et les prix changent sous elle.

La progression type enchaîne règles, puis coût, puis qualité mesurée :

1. Journalisez la route. Stockez le modèle choisi, la latence et les compteurs de tokens par requête dans une colonne de vos traces existantes.
2. Notez les sorties chaque semaine. Un juge LLM ou un échantillon humain, réussite/échec par classe de requêtes. Cinquante sorties notées par classe suffisent pour piloter.
3. Réajustez. Si le niveau économique passe 95 %+ sur une classe, élargissez sa règle pour capter plus de ce trafic. S'il passe sous 90 %, resserrez.

Voici la phrase que nous répétons sans cesse à nos clients : un routeur que vous ne réajustez jamais n'est qu'une config statique avec de la latence en plus. Journalisez le modèle choisi, notez les sorties, réinjectez les notes.

Cette boucle, ce sont les evals plus l'observabilité appliquées au routage. Notre guide des evals LLM couvre les grilles de notation ; le guide d'observabilité IA couvre l'endroit où vivent les traces.

Où va la recherche sur le routage LLM ?

La ligne académique traite le routage comme un problème d'apprentissage, pas comme un fichier de config. LLMRouter d'ulab-uiuc, la bibliothèque qui se classe première sur ce mot-clé, implémente plus de 16 algorithmes (KNN, SVM, MLP, factorisation de matrices, Elo, graphes, BERT et routeurs par RL) avec un pipeline de benchmark sur 11 jeux de données. L'article récent le plus cité, RouteLLM (Ong et al., arXiv:2406.18665), entraîne des routeurs sur des données de préférences humaines et rapporte une réduction de coût de plus de 2x sans perte de qualité sur MMLU et MT-Bench. La nouveauté la plus récente : les routeurs à activations de prefill, la ligne « prefill is all you need », qui lisent les activations internes d'un modèle pendant le prefill pour prédire la difficulté avant que la génération ne démarre. La direction est celle de routeurs qui s'entraînent eux-mêmes à partir de vos données d'eval, ce qui est exactement la boucle de feedback de la section précédente.

Comment Techsy aborde le sujet : les stacks d'agents que nous livrons à nos clients B2B suivent exactement ce schéma, un routeur par niveaux de coût avec des chaînes de fallback câblées dans la gateway, plus un réajustement piloté par les evals. Si vous vous demandez si le routage convient à votre stack, demandez une consultation gratuite et nous cartographierons votre mix de trafic avec vous.

Questions fréquemment posées

Qu'est-ce qu'un routeur LLM ?

Un routeur LLM est une couche, entre votre application et plusieurs modèles de langage, qui décide quel modèle traite chaque requête. Il vérifie le type de tâche, la taille ou la difficulté de la requête, puis la transmet au modèle le mieux adapté, avec un fallback si ce modèle échoue. Voyez-le comme un contrôleur aérien pour vos appels d'API de modèles.

Comment fonctionne le routage LLM ?

Le routage LLM fonctionne en cinq étapes : la requête arrive, le routeur l'inspecte (mots-clés, nombre de tokens ou embedding), une stratégie choisit un niveau de modèle, l'appel est transmis, et un modèle de fallback rattrape tout échec. Toute la décision se prend avant le début de la génération, elle ajoute donc des millisecondes, pas des secondes, sauf si un modèle classifieur fait la notation.

Un routeur LLM est-il la même chose qu'une gateway LLM ?

Non. Une gateway est le tuyau : clés API, rate limits, budgets et journaux. Un routeur est la décision : quel modèle répond. Ce sont des couches, pas des rivales, et la plupart des gateways (LiteLLM, Portkey, OpenRouter) embarquent un routeur. Vous pouvez faire tourner un routeur sans gateway, mais en production vous voulez en général les deux ensemble.

Le routage de modèles fait-il vraiment économiser de l'argent ?

Oui, quand la majorité de votre trafic est éligible à un niveau nettement moins cher. Notre exemple chiffré déplace 80 % des requêtes d'un modèle à 3 $/15 $ par million de tokens vers un modèle à 0,25 $/2 $ et réduit la facture de 70,7 %. AWS a rapporté jusqu'à 30 % pour un routage à l'intérieur d'une même famille de modèles. Si votre trafic est uniformément complexe, l'économie tend vers zéro.

Quel est le meilleur routeur LLM open source ?

Pour la production, LiteLLM : auto-hébergé, activement maintenu, et il combine une gateway avec un routeur. Pour des algorithmes de niveau recherche, LLMRouter d'ulab-uiuc implémente plus de 16 stratégies de routage issues de la littérature académique. RouteLLM est le routeur au meilleur rapport qualité-prix entraîné sur des données de préférences. La plupart des équipes devraient commencer par LiteLLM et ne se tourner vers les bibliothèques de recherche que si elles ont besoin d'une notation sur mesure.

Comment construire un routeur LLM en Python ?

Partez du client OpenAI et d'environ 80 lignes de code : une table de règles des mots-clés vers les modèles, un seuil de coût sur le nombre de tokens, une similarité d'embeddings avec des prompts exemplaires, ou un modèle classifieur économique qui note la difficulté. Les quatre schémas figurent dans la section de construction ci-dessus, exécutables sans modification contre OpenAI, Ollama ou vLLM.

Peut-on router entre modèles locaux et API cloud ?

Oui. Ollama (localhost:11434/v1) et vLLM exposent tous deux des endpoints compatibles OpenAI, le même code de routeur pointe donc vers un modèle local pour le trafic économique et vers une API hébergée pour le trafic difficile. Les tokens locaux coûtent 0 $, mais le matériel et la latence sont à votre charge. C'est le schéma derrière la plupart des configurations multi-modèles de Claude Code.

Qu'est-ce que le routage sémantique ?

Le routage sémantique calcule l'embedding de chaque prompt entrant et le compare à ceux de prompts exemplaires, en envoyant la requête au modèle qui possède le cluster exemplaire le plus proche. Il gère les entrées utilisateur floues et reformulées que les règles de mots-clés manquent, au prix de 50 à 150 ms plus des tokens d'embedding par requête. AWS l'a mesuré à 0,10 seconde de latence ajoutée.

Quelle latence un routeur à classifieur LLM ajoute-t-il ?

AWS a mesuré 0,53 seconde de latence ajoutée pour une classification assistée par LLM, contre 0,10 seconde pour le routage sémantique. Le routage par règles et par coût ajoute environ zéro, car ce sont de simples chemins de code. Si votre produit a un SLA de temps de réponse serré, préférez les règles, les seuils de coût ou les embeddings, et réservez le classifieur aux charges hors ligne ou en file d'attente.

Sources

• Seifi, N. et 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/ (consulté le 30 juillet 2026)
• Code d'exemple AWS : sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (consulté le 30 juillet 2026)
• Documentation LiteLLM. https://docs.litellm.ai (consulté le 30 juillet 2026)
• Tarifs Anthropic. https://www.anthropic.com/pricing (consulté le 30 juillet 2026)
• Tarifs de l'API OpenAI. https://openai.com/api/pricing (consulté le 30 juillet 2026)
• LLMRouter d'ulab-uiuc. https://github.com/ulab-uiuc/LLMRouter (consulté le 30 juillet 2026)
• Ong, I. et al. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (consulté le 30 juillet 2026)
• Classements OpenRouter. https://openrouter.ai/rankings (consulté le 30 juillet 2026)