Routeur d’inférence : le modèle parfait pour chaque requête IA

Temps de lecture : 12 min

Le problème : un modèle uniforme pour toutes les tâches

Concrètement, la plupart des équipes qui construisent avec des LLM aujourd’hui font un choix unique de modèle et l’appliquent de manière uniforme à chaque requête. Elles choisissent un modèle « frontier » non pas parce que chaque tâche l’exige, mais parce que construire l’infrastructure pour faire plus intelligent est coûteux, chronophage et facile à mal faire. Quand les outils ne sont pas là, le chemin de moindre résistance est d’utiliser un seul modèle, même si cela signifie que vous payez trop cher pour la plupart des tâches.

Prenons un exemple. Si vous êtes développeur et que vous utilisez Cursor, Claude Code, Open Code ou tout autre agent de codage, vous avez déjà ressenti cela. Au cours d’une même session, votre agent analyse profondément la base de code, écrit de nouvelles fonctions, corrige des bugs à partir des résultats de tests, explique des méthodes, recherche dans la documentation. Ces tâches ne sont pas équivalentes, mais si vous avez un seul modèle en dur, vous payez le tarif « frontier » pour toutes, y compris celles qui n’en ont pas besoin. Les enjeux sont encore plus élevés dans les workflows agentiques et les systèmes multi-agents. Quand plusieurs agents s’exécutent en parallèle, chacun planifiant, exécutant et évaluant des tâches à long horizon, le coût de la sélection uniforme du modèle se cumule à chaque étape. De plus, les grands fournisseurs d’IA évoluent vers une facturation basée sur les tokens et des limites de débit plus strictes. Les coûts d’inférence vont augmenter.

L’alternative est d’implémenter une logique de routage codée en dur dans la couche application avec un classificateur d’intention à l’aide d’un LLM, ce qui ajoute à vos coûts et devient rapidement fragile. Même si vous utilisez un petit modèle comme Haiku pour réduire les coûts, vous payez maintenant un appel de routage en plus de chaque appel d’inférence. De plus, la précision diminue car le modèle n’est pas conçu pour le routage, et à mesure que vos types de tâches évoluent ou que les modèles changent, la logique se brise de manière difficile à détecter. Vous introduisez une double taxation : le coût du classificateur plus le coût de la maintenance du code de routage fragile qui doit être mis à jour à chaque changement de votre pile. Vous avez transformé la sélection de modèle en une fonctionnalité que vous possédez et maintenez, ce qui n’est pas souhaitable pour un développeur. Ce qui passe à l’échelle, c’est le routage au niveau de l’infrastructure, en faisant correspondre chaque requête au bon modèle automatiquement, en fonction de ce que la tâche exige réellement, en tenant compte des priorités comme le coût et la latence, sans mettre cette logique dans votre code.

La solution : le routeur d’inférence DigitalOcean

C’est pourquoi nous avons construit le routeur d’inférence DigitalOcean. Il lit chaque requête, comprend la tâche à partir du contexte de la conversation et achemine vers le modèle le mieux adapté depuis votre pool configuré, en optimisant le coût, la latence ou la qualité selon vos besoins. Insérez-le avec un seul changement de ligne (« model »: « router:software-engineering »), et votre agent commence à utiliser le bon modèle pour chaque tâche automatiquement.

Sous le capot, il est propulsé par Plano, un proxy open source natif IA initialement développé chez Katanemo (maintenant partie de DigitalOcean). Le modèle de routage qui pilote la résolution d’intention est un modèle Mixture-of-Experts (MoE) de 30B paramètres, finement ajusté pour la détection de tâche sur de longues fenêtes de contexte. Il surpasse GPT-5.1 et Claude Sonnet 4.5 en précision de routage sur des conversations multi-tours, résolvant l’intention en ~200 ms. Une variante dense de 4B est également disponible pour les déploiements sensibles à la latence.

Comment ça marche : présélections personnalisées

Le moyen le plus rapide de commencer le routage est d’utiliser un routeur prédéfini. Le routeur d’inférence est livré avec des présélections pour les workflows courants : Génie logiciel, Général, Rédaction et Base de connaissances & Intelligence documentaire.

