Microsoft Mage-VL: een codec-native 4B-videomodel, uitgebracht zonder aankondiging

Er is geen Microsoft-blogpost over Mage-VL. Geen Azure-nieuwsbericht, geen Foundry-catalogusvermelding, geen lanceringsthread, niets op de productkanalen waar Microsoft normaal gesproken een model introduceert. Wat er in plaats daarvan bestaat, is een Hugging Face-repository — microsoft/Mage-VL, zes commits, 10,8 GB aan gewichten, Apache-2.0 — een GitHub-map met inferencescripts, een projectpagina die wordt onderhouden door iets dat zichzelf het Microsoft Mage Team noemt, en een arXiv-rapport met 23 auteurs. Samen gelezen beschrijven deze artefacten een vision-taalmodel op 4B-schaal waarvan het centrale idee werkelijk ongebruikelijk is: in plaats van video te decoderen naar gelijkmatig verdeelde frames en een dicht raster van patches door een web-voorgetrainde encoder te halen, leest Mage-VL de gecomprimeerde bitstream zelf, met behulp van een vanaf nul getrainde encoder genaamd Mage-ViT die alleen de patches behoudt waaraan de codec bits heeft besteed. Microsoft meldt dat dit het aantal visuele tokens met meer dan 75% vermindert en tot een 3,5x versnelling in wandkloktijd oplevert, terwijl het Qwen3-VL-4B evenaart op statische afbeeldingen en Microsofts eigen 15B Phi-4-Reasoning-Vision verslaat op video.

Die laatste zin is het deel dat je op afstand moet houden. Elk prestatiecijfer in dit artikel is terug te voeren op Microsofts eigen paper, modelkaart of projectpagina. Tien dagen nadat de weights verschenen, heeft geen enkele onafhankelijke partij ook maar iets ervan gereproduceerd, geen enkele externe leaderboard vermeldt het model, en — zoals de Hugging Face-pagina ronduit stelt — is het "niet geïmplementeerd door een Inference Provider," dus er is niet eens een gehost endpoint dat iemand terloops had kunnen benchmarken. Wat volgt, scheidt wat de repository bewijst van wat Microsoft slechts beweert, want bij een release zonder aankondiging zijn dat twee zeer verschillende categorieën.

Wat er daadwerkelijk bestaat, tien dagen later.

Het verifieerbare oppervlak van deze release is klein en het loont de moeite om dit precies op te sommen.

• Gewichten, gedateerd 26 juli 2026. Twee safetensors-shards van 4,97 GB en 4,52 GB, plus een apart bestand van 1,07 GB met de naam streammind_gate.safetensors. De eigen reader van Hugging Face rapporteert 5B parameters bij BF16 — 4B in de taaldecoder, de rest verdeeld tussen de visuele encoder en die gate.

• Een technisch rapport, ingediend op 27 juli 2026 (arXiv 2607.24904), één versie, 23 auteurs, getiteld "Mage-VL: An Efficient Codec-Native Streaming Multimodal Foundation Model."

• Uitvoerbare code, niet alleen gewichten.De repository bevat modeling_mage_vl.py, processing_mage_vl.py, twee videoverwerkers waaronder een speciale codec_video_processing_mage_vl.py, en streammind_gate.py — ongeveer 175 KB aan aangepaste Python-code. De auto_map in config.json routeert zes Transformers-klassen naar die bestanden, daarom draagt de repository de custom_code-tag.

• Twee licenties, niet één. Mage-VL is Apache-2.0; de zelfstandige Mage-ViT-encoder wordt afzonderlijk gepubliceerd onder MIT.

• Een werkende demo die je niet hoeft te installeren. Microsoft draait microsoft/mage-vl-demo als een Hugging Face Space op ZeroGPU, en twee community Spaces gebruiken het model al.

• Vroege community-groei, die zich sneller ontwikkelt dan de eigen communicatie van de leverancier. 268 likes, 435.784 downloads geregistreerd in de afgelopen maand, negen community-kwantizaties en twee finetunes in de modelboom. Downloadtellers bevatten geautomatiseerde en mirror-pulls, dus behandel het ruwe getal als een signaal van aandacht, niet van uitrol.

