Microsoft Mage-VL: Ein Codec-natives 4B-Videomodell, ohne Ankündigung veröffentlicht

Es gibt keinen Microsoft-Blogbeitrag über Mage-VL. Kein Azure-Newsroom-Eintrag, kein Foundry-Katalogeintrag, kein Launch-Thread, nichts auf den Produktkanälen, auf denen Microsoft normalerweise ein Modell vorstellt. Stattdessen gibt es ein Hugging-Face-Repository — microsoft/Mage-VL, sechs Commits, 10,8 GB an Gewichten, Apache-2.0 — einen GitHub-Ordner mit Inferenzskripten, eine Projektseite, die von etwas gepflegt wird, das sich selbst Microsoft Mage Team nennt, und einen arXiv-Bericht mit 23 Autoren. Zusammen gelesen beschreiben diese Artefakte ein Vision-Language-Modell der 4B-Klasse, dessen zentrale Idee wirklich ungewöhnlich ist: Anstatt Video in gleichmäßig verteilte Frames zu dekodieren und ein dichtes Patch-Raster durch einen web-vortrainierten Encoder zu schicken, liest Mage-VL den komprimierten Bitstrom selbst und verwendet einen von Grund auf neu entwickelten Encoder namens Mage-ViT, um nur die Patches zu behalten, für die der Codec Bits ausgegeben hat. Microsoft berichtet, dass dies die visuellen Tokens um mehr als 75 % reduziert und eine bis zu 3,5-fache Wall-Clock-Beschleunigung liefert, während es bei statischen Bildern mit Qwen3-VL-4B mithält und Microsofts eigenes 15B-Phi-4-Reasoning-Vision bei Videos übertrifft.

Diesen letzten Satz sollte man mit Vorsicht genießen. Jede Leistungszahl in diesem Artikel geht auf Microsofts eigenes Paper, Model Card oder Projektseite zurück. Zehn Tage nachdem die Gewichte erschienen sind, hat keine unabhängige Stelle irgendetwas davon reproduziert, kein Drittanbieter-Leaderboard führt das Modell, und — wie die Hugging-Face-Seite unmissverständlich feststellt — es „ist von keinem Inference-Provider bereitgestellt“, sodass es nicht einmal einen gehosteten Endpunkt gibt, den jemand beiläufig hätte benchmarken können. Was folgt, trennt das, was das Repository beweist, von dem, was Microsoft lediglich behauptet, denn bei einer Veröffentlichung ohne Ankündigung sind das sehr unterschiedliche Kategorien.

Was tatsächlich existiert, zehn Tage danach.

Die verifizierbare Oberfläche dieses Releases ist klein und es lohnt sich, sie genau aufzuzählen.

• Gewichte, datiert auf den 26. Juli 2026. Zwei Safetensors-Shards mit 4,97 GB und 4,52 GB, plus eine separate 1,07-GB-Datei namens streammind_gate.safetensors. Hugging Faces eigener Reader meldet 5B Parameter bei BF16 — 4B im Sprach-Decoder, der Rest aufgeteilt zwischen dem visuellen Encoder und diesem Gate.

• Ein technischer Bericht, eingereicht am 27. Juli 2026 (arXiv 2607.24904), eine Version, 23 Autoren, mit dem Titel „Mage-VL: An Efficient Codec-Native Streaming Multimodal Foundation Model.“

• Ausführbarer Code, nicht nur Gewichte.Das Repo enthält modeling_mage_vl.py, processing_mage_vl.py, zwei Videoprozessoren einschließlich eines dedizierten codec_video_processing_mage_vl.py sowie streammind_gate.py – etwa 175 KB eigener Python-Code. Die auto_map in config.json leitet sechs Transformers-Klassen in diese Dateien, weshalb das Repo das custom_code-Tag trägt.

• Zwei Lizenzen, nicht eine. Mage-VL ist Apache-2.0; der eigenständige Mage-ViT-Encoder wird separat unter MIT veröffentlicht.

