Как мы за $2k собрали управляемую мировую модель на базе Wan 2.1

Всем привет! Мы два 19-летних студента второго курса из Казахстана. В свободное от учёбы время мы развиваем DreamForge — собственный исследовательский проект в области интерактивных мировых моделей.

Несколько лет мы с другом занимались инди‑разработкой игр и Minecraft модов. Один из этих модов со временем набрал миллионы загрузок и начал приносить достаточно денег, чтобы финансировать наши эксперименты с облачными GPU.

Получилась довольно странная технологическая пищевая цепочка:

мод, ускоряющий запуск Minecraft → аренда GPU → нейросеть, генерирующая управляемые игровые миры.

Так появился DreamForge‑World 0.1 Preview, экспериментальная мировая модель, которая в реальном времени генерирует визуал, принимает управление с клавиатуры и мыши и использует собственные предыдущие кадры как контекст для следующего шага.

Модель работает с перспективами от первого и третьего лица, поддерживает T2V, I2V, V2V или микс этих модальностей (TI2V, VI2V), позволяет менять промпт во время генерации и достигает 14–15 FPS при разрешении 480р на одной RTX 4090.

В посте разберём:

• почему обычную text‑to‑video модель нельзя просто запустить в бесконечном цикле;

• как мы использовали Wan 2.1 и LongLive в качестве основы;

• как переносили управление из Matrix‑Game;

• зачем потребовались отдельные модули для первого и третьего лица;

• как удалось получить реал‑тайм инференс на потребительской видеокарте;

• и почему модель всё ещё забывает ^[1] собственный мир.

---

Что именно мы называем мировой моделью (world model)

Термин world model сейчас используется довольно широко, поэтому сначала зафиксируем границы.

DF‑World 0.1 это action‑conditioned визуальный предиктор, работающий в замкнутом авторегрессионном цикле:

1. модель получает визуальную историю;

2. принимает действия пользователя;

3. предсказывает следующее состояния мира;

4. декодирует это в кадры;

5. использует сгенерированный результат как часть контекста для следующего шага.

Это принципиально отличается от обычной генерации заранее ограниченного видео. Здесь пользователь может изменить направление движения или камеры, а модель должна продолжить сцену с учётом этого действия.

При этом DF‑World 0.1 не является скрытым игровым движком. Внутри нет системы мешей, физического мира, ECS, точной карты объектов или надёжного 3д состояния. Модель предсказывает наблюдаемое изображение мира, а не симулирует его через явно заданные правила.

Из‑за этого она умеет генерировать правдоподобное движение вперёд, но пока не гарантирует, что дерево, находившееся за спиной игрока десять секунд назад, останется на том же месте после разворота.

---

Где DF‑World находится среди других мировых моделей

За последние два года направление прошло путь от узких демонстраций до моделей, способных поддерживать интерактивный визуальный мир в реальном времени.

Важно уточнить: LongLive сам по себе ближе к инфраструктуре для интерактивной длинной видеогенерации, чем к законченной управляемой мировой модели. Он умеет продолжать видео покадрово и менять промпт прямо во время генерации, но не содержит готового механизма управления мышью и клавиатурой.

Matrix‑Game 2.0, наоборот, уже содержал контроль‑пути, но его модель и runtime были спроектированы вокруг другого набора компромиссов. В частности, Matrix‑Game полностью убирает текстовую ветку и концентрируется на image‑to‑video интерактивной генерации; другими словами, модель принимает на вход только изображения, без промпта, отнимая большой рычаг влияния на состояние мира.

Поэтому мы не взяли один проект целиком. Мы использовали LongLive как хорошую видео‑основу, а Matrix‑Game как источник хорошей реализации контроля.

В общей области мировых моделей, DF‑World 0.1 занимает довольно скромную, но на наш взгляд, практически интересную точку: широкое покрытие функций, включая: текст, изображения, видео, репромптинг, два режима камеры, при минимальном бюджете адаптации и запуске на потребительском GPU.

---

Почему нельзя просто зациклить видеогенератор

На первый взгляд задача кажется простой: Генерируем несколько кадров, затем передаём последний кадр обратно модели; Повторяем ^[10].

На практике такой цикл быстро разваливается.

При обычной генерации видео модель получает сравнительно чистый исходный контекст. В авторегрессионном режиме она начинает обучаться на собственных ошибках уже во время инференса: небольшой дефект в одном фрагменте становится частью контекста следующего фрагмента.

