Inline Batching : Jusqu'à 10K Requêtes sans Fichier

L’alternative légère au File Batching

L’inline batching vous permet de soumettre des requêtes batch directement dans l’appel API, sans passer par l’étape d’upload de fichier. C’est la méthode idéale quand vous avez un volume modéré de requêtes (jusqu’à 10 000) et que vous voulez simplifier votre pipeline.

File Batching vs Inline Batching

Avant de plonger dans le code, clarifions les différences entre les deux approches :

Créer un job inline

Au lieu de passer un input_files, vous passez directement un paramètre requests contenant la liste de vos requêtes :

from mistralai import Mistral

client = Mistral(api_key="votre-clé-api")

# Préparer les requêtes inline
inline_requests = [
    {
        "custom_id": f"req-{i:04d}",
        "body": {
            "max_tokens": 150,
            "messages": [
                {
                    "role": "system",
                    "content": "Vous êtes un expert en classification de texte."
                },
                {
                    "role": "user",
                    "content": f"Classifiez ce texte : {text}"
                }
            ]
        }
    }
    for i, text in enumerate(mes_textes)
]

# Créer le job avec les requêtes inline
job = client.batch.jobs.create(
    requests=inline_requests,
    model="mistral-small-latest",
    endpoint="/v1/chat/completions"
)

print(f"Job inline créé : {job.id}")
print(f"Nombre de requêtes : {len(inline_requests)}")

La différence est minime dans le code : requests= au lieu de input_files=. Tout le reste du workflow (suivi de statut, téléchargement des résultats) est identique.

Cas d’usage concret : classification de tickets

Voici un exemple complet de classification de tickets de support client :

from mistralai import Mistral
import json
import time

client = Mistral(api_key="votre-clé-api")

# Simuler des tickets de support
tickets = [
    {"id": "TK-001", "message": "Je ne peux pas me connecter à mon compte"},
    {"id": "TK-002", "message": "Comment annuler mon abonnement ?"},
    {"id": "TK-003", "message": "L'application plante au démarrage"},
    {"id": "TK-004", "message": "Pouvez-vous ajouter le mode sombre ?"},
    {"id": "TK-005", "message": "Ma facture est incorrecte"},
]

# Construire les requêtes inline
requests = [
    {
        "custom_id": ticket["id"],
        "body": {
            "max_tokens": 50,
            "messages": [
                {
                    "role": "system",
                    "content": (
                        "Classifiez le ticket en une catégorie parmi : "
                        "AUTHENTIFICATION, FACTURATION, BUG, "
                        "FONCTIONNALITE, ABONNEMENT. "
                        "Répondez uniquement avec la catégorie."
                    )
                },
                {"role": "user", "content": ticket["message"]}
            ]
        }
    }
    for ticket in tickets
]

# Lancer le batch inline
job = client.batch.jobs.create(
    requests=requests,
    model="mistral-small-latest",
    endpoint="/v1/chat/completions"
)

# Attendre et récupérer les résultats
while True:
    status = client.batch.jobs.get(job_id=job.id)
    if status.status in ("SUCCESS", "FAILED", "CANCELLED"):
        break
    time.sleep(5)

# Parser les résultats
if status.status == "SUCCESS":
    data = client.files.download(file_id=status.output_file)
    for line in data.decode("utf-8").strip().split("\n"):
        entry = json.loads(line)
        ticket_id = entry["custom_id"]
        category = entry["response"]["body"]["choices"][0]["message"]["content"]
        print(f"{ticket_id} -> {category.strip()}")

Quand choisir l’une ou l’autre approche

Le critère décisif n’est pas seulement le volume, c’est la place du batch dans votre cycle de travail. En phase de prototypage, vous testez un prompt sur quelques centaines d’exemples, vous le corrigez, vous relancez : écrire un fichier JSONL intermédiaire à chaque itération ne ferait que ralentir la boucle. L’inline batching supprime cette friction — vos requêtes sont générées à la volée par votre script, soumises dans le même appel, et vous itérez en quelques minutes. C’est le même raisonnement pour une intégration légère, un script d’analyse ponctuel ou un traitement quotidien qui reste sous les 10 000 requêtes.

Le file batching reprend l’avantage dès que le batch devient un maillon de production. D’abord mécaniquement : au-delà de 10 000 requêtes, c’est la seule option. Mais surtout structurellement : un fichier uploadé est un artefact durable — vous pouvez le réutiliser pour plusieurs jobs, le conserver comme trace de ce qui a été soumis exactement, et séparer proprement l’étape de préparation (qui construit le fichier, le valide, le versionne) de l’étape d’exécution (qui lance le job). Quand un traitement batch tourne toutes les nuits sur des données clients, cette traçabilité n’est pas un luxe : c’est ce qui vous permet de répondre à la question « qu’avons-nous envoyé au modèle le 12 mars ? » six mois plus tard.

En pratique, beaucoup d’équipes utilisent les deux : inline pendant le développement du prompt, puis bascule vers le file batching au moment d’industrialiser — le code de suivi et de récupération des résultats restant identique, la migration se limite à remplacer requests= par input_files=.

Points clés à retenir

• L’inline batching supprime l’étape d’upload en passant les requêtes directement via le paramètre requests
• Limite de 10 000 requêtes par job inline, contre 1 million pour le file batching
• Le suivi de statut et le téléchargement des résultats sont identiques aux deux modes
• Privilégiez l’inline pour le prototypage et les volumes modérés, le file batching pour la production à grande échelle