Les recommandations de modèles de chaque présélection sont basées sur une méthodologie d’évaluation hybride. Nous combinons les signaux des benchmarks publics provenant des principaux tableaux de classement pour identifier les meilleurs candidats par tâche, puis nous validons par des benchmarks internes sur des ensembles de données de tâches spécifiques organisées. Les recommandations finales sont confirmées par l’équipe de science des données de DigitalOcean à l’aide d’une notation automatisée et d’une évaluation humaine. Lorsque les modèles open source offrent une précision comparable aux modèles fermés pour une tâche spécifique, nous les recommandons ; sinon, nous recommandons le modèle fermé de pointe.

Les présélections prennent en charge trois politiques de sélection : Optimale (ordre de modèle recommandé par DigitalOcean basé sur cette évaluation hybride), Efficacité des coûts (prioriser le coût le plus faible) et Optimisation de la vitesse (prioriser la latence la plus faible).

Utiliser une présélection est un remplacement direct de tout appel de modèle. Préfixez le nom du routeur avec router: dans le champ model. La réponse vous indique quel modèle a été sélectionné (dans le champ model) et quelle tâche a correspondé (via l’en-tête x-model-router-selected-route). Si aucune tâche ne correspond, la requête tombe en mode dégradé vers les modèles de secours configurés, essayés dans l’ordre.

Routeurs personnalisés : quand vous avez besoin de contrôle

Lorsque vous avez besoin de plus de contrôle ou souhaitez personnaliser le routage pour votre propre cas d’usage, les routeurs personnalisés vous permettent de définir vos propres tâches. Chaque tâche a un nom, une description en langage naturel (utilisée pour la correspondance d’intention), un pool de modèles éligibles et une politique de sélection (moins cher, plus rapide, ou ordre classé).

Vous pouvez tester le comportement de routage dans le Playground, comparer un routeur à un modèle unique côte à côte, avec les différences de coût et de latence visibles par requête. Pour une évaluation systématique, la fonctionnalité Evals vous permet d’exécuter votre routeur avec un ensemble de données et de mesurer l’exactitude et l’exhaustivité, ce qui facilite la comparaison de la qualité de sortie d’un routeur par rapport à un modèle unique avant de le mettre en production.

Le tableau de bord Analyze affiche des métriques agrégées sur le trafic en direct : nombre total de requêtes, utilisation des tokens, taux de correspondance des tâches et taux de basculement vers les modèles de secours.

Sous le capot : l’architecture Plano

Lorsqu’une requête atteint le routeur d’inférence, voici ce qui se passe à l’intérieur de Plano :

Toute décision de routage se déroule en deux phases. D’abord, un petit modèle de langage (SLM) dédié résout l’intention de l’utilisateur en faisant correspondre la conversation avec les descriptions de tâches en langage naturel. Ensuite, un moteur de classement ordonne les modèles candidats de la tâche correspondante à l’aide de données en direct sur le coût et la latence provenant de sources de métriques enfichables, y compris l’API de tarification de DigitalOcean et Prometheus.

En mode proxy complet, Plano gère l’ensemble du cycle de vie : classer l’intention, classer les modèles, transmettre au fournisseur le mieux classé et diffuser la réponse en retour. Pour le routeur d’inférence DigitalOcean, cela signifie acheminer via les modèles disponibles sur la plateforme d’inférence DigitalOcean. Le moteur open source de Plano prend également en charge la traduction de format entre les API des fournisseurs (OpenAI, Anthropic, Gemini, Bedrock, etc.) pour les déploiements auto-hébergés où vous apportez vos propres clés de fournisseur.

Sous le capot, une configuration de routeur d’inférence se traduit par une configuration de routage Plano. Chaque tâche devient une route avec une description en langage naturel, un pool de modèles et une politique de sélection. Les descriptions de tâches sont ce que le modèle de routage voit. Elles sont passées directement dans son invite sous forme de langage naturel. La politique de sélection spécifie la métrique que le moteur de classement doit optimiser.

Pour les longues conversations, l’invite est tronquée pour s’adapter au budget de tokens du modèle sans exécuter un tokenizer complet sur le chemin critique. Le système conserve les échanges les plus récents, et si le dernier message de l’utilisateur dépasse toujours le budget, il utilise une stratégie de troncature centrale, en préservant environ 60 % du début et 40 % de la fin, séparés par des points de suspension. La raison : les utilisateurs ont tendance à définir la tâche au début d’un long message et à placer la tâche réelle à la fin, donc préserver les deux extrémités fournit au modèle de routage un signal plus fort qu’une troncature par la tête uniquement.

