La voie visuelle¶

Ce que le petit modèle a et que le grand n'a pas.

Le contraste à poser d'emblée¶

C'est la différence la plus visible entre les deux modèles

	Qwen3.8-Max (poids)	Qwen3.8-27B (poids)
Classe	`Qwen3_5MoeForCausalLM`	`Qwen3_5ForConditionalGeneration`
`model_type`	`qwen3_5_moe_text`	`qwen3_5`
Bloc `vision_config`	absent	présent
Images en entrée	❌	✅
Vidéo en entrée	❌	✅

Le suffixe _text du Max n'était pas décoratif : ses poids ouverts sont textuels, alors que son API accepte les images. Voir Licence et disponibilité du Max.

Le 27B, lui, publie tout — encodeur visuel compris.

Le fichier de configuration le dit d'ailleurs explicitement :

"language_model_only": false,
"image_token_id": 248056,
"video_token_id": 248057

Deux jetons du vocabulaire sont réservés pour signaler au modèle où insérer les représentations visuelles.

L'encodeur¶

"vision_config": {
  "depth": 27,
  "hidden_size": 1152,
  "intermediate_size": 4304,
  "num_heads": 16,
  "patch_size": 16,
  "temporal_patch_size": 2,
  "spatial_merge_size": 2,
  "num_position_embeddings": 2304,
  "out_hidden_size": 5120,
  "deepstack_visual_indexes": []
}

C'est un Transformer de vision classique de 27 couches, de dimension 1 152 — des proportions très proches de la famille SigLIP, largement utilisée comme encodeur visuel depuis 2024.

Le chemin d'une image¶

   image 448 × 448
        │
        ▼  découpage en carreaux de 16 × 16
   784 carreaux
        │
        ▼  projection linéaire → dimension 1 152
   784 vecteurs
        │
        ▼  + embeddings de position (2 304 disponibles)
        │
        ▼  27 couches de Transformer, 16 têtes
   784 vecteurs enrichis
        │
        ▼  fusion spatiale 2 × 2 : 4 carreaux → 1 jeton
   196 jetons
        │
        ▼  projection 4 608 → 5 120
   196 jetons dans l'espace du modèle de langage

La fusion 2 × 2 divise le coût par quatre

spatial_merge_size: 2 regroupe quatre carreaux voisins en un seul jeton avant de les envoyer au modèle de langage.

Une image de 448 × 448 coûte donc 196 jetons de contexte et non 784. C'est ce qui rend le traitement d'images abordable dans une fenêtre partagée avec du texte.

La vidéo¶

temporal_patch_size: 2 : les images d'une vidéo sont prises par paires. Deux images consécutives forment un seul carreau temporel, ce qui divise encore par deux le coût d'une séquence.

Le décompte¶

Composant	Paramètres
Projection des carreaux (\(3 \times 2 \times 16^2 \times 1\,152\))	1 770 624
Embeddings de position (\(2\,304 \times 1\,152\))	2 654 208
27 blocs de Transformer	411 404 400
Module de fusion vers 5 120	44 838 656
Total	≈ 460,7 M

Soit 1,7 % des paramètres du modèle.

Ce décompte est une reconstruction

La structure exacte des blocs et du module de fusion n'est pas documentée. Le calcul suppose un Transformer de vision standard et un module de fusion à deux couches.

Ce qui le valide : l'accord final à 0,26 % entre le total recalculé et la taille du dépôt. Une erreur importante sur l'encodeur s'y verrait.

Voir Vérification des paramètres.

Un encodeur bon marché

461 millions de paramètres pour la vision et la vidéo, sur un modèle de 27,7 milliards. La multimodalité coûte moins de 2 % du budget.

C'est le meilleur rapport du modèle : voir les scores en Le tableau officiel, où OSWorld-Verified passe de 63,9 à 84,3.

Le mRoPE¶

C'est la partie la plus subtile, et elle est propre au modèle multimodal.

"rope_parameters": {
  "mrope_interleaved": true,
  "mrope_section": [11, 11, 10],
  "partial_rotary_factor": 0.25,
  "rope_theta": 10000000
}

Le problème¶

Le RoPE ordinaire encode une position : le rang du jeton dans la séquence. C'est suffisant pour du texte, qui est unidimensionnel.

Une image ne l'est pas. Un carreau a une position horizontale et une position verticale. Une vidéo y ajoute une position temporelle. Les aplatir en un seul indice perdrait la structure : le modèle ne saurait plus que deux carreaux verticalement voisins le sont.

La solution¶

Le mRoPE (multimodal RoPE) découpe les dimensions soumises à rotation en trois groupes, un par axe.

mrope_section: [11, 11, 10] — soit 32 paires de dimensions au total, réparties en :

Groupe	Paires	Axe encodé
1	11	temps
2	11	hauteur
3	10	largeur

\[ 11 + 11 + 10 = 32 \text{ paires} = 64 \text{ dimensions} \]

Ce qui correspond exactement au RoPE partiel : \(0{,}25 \times 256 = 64\) dimensions tournées. Les deux réglages sont cohérents, ce qui est un bon signe de configuration bien formée.

Ce que mrope_interleaved change

Les trois groupes sont entrelacés plutôt que placés en blocs contigus. Chaque axe est donc représenté à toutes les échelles de fréquence, au lieu d'être confiné aux hautes ou aux basses.

Conséquence pratique : la position temporelle reste distinguable sur de longues vidéos, et la position spatiale sur de grandes images.

Pour du texte pur, tout cela est transparent

Sur une entrée textuelle, les trois indices sont égaux et le mRoPE se comporte exactement comme un RoPE ordinaire.

Il n'y a donc aucun coût à la multimodalité pour qui n'utilise que du texte — ni en calcul, ni en qualité. Seuls les 461 M de l'encodeur restent chargés en mémoire.

À retenir¶

Ce chapitre en cinq points

Contrairement au Max, le 27B publie son encodeur visuel : images et vidéo sont dans les poids.
L'encodeur est un Transformer de vision de 27 couches, dimension 1 152, pour 461 M de paramètres — 1,7 % du modèle.
La fusion 2 × 2 ramène une image de 448 × 448 à 196 jetons de contexte ; la fusion temporelle divise encore par deux le coût de la vidéo.
Le mRoPE encode trois positions — temps, hauteur, largeur — sur 11 + 11 + 10 paires de dimensions, cohérentes avec le RoPE partiel à 25 %.
Sur du texte pur, la voie visuelle est transparente : aucun coût de calcul, seulement 461 M en mémoire.

Chapitre suivant : Contexte et cache.