Modèles multimodaux et Vision-Language-Action (VLA)

Un modèle multimodal apprend à manipuler plusieurs types d'entrées — texte, image, audio, parfois actions — dans un espace de représentation commun, de sorte qu'une légende et la photo qu'elle décrit finissent « au même endroit ». C'est le socle des assistants qui « voient », et c'est aussi, en bout de chaîne, ce qui permet à un robot de transformer « range la tasse bleue » en un mouvement de bras. Cet article suit ce fil : comment on fusionne les modalités (CLIP, ViT), comment on branche la vision sur un LLM (projecteur, cross-attention, natif), comment on les entraîne et les évalue, puis comment les Vision-Language-Action models (VLA) étendent tout cela à l'action incarnée.

Fusionner des modalités : l'idée centrale

Le problème de base est l'hétérogénéité : une image est une grille de pixels, un texte une suite de symboles discrets. Les fusionner suppose de projeter chaque modalité dans un même espace vectoriel où la proximité géométrique reflète la proximité de sens, indépendamment du format d'origine. Une fois ce pont posé, un encodeur d'image et un encodeur de texte peuvent « se parler » : on interroge dans une modalité et on récupère dans l'autre.

Deux familles cohabitent :

• Les modèles à double encodeur (style CLIP) gardent deux tours séparées et n'alignent que les vecteurs finaux. Ils sont parfaits pour la recherche (texte ⇄ image) et la classification zero-shot, mais ils ne génèrent rien — ils mesurent une proximité.
• Les modèles à fusion profonde (les VLM génératifs) injectent les tokens visuels dans un LLM, qui raisonne conjointement sur le texte et l'image pour produire du langage : décrire, répondre, raisonner.
• Les VLA prolongent cette seconde famille jusqu'à produire des actions plutôt que (ou en plus de) du texte.

On parle de fusion précoce (early fusion) lorsque les modalités sont mélangées dès l'entrée du réseau, et de fusion tardive (late fusion) lorsqu'on n'aligne que des représentations déjà calculées séparément. CLIP est l'archétype de la fusion tardive ; les VLM génératifs penchent vers la fusion précoce, car le LLM doit voir image et texte ensemble pour raisonner. Comprendre ce continuum aide à choisir l'architecture selon la tâche : récupérer, ou générer, ou agir.

Au-delà de l'image et du texte, le même principe s'étend à d'autres modalités :

