Comment créer un routage de modèle LLM tenant compte des coûts sans sacrifier la qualité

Le routage du modèle LLM tenant compte des coûts ne doit pas signifier envoyer chaque requête au modèle disponible le moins cher. Cela crée un mode d'échec discret : les factures s'améliorent pendant quelques semaines, puis les équipes produit découvrent des schémas défectueux, un raisonnement plus faible, un ton incohérent ou des brouillons de support qui nécessitent un nettoyage plus humain.

Le meilleur modèle est une stratégie de routage basée sur une évaluation. Classez la demande, définissez la qualité minimale acceptable pour cette tâche, supprimez les itinéraires qui ne peuvent pas satisfaire aux contraintes de capacité ou de gouvernance, estimez l'économie de l'itinéraire, puis choisissez le modèle éligible le moins coûteux. La décision de routage devient explicable lors d'une révision des coûts, car elle est liée à une version de la politique, et non aux préférences du développeur ou à un vague défaut du fournisseur.

Qu'est-ce que le routage axé sur les coûts optimise ?

Un routeur pratique optimise l'itinéraire le moins cher tout en répondant aux exigences opérationnelles de la tâche. C'est différent de l'optimisation pour le modèle le moins cher.

Faits : les principaux fournisseurs de modèles publient la tarification des jetons avec des dimensions distinctes telles que les jetons d'entrée, les jetons d'entrée mis en cache, les jetons de sortie, la mise en cache des invites et le traitement par lots. Certains fournisseurs exposent également des champs d'utilisation qui signalent le comportement des jetons mis en cache. Cela signifie que l'option la moins coûteuse peut changer en fonction de la forme de l'invite, de la longueur de sortie attendue, de l'éligibilité du cache et de la possibilité pour la charge de travail de s'exécuter de manière asynchrone.

Recommandation : traiter le routage comme un problème de politique au sein d'une passerelle IA multimodèle API, et non comme une instruction de changement au niveau de l'application. La passerelle affiche les enregistrements de capacité du fournisseur, les règles des locataires, les API métadonnées clés, les tableaux de prix, la télémétrie d'utilisation et le comportement de secours en un seul endroit.

Prédiction : les équipes qui maintiennent la logique de routage dispersée dans les référentiels d'applications auront du mal à expliquer les changements de coûts plus tard. Ils peuvent toujours réduire leurs dépenses, mais ils disposeront de preuves plus faibles expliquant pourquoi une requête donnée a utilisé un modèle donné.

Commencez par les classes de tâches, pas par les noms de fournisseurs

Le routeur a besoin d'une étiquette de charge de travail avant de pouvoir prendre une décision utile. Un seul modèle par défaut ne peut pas représenter le profil de risque de chaque demande.

Les classes de tâches utiles incluent :

• Extraction : convertit le texte non structuré en champs, souvent avec une validation de schéma stricte.
• Classification : attribuez des étiquettes, des catégories de priorité, d'intention, de sentiment ou de routage.
• Résumé : compresse les entrées longues tout en préservant les faits et décisions clés.
• Rédaction du support client : génère une réponse qu'un humain peut examiner ou envoyer.
• Synthèse des réponses RAG : réponse à partir du contexte récupéré avec des exigences de citation ou de fondement.
• Révision du code : inspectez les différences ou les fichiers sources pour détecter les problèmes d'exactitude, de risque ou de style.
• Analyse de contexte long : raisonnement sur les contrats, les transcriptions, les journaux, les politiques ou les packages de recherche.
• Aide à la décision à fort impact : tout flux de travail dans lequel une mauvaise réponse pourrait affecter l'argent, la conformité, la sécurité ou la confiance des clients.

La classe de tâches peut provenir de métadonnées de requête explicites, d'une portée de clé API, d'une route d'application ou d'un classificateur léger. Des métadonnées explicites sont généralement préférables à la déduction d'une intention à partir d'un texte d'invite, car des invites vagues forcent le routeur à adopter des valeurs par défaut conservatrices.

Attacher un niveau de qualité à chaque tâche

Le routage tenant compte des coûts ne fonctionne que si chaque tâche a un plancher de qualité. Sans ce modèle, le routeur ne dispose d'aucun moyen de principe pour rejeter un modèle moins cher.

Un sol de qualité peut comprendre plusieurs contrôles :