• Eine funktionierende Demo, die Sie nicht installieren müssen. Microsoft betreibt microsoft/mage-vl-demo als Hugging Face Space auf ZeroGPU, und zwei Community-Spaces nutzen das Modell bereits.

• Früher Community-Zuspruch, der sich schneller bildet als die eigene Kommunikation des Anbieters. 268 Likes, 435.784 Downloads im letzten Monat, neun Community-Quantisierungen und zwei Finetunes im Modellbaum. Die Download-Zähler umfassen automatisierte und Mirror-Abrufe; behandeln Sie die Rohzahl also als Signal für Aufmerksamkeit und nicht für Bereitstellung.

• Ein Geschwister. Mage-Flow, ein Text-zu-Bild- und Anweisungsbearbeitungsmodell, das mit demselben festen 4B-Budget entwickelt wurde, erschien vier Tage früher, am 22. Juli. Das GitHub-Repository präsentiert Mage als „eine Familie leichtgewichtiger, forschungsfreundlicher multimodaler Modelle", was dem am nächsten kommt, was jemand als Positionierungsaussage veröffentlicht hat.

Demgegenüber ist die Liste der Dinge, die es nicht gibt, ebenso aufschlussreich. Es gibt keinen Microsoft-Blogbeitrag und keine Pressemitteilung. Es gibt keinen Eintrag in Azure AI Foundry, was bedeutet: kein Enterprise-Support-Pfad, keine SLA, kein verwalteter Endpunkt. Kein Inferenzanbieter bietet es an. Es gibt keine vLLM- oder SGLang-Unterstützung: Eine Community-Anfrage, Mage-VL zu SGLang hinzuzufügen, wurde am 28. Juli als Issue #32646 eingereicht und ist Stand heute noch offen – ohne verknüpften Pull-Request und ohne Reaktion der Maintainer. Und es gibt keinerlei unabhängige Evaluierung – das Modell fehlt auf den neutralen Leaderboards, wo eine Behauptung wie „schlägt ein 15B-Modell bei Video“ normalerweise getestet würde.

Die eine Idee: den Codec lesen, nicht die Frames.

Fast jedes videofähige VLM in der Produktion macht dasselbe. Es dekodiert das Video in RGB-Frames, sampelt sie gleichmäßig – einen pro Sekunde, oder 32 über den Clip, oder was auch immer das Budget erlaubt – und führt jeden gesampelten Frame durch einen Vision Transformer als dichtes Raster von Patches. Jeder Patch jedes gesampelten Frames wird zu Tokens. Eine statische Hintergrundwand kostet genauso viele Tokens wie die Person, die davor geht, und sie kostet sie erneut im nächsten Frame und im übernächsten.

Das ist eine enorme Menge redundanter Berechnungen, und moderne Videocodecs haben das zugrunde liegende Problem bereits vor Jahrzehnten gelöst. H.264 und HEVC speichern nicht jeden Frame; sie speichern gelegentliche Anker-(I-)Frames in voller Auflösung und beschreiben dann die Frames dazwischen als Bewegungsvektoren plus Residuen – „dieser Block hat sich hierher bewegt, und hier ist, was sich geändert hat.“ Die interessanten Teile eines Videos sind, fast schon konstruktionsbedingt, die Teile, für die der Encoder Bits aufgewendet hat.

Mage-ViT nutzt das direkt aus. Bei einer Patch-Granularität von 16x16 behält es jeden Patch der Ankerframes und behält für vorhergesagte Frames nur die Patches bei, die von den eigenen Bewegungsvektoren und der Restenergie des Codecs als salient markiert wurden – die Bereiche, die echte Informationen, Bewegung oder eine Szenenänderung tragen – während die niedrig redundanten und vollständig redundanten verworfen werden. Microsoft beziffert die resultierende Reduktion auf über 75 % der visuellen Tokens, wobei der räumlich-zeitliche Kontext erhalten bleibt, da die Ankerframes weiterhin die gesamte Szene tragen. Das Design ist codec-agnostisch: Der traditionelle Pfad akzeptiert H.264 oder HEVC, und ein neuronaler Pfad akzeptiert DCVC-RT.

