Évaluation comparative des LLM pour la production en entreprise : Comment évaluer les modèles pour votre cas d'utilisation réel

Les benchmarks publics du LLM mesurent ce qui intéresse les chercheurs en IA : raisonnement de niveau supérieur, génération de code sur des problèmes canoniques, qualité de traduction multilingue. Utile pour le cadrage des capacités dans le résumé. Souvent trompeur lorsqu'il est utilisé pour prendre des décisions d'achat d'entreprise, car l'indice de référence mesure une répartition des tâches qui ne partage probablement presque rien avec votre charge de travail spécifique. Un modèle classé au premier rang du classement MMLU peut produire de moins bons résultats qu'un modèle moins cher en ce qui concerne votre charge de travail de synthèse de documents, simplement parce que vos documents présentent des caractéristiques différentes de celles du jeu de test de référence.

L'écart entre les performances de référence publiques et les performances de production n'est pas un problème d'étalonnage mineur. C'est structurel. Les benchmarks utilisent des données normalisées et propres. Les données de production sont compliquées. Spécifique au domaine. Après les distributions, les concepteurs de benchmarks n'avaient pas anticipé. Les benchmarks mesurent la précision des tâches canoniques. Les systèmes de production doivent satisfaire à des exigences organisationnelles en matière de format de sortie, de tonalité et de cohérence qu'aucune référence publique ne saisit. Et les benchmarks sont des instantanés statiques, tandis que les performances de production évoluent à mesure que les fournisseurs de modèles mettent à jour leurs modèles et que la distribution de vos données évolue.

Ce guide explique comment créer un cadre d'évaluation LLM d'entreprise qui génère un signal significatif pour les décisions de sélection et d'optimisation des modèles. Il couvre les quatre dimensions de référence qui prédisent les performances de production, comment créer un ensemble de données de test reflétant votre charge de travail réelle, comment exécuter des tests A/B en production sans perturber les utilisateurs et comment automatiser le changement de modèle afin que la passerelle achemine vers le meilleur modèle par demande sans intervention d'ingénierie. La passerelle IA de TrueFoundry facilite la configuration et la surveillance des tests A/B de répartition du trafic en production.

Stop guessing which model performs best for your use case. Benchmark it in production.

TrueFoundry's AI Gateway handles production traffic splitting, outcome logging, and automatic rollback for live model A/B tests. Book a demo to see how to run your first benchmark in under 30 minutes.

Book Demo

Pourquoi les indices de référence publics ne sont pas fiables pour les décisions de production des entreprises

Les scores de référence publics sont les données les plus fréquemment citées et les plus fréquemment utilisées à mauvais escient dans le cadre des achats LLM des entreprises. Ils apparaissent dans les dossiers des fournisseurs, les notes du conseil d'administration et les feuilles de calcul des achats. Traitée comme une vérité fondamentale. Comprendre pourquoi ils ne parviennent généralement pas à prévoir les performances de production est une condition préalable pour investir du temps d'ingénierie dans la sélection de modèles basée sur des critères de référence.