L’évolution des modèles : d’Arch-Router à Plano-Orchestrator

V1 : Arch-Router — les fondations

Notre premier modèle de routage, Arch-Router, est un modèle de langage génératif de 1,5B paramètres, finement ajusté spécifiquement pour la classification de route unique. Étant donné une conversation et un ensemble de descriptions de routes, il retourne {« route »: « code_generation »} ou {« route »: « full »} si rien ne correspond. Le résultat clé : 93,17 % de précision à 51 ms, soit 28 fois plus rapide que Claude, 10 fois plus rapide que Gemini-flash-lite, prouvant qu’un petit modèle dédié pouvait remplacer les modèles frontier pour le routage sans sacrifier la qualité.

V2 : Plano-Orchestrator

Arch-Router a validé l’approche, mais les charges de travail en production nous ont poussés plus loin. Les conversations réelles sont désordonnées. Les utilisateurs envoient des suivis ambigus (« fais la même chose pour New York »), changent de sujet en cours de conversation ou envoient des messages qui ne nécessitent aucun routage. Nous avions besoin d’un modèle qui généralise mieux ces schémas.

Plano-Orchestrator est le modèle de routage qui alimente aujourd’hui le routeur d’inférence DigitalOcean. Il utilise la même approche générative (descriptions de route dans l’invite, sortie JSON), mais il est entraîné sur des données conversationnelles plus riches couvrant le routage dépendant du contexte, la gestion des flux multi-tours (suivis, clarifications, corrections) et la détection de cas négatifs (reconnaître quand aucun routage spécialisé n’est nécessaire). Le résultat est un modèle qui généralise significativement mieux sur divers scénarios de routage.

Le modèle est disponible dans la collection Plano-Orchestrator en deux tailles : un modèle dense de 4B pour les déploiements à faible latence et un modèle MoE 30B-A3B pour une précision plus élevée, chacun avec des variantes quantifiées FP8. Nous avons évalué sur 1 958 messages utilisateur dans 605 conversations multi-tours avec plus de 130 agents différents : le modèle MoE 30B-A3B mène avec 87,84 % de performance moyenne, devant GPT-5.1 (86,93 %) et Claude Sonnet 4.5 (86,11 %). Le modèle dense 4B atteint 84,68 %, compétitif avec les modèles frontier à une fraction du coût d’inférence.

La catégorie codage montre le plus grand écart : Plano-Orchestrator-30B-A3B obtient 83,51 % contre 77,54 % pour GPT-5.1 et 74,39 % pour Claude Sonnet 4.5. C’est là que l’entraînement spécialisé paie le plus. Les requêtes de codage impliquent une intention ambiguë (« corrige ça », « rends-le plus rapide », « essaie encore ») qui nécessite le contexte conversationnel pour être routé correctement, et un modèle entraîné spécifiquement sur les schémas de routage gère cela mieux qu’un modèle à usage général.

Le moteur de classement : données en direct coût/latence

Connaître la bonne tâche n’est que la moitié du problème. Au sein d’une tâche, vous pouvez avoir trois modèles candidats. Le meilleur dépend du moment présent, que vous optimisiez pour le coût ou la latence. Un ordre statique ne suffit pas car la tarification des modèles change, la latence varie avec la charge et les limites de débit modifient la disponibilité.

Le moteur de classement récupère en continu les données de coût et de latence à partir de sources externes. Pour le routeur d’inférence, les données de coût proviennent de l’API de tarification Gen AI de DigitalOcean ; les données de latence proviennent de Prometheus. L’interface est extensible à d’autres sources. Cela a de l’importance car les performances du modèle ne sont pas statiques : la latence des fournisseurs varie de 2 à 3 fois au cours de la journée en fonction des modèles de trafic. Un modèle qui est le plus rapide à 2 heures du matin est souvent le plus lent à 14 heures. Le classement en direct capte ces changements ; la configuration statique ne le fait pas.