• Ensemble d'évaluation rejouable : exemples représentatifs du développement et de la production, dépourvus de données sensibles si nécessaire.
• Validité du schéma : le résultat doit être analysé, validé par rapport au schéma canonique et éviter les champs non pris en charge.
• Critères de contenu : la réponse doit suivre les règles de style, de refus, de fondement et d'exhaustivité de la tâche.
• Critères de sécurité : la sortie ne doit pas divulguer d'instructions cachées, ignorer les limites des règles ou exécuter des instructions non fiables à partir du contenu récupéré.
• Examen humain : requis pour les flux de travail à fort impact ou pour la promotion d'un nouvel itinéraire.
• Seuil de régression : l'itinéraire candidat doit atteindre ou dépasser l'itinéraire actuel dans les catégories d'échecs critiques, et pas seulement le score moyen.

Fait : la documentation du fournisseur décrit les évaluations comme un moyen de tester les sorties du modèle par rapport à des critères de contenu et de style spécifiés. L'abandon d'un produit d'évaluation hébergé est prévu. Les systèmes de routage doivent donc stocker des ensembles de données d'évaluation indépendants du fournisseur, les résultats attendus, les grilles de notation et les résultats plutôt que de dépendre d'une seule surface d'évaluation hébergée par un fournisseur.

Recommandation : stockez les résultats d'évaluation par classe de tâches, modèle, version de l'adaptateur de fournisseur, version d'invite, version de schéma et version d'évaluation. Un itinéraire ne devrait pas devenir éligible simplement parce qu’un modèle est nouveau ou moins cher. Il devient éligible lorsqu'il franchit le seuil de qualité actuel de la tâche.

Créer un registre de capacités des fournisseurs

Avant d'estimer le coût, supprimez tout itinéraire qui ne peut pas satisfaire la demande. Cette étape empêche le routeur de sélectionner un modèle bon marché qui ne dispose pas des fonctionnalités requises.

Un enregistrement de capacité doit inclure :

• Modalités d'entrée et de sortie prises en charge.
• Limites de la fenêtre contextuelle.
• Sortie structurée et prise en charge des appels d'outils.
• Prise en charge du streaming.
• Prise en charge de la mise en cache rapide et disponibilité de la télémétrie du cache.
• Support du lot API.
• Options de traitement régional.
• Conditions de conservation des données et de surveillance des abus qui sont importantes pour votre politique.
• Dimensions de limite de débit et capacité actuelle.
• Différences connues du contrat de sortie dans votre couche adaptateur.

Ce registre doit être géré séparément des invites d'application. Il appartient à la couche d'adaptateur de routage et de fournisseur, où le système peut comparer des modèles sans divulguer d'hypothèses spécifiques au fournisseur dans chaque application.

Estimer le coût de l'itinéraire avant la sélection

Le routeur ne peut pas connaître le coût final avant l'exécution, mais il peut l'estimer suffisamment précisément pour choisir parmi les routes éligibles. L'estimation doit inclure les variables qui déplacent réellement la facture.

estimated_cost =
  input_tokens * input_token_price
  + cached_input_tokens * cached_input_token_price
  + output_tokens_expected * output_token_price
  + tool_call_overhead_expected
  + retry_allowance_expected
  - batch_discount_if_eligible

Utilisez la télémétrie récente pour estimer les jetons de sortie par classe de tâches. Par exemple, les tâches d'extraction peuvent avoir une longueur de sortie limitée, tandis que l'analyse de contexte long peut varier considérablement. Les agents utilisant des outils peuvent avoir des coûts cachés supplémentaires liés à la planification des appels, aux tentatives et aux messages intermédiaires.

L'estimation des coûts doit également tenir compte de l'éligibilité du cache et des lots :

• Éligibilité au cache : préfixe d'invite stable, instructions système réutilisables, contexte récupéré répété, comportement du fournisseur pris en charge et probabilité d'accès au cache suffisante.
• Éligibilité par lots : la charge de travail peut attendre, dispose d'un traitement des requêtes idempotent, d'un suivi des tâches durable et n'a pas besoin de streaming interactif.
• Risque lié aux jetons de sortie : le modèle a tendance à produire des réponses plus longues ou plus courtes pour la même tâche, et la troncature nuirait à la qualité.
• Risque de nouvelle tentative : le fournisseur ou le modèle présente des taux d'erreur, des taux de réparation de schéma ou des échecs de latence élevés pour cette tâche.

C'est ici que le routage des coûts se connecte à une gestion des coûts LLM plus large. Le tableau des prix à lui seul ne suffit pas. Le routeur a besoin de métadonnées de requête, de structure d'invite, de mesures d'accès au cache et de données d'utilisation réglées pour savoir si les économies attendues se sont réellement produites.

Utiliser des niveaux de modèle au lieu d'une valeur par défaut globale

Une stratégie à plusieurs niveaux est plus facile à expliquer qu'une longue liste d'exceptions spécifiques au fournisseur. Chaque niveau doit contenir un ou plusieurs modèles éligibles qui ont franchi les étapes spécifiques à une tâche.

