1 Punkte von GN⁺ 2024-11-03 | 1 Kommentare | Auf WhatsApp teilen
  • Damit generatives Video in Echtzeit wie ein Spiel auf Eingaben reagieren kann, ist die Geschwindigkeit der Frame-Erzeugung entscheidend; Oasis wurde mit dem Ziel einer interaktiven AI World mit 20 fps vorgestellt
  • Decart und Etched zeigen eine Open-World-Erfahrung, bei der Physik, Regeln und Grafik nicht von separaten Engines, sondern als Ausgabe eines Foundation Models erzeugt werden
  • Die Veröffentlichung umfasst eine Live-Demo, Code, lokal ausführbare Modellgewichte mit 500M Parametern sowie eine Demo auf Basis eines größeren Checkpoints
  • Die Architektur besteht aus einem Transformer-basierten räumlichen Autoencoder und einem Latent-Diffusion-Backbone; Frames werden autoregressiv passend zu den Nutzereingaben erzeugt
  • Unschärfe in der Ferne, zeitliche Konsistenz von Objekten, Domain-Generalization, Inventarsteuerung und der Umgang mit langem Kontext bleiben noch Grenzen; nötig sind Skalierung von Modell und Datensatz sowie Verbesserungen bei der Inferenz

AI World, die auf Eingaben reagiert

  • Oasis ist ein von Decart und Etched vorgestelltes Echtzeit-Open-World-KI-Modell
  • Es nimmt Tastatureingaben des Nutzers entgegen und erzeugt interaktive Erfahrungen wie Bewegung, Springen, das Aufnehmen von Items und das Zerstören von Blöcken
  • Physik, Regeln und Grafik sind in der Modellausgabe enthalten; die Erfahrung wird allein mit einem Foundation Model ohne separate Physik-Engine aufgebaut
  • Die veröffentlichten Ressourcen sind:
  • Ergebnisbeispiele umfassen Bauen, Lichtphysik, Inventarverwaltung, Objektverständnis, Interaktionen mit Tieren, Regeneration von Gesundheit beim Essen sowie eine schnellere Aktion mit der Schaufel als mit der Hand
  • Zu den erzeugbaren Umgebungen gehören dunkle, weltraumartige Orte, Nachtszenen, verschiedene Objektanordnungen, das Öffnen von Inventarkisten sowie Tiere und Charaktere
  • Auch Erweiterungen zur Steuerung der Erfahrung über Text, Audio und andere Modalitäten sind möglich

Transformer-Architektur und Echtzeit-Inferenz

  • Das Modell besteht aus einem räumlichen Autoencoder und einem Latent-Diffusion-Backbone
    • Beide Komponenten basieren auf Transformern
    • Der Autoencoder basiert auf ViT, der Backbone auf DiT
    • Anders als action-konditionierte World Models wie GameNGen oder DIAMOND wurde ein Transformer gewählt, weil er stabil und vorhersehbar skaliert und schnelle Inferenz auf Etcheds Transformer-ASIC Sohu ermöglicht
  • Anders als bidirektionale Modelle wie Sora erzeugt Oasis Frames autoregressiv
    • Jeder Frame kann auf Nutzereingaben konditioniert werden, was Echtzeitinteraktion ermöglicht
    • Beim Training wird Diffusion Forcing verwendet, bei dem mit unabhängigen Rauschpegeln pro Token entrauscht wird
  • Eine zentrale Herausforderung war die zeitliche Stabilität, damit die Ausgabe über längere Zeit natürlich bleibt
    • In autoregressiven Modellen akkumulieren sich Fehler, und kleine Defekte können zu Glitch-Frames anwachsen
    • Um das zu reduzieren, wird bei der Inferenz dynamic noising eingesetzt, bei dem das Rauschen nach einem Zeitplan angepasst wird
    • In frühen Diffusion-Forward-Passes wird Rauschen injiziert, um Fehlerakkumulation zu verringern; in späteren Passes wird das Rauschen schrittweise entfernt, um hochfrequente Details früherer Frames zu erhalten

