Amazon AIF-C01: Optimisation des coûts et tarification pour l'IA/ML — Guide d'étude

By Laurynas Brazys · 30 July 2026 · #amazon #aif-c01 #certification #exam-prep #study-guide

Fait partie du AWS AI Practitioner AIF-C01 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Facteurs de coût et modèles de tarification pour Bedrock, SageMaker et EC2

La tarification des charges de travail d’IA/ML se répartit entre le calcul, le stockage, le réseau et la mesure spécifique au service. L’accès aux modèles de fondation via Amazon Bedrock est généralement facturé par requête ou par jeton (token) pour les charges de travail textuelles et à la seconde pour les API de streaming ; SageMaker facture les heures d’instance pour l’entraînement et l’hébergement multi-tenant, ainsi que le transfert de données et le stockage. L’hébergement basé sur EC2 entraîne le coût brut de l’heure d’instance, avec des frais supplémentaires pour le stockage EBS, EFS ou FSx et la sortie (egress) du VPC. Les principaux facteurs de coût sont la taille du modèle (les modèles plus grands augmentent le travail sur les jetons/calculs et l’empreinte mémoire), le débit d’inférence (les appels synchrones sensibles à la latence coûtent plus cher lorsqu’ils sont épinglés à des GPU coûteux), et le mouvement des données pour la génération augmentée par récupération (RAG), où les recherches d’embeddings et les recherches vectorielles peuvent multiplier les appels. Les pièges courants pour les praticiens incluent la sous-estimation des coûts des embeddings pour les systèmes RAG à QPS élevé, le fait de laisser tourner plusieurs points de terminaison SageMaker inactifs et d’ignorer la sortie (egress) inter-régions lors de la conservation des PII dans leur région d’origine. Les critères de décision doivent donc prendre en compte le volume de requêtes, la tolérance à la latence par requête, la nécessité ou non d’affiner le modèle (fine-tuning) ou s’il peut rester prêt à l’emploi, et si l’inférence gérée par le fournisseur (points de terminaison Bedrock/SageMaker) ou les instances EC2/GPU auto-hébergées offrent un meilleur TCO en tenant compte de la surcharge de gestion et de mise à l’échelle.

Sélection d’instance, instances Spot et modèles d’optimisation du calcul

Le choix des instances affecte à la fois les performances et les coûts. Pour l’entraînement, utilisez Trainium (trn1) ou des clusters de GPU (p4/p5) lorsque le débit matriciel à grande échelle est essentiel ; pour l’inférence, préférez Inferentia/Inf2 (inf1/inf2) ou l’inférence sur CPU basé sur Graviton pour les modèles plus petits afin de réduire les coûts. Les services gérés comme SageMaker Managed Spot Training et SageMaker Distributed Training intègrent le checkpointing et récupèrent automatiquement la capacité Spot pour réduire considérablement les coûts d’entraînement ; cependant, les instances Spot sont un piège pour la production à faible latence, à moins d’être combinées avec des mécanismes de repli robustes. Les patrons d’architecture qui réduisent les dépenses incluent le traitement par lots asynchrone, l’autoscaling avec des protections contre le démarrage à froid (cold-start), les points de terminaison multi-modèles pour consolider de nombreux petits modèles sur un seul hôte, et l’utilisation de la précision mixte et de la quantification pour réduire les besoins en mémoire et en débit. Utilisez des frameworks tels que DeepSpeed ou ZeRO pour réduire l’empreinte mémoire lors de l’entraînement de grands modèles, et évaluez le fine-tuning efficace en paramètres (LoRA/adaptateurs) pour éviter le réentraînement complet du modèle. Une erreur fréquente consiste à utiliser des GPU haut de gamme pour des charges de travail lourdes en embeddings, où des instances CPU ou Inferentia offriraient un bien meilleur rapport prix/performance.

Compromis dans la sélection de modèles et stratégies soucieuses des coûts