• Een broertje. Mage-Flow, een model voor tekst-naar-afbeelding en instructiebewerking, gebouwd op hetzelfde vaste 4B-budget, verscheen vier dagen eerder op 22 juli. De GitHub-repository presenteert Mage als "een familie van lichtgewicht, onderzoeksvriendelijke multimodale modellen", wat het dichtst in de buurt komt van een positioneringsverklaring die ooit is gepubliceerd.

Afgezet daartegen is de lijst van dingen die niet bestaan even informatief. Er is geen Microsoft-blogpost of persbericht. Er is geen vermelding in Azure AI Foundry, wat betekent dat er geen enterprise-ondersteuningspad is, geen SLA, geen beheerd eindpunt. Geen enkele inferentieprovider biedt het aan. Er is geen vLLM- of SGLang-ondersteuning: een communityverzoek om Mage-VL aan SGLang toe te voegen werd op 28 juli ingediend als issue #32646 en is, op het moment van schrijven, nog steeds open zonder gekoppelde pull-request en zonder reactie van een onderhouder. En er is geen enkele onafhankelijke evaluatie — het model ontbreekt op de neutrale leaderboards waar een bewering als 'verslaat een 15B-model op video' normaal gesproken getest zou worden.

Het enige idee: lees de codec, niet de frames.

Bijna elke video-capabele VLM in productie doet hetzelfde. Hij decodeert de video naar RGB-frames, bemonstert ze uniform — één per seconde, of 32 verspreid over de clip, of wat het budget ook toestaat — en voert elk bemonsterd frame als een dicht raster van patches door een vision-transformer. Elke patch van elk bemonsterd frame wordt omgezet in tokens. Een statische achtergrondmuur kost precies evenveel tokens als de persoon die ervoor loopt, en kost opnieuw evenveel tokens in het volgende frame, en het daaropvolgende.

Dat is een enorme hoeveelheid redundante berekening, en moderne videocodecs hebben het onderliggende probleem tientallen jaren geleden al opgelost. H.264 en HEVC slaan niet elk frame op; ze slaan af en toe een volledig ankerframe (I-frame) op en beschrijven de frames daartussen als bewegingsvectoren plus residuen — "dit blok is hierheen verplaatst, en dit is er veranderd." De interessante delen van een video zijn, haast per definitie, de delen waaraan de encoder bits heeft besteed.

Mage-ViT maakt daar direct gebruik van. Het werkt op een patchgranulariteit van 16x16 en behoudt elke patch van de ankerframes. Voor voorspelde frames behoudt het alleen patches die door de eigen bewegingsvectoren en residuele energie van de codec als saillant zijn gemarkeerd — de gebieden die echte informatie, beweging of een scènewisseling bevatten — terwijl de laag-redundante en volledig redundante patches worden weggegooid. Microsoft schat de resulterende reductie op meer dan 75% van de visuele tokens, waarbij de spatio-temporele context behouden blijft omdat de ankerframes nog steeds de volledige scène dragen. Het ontwerp is codec-agnostisch: het traditionele pad accepteert H.264 of HEVC, en een neuraal pad accepteert DCVC-RT.

De elegantie is dat de {{1}}bewegingsschatting al was uitgevoerd{{/1}}. Elke gecomprimeerde video op het internet arriveert met een kaart van {{2}}waar de actie is{{/2}}, berekend door de encoder en betaald door degene die hem heeft geüpload. Een conventionele pipeline {{3}}gooit die kaart weg{{/3}} op het moment dat hij naar RGB decodeert, en besteedt vervolgens GPU-tijd aan het opnieuw ontdekken van dezelfde informatie. Mage-VL {{4}}weigert het simpelweg weg te gooien{{/4}}. Of de benchmarkcijfers standhouden of niet, die observatie is {{5}}de blijvende bijdrage hier{{/5}} — en het is de reden dat deze release {{6}}de moeite van het lezen waard{{/6}} is, zelfs als je de gewichten nooit downloadt.

