Dépassement de coût de 1,8 million de dollars sur Claude chez Amazon : comment éviter une perte de contrôle des dépenses en IA

Introduction

Selon les informations rapportées, un projet interne d'Amazon utilisant Claude Sonnet d'Anthropic a accumulé une facture de 1,8 million de dollars, dépassant le budget prévu de 860 %, sans être détecté pendant cinq mois, pour finalement ne jamais être mis en production.

La tâche en elle-même semblait des plus courantes : faire correspondre des informations sur les auteurs avec les fiches produits de la plateforme de commerce électronique d'Amazon.

L'affaire a été rapportée par le Financial Times après qu'un ingénieur senior d'Amazon a évoqué plusieurs dépassements de coûts liés à l'IA lors d'une réunion interne avec les employés. Elle constitue un avertissement utile pour toute organisation qui passe d'une utilisation occasionnelle de chatbots à des flux de travail automatisés, susceptibles de générer des milliers, voire des millions d'appels de modèles payants chaque jour.

Les bogues logiciels traditionnels gaspillent souvent du temps d'ingénierie ou produisent des sorties erronées. Or, les défauts dans les flux de travail d'IA facturés à l'usage peuvent provoquer ces deux conséquences à la fois, tout en continuant à générer des frais de tokens, d'outils, de stockage et de calcul à chaque minute où ils restent actifs.

La leçon n'est pas que les entreprises devraient cesser d'utiliser l'IA, mais plutôt que les processus d'IA autonomes ou à haut volume nécessitent des contrôles financiers aussi clairs que leurs contrôles de sécurité et de qualité.

Ce qui s'est passé en interne chez Amazon

Selon des sources informées, Amazon a utilisé Claude Sonnet dans un projet visant à faire correspondre les informations sur les auteurs avec les fiches produits de sa plateforme de vente au détail.

D'après les informations rapportées, ce déploiement :

• A coûté 1,8 million de dollars
• A dépassé le budget alloué de 860 %
• A mis cinq mois à être découvert
• N'a jamais atteint l'environnement de production

Des ingénieurs seniors ont qualifié certaines erreurs de codage liées à l'IA de « catastrophiquement coûteuses ».

Amazon a répondu qu'ils expérimentaient, apprenaient et amélioraient leur façon d'utiliser cette technologie, notamment en ce qui concerne la gestion de la rentabilité. L'entreprise a également déclaré que présenter quelques cas isolés comme une pratique courante ne reflétait pas précisément l'utilisation de l'IA au sein de l'organisation plus large d'Amazon.

Ces deux affirmations peuvent être vraies.

Ces incidents peuvent ne concerner qu'une petite partie des équipes d'Amazon, mais ils révèlent également un problème de contrôle que d'autres organisations devraient prendre au sérieux.

Le défaut de codage spécifique n'a pas été divulgué

Le rapport initial en chinois attribuait le dépassement à un programme sans limitation de fréquence d'appels, qui envoyait en continu des requêtes en boucle.

Cette explication est plausible, mais elle n'a pas encore été confirmée par les reportages publics actuels.

Le Financial Times a décrit des erreurs de codage, des contrôles de dépenses insuffisants et un retard dans la détection. Il n'a pas publié d'analyse post-incident technique indiquant :

• Le code source
• Le défaut précis
• Si le processus était une boucle infinie
• Le nombre d'appels de modèles
• Le nombre de tokens d'entrée ou de sortie
• Si le modèle était accédé directement ou via Amazon Bedrock
• La version du modèle
• La configuration d'utilisation des outils
• Les composants d'infrastructure ayant généré les coûts

La conclusion la plus sûre est plus prudente : un déploiement raté de Claude Sonnet a généré une facture considérable, et les systèmes de contrôle d'Amazon n'ont pas réussi à détecter le problème pendant cinq mois.

À moins qu'Amazon ne publie un rapport technique d'incident, toute explication plus détaillée doit être considérée comme une déduction.

Ce n'est pas le seul problème de coûts

Dépassements

Selon les informations, le même rapport interne aurait également abordé au moins deux autres cas.

D'après les informations, le dépassement logistique a mis plus de deux semaines à être détecté.

Ces cas sont de plus petite ampleur que le projet de correspondance des auteurs à 1,8 million de dollars, mais ils pointent vers le même schéma : lorsqu'aucune panne technique ne force l'arrêt d'un processus, les systèmes d'IA basés sur l'utilisation peuvent accumuler continuellement des coûts.