Ne laissez pas le niveau remplacer les évaluations. Un modèle peut être économique pour la classification mais inadapté à la rédaction d'un support. Un autre modèle peut être efficace pour la synthèse, mais trop coûteux pour un marquage déterministe court.

Itinéraire avec une séquence de décision explicite

Un routeur soucieux des coûts doit être suffisamment déterministe pour pouvoir déboguer. L'implémentation exacte varie, mais la séquence de décision doit être stable.

1. Lire les métadonnées du locataire, de la clé API, de l'environnement et de l'application.
2. Identifiez la classe de tâches à partir des métadonnées explicites ou de la sortie du classificateur.
3. Chargez la version de la stratégie de routage pour ce locataire ou cet espace de travail.
4. Appliquer des contraintes de gouvernance telles que la conservation des données, la région, la liste d'autorisation de modèle et les restrictions de fonctionnalités.
5. Filtrer par fonctionnalités requises : longueur du contexte, outils, sortie structurée, streaming, modalité et prise en charge par lots.
6. Filtrer par niveau de qualité basé sur une évaluation pour la classe de tâches.
7. Estimez le coût à l'aide des jetons d'entrée, des jetons de sortie attendus, de l'éligibilité du cache, de l'éligibilité des lots et du risque de nouvelle tentative.
8. Appliquer la politique budgétaire et les préférences des locataires.
9. Sélectionnez l'itinéraire éligible le moins cher.
10. Ajouter une stratégie d'itinéraire de secours, de délai d'expiration, de nouvelle tentative et de réparation.
11. Enregistrez la décision avec un code de motif stable.

En pseudocode, le routeur devrait ressembler davantage à une évaluation de politique qu'à une préférence de fournisseur codée en dur :

function selectRoute(request):
  context = buildRoutingContext(request)
  task = classifyTask(context)
  policy = loadPolicy(context.tenant_id, task)

  candidates = modelRegistry.models
    .filter(model => policy.allows(model))
    .filter(model => model.supports(context.required_capabilities))
    .filter(model => evalStore.passes(task, model, policy.quality_floor))

  priced = candidates.map(model => ({
    model,
    estimated_cost: estimateCost(model, context),
    expected_latency: estimateLatency(model, context),
    risk_flags: estimateRisk(model, context)
  }))

  eligible = priced.filter(route => route.risk_flags.noneBlocking())
  return minBy(eligible, route => route.estimated_cost)

Enregistrer chaque décision de routage

Si le service financier demande pourquoi un modèle premium a été utilisé, ou si l'ingénierie demande pourquoi la qualité a baissé, le routeur doit répondre à partir des journaux. Ne comptez pas sur la reconstruction de l'intention à partir des invites après coup.

Consignez ces champs pour chaque requête :

• ID de demande, ID de locataire, API ID de clé, ID d'application et environnement.
• Résultat et confiance du classificateur de tâches.
• Version de la politique de routage.
• Version de l'ensemble de données d'évaluation et contrôle de qualité utilisés.
• Modèles éligibles et modèles refusés.
• Raison pour laquelle chaque modèle rejeté a été exclu.
• Entrée estimée, entrée en cache et jetons de sortie.
• Coût estimé de l'itinéraire et coût final réglé lorsqu'ils sont disponibles.
• Fournisseur, modèle, version de l'adaptateur et niveau sélectionnés.
• Route de secours et stratégie de nouvelle tentative.
• Télémétrie réussie ou manquée du cache lorsqu'elle est disponible.
• Mode d'exécution par lots ou synchrone.
• Validation du schéma, tentatives de réparation, statut de refus et indicateurs de sécurité.

Ces journaux prennent également en charge le LLM API attribution des coûts, car la sélection du modèle ne représente qu'une partie des dépenses. Les équipes doivent toujours répartir les coûts par locataire, espace de travail, clé, produit, flux de travail ou client.

Ajoutez des contrôles de dérive avant de promouvoir des itinéraires moins chers

Modèlez le comportement, les tarifs, les invites et la répartition des charges de travail. Un itinéraire qui était sûr le mois dernier peut devenir faible après une révision rapide ou une mise à jour du modèle.

Une boucle de contrôle de dérive de base doit inclure :

