Aperçu du coût et de l’utilisation des jetons de l’optimiseur d’agent

L’optimiseur d’agent dans Service de l’agent Foundry fournit une estimation modélisée des coûts avant la soumission d’un travail d’optimisation. Une fois la tâche terminée, son résultat peut inclure l’utilisation mesurée des jetons. Utilisez l’estimation pour la planification et l’utilisation mesurée pour comprendre l’activité du modèle qui s’est produite pendant l’exécution.

L’estimation préalable à l’exécution et l’utilisation des jetons après l’exécution ont des objectifs différents. Aucune valeur n’est une limite de dépense ou un remplacement de votre facture Azure.

Estimation du coût avant exécution pour les agents de prompt

Avant de créer une tâche d’optimisation d’agent d’invite dans le portail Foundry, l’étape Vérification affiche une estimation du coût pour les paramètres demandés. Les flux d’optimisation de l’agent hébergé n’affichent actuellement pas cette estimation de pré-exécution.

L’estimation prévoit les appels au modèle et les coûts des jetons. La demande d’une estimation ne crée pas de travail d’optimisation ou n’appelle pas les modèles. Le nombre d’appels est calculé à partir des données d’entrée de la tâche. Les valeurs monétaires sont modélisées en appliquant des hypothèses de jeton statique et des prix de modèle de référence à ces nombres d’appels.

Le portail affiche trois valeurs monétaires modélisées :

Le résumé identifie le nombre de candidats, le nombre de lignes du jeu de données, le nombre d’évaluateurs et la date de prix de référence. Développez la répartition des coûts (estimée) pour examiner chaque phase.

Entrées dans l’estimation

L’optimiseur calcule les plages du nombre d’appels à partir de la configuration de tâche résolue. Le calcul utilise ces entrées :

Pour un jeu de données référencé, le service résout son nombre de lignes avant de retourner une estimation. S’il ne peut pas résoudre un nombre de lignes vides, il ne crée pas d’estimation à partir d’une taille de jeu de données supposée.

Pour les exécutions de sélection de modèles, l’estimation ne tarife pas séparément les appels à l’agent pour chaque modèle dans l’espace de recherche. Il utilise le modèle d’agent de base configuré lorsqu’il est disponible. Si ce modèle ne peut pas être résolu, il utilise le prix du modèle d’évaluation pour la couche agent.

Hypothèses de jeton statique

L’estimation sépare l’activité du modèle en couches afin que vous puissiez voir quelle partie de l’exécution contribue au total. Il utilise les hypothèses statiques TokensPerCall suivantes :

Ces hypothèses gérées par le service peuvent changer à mesure que l’estimateur est étalonné. Pour chaque couche, l’optimiseur multiplie la plage du nombre d’appels par les hypothèses statiques concernant les jetons de prompt et d’achèvement. Il applique ensuite des prix de référence datés par million de jetons :

modeled layer cost = calls × ((prompt tokens × input price) + (completion tokens × output price)) / 1,000,000

Le total est la somme des couches qui peuvent être facturées. Si un prix de modèle ou une hypothèse relative aux jetons n’est pas disponible pour une couche donnée, l’estimation identifie la couche non tarifée et l’exclut du total.

Que se passe-t-il pendant une exécution d’optimisation

Pour comprendre les couches de coûts, il permet de savoir comment l’optimiseur utilise chaque modèle en arrière-plan. Un cycle d’optimisation suit cette boucle pour les agents de prompt et les agents hébergés :

1. Évaluez la base de référence (agent + juge). L’optimiseur appelle votre agent sur chaque ligne de jeu de données pour collecter des réponses. Ensuite, le modèle d’évaluation évalue chaque réponse par rapport à chaque évaluateur pour établir des scores de base.
2. Générer un candidat (réflexion). Le modèle d’optimisation reçoit les scores de référence, analyse les faiblesses et produit une configuration améliorée de l’agent. Selon le type d’agent, la configuration peut inclure des instructions réécrites, des compétences affinées, de meilleures descriptions d’outils ou un modèle différent.
3. Évaluez le candidat (agent + juge). L’optimiseur exécute l’agent avec la configuration candidate sur les mêmes lignes de jeu de données et note les réponses.
4. Répétez. Les étapes 2 à 3 se répètent pour chaque candidat supplémentaire. Chaque cycle ajoute une autre série d’appels de réflexion et d’évaluation.

Les trois couches de coût correspondent directement à cette boucle :

• Exécution de votre agent : chaque fois que l’agent est appelé sur une ligne de jeu de données (de référence et chaque candidat).
• Notation des réponses : chaque fois que le modèle d’évaluation juge une réponse contre un évaluateur.
• Génération d’améliorations : chaque fois que le modèle d’optimisation reflète les résultats et produit un nouveau candidat.

Exemple traité : exécution à 2 candidats maximum

L’exemple suivant montre comment la formule s’applique à une configuration de travail concrète. Tous les prix sont à titre d’illustration uniquement.

Paramètres du travail :

Nombre estimé d’appels :

L’optimiseur déduit le nombre d’appels de la configuration de tâche :

Appliquez la formule à chaque couche :