Das Elegante daran ist, dass die Bewegungsschätzung bereits durchgeführt wurde. Jedes komprimierte Video im Internet kommt mit einer Karte, die zeigt, wo sich etwas bewegt, berechnet vom Encoder und bezahlt von demjenigen, der es hochgeladen hat. Eine herkömmliche Pipeline verwirft diese Karte in dem Moment, in dem sie zu RGB decodiert, und verbringt dann GPU-Zeit damit, dieselben Informationen wiederzuentdecken. Mage-VL lehnt es schlicht ab, sie zu verwerfen. Ob die Benchmark-Zahlen nun Bestand haben oder nicht, diese Beobachtung ist der bleibende Beitrag hier – und sie ist der Grund, warum diese Veröffentlichung lesenswert ist, selbst wenn man die Gewichte nie herunterlädt.

Das Sauberste an dem Experiment

Versteckt im Setup steckt eine Designentscheidung, die die Ergebnisse weitaus interpretierbarer macht als bei einem typischen Modell-Launch, und fast niemand, der über diese Veröffentlichung berichtet, hat darauf hingewiesen: Das Sprachmodell wird konstant gehalten.

Mage-VLs Decoder ist Qwen3-4B-Instruct-2507, unverändert. Die Vergleichs-Baseline Qwen3-VL-4B verwendet dasselbe 4B-Qwen3-Backbone mit einem konventionellen, im Web vortrainierten visuellen Encoder. Wenn Mage-VL sich gegenüber Qwen3-VL-4B verbessert, ist die Differenz auf den Encoder und die codec-native Tokenisierung zurückzuführen, nicht auf ein größeres oder besser trainiertes Sprachmodell. Das ist eine kontrollierte Ablation im Gewand eines Produktvergleichs und das stärkste methodische Merkmal der Veröffentlichung.

Es schneidet auch in die andere Richtung, und Ehrlichkeit gebietet, das zu sagen. Ein Vergleich mit identischem Backbone ist der fairste Test für die Encoder-Idee und zugleich die Darstellung, die ihr am ehesten schmeichelt — Microsoft wählte die Baseline, die den eigenen Beitrag isoliert. Die Phi-4-Vergleiche haben diese Eigenschaft nicht: Phi-4-Reasoning-Vision-15B und Phi-4-MM-5.6B haben andere Backbones, andere Trainingsverfahren und ein anderes Post-Training. „Beats our 15B model on video“ ist ein echtes Ergebnis, aber ein weitaus ungenaueres, und es ist außerdem ein Vergleich mit Microsofts eigener älterer Arbeit, also die Art von Vergleich, die am leichtesten zu gewinnen ist.

Der Trainingsumfang ist die andere Stelle, an der das Papier eine wirklich überraschende Behauptung aufstellt. Mage-ViT wurde von Grund auf mit etwa 560 Millionen unbeschrifteten Bildern und 100 Millionen unbeschrifteten Videoframes vortrainiert – ein in absoluten Zahlen großer Korpus, aber weit entfernt von den Milliarden kuratierter Bild-Text-Paare, die hinter den Encodern stehen, mit denen es konkurriert. Die erste ausdrücklich genannte Erkenntnis des Papiers ist, dass ein starker VLM-Encoder keine Web-Scale-Supervised-Daten benötigt. Wenn sich das unter unabhängiger Prüfung bestätigt, ist das erheblich bedeutsamer als jede einzelne Benchmark-Zeile.

Die Zahlen, und wessen Zahlen sie sind

Das Folgende wurde durchgängig von Microsoft berichtet, auf Microsofts eigener Evaluierungsumgebung, gegen von Microsoft ausgewählte Baselines. Nichts davon wurde von Dritten reproduziert. Betrachten Sie es als eine Hypothese mit ungewöhnlich spezifischen Fehlerbalken, nicht als eine Punktetafel.