• La contamination de référence fait gonfler les scores. Les modèles linguistiques de grande taille s'entraînent sur d'énormes quantités de texte Internet, qui incluent de plus en plus de questions et réponses de référence. Les modèles qui ont vu du contenu de référence pendant la formation obtiennent des résultats supérieurs à ce que leur capacité réelle à exploiter de nouvelles données ne pourrait le prédire. L'étendue de la contamination est rarement révélée et est difficile à mesurer de l'extérieur. Le fait de considérer les scores publiés comme une vérité fondamentale surestime l'écart entre les modèles les mieux classés et ne vous en dit pas beaucoup sur la manière dont ils traiteront vos entrées.
• Les tâches académiques ne correspondent pas à la charge de travail de l'entreprise. Le MMLU mesure les performances sur les questions relatives aux connaissances des étudiants des cycles supérieurs dans 57 matières. HumanEval mesure la génération de code sur des problèmes de programmation canoniques. Ni l'un ni l'autre ne mesure les raisons pour lesquelles les équipes d'entreprise déploient réellement des modèles : extraction de données structurées à partir de PDF au formatage incohérent, génération d'une sortie JSON cohérente à partir d'instructions en langage naturel, synthèse du contenu technique spécifique à un domaine sans terminologie hallucinante, maintien du contexte de conversation tout au long d'une interaction en 20 étapes avec le service client.
• La rentabilité est invisible dans les benchmarks axés sur la précision. Un modèle qui obtient un score de 95 % sur un indice de référence mais qui utilise en moyenne 4 000 jetons pour accomplir votre tâche habituelle peut avoir un coût par résultat inférieur à celui d'un modèle obtenant 88 % qui utilise en moyenne 1 800 jetons par tâche. Le coût par résultat, c'est-à-dire le coût réel de la production d'un résultat acceptable pour votre cas d'utilisation, n'est presque jamais pris en compte dans les benchmarks publics. Il s'agit également souvent de l'indicateur le plus important pour la planification du budget de l'entreprise.
• Les valeurs de latence de référence ne s'appliquent pas à votre environnement. Les chiffres de latence publiés pour les API modèles sont mesurés dans des conditions spécifiques : taille de la requête, niveau de simultanéité et infrastructure qui peuvent différer considérablement de la vôtre. Un modèle qui affiche une latence médiane de 800 ms dans des conditions de référence peut fournir une latence P95 de 2 400 ms dans le cadre de votre volume de production simultané. Il s'agit d'une expérience utilisateur totalement différente.
• Les modèles changent sous des numéros de version stables. Les fournisseurs mettent à jour le comportement des modèles sans toujours publier de nouveaux numéros de version ou communiquer clairement les modifications. Un modèle qui a obtenu de bons résultats lors de votre test de référence interne il y a trois mois peut se comporter différemment aujourd'hui si le fournisseur a mis à jour ses réglages, sa gestion rapide du système ou son filtrage des sorties. L'analyse comparative de la production doit être continue et ne pas être un exercice ponctuel au moment de la sélection du modèle.

Les quatre dimensions de l'analyse comparative des LLM en entreprise

Une référence LLM d'entreprise utile couvre quatre dimensions distinctes. Ils ne sont pas indépendants. Un modèle qui excelle en termes de qualité tout en échouant en termes de coût par résultat peut tout de même être un mauvais choix si l'écart de coûts n'est pas justifié par l'amélioration de la qualité. Les quatre doivent être mesurés. Et j'ai fait des échanges explicites.

Dimension 1 : Qualité de sortie adaptée à votre tâche spécifique

• Définissez des critères de qualité spécifiques à la tâche avant d'effectuer des évaluations. Les critères de qualité doivent être mesurables, soit par des évaluateurs humains utilisant une rubrique définie, soit par un modèle d'évaluation automatisé avec des critères spécifiés, soit par des mesures objectives lorsqu'elles existent (code : taux de réussite au test ; extraction structurée : précision sur le terrain ; classification : précision et rappel par rapport à un ensemble étiqueté). Des critères vagues tels que « bon résultat » produisent des évaluations qui ne sont pas reproductibles et ne peuvent justifier une décision du fournisseur.
• Créez une grille de notation qui peut être appliquée de manière cohérente à tous les modèles en cours d'évaluation. Pour le résumé des documents, une rubrique peut couvrir l'exactitude des faits (le résumé contient-il des affirmations non étayées par la source ?) , couverture (inclut-elle tous les points clés ?) , longueur appropriée (dans la plage de mots cible ?) , et la conformité du format (suit-il la structure de sortie requise ?). Chaque critère doit être noté indépendamment afin que les modèles puissent être comparés par dimension, et pas seulement globalement.
• Effectuez une évaluation de la qualité à l'aveugle. Les évaluateurs ou les modèles de juges ne devraient pas savoir quel modèle a produit quel résultat. Le biais lié à l'identité du modèle est réel : les évaluateurs qui savent qu'ils lisent la sortie GPT-4 lui attribuent en moyenne une note plus élevée qu'un texte identique sans cette étiquette. L'évaluation à l'aveugle vous donne des scores qui reflètent la qualité réelle plutôt que les effets de réputation.

Dimension 2 : coût par résultat

