Amazon Nova 2 Lite : comment calculer le coût réel par flux entre tokens, cache, niveaux de service et échecs

Du prix unitaire au coût d’un résultat utile

Le prix par million de tokens est une composante nécessaire, mais il ne répond pas, à lui seul, à la question opérationnelle pertinente : combien coûte l’achèvement d’une tâche avec le résultat et la latence dont le système a besoin ? Dans un flux Amazon Nova 2 Lite sur Amazon Bedrock interviennent le volume d’entrée et de sortie, le contexte répété, les appels qui échouent, la validation de la réponse et, selon la conception, le niveau de service sélectionné. Une prévision défendable doit donc s’exprimer à la fois en unités de consommation et en résultats acceptés.

Il est utile de définir dès le départ une unité de travail. Il peut s’agir d’une demande classée, d’une page traitée, d’un document extrait, d’une session ou d’une automatisation qui produit un objet structuré valide. L’unité retenue doit inclure la condition d’acceptation : par exemple, que le JSON passe le validateur, que l’outil se termine ou qu’une revue humaine ne soit pas nécessaire. Cela évite de présenter comme une réussite une réponse qui a consommé des ressources mais a été rejetée.

Ce guide ne fixe aucun montant : les sources fournies décrivent l’identification du modèle, les modalités, le cache, les niveaux de service, les routes d’inférence, les quotas et les données d’usage facturables, mais elles ne contiennent pas de grille tarifaire en vigueur. Avant d’établir un budget, l’équipe doit figer le tarif officiel applicable en dehors de cet article et consigner la date de consultation. Remplacer cette donnée dans les formules est préférable à la réutilisation de chiffres anciens ou à l’inférence de prix à partir d’un autre modèle.

L’identifiant de base documenté du modèle est amazon.nova-2-lite-v1:0. La fiche documente également des profils d’inférence pour les États-Unis, l’Europe, le Japon et Global. Il ne faut pas supposer que deux profils, routes ou régions ont le même prix, la même capacité ou le même traitement des données au seul motif qu’ils invoquent le même modèle de base.

La fiche de facturation à figer avant de faire les calculs

Toute feuille de calcul devrait commencer par une fiche de périmètre. Notez la date et l’heure de consultation du tarif, la devise, le compte ou l’environnement, l’identifiant du modèle, la région d’origine, le profil d’inférence, la route In-Region ou Cross-Region, le niveau de service demandé et l’unité fonctionnelle. Ajoutez une version du prompt, la configuration de sortie, le schéma de validation et la période d’observation. Ces champs permettent d’expliquer pourquoi deux mesures apparemment identiques aboutissent à des coûts différents.

La documentation des rapports de coûts et d’usage de Bedrock distingue, pour Nova 2 Lite, les types d’usage d’entrée, de sortie, de lecture de cache et d’écriture de cache. Elle documente aussi des suffixes qui permettent de distinguer le niveau Flex ou Priority ainsi que le routage Cross-Region. Cette séparation est importante : une estimation qui additionne uniquement les tokens d’entrée et de sortie peut omettre les opérations de cache, et une réconciliation agrégée peut masquer un mélange de routes ou de niveaux de service.

L’inférence géographique Cross-Region peut traiter les demandes dans la géographie choisie, bien que les prompts et les résultats puissent se déplacer de la région d’origine vers une région de destination située dans cette géographie. Cet aspect doit être évalué comme une exigence d’architecture et de résidence des données, et pas seulement comme une variable de prix. La documentation fournie ne suffit pas pour affirmer ici une équivalence de prix, de quota ou de facturation entre In-Region, Geo Cross-Region et Global Cross-Region.

Variables facturables et quatre formules auditables

Pour chaque tentative, séparez au minimum les tokens d’entrée ordinaires, les tokens de sortie, les lectures de cache et les écritures de cache. Si le flux inclut des entrées multimodales, des outils intégrés, du raisonnement ou une modalité supplémentaire, ajoutez des colonnes spécifiques uniquement si le tarif et l’enregistrement d’usage applicables les identifient. N’attribuez pas automatiquement un supplément à une fonction du seul fait de l’utiliser : avec les sources disponibles, il est impossible de confirmer le traitement tarifaire du raisonnement, des images, des documents, des outils ou des erreurs d’API pour ce modèle.

Utilisez des prix unitaires convertis en coût par token, ou conservez de façon cohérente le dénominateur par million de tokens. Appelez P_i le prix d’entrée, P_o celui de sortie, P_cr celui de lecture de cache et P_cw celui d’écriture de cache. Pour une tentative j, les consommations correspondantes sont I_j, O_j, CR_j et CW_j. S’il existe d’autres concepts publiés, incorporez-les sous forme de somme de quantité multipliée par prix, sans les masquer dans l’entrée ou la sortie.

La première formule estime le coût d’un appel individuel. La deuxième répartit un lot entre les éléments traités. La troisième sert aux sessions qui réutilisent des instructions ou du contexte. La quatrième transforme la consommation en coût par tâche correctement terminée. Dans tous les cas, le résultat dépend du fait que la télémétrie comptabilise chaque tentative, y compris celles qui se sont terminées par un échec de validation ou qui ont été abandonnées après une attente excessive.

Cache de prompt : mesurer l’économie nette, ne pas la présumer