• 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 vs. 20,7 für Phi-4

• Timelens-QVHighlight (temporales Grounding) — 57.4 vs 34.9 vs 11.6

• Ref-DAVIS17 (referenzbasiertes Tracking) — 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, eine der Zeilen, in denen Mage-VL verliert

• MMBench-EN-dev — 84.02 vs 83.25, wobei Phi-4-Reasoning-Vision-15B mit 84.19 vor beiden liegt

• CV-Bench-3D / CV-Bench-2D — 94,75 vs 92,30 und 82,13 vs 81,00

• EmbSpatial — 82.67 vs 77.50

• OVO-Bench (streaming) — 64,00 insgesamt, beschrieben als Stand der Technik unter den Streaming-Architekturen; das Echtzeit-Visual-Perception-Subset erreicht durchschnittlich 79,84 % gegenüber 72,8 % bei Qwen3-VL-4B, bei 1 fps

• Mage-ViT als eigenständiger Encoder — über 86,3 % auf ImageNet bei einem 676-Token-Budget, über 96,1 % auf Food-101

Drei Lesungen dieser Tabelle sind mehr wert als die Tabelle selbst.

Bei Bildern ist „Parität" das ehrliche Wort.DocVQA um 0,45, OCRBench um 0,20, ChartQA um 0,92, MMBench um 0,77 – das liegt in einem Bereich, in dem eine andere Prompt-Vorlage oder ein anderer Decoding-Seed die Reihenfolge umkehren könnte, und RealWorldQA geht tatsächlich an Qwen3-VL-4B. Microsoft sagt genau das und stellt die Bildleistung als Parität dar, nicht als Sieg – und diese Darstellung ist korrekt. Wenn Ihre Arbeitslast das Beantworten von Fragen zu Dokumenten und Bildern ist, gibt Ihnen dieses Release keinen Grund zu wechseln.

Beim Video- und Temporal-Grounding sind die Lücken groß und durchgängig. Timelens-QVHighlight verdoppelt die Baseline nahezu; Video-MME, NExT-QA und LongVideoBench bewegen sich bei unverändertem Backbone alle um 3,6 bis 4,3 Punkte in dieselbe Richtung. Konsistenz über Benchmarks, die unterschiedliche Aspekte betonen, ist das Muster, das man erwarten würde, wenn die Encoder-Änderung real ist und nicht bloß ein Abstimmungsartefakt.

Zwei Zeilen sollten nicht ohne Kontext zitiert werden. Ref-DAVIS17 mit 25,83 gegen 7,48 wirkt wie eine 3,5-fache Demolierung, und die wichtigsten räumlichen Deltas des Papiers umfassen +11,0 bei VSI-Bench und +53,1 bei CrossPoint. Wenn eine Baseline bei einer Aufgabe nahe der Untergrenze abschneidet, misst das Delta hauptsächlich, welches Modell darauf trainiert wurde, das Aufgabenformat zu verstehen — und nicht, welches Modell leistungsfähiger ist. Dieselbe Vorsicht gilt für die Streaming-Ergebnisse in absoluten Zahlen: Bei SoccerNet liegen die angegebenen Werte von Mage-VL bei 55,54 TimVal, 83,14 ROC-AUC und einem F1 von 16,35. Ein F1 von 16,35 ist ein Spitzenwert in einer jungen Evaluierung, kein gelöstes Problem. Proaktive Streaming-Wahrnehmung steckt noch in den Kinderschuhen, und der absolute Wert des Spitzenreiters sagt genau das aus.

Das Tor: ein Modell, das entscheidet, wann es spricht

Die zweite architektonische Idee ist diejenige mit den klarsten Produktauswirkungen, und sie erklärt diese mysteriöse 1,07-GB-Datei.