• Le coût pour 1 000 jetons est une métrique autonome trompeuse. L'unité pertinente est le coût par tâche terminée. Le coût total (jetons d'entrée + jetons de sortie, au prix du modèle) pour produire une sortie acceptable pour votre cas d'utilisation typique. Un modèle haut de gamme dont le prix est, disons, de 3 dollars par million de jetons d'entrée et de 15 dollars par million de jetons de sortie peut être plus ou moins rentable qu'un modèle nominalement moins cher qui nécessite des réponses plus longues pour atteindre une qualité équivalente. Le calcul dépend entièrement de la distribution de la longueur de vos tâches. Consultez toujours les taux par jeton actuels sur la page de tarification de chaque fournisseur le jour où vous effectuez la comparaison ; les chiffres changent tous les trimestres.
• Calculez le coût par tâche terminée en mesurant la longueur moyenne de l'invite (jetons d'entrée) et la longueur de réponse moyenne (jetons de sortie) pour votre ensemble de données de test sur chaque modèle, puis en multipliant par les prix par jeton. Lorsque les scores de qualité sont proches, le coût par tâche est déterminant. Lorsque les différences de qualité sont réelles, le rapport coût/qualité (coût supplémentaire par point de pourcentage d'amélioration de la qualité) détermine si le modèle haut de gamme en vaut le prix.
• Incluez les effets de cache dans le coût par résultat. TrueFoundry cache sémantique renvoie les réponses précédemment générées pour des requêtes sémantiquement similaires, notées par similarité cosinus sur une intégration du dernier message utilisateur. Les accès au cache ne génèrent aucun coût de modèle, de sorte que les dépenses effectives par requête dépendent de votre taux de réussite. Si 35 % de vos demandes sont mises en cache, le coût par résultat est sensiblement différent du calcul par jeton, et l'ignorer peut inverser la comparaison des modèles.

Dimension 3 : Latence par rapport à votre modèle de trafic réel

• Mesurez la latence à P50, P95 et P99, et pas seulement à la médiane. Les applications d'entreprise doivent connaître le pire scénario auquel les utilisateurs seront confrontés, et pas seulement l'expérience habituelle. Un modèle avec un excellent P50 mais un P99 en 8 secondes rend l'utilisation interactive inacceptable, même si la médiane semble correcte. TrueFoundry tableau de bord des métriques expose les sélecteurs P50, P75, P90 et P99 sur la latence de la demande, le délai jusqu'au premier jeton (TTFT), la latence entre jetons (ITL) et le temps par jeton de sortie (TPOT). Les quatre indicateurs apparaissent car chacun d'entre eux vous indique quelque chose de différent.
• Testez le chargement en fonction du volume de demandes simultanées que vous attendez, et non dans des conditions de demande unique. La plupart des modèles ont une belle apparence lorsqu'ils sont isolés et se dégradent de manière significative sous l'effet des charges simultanées générées par les applications de production. TrueFoundry expédie et Outil d'analyse comparative LLM dans le catalogue d'applications qui vous permet de configurer la simultanéité maximale, le taux de montée en puissance, la distribution rapide de la taille et le nombre maximum de jetons de sortie. Il trace les demandes par seconde, le temps de réponse, le TTFT et la latence entre jetons. Exécutez-le sur n'importe quel point de terminaison compatible avec OpenAI, y compris les modèles déployés par TF, les fournisseurs externes via une clé API ou tout autre modèle derrière votre AI Gateway. Testez à environ 2 fois le pic de simultanéité attendu pour obtenir une marge de capacité significative.
• Suivez le TTFT séparément de la durée totale de génération pour les cas d'utilisation du streaming. Les applications qui diffusent la sortie du modèle aux utilisateurs ressentent le TTFT comme une « latence perçue », c'est-à-dire le temps qui s'écoule avant que quelque chose n'apparaisse à l'écran. Un modèle avec une génération totale plus longue mais un TTFT inférieur peut offrir une meilleure expérience qu'un modèle techniquement plus rapide avec un premier jeton lent. Le TPOT (temps total divisé par les jetons de sortie) est le chiffre unique qui capture la vitesse de génération complète et c'est ce que TrueFoundry routage basé sur la latence permet de choisir la cible la plus rapide.

Dimension 4 : Cohérence et fiabilité

• Exécutez chaque invite de votre jeu de données de test trois à cinq fois sur plusieurs sessions pour mesurer la variance de sortie. Certains modèles produisent des résultats radicalement différents pour la même entrée d'une série à l'autre : allégations factuelles différentes, structures de sortie différentes, couverture différente des points requis. Une variance élevée crée des problèmes en aval pour l'analyse, l'extraction de données structurées et la cohérence de l'expérience utilisateur.
• Testez le comportement du mode échec de manière explicite. Que renvoie le modèle lorsque l'entrée dépasse sa fenêtre de contexte ? Que se passe-t-il lorsque la politique de contenu se déclenche lors d'une saisie limite ? Suit-il de manière fiable les instructions de formatage explicites ou tombe-t-il parfois dans des réponses de forme libre lorsqu'une sortie structurée était requise ? Ces modes de défaillance sont pour la plupart absents des benchmarks publics, mais c'est là que les systèmes de production tombent en panne.

Création d'un ensemble de données de référence représentatif pour votre entreprise

L'ensemble de données de référence est l'élément le plus important d'une évaluation LLM d'entreprise. Un ensemble de données bien conçu produit des prévisions fiables sur les performances de production. Une méthode mal conçue produit des résultats trompeurs qui conduisent à de mauvaises sélections. La conception des ensembles de données mérite autant d'investissements techniques que la méthodologie d'évaluation elle-même.

• Les échantillons représentatifs constituent le cœur de l'ensemble de données. Collectez 100 à 500 exemples réels de votre charge de travail de production, revus manuellement par des experts en la matière pour confirmer qu'ils représentent la distribution réelle des entrées gérées par votre système. Couvrez l'ensemble de la distribution : les cas courants, les cas extrêmes, la minorité d'entrées techniquement difficiles ou pour lesquelles les exigences de qualité sont les plus strictes. Les échantillons doivent être prélevés à partir de données de production récentes pour refléter les distributions actuelles, et non de données historiques qui peuvent ne plus être représentatives. Si vous avez activé le traçage sur votre AI Gateway, le API Query Spans (via le SDK TrueFoundry) est probablement le moyen le plus simple d'extraire un échantillon stratifié, en filtrant par utilisateur, équipe, compte virtuel ou par clé de métadonnées personnalisée que vous avez jointe.
• Les boîtiers Edge étudient les modes de défaillance connus des modèles. Concevez des entrées de test spécifiques pour les mettre en surface. Pour le traitement de documents : documents très longs proches des limites de la fenêtre contextuelle, documents dont la mise en forme n'est pas uniforme, documents contenant des tableaux ou des données structurées mélangées à de la prose. Pour la génération de code : requêtes dont les spécifications sont ambiguës, requêtes dans des frameworks peu courants, demandes nécessitant un raisonnement quant aux implications en matière de sécurité. Pour les applications destinées aux clients : entrées contenant des erreurs grammaticales, entrées dans un langage non standard, majuscules limites de politique de contenu. C'est dans la catégorie des scénarios extrêmes que se situe l'écart entre « 95 % par rapport à l'indice de référence » et « une production cassée ».
• Les cas de régression empêchent les régressions de capacité. Conservez un ensemble de 20 à 50 exemples tirés d'incidents antérieurs : cas où votre modèle actuel produisait des résultats incorrects, cas où une mise à niveau précédente du modèle entraînait des régressions de qualité, cas où des modèles d'entrée spécifiques provoquaient régulièrement des problèmes. Tout nouveau modèle en cours d'évaluation doit passer l'ensemble de régression avant d'être considéré pour la production. Cela rend les mises à niveau plus sûres car vous ne pouvez pas réintroduire silencieusement des problèmes précédemment résolus.
• La vérité sur le terrain étiquetée permet une notation automatique. Pour les cas d'utilisation où la notation automatique est possible (extraction structurée, classification, génération de code), incluez des étiquettes de base créées par des experts humains pour chaque cas de test. La notation automatique sur des échelles de vérité sur le terrain est meilleure que l'évaluation humaine pour les grands ensembles de tests. Les étiquettes doivent être examinées par au moins deux évaluateurs indépendants afin de résoudre les désaccords avant de devenir la norme d'évaluation.

Exécution de tests A/B en production : la référence la plus fiable

L'analyse comparative hors ligne d'un jeu de données de test est une première étape nécessaire. Le signal le plus fiable provient généralement du trafic de production. Les utilisateurs réels génèrent une distribution d'entrées qui serait plus variée et plus difficile que n'importe quel ensemble de tests organisé manuellement. Les tests A/B de production, qui acheminent un pourcentage du trafic réel vers un nouveau modèle tout en comparant les résultats avec ceux du modèle actuel, sont ce qui permet de justifier une décision relative à un modèle.

• Commencez par 1 à 5 % du trafic de production. Acheminez un petit pourcentage des requêtes en direct vers le modèle candidat tandis que le reste reste sur le modèle actuel. Surveillez la qualité de sortie, la latence, les coûts et le taux d'erreur pendant au moins deux semaines, suffisamment longtemps pour capturer la distribution complète de vos intrants de production, y compris les modèles hebdomadaires et les cas limites qui n'apparaissent qu'occasionnellement. Dans TrueFoundry, il s'agit d'un champ unique sur un Modèle virtuel configuration : poids : 5 pour le candidat, poids : 95 pour le titulaire.
• Définissez les critères de réussite avant le début du test. Expliquez les conditions spécifiques dans lesquelles le nouveau modèle sera accepté pour un déploiement complet en production. Exemple : le nouveau modèle doit atteindre au moins 97 % du score de qualité du modèle actuel pour un maximum de 110 % du coût par tâche du modèle actuel, avec une latence P95 non inférieure à celle du modèle actuel. Des critères prédéfinis empêchent la rationalisation a posteriori lorsque les équipes acceptent un modèle moins performant parce que d'autres indicateurs s'avèrent satisfaisants.
• Utilisez la couche de routage AI Gateway pour fractionner le trafic. Configurez la passerelle pour répartir le trafic entre les modèles en pourcentage sans modifier le code de l'application. L'application envoie une requête standard à un nom de modèle virtuel (quelque chose comme support-bot/summary), et la passerelle décide quel modèle réel utiliser en fonction de la division configurée. Cela élimine les frais d'ingénierie liés au déploiement de branches de code spécifiques au modèle à des fins d'évaluation. La configuration d'équilibrage de charge de TrueFoundry est déclarative en YAML, modifiable dans l'interface utilisateur ou poussée via la CLI tfy pour les flux de travail GitOps.
• Définissez des déclencheurs d'annulation automatiques. Configurez les conditions qui retirent automatiquement le candidat de la rotation : seuil de taux d'erreur, plafond de latence, seuil de score de qualité. La configuration de tolérance aux pannes de TrueFoundry (allowed_failures_per_minute, cooldown_period_minutes, failure_status_codes) est définie par modèle, et une cible qui dépasse le seuil est marquée comme non saine et exclue du routage pendant la durée du temps de recharge. Le blog sur l'équilibrage de charge montre une configuration typique avec trois pannes par minute déclenchant un temps de recharge de cinq minutes sur [429, 500, 502, 503, 504]. Pour la latence, le routage basé sur les priorités prend en charge une Coupure du SLA sur TPOT : configurez time_per_output_token_ms par cible, et la passerelle surveille une fenêtre glissante de 3 minutes avec jusqu'à 10 échantillons (minimum 3) pour décider si le candidat atteint votre barre de latence. Les tests A/B de production échouent en toute sécurité. Dans le pire des cas, un faible pourcentage du trafic est desservi par un mauvais modèle avant le démarrage de la restauration automatique.
• Enregistrez des indicateurs de résultats qui vont au-delà des signaux techniques. Outre la latence et le taux d'erreur, enregistrez les signaux relatifs aux résultats commerciaux lorsqu'ils sont mesurables : l'utilisateur a-t-il accepté ou rejeté les résultats du modèle ? La tâche de l'agent s'est-elle terminée correctement ? L'interaction avec le service client a-t-elle été résolue en cours de session ? Ces métriques en aval sont plus pertinentes pour la sélection des modèles que la seule qualité technique, et elles nécessitent une instrumentation au niveau de l'application pour être collectées. TrueFoundry métadonnées personnalisées (envoyé via l'en-tête X-TFY-METADATA) vous permet de baliser chaque demande avec une fonctionnalité, un environnement, un identifiant client ou toute autre dimension qui intéresse votre entreprise, et de décomposer le tableau de bord des métriques en fonction de cette dimension ultérieurement.

