Architecture Multimodale des Modèles Mistral
Mis à jour le 29 juillet 2026
Comment un modèle traite-t-il texte et image ?
Lorsque vous envoyez une image à un modèle Mistral, celui-ci ne la « voit » pas comme un humain. Le traitement repose sur une architecture en deux étapes : un encodeur visuel transforme d’abord l’image en une séquence de tokens numériques, puis le modèle de langage traite ces tokens visuels aux côtés des tokens textuels de votre question.
Cette leçon peut sembler théorique ; elle est en réalité la plus rentable de la formation. Comprendre ce mécanisme explique pourquoi une image 4K ne donne pas de meilleurs résultats qu’une image 1080p, pourquoi votre facture mensuelle grimpe plus vite avec cinq images qu’avec cinq paragraphes, et pourquoi un texte minuscule sur une capture d’écran ressort mal transcrit.
L’encodeur visuel (Vision Encoder)
L’encodeur visuel est un réseau de neurones spécialisé — généralement un Vision Transformer (ViT) — qui découpe l’image en petits patchs carrés, par exemple 14×14 pixels, et les convertit en embeddings numériques. Le pipeline se déroule en cinq temps :
- Redimensionnement : l’image est mise à une résolution standard (ex. 384×384 ou 768×768 pixels)
- Découpage en patchs : l’image redimensionnée est divisée en patchs réguliers
- Projection : chaque patch est converti en un vecteur numérique (embedding)
- Encodage positionnel : l’information de position de chaque patch est ajoutée
- Attention : le transformer visuel traite la séquence complète
Le résultat est une séquence de tokens visuels, en tout point comparables aux tokens de texte, à ceci près qu’ils représentent des régions de l’image plutôt que des morceaux de mots. La première étape mérite votre attention : c’est elle qui explique qu’un scan de facture en 4 000 pixels de large soit ramené à quelques centaines avant même d’être analysé. Les caractères d’une mention légale en petits corps, déjà à la limite du lisible, deviennent alors quelques pixels flous.
Fusion texte-image dans le LLM
Une fois les tokens visuels produits, ils sont insérés dans la séquence d’entrée du modèle de langage, aux côtés des tokens textuels. Le modèle traite l’ensemble de manière unifiée grâce au mécanisme d’attention croisée (cross-attention).
[tokens texte: "Décrivez cette image"] + [tokens visuels: patch1, patch2, ..., patchN]
↓
Modèle de langage (LLM)
↓
[tokens de sortie: "Cette image montre..."]
Le modèle peut ainsi « lire » l’image et le texte simultanément, ce qui lui permet de répondre à des questions précises sur le contenu visuel. C’est aussi ce qui explique qu’une question posée avant l’image et une question posée après ne donnent pas exactement le même résultat : tout est dans la même séquence, et l’ordre compte.
Impact sur le comptage de tokens
Chaque image consomme un certain nombre de tokens, qui dépend de sa résolution après redimensionnement. C’est le point à retenir pour estimer vos coûts. Une image standard, autour de 768×768, consomme entre 800 et 1 500 tokens — soit l’équivalent d’une à deux pages de texte. Les images plus grandes sont redimensionnées avant traitement : envoyer une image 4K ne consomme pas plus qu’une image 1080p, mais ne rapporte rien non plus. À ce total s’ajoutent le texte de votre prompt et la réponse générée.
# Exemple : estimer le coût d'un appel vision
tokens_image = 1000 # estimation moyenne
tokens_prompt = 50 # "Décrivez cette image en détail"
tokens_reponse = 200 # réponse estimée
total_tokens = tokens_image + tokens_prompt + tokens_reponse
print(f"Tokens totaux estimés : {total_tokens}")
# → Tokens totaux estimés : 1250
Faites tourner ce calcul sur votre propre volumétrie avant d’industrialiser : mille images par jour représentent au bas mot un million de tokens en entrée, ce qui déplace la discussion du prototype vers le budget.
Limites de taille et de résolution
Mistral accepte les formats JPEG, PNG, GIF (première frame) et WebP, pour une taille maximale d’environ 20 Mo par image. Plusieurs images peuvent cohabiter dans un même message, sujet que nous traiterons en leçon 6. La contrainte la plus contre-intuitive reste le redimensionnement interne : une très haute résolution n’améliore pas les résultats, elle allonge simplement le temps de transfert.
La conséquence pratique est qu’il vaut mieux redimensionner vous-même, en amont, plutôt que de laisser l’API le faire après un upload inutilement lourd :
from PIL import Image
def preparer_image(chemin, taille_max=1024):
"""Redimensionne une image avant envoi pour optimiser la latence."""
img = Image.open(chemin)
img.thumbnail((taille_max, taille_max))
img.save(chemin, quality=85)
return chemin
Cette fonction s’insère juste avant l’encodage Base64 ou la mise à disposition par URL. Sur un lot de photos de smartphone à 4 Mo pièce, elle divise le volume transféré par un facteur important sans perte de qualité significative pour l’analyse.
Architecture simplifiée
Vu de bout en bout, le trajet d’une requête tient en cinq étapes : vous envoyez un message contenant du texte et une ou plusieurs images ; l’API redimensionne chaque image et l’envoie à l’encodeur visuel ; les tokens visuels obtenus sont fusionnés avec les tokens textuels ; le modèle génère une réponse en langage naturel ; vous la recevez comme pour un appel textuel classique. Rien ne change dans votre code côté API — la complexité est entièrement gérée par Mistral, ce qui ne vous dispense pas de savoir ce qu’elle vous coûte.
Points clés à retenir
- Les images sont converties en tokens visuels par un encodeur Vision Transformer
- Ces tokens visuels sont traités par le LLM au même titre que les tokens textuels
- Une image standard consomme environ 800 à 1 500 tokens
- Les images sont redimensionnées en interne — inutile d’envoyer de la très haute résolution
- Redimensionner vos images côté client réduit la latence sans perte de qualité