Het schoonste aan het experiment

Verborgen in de opzet zit een ontwerpbeslissing die de resultaten veel beter interpreteerbaar maakt dan een typische modellancering, en bijna niemand die deze release behandelt heeft erop gewezen: het taalmodel wordt constant gehouden.

De decoder van Mage-VL is Qwen3-4B-Instruct-2507, ongewijzigd. De vergelijkingsbaseline, Qwen3-VL-4B, gebruikt dezelfde 4B Qwen3-backbone met een conventionele, op het web voorgetrainde visuele encoder. Dus wanneer Mage-VL beter presteert dan Qwen3-VL-4B, is het verschil toe te schrijven aan de encoder en de codec-native tokenisatie, niet aan een groter of beter getraind taalmodel. Dat is een gecontroleerde ablatie vermomd als een productvergelijking, en het is het sterkste methodologische kenmerk van de release.

Het werkt ook de andere kant op, en eerlijkheid vereist dat te zeggen. Een vergelijking met dezelfde backbone is de eerlijkste test van het encoder-idee en tegelijkertijd de opzet die het meest in zijn voordeel werkt — Microsoft koos de basislijn die de eigen bijdrage isoleert. De Phi-4-vergelijkingen hebben die eigenschap niet: Phi-4-Reasoning-Vision-15B en Phi-4-MM-5.6B hebben verschillende backbones, verschillende trainingsrecepten, verschillende post-training. "Beats our 15B model on video" is een echt resultaat, maar een veel lossere, en het is ook een vergelijking met Microsofts eigen oudere werk, wat het gemakkelijkste soort is om te winnen.

De trainingsschaal is de andere plaats waar het artikel een werkelijk verrassende bewering doet. Mage-ViT werd vanaf nul voorgetraind op ongeveer 560M ongelabelde afbeeldingen en 100M ongelabelde videoframes — een groot corpus in absolute termen, maar verre van de miljarden gecureerde beeld-tekstparen achter de encoders waarmee het concurreert. De eerste genoemde bevinding van het artikel is dat een sterke VLM-encoder geen web-schaal gesuperviseerde data nodig heeft. Als dat standhoudt onder onafhankelijke controle, is dat aanzienlijk belangrijker dan welke individuele benchmarkrij dan ook.

De cijfers, en van wie de cijfers zijn.

Wat volgt is in zijn geheel door Microsoft gerapporteerd, op Microsofts eigen evaluatieharness, tegen baselines die Microsoft heeft geselecteerd. Niets hiervan is door een derde partij gereproduceerd. Lees het als een hypothese met ongewoon specifieke foutbalken, niet als een scorebord.

• Video-MME — Mage-VL-4B 64.0 versus Qwen3-VL-4B 59.7 versus 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 vs 20,7 voor Phi-4

• Timelens-QVHighlight (temporele grounding) — 57,4 vs 34,9 vs 11,6

• Ref-DAVIS17 (verwijzingstracking) — 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 vs 81.60 vs 81.70

• ChartQA — 84.88 vs 83.96 vs 83.40

• MMStar — 67,32 vs 62,04 vs 59,63

• RealWorldQA — 70.46 vs 70.85 vs 70.72, een van de rijen waarin Mage-VL verliest

• MMBench-EN-dev — 84.02 versus 83.25, met Phi-4-Reasoning-Vision-15B dat met 84.19 beide voorbijgaat

• CV-Bench-3D / CV-Bench-2D — 94.75 vs 92.30, en 82.13 vs 81.00

• EmbSpatial — 82.67 vs 77.50

• OVO-Bench (streaming) — 64,00 totaal, beschreven als de modernste onder de streaming-architecturen; de realtime visuele perceptiedeelverzameling scoort gemiddeld 79,84% tegen 72,8% voor Qwen3-VL-4B, bij 1 fps

• Mage-ViT als zelfstandige encoder — boven 86,3% op ImageNet met een budget van 676 tokens, boven 96,1% op Food-101

Drie lezingen van die tabel zijn meer waard dan de tabel zelf.