• Exemples de requêtes de production récentes par classe de tâches.
• Supprimez ou transformez les données sensibles conformément à la politique.
• Rejouez des échantillons à travers les itinéraires actuels et candidats.
• Comparez la qualité, la validité du schéma, le comportement de refus, le coût et la latence.
• Examinez les échecs par catégorie, et pas seulement par score global.
• Promouvoir l'itinéraire le moins cher uniquement s'il respecte le niveau de qualité et les contraintes d'exploitation.
• Canary, le nouvel itinéraire pour un petit pourcentage du trafic.
• Revenir automatiquement en arrière en cas d'échec de schéma, de dépassement de coûts, de violation de latence ou de remontée d'avis humain.

Recommandation : faites de la promotion d'itinéraire un événement de gestion du changement. Enregistrez qui l'a approuvé, quel ensemble d'évaluation il a réussi, quel pourcentage de trafic il affecte, quand il expire ou doit être révisé, et comment fonctionne la restauration.

Donner des remplacements aux équipes, mais les faire expirer

Il existe des raisons légitimes de remplacer le routage : incident de fournisseur, urgence budgétaire, examen de conformité, remontée d'informations par le client ou régression de modèle. Le problème n'est pas la dérogation. Le problème est un remplacement qui devient une politique permanente invisible.

Chaque remplacement doit inclure :

• Portée : locataire, application, clé API, classe de tâches, modèle, fournisseur ou région.
• Raison : incident, budget, qualité, conformité, latence ou demande du client.
• Approbateur.
• Heure de début et heure d'expiration.
• Impact attendu sur le coût, la latence et la qualité.
• Condition de restauration.

Les remplacements expirés devraient échouer conformément à la stratégie de routage normale ou nécessiter un renouvellement. Cela évite que les décisions d'urgence ne se transforment en risques cachés en termes de coûts ou de qualité.

Compromis à rendre explicites

Le routage tenant compte des coûts entraîne un coût opérationnel réel. Cela vaut toujours la peine lorsque les dépenses LLM sont importantes, mais les compromis doivent être visibles.

• Dépendance des métadonnées : la qualité du routage dépend de la précision des étiquettes de tâches et des métadonnées de la charge de travail. Les étiquettes manquantes poussent le trafic vers des valeurs par défaut conservatrices.
• Maintenance des évaluations : les évaluations de tâches nécessitent des mises à jour à mesure que les invites, les produits et le comportement des utilisateurs changent.
• Complexité du fournisseur : les remises sur le cache et les lots peuvent améliorer la rentabilité, mais rendre la logique de routage plus complexe.
• Risque lié à la portabilité : les fonctionnalités spécifiques au fournisseur doivent résider dans les adaptateurs et les enregistrements de fonctionnalités, et non dans le code produit.
• Incertitude de l'estimation : la longueur finale de la sortie, les appels d'outils, les tentatives et les accès au cache ne sont pas entièrement connus avant l'exécution.
• Fardeau d'explicabilité : une optimisation agressive peut rendre le comportement du produit difficile à expliquer à moins que chaque décision ne soit enregistrée avec la version de la politique et les codes de raison.

Liste de contrôle de mise en œuvre

• Définissez des classes de tâches pour les principaux workflows LLM en fonction des dépenses et de l'impact commercial.
• Créez des ensembles d'évaluation et des niveaux de qualité pour chaque classe de tâches.
• Créez un registre de capacités de fournisseurs et de modèles.
• Stockez les tableaux de prix actuels et les modificateurs de prix par fournisseur, modèle et mode d'exécution.
• Estimez les jetons d'entrée, les jetons de sortie attendus, l'éligibilité du cache, l'éligibilité des lots et le risque de nouvelle tentative.
• Filtrer les candidats par contraintes de gouvernance avant d'optimiser les coûts.
• Sélectionnez le modèle le moins cher uniquement une fois les critères de capacité et de qualité franchis.
• Enregistrer les itinéraires sélectionnés et rejetés avec les codes de raison.
• Comparez le coût estimé avec les données d'utilisation réglées et de facturation.
• Effectuez des évaluations de rediffusion périodiques avant de promouvoir des itinéraires moins chers.
• L'itinéraire Canary change et définit des déclencheurs de restauration.
• Exiger des dates d'expiration pour les remplacements manuels.

Conclusion

L'objectif pratique n'est pas d'acheminer chaque requête vers un modèle moins cher. L'objectif est d'arrêter de payer trop cher pour le travail de routine tout en protégeant la qualité, les contrats, les règles de gouvernance et l'explicabilité.

Construisez le routeur autour de classes de tâches, de niveaux de qualité, de capacités de fournisseur, d'estimations de coûts et de journaux de politiques. Choisissez ensuite l’itinéraire éligible le moins cher. Ce seul mot, éligible, est ce qui différencie le routage tenant compte des coûts du routage du modèle le moins cher.

Lecture connexe

• limites de dépenses au niveau de la passerelle