L’optimiseur recherche les prix d’entrée et de sortie de référence datant de chaque modèle et applique la formule. Par exemple, le calcul de la couche agent est :

60 × ((2,000 × <input price>) + (400 × <output price>)) / 1,000,000

Le même schéma s’applique aux couches d’évaluation et de réflexion, chacune s’appuyant sur les hypothèses relatives aux jetons et les prix de référence de son modèle respectif. Le portail additionne ensuite toutes les couches pour produire les valeurs minimales, estimées et maximales affichées à l’étape Révision .

Dans une exécution classique de 2 candidats, la couche de réflexion (modèle d’optimisation) compte pour la plus grande part du coût estimé, car elle utilise un modèle plus capable avec des taux plus élevés par jeton. La couche juge est généralement la moins coûteuse, car elle utilise un modèle d’évaluation plus petit avec des hypothèses de jeton faible par appel.

Hypothèses et limitations d’estimation

L’estimation est une valeur de planification plutôt qu’une charge finale, car elle combine un budget d’appel algorithmique avec une utilisation de jeton modélisée.

• Les hypothèses relatives aux tokens correspondent à des moyennes pour chaque niveau de coût. Le nombre effectif de prompts, de réponses, de raisonnements et de tokens mis en cache varie selon le modèle et la requête.
• Un travail d’optimisation peut s’arrêter tôt après qu’il ne trouve aucune amélioration supplémentaire. L’arrêt anticipé peut réduire l’utilisation réelle en dessous de la valeur estimée ou maximale .
• L’utilisation de l’agent varie en fonction des instructions, des tours de conversation, de la longueur de réponse, des appels d’outils et de la sortie de l’outil.
• Les prix du modèle de référence sont datés et peuvent différer des prix de votre abonnement, région, type de déploiement ou contrat.
• L’estimation n’inclut pas de frais provenant d’API externes, de bases de données, de services de recherche ou d’autres outils que votre agent appelle.
• La valeur maximale n’est pas une limite de dépense.

Utilisation mesurée des jetons après l’exécution

Lorsqu’un travail d’optimisation se termine, son résultat peut inclure la consommation de jetons mesurée pour chaque phase de l’exécution. La vue Utilisation des tokens peut être disponible pour les exécutions de prompt-agent et de hosted-agent.

Pour les agents hébergés, l’exécution de votre utilisation de l’agent est disponible uniquement lorsque l’exemple d’évaluation ou la trace de l’agent inclut des informations d’utilisation de jetons. Si l’agent hébergé ne signale pas d’utilisation, le portail omet la phase de l’agent au lieu de l’indiquer à zéro. Le portail comptabilise séparément l’utilisation de Scoring responses et de Generating improvements lorsque ces appels de modèle signalent leur utilisation.

La vue peut contenir plusieurs lignes pour exécuter votre agent lorsque l’optimiseur évalue plusieurs modèles d’agent.

Le portail calcule un coût estimé à partir de l’utilisation des jetons mesurés et des prix du modèle de référence. Sélectionnez Afficher la tarification pour passer en revue la source de tarification. L’estimation n’est pas le montant final facturé.

Une phase ou une valeur de jeton manquante signifie que l’utilisation n’a pas été mesurée. Cela ne signifie pas que la phase n’a utilisé aucun jeton ou qu’elle n’a entraîné aucun frais. Certains agents hébergés et certains travaux d’optimisation plus anciens peuvent ne pas fournir de données d’utilisation de l’agent.

Le résultat de la tâche sous-jacente peut contenir davantage de détails sur les jetons mis en cache et les jetons de raisonnement. Les jetons mis en cache sont un sous-ensemble de jetons d’entrée, et les jetons de raisonnement sont un sous-ensemble de jetons de sortie. N’ajoutez pas ces valeurs de sous-ensemble aux totaux d’entrée ou de sortie.

Calculer le coût du modèle à partir de l’utilisation mesurée

L’utilisation des jetons mesurés est plus représentative que les hypothèses de pré-exécution, mais elle signale le nombre de jetons plutôt que le montant facturé final. Appliquez la tarification de chaque ligne de modèle pour estimer le coût du modèle :

approximate model cost = ((input tokens × input price) + (output tokens × output price)) / 1,000,000

Si l’utilisation détaillée fournit un nombre de jetons mis en cache et que le modèle a un taux d’entrée mis en cache distinct, soustrayez les jetons mis en cache du total d’entrée et prix des parties mises en cache et non mises en cache séparément.

Calculez séparément chaque phase et ligne de modèle, puis ajoutez les résultats. Si une ligne n’identifie pas un modèle, vous ne pouvez pas appliquer de manière fiable un prix spécifique au déploiement à cette utilisation.

Utilisez les tarifs qui s’appliquent à votre abonnement, région, type de déploiement et contrat de facturation. Pour connaître les tarifs publiés, consultez Azure OpenAI Service tarification. Le résultat exclut toujours les frais des outils et services externes.

Contenu connexe

• Vue d’ensemble de l’optimiseur d’agent
• Démarrage rapide : Optimiser un agent de prompt
• Démarrage rapide : Optimiser un agent hébergé