• Audio (parole, sons d'environnement), aligné lui aussi par contraste sur du texte.
• Vidéo, traitée comme une séquence d'images avec une dimension temporelle.
• Capteurs robotiques (profondeur, proprioception, forces) chez les VLA.

Le motif est toujours le même : un encodeur par modalité, un alignement vers un espace commun, puis un raisonnement conjoint. C'est cette uniformité qui rend l'approche si fertile.

CLIP : l'alignement contrastif image-texte

CLIP (Contrastive Language-Image Pre-training, OpenAI, 2021) est le modèle fondateur de la fusion image-texte. Son architecture est un double encodeur : un encodeur d'image (ViT ou ResNet) et un encodeur de texte (Transformer) projettent chacun leur entrée dans un espace d'embedding partagé où images et textes proches par le sens se retrouvent côte à côte.

Figure : pré-entraînement contrastif de CLIP. Schéma original.

L'entraînement est contrastif. Sur un lot de N paires (image, légende), on calcule une matrice N×N de similarités cosinus : la diagonale correspond aux bonnes paires, le reste à des négatifs. L'objectif (une perte InfoNCE symétrique, image→texte et texte→image) rapproche chaque image de SA légende et éloigne toutes les autres. CLIP a été entraîné sur ~400 millions de paires image-texte récupérées du Web, avec des lots gigantesques (la matrice de similarité atteint 32 768 × 32 768).

Conséquence remarquable : un classificateur zero-shot. Pour classer une image parmi des catégories, on encode chaque catégorie sous forme de phrase (« une photo d'un chien »), on encode l'image, et on choisit la légende de plus forte similarité — sans aucun ré-entraînement. C'est cette aptitude qui a fait de CLIP la brique visuelle de quantité de systèmes ultérieurs (génération d'images, récupération, et… les VLM).

Quelques points souvent mal compris à propos de CLIP :

• La normalisation compte. Les embeddings sont projetés sur la sphère unité avant le calcul de similarité ; produit scalaire et cosinus coïncident alors, et un paramètre de température apprise contrôle la « netteté » de la distribution.
• Le contraste est symétrique. La perte additionne deux termes : trouver la bonne légende pour chaque image et la bonne image pour chaque légende. C'est ce qui rend l'espace réversible.
• CLIP n'est pas génératif. Il ne décrit pas une image : il mesure à quel point une image et un texte vont ensemble. La génération viendra des VLM, qui réutiliseront pourtant souvent l'encodeur de vision de CLIP.

Pour fixer les idées, le cœur de la perte contrastive tient en quelques lignes :

# Pseudo-code : perte contrastive symétrique de CLIP (un lot de N paires)
img_emb = l2_normalize(image_encoder(images))   # (N, d) sur la sphère unité
txt_emb = l2_normalize(text_encoder(texts))     # (N, d)
logits  = (img_emb @ txt_emb.T) * exp(temperature)  # similarités N×N
labels  = arange(N)                             # la bonne paire est sur la diagonale
loss_i  = cross_entropy(logits, labels)         # image → texte
loss_t  = cross_entropy(logits.T, labels)       # texte → image
loss    = (loss_i + loss_t) / 2                 # objectif symétrique

Pourquoi un espace partagé « fonctionne »

Pourquoi est-il raisonnable d'espérer qu'une image et sa description finissent au même endroit ? Parce que le sens est relationnel. Dans un espace appris, ce qui compte n'est pas la valeur absolue d'un axe mais la position relative : « chat » et « chien » sont proches l'un de l'autre et loin de « avion », que l'on parte d'une photo ou d'un mot. L'entraînement contrastif sculpte exactement cette géométrie : il tire les paires qui correspondent et repousse celles qui ne correspondent pas, jusqu'à ce que la structure de l'espace soit cohérente d'une modalité à l'autre.

Deux propriétés en découlent, précieuses pour la suite :

• Compositionnalité. Des concepts proches partagent des directions communes ; on peut combiner « tasse » et « bleue » de façon partiellement additive, ce qui aide à généraliser à des combinaisons jamais vues.
• Transférabilité. Un encodeur qui a appris cet espace sur des centaines de millions de paires Web emporte avec lui un « bon sens » visuel réutilisable — c'est ce capital qu'un VLM, puis un VLA, vont recycler au lieu de tout réapprendre.

C'est la raison profonde pour laquelle on réutilise des encodeurs pré-entraînés (CLIP, SigLIP, DINOv2) plutôt que d'en former de nouveaux : l'alignement coûte cher, autant le capitaliser.

Encodeurs de vision : du patch au token

Côté image, l'outil dominant est le Vision Transformer (ViT). L'idée clé est simple et puissante : découper l'image en patches (par ex. 14×14 ou 16×16 pixels), aplatir chaque patch, le projeter linéairement en un vecteur — et traiter cette séquence de vecteurs exactement comme une séquence de tokens pour un Transformer. Un patch devient un « mot visuel ».

Un ordre de grandeur utile : une image 224×224 en patches 14×14 produit 16×16 = 256 tokens visuels ; passer à 336×336 en fait grimper le nombre à 576. C'est ce simple calcul qui explique pourquoi la résolution coûte si cher en aval — chaque token supplémentaire alourdit toute l'attention du LLM.

Le ViT sort alors une grille de vecteurs (un par patch), porteurs d'information spatiale locale. C'est précisément ce dont un VLM a besoin : LLaVA, par exemple, prélève les grid tokens d'une couche avant-dernière de CLIP ViT-L/14 pour conserver le détail fin plutôt que de se contenter d'un unique vecteur global. Plus de patches = plus de tokens visuels = plus de détail, mais aussi plus de calcul dans le LLM en aval — un compromis central des VLM modernes.

Tous les encodeurs de vision ne se valent pas, et le choix influe fortement sur le VLM final :

• CLIP ViT apporte une forte alignement sémantique (il « sait » que cet objet est un chien), grâce à son pré-entraînement contrastif texte-image.
• SigLIP remplace la perte softmax de CLIP par une perte sigmoïde par paire, plus stable à grande échelle et souvent meilleure à budget égal.
• DINOv2 (auto-supervisé, sans texte) excelle sur la géométrie et le détail spatial fin, mais sans ancrage linguistique.

D'où une tendance forte : fusionner deux encodeurs (par ex. SigLIP + DINOv2) pour cumuler sémantique et précision spatiale — c'est exactement le choix d'OpenVLA, comme on le verra.

Brancher la vision sur un LLM : trois écoles

Comment fait-on « voir » un LLM purement textuel ? Trois stratégies, par fusion de plus en plus profonde.

Figure : architecture VLM → VLA et étapes d'entraînement. Schéma original.

1. Projection (LLaVA). L'approche la plus simple et la plus répandue. Un projecteur — une matrice apprise dans LLaVA 1.0, puis un MLP à deux couches avec activation GELU dans LLaVA 1.5 — convertit les vecteurs du ViT en « tokens d'image » qui vivent dans l'espace d'embedding du LLM. On les préfixe simplement aux tokens de texte : le LLM consomme alors une séquence mixte, sans modification de son architecture. Léger, efficace, c'est la recette par défaut de la plupart des VLM open source.

2. Cross-attention (Flamingo). DeepMind insère des blocs de cross-attention « gated » entre les couches du LLM. Les requêtes (texte) interrogent les clés/valeurs (vision) ; un gating tanh initialisé à zéro garantit qu'au départ le modèle se comporte exactement comme le LLM d'origine, puis ouvre progressivement la porte aux signaux visuels — ce qui stabilise l'entraînement. Cette voie gère élégamment plusieurs images entrelacées et de longues séquences.

3. Multimodal natif (GPT-4o, Gemini, Qwen2-VL). Plutôt qu'ajouter la vision après coup, on entraîne dès le départ un modèle unique qui traite tokens d'image et de texte de façon uniforme via la même self-attention, avec des tokens spéciaux pour délimiter le visuel (par ex. vision_start/vision_end). GPT-4o et Gemini sont décrits comme nativement multimodaux ; leurs détails exacts restent non publiés. C'est la voie qui généralise le mieux mais la plus coûteuse à entraîner.

Comment choisir ? En pratique :

• La projection est imbattable en rapport simplicité/coût : on réutilise un ViT et un LLM existants, on n'entraîne presque rien au départ. C'est pourquoi la quasi-totalité des VLM open source l'adoptent.
• La cross-attention brille sur les séquences multi-images entrelacées (documents, vidéos, dialogues riches en images) et garde le LLM intact au démarrage grâce au gating à zéro.
• Le natif offre la meilleure fusion et la meilleure généralisation, mais exige un pré-entraînement multimodal de bout en bout — donc des moyens que seuls les grands laboratoires alignent.

Tokeniser une image

Dans les approches « projection » et « natif », l'image finit représentée par une séquence de tokens homogène à du texte. C'est ce qui rend les VLM si pratiques : tout le pipeline d'un LLM (attention, génération auto-régressive, KV-cache) s'applique tel quel. Le revers est le budget de tokens : une image en haute résolution peut coûter des centaines, voire des milliers de tokens. D'où les techniques de réduction — pooling, resampler à la Flamingo (Perceiver Resampler compressant une grille variable en un petit nombre fixe de tokens), tuiles à résolution adaptative — pour contenir le coût sans sacrifier le détail utile.

Entraîner un VLM : aligner puis instruire

Le schéma d'entraînement de LLaVA est devenu canonique, en deux étapes.

• Étape 1 — alignement de caractéristiques. On gèle l'encodeur de vision ET le LLM, et on n'entraîne que le projecteur sur des paires image-légende (595 000 paires filtrées de CC3M pour LLaVA). Objectif : apprendre au projecteur à mapper l'espace visuel vers l'espace du langage. C'est rapide et stable.
• Étape 2 — instruction visuelle. On dégèle le LLM et le projecteur (l'encodeur de vision reste souvent gelé) et on entraîne sur des dialogues visuels de plus haute qualité (158 000 conversations synthétiques pour LLaVA). Le modèle apprend à suivre des instructions, décrire, raisonner, répondre à des questions sur l'image.

Des modèles plus récents (Qwen2-VL) ajoutent une troisième étape et dégèlent progressivement les composants, sur des volumes massifs (de l'ordre de 10^12 tokens). Le principe reste le même : d'abord aligner les modalités, ensuite enseigner le comportement.

# Pseudo-code : forward d'un VLM de type LLaVA
patches = vit(image)               # ViT → grille de tokens visuels (spatial)
img_tokens = projector(patches)    # MLP : espace vision → espace LLM
txt_tokens = embed(text)           # tokens de texte
seq = concat([img_tokens, txt_tokens])  # on PRÉFIXE l'image au texte
logits = llm(seq)                  # le LLM raisonne conjointement
answer = decode(logits)            # génération auto-régressive de texte

Évaluer les VLM — et le problème des hallucinations

On évalue les VLM sur des questions visuelles (VQA), du captioning, du raisonnement spatial, de l'OCR, des graphiques et documents. Mais le risque majeur est l'hallucination d'objets : le modèle décrit des éléments absents de l'image, par excès de prior linguistique (le LLM « complète » selon ce qui est plausible textuellement, pas selon ce qu'il voit). Les causes habituelles : un encodeur de vision gelé qui perd du détail, un déséquilibre entre signal visuel et signal textuel, des données d'instruction biaisées. Les parades : meilleurs encodeurs, plus haute résolution, données de grounding (ancrage explicite objet ↔ région), et des benchmarks dédiés (POPE pour l'hallucination d'objets, MMMU pour le raisonnement multimodal exigeant). Règle de prudence : un VLM fluide n'est pas un VLM fiable — il faut mesurer le grounding, pas seulement la qualité de prose.

Des VLM aux VLA : ajouter l'action

Un Vision-Language-Action model (VLA) est un modèle de fondation multimodal qui intègre vision, langage ET actions. À partir d'images de caméra et d'une instruction en langage naturel, il produit des commandes exécutables par un robot. L'intuition fondatrice : un VLA est un VLM plus un décodeur d'action. La perception et le raisonnement sont assurés par le VLM (qui encode images + texte en tokens dans un espace latent partagé) ; un étage final convertit ces tokens en commandes représentant les degrés de liberté du robot (déplacements, rotations, ouverture de pince).

Le coup de génie qui a lancé le domaine : traiter les actions comme des tokens. Si l'on discrétise une action continue (par ex. « avancer de 50 mm ») en un identifiant discret, alors générer une trajectoire revient exactement à générer du texte — même architecture Transformer, même objectif auto-régressif, et surtout transfert du savoir acquis sur des milliards d'images et de textes du Web vers le contrôle moteur.

Concrètement, on discrétise chaque dimension d'action (déplacement en x, y, z, rotation, état de la pince) en un petit nombre de bacs (souvent 256), chacun associé à un token. Un pas de contrôle devient alors une courte suite de tokens d'action, et le modèle apprend à la générer comme il générerait une phrase. À l'inférence, on dé-tokenise ces identifiants pour retrouver des consignes continues (couples, vitesses) envoyées au contrôleur bas niveau. L'élégance de l'approche est qu'elle n'invente rien côté architecture : c'est un LLM multimodal standard dont on a élargi le vocabulaire.

Exemple de bout en bout : de l'instruction au geste

Suivons « range la tasse bleue » à travers un VLA à tokens d'action :

1. La caméra capture la scène ; l'encodeur de vision la découpe en patches et produit des tokens visuels.
2. Le projecteur les amène dans l'espace du LLM ; ils sont fusionnés avec les tokens de l'instruction.
3. Le LLM raisonne conjointement : il « voit » la tasse bleue, comprend l'ordre, planifie.
4. Il génère des tokens d'action (Δx, Δy, Δz, rotation, pince) pas après pas.
5. Ces tokens sont dé-tokenisés en consignes continues envoyées au contrôleur du bras.
6. Le robot agit ; la nouvelle image revient en entrée, et la boucle recommence.

image (patches) ─▶ ViT ─▶ projecteur ─┐
                                       ├─▶ LLM ─▶ tokens d'action ─▶ dé-tokenise ─▶ robot
instruction ─────▶ tokens texte ───────┘            ▲                                  │
                                                     └──────── nouvelle image ◀─────────┘

Toute la difficulté pratique tient dans cette boucle fermée : chaque itération doit être assez rapide pour que le geste reste fluide, ce qui ramène au défi de latence évoqué plus loin.

RT-2 : le pionnier

RT-2 (Google DeepMind, juillet 2023) a établi le paradigme VLA. Il co-entraîne un VLM (sur les backbones PaLI-X et PaLM-E) à la fois sur des données Web et sur des données de robot, en représentant les actions du robot comme des tokens au même titre que le langage. Concrètement, une action continue est discrétisée en un token (« déplace-toi de 50 mm » devient, par ex., le token n°1247), réutilisant le vocabulaire du modèle. Résultat : RT-2 généralise mieux que son prédécesseur RT-1 à des tâches nouvelles et peut enchaîner un raisonnement multi-étapes (chain-of-thought) tirant parti des connaissances héritées du Web — par exemple « choisir l'objet qui sert à enfoncer un clou ».

L'apport décisif n'est pas une nouvelle architecture mais une représentation : en écrivant l'action dans le même alphabet que le langage, RT-2 fait du contrôle moteur un cas particulier de génération de texte, et hérite « gratuitement » du raisonnement appris sur le Web.

OpenVLA : l'open source à 7 milliards de paramètres

OpenVLA (Stanford et collaborateurs, juin 2024) a rendu le paradigme ouvert et reproductible. C'est un modèle de 7 milliards de paramètres entraîné sur ~970 000 épisodes de robot issus du dataset Open X-Embodiment (couvrant 22 morphologies de robots différentes). Son architecture :

• un encodeur de vision fusionné combinant SigLIP et DINOv2 (sémantique + détail spatial) ;
• un projecteur mappant les embeddings visuels vers l'espace du langage ;
• un backbone Llama-2 7B qui prédit des tokens d'action discrets, ensuite dé-tokenisés en commandes continues directement exécutables.

OpenVLA surpasse des politiques généralistes antérieures (RT-1-X, Octo) et même RT-2-X (un VLA fermé de 55 milliards de paramètres) sur de nombreuses tâches — RT-2-X gardant l'avantage sur la généralisation sémantique fine qui exige des connaissances Web. Côté ingénierie, OpenVLA a été entraîné sur 64 GPU A100 pendant 15 jours, et il se fine-tune efficacement : LoRA n'ajuste que 1,4 % des paramètres tout en égalant le fine-tuning complet — un atout décisif pour l'adaptation à un nouveau robot ou une nouvelle tâche.

Pour le praticien, OpenVLA illustre deux leçons concrètes : le choix d'un encodeur fusionné (sémantique + spatial) est payant pour la manipulation, et la quantification plus LoRA rendent réaliste l'adaptation sur du matériel modeste, sans cluster.

π0 (pi-zero) : sortie continue par flow-matching

π0 (Physical Intelligence, fin 2024) prend l'autre chemin pour la dextérité haute fréquence. Plutôt que des tokens discrets, il s'appuie sur un VLM (PaliGemma, construit à partir de SigLIP et Gemma) et génère directement des actions continues via un réseau de flow-matching (cousin des modèles de diffusion). Cela produit des trajectoires fluides à ~50 Hz, mieux adaptées à des robots à nombreux degrés de liberté et à des gestes fins (plier du linge, manipuler des objets délicats). Le compromis se dessine ainsi : tokens discrets = simplicité et héritage direct du LLM, mais granularité limitée ; sortie continue (diffusion/flow) = précision et haute fréquence, au prix d'un décodeur plus complexe.

Une notion clé revient ici : les action chunks. Au lieu de prédire un seul pas, le modèle génère d'un coup une courte séquence d'actions futures, ce qui lisse la commande et amortit le coût d'une passe du gros VLM — une astuce centrale pour tenir la cadence temps réel.

Généralisation et raisonnement incarné

La promesse des VLA est la généralisation incarnée : parce que le tronc est un VLM pré-entraîné sur le Web, le robot hérite d'un bon sens visuel et linguistique qu'aucune démonstration robotique seule ne pourrait fournir. Il peut suivre des instructions inédites, reconnaître des objets jamais vus en démonstration, et raisonner sur la tâche (« range d'abord la tasse, puis essuie la table »). Le dataset Open X-Embodiment pousse plus loin : entraîner une seule politique sur plusieurs morphologies pour viser un contrôleur générique, transférable d'un robot à l'autre.

Défis ouverts

• Latence. Un LLM de plusieurs milliards de paramètres dans une boucle de contrôle temps réel est un défi : générer des tokens est lent, alors que le contrôle exige 10–50 Hz. D'où les sorties continues (π0), la distillation, la quantification, les action chunks (prédire plusieurs pas d'un coup).
• Données. Les démonstrations robotiques sont rares et coûteuses face aux téraoctets de texte/image du Web ; la télé-opération ne passe pas à l'échelle. Open X-Embodiment, la simulation et l'apprentissage à partir de vidéos humaines tentent de combler le fossé.
• Sécurité et fiabilité. Une hallucination dans un chatbot produit une phrase fausse ; dans un VLA, elle produit un geste. Garde-fous, détection hors-distribution, arrêts d'urgence et bornes de couple sont indispensables.
• Évaluation. Mesurer une politique robotique dans le monde réel est lent, bruité et difficilement reproductible — un frein concret au progrès.

Discret ou continu : récapitulatif

Le choix de la représentation d'action structure tout le système :

• Tokens discrets (RT-2, OpenVLA). Avantages : architecture identique à un LLM, héritage direct du pré-entraînement Web, simplicité d'implémentation, fine-tuning par LoRA très efficace. Limite : la granularité dépend du nombre de bacs, et la génération token par token peut brider la fréquence de contrôle.
• Sortie continue / flow-matching (π0). Avantages : trajectoires fluides, haute fréquence (~50 Hz), bonne dextérité sur de nombreux degrés de liberté. Limite : décodeur plus complexe (diffusion/flow), entraînement et débogage moins « LLM-classiques ».

Il n'existe pas de gagnant universel : le bon choix dépend de la tâche (préhension grossière vs gestes fins), de la fréquence de contrôle exigée, et des contraintes de calcul embarqué.

Au-delà de la robotique

La multimodalité ne se limite pas aux bras articulés. Les mêmes briques alimentent :

• des assistants visuels (décrire une scène, lire un graphique, extraire un tableau d'une capture d'écran) ;
• des agents qui pilotent une interface (computer use) en « voyant » l'écran et en cliquant ;
• la recherche multimodale et la modération de contenu (texte + image) ;
• l'accessibilité (description d'images pour personnes malvoyantes) et l'analyse documentaire (OCR + raisonnement).

Le fil conducteur reste identique : projeter des modalités hétérogènes dans un espace commun, puis laisser un Transformer raisonner — que la sortie soit une phrase, un clic ou un mouvement.

Données et passage à l'échelle

Une leçon traverse tout le domaine : la donnée est le vrai goulot d'étranglement. Côté VLM, on dispose de milliards de paires image-texte sur le Web, ce qui a rendu CLIP et ses successeurs possibles. Côté VLA, on parle de centaines de milliers d'épisodes seulement (≈970 000 pour Open X-Embodiment) — plusieurs ordres de grandeur en moins. Trois pistes pour réduire l'écart :

• Mutualiser les morphologies. Open X-Embodiment agrège des données de 22 robots différents pour entraîner une politique unique ; chaque embodiment profite des autres.
• Co-entraîner sur le Web. RT-2 mélange données robot et données image-texte généralistes, ce qui injecte du « bon sens » et améliore la généralisation sémantique.
• Apprendre sans téléopération. Simulation, vidéos humaines et auto-supervision visent à produire du signal d'action sans démonstration humaine coûteuse.

Le pari implicite des VLA est que la mise à l'échelle qui a transformé le NLP puis la vision finira par transformer le contrôle moteur — à condition de résoudre d'abord la rareté des données d'action.

Checklist pratique : choisir et construire

Pour transformer cette théorie en décisions, une grille de questions à se poser dans l'ordre :

1. Quelle sortie ? Récupération/classification → un double encodeur (CLIP/SigLIP) suffit. Description, Q/R, raisonnement → un VLM. Contrôle d'un robot → un VLA.
2. Quel encodeur de vision ? Privilégier le sémantique (CLIP/SigLIP) pour décrire et raisonner ; ajouter du spatial (DINOv2) quand la géométrie compte (manipulation, OCR fin).
3. Quel mode de fusion ? Projection par défaut (simple, peu coûteux) ; cross-attention pour les longues séquences multi-images ; natif seulement avec un budget de pré-entraînement conséquent.
4. Quelle résolution / quel budget de tokens ? Monter la résolution améliore le détail mais alourdit le LLM ; envisager pooling ou resampler si le contexte explose.
5. Discret ou continu (VLA) ? Tokens discrets pour la simplicité et le transfert Web ; sortie continue (flow/diffusion) pour la haute fréquence et la dextérité fine.
6. Comment évaluer ? Mesurer le grounding (POPE, MMMU), pas seulement la fluidité ; pour un VLA, prévoir une évaluation réelle, lente mais incontournable.

Cette séquence — sortie, encodeur, fusion, résolution, représentation d'action, évaluation — couvre l'essentiel des arbitrages d'un projet multimodal, du moteur de recherche à la politique robotique.

En résumé

La trajectoire est cohérente : CLIP apprend à aligner image et texte dans un espace partagé ; le ViT transforme l'image en tokens ; un projecteur (ou de la cross-attention, ou un entraînement natif) branche cette vision sur un LLM ; l'entraînement procède en alignant puis en instruisant ; et les VLA poussent l'idée jusqu'à produire des actions comme des tokens (RT-2, OpenVLA) ou des trajectoires continues (π0). Le même principe — projeter des modalités hétérogènes dans un espace commun et laisser un Transformer raisonner dessus — relie la légende d'image au bras robotique. Restent les verrous du monde réel : latence, données, sécurité, évaluation — c'est là que se jouera la prochaine génération de l'IA incarnée.