Amazon Bedrock exécute l'inférence par lots à 50 % du tarif de tokens à la demande, et la seule chose que vous sacrifiez est l'immédiateté. Vous soumettez un fichier de requêtes, le job s'exécute de manière asynchrone quand il y a de la capacité, et vous récupérez les résultats plus tard. Pour toute charge de travail où aucun humain n'attend la réponse assis là, payer le plein tarif pour de l'inférence en temps réel laisse la moitié de l'argent sur la table pour une vitesse dont personne n'avait besoin.

L'erreur consiste à faire de chaque appel modèle le chemin synchrone en temps réel par défaut, parce que c'est ainsi que le premier prototype a été écrit. Le chat interactif doit être en temps réel. Un job nocturne qui classe les tickets de support d'hier ne le doit pas. Ce sont des exigences de latence différentes, et Bedrock les tarifie différemment. La question d'ingénierie est simplement de savoir lesquelles de vos charges de travail ont réellement besoin d'une réponse maintenant par rapport à celles qui ont besoin d'une réponse éventuellement.

Comment fonctionne le batch sur Bedrock

L'inférence par lots est un job, pas un appel. Le flux est délibérément ennuyeux :

1. write requests as JSONL to S3   (one record per line)
2. create a batch inference job     (input S3 -> output S3)
3. job runs asynchronously          (minutes to hours)
4. read results from the output S3 prefix

Chaque enregistrement d'entrée porte un ID d'enregistrement et la même entrée de modèle que vous enverriez en temps réel. La sortie est réécrite dans S3, un résultat par entrée, indexé par cet ID d'enregistrement pour que vous puissiez joindre les résultats aux entrées. Il n'y a pas de endpoint à garder chaud, pas de concurrence à ajuster, pas de throttling à intercepter. Vous échangez la boucle requête-réponse contre une boucle soumettre-et-récupérer, et vous obtenez le tarif réduit en échange d'accepter que le job se termine selon le calendrier du service, pas le vôtre.

Où la latence n'a vraiment pas d'importance

Les charges de travail qui conviennent sont celles où le résultat alimente un processus, pas une personne qui attend devant un écran :

  • Classification et étiquetage en masse. Catégoriser un arriéré de documents, tickets ou produits. La réponse atterrit dans une base de données, pas devant un utilisateur.
  • Pipelines d'enrichissement. Résumés, extractions ou embeddings générés à l'avance et stockés, pour que le chemin en temps réel se contente de lire une valeur précalculée.
  • Évaluation hors ligne. Noter un modèle ou un changement de prompt sur des milliers de cas de test. C'est un rapport, et les rapports peuvent attendre une heure.
  • Rapports périodiques. Tout ce qui tourne sur un calendrier et produit une sortie qu'un humain lira plus tard, pas instantanément.

Le fil conducteur : la deadline se mesure en heures, et le volume est assez grand pour que réduire de moitié le prix des tokens représente de l'argent réel plutôt qu'une erreur d'arrondi.

Le calcul de coût

Le compromis est frappant une fois posé sur papier. Prenez un job d'un million d'enregistrements, chacun avec un coût de tokens moyen fixe :

Real-time path:
  1,000,000 requests x on-demand token price
  + endpoint kept responsive
  + throttling handling under load

Batch path:
  1,000,000 records x (0.5 x on-demand token price)
  + S3 storage (negligible)
  + the willingness to wait

La colonne batch représente la moitié de la facture de tokens et moins de surface opérationnelle, car il n'y a pas de endpoint en direct à protéger d'un pic. Le point d'équilibre ne concerne pas le volume, il concerne la deadline. Si la réponse peut attendre, le batch gagne à la fois sur le coût et la simplicité. Si elle ne peut pas, aucune remise ne rend un job asynchrone acceptable.

Quand le batch est le mauvais outil

Ne le forcez pas là où la forme ne correspond pas. Le batch est mauvais quand un utilisateur attend la sortie, quand une requête dépend du résultat de la précédente, ou quand le job est assez petit pour que la remise soit triviale et que la plomberie asynchrone ne vaille pas le coup. C'est aussi mauvais comme contournement de throttling : si votre trafic en temps réel se fait throttler, la solution est la planification de capacité et le prompt caching, pas pousser des requêtes interactives à travers un job qui revient des heures plus tard. Le batch est fait pour du travail qui allait toujours être différé, pas pour cacher un problème de latence.

À retenir

La moitié d'une grosse facture de tokens vaut une architecture que la plupart des équipes ont déjà sous la main : écrire dans S3, soumettre un job, lire les résultats plus tard. La remise n'est pas astucieuse, c'est juste payer pour de la capacité différée au lieu de la capacité à la demande. Auditez vos appels modèle et triez-les selon qui attend. Tout ce qui a un humain de l'autre côté reste en temps réel. Tout le reste, la classification, l'enrichissement, l'évaluation et les rapports qui alimentent un pipeline plutôt qu'une personne, appartient à un job batch à 50 % de réduction. Les économies se trouvent dans les charges de travail que vous n'avez jamais remises en question.

À lire ensuite

Pour le playbook plus large d'optimisation des coûts et de pipeline sur AWS, les notes de terrain cloud se trouvent sur ercan.cloud, et le hub est sur ercanermis.com.