Accueil › Glossaire › Batch Processing

Batch Processing (Traitement par lots)

Comment fonctionne le batch processing

Le batch processing suit un workflow en trois phases distinctes. D’abord, la preparation : vous construisez un fichier (generalement au format JSONL) contenant toutes vos requetes, chacune avec un identifiant unique. Ensuite, la soumission : vous uploadez ce fichier via l’endpoint batch du provider et recevez un identifiant de job. Enfin, la recuperation : vous interrogez periodiquement l’etat du job, et une fois termine, vous telechargez le fichier de resultats.

Cette architecture asynchrone permet au provider d’optimiser l’utilisation de ses ressources GPU. Au lieu de traiter vos requetes immediatement (ce qui peut necessiter de l’infrastructure disponible a l’instant T), le provider les planifie quand la capacite de calcul est disponible, souvent pendant les heures creuses. C’est cette flexibilite de planification qui justifie la reduction tarifaire.

Le delai de traitement varie selon le provider et la charge. OpenAI garantit un traitement sous 24 heures maximum, mais la plupart des jobs terminent en 1 a 4 heures. Anthropic ne donne pas de garantie formelle de delai mais offre des temps similaires. Ces delais sont acceptables pour les cas d’usage non interactifs ou la reponse instantanee n’est pas necessaire.

API Batch par provider

OpenAI Batch API

L’API Batch d’OpenAI est la plus mature. Elle offre une reduction de 50% sur le prix des tokens par rapport aux appels synchrones. Le workflow se decompose ainsi : upload du fichier JSONL via /v1/files, creation du batch via /v1/batches, puis polling du statut et telechargement des resultats.

Chaque ligne du fichier JSONL contient une requete complete avec un custom_id (votre reference), la methode HTTP, l’URL de l’endpoint et le body de la requete. La taille maximale d’un fichier batch est de 100 Mo ou 50 000 requetes, selon la limite atteinte en premier.

{"custom_id": "req-001", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o", "messages": [{"role": "user", "content": "Resume cet article en 3 points."}], "max_tokens": 200}}
{"custom_id": "req-002", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o", "messages": [{"role": "user", "content": "Traduis en anglais : Bonjour le monde."}], "max_tokens": 100}}

Anthropic Message Batches

Anthropic propose son propre systeme de batch via l’endpoint /v1/messages/batches. La reduction est egalement de 50% sur les tokens. Le format differe legerement d’OpenAI : chaque requete est un objet avec un custom_id et un objet params contenant les parametres du message (modele, max_tokens, messages).

Le SDK Python d’Anthropic simplifie considerablement le workflow batch. Vous pouvez creer un batch, suivre son statut et recuperer les resultats avec quelques lignes de code. Le SDK gere le polling automatique et renvoie les resultats dans le meme ordre que les requetes soumises.

import anthropic
client = anthropic.Anthropic()

# Creer un batch
batch = client.messages.batches.create(
    requests=[
        {
            "custom_id": "req-001",
            "params": {
                "model": "claude-sonnet-4-20250514",
                "max_tokens": 200,
                "messages": [{"role": "user", "content": "Resume en 3 points."}]
            }
        },
        {
            "custom_id": "req-002",
            "params": {
                "model": "claude-sonnet-4-20250514",
                "max_tokens": 100,
                "messages": [{"role": "user", "content": "Traduis en anglais."}]
            }
        }
    ]
)

# Verifier le statut
status = client.messages.batches.retrieve(batch.id)
print(status.processing_status)  # in_progress, ended, etc.

Google Vertex AI Batch

Google propose le batch prediction sur Vertex AI pour les modeles Gemini. Le workflow utilise BigQuery ou Cloud Storage pour les fichiers d’entree et de sortie. Les requetes sont soumises via l’API Vertex AI avec un format specifique. La reduction tarifaire est moins transparente que chez OpenAI et Anthropic, car elle depend du type de machine et de la region.

Cas d’usage du batch processing

Le batch processing est pertinent chaque fois que vous n’avez pas besoin d’une reponse instantanee. La classification massive de documents est un cas classique : vous avez 10 000 emails a categoriser, rien ne presse, et la reduction de 50% fait passer votre facture de 200 $ a 100 $.

La generation de contenu a grande echelle en est un autre. Generer des descriptions de produits pour un catalogue de 5 000 articles, creer des variantes de meta-descriptions pour le SEO, ou produire des resumes automatiques pour une base documentaire. Dans tous ces cas, le delai de quelques heures est acceptable et les economies sont significatives.

L’evaluation de modeles (benchmarking) beneficie aussi du batch. Quand vous testez les performances d’un modele sur un jeu de test de 1 000 exemples, le traitement sequentiel est lent et couteux. Le batch accelere le processus et reduit la facture de moitie.

Le traitement de donnees structurees est egalement un cas frequent : extraction d’entites, normalisation d’adresses, enrichissement de bases de donnees CRM. Toutes ces operations se pretent au traitement par lots car elles sont independantes les unes des autres et ne necessitent pas d’interaction utilisateur.

Batch vs streaming : deux philosophies opposees

Le batch processing et le streaming representent les deux extremes du spectre de traitement. Le streaming optimise la latence (reponse immediate, token par token). Le batch optimise le cout (reduction de 50%, traitement differe). Entre les deux, les appels synchrones classiques offrent un compromis : reponse rapide mais sans reduction tarifaire.

En architecture, ces trois modes coexistent souvent. Le streaming pour l’interface utilisateur (chatbot, assistant). Les appels synchrones pour les traitements backend en temps reel (moderation de contenu, detection de spam). Le batch pour les traitements lourds planifies (rapports quotidiens, mise a jour de catalogues).

Implementation et bonnes pratiques

Construire un pipeline batch robuste necessite de prendre en compte plusieurs aspects. La gestion des erreurs partielles : dans un batch de 1 000 requetes, certaines peuvent echouer tandis que d’autres reussissent. Le fichier de resultats contient le statut individuel de chaque requete, et votre code doit traiter les echecs (retry, logging, alerte).

L’idempotence est essentielle. Si votre pipeline crash apres avoir soumis le batch mais avant de recuperer les resultats, vous devez pouvoir reprendre sans re-soumettre les requetes. Utilisez les custom_id pour tracker chaque requete et stockez l’identifiant du batch pour pouvoir recuperer les resultats ulterieurement.

Le chunking est necessaire pour les tres gros volumes. Si vous avez 200 000 requetes et la limite est de 50 000, decoupez en 4 batches. Gerez-les en parallele et consolidez les resultats a la fin. Les SDK ne gerent generalement pas ce decoupage automatiquement, c’est a vous de l’implementer.

Surveillez vos batches en production. Mettez en place des alertes sur le temps de traitement (si un batch depasse le delai attendu) et sur le taux d’echec (si plus de 5% des requetes echouent dans un batch, il y a probablement un probleme systematique dans vos prompts ou parametres).