Tarification de l'inférence par batch des API d'IA : quand les jobs asynchrones permettent de faire des économies

La tarification de l'inférence par lots (batch) repose sur un compromis : vous acceptez une latence plus élevée en échange d'un tarif par token réduit. Vous soumettez une tâche, le fournisseur la traite dans un délai défini (généralement jusqu'à 24 heures), et vous payez moins cher que pour un appel synchrone en temps réel. La pertinence de ce compromis dépend entièrement de la tolérance de votre charge de travail à ce délai.

Cet article compare l'inférence par lots (asynchrone) aux appels API synchrones standard, en se basant sur la documentation des API batch publiée par OpenAI et Google, et propose un cadre décisionnel pour déterminer quand l'approche asynchrone permet réellement de réduire les coûts de votre produit.

Points clés à retenir

• OpenAI et Gemini proposent tous deux une API batch qui accepte des tâches pour un traitement asynchrone à un tarif réduit par rapport aux appels synchrones ; vérifiez le pourcentage de remise exact sur la page de tarification de chaque fournisseur avant d'établir votre budget, car les tarifs peuvent évoluer.
• L'inférence par lots est adaptée aux charges de travail qui tolèrent un délai de traitement plutôt que de nécessiter une réponse immédiate : classification en masse, génération d'embeddings, évaluation hors ligne, étiquetage de jeux de données et tâches de rattrapage (backfill).
• Le chat en temps réel, les agents de codage et les fonctionnalités interactives ne sont généralement pas adaptés à la tarification par lots, car le délai de traitement les rend inutilisables pour une interaction utilisateur en direct.
• Les économies cumulées les plus importantes proviennent généralement de la combinaison des remises sur les lots avec le choix du modèle et l'optimisation des prompts ; consultez /models/rankings et le guide de réduction des coûts des API IA pour découvrir les autres leviers.

Ce que signifie réellement l'inférence par lots

Les appels API synchrones renvoient une réponse dès que le modèle a terminé sa génération, généralement en quelques secondes. Vous payez un tarif par token lié à cette immédiateté. L'inférence par lots inverse le modèle : au lieu d'un échange unique requête-réponse, vous soumettez un fichier ou une liste de requêtes sous forme de tâche. Le fournisseur met la tâche en file d'attente, la traite pendant une fenêtre de temps qu'il contrôle, et met les résultats à votre disposition une fois terminés.

Il ne s'agit pas d'une nouvelle technique d'inférence au sein du modèle, mais d'un contrat commercial et opérationnel différent. Le fournisseur planifie votre charge de travail en fonction de ses capacités inutilisées ou hors pointe, et en échange, facture moins par token qu'il ne le ferait pour une requête traitée instantanément.

OpenAI et Google documentent tous deux ce modèle pour leurs API respectives :

• La référence de l'API Batch d'OpenAI décrit la création d'un objet batch à partir d'un fichier de requêtes téléchargé, le suivi de son statut et la récupération du résultat une fois la tâche terminée (platform.openai.com/docs/api-reference/batch/object).
• La documentation de l'API Gemini Batch de Google décrit un modèle comparable : soumission d'un lot de requêtes, exécution asynchrone de la tâche, et récupération des résultats après traitement (ai.google.dev/gemini-api/docs/batch-api).

Les mécanismes diffèrent légèrement selon les fournisseurs (soumission par fichier, objets de tâche, interrogation du statut, récupération des résultats), mais la structure sous-jacente est cohérente : soumettre maintenant, collecter plus tard, payer moins par token que l'équivalent synchrone. Consultez la documentation actuelle de chaque fournisseur pour connaître la fenêtre de traitement exacte et le taux de remise applicable à votre compte et à votre modèle, car ces détails sont spécifiques à chaque fournisseur et sujets à modification.

Fonctionnement des deux API Batch documentées

Sur le plan technique, les deux fournisseurs suivent un cycle de vie similaire :

1. Préparer les requêtes. Vous assemblez les requêtes d'inférence individuelles que vous souhaitez traiter, généralement formatées sous forme de fichier (OpenAI accepte un fichier de requêtes identifiées par un ID personnalisé ; Gemini accepte un lot de requêtes structurées).
2. Soumettre la tâche. Vous créez un objet batch ou une ressource de tâche qui fait référence à votre entrée téléchargée.
3. Interroger ou attendre la fin. La tâche passe par différents états (en file d'attente, en cours, terminée ou échouée) jusqu'à ce que le fournisseur termine le traitement dans sa fenêtre documentée.
4. Récupérer le résultat. Une fois terminée, vous téléchargez ou récupérez le fichier de sortie ou l'ensemble des résultats, en faisant correspondre chaque réponse à sa requête d'origine via l'ID.

Aucun des deux fournisseurs ne traite les tâches par lots instantanément. C'est là tout l'intérêt du modèle de tarification : la tâche s'exécute selon le calendrier du fournisseur, pas le vôtre, et vous acceptez un délai borné en échange d'un tarif inférieur. Si votre produit ne peut pas tolérer ce délai, la tarification par lots ne vous est pas accessible, quel que soit le montant théorique des économies.

Quand la tarification par lots permet-elle de faire des économies : une liste de contrôle

Utilisez cette liste de contrôle avant d'orienter une charge de travail vers un point de terminaison batch :

• La charge de travail a-t-elle une nature non interactive ? Les passes de classification sur un jeu de données, la génération d'embeddings pour un corpus de documents, les balayages de modération de contenu ou les tâches de résumé nocturnes sont parfaitement adaptés.
• Votre produit peut-il tolérer la fenêtre de traitement documentée ? Si un utilisateur ou un système en aval a besoin du résultat en quelques secondes ou minutes, le batch ne convient pas.
• Le volume est-il suffisamment important ? Les remises sur les lots s'appliquent par token, donc les économies absolues augmentent avec le volume. Quelques requêtes ne modifieront pas votre facture de manière significative.
• La tâche est-elle idempotente ou peut-elle être relancée en toute sécurité ? Comme les tâches par lots s'exécutent de manière asynchrone et peuvent échouer partiellement, votre pipeline doit gérer la resoumission ou l'achèvement partiel sans corrompre l'état en aval.
• Votre couche d'orchestration prend-elle déjà en charge l'interrogation de tâches asynchrones ? Si vous construisez ce modèle pour la première fois, prévoyez du temps d'ingénierie pour la soumission des tâches, l'interrogation du statut et la réconciliation des résultats.

Dimension	API Synchrone	API Batch (asynchrone)
Latence	Quelques secondes, généralement	Minutes à heures, bornée par la fenêtre documentée du fournisseur
Tarification	Tarif standard par token	Tarif réduit par token par rapport au synchrone, selon la documentation
Usage idéal	Chat, agents, fonctionnalités en direct	Classification en masse, embeddings, évaluation hors ligne, rattrapages
Gestion des erreurs	Erreur immédiate lors de l'appel	Statut au niveau de la tâche ; échecs partiels possibles au sein d'un lot
Charge d'ingénierie	Requête-réponse simple	Nécessite une logique de soumission, d'interrogation et de récupération
Ordre des résultats	Correspond à l'ordre des appels	Correspond à l'ID de requête personnalisé, pas à l'ordre d'appel

Quand la tarification par lots ne convient pas

L'inférence par lots est inadaptée dès lors qu'une personne ou un système en aval attend la réponse. Cela inclut :

• Les agents conversationnels et les produits de chat. Un utilisateur s'attend à une réponse en quelques secondes, pas après une fenêtre de traitement.
• Les assistants de codage et les flux de travail d'agents de codage. Les outils basés sur des modèles comme Claude Sonnet 5 ou Kimi K2.7 Code dépendent de boucles de rétroaction serrées entre le développeur et le modèle ; le traitement par lots briserait totalement l'interaction.
• La génération de contenu en temps réel pour les fonctionnalités utilisateur, y compris la génération d'images ou de vidéos à la demande via des API telles que Nano Banana Pro ou Veo 3, où l'utilisateur observe une barre de progression.
• Tout ce qui a une exigence de latence au niveau du service, même si cette exigence est souple (par exemple, moins d'une minute). Les fenêtres de traitement par lots se mesurent généralement en heures, pas en secondes.

Si une partie de votre pipeline est en temps réel et l'autre non, divisez le travail. Acheminez la partie interactive via l'API synchrone et envoyez la partie volumineuse tolérante au délai (réindexation nocturne, réétiquetage de jeux de données, exécutions d'évaluation) vers le point de terminaison batch.

Un exemple de structure de requête

Le schéma exact diffère entre l'objet batch d'OpenAI et l'API batch de Gemini, considérez donc ce qui suit comme une structure illustrative plutôt que comme une copie littérale du format de requête de l'un ou l'autre fournisseur. Confirmez les noms de champs exacts et les points de terminaison avec la documentation actuelle avant de mettre en œuvre cette solution.

# 1. Préparer un fichier de requêtes, chacune avec un ID personnalisé
{"custom_id": "req-001", "method": "POST", "url": "/v1/chat/completions",
 "body": {"model": "your-selected-model", "messages": [{"role": "user", "content": "Classify this ticket."}]}}
{"custom_id": "req-002", "method": "POST", "url": "/v1/chat/completions",
 "body": {"model": "your-selected-model", "messages": [{"role": "user", "content": "Classify this ticket."}]}}

# 2. Soumettre la tâche batch
POST /v1/batches
{
  "input_file_id": "file-abc123",
  "endpoint": "/v1/chat/completions",
  "completion_window": "24h"
}

# 3. Interroger le statut de la tâche
GET /v1/batches/{batch_id}
# renvoie le statut : queued | in_progress | completed | failed

# 4. Récupérer le résultat une fois terminé
GET /v1/files/{output_file_id}/content
# faire correspondre chaque réponse à sa requête par custom_id

Le modèle d'ingénierie de base est le même quel que soit le fournisseur : construisez votre fichier de requêtes avec des ID stables, soumettez la tâche, interrogez l'état d'avancement et réconciliez les résultats avec votre liste de requêtes d'origine. Mettez en place une logique de nouvelle tentative pour les échecs partiels au niveau de la tâche, car un lot peut se terminer avec certaines requêtes individuelles en échec même si la tâche elle-même réussit.

Combiner les remises batch avec la sélection de modèles

La tarification par lots est un levier. Elle se combine, plutôt qu'elle ne remplace, aux décisions au niveau du modèle et du prompt couvertes dans AI model routing benchmark et le guide de réduction des coûts des API IA. Une charge de travail à la fois éligible au batch et servie par un modèle à moindre coût, tel que DeepSeek V4 Flash, GLM-5.2 ou Gemini 3.5 Flash pour les tâches adaptées au routage, permettra généralement des économies absolues plus importantes que l'application d'un seul de ces leviers. Avant de confier une tâche volumineuse à un modèle et à un niveau de tarification uniques, vérifiez la tarification et le positionnement actuels par modèle sur /models/rankings, car la tarification relative entre les modèles de pointe et les modèles à bas coût évolue au gré des mises à jour des catalogues des fournisseurs.

Pour les équipes évaluant l'opportunité de mettre en place un support batch, le calcul est simple : estimez votre volume mensuel de tokens pour les tâches tolérantes au délai, comparez la remise batch documentée à vos dépenses synchrones actuelles sur ce même volume, et pesez cela par rapport au coût d'ingénierie de la construction de la logique de soumission et d'interrogation. Si le volume est faible, la remise peut ne pas compenser la complexité ajoutée.

Limitations

Cette comparaison est basée sur les mécanismes généraux documentés par OpenAI et Google pour leurs API batch tels qu'observés le 14/07/2026. Les pourcentages de remise exacts, les durées des fenêtres de traitement, la disponibilité par modèle et les exigences de format de fichier sont spécifiques à chaque fournisseur, évoluent dans le temps et ne sont pas rappelés ici sous forme de chiffres fixes. Vérifiez la tarification et les conditions actuelles du batch directement auprès de la documentation de chaque fournisseur avant d'établir un budget ou de développer une solution. Cet article ne couvre pas non plus le support batch de tous les fournisseurs de modèles ; vérifiez si votre modèle et votre fournisseur choisis publient un point de terminaison batch avant de planifier quoi que ce soit autour de celui-ci.

FAQ

Combien l'inférence par lots est-elle moins chère que les appels synchrones ? OpenAI et Google documentent tous deux une remise pour le traitement par lots par rapport à leur tarif synchrone standard, mais le pourcentage exact est spécifique au fournisseur et à la période. Consultez la page de tarification actuelle de votre fournisseur et de votre modèle avant d'estimer les économies.

Que se passe-t-il si ma tâche batch ne se termine pas dans la fenêtre de traitement ? La documentation des fournisseurs décrit les états de statut des tâches (tels que queued, in_progress, completed et failed). Consultez la documentation de chaque fournisseur sur la manière dont il gère les tâches qui dépassent la fenêtre d'achèvement, car le comportement peut différer selon le fournisseur et est sujet à changement.

Puis-je utiliser l'inférence par lots pour des fonctionnalités de chat en temps réel ? Non. Les tâches par lots sont traitées de manière asynchrone dans une fenêtre pouvant aller de quelques minutes à plusieurs heures, ce qui les rend inadaptées à toute charge de travail où un utilisateur ou un système attend une réponse immédiate. Utilisez l'API synchrone pour les fonctionnalités interactives et réservez les points de terminaison batch aux tâches à haut volume tolérantes au délai.

Si vous évaluez si la tarification par lots convient à votre charge de travail, comparez les tarifs et classements actuels par modèle, puis commencez par mapper vos tâches tolérantes au délai par rapport à la liste de contrôle ci-dessus avant d'engager du temps d'ingénierie dans la logique de soumission et d'interrogation.