Les traitements par lots traditionnels peuvent planter, manquer de mémoire ou échouer aux tests.

Or, les processus d'IA peuvent rester techniquement sains tout en étant économiquement en faillite.

Même si un projet ne produit plus de résultats utiles, il peut continuer à recevoir des réponses API réussies, écrire des journaux, appeler des outils, réessayer des tâches ou traiter des enregistrements de faible valeur.

Pourquoi les défaillances de coûts liées à l'IA se manifestent différemment

Les coûts des applications traditionnelles sont généralement liés à des unités relativement familières :

• Temps serveur
• Capacité de base de données
• Stockage
• Transfert réseau
• Heures de travail humain

Les flux de travail d'IA peuvent en revanche cumuler simultanément plusieurs niveaux de facturation à l'usage :

• Tokens d'entrée
• Tokens de sortie
• Contexte en cache et non en cache
• Tokens de raisonnement
• Appels d'outils
• Recherches web
• Sessions d'exécution de code
• Recherches vectorielles
• Nouvelles tentatives d'agent
• Processus de travail parallèles
• Historiques de conversation longs
• Ressources de cloud computing
• Sorties de journaux et de stockage

Cela crée un effet multiplicateur.

Supposons qu'une tâche envoie une très longue invite, génère une réponse volumineuse, appelle deux outils, réessaie après une erreur et transmette l'historique complet à l'étape suivante. Si l'application traite des millions d'enregistrements, une petite erreur de conception peut devenir extrêmement coûteuse.

D'un point de vue opérationnel, l'application peut sembler parfaitement normale. Les requêtes renvoient toujours 200 OK. Les processus de travail restent actifs. Les files d'attente diminuent. La facture est souvent le premier endroit où le problème se révèle.

Un modèle de coûts simple pour les flux de travail d'IA

Avant de lancer un processus d'IA automatisé, estimez d'abord le coût par tâche métier accomplie.

Un modèle simplifié se présente ainsi :

L'indicateur clé n'est pas simplement le coût par token.

C'est :

Coût total par résultat métier accompli avec succès

Une requête moins chère peut néanmoins produire un flux de travail plus coûteux si elle a un taux d'échec plus élevé, nécessite des appels répétés ou génère davantage de vérification humaine.

De même, un modèle plus puissant peut en fin de compte coûter moins cher s'il accomplit la tâche en moins d'étapes.

Premier contrôle : désigner un responsable financier pour chaque tâche d'IA

Chaque flux de travail d'IA en production doit avoir un responsable nommé, en charge à la fois du comportement technique et des dépenses.

Ce responsable doit connaître :

• Le volume d'activité attendu
• Le modèle utilisé
• Le coût prévu par unité
• Les budgets quotidien et mensuel
• Le coût maximal par exécution
• Les conditions d'arrêt du flux de travail
• Les personnes à alerter
• Le processus d'approbation pour des limites plus élevées

Lorsqu'un seul processus de travail peut émettre des requêtes en continu, un budget vague au niveau du projet ne suffit pas.

Les budgets doivent exister à plusieurs niveaux :

Les niveaux inférieurs offrent le mécanisme de freinage le plus rapide et le plus efficace.

Définir des limites strictes à l'intérieur de l'application

Les alertes de facturation cloud sont importantes, mais elles ne remplacent pas les contrôles au niveau de l'application.

L'application doit s'arrêter ou exiger une approbation lorsqu'elle atteint les limites définies.

Les limites utiles incluent :

• Nombre maximal de requêtes par tâche
• Nombre maximal d'étapes pour l'agent
• Nombre maximal de nouvelles tentatives
• Nombre maximal de tokens d'entrée
• Nombre maximal de tokens de sortie
• Longueur maximale du contexte
• Nombre maximal d'appels d'outils
• Nombre maximal de processus de travail parallèles
• Durée maximale
• Coût maximal en dollars par tâche
• Nombre maximal d'enregistrements traités avant vérification

Ces contrôles doivent être désactivés par défaut.

Si le service de suivi des coûts n'est pas disponible, ou si l'application ne peut pas déterminer le budget restant, le comportement le plus sûr est généralement de suspendre plutôt que de continuer indéfiniment.

Utiliser un interrupteur d'arrêt d'urgence indépendant de l'agent

