Von „KI-generierte Videos anschauen“ bis „die von KI generierten Welten selbst spielen“ – dazwischen liegt in Wahrheit eine Hürde namens „Echtzeit“.
Am 15. Oktober 2026 hat Kunlun Tech offiziell das weltweit erste große Videomodell-Spiel veröffentlicht, das auf einer einzelnen Consumer-Grafikkarte läuft: Matrix-Game 4.0. Matrix-Game 4.0 begründet ein neues Paradigma für Spielweltmodelle: Die Spiel-Engine verwaltet den Weltzustand und die Interaktionsregeln, während das Video-Generierungsmodell die detaillierten Bilder in Echtzeit darstellt. Es packt ein Echtzeit-Spielerlebnis mit 480p und 60 FPS in eine einzige NVIDIA RTX 5090; vom Drücken einer Taste bis zur Reaktion des Bildes beträgt die Latenz weniger als 150 Millisekunden. Matrix-Game 4.0 hat erstmals den vollständigen Kreislauf „Code generiert Spiellogik → Strukturbild liefert strukturelle Constraints → Videomodell rendert in Echtzeit“ durchlaufen und gibt damit der Spiele-Prototypenentwicklung, personalisierten Anpassung und UGC einen tatsächlich umsetzbaren technischen Weg. Das Projekt wurde gleichzeitig als Open Source veröffentlicht.
Open-Source-Adresse
Huggingface: https://huggingface.co/Skywork/Matrix-Game-4.0
I. Von einem Codeausschnitt zu einer spielbaren Welt – die vier Eckpfeiler von Matrix-Game 4.0
1. Echtzeit auf einer einzelnen Karte: Das „spielbare Videomodell“ verlässt das Labor
Die Echtzeit-Generierung von Spielbildern auf Consumer-Grafikkarten war lange ein Ziel, das schwer zu erreichen war – der Rechenleistungshunger von Video-Generierungsmodellen hielt sie lange in Multi-GPU-Clustern im Labor gefangen.
Die Antwort von Matrix-Game 4.0 ist eine Reihe harter Kennzahlen: Auf einer einzigen NVIDIA RTX 5090 läuft das Spiel bei 480p Auflösung mit 60 FPS; von der Tasteneingabe des Spielers bis zum ersten Bildrahmen beträgt die End-to-End-Latenz weniger als 150 Millisekunden; die stationäre Generierungsgeschwindigkeit eines einzelnen Denoising-Schritts erreicht 83 FPS, der Spitzenwert des Grafikspeichers liegt bei 18.5 GiB.
Diese Zahlen bedeuten, dass von Videomodellen angetriebene Spiele zum ersten Mal einen tatsächlichen Wert für lokale Bereitstellung und Echtzeit-Interaktion besitzen – es handelt sich nicht mehr um ein offline gerendertes Demo-Video, sondern um ein Spiel, das man vor dem Computer wirklich selbst bedienen kann.
2. Das neue Harness-Paradigma: Der Weltzustand wird wirklich „verwaltet“
Matrix-Game 4.0 definiert die Beziehung zwischen Videomodell und Welt neu: Ein Coding Agent (Programmier-Agent) baut durch Code ein leichtgewichtiges Spiel auf, die Engine agiert als „Schiedsrichter“, pflegt kontinuierlich den Weltzustand, führt die Interaktionsregeln aus und gibt Strukturbilder sowie dynamische semantische Bedingungen aus; das Videomodell fungiert als „Maler“ und verwandelt einfache Geometrie in reiche Bilder.
Durch die externen Constraints und die kontinuierliche Korrektur der Engine kann der Weltzustand dauerhaft gepflegt, die Spielregeln präzise definiert und das Gameplay in natürlicher Sprache umgeschrieben werden – das ist das Problem der Genie-Paradigmen, ob die Welt ernsthaft verwaltet wird, das nie wirklich gelöst wurde.
3. Daten, Training und Laufzeit verbinden: eine wiederverwendbare Engineering-Kette
Von der Erfassung von Strukturbild-Detailbild-Datenpaaren über dynamische semantische Annotation bis hin zu kontrollierbarem Videotraining, few-step autoregressiver Destillation und Echtzeit-Inferenz ziehen sich einheitliche geometrische und semantische Bedingungen durch die gesamte technische Kette.
Dieser Prozess bietet eine ingenieurtechnische Grundlage für neue Szenarien, neue Interaktionen und neue Spielweisen: Er reduziert die Abhängigkeit von der Erstellung detaillierter 3D-Assets, ermöglicht schnelle Entwicklung und Iteration von Spielprototypen und lässt „auch kleine Teams können Welten bauen“ vom Schlagwort zur Realität werden.
4. Veröffentlichung mit gleichzeitiger Open-Source-Freigabe: Damit Kreative wirklich „spielen“ können
Matrix-Game 4.0 wurde bei der Veröffentlichung gleichzeitig als Open Source freigegeben und stellt Forschern, Entwicklern und Kreativen eine wiederverwendbare technische Grundlage sowie anpassbaren Spielcode zur Verfügung. In Kombination mit dem Coding Agent können Kreative Szenen in natürlicher Sprache anpassen, Interaktionen gestalten und Gameplay entwerfen – und senken damit die Hürde für Forschung und Kreation auf die Höhe eines einzigen Prompts, sodass mehr Ideen zu Spielen werden, die man selbst erleben und kontinuierlich weiterentwickeln kann.
II. Drei grundlegende Stolpersteine: Warum Welten, in denen man „laufen“ kann, „keinen Spaß machen“
Blickt man auf die interaktiven Weltmodelle der vorherigen Generation zurück, lag das Problem nie an der Bildqualität – sie konnten bereits ausreichend schöne Szenen generieren. Die eigentlichen Stolpersteine verstecken sich auf einer fundamentaleren Ebene. Zerlegt man den Ansatz der vorherigen Generation, gibt es drei Probleme, die nie gelöst wurden.
1. Dem Weltzustand fehlt ein unabhängiger, verifizierbarer Pflege-Mechanismus
Ohne eine externe Engine, die einen expliziten Zustand pflegt, hängt das Fortbestehen von Szenen und Objekten hauptsächlich von der internen Repräsentation und dem historischen Gedächtnis des Modells ab. Das Modell kann sich „erinnern“, was es einmal gesehen hat, aber das bedeutet nicht, dass Entwickler den Zustand jedes Objekts präzise lesen, ändern und verifizieren können; ebenso lässt sich kaum sicherstellen, dass Charaktere und Ereignisse außerhalb des Sichtfelds stets gemäß den vorgegebenen Regeln weiterentwickelt werden.
2. Konsistenz bei langen Interaktionszeiten ist weiterhin schwer garantiert
Autoregressive Generierung hängt von den vorherigen Generierungsergebnissen ab, und lokale Abweichungen können sich durch kontinuierliche Interaktion ausbreiten und akkumulieren. Wenn Spieler lange erkunden, wiederholt zum selben Ort zurückkehren oder Objekte mehrfach das Sichtfeld betreten und verlassen, können Szenenstruktur, Objektidentität und Interaktionsergebnisse abdriften. Größere Kontexte und Gedächtnismechanismen können diese Probleme lindern, liefern aber keine spieltaugliche Garantie für langfristige Konsistenz.
3. Plausible Interaktionsbilder sind nicht dasselbe wie verlässliche Spielregeln
Das Modell kann visuelle Effekte wie das Öffnen von Türen, Kollisionen oder Angriffe erzeugen, aber ein vollständiges Spiel erfordert auch eine präzise numerische Abrechnung – Änderungen von Lebenspunkten, Item-Zugehörigkeit, Aufgabenfortschritt und Sieg-Niederlage-Bewertung. Diese Mechanismen müssen nicht nur „plausibel aussehen“, sondern auch von Entwicklern klar definiert, geändert und getestet werden können und über unterschiedliche Aktionen und lange Laufzeiten hinweg konsistent bleiben.
Alle drei Probleme verweisen im Grunde auf dieselbe Sache: Bestehende Ansätze legen die „Welt“ im Gedächtnis des Modells ab, während Spiele eine Welt benötigen, die gelesen, geändert und verifiziert werden kann.
Genau hier liegt der Ausgangspunkt für die Entscheidung von Matrix-Game 4.0 für das Paradigma „Code baut das Spiel, KI generiert die Bilder in Echtzeit“ – statt das Modell sich die ganze Welt mühsam merken zu lassen, gibt man der Welt lieber einen expliziten, wartbaren Träger.
III. Das neue Paradigma: Die Engine verwaltet die Welt, die KI malt die Welt
Die Lösung von Matrix-Game 4.0 besteht darin, dem Videomodell einen „Harness“ überzustülpen, der für die Pflege des Weltzustands zuständig ist – ein externer Spiel-Manager liefert räumliche Layout-Referenzen, verwaltet den Weltzustand und aktualisiert semantische Dynamiken, während das Videomodell diese Kontexte und Steuerbedingungen einheitlich empfängt und autoregressiv kurze, realistische Zukunftsbilder generiert.
Das gesamte System besteht aus drei Modulen mit klarer Arbeitsteilung:
Die Engine zeichnet auf, was in der Welt „wirklich geschieht“, und entscheidet, welche Ergebnisse die Aktionen der Spieler haben. Sie muss keine vollständige, hochdetaillierte Bildproduktion leisten, sondern beschreibt Straßen, Gebäude, Charaktere und interagierbare Objekte über vereinfachte geometrische Modelle und Szenenstrukturen; Zustände und Regeln wie Lebenspunkte, Inventar, Gravitation, Kollisionen und Missionsfortschritt werden durch Code explizit verwaltet und ausgeführt statt aus generierten Bildern erschlossen. Mit den Aktionen der Spieler aktualisiert die Engine die Welt fortlaufend und gibt strukturierte Bilder aus, die dem Videomodell Constraints für Szenenlayout, Objektbewegung und Kameraperspektive liefern. Selbst wenn ein Objekt den Sichtbereich verlässt, wird sein Zustand von der Engine gemäß den Spielregeln weiterverwaltet.
Der Programmier-Agent ist dafür zuständig, die kreativen Ideen der Spieler in ein lauffähiges Spiel umzuwandeln. Spieler können ihre Anforderungen in natürlicher Sprache äußern – vom Anpassen des Terrains und Platzieren von Objekten bis zum Ändern des NPC-Verhaltens oder Entwerfen neuer Spielmechaniken – und all dies wird in Szenenkonfigurationen und Spielcode umgesetzt. Ein Beispiel: „Lass Monster aus allen Richtungen heranstürmen“ bedeutet nicht nur, dass im Bild mehr Monster erscheinen, sondern erfordert auch die Implementierung von Spawnpositionen, Bewegungsarten, Angriffsverhalten und Sieg-/Niederlagebedingungen. Der Programmier-Agent kann auch bei der Definition der Semantik und des visuellen Stils einer Szene helfen: Dasselbe vereinfachte Gebäude kann als altes Haus am Meer oder als Geschäft in einer Zukunftsstadt festgelegt werden – diese Beschreibungen dienen als Textbedingungen, die zusammen mit den strukturierten Bildern die visuelle Generierung anleiten.
Das Videomodell wandelt die strukturierten Bilder in ein feines visuelles Erlebnis um: Unter Beibehaltung der Szenenstruktur und Bewegungsconstraints erzeugt es Materialien, Beleuchtung, Umgebungsatmosphäre und reichhaltige Detailmerkmale des Erscheinungsbilds und verringert so die Abhängigkeit von einzeln gefertigten, hochdetaillierten 3D-Assets. Es kombiniert die aktuellen Steuerungsbedingungen mit den historischen Bildern und generiert auf kausal-autoregressive Weise kontinuierlich; durch auf Echtzeit-Re-Rendering ausgerichtete Distanillation mit wenigen Schritten und Inferenzoptimierungen wird die Wartezeit zwischen der Spieleraktion und der Bildreaktion verkürzt.
Echtzeit-Ablauf: Spieleraktion → Engine aktualisiert den Weltzustand → Ausgabe strukturierter Bilder und Steuerungsbedingungen → Videomodell rendert in Echtzeit → Darstellung für den Spieler
Der Schlüssel dieses Ansatzes liegt darin, die Frage, wie das Spiel funktioniert, von der Frage zu trennen, wie es dargestellt wird: Der Code trägt die Regeln, die Engine verwaltet den Zustand, das Videomodell erzeugt die visuelle Darstellung. In Kombination mit der Kreativfähigkeit des Programmier-Agents ermöglicht Matrix-Game 4.0 mehr Menschen, mit deutlich geringeren Produktionshürden ihre Ideen in spielbare, veränderbare und kontinuierlich iterierbare Spiele zu verwandeln.
IV. Von den Daten bis zur Inferenzbeschleunigung: Eine vollständig durchgängige Kette
Eine in Echtzeit lauffähige „Spielwelt“ beruht darauf, dass drei Ebenen – Daten, Training und Laufzeit – zusammengeführt werden.
Daten: Ein strukturierte Bilder – feine Bilder-Ausrichtungsdatensatz für Weltmodelle
Das Team hat auf Basis der Unreal Engine 5 (UE5) einen strukturfein-Bild-übergreifenden Ausrichtungsdatensatz für Weltmodelle und Videoerzeugung aufgebaut, der vier typische Szenen abdeckt: die Megacity CitySample, offene Wüste, eine komplexe Burg und hochdynamische Luftkämpfe.
Die selbst entwickelte, leichtgewichtige Erfassungspipeline für geometrische Abstraktion abstrahiert komplexe Szenen – unter strikter raum-zeitlicher Synchronisation von Kamerapfaden und Zeitstempeln – in eine Low-Poly-Strukturrepräsentation, die räumliche Topologie, Starrkörperposen und dynamische Trajektorien bewahrt, und richtet sie bildweise pixelgenau mit hochauflösenden filmreifen Bildern aus; zugleich werden Objekt-Instanz-IDs, Sichtbarkeitszustände und kausale Interaktionsereignisse parallel erfasst, um einen semantisch reichen Strom dynamischer Metadaten aufzubauen.
Dynamisches Caption: Damit die Beschreibung mit dem Spiel mitgeht
In interaktiven Spielen verändert sich das Bild ständig durch die Aktionen der Spieler: Nach dem Drehen der Perspektive sind andere Objekte sichtbar, und nach Bewegungen oder ausgelösten Ereignissen ändert sich auch der Zustand der Objekte. Feste Textbeschreibungen können diese Veränderungen nur schwer rechtzeitig widerspiegeln.
Matrix-Game 4.0 führt dynamische Captions ein: Das System verknüpft die IDs der Objekte in der Szene mit semantischen Beschreibungen, ruft vom Spiel-Engine die aktuell sichtbaren Objekte und deren Echtzeitzustände ab und füllt sie zur Laufzeit in eine Prompt-Vorlage ein. Die strukturierten Bilder liefern Strukturinformationen wie Position, Layout und Bewegung, die Caption ergänzt semantische Informationen wie „welche Objekte sich im Bild befinden und in welchem Zustand sie sind“ – gemeinsam schränken beide die Generierung ein.
Kontrollierbare Generierung und räumliches Gedächtnis
Das Videomodell wurde auf Basis von Wan2.2 5B in einen Video-zu-Video-Modus (V2V) umgebaut: Das von der Engine gerenderte strukturierte Bild wird mit dem zu generierenden Video kanalweise zusammengefügt (148-Kanal-Eingabe) und teilt dem Modell mit, „was es zeichnen soll und wo“; gleichzeitig werden dynamisch zusammengesetzte Szenenereignis-Prompts, eine Referenz für das räumliche Gedächtnis und der erste Frame eingegeben, die jeweils für Detailbeschreibung, Szenenkonsistenz und Bildübergang zuständig sind.
Netzwerkstruktur des Rendering-Modells: 148-Kanal-Eingabe per Concatenation, 30 Schichten kausaler DiT, Self-Attention liest den K/V-Cache, Cross-Attention liest Text-K/V
Inferenzbeschleunigung: Jede Millisekunde herausholen
Damit 60 FPS auf Consumer-Grafikkarten wirklich realisierbar werden, hat das Team umfangreiche Engineering-Optimierungen vorgenommen: Die DiT-Hauptberechnungen werden mit CUDA Graph vorab aufgezeichnet und zur Laufzeit in einem Durchlauf abgespielt; für RoPE, Normalisierung und FP8-Quantisierung wurden fusionierte spezielle GPU-Kernel geschrieben, wobei Q, K und V derselben Schicht eine gemeinsame Eingabequantisierung nutzen; die KV der Textbedingungen werden nur bei Caption-Updates neu berechnet; der Video-Historien-KV wurde auf einen Ringpuffer umgestellt; die Self-Attention wird nach Aufteilung in KV-Fenster parallel berechnet; für Encodierung und Dekodierung wird das leichte TAEHV verwendet. Am Ende können Text-Encoder, DiT und VAE vollständig auf einer einzigen RTX 5090 dauerhaft geladen bleiben.
V. Coding Agent: Mit einer Idee ein Spiel umschreiben
Der spannendste Aspekt von Matrix-Game 4.0 ist vielleicht nicht, wie gut es malt, sondern wie leicht es sich „verändern“ lässt.
Mit Hilfe des Programmier-Agents (Coding Agent) können Spieler auf Grundlage des vorhandenen Spielcodes ihr Spiel in natürlicher Sprache anpassen: vom Verändern des Terrains und Platzieren von Szenenobjekten über das Ändern des Verhaltens und der Interaktionslogik von NPCs bis hin zum Entwerfen völlig neuer Spielmechaniken.
Kreativität bleibt nicht mehr auf dem Fließband der 3D-Asset-Produktion stecken, sondern kann direkt in die „spielbare, iterierbare“ Phase eintreten.
Das ist auch die praktische Bedeutung dieses technischen Wegs: Mit dem raschen Fortschritt von KI-Programmierassistenten sind die Kosten für den Aufbau eines leichtgewichtigen Spiel-Engine bereits stark gesunken. Wir ermutigen Kreative auch, auf dem vom Projekt bereitgestellten Spielcode aufzubauen, ihn weiter umzubauen und zu erweitern und gemeinsam weitere Spielmechaniken zu erkunden.
Im vergangenen Jahr haben Videogenerierungsmodelle beim Spielen von Spielen viele neue Erfolge erzielt – aber ob sie sich auch auf dem Rechner eines gewöhnlichen Spielers ausführen lassen, ist eine andere Frage.
Aus diesem Vergleichsbild geht hervor: Bei der End-to-End-Latenz erreicht Code World Model etwa 10.2 Sekunden, StreamRender-H3 etwa 545 Millisekunden, AgentGarten etwa 878 Millisekunden, während Matrix-Game 4.0 nur 112 Millisekunden benötigt – vom Drücken einer Taste bis zur Bildreaktion sind dies etwa 1/90 des Ersteren bzw. 1/5 und 1/8 der beiden Letzteren, womit erstmals wirklich der Bereich „Echtzeit-spielbar“ erreicht wird.
Beim Rechenleistungsbedarf benötigen die anderen Lösungen jeweils 1× H200 141GB, 8× GB200 bzw. 1× H100 Datacenter-Karten, während Matrix-Game 4.0 nur auf 1× RTX 5090 läuft – einer Consumer-Grafikkarte mit 32GB Videospeicher genügt.
Beim Open-Source-Status sind Code World Model und StreamRender-H3 vollständig offen, AgentGarten teilweise offen, während Matrix-Game 4.0 Code, Gewichte und Whitepaper gleichzeitig offenlegt.
VI. Open Source, damit mehr Menschen gemeinsam „spielen“
Matrix-Game 4.0 wird mit der Veröffentlichung gleichzeitig als Open Source bereitgestellt und bietet Forschern, Entwicklern und Kreativen eine wiederverwendbare technische Grundlage sowie anpassbaren Spielcode. Wir ermutigen Kreative auch, auf dem vom Projekt bereitgestellten Spielcode aufzubauen, ihn weiter umzubauen und zu erweitern und gemeinsam weitere Spielmechaniken zu erkunden.
Zukünftig wird das Team das Modell kontinuierlich weiterentwickeln: einen Refiner zur Erhöhung der Bildauflösung einsetzen, Multiplayer-Erlebnisse mit konsistenter Perspektive über mehrere Spieler hinweg erforschen, feingranularere Bildsteuerung bieten und die Unterstützung für weitere Spielgenres und Szenarien ausbauen.
Vom „steuerbaren Video“ zur „laufenden Welt“ – dieser Schritt ist vielleicht wichtiger, als er aussieht. Er bedeutet, dass die Schwelle für Kreativität sinkt und die Grenzen der Vorstellungskraft sich öffnen.