Mage-VL teilt Streaming in zwei Prozesse auf, die in der Arbeit als System 1 und System 2 bezeichnet werden. System 1 ist ein leichtgewichtiges „Kognitions-Gate“, das jedes gleitende Fenster von Codec-Merkmalen beobachtet und die Wahrscheinlichkeit schätzt, dass gerade etwas zu Ende gegangen ist, worüber es sich zu sprechen lohnt. Unterhalb eines Schwellenwerts bleibt es still und der teure Teil des Modells wird nie ausgeführt. Oberhalb davon wird der vollständige Decoder aufgerufen, um eine Antwort zu erzeugen. Die Demo-Konfiguration verwendet kausale Fenster von 30 Sekunden bei 1 fps, die CLI stellt den Schwellenwert direkt als --gate_threshold bereit, und der Streaming-Einstiegspunkt verarbeitet Videosegmente Abschnitt für Abschnitt (inference_streaming.py --video_backend codec --segment_sec 8). Nur das Gate wird in der letzten Stufe trainiert, mit 3,35 Mio. Streaming-Beispielen.

Zweierlei daran ist bemerkenswert. Erstens ist das Gate kein kleines Klassifikationsköpfchen, das oben draufgesetzt wurde: 1,07 GB BF16-Gewichte entsprechen grob einer halben Milliarde Parametern – ein eigenständiges Modell, das als separater Checkpoint ausgeliefert wird. Zweitens lautet der Dateiname streammind_gate.safetensors – die Benennung legt nahe, dass diese Komponente aus früheren Arbeiten zum Streaming-Perception stammt und nicht eigens für dieses Paper erfunden wurde, auch wenn das Repository diese Herkunft nicht explizit darlegt.

Warum das kommerziell wichtig ist: Bei Dauer-Video sind nicht die Latenz pro Aufruf, sondern die Aufrufhäufigkeit der dominante Kostenfaktor. Ein Kamera-Feed, der rund um die Uhr mit 1 fps durch ein herkömmliches VLM läuft, bedeutet 86.400 Forward-Passes pro Tag, egal ob etwas passiert ist oder nicht. Ein Gate, das in den 99 % des Materials, in denen nichts passiert, ruhig bleibt, verändert die Form dieser Rechnung, nicht nur ihre Höhe. Ob Microsofts Gate genau genug ist, um dieser Entscheidung zu vertrauen, ist genau das, was außerhalb des Labors noch niemand getestet hat.

Kannst du es heute tatsächlich ausführen?

Ja, wenn man eine GPU und Geduld hat. Die Reibung ist real und liegt hauptsächlich in der Videopipeline und nicht im Modell.

Speicher.Microsoft veröffentlicht keine VRAM-Anforderung. Aus dem Gewichtsindex: 9,49 GB Shards plus 1,07 GB Gate ergeben etwa 10,6 GB BF16-Parameter. Eine 16-GB-Karte ist also eine realistische Untergrenze für die Arbeit mit Bildern, und 24 GB oder mehr sind das sinnvolle Ziel, sobald Sie den KV-Cache für lange Videos oder ein Streaming-Fenster hinzufügen. Das ist eine Berechnung anhand der Dateigrößen, keine Herstellerspezifikation – messen Sie, bevor Sie bereitstellen.

Eigener Code ist zwingend erforderlich. Die auto_map verweist jeden Transformers-Einstiegspunkt auf die eigenen Module des Repositorys, daher ist trust_remote_code erforderlich. Sie führen Microsofts Python aus, nicht nur Tensoren zu laden. Es gibt noch keinen vLLM- oder SGLang-Pfad, was bedeutet: kein Paged Attention, kein Continuous Batching, kein Produktions-Serving-Stack – eine erhebliche Lücke, wenn Sie gehofft hatten, dies hinter einen Endpunkt zu stellen.

Der Codec-Pfad benötigt Systemwerkzeuge. FFmpeg und ffprobe müssen im PATH verfügbar sein. Das traditionelle Codec-Backend hängt von einem codec-video-prep-Paket ab, das einen cv-preinfer-Schritt bereitstellt; der neuronale Pfad benötigt DCVC-RT; das einfache Frames-Backend benötigt Decord. Die Anforderungen ziehen außerdem flash-attn und mamba-ssm mit sich, die CUDA-Erweiterungen kompilieren – installieren Sie zuerst einen PyTorch-Build, der zu Ihrem Toolkit passt, oder planen Sie einen Nachmittag für den Build ein.