Les agents autonomes ne doivent pas avoir le contrôle final sur leurs propres limites de dépenses.

Un service indépendant doit pouvoir :

• Désactiver les clés API
• Refuser les appels de modèles
• Suspendre les files d'attente
• Réduire les processus de travail à zéro
• Bloquer les outils externes
• Révoquer les rôles
• Arrêter les tâches planifiées
• Exiger une approbation humaine avant la reprise

Même si l'agent est pris dans une boucle de nouvelles tentatives ou produit des messages d'état trompeurs, l'interrupteur d'arrêt d'urgence doit rester accessible.

Testez-le en environnement de production.

Un contrôle qui n'a jamais été utilisé n'est qu'une théorie.

Surveiller chaque appel de modèle

Les organisations utilisant Amazon Bedrock peuvent activer la journalisation des appels de modèles pour les appels bedrock-runtime pris en charge.

AWS indique que ces journaux peuvent inclure les données de requête et de réponse, les métadonnées, les identifiants de modèle, les identifiants de requête, les informations d'identité et l'utilisation des tokens. Les destinations des journaux peuvent inclure Amazon CloudWatch Logs et Amazon S3.

La journalisation des appels est désactivée par défaut.

L'équipe ne devrait activer que les données nécessaires à l'observabilité et appliquer les contrôles appropriés en matière de confidentialité, de sécurité, de conservation et de masquage. Les invites et les sorties peuvent contenir des informations sensibles sur l'entreprise ou les clients.

Au minimum, les enregistrements de suivi des coûts devraient inclure :

• Horodatage
• Application
• Environnement
• Équipe ou centre de coûts
• Modèle
• Utilisateur ou locataire
• Nombre de jetons d'entrée
• Nombre de jetons de sortie
• Utilisation du cache
• Appels d'outils
• Nombre de nouvelles tentatives
• Identifiant de tâche
• Coût estimé de la requête
• Résultat commercial
• Erreurs ou raisons d'escalade

Cela permet de relier la facturation à des tâches spécifiques plutôt que de découvrir une somme globale importante lors de l'examen financier mensuel.

Suivi des coûts Claude sur Bedrock avec AWS Budgets

AWS Budgets permet de suivre les coûts ou l'utilisation par rapport à des seuils définis et d'envoyer des notifications. Les actions de budget peuvent également appliquer des mesures de contrôle, telles que des politiques IAM ou des politiques de contrôle des services, lorsque les seuils sont dépassés. Selon la configuration, les actions peuvent s'exécuter automatiquement ou attendre une approbation humaine.

Un détail important spécifique à AWS est facile à négliger.

La documentation sur la détection d'anomalies de coûts AWS indique que ce service ne surveille pas les produits tiers vendus via l'AWS Marketplace, y compris les modèles de langage tiers proposés via Amazon Bedrock, comme Anthropic Claude.

Ces frais apparaissent toujours dans Cost Explorer et sur la facture, mais AWS recommande d'utiliser AWS Budgets pour être alerté sur ces dépenses.

Les budgets peuvent utiliser des filtres d'entité de facturation pour suivre plus précisément les frais du Marketplace.

C'est exactement le type de détail de configuration qui peut créer un faux sentiment de sécurité. Une entreprise peut activer la détection d'anomalies et penser que tous les coûts de modèles sont couverts, alors qu'une catégorie de facturation spécifique n'est pas incluse.

Ne pas utiliser AWS Budgets comme coupe-circuit en temps réel

La documentation AWS indique que l'état des budgets est mis à jour plusieurs fois par jour.

La documentation avertit également que les coûts peuvent continuer à augmenter avant ou après la livraison des notifications.

Cela signifie qu'AWS Budgets est utile pour la gouvernance financière, mais qu'utilisé seul, il pourrait ne pas arrêter suffisamment rapidement un agent à haut débit.

La pile de contrôle devrait inclure :

1. Compteurs au niveau des requêtes dans l'application
2. Indicateurs d'utilisation en quasi-temps réel
3. Plafonds stricts par tâche et par session
4. Alertes budgétaires cloud
5. Actions budgétaires automatisées lorsque approprié
6. Examens financiers quotidiens pour les lancements à haut risque

Plus le flux de travail dépense de l'argent rapidement, plus les contrôles doivent être proches du point d'appel.

