Comment réduire les coûts des API LLM de 82 % grâce au Smart Routing

La plupart des équipes envoient toutes leurs requêtes vers le même modèle premium, quel que soit leur niveau de complexité. À mesure que le trafic augmente, cette approche fait rapidement grimper les coûts des API LLM, alors qu’une grande partie des prompts pourrait être traitée efficacement par des modèles moins coûteux.

Notre benchmark le démontre : le Smart Routing a réduit les coûts des API LLM de 82 % par rapport à GPT-5.1, avec une baisse de la qualité moyenne limitée à 0,08 point.

Pour obtenir ces résultats, nous avons comparé trois stratégies de routage sur cinq types de tâches. Chaque tâche a été exécutée trois fois, puis les résultats ont été moyennés afin de garantir une comparaison plus fiable des coûts et de la qualité.

Pourquoi utiliser un seul modèle pour toutes les requêtes augmente les coûts des API LLM

Vos coûts liés aux LLM n’augmentent probablement pas parce que chaque requête est complexe. Ils augmentent parce que votre application traite toutes les requêtes comme si elles l’étaient.

Dans la plupart des systèmes en production, tous les prompts sont envoyés vers le même modèle premium. Une requête comme « Liste trois frameworks Python » est ainsi traitée par le même modèle qu’une demande telle que « Conçois l’architecture de base de données d’un SaaS multi-tenant ».

La première tâche nécessite seulement des connaissances générales et quelques tokens de sortie. La seconde exige davantage de raisonnement, un contexte plus riche et une meilleure capacité à suivre des instructions complexes. Pourtant, les deux requêtes sont facturées selon les mêmes tarifs du modèle premium.

Cette approche crée un problème d’efficacité souvent invisible. Les requêtes simples représentent généralement une part importante du trafic en production. De faibles dépenses inutiles finissent donc par s’accumuler sur des milliers, voire des millions d’appels API.

Les prompts plus longs, l’augmentation de la taille des historiques de conversation, les nouvelles tentatives après un échec et les réponses trop détaillées creusent encore davantage cet écart de coûts.

Un modèle premium peut produire d’excellents résultats. Cela ne signifie pas pour autant que toutes ses capacités sont nécessaires pour chaque tâche. L’utiliser par défaut revient à déployer votre serveur le plus puissant pour chaque charge de travail, y compris les plus simples.

La solution ne consiste pas à sacrifier la qualité en remplaçant systématiquement les modèles premium par des modèles moins chers. Elle consiste à router chaque requête vers le modèle le moins coûteux capable de la traiter de manière fiable. C’est sur ce principe que repose le Smart Routing des LLM.

Comment le Smart Routing sélectionne le bon modèle LLM

Le Smart Routing ajoute une couche de décision entre votre application et l’API du modèle. Avant que la requête ne soit envoyée à un LLM, un classificateur analyse le prompt afin d’en estimer le niveau de difficulté.

Cette analyse peut s’appuyer sur plusieurs critères :

• le type de tâche ;
• le niveau de raisonnement requis ;
• la longueur du contexte ;
• les contraintes de formatage ;
• la complexité attendue de la réponse.

En pratique, le processus de routage intelligent reste simple :

Prompt → Classification de la complexité → Sélection du modèle → Réponse

Le Smart Routing ne sélectionne pas automatiquement un modèle parmi tous les LLM disponibles sur le marché. Votre équipe définit en amont un ensemble de modèles candidats ainsi que les conditions dans lesquelles chacun peut être utilisé.

Cette configuration peut notamment inclure :

• les modèles et fournisseurs autorisés ;
• les limites de prix ;
• les seuils de capacité requis ;
• les règles de fallback.

Vous gardez ainsi le contrôle sur les modèles pouvant être sélectionnés, les coûts maximums autorisés et les critères de routage appliqués à chaque requête.

Il est également possible de configurer des mécanismes de fallback. Lorsqu’un fournisseur rencontre une erreur, atteint une limite de requêtes ou que le niveau de confiance de la classification est insuffisant, la requête peut être automatiquement redirigée vers un modèle de secours.

Benchmark : GPT-5.1 vs Gemini Flash vs Smart Routing

Nous avons comparé trois stratégies d’utilisation des LLM sur cinq types de tâches :

• GPT-5.1 utilisé seul ;
• Gemini 2.0 Flash utilisé seul ;
• le Smart Routing, basé sur un classificateur de complexité à plusieurs niveaux.

Chaque tâche a été exécutée trois fois, puis les résultats ont été moyennés afin de comparer plus fiablement les coûts, la qualité et la latence.

Paramètres du benchmark : Les tests ont été réalisés avec la température par défaut de chaque modèle, sans prompt système et avec une limite définie à max_tokens = 600. Le temps de réponse mesuré correspondait à la latence de bout en bout. Il incluait donc le traitement de la requête par le modèle ainsi que l’éventuelle surcharge liée au routage via Eden AI.