Was dir die Konfiguration sagt, das tut die Karte nicht. Die maximalen Positions-Embeddings betragen 262.144, sodass der Decoder den langen Kontext von Qwen3-4B erbt. Die Vision-Seite arbeitet mit einer 448-Pixel-Eingabe, 16x16-Patches, einem 24-Schichten-Encoder mit 1024 Hidden-Dimensionen, 2x2-Spatial-Merging, einem Token pro Sekunde Video und einem Vier-Frame-Fenster. In Stufe drei erreichte das Training eine zeitliche Länge von 384 Frames. Eine Obergrenze von 262K ist nicht dasselbe wie 262K validiertes Verhalten, und 384 Frames ist die Länge, mit der das Modell tatsächlich trainiert wurde.

Bekannte raue Kanten. Eine offene Diskussion im Repo, eingereicht am 4. August und bis heute unbeantwortet, berichtet von einer Token-Fehlausrichtung, wenn Bilder und Videos in derselben Anfrage übergeben werden. Zehn-Tage-Software verhält sich wie Zehn-Tage-Software. Wenn Sie einen Blick ohne all das werfen möchten, ist der von Microsoft betriebene Space auf ZeroGPU die Option ohne Installation.

Die Lizenzzeile ist nicht so einfach wie „Apache-2.0“.

Das Modellkartenblatt gibt Apache-2.0 an. Der Mage-ViT-Encoder gibt MIT an. Beide sind so permissiv, wie offene Gewichte nur sein können. Aber das Familienrepository stellt fest, dass „diese Modelle nur für Forschungszwecke veröffentlicht werden“, mit Betonung auf Responsible-AI-Review und menschlicher Aufsicht – und dieser Satz verträgt sich nur schlecht mit einer Apache-2.0-Lizenz, die die kommerzielle Nutzung nicht einschränkt. Hinzu kommen die Abhängigkeiten: DCVC-RT und die Codec-Vorbereitungstools tragen ihre eigenen Bedingungen, unabhängig von denen des Modells.

Für ein Hobbyprojekt ist das nur Rauschen. Für alles, was an Kunden ausgeliefert wird, ist es die Art von Mehrdeutigkeit, die vor der Produktion dem Rechtsbeistand vorgelegt werden sollte, und die Art von Frage, die es wert ist, im Repository selbst gestellt zu werden — wo es bemerkenswerterweise derzeit keinen Microsoft-Vertreter gibt, der antwortet.

Solltest du darauf aufbauen?

Die Entscheidung teilt sich sauber entlang einer Linie: ob Ihr Problem ein Stream oder eine Anfrage ist.

Wenn Sie Dauerwahrnehmung betreiben — einen Kamerafeed, eine Live-Übertragung, das Sichtfeld eines Roboters, eine Besprechung, die eine Stunde lang läuft — dann ist Mage-VL genau auf Sie ausgerichtet, und die Wirtschaftlichkeit des Self-Hostings spricht für Sie. Die Pro-Token-Preise der API skalieren mit den Frames, was für kontinuierliches Video ein brutales Modell ist; ein 4B-Modell auf eigener Hardware mit einem Gate, das bei ereignislosem Videomaterial still bleibt, ist eine grundlegend andere Kostkurve. Der Haken ist, dass Sie sich damit auch darauf einlassen, die erste Person außerhalb von Microsoft zu sein, die herausfindet, ob das Urteil des Gates etwas taugt.