L’algorithme de classement est simple : lisez les derniers instantanés de coût et de latence à partir du cache mémoire. En fonction de la politique de sélection de la tâche : Efficacité des coûts (trier les modèles candidats par coût croissant ; les modèles sans données de coût sont poussés à la fin) ; Optimisation de la vitesse (trier par latence croissante ; les modèles sans données de latence sont poussés à la fin) ; Classement manuel (retourner les modèles dans l’ordre que vous avez spécifié, sans reclassement). Cela vous donne un contrôle total sur la priorité du modèle lorsque vous souhaitez un ordre déterministe.

Pour tout modèle manquant de données métriques, un avertissement est enregistré (au démarrage et par requête) afin que les erreurs de configuration remontent tôt sans échouer durement sur des manques transitoires de métriques. Le résultat est une liste ordonnée où le premier modèle est le meilleur correspondant à la politique, et les modèles sans données sont toujours disponibles comme solution de secours mais ne seront pas préférés. Une carte model_aliases comble les différences de dénomination entre les sources de métriques et votre configuration de routage.

Plano valide la configuration complète des métriques au démarrage. Les politiques de sélection non appariées, les sources en double, les modèles manquants dans les fournisseurs échouent avec un message d’erreur spécifique plutôt que de revenir silencieusement à l’ordre par défaut.

L’infrastructure : Envoy, WASM et Rust asynchrone

Le service de routage s’exécute dans l’architecture à trois couches de Plano :

• Envoy gère TLS, le pool de connexions, les tentatives, le circuit breaking et le multiplexage HTTP/2. Pour le routage, l’important est le modèle de thread : un worker par cœur de CPU, chaque connexion épinglée à un seul worker. Pas de contention de verrou sur le chemin critique. Pour les réponses LLM en streaming (connexions HTTP longues, fragmentées), cela évolue naturellement sans surcharge de coordination.
• Le filtre WASM llm_gateway.wasm s’exécute à l’intérieur du processus d’Envoy, pas en sidecar, pas en service séparé. Il gère la traduction de format entre les fournisseurs (OpenAI, Anthropic, Gemini, Mistral, Groq, DeepSeek, xAI, Bedrock) à la vitesse du fil, sans saut de réseau. Le bac à sable WASM impose des contraintes strictes : pas de std networking, pas de tokio, pas de runtime asynchrone, et toutes les dépendances doivent être compatibles no_std. La couche de traduction de format est alimentée par hermesllm, notre crate Rust pour l’abstraction d’API LLM. Ajouter un nouveau fournisseur signifie implémenter les traits ProviderRequest et ProviderResponse. Le routeur et la passerelle n’ont pas besoin de changer.
• Brightstaff est un binaire natif qui s’exécute aux côtés d’Envoy et gère la logique de routage, y compris la résolution d’intention, le classement des modèles et le traçage OTEL. Il utilise une tâche asynchrone légère par requète plutôt qu’un thread par requète, ce qui lui permet de gérer des milliers de décisions de routage simultanées sur du matériel modeste. Pour un proxy sur le chemin chaud des réponses LLM en streaming, une latence de queue prévisible est importante. Les pauses du ramasse-miettes dans la couche de routage se propageraient comme des saccades dans la livraison des tokens. Brightstaff est écrit en Rust, ce qui élimine complètement cette classe de problèmes : pas de ramasse-miettes, pas de pauses stop-the-world, récupération de mémoire déterministe. Le cache de métriques utilise une structure de données concurrente optimisée en lecture. Chaque requète le lit, mais les écritures n’ont lieu qu’à l’intervalle de rafraîchissement, donc la contention est quasi nulle en pratique.

Comment déployer : DigitalOcean et auto-hébergement

Sur DigitalOcean : créez un routeur d’inférence à partir du catalogue de routeurs (choisissez une présélection ou construisez un routeur personnalisé via l’API ou l’interface utilisateur). Pas de gestion de GPU, pas d’infrastructure à exécuter. Utilisez-le en définissant "model": "router:votre-nom-routeur" dans n’importe quel appel d’API compatible OpenAI.

Auto-hébergé : le moteur de routage est open source en tant que Plano. Les modèles de routage fonctionnent sur vLLM. Arch-Router (1,5B quantifié) tient sur un seul NVIDIA L4 ; les modèles Plano-Orchestrator plus grands s’exécutent sur un NVIDIA L40S. Le dépôt de démonstration comprend des manifestes Kubernetes, des fichiers Docker Compose et une configuration Plano pour l’auto-hébergement.

