VideoJev : un modèle vidéo qui répond par un nombre au lieu d'une phrase

VideoJev est une famille de modèles de compréhension vidéo qui ne rédige jamais de réponse. Demandez-lui l’horodatage d’un événement et il renvoie un intervalle assemblé à partir de créneaux candidats notés ; posez-lui une question à choix multiples sur une vidéo et il renvoie l’option ayant le score le plus élevé. Il existe deux checkpoints publiés — VideoJev-4B sur Qwen3.5-4B et VideoJev-35B-A3B sur Qwen3.6-35B-A3B — et ils n’ont pas été lancés. Personne n’a publié de communiqué de presse. Un article est apparu sur arXiv le 13 octobre 2026, les poids ont été mis en ligne sur Hugging Face le 10 octobre 2026, et le dépôt était encore en cours de rangement quatre jours plus tard : au 14 octobre, il recevait des commits comme « Restaurer la vidéo README intégrée avec une pièce jointe publique » et « Ajouter le lien de l’article arXiv et la citation BibTeX officielle. » Voilà à quoi ressemble un lancement discret — les artefacts sont réels et inspectables, et aucune annonce ne vous dit ce que les auteurs jugent important.

Tout ce qui suit provient de l’un de trois endroits : la prépublication arXiv (2610.18615, cs.CV, soumise le 13 octobre 2026), les fiches de modèle et le code publiés par les auteurs, et les notes de bas de page de l’article lui-même sur la manière dont les chiffres ont été mesurés. J’ai essayé de garder ces trois sources clairement séparées, car ce qui est intéressant dans cette publication, ce n’est pas le chiffre phare — c’est la fragilité du terrain sur lequel il repose.

Ce que l'article affirme réellement

VideoJev prend un LLM multimodal pré-entraîné, supprime le MLP final et la tête de sortie du modèle de langage, et met à leur place un évaluateur de candidats. Deux nouveaux tokens, <|option_end|> et <|decide|>, produisent des lectures. L'état de décision et chaque état candidat sont projetés en 512 dimensions, normalisés, puis combinés par produit scalaire ; les intervalles temporels sont évalués avec une sigmoïde et assemblés en un span, les options de réponse sont évaluées et normalisées avec un softmax. Les deux tâches passent par la même tête. Rien n'est décodé de manière autorégressive, car il n'y a rien à décoder.

Les trois chiffres phares de l'article, tous déclarés par les fournisseurs et tous issus du propre banc d'évaluation des auteurs :

• Qualité de l’ancrage — VideoJev-4B atteint 65,3 de mIoU moyen sur trois benchmarks d’ancrage temporel, soit 6,7 points de plus que son backbone Qwen3.5-4B. VideoJev-35B-A3B atteint 67,7, soit 10,8 points de plus que Qwen3.6-35B-A3B.

• Parité de QA sans raisonnement — sur quatre benchmarks de QA vidéo, les deux modèles affichent des moyennes de 74,3 et 79,5, soit respectivement 0,6 point en dessous et 0,7 point au-dessus de leurs backbones en mode Thinking.

• Latence — 2,8–3,1× plus rapide que ces backbones sur le grounding, et plus de 100× sur le QA. Le chiffre mesuré pour le QA est de 129× à 4B et de 100× à 35B-A3B.

La présentation honnête de l’affirmation sur la vitesse est qu’il s’agit d’une comparaison avec un modèle de raisonnement qui fait quelque chose de bien plus difficile que ne l’exige la tâche. Qwen3.5-4B en mode Thinking consomme 144,9 secondes par question sur LVBench pour obtenir 74,9 ; VideoJev-4B passe 1,123 seconde pour obtenir 74,3. Le 129× est un calcul réel à partir du propre tableau de latence de l’article, et c’est aussi le calcul que l’on obtiendrait avec n’importe quel modèle qui refuse de penser. La question intéressante n’est pas de savoir si l’accélération est réelle — mais si l’on peut construire un système où cet arbitrage est correct.

L’argument qui sous-tend cela : des décisions, pas des générations