Wenn Ihr Problem die Form einer Anfrage hat – ein Benutzer lädt ein Dokument, eine PDF, einen Screenshot, einen kurzen Clip hoch und erwartet eine Antwort – ist das Argument viel schwächer. Genau bei diesen Aufgaben ist Mage-VL auf Augenhöhe mit einem Modell, das Sie selbst hosten müssten, und gehostete multimodale Endpunkte sind nur einen API-Aufruf entfernt, ohne GPU, ohne ffmpeg-Build und ohne trust_remote_code. Bei OrcaRouter, Gemini 3.6 Flashkostet 1,50 $ pro Million Eingabe-Token und 7,50 $ pro Million Ausgabe-Token, was der Listenpreis des Anbieters ist, direkt durchgereicht — wir erheben 0% Aufschlag. Wenn also ein Anbieter die Preise senkt, ist die Senkung bei uns am selben Tag live und nicht erst nach einer Preisüberprüfung. Ein Schlüssel bietet Zugriff auf über 200 Modelle mit automatischem Failover, falls ein Anbieter nachlässt, was der praktische Grund ist, einen gehosteten Endpunkt als Standard beizubehalten und Self-Hosting für die Arbeitslasten zu reservieren, die es wirklich benötigen.

Um es deutlich zu sagen, weil die Unterscheidung wichtig ist: wir hosten Mage-VL nicht, und das tut auch niemand sonst. Hugging Ffaces eigene Modellseite besagt, dass kein Inferenzanbieter es bereitgestellt hat. Heute bedeutet, es auszuführen, dass man es selbst ausführt.

Was würde diese Lesart ändern?

Vier Dinge, grob danach geordnet, wie sehr sie zählen würden.

Eine unabhängige Bewertung ist das Wichtigste. Jede der obigen Zahlen ist eine Behauptung, und die Behauptung, die am dringendsten getestet werden muss, ist kein Benchmark-Ergebnis, sondern die 3,5-fache Beschleunigung, die gegen gleichmäßiges Frame-Sampling auf NExT-QA gemessen wurde, ohne veröffentlichte Angaben zu Hardware, Auflösung oder Frame-Anzahl. Codec-Vorverarbeitung verlagert echte Arbeit auf die CPU und in ffmpeg; ein in Echtzeit gemessener Ende-zu-Ende-Gewinn auf der Maschine eines anderen ist die einzige Version dieser Zahl, mit der man planen sollte.

Zweitens: Serving-Unterstützung. Eine zusammengeführte vLLM- oder SGLang-Implementierung würde dies von einem Forschungs-Checkpoint in etwas verwandeln, das man hinter einen Load Balancer setzen kann. Das SGLang-Issue ist offen und nicht beansprucht; das ist der Thread, den man beobachten sollte.

Drittens: eine Auflistung in Azure AI Foundry, was signalisieren würde, dass Microsoft dies als Produkt und nicht als Paper betrachtet. Nichts in der aktuellen Version deutet darauf hin, dass dies unmittelbar bevorsteht.

Viertens, und am merkwürdigsten: ob Microsoft überhaupt etwas sagt. Ein technischer Bericht mit 23 Autoren, eine gepflegte Projektseite, ein gehostetes Demo-Space und ein zugehöriges generatives Modell vier Tage zuvor beschreiben kein Leak oder keinen Zwischenfall – sie beschreiben eine bewusste Forschungsveröffentlichung, die das Produkt-Megafon völlig übersprungen hat. Die Community füllte die Stille trotzdem, mit neun Quantisierungen und zwei Feinabstimmungen innerhalb von zehn Tagen.

Für die meisten Teams ist der richtige Schritt, das Paper zu lesen, nicht die Gewichte herunterzuladen. Die codec-native Idee ist die zentrale Erkenntnis, und sie ist übertragbar: Wenn das Wiederverwenden von Bewegungsektoren, die der Encoder bereits berechnet hat, wirklich eine Token-Reduktion von 75 % bei gleicher Genauigkeit bringt, wird diese Technik in Modellen mit Launch-Ankündigungen, Anbieterunterstützung und reproduzierten Benchmarks auftauchen. Wenn du heute kontinuierliches Video betreibst, sieht die Rechnung anders aus — klone das Repo, lass deine eigenen Clips durch beide Backends laufen und miss den Speedup selbst, denn im Moment wärst du der Erste.