Utiliser la détection d'anomalies pour les coûts dans la couverture du service

AWS Cost Anomaly Detection utilise des modèles d'apprentissage automatique pour identifier les schémas de dépenses anormaux et aider à localiser les causes profondes possibles.

AWS indique que ce service évalue les données de facturation traitées environ trois fois par jour.

Il peut détecter efficacement les croissances inattendues dans les services AWS, les comptes, les régions, les types d'utilisation et les balises d'allocation des coûts.

Pour les systèmes d'IA, il peut identifier des anomalies dans les coûts de support impliquant le calcul, le stockage, les bases de données ou le réseau.

Cependant, les équipes doivent se souvenir de la limitation du Marketplace mentionnée ci-dessus et créer séparément des AWS Budgets pour les frais des modèles tiers si nécessaire.

Considérer Service Quotas comme une frontière de sécurité, pas comme un budget

Amazon Bedrock applique des quotas de service à l'inférence des modèles, y compris des limites basées sur les jetons pour les modèles et points de terminaison pris en charge.

Les quotas empêchent un débit illimité, mais ils ne sont pas conçus comme des budgets financiers précis.

Les quotas peuvent encore permettre des dépenses bien supérieures aux limites prévues du projet. À l'inverse, augmenter les quotas pour résoudre des problèmes de capacité de production peut retirer involontairement une frontière de sécurité utile.

Par conséquent, les modifications de quotas devraient exiger :

• Une justification commerciale
• Des prévisions de coûts mises à jour
• Une approbation nominative
• Des seuils d'alerte mis à jour
• Un plan de rollback
• Un examen après l'augmentation du trafic

Les limites de débit et de jetons devraient être considérées comme faisant partie de la conception des risques système, et pas seulement comme des obstacles à la mise à l'échelle.

Suivre directement l'utilisation et les coûts Anthropic lorsque approprié

Pour les applications qui appellent directement Anthropic, la console Anthropic fournit des rapports de coûts et d'utilisation.

Les limites de l'API Anthropic peuvent inclure des demandes par minute, des jetons d'entrée par minute, des jetons de sortie par minute, ainsi que des limites de dépenses liées au niveau d'utilisation.

Ces limites peuvent réduire le débit non contrôlé, mais devraient toujours être complétées par des contrôles au niveau de l'application.

Les organisations ayant plusieurs équipes peuvent également déployer une passerelle LLM entre les applications et le fournisseur de modèles. La passerelle peut centraliser l'authentification, le suivi de l'utilisation, les budgets, les limites de débit, le routage des modèles et les journaux d'audit.

La passerelle devient un composant de sécurité critique et doit donc être exploitée et examinée avec la même rigueur que tout autre couche d'accès de production.

Commencer par un petit échantillon représentatif

Il est rapporté qu'un projet Amazon a tenté d'exécuter une tâche de correspondance de données à grande échelle.

Un modèle de déploiement plus sûr consiste à :

1. Exécuter 100 enregistrements représentatifs.
2. Mesurer la précision et les coûts.
3. Exécuter 1 000 enregistrements.
4. Vérifier les erreurs et la distribution des jetons.
5. Tester les entrées dans le pire des cas.
6. Confirmer les contrôles d'arrêt.
7. Estimer les dépenses pour le traitement complet.
8. Exiger une approbation avant de traiter l'ensemble du jeu de données.

Ne pas extrapoler uniquement à partir de l'enregistrement moyen.

Les documents les plus longs, les enregistrements en échec de correspondance, les cas ambigus, les nouvelles tentatives et les boucles d'agents dominent souvent le coût total.

Utiliser des estimations par centiles, comme les coûts P50, P95 et P99 par tâche.

Fixer un plafond de coût maximal par résultat valide

Le flux de travail devrait s'arrêter lorsque des appels de modèles supplémentaires ne sont plus économiquement justifiés.

Pour un système de correspondance d'auteurs, les indicateurs utiles pourraient inclure :

• Coût par correspondance d'auteur réussie
• Coût par enregistrement examiné manuellement
• Pourcentage d'enregistrements résolus automatiquement
• Taux de fausses correspondances
• Coût des fausses correspondances
• Économies par rapport au traitement manuel
• Nombre d'appels de modèles requis par résultat accepté

Un processus qui coûte 0,02 $ par requête peut sembler bon marché.