Ошибки ^[11] начинают накапливаться:

• текстуры становятся более гладкими;

• цвета постепенно перенасыщаются;

• объекты меняют форму;

• геометрия сцены перестраивается;

• управляющее действие может конфликтовать с визуальной динамикой;

• резкие движения камеры повреждают весь последующий rollout.

Это принято называть error accumulation или autoregressive drift. Кроме того, традиционная text‑to‑video модель не обязана понимать соответствие между нажатием W и движением камеры вперёд. Для этого нужен отдельный способ передачи действий и обучение ^[12] на видео, синхронизированных с переферией (мышь+клавиатура)

Поэтому система потребовала не только дообучения модели, но и полноценного causal (причинного) авторегрессивного пайплайна: управления историей, KV‑кэшем, декодированием, потоком действий и повторным использованием ранее сгенерированных состояний.

---

Архитектура DF‑World 0.1

Упрощённо runtime состоит из трёх связанных потоков:

1. Состояние мира. Текст, изображение или видео задают начальный контекст. Изображение и видео кодируются в latent space Wan VAE и помещаются в начало авторегрессионной истории.

2. Управление. Клавиатура и мышь кодируются action‑модулем, затем модуль «изменяет» процесс видео‑генерации внутри DiT, чтобы задать необходимое движение камеры/пространства.

3. Генерация. LongLive предсказывает следующие кадры, VAE декодирует их в изображение и эти новые кадры возвращаются в историю для следующего шага.

---

Первый этап: адаптация видео модели

Сначала мы обучили rank-64 LoRA поверх LongLive без action‑модуля.

Так как LongLive имел сильный bias на стоковые кинематографичные видео, целью этого этапа было не научить модель управлению, а сместить специализацию в сторону интерактивных сцен и моделлирования мира:

• first‑person gameplay;

• third‑person gameplay;

• открытые локации;

• движение камеры;

• персонажи и объекты, характерные для игровых окружений.

В тренировочный сет вошли материалы из датасетов NitroGen, GameGen‑X/Open‑World Video Game Dataset, а также из меньшего, вручную собранного набора более качественных роликов.

И первое, и третье лицо использовались в связке во время обучения. Режим камеры задавался в промпте, например токенами first person и third person.

Эта LoRA ещё не позволяла управлять моделью, но делала следующий этап значительно проще: action‑модулю не приходилось одновременно учить и игровую визуальную динамику, и реакцию ^[13] на команды с периферии.

---

Второй этап: управление клавиатурой и мышью

Главная проблема action conditioning заключается в том, что одно и то же действие выглядит совершенно по‑разному с разными режимами камеры.

Например, нажатие W в первом лице обычно вызывает движение камеры вперёд; а в третьем лице должно переместить персонажа, изменить его анимацию, сделать параллакс окружения и иногда скорректировать внешнюю камеру.

Попытка заставить один небольшой контроллер устойчиво моделировать обе зависимости привела бы к конфликтам между действием и наблюдаемым результатом, и сильно бы усложнила обучение.

Поэтому контроль был разделён на две ветки:

• отдельный чекпоинт для first‑person view;

• отдельный чекпоинт для third‑person view.

Датасет контроля

Вручную собранная часть датасета состояла из пятиисекундных клипов при 24 FPS.

Для каждого клипа сохранялись:

• непрерывные движения мыши;

• перемещение;

• прыжок;

• спринт;

• приседание;

• взаимодействие;

• две дополнительные action‑кнопки;

• тип камеры.

Всего во всех стадиях адаптации использовалось около 64 часов отфильтрованного видео (включая наш собственный датасет и несколько open‑source источников, упомянутых ранее). Наша часть датасета в основном фокусировалась на связи контроля и видео для третьего лица (TPV), так как существующие датасеты недобирали хороших TPV сэмплов.

Перенос action‑модуля

Вместо обучения собственного модуля полностью с нуля, мы перенесли веса action‑модуля, основанного на архитектуре Matrix‑Game 2.0, поверх LongLive DiT. Такой перенос был возможен во многом за счет использования одной и той же видео модели и LongLive, и Matrix‑Game 2 — Wan 2.1 1.3B.

После переноса потребовалось короткое дообучение/файнтюн, чтобы:

• уменьшить ошибку несоответствия весов;

