Batch API ou appels en temps réel : comment choisir le bon canal pour chaque charge de travail

Distinguer d'abord deux échelles de temps

La sensibilité au temps des appels LLM varie énormément. Un utilisateur qui attend une réponse dans une fenêtre de chat tolère l'échelle de la seconde ; une tâche de génération de rapport quotidien pour une équipe peut tolérer l'échelle de l'heure. Le canal batch est précisément conçu pour ce dernier cas : il met les requêtes en file d'attente, les traite en masse, et échange un temps de complétion plus long contre un prix par token plus bas.

La [documentation sur le batch processing](https://platform.claude.com/docs/en/build-with-claude/batch-processing) d'Anthropic et la [page pricing](https://claude.com/pricing) listent séparément les tarifs batch ; côté OpenAI, il existe également des remises batch et de traitement par lots correspondantes. Leur point commun est une remise sur le prix standard, la différence résidant dans le mode de soumission et la fenêtre de complétion.

Cadre de décision : quatre questions

1. Quelqu'un attend-il ce résultat de manière synchrone ? Oui → temps réel. Non → continuer.
2. Le résultat peut-il attendre quelques heures ? Oui → candidat batch. Doit être au niveau de la minute → temps réel.
3. La requête est-elle un ensemble énumérable hors ligne ? Oui (un lot de documents, un lot de tickets, un lot d'échantillons d'évaluation) → le batch est très adapté.
4. Le coût d'une réexécution en cas d'échec est-il élevé ? Élevé → temps réel pour un retour immédiat ; faible → le retry par lots en batch est plus rentable.

Liste des scénarios batch typiques

• Classification et étiquetage de contenu : système d'étiquettes unifié pour des centaines de milliers de produits, avis, tickets.
• Nettoyage de données hors ligne : extraction par lots de champs structurés à partir de texte non structuré.
• Évaluation de régression : avant de modifier un prompt, exécuter un jeu d'évaluation fixe pour comparer.
• Résumé / traduction par lots : organisation hors ligne de bibliothèques de documents, historiques de support, comptes rendus de réunion.
• Génération de données synthétiques : génération par lots d'échantillons pour l'entraînement ou l'évaluation.

Les pièges du batch : succès partiel et retries

Un job batch n'est pas « tout ou rien ». Dans un job de plusieurs centaines de requêtes, quelques-unes échouent généralement pour cause d'erreur de paramètre, d'entrée trop longue, de politique de contenu, etc. Sur le plan technique, il faut impérativement :

• Enregistrer les résultats individuellement, ne pas traiter le succès ou l'échec du lot entier comme un booléen.
• Distinguer ce qui est réessayable de ce qui ne l'est pas : 429 / 5xx sont réessayables, une erreur de paramètre 400 ne sert à rien à réessayer.
• Clé d'idempotence : la resoumission d'une même donnée métier ne doit pas entraîner de double facturation ni de double écriture.
• Prévisualisation des coûts : estimer la limite en tokens avant soumission, pour éviter une facture inattendue sur un job.

Gérer les deux canaux avec une seule passerelle

Séparer le temps réel et le batch en deux ensembles indépendants de comptes, de clés et de facturation est la dette d'architecture la plus courante : à chaque changement de prix il faut mettre à jour deux endroits, et le diagnostic d'échec oblige à consulter deux back-offices.

L'approche d'Admesh est une seule Base URL, un seul jeu de clés, une seule facturation : côté métier, vous décidez du canal selon le type de tâche, tandis que le catalogue de modèles et les prix unitaires proviennent toujours de la même configuration back-office, et la marge comme l'usage sont consultables au même endroit.

Voir la documentation sur le rate limiting et la concurrence →