Là où cela devient plus intéressant qu'un tableau de benchmark, c'est au niveau de l'affirmation architecturale. Les auteurs ont affiné un Qwen3.5-4B autorégressif ordinaire sur exactement les mêmes données de post-entraînement, dans la même étape unique, avec les mêmes réglages, et l'ont amené à générer des intervalles ou à répondre par des lettres. Le tableau 3 de l'article indique que VideoJev-4B dépasse ce témoin de 1,3 point de mIoU de grounding moyen et de 1,9 point de score QA moyen. Les deux modèles ont reçu une supervision identique ; seule la forme de la lecture différait.

Si cela se vérifie, le gain ne réside ni dans les données ni dans l’échelle — il réside dans le fait que demander à un modèle d’émettre une distribution de probabilité sur des candidats structurés convient mieux à une décision structurée que de lui demander de produire une chaîne, puis de réanalyser cette chaîne pour en extraire une décision. C’est le même pari que TypeSafe a fait avec Jev 1.13 et sa famille System One, généralisée des états textuels à la vidéo. L’article précise explicitement qu’il s’appuie sur cette ligne de travaux plutôt que d’inventer la catégorie.

Deux détails d'implémentation valent plus que les chiffres phares, car ce sont eux qui le rendent utilisable et pas seulement rapide. L'inférence avec cacheencode et préremplit la vidéo une seule fois, puis laisse les requêtes qui arrivent se ramifier à partir de ce préfixe mis en cache — une seule passe avant par requête. L'inférence conjointeplace plusieurs requêtes derrière un seul préfixe vidéo et extrait un <|decide|> distinct pour chacune, de sorte qu'un groupe de questions coûte une seule passe avant au total. Sur dix requêtes de grounding portant sur une même vidéo, l'article mesure 0,39 s pour VideoJev contre 5,98 s pour une baseline Instruct ; côté QA, dix requêtes s'établissent à 1,67 s. L'article vérifie également le mode de défaillance évident de l'inférence conjointe — à savoir qu'une question antérieure laisse fuiter sa réponse dans une question ultérieure — et indique avoir vérifié qu'aucune réponse de référence ou prédite n'est insérée dans le préfixe partagé. Il convient de noter qu'il s'agit de la vérification des auteurs eux-mêmes, et que l'inférence conjointe fait mieuxque le mode isolé avec cache (65,3 vs 64,5 mIoU à 4B), ce qu'ils attribuent à un entraînement sur la même disposition conjointe.

Ce que la carte ne vous dit pas

Quatre choses sont manifestement absentes, et elles comptent plus que tout ce qui précède si vous cherchez à déterminer si c’est prêt pour la production.

• Les données d'entraînement ne sont pas divulguées. Le dépôt documente le format et fournit les outils nécessaires pour créer votre propre JSONL, mais le corpus, sa taille et sa provenance ne sont pas précisés. Vous ne pouvez pas évaluer la contamination par rapport aux sept benchmarks sur lesquels il publie des résultats.

• Les poids du 35B démarrent en FP32. La page du projet indique FP32 pour l'inférence « Cached » et BF16 pour « Joint » — la configuration phare du plus grand modèle est donc celle dont l'empreinte mémoire est la plus lourde, et la page ne donne aucune valeur de VRAM pour l'une comme pour l'autre.

• La confiance est trop confiante. L'article rapporte une erreur de calibration moyenne de 8,65 points pour 4B et de 8,13 pour 35B-A3B. Le score est un signal de classement exploitable, pas une probabilité sur laquelle vous devriez vous brancher sans un seuil que vous avez ajusté vous-même.

• Personne n'a vérifié les chiffres de manière indépendante. Tous les chiffres ici proviennent du groupe qui a entraîné les modèles. À l'heure où nous écrivons, il n'existe aucune réplication par un tiers, aucune entrée dans un classement et aucune prise en charge par un framework n'a encore été intégrée — le chemin d'inférence repose sur trust_remote_code=True face à une architecture personnalisée, nécessitant au minimum PyTorch 2.8/CUDA 12.8 et FlashAttention 2.

