Amazon Bedrock : un data lake pour analyser la consommation et les coûts en tokens
Les équipes plateforme et machine learning qui exploitent Amazon Bedrock à grande échelle disposent désormais d'une architecture de référence pour centraliser l'observabilité de leurs appels aux modèles. Publiée par AWS sous forme d'exemple, accompagnée de deux modèles CloudFormation, de code Lambda et de requêtes SQL dans le dépôt GitHub « Bedrock Invocation Data Lake », la solution rassemble dans un lac de données unique les journaux d'invocation de tous les comptes d'une organisation. Chaque compte source active la journalisation Bedrock par un appel d'API vers un groupe de journaux CloudWatch. Un filtre d'abonnement transmet ensuite chaque nouvel événement vers une destination CloudWatch Logs hébergée dans un compte central. Les données transitent par Amazon Data Firehose, puis sont exposées via Amazon Athena sous la forme d'une table consolidée. Pour chaque invocation, on retrouve le prompt envoyé, la réponse du modèle, le nombre de jetons en entrée et en sortie, le modèle utilisé, la raison d'arrêt (par exemple « max_tokens », signe d'une réponse tronquée), le compte, l'horodatage et le rôle IAM à l'origine de l'appel.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'enjeu est très concret pour les organisations qui lancent des milliers d'appels par jour sur plusieurs comptes. Aujourd'hui, elles voient surtout la facture agrégée, sans pouvoir comprendre ce qui s'est passé dans chaque requête : impossible d'expliquer un pic de consommation, de repérer des prompts inutilement lourds ou de distinguer l'usage d'une équipe de celui d'une autre. Avec une table unique interrogeable en SQL, il devient possible de passer d'un constat global du type « nous avons consommé X jetons » à une analyse fine du contenu et de l'efficacité de chaque appel, et de dériver un coût par invocation. Cela ouvre la voie à une imputation des coûts par équipe, à l'optimisation des prompts, au suivi de l'utilisation des modèles et à l'évaluation de la qualité des réponses. Le déploiement par infrastructure as code garantit en outre que le dispositif peut être répliqué de façon reproductible sur l'ensemble des comptes.
Cette initiative répond à une limite connue de la journalisation native de Bedrock. Celle-ci fournit déjà un enregistrement complet des requêtes et des réponses, livré vers Amazon S3 ou CloudWatch, mais les données restent cloisonnées dans chaque compte AWS, ce qui empêche toute vue transversale. L'architecture en cinq étapes comble ce manque : Bedrock écrit le journal, CloudWatch le transmet au compte central, puis une petite fonction Lambda nettoie les enregistrements. Elle est nécessaire car CloudWatch livre les événements regroupés en lots, compressés et encodés, illisibles en l'état. La fonction les décompresse et les reconvertit en enregistrements individuels avant leur aplatissement dans la table traitée. Sur le plan de la sécurité, les comptes sources ne reçoivent aucune permission sur le pipeline central : ils remettent simplement leurs événements à la destination, et c'est le rôle du compte central qui assure la suite. Cette approche s'inscrit dans la montée des pratiques de FinOps et d'observabilité appliquées à l'IA générative, à mesure que les entreprises déploient ces modèles à grande échelle.
Les entreprises françaises et européennes utilisant Bedrock sur plusieurs comptes peuvent s'appuyer sur cette architecture pour suivre leurs coûts, mais la conservation des prompts et réponses dans un lac de données appelle une vigilance quant au RGPD.