Nova 2 Lite prend en charge le cache explicite avec un minimum de 1 000 tokens par point de contrôle, jusqu’à quatre points de contrôle, une durée de vie de cinq minutes et un maximum de 20 000 tokens de cache. Ces limites déterminent les conceptions qui peuvent en bénéficier : une instruction longue et stable, partagée entre des demandes rapprochées dans le temps, est un candidat plus clair qu’un contexte petit, très variable ou espacé.

La bonne comparaison n’est pas abstraitement « avec cache contre sans cache ». Mesurez les tokens écrits, les tokens lus, le nombre de demandes éligibles, le pourcentage de succès du cache, l’intervalle entre les appels, la complexité supplémentaire et les changements du taux de réussite. L’écriture initiale peut avoir un coût différent d’une lecture, et le rapport de coûts et d’usage permet de distinguer les deux catégories. L’économie nette n’apparaît que si les lectures réutilisées compensent les écritures et la maintenance de la conception.

Un cache peut aussi dégrader l’économie s’il accroît la complexité de segmentation, réduit la personnalisation nécessaire, provoque des expirations fréquentes ou incite à inclure un contexte non pertinent. Le fait qu’un bloc puisse être mis en cache ne démontre pas qu’il réduit la facture. La décision doit reposer sur une cohorte comparable et sur les coûts par tâche acceptée, et non seulement sur les tokens d’entrée observés.

Standard, Flex et Priority : une décision de coût attendu

La documentation sur les niveaux de service décrit Flex pour les charges tolérantes aux retards et Priority comme une option demandée par requête. Elle indique également que les quotas à la demande sont partagés entre Priority, le comportement par défaut et Flex. Choisir un niveau ne supprime donc pas la nécessité de mesurer la demande agrégée et ne garantit pas, à lui seul, que le flux opère dans les limites de ses quotas.

Le niveau effectivement servi peut être observé dans la réponse API, CloudTrail et CloudWatch selon la documentation. Conservez cette donnée avec le niveau demandé. Elle est essentielle pour détecter les écarts entre l’intention et le service servi, ainsi que pour réconcilier les analyses de latence, de consommation et de types d’usage dans le rapport de coûts.

L’option la moins chère par unité peut être plus coûteuse par résultat utile si elle augmente l’abandon, les timeouts ou la répétition du travail. À l’inverse, un niveau orienté priorité ne justifie son coût supplémentaire que s’il réduit des pertes opérationnelles dont le flux souffre réellement. Il s’agit d’une conclusion d’analyse économique, et non d’une affirmation sur les prix ou les performances garanties d’un niveau particulier.

Échecs, nouvelles tentatives et réponses rejetées : le multiplicateur à comptabiliser une seule fois

Un flux robuste doit enregistrer toutes les tentatives : premier appel, nouvelle tentative automatique, réparation de JSON, nouvel appel après timeout et escalade vers une revue humaine. Pour éviter le double comptage, attribuez un identifiant de tâche racine et un identifiant de tentative. Chaque coût de modèle appartient à une tentative ; le coût par tâche acceptée s’obtient en agrégeant les tentatives de la tâche une seule fois, puis en divisant par les tâches acceptées.

Distinguez les erreurs avant l’invocation du modèle, qui peuvent ne pas produire de consommation d’inférence, des réponses ou des échecs postérieurs à une invocation. Il n’est pas prudent de considérer toute erreur HTTP comme gratuite, ni toute nouvelle tentative comme identique au premier essai. La réconciliation doit utiliser les données de réponse, les journaux opérationnels et les types d’usage Bedrock disponibles dans le rapport de coûts. S’il manque une corrélation par demande, documentez cette limite au lieu d’attribuer toute la dépense à la dernière étape visible.

Les quotas publiés comprennent des limites de requêtes par minute et de tokens par minute pour l’inférence Cross-Region de Nova 2 Lite, et certains quotas peuvent être ajustés via Service Quotas. Mesurez les rejets, les attentes et les nouvelles tentatives liés aux limites. Une modification de quota ou du profil d’arrivée peut faire varier le taux de réussite et le coût effectif sans que le prix unitaire ne change.

Budget mensuel substituable et réconciliation avec la dépense

Pour établir un budget, partez d’une prévision de tâches démarrées par mois, d’une distribution attendue de tentatives par tâche et de consommations moyennes par type de tentative. Calculez chaque segment séparément : demandes simples, documents, sessions avec contexte répété et automatisations structurées. Multipliez le coût moyen par tentative de chaque segment par ses tentatives prévues ; ajoutez ensuite le coût des opérations auxiliaires et de la revue humaine si elles font partie du coût opérationnel sur lequel la décision doit porter.

À titre d’exemple de structure, une feuille peut comporter une ligne par segment et des colonnes pour les tâches démarrées, le taux d’acceptation, les tentatives par tâche, l’entrée, la sortie, l’écriture et la lecture de cache par tentative, les prix en vigueur, le coût estimé et le coût par accepté. Les cellules de prix doivent rester vides jusqu’à la copie du tarif vérifié pour la configuration concernée. Il n’est pas judicieux de les remplir avec des chiffres illustratifs, car ils pourraient être interprétés comme un tarif actuel.

À la clôture de la période, comparez la prévision et la réalité par modèle, route, niveau de service et type d’usage. Expliquez l’écart par les changements du mélange d’entrées, de la longueur des sorties, des succès de cache, des nouvelles tentatives et de l’acceptation, avant de l’attribuer à une modification de prix. Recalculez lorsque changent le modèle, la région ou le profil, le prompt, la politique de cache, le niveau de service, le mélange multimodal, le volume, les quotas ou les règles de validation.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.