S'il nécessite 50 appels, que la moitié des enregistrements échouent et que le reste est envoyé à un examen manuel, l'économie réelle peut être très mauvaise.

Router les tâches simples vers des méthodes moins coûteuses

Tous les enregistrements n'ont pas besoin d'un modèle de pointe.

Un pipeline soucieux des coûts peut utiliser :

1. Correspondance exacte
2. Jointures de base de données
3. Règles
4. Similarité d'intégrations
5. Modèles plus petits
6. Modèles plus puissants uniquement pour les cas ambigus
7. Examen humain pour les décisions à haut risque

Pour les projets de correspondance de données, les logiciels traditionnels peuvent résoudre la plupart des cas à moindre coût et de manière plus déterministe.

Les LLM ne devraient être utilisés que lorsque l'ambiguïté linguistique l'exige réellement, et non automatiquement pour chaque ligne.

Les propres directives tarifaires d'Anthropic recommandent de choisir le modèle approprié, d'utiliser la mise en cache des invites pour les contextes répétitifs, le traitement par lots pour les travaux non urgents, et de surveiller les schémas d'utilisation.

Empêcher les nouvelles tentatives illimitées

Les nouvelles tentatives sont une source courante de dépenses implicites.

Une requête échouée peut être retentée par l'application, le système de file d'attente, le SDK, la passerelle, le gestionnaire de workers, l'agent ou l'orchestrateur de flux de travail.

Lorsque plusieurs couches réessaient indépendamment, une tâche logique peut produire plusieurs requêtes payantes.

Définir une stratégie de nouvelle tentative unifiée incluant :

• Un nombre maximal de tentatives faible
• Un backoff exponentiel
• De la gigue (jitter)
• Un traitement explicite des erreurs non réessayables
• De l'idempotence
• Des files d'attente mortes
• Des alertes en cas d'échecs répétés
• Un budget par tâche incluant tous les coûts associés, y compris les nouvelles tentatives

Les erreurs ne devraient pas créer de boucle économique infinie.

Séparer les identifiants de développement et de production

Les scripts de test ne devraient pas hériter des limites de niveau production.

Utiliser des comptes ou espaces de travail séparés, des clés API, des rôles IAM, des budgets, des quotas, des journaux, des sources de données et des permissions réseau distincts.

L'environnement de développement devrait avoir des plafonds de dépenses volontairement bas.

Un prototype qui entre accidentellement dans une boucle devrait échouer avec une petite facture, plutôt que d'obtenir des quotas de production de niveau entreprise.

Examiner le code généré par l'IA comme une infrastructure financière de production

L'incident impliquait un projet assisté par l'IA, mais le problème clé n'était pas de savoir si le code avait été généré par un modèle.

La question importante est de savoir si le code est susceptible de dépenser de l'argent.

Tout composant capable d'initier des requêtes de modèles payantes devrait être soumis à un examen incluant :

• Terminaison de boucle
• Comportement de nouvelle tentative
• Concurrence
• Extension de file d'attente
• Contexte maximal
• Limites d'appels d'outils
• Gestion des délais d'attente
• Mécanismes d'annulation
• Attribution des coûts
• Chemins d'erreur
• Journalisation
• Exécution budgétaire
• Comportement d'arrêt d'urgence

Les tests unitaires devraient inclure des scénarios d'échec économique.

Des exemples incluent : le modèle qui ne renvoie jamais de réponse valide, la livraison de tâches en double, le plantage du worker après un appel payant, des erreurs de limite de débit répétées, un contexte qui croît à chaque tour à cause des sorties d'outils, et le service d'estimation des coûts indisponible.

Un chemin nominal fonctionnellement correct est loin d'être suffisant.

Liste de contrôle pour le contrôle des coûts IA de niveau production

Propriété et planification

• Un responsable technique désigné est responsable des dépenses.

• L'utilisation et le coût prévus par résultat réussi sont documentés.

[ ] Les environnements de développement, de préproduction et de production disposent de budgets indépendants.

• Le traitement à grande échelle nécessite une approbation explicite.

Contrôles applicatifs

• Chaque tâche dispose de plafonds maximaux de requêtes, de tokens, d'étapes, de nouvelles tentatives et de temps d'exécution.

• Chaque session d'agent dispose d'un budget libellé en dollars.

• Les services non liés aux agents peuvent arrêter le flux de travail.