20-fps-Leistung und Hardware-Engpässe

  • Oasis erzeugt Echtzeitausgaben mit 20 fps
    • Text-zu-Video-Modelle mit ähnlicher DiT-Architektur wie Sora, Mochi-1 und Runway können selbst auf mehreren GPUs 10 bis 20 Sekunden benötigen, um ein einsekündiges Video zu erzeugen
    • Für Echtzeitinteraktion muss alle 0,04 Sekunden ein neuer Frame erzeugt werden, also mehr als 100-mal schneller
    • Mit Decarts Inferenz-Stack ist die Ausführung mit Live-Framerate möglich
  • Für schnellere und kosteneffiziente Ausführung im großen Maßstab ist neue Hardware nötig
    • Oasis ist für Etcheds Transformer-ASIC Sohu optimiert
    • Sohu kann bis zu 100B+-Next-Generation-Modellen mit 4K-Auflösung skalieren
    • Die End-to-End-Transformer-Architektur von Oasis ist auf Sohu effizient und kann auch bei Modellen mit 100B+ Parametern mehr als 10-mal so viele Nutzer bedienen

Noch bestehende Grenzen

  • Unschärfe bei entfernten Bildern, unsichere zeitliche Konsistenz von Objekten, Domain-Generalization, präzise Inventarsteuerung, präzise Objektsteuerung und begrenzter Speicher über lange Zeiträume bleiben Einschränkungen
  • Nach Sensitivitätsanalysen zu Architekturaufbau, Daten und Modellgröße lautet die Hypothese, dass sich viele Probleme durch Skalierung von Modell und Datensatz lösen lassen
  • Auch bei der Entwicklung größerer Modelle sind neue Inferenztechniken nötig, um Latenz und Kosten im Gleichgewicht zu halten

