Réduire la Latence avec les Predicted Outputs

Le problème de la latence en production

En production, chaque milliseconde compte. Lorsqu’un utilisateur attend la réponse d’un LLM pour une modification mineure de code ou de texte, la latence standard de génération token par token peut sembler disproportionnée. Si 90 % de la sortie attendue est déjà connue, pourquoi le modèle devrait-il la régénérer intégralement ?

Les Predicted Outputs (sorties prédites) résolvent ce problème. En fournissant au modèle une prédiction de ce que sera la sortie, vous lui permettez d’allouer ses ressources de calcul uniquement sur les parties qui diffèrent réellement, réduisant drastiquement le temps de réponse.

Le concept : prédire pour accélérer

Le principe est simple. Vous connaissez déjà une grande partie de la réponse attendue — par exemple, un fichier de code existant que vous voulez modifier légèrement. Au lieu de laisser le modèle tout régénérer, vous lui passez le contenu prévu via le paramètre prediction :

response = client.chat.complete(
    model="mistral-large-latest",
    messages=[...],
    prediction={
        "type": "content",
        "content": contenu_attendu
    }
)

Le modèle utilise alors ce contenu comme base. Il consacre ses ressources de calcul aux tokens qui diffèrent de la prédiction, ce qui accélère significativement la génération.

Comment ça fonctionne techniquement

Quand vous fournissez une prédiction :

1. Le modèle reçoit la prédiction comme contexte supplémentaire
2. Il compare sa génération avec le contenu prédit
3. Les tokens identiques sont validés rapidement sans coût de calcul complet
4. Les tokens différents sont générés normalement

Le résultat : la qualité de la réponse est préservée, mais le temps de génération est réduit proportionnellement au pourcentage de contenu correctement prédit.

Modèles compatibles

En avril 2026, deux modèles supportent les Predicted Outputs :

• mistral-large-latest — Pour les tâches complexes d’édition et de raisonnement
• codestral-latest — Optimisé pour l’édition de code

Quand utiliser les Predicted Outputs

Les scénarios idéaux sont ceux où la sortie est largement prévisible :

• Modification de code — Vous changez un nom de variable, un paramètre, ou une petite section dans un fichier existant. Le reste du fichier ne bouge pas.
• Édition de texte — Vous corrigez une phrase, reformulez un paragraphe, ou mettez à jour une date dans un document long.
• Remplissage de templates — La structure de la réponse est fixe, seules quelques valeurs changent.
• Mise à jour de configurations — Vous modifiez une clé dans un fichier JSON/YAML volumineux.

Quand ne PAS les utiliser

Les Predicted Outputs ne sont pas adaptés quand :

• La sortie est entièrement imprévisible (réponses créatives, brainstorming)
• Le contenu change à plus de 50 % entre la prédiction et la sortie réelle
• Vous utilisez le paramètre n (générations multiples) — il est incompatible

Impact sur le pricing

Bonne nouvelle : les Predicted Outputs n’ont aucun impact sur le pricing. Vous ne payez pas plus cher pour fournir une prédiction. Vous payez uniquement les tokens effectivement générés, comme d’habitude.

Points clés à retenir

• Les Predicted Outputs réduisent la latence en exploitant du contenu prévisible
• Le paramètre prediction fournit au modèle la sortie attendue comme base
• Deux modèles compatibles : mistral-large-latest et codestral-latest
• Idéal pour l’édition de code, la modification de texte et les templates
• Aucun surcoût tarifaire — la qualité est préservée