• согласовать паттерны контроля внутри новой модели;

• адаптировать модуль к нашим данным и runtime;

• восстановить устойчивое влияние команд на видео‑генерацию.

Поверх перенесённого action‑модуля затем обучались две высокоранговые LoRA, одна для first‑person и другая для third‑person режимов.

В качестве лоссов использовались MSE и trajectory/pose лоссы. Depth Anything 3 использовался для генерации pose данных из нашего датасета.

После обучения, LoRA сливались с исходными весами action‑модуля, формируя два отдельных чекпоинта, между которыми runtime переключается до начала генерации, в зависимости от выбранного режима камеры.

---

Инициализация из изображения и видео

LongLive 1 изначально был text‑to‑video системой. Он поддерживал продолжительную авторегрессионную генерацию и переключение промптов, но не предоставлял нам готовый интерфейс для генерации видео из произвольного изображения или клипа.

Мы реализовали это через latent history conditioning.

Изображение

Входное изображение:

1. кодируется через Wan VAE;

2. вставляется в начало KV кэша, будто модель сама сгенерировала этот отрезок истории;

3. используется моделью как стартовое состояние мира.

После этого пользователь может управлять миром через клавиатуру и мышь.

Видео

Видеофрагмент аналогично кодируется в последовательность латент‑кадров и становится начальной историей.

Модель получает уже существующую динамику сцены и продолжает её авторегрессионно под управлением пользователя.

Так один runtime поддерживает:

• text‑to‑world;

• image‑to‑world;

• video‑to‑world;

• смешанную инициализацию;

• динамическое изменение мира во время активного стрима.

---

Runtime: где на самом деле теряется FPS

Высокая скорость DiT сама по себе ещё не означает интерактивную систему.

В финальный пайплайн входят:

• цикл DiT;

• action conditioning;

• управление KV кэшем;

• VAE декодинг;

• передача кадров;

• приём управляющих событий;

• синхронизация генерации и отображения.

Если генерировать латент‑кадры быстро, но затем последовательно ждать тяжёлый VAE, пользователь всё равно получит медленный интерфейс.

Поэтому вокруг LongLive runtime мы добавили:

• асинхронный стриминг генерации и декодирования;

• квантизацию KV кэша;

• квантизацию DiT;

• адаптировали Deep Forcing training‑free метод для уменьшения накопления ошибки во время длинных непрерывных сессий;

• альтернативный облегчённый VAE.

Мы измеряли не изолированную скорость трансформера (как например авторы LongLive и некоторых других проектов), а наблюдаемую скорость полного runtime, включая DiT, время на VAE декодинг и задержки в стриминге/отображении.

Результаты на RTX 4090

(Замеры при разрешении 480×832)

Стандартный Wan VAE остаётся нашим основным выбором для демо с более высоким качеством. LightTAEW уменьшает задержку и потребление памяти, но вносит дополнительный компромисс по качеству декодирования.

14–15 FPS технически позволяют управлять миром в реальном времени, но это пока далеко до комфортной игры. Между нажатием клавиши и достаточно заметной визуальной реакцией всё ещё существует задержка, особенно при сложной динамике или резких поворотах.

---

Где система ломается

Мы считаем, что самая важная часть проекта это не лучшие демонстрации, а понимание того, почему система перестаёт работать.

1. Отсутствие постоянной пространственной памяти

DF‑World 0.1 хранит локальный визуальный контекст, но не поддерживает надёжное внешнее состояние мира.

Если пользователь:

1. смотрит на объект;

2. отворачивается;

3. проходит некоторое расстояние;

4. возвращается назад,

модель может не восстановить исходную сцену, а синтезировать новую правдоподобную версию.

На данный момент, это главный архитектурный предел версии 0.1.

Чтобы решить его, одного более длинного окна attention, вероятно, недостаточно. Нужен либо отдельный механизм постоянной памяти или спец‑обучение на запоминание ^[14] пространственных паттернов.

2. Авторегрессивнный дрифт

Каждый новый кадр зависит от ранее сгенерированных кадров. Ошибка не исчезает, а становится основой для следующих кадров.

При длинной генерации возникают:

• потеря мелких текстур;

• перенасыщение/выгорание цвета;

• изменение формы объектов;

• размывание границ;

• перестройка сцены;

• деградация идентичности персонажа.

