Budget de temps et de coûts pour les appels de modèle dans les agents

Objectif

Savoir, avant le déploiement, ce que coûte une exécution de l'agent et combien de temps les utilisateurs attendent, limiter les deux dans le code, et détecter quand une modification fait dériver l'un ou l'autre.

Prérequis

Les champs de consommation que le fournisseur retourne pour chaque appel. La documentation du fournisseur citée sur la mise en cache des prompts décrit, dans l'objet usage, les champs input_tokens, cache_creation_input_tokens et cache_read_input_tokens ; la somme des trois donne le volume d'entrée effectif. À cela s'ajoutent une grille tarifaire des modèles utilisés, un jeu d'évaluation avec des tâches représentatives, et des journaux d'exécution qui attribuent les coûts à des étapes précises.

Étapes

1. Mesurer une ligne de base : pour chaque exécution sur le jeu d'évaluation, consigner le nombre d'appels au modèle, les tokens d'entrée et de sortie, la durée totale et l'appel individuel le plus long.
2. Fixer des budgets par exécution – plafond de tokens, plafond d'étapes, échéance – et les faire appliquer dans la boucle. Lorsqu'un budget est atteint, l'agent obtient un dernier tour pour rendre compte de ce qui est fait et de ce qui ne l'est pas ; une exécution interrompue sans compte rendu est du travail perdu.
3. Réduire d'abord les tokens d'entrée : placer le prompt système, les définitions d'outils et les documents de référence au début, et les marquer pour la mise en cache. La documentation décrit une durée de vie standard de cinq minutes, renouvelée à chaque utilisation sans coût supplémentaire, une durée d'une heure moyennant un supplément, ainsi que l'ordre tools → system → messages, où une modification à un niveau invalide tous les niveaux suivants. Les horodatages et les valeurs propres à chaque requête doivent donc se trouver après la partie mise en cache ; cache_read_input_tokens indique si la mise en cache s'applique.
4. Réduire les tokens de sortie : exiger la sortie la plus courte que l'étape suivante puisse traiter – un appel d'outil, un identifiant, des données structurées – et non un récit.
5. Élaguer le contexte : résumer ou omettre les anciens résultats d'outils, plutôt que de les renvoyer à chaque étape.
6. Déporter le travail hors ligne (exécutions d'évaluation, extraction nocturne) vers le point de terminaison de traitement par lots. La documentation du traitement par lots citée indique 50 % du tarif standard, un achèvement généralement en moins d'une heure, une expiration après 24 heures sans achèvement, et des résultats qui restent accessibles pendant 29 jours.
7. N'utiliser un modèle plus petit que là où le jeu d'évaluation montre qu'il réussit la tâche ; comparer le coût par tâche accomplie, pas par appel.
8. Alerter sur le coût par tâche réalisée et sur la latence au 95e percentile, pas seulement sur la dépense totale.

Résultat attendu

Des coûts et une latence documentés par type de tâche, des budgets appliqués dans le code, et un tableau de bord sur lequel une modification de prompt qui double la consommation de tokens est repérée le jour même.

Limites et base de vérification

Les tarifs, les durées de vie du cache et les conditions du traitement par lots sont des indications du fournisseur et évoluent ; les chiffres proviennent de la documentation citée au moment de la rédaction. Le traitement par lots ne convient pas à un usage interactif. Les budgets arrêtent les exécutions qui dérivent, mais ne les rendent pas moins coûteuses ; seules les étapes 3 à 7 y parviennent.

Élaguer le contexte sans perdre le cache

La mise en cache des prompts compare des préfixes : toute modification apportée à un message antérieur invalide le cache à partir de cet endroit. Qui raccourcit l'historique à chaque tour repaie, à chaque tour, le reste de l'historique, plus le surcoût d'écriture pour la nouvelle entrée. D'où la règle : garder les résultats d'outils petits dès le départ (en-tête plutôt que fichier entier, compteur plutôt que liste, référence plutôt que contenu), n'élaguer l'historique qu'à quelques seuils définis, et le faire en une seule étape, afin que le nouveau préfixe redevienne stable pendant plusieurs tours, puis vérifier le succès sur cache_read_input_tokens, qui doit croître après chaque tour. Les variantes côté serveur telles que l'édition de contexte (context editing) et le compactage fonctionnent, pour la même raison, avec des seuils.