Modèles supportés et compatibilité

Compatibilité des modèles Mistral

Tous les modèles Mistral ne traitent pas les sorties structurées de la même manière. Avant d’écrire la première ligne de code, vérifiez que le modèle visé est compatible avec l’approche que vous avez retenue — c’est une vérification de trente secondes qui évite une erreur d’API incompréhensible en fin de développement.

La bonne nouvelle tient en une phrase : la quasi-totalité des modèles Mistral supportent les sorties structurées, aussi bien en JSON Mode qu’en Custom Structured Outputs. La seule exception notable est codestral-mamba, qui ne supporte ni l’un ni l’autre.

Les modèles principaux

Voici les modèles les plus couramment utilisés et leur compatibilité (avril 2026) :

Modèle	Compatibilité	Usage typique
`mistral-large-latest`	Support complet (JSON Mode + Custom)	Tâches complexes exigeant des sorties structurées fiables
`mistral-medium-latest`	Support complet	Bon compromis performance/coût pour les pipelines de production
`mistral-small-latest`	Support complet	Tâches simples (classification, extraction d’entités basiques) à budget limité
`ministral-8b-latest`	Support complet	Extractions légères avec une latence minimale
`ministral-3b-latest`	Support complet	Le plus léger, quand la vitesse prime sur la complexité
`codestral-latest`	Support complet	Optimisé pour le code, fonctionne aussi sur des tâches non-code
`codestral-mamba`	Non supporté	Architecture Mamba, incompatible avec les mécanismes de sorties structurées
`mistral-embed`	Non applicable	Modèle d’embeddings, pas de génération de texte

Les modèles généralistes Large 3, Medium 3.5 et Small 4 couvrent donc l’essentiel des besoins, les Ministral prennent le relais sur les contraintes de latence, et la seule véritable impasse reste codestral-mamba.

Choisir le bon modèle

En phase de prototypage, prenez mistral-small-latest ou ministral-8b-latest. Ils sont rapides, peu coûteux, et amplement suffisants pour valider que votre schéma tient et que votre prompt dit ce que vous croyez qu’il dit. Payer le modèle le plus puissant pour découvrir qu’un champ était mal nommé serait du gâchis.

# Prototypage — modèle léger
response = client.chat.parse(
    model="ministral-8b-latest",
    messages=messages,
    response_format=MonSchema
)

Le passage en production change les critères. Une extraction multi-champs, une analyse de sentiments nuancée ou une classification fine justifient mistral-large-latest ; à l’inverse, une tâche simple traitée à fort volume reste très bien servie par mistral-small-latest. Notez au passage l’ajout de temperature=0, sur lequel nous revenons plus bas.

# Production — modèle puissant
response = client.chat.parse(
    model="mistral-large-latest",
    messages=messages,
    response_format=MonSchema,
    temperature=0  # Reproductibilité maximale
)

Reste le cas des pipelines à haute fréquence, où la latence devient la contrainte dominante. Si vous traitez des milliers de requêtes par minute — classification de tickets, triage d’emails — ministral-8b-latest offre le meilleur ratio latence/qualité, et plafonner maxTokens évite que le modèle s’attarde sur des réponses trop longues.

// TypeScript — pipeline haute fréquence
const response = await client.chat.parse({
  model: "ministral-8b-latest",
  messages,
  responseFormat: MonSchema,
  maxTokens: 128,  // Limiter pour la vitesse
});

Le paramètre `temperature`

Un point mérite votre attention : temperature influence la variabilité de la sortie même en mode structuré. À 0, la sortie est déterministe, ce qui est le réglage recommandé en production et partout où la reproductibilité compte — deux exécutions sur le même document doivent donner le même enregistrement. Entre 0.1 et 0.3, vous introduisez une légère variabilité, utile uniquement si vous souhaitez des formulations différentes dans les champs textuels libres comme un résumé. À partir de 0.7, la variabilité devient forte et le modèle peut produire des valeurs incohérentes : c’est à proscrire avec les sorties structurées.

Vérifier la compatibilité programmatiquement

En production, plutôt que de vous fier à une liste, capturez l’erreur remontée par le SDK lorsqu’un modèle ne sait pas honorer la demande :

from mistralai import Mistral
from mistralai.models import SDKError

client = Mistral(api_key=api_key)

try:
    response = client.chat.parse(
        model="codestral-mamba",  # Non supporté
        messages=[{"role": "user", "content": "Test"}],
        response_format=MonSchema
    )
except SDKError as e:
    print(f"Modèle non compatible : {e}")

Ce réflexe garde son utilité dans la durée. Mistral publie régulièrement de nouveaux modèles, et la compatibilité avec les sorties structurées est devenue un standard que les nouvelles générations supportent systématiquement ; consultez la documentation officielle pour la liste à jour avant d’épingler un identifiant dans votre configuration.

Points clés à retenir