1 Kommentare

 
GN⁺ 2024-11-03
Hacker-News-Kommentare
  • Wenn man in Minecraft träumen würde, dürfte es sich ungefähr so anfühlen.
    Wegen der fehlenden Objektpersistenz fühlt es sich wirklich wie ein Traum an. Auch die Beleuchtungsstufen sind interessant: Wenn man lange in einen dunklen Bereich schaut oder „unter Wasser“ gerät und der Bildschirm schwarz wird, ist es schwierig, aus einem anderen Zustand als einem schwarzen Bildschirm zurückzukommen. In einem Durchlauf ist mir das nicht gelungen. Ein ziemlich seltsames Gefühl.

  • Ich bin mir nicht sicher, wie man auf diese Weise ein Spiel entwerfen und veröffentlichen soll. Man kann die Modellgewichte nicht direkt so einstellen, dass man damit ein Spiel designt.
    Vielleicht kann man irgendwann Spiele ohne die fehlenden Elemente wie Objektpersistenz oder langfristigen Zustand replizieren, aber vermutlich kostet der Betrieb der Inference-Engine mehr als die Game-Engine, die sie nachahmt. Als jemand, der schon lange im Bereich AI arbeitet, frage ich mich wirklich, wofür diese Technik nützlich ist.

    • Genau. Deshalb ist das zentrale Ziel des nächsten Modells, an den Punkt zu kommen, an dem man per Prompt neue Welten „coden“ kann.
      Ich stimme zu: Diese Tools werden erst dann enorm nützlich, wenn Creators auf diesem System neue Welten oder Spiele „entwickeln“ können und Nutzer sinnvoll mit diesen Welten interagieren können. Letztlich muss es eine „API“ wie bei einer Game-Engine bereitstellen. Creators erschaffen Welten, Nutzer interagieren mit ihnen. Wenn AI diese Rolle tatsächlich übernehmen kann, dann 1) könnte es viel einfacher werden, Welten und Spiele zu erschaffen, indem man einfach sagt: „Füge hier einen fliegenden rosa Elefanten hinzu“, und 2) es werden wirklich unendliche Welten möglich, weil Nutzer mit Welten interagieren können, die sich an jede Spielsitzung anpassen. Sind wir schon so weit? Natürlich nicht. Oasis v1 ist der erste Proof of Concept; wartet einfach noch ein bisschen auf v2 ;)
    • Natürlich wird dieses Tool nicht sofort releasefähige Spiele erzeugen. AI ist davon noch weit entfernt.
      Aber aus „Design“-Sicht ist es nicht schwer zu erkennen, wie nützlich es sein könnte, Spiele schnell zu prototypisieren, selbst wenn dafür massiv GPU-Leistung benötigt wird. Solche Papers sind nur Trittsteine in diese Richtung.
    • Die visuellen Artefakte haben mich gestört. Ich frage mich, ob schon einmal jemand Game-Engine-Ausgaben vor der Rasterisierung trainiert hat, etwa Meshes/Materialien, Kamera oder rohe OpenGL-Calls.
      Eine AI, die Eingaben für einen echten Renderer oder eine Engine erzeugt, könnte das Problem der visuellen Wiedergabetreue lösen.
    • Ich halte das für machbar. Man muss nur denselben Ansatz, den man bei AI-Bildern verwendet hat, auf Videospiel-Weltmodelle anwenden.
      Mehrere Modelle zusammenführen, Teile der jeweiligen Spiel-„Weltmodelle“ nehmen und kombinieren – das käme fast der Erschaffung eines völlig neuen Spiels gleich. Fehlende Elemente wie Objektpersistenz oder langfristiger Zustand ließen sich über eine deutlich kleinere Menge an Variablen hinzufügen. Da bereits das gesamte vorherige Frame und die Nutzereingabe in die Gewichte einfließen, sehe ich keinen Grund, warum man nicht auch einen vereinfachten Spielzustand mit einspeisen könnte.
    • Man könnte wohl einen Film wie Avatar nehmen und daraus eine einigermaßen interaktive Erfahrung machen.
  • Es heißt „vollständig von AI generiertes Videospiel“, aber als ich die Webseite mit Ctrl-F durchsucht habe, kam Minecraft nullmal vor. Keine Ahnung, warum.
    Das ist kein Videospiel, sondern eine grobe Kopie eines echten Videospiels – ohne sich auch nur die Mühe zu machen, den Namen zu nennen oder Credits zu geben.

    • Sieht nach einem interessanten Versuch aus, rechtliche Probleme zu umgehen.
      „Minecraft“ können sie wohl nicht sagen, weil es eine Marke von Microsoft ist, aber Minecraft-Bilder als Trainingsdaten zu verwenden, halten sie offenbar für möglich. Schließlich trainieren alle, auch Microsoft, Diffusionsmodelle mit proprietären Daten. Das Problem ist, dass der Output offensichtlich nach Minecraft aussieht; aber Microsoft hat mit Bing und DALL-E ebenfalls das Problem, dass trotz Schutzmechanismen Bilder erzeugt werden, die offensichtlich markenrechtlich geschützten Dingen ähneln.
    • Im zweiten Absatz des Architecture-Abschnitts taucht Minecraft tatsächlich einmal auf: „...We train on a subset of open-source Minecraft video data collected by OpenAI[9].“
      Ich weiß nicht, ob das nach dem ursprünglichen Kommentar hinzugefügt wurde.
    • Seltsam. Besonders im Vergleich zu https://diamond-wm.github.io/, wo Counter Strike ausdrücklich erwähnt wird.
      Wenn wissenschaftliche Arbeit ein Werk nutzt und keine Credits gibt, ist das wissenschaftliche Unredlichkeit. Man hätte auch mit einem anderen Datensatz trainieren können, aber welche Quelle auch immer verwendet wurde, sie muss zitiert werden.
    • Es ist merkwürdig, so zu tun, als könne das Modell jede beliebige Umgebung erzeugen, während die Demo nur das Spiel zeigt, für das es die meisten Daten gibt.
  • Wirklich cool, und es ist schön zu sehen, wie sich solche Modelle weiter schnell verbessern. Ich frage mich allerdings, wie Langzeitzustand funktionieren soll.
    Zum Beispiel: eine Basis bauen und später dorthin zurückkehren, durch klassischen Code erzwungene Spielregeln, Multiplayer, gespeicherte Spielstände laden – ich weiß nicht, wie ein solcher geleiteter Zustand behandelt würde. Grundsätzlich sind externer Zustand und Speicher/Simulation etwas anderes, daher wird es vermutlich nicht einfach damit getan sein, das Kontextfenster zu vergrößern oder das Modell größer zu machen. Helfen würde es natürlich schon. Jedenfalls werden solche Modelle wohl bald zur zielgerichteten Aufgabenimagination eingesetzt. Etwa bei einem Agenten, der auf einem Computer ein bestimmtes Bild finden muss und fortlaufend den Pfad zwischen dem aktuellen gesehenen Zustand und dem gewünschten Zustand imaginiert. Dieses Modell nimmt Nutzereingaben entgegen, aber ein solcher Agent würde auch diese Eingaben imaginieren. Soweit ich es verstehe, passiert Ähnliches in einigen Robotik-Steuerungsnetzen bereits ohne Pixel.

    • In dieser Demo gibt es kaum auch nur Spuren von Zustand. Wenn man eine volle Umdrehung lang „nach links drehen“ gedrückt hält, kommt man nicht wieder am Ausgangspunkt an.
      Nach ein paar Umdrehungen verschwinden die Details, und man bleibt mitten in einem leeren Ozean zurück. Mit dieser Technik scheint es unmöglich, auch nur eine spielbare Version von Mario zu bauen, geschweige denn Minecraft.
  • Das ist kein Videospiel, sondern eher ein schneller Minecraft-Screenshot-Simulator, bei dem der Prompt zwischen den einzelnen Frames aus dem Eingabestatus und dem vorherigen Frame besteht.
    Eine gewisse Art von Konsistenz gibt es schon.

  • Im Grunde wurde das Modell auf Minecraft trainiert. Es ist überhaupt nicht generisch.
    Das Spiel stammt wahrscheinlich nicht aus dem Prompt, sondern aus einem großen Datensatz von Minecraft-Gameplay und Fine-Tuning. Ich würde gern solche Arbeiten sehen, bei denen Welten oder Spiele aus Prompts entstehen.

    • Warte einfach auf das bald kommende Oasis v2 :)
      Zur Einordnung: Ich gehöre zum Oasis-Team.
  • Wenn man Nutzer während des Spielens direkt in den Framebuffer zeichnen lassen und das wieder als Eingabe einspeisen würde, könnte etwas ziemlich Interessantes entstehen.

    • Minecraft von Hand zu zeichnen ist wirklich schwierig, also würde das vermutlich ziemlich stark kaputtgehen.
  • Die Warteschlange war zu lang, also habe ich aufgegeben. Ich frage mich, ob das Modell die Pixel selbst erzeugt oder nur die Umgebung generiert und sie dann auf „traditionelle“ Weise gerendert wird.

    • Wenn es eine Umgebung erzeugt, die traditionell gerendert wird, gäbe es wahrscheinlich Objektpersistenz, statt dass nach einem kurzen Wegschauen wieder etwas Neues generiert wird: https://oasis-model.github.io/3_second_memory.webp
    • Alle Pixel werden generiert. Nutzeraktionen gehen hinein, Pixel kommen heraus, und dazwischen steckt nur ein Transformer :)
      Warum das interessant ist? Stand heute ist es vielleicht noch nicht besonders interessant. Oasis v1 ist nur ein Proof of Concept. Aber wenn man an die Zukunft denkt, an die nächsten Oasis-Versionen, die buchstäblich in ein paar Monaten kommen, kann man sich eine Situation vorstellen, in der alle sichtbaren Pixel generiert werden – einschließlich der Pixel, die ihr gerade beim Lesen dieser Nachricht seht. Das ist eine neue Kommunikationsschnittstelle zwischen Mensch und Maschine. Wenn LLMs im Chat deshalb interessant sind, weil sie Mensch und Maschine in einer für Menschen vertrauten Form – dem Gespräch – interagieren lassen, dann wird es hier möglich, dass Computer die Welt so sehen, wie wir sie sehen, und sie uns wieder auf eine für uns vertraute Weise zeigen. Kurz gesagt: Man kann sich vorstellen, dem Computer zu sagen: „Erzeuge einen rosa Elefanten“, und er erscheint direkt in dem Spiel, das man gerade spielt.
    • Es erzeugt Pixel, einschließlich der verschwommenen UI am unteren Rand.
  • Vielleicht sollte man ein Modell auf Mario-Spiele trainieren, damit Nintendo für einen „guten Zweck“ kämpft.