Automatiser la sélection des modèles : au-delà des tests A/B manuels

L'objectif d'un programme d'évaluation LLM d'entreprise mature est de supprimer complètement la sélection des modèles de la trajectoire critique des décisions d'ingénierie. Au lieu d'exécuter des tests A/B manuels chaque fois qu'un nouveau modèle est livré, la passerelle applique automatiquement les critères de sélection configurés. Chaque demande est dirigée vers le modèle qui produit probablement le meilleur résultat compte tenu des données de performance actuelles.

• Routage des types de tâches en fonction des résultats de l'évaluation. Une fois que les évaluations ont établi que le modèle A est meilleur pour la synthèse des documents et que le modèle B est meilleur pour la génération de code, configurez la passerelle pour qu'elle achemine par balise de type de tâche attachée à chaque demande. Il s'agit d'un routage statique basé sur une évaluation préalable, la forme la plus simple de sélection automatique de modèles. Dans les modèles virtuels de TrueFoundry, il s'agit d'un bloc de correspondance de métadonnées sur chaque cible : envoyez des requêtes {task : « summary"} à un fournisseur, {task : « code_gen"} à un autre, avec les métadonnées renseignées par votre application via l'en-tête X-TFY-METADATA.
• Routage dynamique basé sur des signaux de performance en temps réel. Un routage plus sophistiqué utilise les données de latence et de taux d'erreur en temps réel de la passerelle pour s'éloigner des modèles actuellement dégradés. Lorsque l'API d'un fournisseur connaît une latence élevée, la passerelle déplace le trafic vers le modèle le mieux adapté à ce type de tâche sans attendre qu'un humain s'en aperçoive. TrueFoundry routage basé sur la latence itinéraires vers le TPOT le plus bas au cours des 20 dernières minutes (ou des 100 dernières demandes, selon la valeur la moins élevée), avec une bande 1,2× afin que les modèles compris dans cette plage soient traités comme étant tout aussi rapides et que le trafic n'oscille pas en cas de différences mineures.
• Un routage rentable avec des sols de qualité. Configurez des règles qui envoient des demandes au modèle le moins cher répondant à un seuil de qualité défini. Pour les tâches où n'importe quel modèle au-dessus d'un sol est acceptable, la passerelle permet de réaliser des économies de coûts, car les modèles les moins chers atteignent la barre sans travaux d'ingénierie. C'est là que le routage automatisé est rentabilisé le plus rapidement : chaque nouveau modèle moins cher qui atteint votre niveau de qualité est directement synonyme d'économies.
• Évaluation continue avec des tests parallèles. Les tests parallèles acheminent chaque demande de production vers plusieurs modèles simultanément, fournissent la réponse depuis le primaire et évaluent les résultats de tous les candidats. Cela crée un flux d'évaluation continu qui détecte les changements de performances du modèle en temps réel, avant qu'ils n'entraînent des dégradations visibles pour l'utilisateur. Les frais généraux sont d'environ N fois les dépenses liées au modèle si vous comparez N modèles, ce qui est significatif mais souvent inférieur au coût de déploiement d'un modèle régressif en production. Vous pouvez gérer ces frais généraux en ne surveillant qu'une fraction du trafic ou en vous basant uniquement sur des modèles plus petits et moins chers évalués en tant que candidats à la réduction des coûts.