Иногда цветовой баланс частично восстанавливается, за счет обучения модели к сопротивлению авторегрессивным ошибкам, но утраченная детализация обычно не возвращается.

3. Резкие движения камеры

Плавное перемещение модель переносит заметно лучше, чем быстрое вращение.

При агрессивном повороте камеры, модель должна одновременно:

• обновить направление камеры;

• синтезировать ранее невидимую область;

• сохранить уже существующую геометрию;

• согласовать движение с ранней историей кадров.

Без постоянного состояния мира эти требования конфликтуют, и сцена может дестабилизироваться.

4. Third‑person контроль сложнее first‑person

В первом лице действие в основном связано с движением камеры.

В третьем лице необходимо учитывать:

• движение персонажа;

• его позу и анимацию;

• относительное положение камеры;

• окклюзии;

• параллакс;

• фон.

Поэтому third‑person чекпоинт нашего action‑модуля остаётся более хрупким, хотя и вполне работоспособным.

5. Это ещё не точная симуляция

Управляющие действия влияют на результат, но модель не гарантирует высокой точности симуляции.

Она может понять общее намерение, например, двигаться вперёд, повернуть, изменить направление, но пока не обеспечивает точную физику, детерминированное взаимодействие или постоянное состояние объектов.

DF‑World 0.1 также не включает аудиогенерацию, поддержку нескольких симуляций внутри одного мира и устойчивое физическое взаимодействие с ранее созданными объектами.

---

Почему $2k вообще оказалось достаточно

Ответ не в одном трюке и не в том, что большие world models внезапно стали дешёвыми.

Мы экономили вычисления на каждом уровне:

1. Не переучивали визуальное знание.
   Wan уже умел генерировать широкий диапазон сцен.

2. Не строили видеостек с нуля.
   LongLive уже решал базовую задачу стриминговой видео‑генерации.

3. Не обучали управление с полного нуля.
   Мы перенесли существующий action‑модуль и адаптировали его к новой модели через доп. обучение.

4. Использовали LoRA там, где полное дообучение/файнтюнинг было бы избыточным.

5. Разделили FPV и TPV.
   Это уменьшило конфликт ^[15] между двумя разными режимами камеры.

6. Оптимизировали полный runtime, а не только DiT.

7. Приняли ограничения preview‑версии.
   Мы не пытались в рамках того же бюджета решить постоянную память, точную физику и уровень качества сопоставимый с гигантами world modelling‑а, как например Genie 3 от Google.

Таким образом, 2000$ это не стоимость универсальной мировой модели, а скорее стоимость конкретной адаптационной траектории, построенной поверх уже существующей открытой инфраструктуры.

---

Что опубликовано

По результатам года работы и экспериментов, сейчас доступны:

• технический отчёт на arXiv;

• описание архитектуры и рецепт для воспроизводства наших результатов;

• небольшие замеры;

• демонстрационные видео;

• project page.

DF‑World 0.1 остаётся в формате preview, то есть не полноценным публичным релизом модели. Веса версии 0.1 в данный момент не открыты.

Следующая версия, DF‑World 0.5, нацелена на более крупную базовую видео модель, теперь с поддержкой аудиовизуальной генерации, более устойчивым управлением, наработками в области постоянной памяти, более высокое разрешение (720р) и улучшения общего качества генерации. Мы планируем открыть веса и код DF‑World 0.5, как только модель будет достаточно готова для релиза. Эта возможность публичного выпуска все еще взвешивается нами, но пока open‑source путь является нашим основным направлением.

---

Что мы из этого вынесли

Самый важный результат версии 0.1 это не 14 FPS и не отдельная красивая демонстрация.

Проект показал, что небольшая независимая команда может собрать real‑time мировую модель, не обладая бюджетом лаборатории уровня топовых ИИ лабораторий.

Следующий барьер в мировом моделлировании, это не просто более высокая визуальная точность, а состояние:

• где находятся объекты;

• что пользователь уже видел;

• какие части сцены должны сохраниться;

• как восстановить пространство после возвращения;

• как не позволить модели постепенно переписывать собственную историю.

Именно постоянное состояние, вероятно, разделяет сегодняшние интерактивные видеогенераторы и будущие полноценные нейронные мировые движки.

Будет интересно услышать мнение Хабра насчет этого проекта!

Сайт проекта и демки ^[16]
Технический отчёт / Research paper ^[17]
HF страничка репорта ^[18]