Selon des rapports, un projet interne d'Amazon utilisant Claude Sonnet d'Anthropic a accumulé une facture de 1,8 million de dollars, dépassa...
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é.
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 :
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 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 :
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.
Dépassements
Selon les informations, le même rapport interne aurait également abordé au moins deux autres cas.
| Projet | Coûts imprévus signalés |
|---|---|
| Outil d'audit financier | Environ 541 000 dollars |
| Projet logistique visant à améliorer la vitesse de livraison | Environ 134 000 dollars |
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.
Les coûts des applications traditionnelles sont généralement liés à des unités relativement familières :
Les flux de travail d'IA peuvent en revanche cumuler simultanément plusieurs niveaux de facturation à l'usage :
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.
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 :
| Composante de coût | Mode de calcul |
|---|---|
| Coût d'entrée | Nombre de tokens d'entrée × prix d'entrée du modèle |
| Coût de sortie | Nombre de tokens de sortie × prix de sortie du modèle |
| Coût des outils | Nombre d'appels d'outils × prix de l'outil |
| Coût des nouvelles tentatives | Nombre d'échecs ou de répétitions × coût moyen par tentative |
| Coût de l'infrastructure | Calcul, stockage, base de données, réseau et journaux |
| Coût de la vérification humaine | Temps de vérification × taux horaire incluant les coûts de main-d'œuvre |
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.
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 :
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 :
| Niveau | Exemple |
|---|---|
| Organisation | Plafond mensuel des dépenses IA |
| Équipe | Quota mensuel pour une unité métier |
| Application | Budget pour un produit ou un flux de travail |
| Environnement | Limites distinctes pour le développement, la préproduction et la production |
| Tâche | Coût maximal pour un lot |
| Utilisateur ou locataire | Quota d'utilisation par client |
| Session d'agent | Nombre maximal de tokens, d'étapes, d'outils et de temps |
Les niveaux inférieurs offrent le mécanisme de freinage le plus rapide et le plus efficace.
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 :
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.
Les agents autonomes ne doivent pas avoir le contrôle final sur leurs propres limites de dépenses.
Un service indépendant doit pouvoir :
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.
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 :
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.
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.
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 :
Plus le flux de travail dépense de l'argent rapidement, plus les contrôles doivent être proches du point d'appel.
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.
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
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 :
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.
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.
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 à :
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.
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 :
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.
Tous les enregistrements n'ont pas besoin d'un modèle de pointe.
Un pipeline soucieux des coûts peut utiliser :
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.
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 :
Les erreurs ne devraient pas créer de boucle économique infinie.
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.
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 :
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.
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.
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.
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.
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.
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.
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é.
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.
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.
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.
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.
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.
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.
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.
É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.
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.
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.
Partez d’une phrase et obtenez un site complet en quelques minutes.