Bij afbeeldingen is "pariteit" het eerlijke woord. DocVQA met 0,45, OCRBench met 0,20, ChartQA met 0,92, MMBench met 0,77 — deze liggen binnen het bereik waarin een andere prompttemplate of decoderingseed de volgorde zou kunnen omkeren, en RealWorldQA gaat zelfs naar Qwen3-VL-4B. Microsoft zegt dat ook, door beeldprestaties als pariteit te framen in plaats van als een overwinning, en dat framen klopt. Als je workload bestaat uit het beantwoorden van vragen over documenten en afbeeldingen, geeft deze release je geen reden om over te stappen.

Bij video- en temporele grounding zijn de verschillen groot en consistent. Timelens-QVHighlight verdubbelt bijna de baseline; Video-MME, NExT-QA en LongVideoBench bewegen allemaal met 3,6 tot 4,3 punten in dezelfde richting met een vaste backbone. Consistentie over benchmarks die verschillende aspecten testen, is het patroon dat je zou verwachten als de encoderwijziging echt is in plaats van een afstemartefact.

Twee rijen mogen niet zonder context worden geciteerd.Ref-DAVIS17 met 25.83 tegen 7.48 ziet eruit als een 3.5x afstraffing, en de belangrijkste ruimtelijke delta's in het paper omvatten +11.0 op VSI-Bench en +53.1 op CrossPoint. Wanneer een baseline bijna op de bodem scoort bij een taak, meet de delta vooral welk model getraind is om het taakformaat te begrijpen — niet welk model capabeler is. Dezelfde kanttekening geldt voor de streamingresultaten in absolute termen: op SoccerNet zijn de gerapporteerde cijfers van Mage-VL 55.54 TimVal, 83.14 ROC-AUC en een F1 van 16.35. Een F1 van 16.35 is een state-of-the-art getal in een jong evaluatiekader, geen opgelost probleem. Proactieve streamingperceptie staat nog in de kinderschoenen, en de absolute score van de koploper zegt genoeg.

De gate: een model dat beslist wanneer het moet spreken

Het tweede architectuuridee is het idee met de duidelijkste productimplicaties, en het verklaart dat mysterieuze bestand van 1,07 GB.

Mage-VL splitst streaming in twee processen, in de paper gepresenteerd als {{1}}Systeem 1 en Systeem 2{{/1}}. Systeem 1 is een lichtgewicht {{2}}"cognitiepoort"{{/2}} die elk schuivend venster van codec-features in de gaten houdt en de kans schat dat er zojuist iets is afgerond dat het bespreken waard is. Onder een drempel blijft het stil en het dure deel van het model draait nooit. Boven die drempel wordt de volledige decoder aangeroepen om een respons te genereren. De demo-configuratie gebruikt causale vensters van 30 seconden bij 1 fps, de CLI stelt de drempel rechtstreeks beschikbaar als {{3}}--gate_threshold{{/3}}, en het streaming-ingangspunt verwerkt video segment voor segment ({{4}}inference_streaming.py --video_backend codec --segment_sec 8{{/4}}). Alleen de poort wordt in de laatste fase getraind, op 3,35 miljoen streaming-samples.

Er zijn twee dingen die het opmerken waard zijn. Ten eerste is de gate geen kleine classificatiekop die er bovenop is vastgeschroefd: 1,07 GB aan BF16-gewichten is ruwweg een half miljard parameters, een volwaardig model op zich, geleverd als een afzonderlijk checkpoint. Ten tweede is de bestandsnaam streammind_gate.safetensors — de naamgeving suggereert dat dit onderdeel voortkomt uit eerder streaming-perceptiewerk in plaats van speciaal voor dit artikel te zijn bedacht, hoewel de repository zelf die afstamming niet expliciet vermeldt.