• La tâche est suspendue lorsqu'il est impossible de lire le budget restant.

• L'idempotence empêche les travaux en double.

Surveillance

• Chaque appel de modèle est rattaché à une équipe, un projet, un utilisateur et une tâche.

• L'utilisation des entrées, sorties, caches, outils et nouvelles tentatives est consignée.

• Des alertes sont configurées à la fois sur le rythme de dépense et sur la dépense totale.

• Une revue quotidienne est activée lors de la mise en service initiale en production.

• Les équipes connaissent les postes de dépense non couverts par la détection des anomalies.

Qualité et économique

• Le coût est mesuré par résultat opérationnel réussi.

• Des codes conventionnels et des modèles plus petits sont utilisés lorsque cela est approprié.

• Les scénarios pessimistes et les coûts à haut percentile ont été testés.

• Les coûts de revue humaine sont inclus.

• Le flux de travail s'arrête lorsque des appels supplémentaires n'apportent plus de valeur.

Gouvernance

• Le code généré par l'IA fait l'objet d'une revue humaine.

• Les augmentations de budget et de quota nécessitent une approbation.

• L'interrupteur d'urgence est testé.

• La réponse aux incidents implique les parties prenantes financières et techniques.

• Les équipes examinent les dépenses après chaque modification majeure de modèle ou de prompt.

Enseignements de la réponse d'Amazon

Selon des rapports, les ingénieurs d'Amazon construisent des garde-fous automatisés pour les futurs projets d'IA.

C'est la bonne direction,

mais l'automatisation doit exister à plusieurs niveaux.

Un système de contrôle mature doit combiner des plafonds durs applicatifs, des limites de modèle et de passerelle, des budgets cloud, des actions automatisées, des journaux d'utilisation, des tableaux de bord financiers, des approbations humaines et des revues périodiques.

L'entreprise avait également supprimé un classement interne qui encourageait les employés à maximiser l'utilisation de leur outil de développement Kiro. Selon le Financial Times, ce classement favorisait le « tokenmaxxing », un phénomène où les employés augmentaient leur consommation de tokens pour améliorer leur classement.

C'est un rappel utile : les incitations peuvent affaiblir la maîtrise des coûts.

Si les employés sont récompensés pour utiliser davantage l'IA plutôt que pour créer une valeur commerciale mesurable, l'utilisation augmentera même si les résultats ne s'améliorent pas.

Les organisations devraient récompenser les problèmes résolus, l'amélioration de la qualité, le temps gagné, les revenus générés, les risques réduits et la baisse du coût unitaire de production.

Le nombre de tokens est une mesure d'entrée, pas une mesure de productivité.

Questions fréquentes

Amazon a-t-elle réellement dépensé 1,8 million de dollars sur Claude Sonnet ?

Le Financial Times a rapporté qu'un projet interne d'Amazon utilisant Claude Sonnet a accumulé une facture de 1,8 million de dollars. Ce projet, destiné à faire correspondre des informations sur les auteurs avec des fiches de commerce électronique, a dépassé son budget de 860 % et n'a jamais été mis en service.

Pourquoi le dépassement de coûts n'a-t-il pas été détecté en cinq mois ?

Selon les informations publiques, Amazon manquait de contrôles de dépenses suffisants et des erreurs de codage ont été l'un des facteurs du problème. Amazon n'a pas publié d'analyse post-mortem technique pour identifier le défaut précis ou les défaillances de surveillance.

Le problème était-il dû à des boucles d'IA infinies ?

Cette explication est apparue dans certains reportages secondaires, mais elle n'a pas été confirmée par les principaux médias. Le nombre exact de requêtes, la logique de nouvelle tentative, les volumes de tokens et les défauts du code source restent inconnus.

Amazon a-t-elle d'autres cas de dépassement de coûts liés à l'IA ?

Oui. La même présentation interne contiendrait également des coûts imprévus d'environ 541 000 dollars pour un projet d'audit financier, ainsi que 134 000 dollars pour un projet logistique.

AWS Cost Anomaly Detection peut-il surveiller les frais de Claude sur Amazon Bedrock ?

La documentation AWS indique que Cost Anomaly Detection ne surveille pas les produits tiers de l'AWS Marketplace, y compris les modèles Anthropic Claude sur Bedrock. AWS recommande d'utiliser AWS Budgets pour gérer ces frais et, le cas échéant, des filtres par entité de facturation.