Fragen, die sich tatsächlich zu stellen lohnen

Ist Mage-VL nur Qwen3-VL mit einem Microsoft-Label darauf?

Nein, auch wenn die Verwirrung verständlich ist. Der Sprachdecoder ist Qwen3-4B-Instruct-2507, unverändert verwendet — Microsoft hat kein neues LLM trainiert. Alles andere ist neu: Mage-ViT wurde von Grund auf vortrainiert, die codec-native Tokenisierung hat kein Gegenstück in Qwen3-VL, und das Streaming-Gate ist ein zusätzliches Modell mit einer halben Milliarde Parametern. Ein offenes Backbone wiederzuverwenden und das visuelle Frontend auszutauschen, ist eine legitime und zunehmend übliche Forschungsstrategie, und hier ist es auch das, was den direkten Vergleich interpretierbar macht. Wenn Sie Compliance-Anforderungen bezüglich der Herkunft des Modells haben, beachten Sie, dass die Abstammungslinie über Alibabas Qwen3-Gewichte verläuft, und prüfen Sie beide Lizenzen.

Heißt „3,5x schneller“ 3,5x günstiger im Betrieb?

Nicht zuverlässig. Die Angabe ist ein Wall-Clock-Speedup auf NExT-QA gegenüber gleichmäßigem Frame-Sampling, und Microsoft gibt sie mit „bis zu“ an. Zwei Dinge verwässern das in der Praxis. Codec-native Inferenz benötigt einen Vorbereitungsschritt — ffmpeg, ffprobe und den cv-preinfer-Schritt oder eine DCVC-RT-Neucodierung für den neuronalen Pfad —, der CPU-Zeit verbraucht, die eine naive Frames-Pipeline nicht verbraucht, und der in einer GPU-seitigen Messung nicht auftaucht. Und der Gewinn entsteht durch Token-Reduktion, skaliert also mit der Redundanz deines Videomaterials: Eine überwiegend statische Überwachungskamera sollte besser abschneiden als die angegebene Zahl, während schnell geschnittenes und bearbeitetes Video, bei dem sich fast jedes Patch ändert, schlechter abschneiden sollte. Miss es an deinen eigenen Clips.

Brauche ich spezielle Videodateien, um den Codec-Pfad zu verwenden?

Meistens nein, und das ist die angenehme Überraschung. Gewöhnliche MP4-Dateien sind bereits H.264 oder HEVC, also genau das, was das traditionelle Codec-Backend verarbeitet – die Bewegungsvektoren, die es benötigt, stecken bereits in der Datei, die Sie schon haben. Was Sie hinzufügen müssen, ist die Werkzeugkette: FFmpeg und ffprobe in Ihrem PATH sowie das Paket zur Codec-Vorbereitung. Das neuronale Backend ist die Ausnahme; DCVC-RT erwartet Videos, die mit diesem Codec kodiert wurden, Sie müssten also neu kodieren. Und das Plain-Frames-Backend bleibt als Fallback verfügbar, das sich wie jedes andere VLM verhält – das ist auch der ehrliche Weg, den Codec-Anspruch selbst per A/B-Test zu überprüfen.

Kann ich es kommerziell nutzen?

Die Lizenz gibt Apache-2.0 an, was kommerzielle Nutzung, Modifikation und Weiterverbreitung erlaubt. Das Repository sagt außerdem, dass die Modelle „nur für Forschungszwecke veröffentlicht“ werden. Diese beiden Aussagen weisen in unterschiedliche Richtungen, und diese Lücke wurde von niemandem bei Microsoft geklärt – was bei einer Veröffentlichung ohne Ankündigung, ohne Produktlisting und ohne Präsenz des Anbieters in den Repository-Diskussionen nicht überraschend ist. Wenn Geld von der Antwort abhängt, sollten Sie einen Anwalt damit beauftragen, beide Dokumente und die Abhängigkeitslizenzen zu lesen, anstatt sich allein auf das Lizenzabzeichen zu verlassen.