{{1}}Waarom dit commercieel van belang is:{{/1}} {{2}}bij video die altijd aan staat, zijn de dominante kosten niet de latentie per oproep, maar de oproepfrequentie.{{/2}} {{3}}Een camerafeed die 24/7 via een conventionele VLM op 1 fps draait, betekent 86.400 forward passes per dag, of er nu wel of niet iets is gebeurd.{{/3}} {{4}}Een gate die stil blijft tijdens de 99% van de beelden waarin niets gebeurt, verandert de vorm van die rekening, niet alleen de hoogte ervan.{{/4}} {{5}}Of Microsofts gate nauwkeurig genoeg is om die beslissing aan toe te vertrouwen, is precies het punt dat niemand buiten het lab heeft getest.{{/5}}

Kun je het vandaag echt laten draaien?

Ja, als je een GPU en geduld hebt. De frictie is reëel en zit vooral in de videopijplijn in plaats van in het model.

Geheugen. Microsoft publiceert geen VRAM-vereiste. Op basis van de gewichtsindex: 9,49 GB aan shards plus de 1,07 GB gate is ongeveer 10,6 GB aan BF16-parameters, dus een 16 GB-kaart is een realistisch minimum voor beeldwerk en 24 GB of meer is het verstandige doel zodra je KV-cache toevoegt voor lange video of een streamingvenster. Dat is rekenwerk op basis van bestandsgroottes, geen leveranciersspecificatie — meet voordat je inricht.

Aangepaste code is verplicht. De auto_map wijst elk Transformers-ingangspunt naar de eigen modules van de repository, dus trust_remote_code is vereist. Je voert Microsofts Python uit, niet louter het laden van tensors. Er is nog geen vLLM- of SGLang-pad, wat betekent: geen paged attention, geen continue batching, geen productie-servingstack — een aanzienlijke leemte als je hoopte dit achter een endpoint te plaatsen.

Het codec-pad vereist systeemhulpmiddelen. FFmpeg en ffprobe moeten op je PATH staan. De traditionele codec-backend is afhankelijk van een codec-video-prep-pakket dat een cv-preinfer-stap levert; het neurale pad heeft DCVC-RT nodig; de backend voor gewone frames heeft Decord nodig. De vereisten trekken ook flash-attn en mamba-ssm aan, die CUDA-extensies compileren — installeer eerst een PyTorch-build die overeenkomt met je toolkit of reserveer een middag voor de build.

Wat de configuratie je vertelt dat de kaart niet doet. Maximale positie-embeddings zijn 262.144, dus de decoder erft de lange context van Qwen3-4B. De visiekant draait op 448-pixel invoer met 16x16 patches, een encoder met 24 lagen en 1024 verborgen eenheden, 2x2 ruimtelijke samenvoeging, één token per seconde video en een venster van vier frames. De training bereikte in fase drie een temporele lengte van 384 frames. Een plafond van 262K is niet hetzelfde als 262K aan gevalideerd gedrag, en 384 frames is de lengte die het model daadwerkelijk heeft geleerd te verwerken.

Bekende ruwe randjes. Een open discussie op de repo, ingediend op 4 augustus en nog steeds onbeantwoord, meldt token-misalignment wanneer afbeeldingen en video's in hetzelfde verzoek worden doorgegeven. Tiendaagse software gedraagt zich als tiendaagse software. Als je een kijkje wilt zonder dit alles, is de door Microsoft beheerde Space op ZeroGPU de installatievrije optie.

De licentieregel is minder eenvoudig dan "Apache-2.0"

De modelkaart vermeldt Apache-2.0. De Mage-ViT-encoder vermeldt MIT. Beide zijn ongeveer zo permissief als open weights kunnen zijn. Maar de family-repository stelt dat "deze modellen uitsluitend voor onderzoeksdoeleinden worden vrijgegeven", met de nadruk op verantwoorde-AI-review en menselijk toezicht — en die zin staat op gespannen voet met een Apache-2.0-licentie, die commercieel gebruik niet beperkt. Tel daarbij de afhankelijkheden op: DCVC-RT en de tooling voor codec-voorbereiding hebben hun eigen voorwaarden, onafhankelijk van die van het model.

