OpenAI Batch : remise de 50 %, résultat parfois incomplet

Summary

Batch API promet un coût inférieur de 50 % à celui des appels synchrones et une fenêtre de traitement de 24 heures. Si le lot expire, OpenAI facture les jetons des requêtes déjà terminées.
Les requêtes inachevées sont annulées. Le fichier de sortie contient les réponses obtenues, le fichier d’erreurs signale notamment batch_expired, et custom_id permet de retrouver précisément les lignes qui manquent.

La remise est facile à approuver. L’addition est plus difficile à expliquer lorsque le fichier livré présente des trous.

OpenAI propose de placer des appels dans un fichier JSONL, puis de laisser Batch API les traiter de façon asynchrone. L’entreprise annonce une réduction de 50 % par rapport aux API synchrones, un réservoir de limites de débit distinct et un délai de 24 heures. Ce contrat intéresse les travaux que l’on peut lancer en arrière-plan : évaluations, classement d’un fonds documentaire ou création d’embeddings. Le prix par appel baisse. La responsabilité de livrer un ensemble complet reste chez celui qui a soumis le fichier.

La documentation décrit précisément le scénario embarrassant. Quand le traitement ne se termine pas dans la fenêtre prévue, le lot passe à l’état expired. Les réponses déjà produites se retrouvent dans le fichier de sortie. Les demandes restées en attente sont annulées et apparaissent dans le fichier d’erreurs, avec le code batch_expired. Les jetons consommés par les réponses achevées sont facturés. L’expiration ferme le lot, pas la comptabilité.

Deux unités de compte se croisent ici. Pour OpenAI, une réponse achevée a utilisé des jetons et porte un prix. Pour l’acheteur, un classement qui couvre seulement une partie des documents peut être inutilisable tant que les autres lignes n’ont pas été traitées. Le chiffre de la facture et le taux d’achèvement du projet racontent donc deux histoires différentes. Un rabais sur la première ne répare pas la seconde.

Le contrôle commence avant l’envoi. Chaque ligne du fichier d’entrée doit avoir un custom_id unique. OpenAI prévient que l’ordre des lignes du fichier de sortie peut différer de celui du fichier d’entrée. Rapprocher les lignes par leur position revient à remettre de mauvaises réponses sur de mauvais dossiers. Il faut conserver l’ensemble des identifiants envoyés, puis le comparer à ceux des réponses et des erreurs. Cette opération dit ce qui a été payé, ce qui a été rendu et ce qui reste à produire.

L’objet Batch ajoute un état général : expires_at, expired_at, les identifiants des fichiers de sortie et d’erreurs, ainsi que des compteurs de requêtes totales, terminées et échouées. Les champs d’utilisation donnent les volumes de jetons pour les lots éligibles. Ces nombres signalent l’écart; ils ne désignent pas les documents manquants. Seul le rapprochement des custom_id peut les nommer.

La relance se joue à cette frontière. Réexpédier tout le fichier initial inclurait aussi les lignes déjà achevées. Envoyer uniquement les identifiants restés sans réponse réduit le deuxième passage au travail qui manque. La documentation publique établit le mécanisme, pas le coût d’un client donné. Un montant concret exigerait son fichier de sortie, son relevé d’utilisation et le tarif du modèle employé.

La question à poser au moment de l’achat tient en une ligne : paie-t-on des réponses à prix réduit, ou achète-t-on un résultat complet pour une échéance interne ? Batch API facture la première unité. Le second engagement demande un registre de rapprochement et un responsable capable de décider quoi relancer.