AWS Budgets peut-il bloquer immédiatement les dépenses d'IA incontrôlées ?

Pas à lui seul. AWS indique que les informations budgétaires sont mises à jour plusieurs fois par jour et que les coûts peuvent continuer à augmenter avant et après la période de notification. Les applications à fort trafic nécessitent des plafonds durs au niveau des requêtes ainsi qu'un interrupteur d'arrêt d'urgence indépendant.

Les limites de débit équivalent-elles à des limites de dépenses ?

Non. Les limites de débit contrôlent le volume de requêtes, tandis que les budgets contrôlent les coûts acceptables. Un flux de travail peut fonctionner dans les limites de débit tout en dépassant largement les dépenses prévues sur des semaines ou des mois.

Quel est le contrôle le plus important pour les agents d'IA ?

Établir un budget dur pour chaque session d'agent incluant requêtes, tokens, outils, nouvelles tentatives et temps. Appliquer ce budget en dehors de l'agent et disposer d'un moyen testé pour arrêter immédiatement le flux de travail.

Outils associés

• AWS Budgets : permet de suivre les coûts et l'utilisation par rapport à des seuils et de déclencher des notifications ou des actions budgétaires configurées.
• AWS Cost Anomaly Detection : détecte les modèles de dépenses AWS anormaux dans les catégories de facturation prises en charge.
• AWS Cost Explorer : aide les équipes à analyser les coûts et l'utilisation historiques par service AWS et par dimension de facturation.
• Journaux d'appels de modèles Amazon Bedrock : consigne les appels de modèles pris en charge et les métadonnées associées dans CloudWatch Logs ou Amazon S3.
• Quotas de service Amazon Bedrock : indique les limites de modèles et de points de terminaison qui peuvent restreindre le débit d'inférence.
• Console Anthropic : fournit des clés API, des rapports d'utilisation et de coûts, des espaces de travail et des contrôles au niveau du compte pour une utilisation directe de l'API Anthropic.

Liens connexes

• Financial Times : Dépassement des dépenses d'IA chez Amazon : reportage principal sur le projet de 1,8 million de dollars et les dépassements de coûts internes supplémentaires.
• Documentation AWS Budgets : guide officiel sur le suivi des coûts et de l'utilisation AWS par rapport aux budgets.
• Actions AWS Budgets : explique les actions automatisées ou nécessitant une approbation humaine lorsque les seuils sont dépassés.
• Limites d'AWS Cost Anomaly Detection : documente la surveillance des anomalies et l'exclusion des frais de modèles tiers du Marketplace.
• [Journaux d'appels Amazon Bedrock](https://docs.aws.amazon.

com/bedrock/latest/userguide/model-invocation-logging.html) : Guide officiel sur la configuration et le traitement des données pour la journalisation des appels de modèles Bedrock.

• Rapports de coûts et d'utilisation Anthropic : Présente les rapports de coûts, d'utilisation, de tokens, de modèles, d'espaces de travail et de limites de débit dans la console Anthropic.
• Limites de débit de l'API Anthropic : Décrit les limitations relatives au nombre de requêtes, aux tokens d'entrée, aux tokens de sortie et aux niveaux d'utilisation.

Résumé

Selon les rapports, un projet interne d'Amazon utilisant Claude Sonnet a coûté 1,8 million de dollars, dépassant le budget de 860 %, sans être détecté pendant cinq mois, et n'a jamais été mis en production. D'autres projets d'IA auraient généré des dépenses imprévues de plusieurs centaines de milliers de dollars.

Les archives publiques ne confirment pas que l'incident principal ait été causé par une boucle de requêtes infinie. Ce que les archives confirment, c'est l'écart entre la vitesse à laquelle les flux de travail d'IA dépensent et la rapidité avec laquelle les organisations détectent les problèmes.

Les entreprises devraient combiner le suivi des requêtes individuelles, des budgets au niveau des tâches, des limites de tokens et d'outils, des tentatives contrôlées, du routage des modèles, des budgets cloud, des actions automatisées, ainsi qu'un interrupteur d'arrêt d'urgence que les agents ne peuvent pas contourner.

**

La règle la plus sûre est simple : aucun processus d'IA ne devrait fonctionner pendant cinq mois sans avoir démontré à plusieurs reprises qu'il reste utile, dans les limites du budget et autorisé à continuer.