Avant chaque appel, un classificateur par mots-clés exécuté côté client catégorisait le prompt comme simple ou complexe.

Les tâches simples étaient envoyées vers GPT-4.1-nano, tandis que la génération de code, l’analyse, la conception de schémas, les prompts longs et les autres tâches complexes étaient routés vers GPT-4.1-mini. Comme le classificateur fonctionnait directement côté client, il n’ajoutait aucune latence de routage.

Le routeur pouvait sélectionner dix modèles répartis entre deux niveaux de capacité, notamment des modèles GPT, Claude et Mistral. Durant ce benchmark, seuls GPT-4.1-nano et GPT-4.1-mini ont été retenus. Les autres modèles restaient néanmoins disponibles comme solutions de fallback.

Limites du benchmark :

Ce test interne portait sur un nombre limité de tâches. Il ne doit donc pas être considéré comme une évaluation universelle des performances des différents modèles LLM.

Une classification fondée sur des mots-clés peut également mal catégoriser certains cas particuliers. Un ensemble de tâches plus large et plus diversifié permettrait d’obtenir une vision plus représentative de la sélection des modèles, des coûts, de la qualité et de la latence.

Résultats des coûts : GPT-5.1 vs Gemini Flash vs Smart Routing

À l’échelle de la production, même une faible différence de coût par requête peut rapidement devenir significative. D’après les moyennes observées pendant le benchmark, un volume de 10 000 requêtes par jour représenterait un coût mensuel d’environ :

• 662 $ avec GPT-5.1 ;
• 116 $ avec le Smart Routing.

Avec 50 000 requêtes par jour, le coût mensuel estimé atteindrait :

• 3 309 $ avec GPT-5.1 ;
• 581 $ avec le Smart Routing.

Ces estimations reposent sur 30 jours de trafic et sur un coût moyen de 0,002206 $ par requête avec GPT-5.1, contre 0,000387 $ avec le Smart Routing. Le Smart Routing permet ainsi d’obtenir un coût par requête inférieur de 82 %, en sélectionnant un modèle adapté à la complexité réelle de chaque tâche plutôt qu’en utilisant systématiquement un modèle premium.

Résultats sur le temps de réponse et la latence : GPT-5.1 vs Gemini Flash vs Smart Routing

Résultats sur la qualité des réponses : GPT-5.1 vs Gemini Flash vs Smart Routing

Quelle stratégie LLM choisir selon votre charge de travail ?

La stratégie la plus adaptée dépend moins du volume total de requêtes que de la variation de leur niveau de complexité.

Pour une charge de travail mixte, composée de requêtes simples et complexes, le Smart Routing est généralement la meilleure option. Il dirige les prompts peu complexes vers des modèles moins coûteux et réserve les modèles premium aux tâches qui nécessitent un raisonnement plus avancé.

Dans notre benchmark interne, cette approche a permis de réduire les coûts de 82 % par rapport à l’utilisation systématique de GPT-5.1, tout en maintenant l’écart de qualité moyenne sous les 0,1 point.

Pour les charges de travail à fort volume constituées uniquement de tâches simples, il est préférable de router directement les requêtes vers un modèle économique, comme Gemini Flash. Lorsque le type de tâche est prévisible et que le modèle moins coûteux respecte systématiquement votre seuil de qualité, l’ajout d’un classificateur de complexité entraîne des coûts et une complexité opérationnelle inutiles.

Pour les charges de travail composées exclusivement de tâches complexes, utilisez directement un modèle premium. Lorsque presque toutes les requêtes nécessitent un raisonnement avancé, de la génération de code ou un respect strict des instructions, le routeur sélectionnera de toute façon le modèle premium dans la majorité des cas. Dans cette situation, l’étape de classification devient un coût supplémentaire sans générer d’économies significatives.

Si la qualité est votre seule priorité et que le coût ne constitue pas une contrainte, vous pouvez envoyer toutes vos requêtes à GPT-5.1. Ce modèle a obtenu le meilleur score moyen de notre benchmark. Toutefois, l’écart reste faible : GPT-5.1 n’a obtenu que 0,08 point de plus que le Smart Routing, pour un coût 5,7 fois supérieur.

Comment mettre en place le Smart Routing avec Eden AI

Définissez le paramètre model sur @edenai pour activer la couche de routage intelligent d’Eden AI, au lieu de sélectionner directement un modèle spécifique. Le paramètre router_candidates permet de définir précisément la liste des modèles que le routeur est autorisé à analyser et à sélectionner pour chaque requête.

import requests

response = requests.post(
    "https://api.edenai.run/v2/llm/chat/completions",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={
        "model": "@edenai",
        "router_candidates": [
            "openai/gpt-4.1-nano",
            "openai/gpt-4.1-mini",
            "google/gemini-2.0-flash"
        ],
        "messages": [
            {"role": "user", "content": "Your prompt here"}
        ],
        "max_tokens": 600
    }
)

