Toutes vos requêtes n'ont pas besoin du modèle le plus cher. Nous mesurons la qualité par usage, déployons un routeur derrière votre gateway et vérifions par tests A/B que les économies ne dégradent pas les réponses.
La plupart des applications LLM choisissent un modèle une fois pour toutes, souvent le plus performant disponible au moment du développement. Or une grande partie des requêtes, classification, extraction, reformulation ou questions simples, serait traitée correctement par un modèle plus petit, plus rapide et moins cher.
Le routage consiste à décider, requête par requête, quel modèle appeler selon la tâche, la complexité et vos contraintes. Des outils existent pour cela, par exemple le routeur open source de NotDiamond ou RouteLLM, ou de simples règles dans une gateway comme LiteLLM. Nous choisissons l'approche selon votre contexte, sans lien commercial avec ces éditeurs.
Ce qui fait échouer ces projets, c'est rarement le routeur lui-même. C'est l'absence de jeu d'évaluation pour savoir si la qualité tient, l'absence de logs exploitables pour connaître les usages, et une intégration fragile sans fallback. C'est un travail d'infrastructure, de mesure et d'exploitation, le cœur du métier de Keltio.
Estimez les économies d'un routage des requêtes vers le modèle le plus rentable, et l'urgence du sujet.
Estimation indicative à partir de vos réponses et d'hypothèses prudentes, modifiables. Rien n'est enregistré.
Chaque volet peut être engagé seul ou combiné aux autres : nous ajustons le périmètre à votre existant et à votre objectif.
Nous partons de vos logs réels pour identifier où le routage a du sens.
Nous construisons le référentiel qui permet de juger si un modèle moins cher suffit.
Nous installons le routeur dans votre chaîne d'appel, sans réécrire vos applications.
Nous traduisons vos arbitrages métier en règles configurées et testées.
Nous comparons le routeur au modèle unique sur votre trafic réel avant toute généralisation.
d'une mission IA en production relève de l'infra et du DevOps. C'est notre métier depuis 2019.
Nous citons NotDiamond comme exemple parce que son routeur est open source, pas en raison d'un partenariat. Nous retenons l'outil, ou les simples règles de gateway, qui conviennent à votre architecture.
Placé sur le chemin de toutes vos requêtes, le routeur doit être hautement disponible, observable et doté d'un fallback. Nous le déployons en infrastructure as code, comme nous le faisons pour les plateformes cloud depuis 2019.
Jeux d'évaluation, tests A/B et rapport d'impact qualité : vous décidez de généraliser sur la base de vos propres données, pas d'un benchmark public.
Le routage est un levier parmi d'autres, avec le cache de prompts, le batch et le suivi des budgets. Nous vous indiquons s'il est le plus pertinent dans votre cas.
Analyse des logs d'appels et des factures pour cartographier les usages et repérer les candidats au routage.
Constitution des jeux d'évaluation avec vos experts métier et scoring des modèles candidats sur chaque usage prioritaire.
Mise en place du routeur derrière la gateway, règles de routage par usage, fallback et tests de non-régression.
Test A/B sur une partie du trafic, bilan coûts, latences et qualité, puis recommandation go / no-go et extension aux autres usages.
Non. NotDiamond est un exemple d'outil possible, que nous citons parce qu'il propose un routeur open source. Selon votre contexte, nous pouvons aussi utiliser d'autres routeurs comme RouteLLM, ou de simples règles dans une gateway comme LiteLLM.
Chaque usage routé dispose d'un jeu d'évaluation et d'un seuil de qualité défini avec vos métiers. Le routeur est ensuite comparé au modèle unique en test A/B sur votre trafic réel, et la généralisation ne se décide qu'au vu des résultats.
Des logs d'appels LLM ou une gateway, les factures des fournisseurs, des exemples réels de requêtes et des experts métier pour valider les réponses attendues. Le test A/B demande aussi un trafic suffisant sur la période pilote et l'accord des équipes applicatives.
Très peu si vos applications passent déjà par une gateway compatible OpenAI : le routeur s'insère derrière elle. Sinon, la première étape consiste à faire transiter les appels par une gateway, ce qui vous sert aussi pour le suivi des coûts et la gouvernance.
Le routeur que nous déployons tourne en conteneur sur votre infrastructure. Les requêtes ne vont qu'aux modèles que vous avez autorisés, et des règles peuvent réserver certaines données à des modèles européens ou auto-hébergés.
Coût, latence, erreurs, qualité par évals, usage, dérive : la checklist des 6 métriques d'observabilité LLM à suivre avant la montée en charge.
Lire l'article →Savoir ce que coûte l'IA, et qui la consomme
Voir l'offre →Vos modèles open source derrière une gateway unique
Voir l'offre →