Votre équipe envoie parfois un modèle coûteux pour résumer un courriel ou classer une demande simple. Le diriger vers un modèle moins cher peut réduire la facture, à condition que le résultat reste utilisable et ne réclame pas davantage de corrections. Le routeur automatique annoncé par Cloudflare propose de choisir un modèle selon la requête; un essai doit encore mesurer ce que cette décision change chez vous.
Le routeur choisit une destination, l’équipe garde le critère de qualité
Une économie annoncée à remettre dans son contexte
Le 30 septembre, Cloudflare a annoncé Auto Router, disponible en bêta publique dans AI Gateway. Avec le nom de modèle cloudflare/auto, le service analyse une requête et la dirige vers un modèle qu’il estime assez capable pour la tâche. Cloudflare dit avoir observé jusqu’à 30 % d’économies dans son usage interne avec OpenCode, comparé à l’utilisation exclusive de modèles de pointe. C’est un résultat éditeur, dans un environnement donné, et non une économie promise à chaque équipe. (Cloudflare, annonce Auto Router)
Auto Router et User Insights répondent à deux questions différentes. Le premier choisit une destination pour une requête. User Insights aide à comprendre quels utilisateurs, applications, tâches et modèles contribuent au trafic et au coût. Le 30 septembre, Cloudflare a ajouté du contexte de tâche à cet outil, lancé le mois précédent; il ne s’agit donc pas de deux nouveaux routeurs. (Cloudflare, mise à jour User Insights)
Une classification indiquant qu’un modèle semble surdimensionné ne démontre pas que son remplacement produira une réponse acceptable. Les tâches dont l’échec coûte cher, qui manipulent des données sensibles ou qui utilisent des outils avec effet réel méritent des règles distinctes. Le routeur peut réduire l’effort de choix manuel, mais la responsabilité du résultat reste à l’équipe qui déploie le système.
Fixer les contraintes avant de laisser choisir le routeur
Définir les familles de tâches
Commencez par séparer trois familles : extraction de champs déjà présents, rédaction à partir d’instructions et diagnostic ou raisonnement plus ouvert. Pour chacune, écrivez un critère d’acceptation. Une extraction peut exiger un format valide et des champs fidèles à la source; une rédaction peut être relue selon une grille; un diagnostic peut demander la reproduction du problème et une explication vérifiable.
Établissez aussi une liste de contraintes qui ne doivent pas être déléguées au routeur : quelles données peuvent sortir du système, quels outils sont autorisés, quel budget maximal s’applique, quelle latence est tolérée et quelles versions de modèle sont admises. La documentation de Cloudflare indique qu’Auto Router filtre les options selon les formats et modes d’exécution compatibles, les identifiants, la facturation, les politiques d’accès, les plafonds de dépense et l’état des fournisseurs. Le périmètre évolue toutefois : l’éditeur indique encore travailler à l’élargissement des modèles disponibles et à certaines fonctions. Vérifiez les destinations réelles dans la documentation au moment du pilote. (Cloudflare, fonctionnement et feuille de route Auto Router)
Comparer avec une référence fixe
Constituez un petit corpus synthétique commun, sans information client : demandes d’extraction, de rédaction et de diagnostic. Pour chacune, consignez la sortie attendue et les erreurs rédhibitoires. Lancez d’abord chaque modèle de référence avec des paramètres fixes, puis comparez la même tâche au routeur. Si l’application accepte le test, vous pouvez aussi exécuter le pilote en parallèle sans montrer les sorties aux utilisateurs ni déclencher d’action métier.
Conservez les versions, consignes, limites de tokens, outils, réglages, nombre d’essais et conditions de cache. Il faut comparer la qualité avec la même définition de réussite, pas les notes de benchmark des fournisseurs. Une sortie rejetée ou une relance fait partie du coût. Une feuille de suivi peut contenir :
| tâche | chemin utilisé | acceptée | appels et outils | coût total | délai | motif de rejet |
|---|---|---|---|---|---|---|
| extraction fictive A | référence / routeur | à mesurer | à relever | à relever | à relever | à documenter |
| rédaction fictive B | référence / routeur | à mesurer | à relever | à relever | à relever | à documenter |
| diagnostic fictif C | référence / routeur | à mesurer | à relever | à relever | à relever | à documenter |
Calculez le coût par résultat accepté, en incluant le modèle, les outils et les reprises. Ajoutez la latence médiane et le 95e percentile (le seuil sous lequel se terminent 95 % des essais) si le délai importe. N’agrégez pas des tâches très différentes en un seul taux qui cacherait, par exemple, une baisse de réussite sur le diagnostic.
User Insights : voir les usages sans surveiller les personnes
User Insights classe les trajectoires de conversation par tâche et fournit un contexte au-delà du seul nom de modèle. Cloudflare indique que cette analyse n’est pas en temps réel et peut accuser environ un jour de retard. Pour les applications maison, la fonctionnalité utilise des identifiants stables d’utilisateur et de session; il faut éviter d’y mettre une identité personnelle inutile. Ces vues aident à repérer des tendances sur une période, elles ne remplacent pas une mesure en direct ni un contrôle de la qualité des réponses. (Cloudflare, limites et contexte User Insights)
Réservez l’analyse à une décision précise : choisir quelles familles de tâches inclure dans l’essai ou repérer une hausse de coût à examiner. Évitez d’en faire un classement individuel. Définissez qui peut voir les rapports, comment les identifiants sont pseudonymisés et combien de temps les traces sont conservées.
Déployer avec un retour arrière prêt
Un pilote acceptable a une référence stable, un plafond de dépenses, des règles de données, un échantillon de tâches et des seuils d’arrêt. Si le taux d’acceptation baisse, si le coût complet augmente ou si une destination devient incompatible avec vos contraintes, revenez au modèle de référence. Enregistrez pour chaque décision le modèle effectivement appelé, la version, la tâche et le motif; sans cette trace, il sera difficile d’expliquer un changement de qualité.
La bêta publique permet d’évaluer une politique de routage, pas de lui abandonner le contrôle. Vérifiez les limites de l’offre et les modèles accessibles, mesurez des tâches identiques avec et sans routeur, puis ne généralisez que les familles de travail pour lesquelles les résultats et les coûts sont observés. Aucun chiffre de cet essai n’est fourni ici : il reste à produire dans votre environnement.
Ce protocole prolonge le guide Partitech sur le choix entre API, cloud privé et installation locale, qui traite notamment du coût complet et de la portabilité.