Le choix du modèle est un compromis entre le coût, la latence, la précision et la sensibilité des données. Les modèles de fondation dans Bedrock offrent une mise à l’échelle gérée, des outils de sécurité et une itération rapide, mais entraînent des coûts par appel ou par jeton (token) qui peuvent devenir prédominants à grande échelle ; les modèles open source hébergés sur SageMaker ou EC2 peuvent réduire les dépenses par inférence si vous amortissez les frais généraux d’hébergement et d’exploitation. Les architectures hybrides fonctionnent bien : exécutez un petit modèle peu coûteux pour la majeure partie des requêtes et escaladez vers un modèle plus grand pour les requêtes complexes, ou utilisez la génération augmentée par récupération où le contexte lourd est servi par une base de données vectorielle (OpenSearch, une base de données vectorielle adossée à Amazon QLDB, ou un service tiers) et seuls des prompts concis sont envoyés au LLM. Les décisions de fine-tuning doivent prendre en compte les méthodes efficaces en paramètres (LoRA, adaptateurs) et les paires prompt-complétion au format JSONL pour les tâches de type texte-à-texte afin de limiter l’utilisation du jeu de données et du calcul. Les pièges courants incluent le fine-tuning de modèles inutilement grands au lieu d’utiliser l’ingénierie de prompt, le fait de négliger l’inflation de la longueur des prompts en jetons, et de ne pas mettre en cache ou dédupliquer les réponses pour les requêtes très répétitives.

Stockage, localité des données, gouvernance et observabilité pour le contrôle des coûts

Les choix de stockage influencent à la fois les coûts mensuels et la conformité légale. Utilisez S3 avec des politiques de cycle de vie, Intelligent-Tiering et des formats compressés (Parquet/TFRecord) pour les jeux de données ; placez les données d’entraînement actives dans des niveaux à haut débit et archivez les ressources brutes dans Glacier. Pour les PII et la résidence des données, conservez les buckets S3, les clés KMS et les ressources de calcul dans la Région AWS requise et contrôlez l’accès via des points de terminaison VPC, des politiques IAM et un réseau privé pour empêcher toute sortie inter-régions accidentelle. Les pipelines de récupération pour RAG doivent colocaliser les banques de vecteurs (Amazon OpenSearch Service ou une banque d’embeddings sur EC2/EBS) avec la couche d’inférence pour éviter les coûts de transfert et la latence. Les outils d’observabilité et d’explicabilité tels que SageMaker Clarify, Debugger et Model Monitor apportent une gouvernance et une détection précoce des dérives, mais ajoutent des coûts — déployez des moniteurs basés sur l’échantillonnage pour maîtriser les dépenses. Minimisez l’empreinte environnementale et la facture en choisissant des puces efficaces (Inferentia/Trainium) et en utilisant le traitement par lots ; une erreur courante consiste à activer la journalisation complète et la surveillance continue des modèles sans seuils d’échantillonnage, ce qui augmente à la fois les coûts et le bruit tout en n’apportant que peu de valeur ajoutée.

Problème pratique : Scénario d’utilisation

Scénario : Acme Retail exploite une pile IA sur AWS utilisant Amazon Bedrock pour l’accès aux LLM, Amazon SageMaker pour l’entraînement et l’hébergement de modèles, S3 pour les données et Amazon OpenSearch pour l’indexation des produits. Ils doivent générer des milliers de descriptions de produits de la longueur d’un paragraphe chaque jour, avec une voix de marque cohérente, des exigences strictes de PII en région et un objectif de coût serré.

Défi : Fournir des descriptions de haute qualité et de marque à grande échelle tout en minimisant le coût par description et en garantissant que les données des clients ne quittent jamais la Région AWS désignée.

Approche recommandée :

1. Utiliser un pipeline d’inférence à deux niveaux : router d’abord toutes les requêtes vers un modèle léger hébergé localement sur SageMaker ou EC2 (quantifié) pour traiter les SKU courants et les descriptions simples ; escalader les cas complexes ou à faible confiance vers un modèle de fondation Bedrock.
2. Stocker les embeddings et les index de récupération dans Amazon OpenSearch en région ; utiliser un contexte récupéré concis pour maintenir une faible utilisation des jetons Bedrock et mettre en cache les réponses courantes dans ElastiCache.
3. Ajuster finement un petit modèle spécialisé en utilisant des méthodes efficaces en paramètres (LoRA) sur SageMaker Managed Spot Training avec des points de contrôle vers S3, en ne réentraînant que rarement le modèle complet.
4. Appliquer des contrôles aux limites de la région : buckets S3 et clés KMS en région, points de terminaison VPC pour Bedrock/SageMaker, et Model Monitor + Clarify basés sur l’échantillonnage pour limiter les coûts de surveillance.

Justification : La combinaison d’un modèle de base peu coûteux avec une escalade sélective minimise les coûts par description en jetons et en instances, tandis que le RAG et la mise en cache réduisent les appels à Bedrock. L’entraînement spot géré et l’ajustement fin efficace en paramètres diminuent les dépenses d’entraînement et la surcharge de stockage, tandis que les contrôles en région satisfont aux exigences de PII et de conformité.

← MLOps et déploiement · Tous les domaines

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →