
Microsoft Mage-VL : Un modèle vidéo 4B natif au codec, livré sans annonce
- qwenNOUVEAUQwen: Qwen3.8 Max2026-08-03$2.00 / $6.00 par million de tokens · 56 tok/s
- deepseekNOUVEAUDeepSeek: DeepSeek V4 Flash 07312026-07-3150Intelligence69Code
- qwenNOUVEAUQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 par million de tokens · 201 tok/s
- orcaNOUVEAUOrcaDub: OrcaDub 1.02026-07-27orca/dub
- anthropicNOUVEAUAnthropic: Claude Opus 52026-07-2461Intelligence78Code
- googleGoogle: Gemini 3.6 Flash2026-07-2150Intelligence69Code
- googleGoogle: Gemini 3.5 Flash-Lite2026-07-2137Intelligence49Code
- metaMeta: Muse Spark 1.12026-07-1651Intelligence71Code
- kimiMoonshotAI: Kimi K32026-07-1557Intelligence76Code
- openaiOpenAI: GPT-5.6 Luna2026-07-0951Intelligence71Code
- openaiOpenAI: GPT-5.6 Terra2026-07-0955Intelligence77Code
- openaiOpenAI: GPT-5.6 Sol2026-07-0959Intelligence77Code
- grokxAI: Grok 4.52026-07-0854Intelligence72Code
- tencentTencent: Hy32026-07-0641Intelligence59Code
- obsidianQwen3.6 35B A3B Uncensored (Aggressive)2026-07-0232Intelligence42Code
- obsidianGemma4 26B A4B Uncensored (Balanced)2026-07-0226Intelligence39Code
- anthropicAnthropic: Claude Sonnet 52026-06-3053Intelligence72Code
- klingKling: Kling 3.0 Turbo2026-06-1757Intelligence52Code57Maths
- z-aiZ.ai: GLM 5.22026-06-1651Intelligence69Code60Maths
- kimiMoonshotAI: Kimi K2.7 Code2026-06-1242Intelligence61Code61Maths
Il n'y a aucun article de blog de Microsoft à propos de Mage-VL. Aucune entrée dans la salle de presse d'Azure, aucune fiche dans le catalogue Foundry, aucun fil de lancement, rien sur les canaux produits sur lesquels Microsoft présente normalement un modèle. Ce qui existe à la place, c'est un dépôt Hugging Face — microsoft/Mage-VL, six commits, 10,8 Go de poids, Apache-2.0 — un dossier GitHub de scripts d'inférence, une page de projet maintenue par une entité qui se fait appeler Microsoft Mage Team, et un rapport arXiv signé par 23 auteurs. Lus ensemble, ces artefacts décrivent un modèle vision-langage à l'échelle 4B dont l'idée centrale est vraiment inhabituelle : au lieu de décoder la vidéo en trames équidistantes et de faire passer une grille dense de patches à travers un encodeur pré-entraîné sur le web, Mage-VL lit lui-même le flux binaire compressé, en utilisant un encodeur créé de toutes pièces appelé Mage-ViT pour ne conserver que les patches sur lesquels le codec a dépensé des bits. Microsoft rapporte que cela réduit les tokens visuels de plus de 75 % et offre une accélération allant jusqu'à 3,5x en temps d'exécution, tout en égalant Qwen3-VL-4B sur les images statiques et en surpassant le propre modèle 15B de Microsoft, Phi-4-Reasoning-Vision, sur la vidéo.
Cette dernière phrase est à prendre avec des pincettes. Chaque chiffre de performance de cet article provient de la publication, de la fiche de modèle ou de la page de projet de Microsoft lui-même. Dix jours après la publication des poids, aucune entité indépendante n'a reproduit la moindre de ces performances, aucun classement tiers ne référence le modèle, et — comme le déclare clairement la page Hugging Face — il « n'est déployé par aucun fournisseur d'inférence », de sorte qu'il n'existe même pas de point de terminaison hébergé que l'on aurait pu évaluer à la légère. Ce qui suit distingue ce que le référentiel prouve de ce que Microsoft se contente d'affirmer, car lors d'une sortie sans annonce, ces deux catégories sont très différentes.
Ce qui existe réellement, au bout de dix jours.
La surface vérifiable de cette version est petite et mérite d'être énumérée précisément.
• Poids, datés du 26 juillet 2026.Deux fragments safetensors de 4,97 Go et 4,52 Go, plus un fichier séparé de 1,07 Go nommé streammind_gate.safetensors. Le lecteur de Hugging Face indique lui-même 5B paramètres en BF16 — 4B dans le décodeur de langage, le reste étant réparti entre l'encodeur visuel et cette porte.
• Un rapport technique, soumis le 27 juillet 2026 (arXiv 2607.24904), une version, 23 auteurs, intitulé "Mage-VL: An Efficient Codec-Native Streaming Multimodal Foundation Model."
• Du code exécutable, pas seulement des poids.Le dépôt fournit modeling_mage_vl.py, processing_mage_vl.py, deux processeurs vidéo, dont un dédié codec_video_processing_mage_vl.py, et streammind_gate.py — environ 175 Ko de Python personnalisé. Le champ auto_map dans config.json achemine six classes Transformers vers ces fichiers, ce qui explique pourquoi le dépôt porte la balise custom_code.
• Deux licences, pas une. Mage-VL est sous Apache-2.0 ; l'encodeur Mage-ViT autonome est publié séparément sous licence MIT.
• Une démo fonctionnelle que vous n'avez pas besoin d'installer. Microsoft exécute microsoft/mage-vl-demo comme un Space Hugging Face sur ZeroGPU, et deux Spaces communautaires utilisent déjà le modèle.
• Adoption communautaire précoce, qui se forme plus rapidement que les communications du fournisseur lui-même. 268 J'aime, 435 784 téléchargements enregistrés le mois dernier, neuf quantifications communautaires et deux affinages dans l'arborescence du modèle. Les compteurs de téléchargement incluent les téléchargements automatisés et ceux provenant de miroirs ; considérez donc ce nombre brut comme un signal d'attention plutôt que de déploiement.
• Un frère. Mage-Flow, un modèle de texte-à-image et d'édition d'instructions conçu avec le même budget fixe de 4B, est sorti quatre jours plus tôt, le 22 juillet. Le dépôt GitHub présente Mage comme « une famille de modèles multimodaux légers et adaptés à la recherche », ce qui s'approche le plus d'une déclaration de positionnement jamais publiée.
En regard de cela, la liste des choses qui n'existent pas est tout aussi instructive. Il n'y a ni article de blog Microsoft ni communiqué de presse. Il n'y a aucune référence dans Azure AI Foundry, ce qui signifie aucune voie de support entreprise, aucun SLA, aucun point de terminaison géré. Aucun fournisseur d'inférence ne le propose. Il n'existe aucun support vLLM ou SGLang : une demande de la communauté pour ajouter Mage-VL à SGLang a été déposée le 28 juillet en tant qu'issue #32646 et, à l'heure où ces lignes sont écrites, reste ouverte sans pull request liée ni réponse des mainteneurs. Et il n'existe aucune évaluation indépendante d'aucune sorte — le modèle est absent des classements neutres où une affirmation comme « bat un modèle de 15B en vidéo » serait normalement testée.

L'idée principale : lire le codec, pas les images.
Presque tous les VLM capables de traiter la vidéo en production font exactement la même chose. Ils décodent la vidéo en images RVB, les échantillonnent uniformément — une par seconde, ou 32 sur l’ensemble du clip, ou selon ce que le budget permet — et font passer chaque image échantillonnée dans un transformateur de vision sous forme de grille dense de patches. Chaque patch de chaque image échantillonnée devient des jetons. Un mur d’arrière-plan statique coûte exactement autant de jetons que la personne qui marche devant, et ce coût se répète dans l’image suivante, puis encore dans la suivante.
C'est une énorme quantité de calcul redondant, et les codecs vidéo modernes ont déjà résolu le problème sous-jacent il y a des décennies. H.264 et HEVC ne stockent pas chaque image ; ils stockent des images d'ancrage (I) occasionnelles en entier, puis décrivent les images intermédiaires comme des vecteurs de mouvement plus des résidus — « ce bloc a bougé ici, et voici ce qui a changé ». Les parties intéressantes d'une vidéo sont, presque par construction, les parties sur lesquelles l'encodeur a dépensé des bits.
Mage-ViT exploite cela directement. Fonctionnant à une granularité de patchs de 16x16, il conserve chaque patch des trames d'ancrage et, pour les trames prédites, ne retient que les patchs signalés comme saillants par les vecteurs de mouvement et l'énergie résiduelle du codec lui-même — les régions qui portent des informations réelles, un mouvement ou un changement de scène — tout en écartant les patchs à faible redondance et ceux entièrement redondants. Microsoft estime la réduction obtenue à plus de 75 % des jetons visuels, le contexte spatio-temporel étant préservé car les trames d'ancrage portent toujours la scène complète. La conception est indépendante du codec : le chemin traditionnel accepte H.264 ou HEVC, et un chemin neuronal accepte DCVC-RT.
L'élégance réside dans le fait que l'estimation de mouvement a déjà été effectuée. Chaque vidéo compressée sur Internet arrive avec une carte indiquant où se trouve l'action, calculée par l'encodeur et payée par celui qui l'a téléversée. Un pipeline conventionnel jette cette carte dès qu'il décode en RVB, puis dépense du temps GPU à redécouvrir la même information. Mage-VL refuse simplement de la jeter. Que les chiffres du benchmark se confirment ou non, cette observation est la contribution durable ici — et c'est la raison pour laquelle cette version mérite d'être lue même si vous ne téléchargez jamais les poids.

La chose la plus propre à propos de cette expérience
Dans la configuration se cache une décision de conception qui rend les résultats bien plus interprétables qu'un lancement de modèle typique, et presque personne parmi ceux qui couvrent cette sortie ne l'a soulignée : le modèle de langage est maintenu fixe.
Le décodeur de Mage-VL est Qwen3-4B-Instruct-2507, non modifié. La baseline de comparaison, Qwen3-VL-4B, utilise le même backbone Qwen3 4B avec un encodeur visuel conventionnel pré-entraîné sur le web. Ainsi, lorsque Mage-VL améliore Qwen3-VL-4B, la différence est attribuable à l'encodeur et à la tokenisation native au codec, et non à un modèle de langage plus gros ou mieux entraîné. Il s'agit d'une ablation contrôlée déguisée en comparaison de produits, et c'est la caractéristique méthodologique la plus solide de la version.
Cela joue aussi dans l'autre sens, et l'honnêteté exige de le dire. Une comparaison sur la même base est le test le plus équitable de l'idée d'encodeur et, simultanément, le cadrage le plus susceptible de la flatter — Microsoft a choisi la référence qui isole sa propre contribution. Les comparaisons Phi-4 n'ont pas cette propriété : Phi-4-Reasoning-Vision-15B et Phi-4-MM-5.6B sont des bases différentes, des recettes d'entraînement différentes, des post-entraînements différents. « Bat notre modèle 15B sur la vidéo » est un résultat réel, mais beaucoup moins rigoureux, et c'est aussi une comparaison avec les propres travaux antérieurs de Microsoft, le type le plus facile à remporter.
L'échelle d'entraînement est l'autre endroit où l'article avance une affirmation vraiment surprenante. Mage-ViT a été pré-entraîné de zéro sur environ 560 millions d'images non étiquetées et 100 millions de trames vidéo non étiquetées — un corpus important en termes absolus, mais bien en deçà des milliards de paires image-texte organisées qui se trouvent derrière les encodeurs auxquels il se mesure. La première conclusion énoncée par l'article est qu'un encodeur VLM performant n'exige pas de données supervisées à l'échelle du web. Si cela résiste à un examen indépendant, cela compte beaucoup plus que n'importe quelle ligne de référence sur un tableau.
Les nombres, et à qui ils appartiennent.
Ce qui suit est rapporté par Microsoft de bout en bout, sur le propre dispositif d'évaluation de Microsoft, face à des références choisies par Microsoft. Rien de tout cela n'a été reproduit par un tiers. À lire comme une hypothèse avec des barres d'erreur inhabituellement précises, pas comme un tableau des scores.
• Video-MME — Mage-VL-4B 64,0 vs Qwen3-VL-4B 59,7 vs Phi-4-Reasoning-Vision-15B 55,3
• NExT-QA — 83,1 vs 79,8 vs 69,0
• LongVideoBench — 61.3 vs 57.7 vs 51.2
• VideoEval-Pro — 45.2 contre 20.7 pour Phi-4
• Timelens-QVHighlight (ancrage temporel) — 57.4 vs 34.9 vs 11.6
• Ref-DAVIS17 (suivi des références) — 25.83 vs 7.48 vs 2.15
• DocVQA-val — 95.14 vs 94.69 vs 92.79 (Phi-4-MM-5.6B)
• OCRBench — 81.80 contre 81.60 contre 81.70
• ChartQA — 84.88 vs 83.96 vs 83.40
• MMStar — 67.32 contre 62.04 contre 59.63
• RealWorldQA — 70.46 contre 70.85 contre 70.72, l'une des lignes où Mage-VL perd
• MMBench-EN-dev — 84.02 contre 83.25, avec Phi-4-Reasoning-Vision-15B devant les deux à 84.19
• CV-Bench-3D / CV-Bench-2D — 94.75 vs 92.30, et 82.13 vs 81.00
• EmbSpatial — 82,67 contre 77,50
• OVO-Bench (streaming) — 64,00 au total, décrit comme l'état de l’art parmi les architectures de streaming ; le sous-ensemble de perception visuelle en temps réel atteint en moyenne 79,84 % contre 72,8 % pour Qwen3-VL-4B, à 1 fps
• Mage-ViT en tant qu'encodeur autonome — plus de 86,3 % sur ImageNet avec un budget de 676 jetons, plus de 96,1 % sur Food-101

Trois lectures de ce tableau valent plus que le tableau lui-même.
Sur les images, « parité » est le terme honnête. DocVQA de 0,45, OCRBench de 0,20, ChartQA de 0,92, MMBench de 0,77 — ces valeurs se situent dans une fourchette où un autre template de prompt ou un autre seed de décodage pourrait inverser le classement, et RealWorldQA revient en fait à Qwen3-VL-4B. Microsoft le dit lui-même, qualifiant les performances sur les images de parité plutôt que de victoire, et ce cadrage est correct. Si votre charge de travail consiste à répondre à des questions sur des documents et des images, cette version ne vous donne aucune raison de migrer.
En matière d'ancrage vidéo et temporel, les écarts sont importants et systématiques. Timelens-QVHighlight double presque la baseline ; Video-MME, NExT-QA et LongVideoBench progressent tous de 3,6 à 4,3 points dans la même direction, à backbone fixe. La cohérence entre des benchmarks qui testent des aspects différents est le schéma auquel on s'attend si le changement d'encodeur est réel plutôt qu'un artefact de réglage.
Deux lignes ne doivent pas être citées sans contexte. Ref-DAVIS17 à 25,83 contre 7,48 ressemble à une démolition 3,5x, et les principaux écarts spatiaux de l'article incluent +11,0 sur VSI-Bench et +53,1 sur CrossPoint. Lorsqu'une baseline obtient un score proche du plancher sur une tâche, l'écart mesure surtout quel modèle a été entraîné à comprendre le format de la tâche — pas quel modèle est le plus capable. La même prudence s'applique aux résultats de streaming en termes absolus : sur SoccerNet, les chiffres rapportés par Mage-VL sont 55,54 TimVal, 83,14 ROC-AUC et un F1 de 16,35. Un F1 de 16,35 est un chiffre de pointe dans une évaluation récente, pas un problème résolu. La perception proactive en streaming en est à ses débuts, et le score absolu du leader le confirme.
La porte : un modèle qui décide quand parler
La deuxième idée architecturale est celle qui a les implications produit les plus claires, et elle explique ce mystérieux fichier de 1,07 Go.
Mage-VL divise le streaming en deux processus, présentés dans l'article comme Système 1 et Système 2. Le Système 1 est une « porte cognitive » légère qui surveille chaque fenêtre glissante des caractéristiques du codec et estime la probabilité que quelque chose méritant d'être mentionné vient de se terminer. En dessous d'un seuil, il reste silencieux et la partie coûteuse du modèle ne s'exécute jamais. Au-dessus de ce seuil, le décodeur complet est invoqué pour produire une réponse. La configuration de démonstration utilise des fenêtres causales de 30 secondes à 1 fps, la CLI expose le seuil directement via --gate_threshold, et le point d'entrée du streaming traite la vidéo segment par segment (inference_streaming.py --video_backend codec --segment_sec 8). Seule la porte est entraînée lors de la dernière étape, sur 3,35 millions d'échantillons de streaming.
Deux choses méritent d'être notées à ce sujet. Premièrement, le gate n'est pas une petite tête de classification ajoutée par-dessus : 1,07 Go de poids BF16 représentent environ un demi-milliard de paramètres, un véritable modèle à part entière, fourni sous forme de checkpoint séparé. Deuxièmement, le nom du fichier est streammind_gate.safetensors — cette dénomination suggère que ce composant descend de travaux antérieurs sur la perception en streaming plutôt que d'avoir été inventé pour cet article, bien que le dépôt lui-même ne précise pas cette lignée.
Pourquoi c'est important commercialement : pour la vidéo en continu, le coût dominant n'est pas la latence par appel, c'est la fréquence des appels. Un flux de caméra fonctionnant 24h/24 et 7j/7 via un VLM classique à 1 fps implique 86 400 passages forward par jour, qu'il se soit passé quelque chose ou non. Une porte qui reste silencieuse pendant les 99 % de séquences où rien ne se passe change la forme de cette facture, pas seulement son montant. La question de savoir si la porte de Microsoft est assez précise pour qu'on lui confie cette décision est précisément ce que personne en dehors du laboratoire n'a testé.
Peux-tu vraiment le lancer aujourd'hui ?
Oui, si vous avez un GPU et de la patience. La friction est réelle et se situe surtout dans le pipeline vidéo plutôt que dans le modèle.
Mémoire. Microsoft ne publie pas d'exigence de VRAM. Selon l'index des poids : 9,49 Go de shards plus la porte de 1,07 Go représentent environ 10,6 Go de paramètres BF16. Une carte de 16 Go est donc un minimum réaliste pour le travail sur image, et 24 Go ou plus est la cible raisonnable une fois que vous ajoutez le cache KV pour une longue vidéo ou une fenêtre de streaming. Ce calcul provient des tailles de fichiers, pas d'une spécification du fournisseur — mesurez avant de provisionner.
Le code personnalisé est obligatoire. L'auto_map fait pointer chaque point d'entrée de Transformers vers les modules du dépôt, donc trust_remote_code est requis. Vous exécutez le Python de Microsoft, pas simplement un chargement de tenseurs. Il n'existe pas encore de chemin vLLM ou SGLang, ce qui signifie pas d'attention paginée, pas de batching continu, pas de pile de service en production — une lacune importante si vous espériez mettre cela derrière un endpoint.
Le chemin de codec nécessite des outils système. FFmpeg et ffprobe doivent être dans votre PATH. Le backend de codec traditionnel dépend d'un paquet codec-video-prep qui fournit une étape cv-preinfer ; le chemin neuronal nécessite DCVC-RT ; le backend d'images brutes nécessite Decord. Les dépendances incluent également flash-attn et mamba-ssm, qui compilent des extensions CUDA — installez d'abord une version de PyTorch correspondant à votre toolkit ou prévoyez un après-midi pour la compilation.
Ce que la config vous dit que la carte ne fait pas.Les embeddings de position maximum sont de 262 144, donc le décodeur hérite du long contexte de Qwen3-4B. Le côté vision fonctionne avec une entrée de 448 pixels et des patchs de 16x16, un encodeur de 24 couches avec une taille cachée de 1024, une fusion spatiale 2x2, un token par seconde de vidéo et une fenêtre de quatre images. L'entraînement a atteint 384 images de longueur temporelle à l'étape trois. Un plafond de 262K n'est pas la même chose que 262K de comportement validé, et 384 images est la longueur que le modèle a réellement appris à gérer.
Limites connues. Une discussion ouverte sur le dépôt, déposée le 4 août et toujours sans réponse, signale un désalignement des jetons lorsque des images et des vidéos sont passées dans la même requête. Un logiciel vieux de dix jours se comporte comme un logiciel vieux de dix jours. Si vous voulez un aperçu sans tout cela, le Space géré par Microsoft sur ZeroGPU est l'option sans installation.
La ligne de licence est moins simple que « Apache-2.0 ».
La fiche modèle indique Apache-2.0. L'encodeur Mage-ViT indique MIT. Les deux sont à peu près aussi permissifs que possible pour des poids ouverts. Mais le dépôt de la famille déclare que « ces modèles sont publiés à des fins de recherche uniquement », avec un accent sur l'examen de l'IA responsable et la supervision humaine — et cette phrase s'accorde mal avec une licence Apache-2.0, qui ne restreint pas l'usage commercial. Ajoutez les dépendances : DCVC-RT et les outils de préparation du codec portent leurs propres conditions, indépendantes de celles du modèle.
Pour un projet amateur, c'est du bruit. Pour tout ce qui est livré à des clients, c'est le genre d'ambiguïté qui devrait passer par le service juridique avant d'être mis en production, et le genre de question qu'il vaut la peine de poser sur le dépôt lui-même — où, de manière notable, aucun représentant Microsoft ne répond actuellement.
Devriez-vous construire là-dessus ?
La décision se scinde nettement selon une ligne : votre problème est-il un flux ou une requête ?
{{1}}Si vous faites de la perception en continu — un flux de caméra, une diffusion en direct, le champ de vision d'un robot, une réunion qui dure une heure — Mage-VL s'adresse exactement à vous, et l'économie de l'auto-hébergement joue en votre faveur.{{/1}} {{2}}La tarification API par token évolue en fonction des images, ce qui est un modèle impitoyable pour la vidéo continue ; un modèle 4B sur votre propre matériel, avec une passerelle qui reste silencieuse pendant les séquences sans intérêt, représente une courbe de coûts fondamentalement différente.{{/2}} {{3}}Le revers de la médaille, c'est que vous devenez aussi la première personne en dehors de Microsoft à découvrir si le jugement de la passerelle est vraiment bon.{{/3}}
Si votre problème a la forme d'une requête — un utilisateur téléverse un document, un PDF, une capture d'écran, un court clip et attend une réponse — le cas est bien plus faible. Sur exactement ces tâches, Mage-VL est au niveau d'un modèle que vous devriez de toute façon héberger vous-même, et les endpoints multimodaux hébergés sont à un appel d'API près, sans GPU, sans compilation ffmpeg, et sans trust_remote_code. Sur OrcaRouter, Gemini 3.6 Flash coûte 1,50 $ par million de jetons en entrée et 7,50 $ par million en sortie, ce qui correspond au prix catalogue du fournisseur transmis tel quel — nous prenons 0 % de marge, donc quand un vendeur baisse ses prix, la baisse est effective chez nous le jour même plutôt qu'après une révision des prix. Une seule clé donne accès à plus de 200 modèles avec bascule automatique en cas de dégradation d'un fournisseur, ce qui est la raison pratique de garder un endpoint hébergé comme option par défaut et de réserver l'auto-hébergement aux charges de travail qui en ont réellement besoin.
Pour être explicite, car la distinction est importante : nous n'hébergeons pas Mage-VL, et personne d'autre non plus. La propre page du modèle de Hugging Face indique qu'aucun fournisseur d'inférence ne l'a déployé. Aujourd'hui, l'exécuter signifie l'exécuter soi-même.
Qu'est-ce qui changerait cette lecture ?
Quatre choses, à peu près par ordre d'importance.
Une évaluation indépendante est l'élément clé. Chaque chiffre ci-dessus est une affirmation, et celle qui mérite le plus d'être testée n'est pas un score de référence, mais l'accélération de 3.5x, qui a été mesurée par rapport à un échantillonnage uniforme des frames sur NExT-QA sans détails publiés sur le matériel, la résolution ou le nombre de frames. Le prétraitement du codec déplace le travail réel vers le CPU et vers ffmpeg ; une victoire en temps réel mesurée de bout en bout sur la machine de quelqu'un d'autre est la seule version de ce chiffre qui vaille la peine d'être utilisée pour planifier.
Deuxièmement, le support du serving. Une implémentation fusionnée dans vLLM ou SGLang transformerait ceci d'un checkpoint de recherche en quelque chose que l'on peut placer derrière un équilibreur de charge. Le ticket SGLang est ouvert et sans preneur ; c'est le fil à suivre.
Troisièmement, une inscription dans Azure AI Foundry, ce qui signalerait que Microsoft considère cela comme un produit plutôt qu'un article. Rien dans la version actuelle ne suggère que cela soit imminent.
Quatrièmement, et le plus étrange : la question de savoir si Microsoft dit jamais quoi que ce soit. Un rapport technique cosigné par 23 auteurs, une page de projet tenue à jour, un Space de démonstration hébergé et un modèle génératif frère publié quatre jours plus tôt ne décrivent ni une fuite ni un accident — ils décrivent une publication de recherche délibérée qui a complètement ignoré le mégaphone produit. La communauté a comblé le silence malgré tout, avec neuf quantifications et deux finetunes en dix jours.
Pour la plupart des équipes, la bonne décision est de lire l'article, pas de télécharger les poids. L'idée native au codec est ce qu'il faut retenir, et elle est portable : si la réutilisation des vecteurs de mouvement déjà calculés par l'encodeur permet vraiment une réduction de 75 % des jetons à précision égale, cette technique apparaîtra dans des modèles avec des annonces de lancement, le support des fournisseurs et des benchmarks reproduits. Si vous faites de la vidéo en continu aujourd'hui, le calcul est différent — clonez le dépôt, faites passer vos propres clips dans les deux backends et mesurez vous-même l'accélération, car pour l'instant vous seriez le premier.
Des questions qui méritent vraiment d'être posées
Est-ce que Mage-VL n'est qu'un Qwen3-VL avec une étiquette Microsoft ?
Non, même si la confusion est compréhensible. Le décodeur de langage est Qwen3-4B-Instruct-2507, utilisé tel quel — Microsoft n'a pas entraîné un nouveau LLM. Tout le reste est nouveau : Mage-ViT a été pré-entraîné à partir de zéro, la tokenisation native au codec n'a pas d'équivalent dans Qwen3-VL, et la passerelle de streaming est un modèle supplémentaire d'un demi-milliard de paramètres. Réutiliser un backbone ouvert et remplacer le front-end visuel est une stratégie de recherche légitime et de plus en plus courante, et c'est aussi ce qui rend la comparaison directe interprétable. Si vous avez des exigences de conformité concernant la provenance du modèle, notez que la lignée passe par les poids Qwen3 d'Alibaba et vérifiez les deux licences.
Est-ce que « 3.5x plus rapide » signifie 3.5x moins cher à servir ?
Pas de manière fiable. Le chiffre est une accélération en temps horloge sur NExT-QA par rapport à un échantillonnage uniforme des frames, et Microsoft le présente comme « jusqu'à ». Deux choses le diluent en pratique. L'inférence native au codec nécessite une passe de préparation — ffmpeg, ffprobe, et l'étape cv-preinfer, ou un ré-encodage DCVC-RT pour le chemin neuronal — qui consomme du temps CPU qu'un pipeline de frames naïf n'utilise pas, et qui n'apparaît pas dans une mesure côté GPU. Et le gain provient de la réduction de tokens, donc il évolue avec la redondance de vos séquences : une caméra de sécurité quasi statique devrait faire mieux que le chiffre cité, tandis qu'une vidéo montée avec des coupes rapides où presque chaque patch change devrait faire pire. Mesurez-le sur vos propres clips.
Ai-je besoin de fichiers vidéo spéciaux pour utiliser le chemin du codec ?
En grande partie non, et c’est la bonne surprise. Les fichiers MP4 ordinaires sont déjà en H.264 ou en HEVC, ce qui est exactement ce que consomme le backend de codec traditionnel — les vecteurs de mouvement dont il a besoin se trouvent dans le fichier que vous possédez déjà. Ce qu’il faut ajouter, ce sont les outils : FFmpeg et ffprobe dans votre PATH, ainsi que le package de préparation du codec. Le backend neuronal est l’exception ; DCVC-RT attend une vidéo encodée avec ce codec, vous devriez donc ré-encoder. Et le backend de trames brutes reste disponible comme solution de repli qui se comporte comme n’importe quel autre VLM, ce qui est aussi la façon honnête de tester vous-même l’affirmation sur le codec.
Puis-je l'utiliser à des fins commerciales ?
La licence indique Apache-2.0, ce qui autorise l'utilisation commerciale, la modification et la redistribution. Le dépôt indique également que les modèles sont « publiés à des fins de recherche uniquement ». Ces deux déclarations vont dans des directions différentes, et cet écart n'a été clarifié par personne chez Microsoft — ce qui, pour une publication sans annonce, sans fiche produit et sans présence du fournisseur dans les discussions du dépôt, n'a rien de surprenant. Si des enjeux financiers dépendent de la réponse, faites lire les deux documents et les licences des dépendances par un avocat plutôt que de vous fier au seul badge de licence.