Leçons apprises en production

Construire et opérer cela en production a mis en lumière plusieurs leçons non évidentes :

• Les modèles spécialisés battent les modèles généralistes pour le routage (si vous avez les données d’entraînement). Notre premier modèle (Arch-Router, 1,5B) surperformait Claude 3.7 Sonnet sur la précision du routage avec une latence 28 fois inférieure. L’intuition est que le routage est une tâche étroite et bien définie : le modèle n’a pas besoin de générer de la prose ou de gérer des appels d’outils. Il doit lire une conversation, la comparer avec des descriptions de route et émettre un objet JSON. C’est une surface de capacité beaucoup plus petite qu’un modèle frontier fournit, et un modèle spécialisé peut la couvrir avec une haute précision si les données d’entraînement sont représentatives.
• Les descriptions de route sont un nouveau type d’ingénierie de prompt. Le modèle de routage est entraîné pour faire correspondre les prompts utilisateur aux tâches définies par l’utilisateur : les descriptions en langage naturel dans votre configuration sont l’interface. Cela signifie que la qualité de votre routage dépend fortement de la façon dont vous écrivez ces descriptions. « Gère le code » correspond à tout ; « écris des fonctions Python pour les pipelines de traitement de données » manque « aide-moi à déboguer ce JavaScript ». Trouver le bon niveau de spécificité (suffisamment large pour capturer le trafic réel, suffisamment précis pour distinguer les routes) est de l’ingénierie de prompt appliquée à la configuration d’infrastructure. C’est pourquoi le routeur d’inférence est livré avec des routeurs prédéfinis : des descriptions de tâche benchmarkées qui fonctionnent immédiatement pour les workflows courants.
• Le classement en direct des métriques est plus utile que la configuration statique car les performances des modèles dérivent. La latence des fournisseurs varie de 2 à 3 fois au cours de la journée. L’implémentation exécute une boucle en arrière-plan par source de métriques qui récupère les données fraîches à un intervalle configurable et met à jour un cache interne thread-safe. Les lectures sont non bloquantes pendant le rafraîchissement, donc il n’y a pas d’impact sur la latence des décisions de routage en vol.
• La contrainte du bac à sable WASM produit un code plus propre. Le bac à sable WASM supprime les outils que vous utiliseriez normalement : pas de pile réseau, pas de runtime asynchrone, pas d’appels système. Il ne reste qu’une architecture pilotée par les rappels où le proxy contrôle toutes les E/S et votre code de filtre ne traite que la logique. Cette contrainte est pénible pendant le développement, mais elle produit des filtres de petite taille (quelques Mo), déterministes et faciles à auditer. Vous pouvez retracer chaque interaction externe à partir de la source seule. Cela donne également de fortes garanties d’isolation : un bug dans un filtre WASM ne peut pas planter le proxy ni fuiter de mémoire en dehors de son bac à sable.

Prochaines étapes : ce que nous explorons

Le routeur d’inférence est une pièce d’un effort plus large chez DigitalOcean pour construire une infrastructure de production pour l’IA agentique. Dans un prochain article, je couvrirai l’évolution du modèle d’Arch-Router à Plano-Orchestrator, comment nous avons entraîné des modèles de routage spécialisés à différentes échelles, et ce que nous avons appris sur la généralisation dans divers scénarios de routage.

Nous investissons également dans la recherche sur des problèmes connexes. Notre article Signals: Trajectory Sampling and Triage for Agentic Interactions aborde l’observabilité des systèmes agentiques : comment identifier les trajectoires d’agents informatives en production sans revoir chaque interaction.

Le moteur de routage est open source dans le cadre de Plano. Essayez le routeur d’inférence sur DigitalOcean ou exécutez Plano auto-hébergé avec la démo.

Nicolas D.

Développeur full-stack depuis 25 ans, je suis passé du PHP des années 2000 aux stacks modernes (Next.js, React Native, IA). J’accompagne entrepreneurs et créateurs dans leurs projets digitaux avec une approche pragmatique : du code aux résultats concrets.