LLaVA-OneVision-2 : ce que la sélection de patches alignée codec change pour l'entraînement multimodal
Fully Open Framework for Democratized Multimodal Training
En bref
- De quoi s’agit-il ?
- Le framework 8B de Glint Lab réunit image, vidéo longue et raisonnement spatial sous une seule architecture, avec données, encodeurs, code d'entraînement et journaux publiés. La vraie rupture est dans l'encodeur, pas dans les scores.
- À qui s’adresse-t-il ?
- LLaVA-OneVision-2 s'adresse aux équipes qui entraînent ou affinent des modèles vision-langage et veulent disposer des poids d'encodeur, des configurations et des journaux d'entraînement, pas seulement d'un checkpoint d'inférence.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème que le projet attaque : la couverture temporelle vidéo à budget de tokens constant
La plupart des modèles multimodaux ouverts restent dans un monde 2D à image unique. Le README le formule ainsi : « Most open multimodal models still live in a 2D, single-image world. » LLaVA-OneVision-2 vise trois charges de travail dans un seul modèle de 8B : vidéo longue, raisonnement spatial 3D (profondeur, disposition, relations entre objets) et documents ou graphiques en résolution native. Le public visé est celui qui entraîne ces modèles, pas seulement celui qui les appelle : le dépôt publie les poids d'encodeur, le code d'entraînement, les configurations et les journaux complets. C'est une différence de nature avec les publications qui ne livrent qu'un checkpoint et une carte de modèle. Le point de friction que le projet met en avant est précis : à budget de tokens fixé, l'échantillonnage uniforme de trames épuise le contexte temporel disponible. Le README annonce, pour un budget identique de 54 tokens, une portée temporelle trois fois supérieure avec la sélection alignée codec.
Encodeurs alignés codec : sélectionner les patches, pas échantillonner les trames
OneVision-Encoder et OneVision-Encoder-Lang sont décrits comme des transformeurs visuels de style HEVC. Ils ajoutent un mode d'entrée flux codec à côté de l'image et de la vidéo à trames uniformes. Le mécanisme annoncé : retenir uniquement les patches riches en mouvement et en résidu, et échantillonner des trames denses de façon clairsemée plutôt que des trames clairsemées de façon dense. La formulation du README est inversée par rapport à l'intuition, et c'est justement l'intérêt : on ne choisit plus quelles trames garder, on choisit quels patches d'un flux dense méritent d'occuper le budget. Un encodeur vidéo classique ne peut pas faire ce tri, il consomme le contexte jusqu'à saturation. Le schéma method_codec_selection illustre la comparaison à budget égal. Il faut noter ce que la documentation ne dit pas : aucune architecture interne détaillée de l'encodeur n'apparaît dans le README, seulement le principe de sélection et le renvoi au rapport technique arXiv 2605.25979. Pour évaluer si le gain tient sur vos données, il faudra lire ce rapport, pas le dépôt.
Deux backends d'inférence, deux chemins d'évaluation
Le README mentionne explicitement un backend frames et un backend codec, tous deux couverts par la branche d'évaluation. C'est un point pratique : le chemin codec n'est pas le seul moyen d'exécuter le modèle, et les résultats rapportés sont reproduits séparément pour chaque backend. Cette dualité a un coût de maintenance. Elle signifie aussi qu'un déploiement existant basé sur le wrapper vLLM standard peut fonctionner sans adopter immédiatement le flux codec, ce qui laisse une porte de sortie si l'intégration pose problème. La documentation renvoie à la page vLLM dédiée au modèle llava_onevision2 pour l'exécution. Je n'ai pas exécuté cette intégration et je ne peux pas confirmer la version minimale de vLLM requise : le README ne la précise pas. C'est le premier élément à vérifier dans votre environnement avant de planifier quoi que ce soit.
Mise en route : ce que le dépôt documente réellement
La table des matières contient une section Quick Start (4B, single node). Le périmètre annoncé est donc un nœud unique pour la variante 4B, pas une recette multi-nœuds pour le 8B. Le README ne fournit pas, dans l'extrait disponible, les commandes exactes de lancement : ni ligne d'installation, ni clé de configuration, ni script d'entraînement cité textuellement. Il faut donc se référer au dépôt lui-même pour les commandes, et non à cette description. Ce que le matériel confirme, en revanche : les jeux de données sont hébergés sur Hugging Face sous mvp-lab/LLaVA-OneVision-2-Data, les modèles 2.0 sous lmms-lab-encoder/LLaVA-OneVision-2-8B-Instruct, et la reproduction des évaluations passe par la branche llava-onevision2 du dépôt lmms-eval, qui contient selon le README le wrapper de modèle, les configurations de tâches, un environnement Docker et des scripts de lancement. Si vous cherchez un guide d'installation pas à pas, c'est cette branche d'évaluation qu'il faut ouvrir en premier, pas la page d'accueil du projet.
Quatre jeux de données, dont deux hérités de la version 1.5
Le projet livre quatre corpus : LLaVA-OneVision-2-VideoCaption pour des légendes vidéo très denses, LLaVA-OneVision-2-Spatial pour le raisonnement spatial 3D, puis deux corpus repris de la branche 1.5, LLaVA-OneVision-1.5-Mid-Training-85M (85 millions d'échantillons équilibrés par concept) et LLaVA-OneVision-1.5-Instruct (le mélange complet d'instruction-tuning). Cette composition est instructive : la version 2.0 n'a pas reconstruit toute la chaîne de données, elle a ajouté deux corpus ciblés sur les capacités nouvelles et conservé le socle de 1.5. Cela réduit le coût de reproduction d'un entraînement complet, mais cela signifie aussi que les propriétés du socle hérité (équilibrage des concepts, filtrage) sont documentées dans le rapport technique de 1.5, arXiv 2509.23661, et non dans celui de 2.0. Pour auditer la composition réelle de vos données d'entraînement, il faut donc consulter deux documents, pas un.
La limite structurelle : un framework d'entraînement, pas un service
Le projet se présente comme un framework d'entraînement multimodal, et son appareil documentaire est cohérent avec cette ambition : journaux d'entraînement, configurations, poids d'encodeur. Le revers est net. Rien dans le matériel fourni ne décrit un serveur prêt à l'emploi, une API de service, une quantification, un format de déploiement léger ou une procédure de mise à jour incrémentale d'un modèle en production. Un modèle de 8B en résolution native avec un chemin vidéo longue est gourmand en mémoire, et le README ne donne aucune empreinte mémoire, aucun débit, aucun temps de latence. Si votre besoin est d'ajouter la compréhension d'images à une application existante, un modèle plus petit et déjà intégré à votre pile d'inférence sera moins coûteux à opérer. LLaVA-OneVision-2 devient le bon outil quand vous devez contrôler la recette d'entraînement, pas quand vous devez servir des requêtes.
Face à Qwen3-VL : reproduire une recette contre consommer un modèle
Le dépôt liste qwen3 parmi ses topics, ce qui rend la comparaison légitime. La différence n'est pas dans les scores, elle est dans ce qui est livré. Un modèle de la famille Qwen3-VL s'obtient comme un checkpoint documenté, avec des guides d'inférence et de quantification, et l'essentiel du travail d'adaptation se fait par affinage supervisé ou par invite. LLaVA-OneVision-2 livre en plus la chaîne amont : les encodeurs OneVision-Encoder, les corpus de mi-entraînement et d'instruction-tuning, les configurations et les journaux. Vous pouvez donc reprendre l'entraînement à une étape intermédiaire, remplacer un corpus, ou vérifier ce qui a produit une capacité donnée. En contrepartie, vous héritez d'une pile d'entraînement à maintenir et d'un chemin codec à intégrer. Le choix se résume à ceci : voulez-vous consommer un modèle ou reproduire une recette ?
Licence, maintenance et coût de mise à jour
Le dépôt est publié sous Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications. Cette licence couvre le code du dépôt. Elle ne dit rien, à elle seule, du régime des poids et des jeux de données hébergés séparément sur Hugging Face : ce sont des artefacts distincts, et leurs conditions doivent être vérifiées à la source. Je ne peux pas les confirmer à partir du matériel fourni. Sur la maintenance, le rythme observé est celui de publications majeures espacées : 1.5 en décembre 2025, 2.0 en août 2026, avec un dernier push en septembre 2026. Les recettes d'évaluation vivent dans une branche de lmms-eval, pas dans une version publiée, ce qui implique de suivre cette branche pour reproduire les chiffres. Une montée de version majeure peut donc toucher simultanément le code d'entraînement, les encodeurs et les données. Budgétez cette revalidation, pas seulement le calcul.
Conclusion éditoriale
LLaVA-OneVision-2 s'adresse aux équipes qui entraînent ou affinent des modèles vision-langage et veulent disposer des poids d'encodeur, des configurations et des journaux d'entraînement, pas seulement d'un checkpoint d'inférence. Il n'est pas indiqué si vous cherchez un modèle à brancher sur un pipeline existant en une après-midi : la documentation d'installation est centrée sur un nœud unique pour le 4B, et la reproduction des résultats passe par une branche dédiée de lmms-eval, pas par le dépôt principal. Avant d'engager des ressources, vérifiez trois choses concrètes : la présence effective des configurations d'entraînement dans le dépôt, la compatibilité du chemin codec avec votre version de vLLM, et le volume de tokens de la recette d'instruction-tuning par rapport à votre budget GPU.
Notes de la communauté