data = response.json()
print("Model selected:", data.get("model"))
print("Response:", data["choices"][0]["message"]["content"])

‍

Votre application continue d’appeler un seul endpoint de chat completion. Eden AI analyse le prompt, sélectionne le modèle le plus adapté parmi les candidats configurés, puis renvoie le modèle choisi dans la réponse, avec le contenu généré.

Vous pouvez ainsi modifier la liste des modèles disponibles pour le routage sans changer le reste de la structure de votre requête.

Trois leviers supplémentaires pour réduire les coûts des LLM

Le Smart Routing constitue généralement le principal levier d’optimisation, car il adapte la puissance du modèle à la complexité réelle de chaque requête. Une fois le routage intelligent mis en place, trois techniques complémentaires permettent de réduire davantage les coûts des API LLM : la mise en cache des prompts, les fallbacks entre fournisseurs et le traitement par lots.

Mise en cache des prompts

La mise en cache des prompts est particulièrement efficace lorsque de nombreuses requêtes contiennent un même bloc d’entrée volumineux. Il peut s’agir d’un prompt système, d’une documentation produit, d’un manuel de procédures, du début d’une longue conversation ou d’un ensemble d’instructions fixes.

Prenons l’exemple d’un assistant de support qui inclut la même base de connaissances de 8 000 tokens dans chaque requête. Sans cache, le fournisseur traite et facture ces tokens à chaque appel. Avec la mise en cache, ce préfixe répétitif peut être réutilisé et facturé à un tarif inférieur. Selon le fournisseur et la nature de la charge de travail, le coût des entrées éligibles mises en cache peut diminuer de 50 à 90 %.

Pour améliorer le taux d’utilisation du cache, placez le contenu stable au début du prompt et les données variables de l’utilisateur à la fin. Les fournisseurs mettent généralement en cache les préfixes identiques. Une petite modification au début du prompt peut donc empêcher la réutilisation du cache.

Surveillez notamment le taux de cache hit, la durée d’expiration, le nombre minimum de tokens requis et les éventuels frais liés à l’écriture du cache. Cette technique est surtout rentable lorsque les prompts restent stables sur un grand nombre de requêtes.

Fallbacks entre fournisseurs

Les fallbacks entre fournisseurs protègent l’expérience utilisateur lorsque le modèle principal est indisponible, trop lent ou soumis à une limitation de débit. Au lieu de renvoyer une erreur, l’application redirige automatiquement la requête vers un modèle de secours.

Prenons le cas d’un workflow d’extraction de documents utilisant un fournisseur principal. Lorsque celui-ci dépasse le délai d’attente, relancer plusieurs fois la même requête augmente la latence et peut générer des appels supplémentaires facturables. Un fallback permet de rediriger la requête vers un autre modèle compatible et de terminer le traitement sans obliger l’utilisateur à soumettre à nouveau son document.

L’économie provient principalement de la réduction des tentatives inutiles et des workflows interrompus. Les fallbacks rendent également les dépenses plus prévisibles, car chaque erreur suit un scénario de récupération défini.

Choisissez des modèles de secours disposant de limites de contexte, de formats de sortie et de capacités de génération structurée compatibles. Définissez précisément les délais d’attente et le nombre de nouvelles tentatives autorisées. Évitez également de changer de fournisseur après une simple variation ponctuelle de latence.

Il est important de suivre la fréquence d’activation des fallbacks, le fournisseur qui termine réellement la requête et la capacité du modèle de secours à respecter le niveau de qualité attendu.

API batch et traitement par lots

Les API batch sont conçues pour les traitements dont le résultat n’est pas nécessaire immédiatement. Elles conviennent notamment au traitement de documents, à l’enrichissement de données CRM, à la classification de tickets de support, aux évaluations de modèles, à la génération de rapports et aux mises à jour massives de données.

Au lieu d’envoyer chaque requête individuellement vers une API en temps réel, l’application les regroupe dans un traitement asynchrone. Le fournisseur exécute ensuite le lot dans un délai plus long, en appliquant un tarif inférieur. OpenAI et Anthropic proposent une réduction de 50 % sur les requêtes batch éligibles.

Une approche efficace consiste à conserver les interactions visibles par l’utilisateur sur des endpoints en temps réel, tout en transférant les traitements en arrière-plan vers une API batch. Par exemple, un utilisateur peut importer des documents pendant la journée, tandis que leur extraction et leur classification sont exécutées pendant la nuit.

Avant l’implémentation, vérifiez la taille maximale des lots, les formats de fichiers acceptés, les délais de traitement et la durée de conservation des résultats. Attribuez également un identifiant unique à chaque requête afin de pouvoir associer correctement chaque résultat à son entrée d’origine.

Enfin, prévoyez une gestion des échecs partiels afin d’éviter de relancer l’intégralité d’un lot lorsqu’une seule requête échoue.

FAQ : réduire les coûts des API LLM de 82 % grâce au Smart Routing