Comment TrueFoundry résout les problèmes d'analyse comparative et de sélection de modèles en entreprise en matière de LLM

La passerelle IA de TrueFoundry est conçue pour faire de l'évaluation des modèles de production une capacité continue pour les équipes chargées des plateformes d'entreprise, et non un projet ponctuel. Les éléments ci-dessous sont documentés dans la documentation en direct d'AI Gateway et ont été vérifiés par rapport au produit déployé.

• Répartition du trafic sans modification du code. Modèles virtuels gérer la répartition du trafic de production entre un certain nombre de cibles réelles en pourcentage. Les équipes d'ingénieurs configurent le split dans l'éditeur YAML de l'interface utilisateur ou via tfy apply -f loadbalancer-config.yaml pour GitOps. Le code de l'application reste inchangé : il appelle un nom de modèle virtuel tel que support-bot/summary, et la passerelle décide quel fournisseur réel gère chaque demande. Les divisions peuvent être ajustées en temps réel, de 1 % à 10 % à 50 %, à mesure que la confiance dans le candidat augmente.
• Déclencheurs d'annulation automatiques intégrés. Deux mécanismes complémentaires régissent le moment où une cible est retirée de la rotation. La configuration de tolérance aux pannes (configurable par modèle via allowed_failures_per_minute, cooldown_period_minutes et une liste de failure_status_codes) marque une cible comme défectueuse lorsque le taux d'erreur dépasse le seuil, puis la restaure automatiquement une fois le temps de recharge écoulé. La coupure SLA (routage basé sur les priorités uniquement) vous permet de définir un seuil TPOT par cible ; la passerelle surveille une fenêtre glissante de 3 minutes et rétrograde une cible qui le dépasse. Les tests A/B de production échouent en toute sécurité sans nécessiter de surveillance humaine en dehors des heures de travail.
• Suivi du coût par résultat sur l'ensemble des modèles. Suivi des coûts prend en charge à la fois le coût public (renseigné automatiquement à partir des tarifs des fournisseurs) et le coût privé (contrats personnalisés, modèles affinés). Le tableau de bord Metrics ventile les coûts par utilisateur, modèle, équipe ou compte virtuel, avec un pivot « Afficher par métadonnées » qui vous permet de répartir les dépenses en fonction de n'importe quel tag personnalisé attaché à votre application. L'exportation au format CSV et une API HTTP pour les mesures brutes et agrégées facilitent l'intégration des données dans votre infrastructure financière ou décisionnelle.
• Mise en cache sémantique qui survit aux modifications de routage. Cache sémantique renvoie les réponses précédemment générées pour les requêtes sémantiquement similaires, en utilisant la similarité cosinus sur l'embedding du dernier message utilisateur avec un seuil configurable (point de départ recommandé : 0,9). Les autres paramètres de requête (modèle, messages précédents, température) sont hachés séparément et doivent correspondre exactement, ainsi les accès au cache sont-ils strictement délimités. Les entrées de cache sont isolées par utilisateur/compte virtuel par défaut, avec des espaces de noms personnalisés optionnels pour les applications multi-locataires. Les accès au cache renvoient une réponse en millisecondes sans coût de modèle, indépendamment de la cible que la couche de routage aurait autrement sélectionnée.
• Large éventail de fournisseurs dans une seule évaluation. TrueFoundry achemine les requêtes vers OpenAI, Anthropic (directement et via AWS Bedrock), Azure OpenAI, AWS Bedrock, AWS SageMaker, GCP Vertex AI, Cohere, Together AI, Mistral, Groq, Cerebras, xAI, Databricks, les modèles auto-hébergés et d'autres (la liste complète se trouve sur la page de présentation de la passerelle IA). Les équipes peuvent comparer AWS Bedrock Claude Sonnet 4.5 aux équivalents Azure OpenAI dans un seul test A/B sans travail d'intégration distinct pour chaque fournisseur. La surcharge annoncée de la passerelle est « généralement inférieure à 5 ms » avec un débit soutenu de plus de 350 RPS sur 1 vCPU, ce qui maintient la passerelle hors du chemin critique, même à l'échelle de la production.

Run your first production model A/B test in under 30 minutes with TrueFoundry.

TrueFoundry's AI Gateway handles traffic splitting, cost-per-outcome tracking, and automatic rollback for live model evaluations. Book a demo to see the setup.

Book Demo