Voor een hobbyproject is dit ruis. Voor alles wat naar klanten wordt verzonden, is het het soort dubbelzinnigheid dat eerst naar de juridische adviseur zou moeten gaan voordat het naar productie gaat, en het soort vraag dat de moeite waard is om op de repo zelf te stellen — waar, opmerkelijk genoeg, momenteel geen vertegenwoordiger van Microsoft antwoordt.

Moet je hierop voortbouwen?

De beslissing valt duidelijk uiteen langs één lijn: of je probleem een stream of een verzoek is.

Als je altijd-aan-perceptie draait — een camerafeed, een live-uitzending, het gezichtsveld van een robot, een vergadering die een uur duurt — dan is Mage-VL precies op jou gericht en is de economie van self-hosting in jouw voordeel. Bij API-prijsstelling per token schalen de kosten met het aantal frames, wat een genadeloos model is voor continue video; een 4B-model op je eigen hardware met een gate die stil blijft bij onopvallende beelden is een fundamenteel andere kostencurve. Het addertje onder het gras is dat je er ook voor tekent om de eerste persoon buiten Microsoft te zijn die erachter komt of het oordeel van de gate wel deugt.

Als uw probleem de vorm heeft van een verzoek — een gebruiker uploadt een document, een pdf, een screenshot, een korte clip en verwacht een antwoord — ligt de zaak veel zwakker. Op precies die taken presteert Mage-VL even goed als een model dat u nog altijd zelf zou moeten hosten, en gehoste multimodale endpoints liggen op slechts één API-aanroep afstand: geen GPU, geen ffmpeg-build en geen trust_remote_code nodig. Via OrcaRouter is Gemini 3.6 Flash beschikbaar voor $1,50 per miljoen invoertokens en $7,50 per miljoen uitvoertokens — dat is de lijstprijs van de provider, die we rechtstreeks doorgeven; wij rekenen 0% opslag. Dus wanneer een leverancier de prijzen verlaagt, is die verlaging dezelfde dag bij ons live in plaats van na een prijsherziening. Eén sleutel geeft toegang tot 200-plus modellen met automatische failover als een provider degradeert; dat is de praktische reden om een gehost endpoint als standaard te behouden en self-hosting te reserveren voor workloads die het echt nodig hebben.

Om het expliciet te zeggen, omdat het onderscheid ertoe doet: wij hosten Mage-VL niet, en niemand anders doet dat ook. Hugging Face's eigen modelpagina zegt dat geen enkele inference-provider het heeft ingezet. Vandaag de dag betekent het draaien ervan dat je het zelf draait.

Wat zou deze aflezing veranderen?

Vier dingen, in grove volgorde van hoeveel ze ertoe zouden doen.

Een onafhankelijke evaluatie is de belangrijkste. Elk getal hierboven is een bewering, en de bewering die het meest getest moet worden is niet een benchmarkresultaat, maar de 3,5x versnelling, die is gemeten ten opzichte van uniforme framesampling op NExT-QA zonder gepubliceerde details over hardware, resolutie of het aantal frames. Codec-voorverwerking verplaatst echt werk naar de CPU en naar ffmpeg; een kloktijdwinst die end-to-end is gemeten op andermans systeem is de enige versie van dat getal waarmee je bij het plannen rekening moet houden.

Ten tweede, ondersteuning voor serving. Een geïntegreerde vLLM- of SGLang-implementatie zou dit veranderen van een onderzoekscheckpoint in iets dat je achter een load balancer kunt plaatsen. De SGLang-issue is open en niet opgeëist; dat is de thread om in de gaten te houden.

Ten derde, een vermelding in Azure AI Foundry, die zou aangeven dat Microsoft dit als product bedoelt in plaats van als paper. Niets in de huidige release suggereert dat dat op handen is.

Ten vierde, en het vreemdste: of Microsoft ooit iets zegt. Een technisch rapport met 23 auteurs, een onderhouden projectpagina, een gehoste demo Space en een zustergenerationeel model vier dagen eerder beschrijven geen lek of ongeluk — ze beschrijven een bewuste onderzoekspublicatie die de productmegafoon volledig oversloeg. De gemeenschap vulde de stilte toch in, met negen kwantiseringen en twee finetunes binnen tien dagen.