Ce dernier point vaut aussi pour le plus petit modèle, et il va à l'encontre de l'hypothèse évidente. VideoJev-4B est celui qu'on s'attendrait à voir tourner sur du matériel modeste, et le guide de démarrage rapide de la fiche modèle suppose lui-même un H200 à 2 fps avec jusqu'à 2 048 images. Il existe une démo moins coûteuse — un clip de dix secondes, dix intervalles candidats, des probabilités imprimées —, mais les résultats sur vidéos longues de l'article utilisent un contexte fixe de 262 144 tokens, avec des images plafonnées à 640×640. Le 4B est petit en nombre de paramètres, pas nécessairement en coût de service.

L'essayer sans parier dessus

Parce que ce sont les checkpoints qui existent réellement, la façon de commencer à faible risque consiste à exécuter VideoJev en local sur vos propres séquences avant de construire quoi que ce soit dessus — le parcours de démonstration se résume à un téléchargement et à une douzaine de lignes, et les cas d’échec que l’article documente lui-même (le comptage de petits objets sur Video-MME, où les deux tailles ratent une réponse de quatre livres) sont exactement ceux que vous voulez rencontrer sur vos données plutôt que sur Charades. VideoJev-4B et VideoJev-35B-A3B sont sous Apache-2.0, donc rien ne vous arrête.

Là où OrcaRouter intervient, c'est l'autre moitié du workflow. Une interface de décision vidéo est rare en soi ; ce qui est courant, c'est un pipeline qui a aussi besoin d'un modèle génératif pour rédiger le résumé, d'un classifieur bon marché pour filtrer l'appel coûteux, et de quelque chose pour router entre eux. OrcaRouter place plus de 200 modèles derrière une seule API avec 0 % de marge — le prix catalogue du fournisseur répercuté tel quel, de sorte qu'une baisse de prix d'un fournisseur est effective ici le jour même — avec un basculement automatique entre fournisseurs, un DSL de routage pour composer plusieurs modèles en un seul appel, et la fusion de modèles pour les panels. Aucun des checkpoints VideoJev n'est hébergé ici, et cet article ne va pas prétendre le contraire ; les deux endroits où il gagne sa place sont comme second segment d'un pipeline dont le premier segment est un modèle local, et comme la raison pour laquelle un modèle de recherche comme celui-ci peut être essayé sans un second contrat fournisseur pour tout ce qui l'entoure.

Qu’est-ce qui en ferait une histoire plus importante ?

La validation en amont de ce texte est inhabituellement limpide, cela vaut donc la peine de le dire clairement : VideoJev est une publication de recherche, pas un lancement de produit. Il n’y a pas de journal des modifications, pas de page tarifaire, pas de point de terminaison hébergé, pas de liste d’attente et pas d’article de blog du fournisseur. Ce qui existe, c’est une prépublication soumise le 13 octobre 2026, deux checkpoints Apache-2.0 mis en ligne le 10 octobre, et un dépôt qui était encore en cours de modification le 14 octobre — la veille de cet article. L’absence d’annonce ne prouve pas qu’il y a un problème, mais elle signifie que le cadrage doit être « ce que disent les artefacts », et non « ce que le fournisseur affirme ».

Trois développements changeraient la donne. Une évaluation par un tiers reproduisant les gains de +6,7 et +10,8 mIoU sur les mêmes backbones selon le même protocole. Une implémentation vLLM ou SGLang, qui la ferait passer d’une curiosité trust_remote_code à quelque chose que l’on peut servir à haut débit. Ou un endpoint hébergé proposé par quelqu’un, qui ferait de l’affirmation du 100× un nombre que vous pouvez mesurer sur votre propre vidéo plutôt qu’un nombre que vous reprenez d’un tableau en page six. Tant que l’un de ces éléments ne se concrétise pas, la position utile est celle que prend l’article lui-même : l’interface de scoring direct est une façon véritablement différente de construire un agent vidéo, et les preuves à son appui ne reposent actuellement que sur la prépublication de neuf pages d’un seul groupe.

Gardez le notebook de démo ouvert, exécutez-le sur les séquences les moins flatteuses que vous avez, et traitez les scores de confiance comme un classement jusqu'à ce que vous les ayez vous-même calibrés.

Une sortie est aussi le moment de vérifier ce qui a mal tourné auparavant : les incidents d'IA documentés et les défaillances d'agents autour des modèles de cette classe sont rassemblés dans the OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, sa gravité, sa note de confiance et un indicateur de contestation.