Voor de meeste teams is de juiste zet om het paper te lezen, niet de gewichten te downloaden. Het codec-native idee is de belangrijkste conclusie, en het is overdraagbaar: als het hergebruiken van bewegingsvectoren die de encoder al heeft berekend echt een tokenreductie van 75% oplevert bij gelijke nauwkeurigheid, dan zal die techniek opduiken in modellen met lanceringsaankondigingen, providerondersteuning en gereproduceerde benchmarks. Als je vandaag continu video draait, is de afweging anders — clone de repo, draai je eigen clips door beide backends en meet de snelheidswinst zelf, want op dit moment zou je de eerste zijn.

Vragen die het echt waard zijn om te stellen

Is Mage-VL gewoon Qwen3-VL met een Microsoft-label erop?

Nee, hoewel de verwarring begrijpelijk is. De taaldecoder is Qwen3-4B-Instruct-2507, ongewijzigd gebruikt — Microsoft heeft geen nieuw LLM getraind. Al het andere is nieuw: Mage-ViT is vanaf nul voorgetraind, de codec-native tokenisatie heeft geen tegenhanger in Qwen3-VL, en de streaming-gate is een extra model van een half miljard parameters. Het hergebruiken van een open backbone en het vervangen van de visuele front-end is een legitieme en steeds vaker voorkomende onderzoeksstrategie, en hier maakt het ook de directe vergelijking interpreteerbaar. Als je compliance-eisen hebt rondom modelherkomst, houd er dan rekening mee dat de afstamming via Alibaba's Qwen3-gewichten loopt en controleer beide licenties.

Betekent '3,5x sneller' 3,5x goedkoper om te serveren?

Niet betrouwbaar. Het cijfer is een wall-clock-versnelling op NExT-QA ten opzichte van uniforme framebemonstering, en Microsoft presenteert het als "tot wel". Twee dingen zwakken dit in de praktijk af. Codec-native inferentie vereist een voorbereidingsstap — ffmpeg, ffprobe en de cv-preinfer-stap, of een DCVC-RT-hercodering voor het neurale pad — die CPU-tijd kost die een naïeve frames-pipeline niet heeft, en die niet wordt meegenomen in een GPU-zijdige meting. En de winst komt voort uit tokenreductie, dus het schaalt met hoe redundant je beeldmateriaal is: een grotendeels statische beveiligingscamera zou het beter moeten doen dan het genoemde cijfer, terwijl snel gemonteerde video waarin bijna elke patch verandert, slechter zou presteren. Meet het op je eigen clips.

Heb ik speciale videobestanden nodig om het codec-pad te gebruiken?

Meestal niet, en dat is de prettige verrassing. Gewone MP4-bestanden zijn al H.264 of HEVC, en dat is precies wat de traditionele codec-backend gebruikt — de bewegingsvectoren die hij nodig heeft, zitten al in het bestand dat je al hebt. Wat je moet toevoegen is de tooling: FFmpeg en ffprobe op je PATH, plus het pakket voor codec-voorbereiding. De neurale backend is de uitzondering; DCVC-RT verwacht video die met die codec is gecodeerd, dus die zou je opnieuw moeten encoderen. En de backend met gewone frames blijft beschikbaar als fallback die zich gedraagt als elke andere VLM, wat ook de eerlijke manier is om de codec-claim zelf te A/B-testen.

Mag ik het commercieel gebruiken?

De licentie vermeldt Apache-2.0, wat commercieel gebruik, modificatie en redistributie toestaat. De repository vermeldt ook dat de modellen "alleen voor onderzoeksdoeleinden zijn uitgebracht". Die twee verklaringen wijzen in verschillende richtingen, en het gat daartussen is door niemand bij Microsoft verduidelijkt — wat bij een release zonder aankondiging, zonder productverwijzing en zonder aanwezigheid van de leverancier in de repository-discussies niet verrassend is. Als er geld afhangt van het antwoord, laat dan een jurist beide documenten en de licenties van de afhankelijkheden lezen, in plaats van alleen op de licentiebadge te vertrouwen.