Что именно собрали на Qwen3.8 Flash Next и почему это не text-to-video
Автор поста в r/LocalLLaMA выложил 15-секундный ролик про японский синкансэн в разрешении 1920×1080 при 60 fps. Всё сделано локально: Qwen3.8 Flash Next в квантовании GSQ RCO IQ3_XXS, RTX 4080 с 16 ГБ VRAM, 64 ГБ DDR5-5600, окружение strata и opencode. Первый рендер занял около 40 минут, три дополнительных промпта на правки растянули процесс примерно на два часа. Исходный пост с роликом и конфигурацией.
Модель не рисовала кадры. Она написала JavaScript-код 3D-сцены на three.js, Playwright открыл страницу в браузере и снял кадр за кадром, ffmpeg склеил последовательность в MP4. Отсюда три практических следствия: результат воспроизводим (тот же код даёт ту же картинку), правки вносятся текстом и повторным рендером, а длительность упирается в терпение и диск, а не в лимит генератора.
Заявленные скорости: около 95 tps на декодировании и около 3000 tps на префилле. Это единичный замер на конкретной машине, а не бенчмарк. Основное время съел рендер кадров, а не инференс модели. Качество автор оценивает прямо: до Opus результат не дотягивает, но для локального запуска выглядит достойно.
Ключевые цифры кейса: 15 секунд, 1080p60, 40 минут и 2 часа
- Длительность и формат: 15 секунд, 1920×1080, 60 fps, то есть 900 кадров.
- Сюжет: синкансэн в виде шоурила, с 1-секундным хуком в начале и лупа в конце.
- Первый рендер: около 40 минут, в среднем примерно 2,7 секунды на кадр.
- Доработки: три follow-up промпта, суммарно около 2 часов работы.
- Модель и железо: Qwen3.8 Flash Next GSQ RCO IQ3_XXS, RTX 4080 16 ГБ, 64 ГБ DDR5-5600.
- Скорости по словам автора: ~95 tps decode, ~3000 tps prefill.
Тайминги зависят от количества объектов, источников света, материалов и машины. Цифры выше задают порядок величин, а не норматив, который повторится у вас один в один.
Чем подход отличается от обычных генераторов видео
Диффузионные видеомодели выдают пиксели и плохо подчиняются точным инструкциям по композиции: чтобы поправить свет, приходится часто перегенерировать сцену целиком и надеяться на удачу. Здесь середина цепочки другая. Модель выдаёт исходник сцены, а картинку строит браузерный WebGL-рендер.
Практическая разница: правка «поднять экспозицию» превращается в изменение нескольких строк кода, а не в новую лотерею. Число кадров на выходе задаётся арифметикой (длительность × fps), поэтому ролик можно сделать сколь угодно длинным. Обратная сторона тоже очевидна: фотореализма, сложной физики и живой мимики тут не будет, потому что модель пишет геометрию и шейдеры, а не сэмплирует реальность. Подробнее о том, как LLM справляются с генерацией видео кодом и какие подходы им даются хуже, разбирали в материале про Remotion и чистый JavaScript.
Железо и запуск: влезет ли Qwen3.8 Flash Next в 16 ГБ VRAM
Конфигурация автора: RTX 4080 на 16 ГБ VRAM, 64 ГБ DDR5-5600, квант GSQ RCO IQ3_XXS, поверх которого работают strata и opencode. Точные параметры квантования, версии сборок и настройки strata с opencode в источнике не раскрыты, так что воспроизвести окружение байт в байт по этому посту не получится. Обсуждать стоит принцип, а не конкретные флаги.
16 ГБ VRAM для модели такого класса мало, поэтому агрессивное квантование здесь не роскошь, а условие запуска. Всё, что не помещается в видеопамять, уезжает в системную RAM или на диск, и скорость декодирования падает до скорости подкачки. При 64 ГБ DDR5-5600 запас по host-памяти есть, но обмен через PCIe всё равно остаётся узким местом.
Что даёт квантование GSQ RCO IQ3_XXS
IQ3_XXS относится к низкобитным i-квантам: веса хранятся примерно в 3 бита с умным распределением ошибки, что заметно экономит память по сравнению с 4- и 5-битными вариантами. Плата за это стандартная: часть точности рассуждений и качества кода теряется, и на длинных задачах модель чаще ошибается в мелочах.
В этом кейсе компромисс оказался приемлемым: кода хватило, чтобы собрать рабочую сцену и довести её правками. Но именно квантование вместе с классом модели автор имеет в виду, когда говорит, что до Opus результат не дотягивает. Конкретный размер файла модели и схему разбиения по слоям в источнике не приводят, поэтому подставлять сюда цифры из других кейсов смысла нет.
Скорость decode и prefill: что эти цифры значат на практике
Два числа отвечают за разные этапы. Prefill, около 3000 tps, это обработка входного промпта и уже накопленного контекста: 30 тысяч токенов такого промпта прожуются примерно за 10 секунд. Decode, около 95 tps, это генерация ответа токен за токеном: 1000 токенов кода выходят примерно за 10-11 секунд.
Полезно держать в голове масштаб: даже 10 тысяч токенов кода при такой скорости это меньше двух минут машинного времени. 40 минут первого рендера почти целиком ушли на работу браузера и ffmpeg, а не на модель. Если у вас похожая карта, узкое место будет там же.
Рецепт промпта: как описать ролик, чтобы модель собрала пайплайн
Формулировка автора выглядит так:
Make a 15-second, 1920×1080, 60fps video in Three.js that showcases the famous japan shinkansen train, like a showreel. Render it frame by frame to MP4 with Playwright and ffmpeg, go all out, 1s hook, loop.
Разбор по блокам: инструменты названы явно (three.js, Playwright, ffmpeg), технические параметры заданы числами (15 секунд, 1920×1080, 60 fps), способ вывода описан однозначно (покадрово в MP4), сюжет и формат заданы простыми словами (синкансэн, шоурил), структура ролика обозначена (хук на секунду, луп). Никаких схем API, названий функций и структуры файлов в промпте нет. Автор формулирует принцип так: сначала явно перечислить инструменты, потом обычными словами описать стиль, размеры, содержание, звук и характер анимации.
Обязательные блоки промпта: инструменты, размеры, сюжет, звук, анимация
- Инструменты и способ рендера: three.js для сцены, Playwright для покадрового захвата, ffmpeg для сборки MP4. Без этого модель может уйти в canvas 2D или в GIF.
- Размеры и частота: разрешение и fps числами, плюс итоговая длительность.
- Сюжет и объекты: что в кадре, что происходит, какие детали важны (например, поезд, рельсы, город на фоне).
- Стиль и стиль анимации: шоурил, рекламный ритм, плавные пролёты камеры, минимализм или плотная графика.
- Звук: упомянуть, нужен ли он. В кейсе аудио входит в рецепт, но как именно автор его задавал и что получилось, в источнике не раскрыто.
- Структура: хук в начале, луп в конце, порядок сцен, если он важен.
Правило простое: инструменты и числа задаются точно, содержание и настроение описываются человеческим языком. Чем больше вы пытаетесь предусмотреть в коде сцены заранее, тем выше шанс, что модель утонет в деталях.
Готовый шаблон промпта на русском
Каркас ниже это адаптация примера автора под русский язык, а не проверенный на других сценах промпт. Подставьте свои значения в квадратных скобках.
Сделай видео длительностью [15] секунд, [1920]x[1080], [60] fps, на Three.js. Тема: [поезд синкансэн]. Формат: [шоурил, динамичная нарезка]. Собери сцену в Three.js, отрендерь покадрово в MP4 через Playwright и ffmpeg. Стиль: [чистая геометрия, неоновый свет, тёмный фон, мягкие тени]. Анимация: [плавные пролёты камеры, ускорение к финалу, без резких склеек]. Звук: [фоновый эмбиент, без голоса]. Структура: [1 секунда хука в начале, луп в конце]. Города на фоне: [силуэты зданий, огни окон].
Дальше промпт живёт итерациями. Один прогон почти никогда не даёт финальный вид, и это нормальная часть процесса, а не признак, что модель не справилась.
Роль каждого инструмента в цепочке three.js → Playwright → ffmpeg
Каждый шаг решает свою задачу, и выпадение любого ломает пайплайн.
three.js строит сцену: камеру, свет, материалы, объекты и их движение. Ключевой момент в том, что состояние сцены вычисляется как функция от номера кадра, а не от реального времени. Кадр 540 всегда выглядит одинаково, сколько бы раз вы его ни рендерили.
Playwright управляет браузером: открывает страницу, ждёт готовности сцены, выставляет нужный момент времени и сохраняет изображение. Автоматизация браузера снимает зависимость от того, успел ли WebGL отрисовать всё в реальном времени.
ffmpeg превращает папку с кадрами в видеофайл с заданной частотой. Он же отвечает за кодеки и контейнер, если нужен не только MP4.
Почему покадровый рендер, а не захват экрана
Запись экрана в реальном времени зависит от загрузки системы: браузер дропает кадры, захватчик их теряет, на выходе получается 60 fps с рывками и неравномерными интервалами. Покадровый рендер такой проблемы не знает по построению: 15 секунд при 60 fps это ровно 900 файлов, каждый снят в своём моменте времени.
Цена тоже понятна. В кейсе 40 минут на 900 кадров дают в среднем около 2,7 секунды на кадр, и это время почти не зависит от скорости модели. Плюс место на диске: при весе кадра в PNG 2-3 МБ последовательность займёт около 2-3 ГБ. Это арифметика по заявленным числам, а не отдельный замер из источника, но порядок величин такой.
Побочный плюс для правок: меняется код сцены, а не «перегенерируется видео». Достаточно перерендерить затронутый участок, если вы предусмотрели такую возможность в скрипте.
Итеративные правки: три промпта, которые довели ролик до результата
Первый рендер автор описывает без прикрас: картинка вышла тёмной, зданий на фоне не было, текста оказалось слишком много. На исправление ушло три дополнительных промпта.
Логика follow-up простая: указываете, что не так, и что должно быть вместо этого. Не «сделай красивее», а «сцена слишком тёмная, подними экспозицию и добавь источники света». Связка three.js, Playwright и ffmpeg удобна именно для таких правок, потому что каждое замечание ложится в конкретное место кода. Автор отмечает, что этот стек хорошо подходит для исправлений.
Как формулировать правки по свету, объектам и тексту
- Свет: «картинка тёмная, подними общую экспозицию, добавь направленный источник и подсветку окон». Точка приложения понятна: параметры освещения и тонмаппинг.
- Объекты: «на заднем плане нет города, добавь силуэты зданий разной высоты вдоль путей». Модель добавляет геометрию, а не дорисовывает фон.
- Текст: «убери лишние надписи, оставь только короткий заголовок в финале». Текста в 3D-сцене лучше держать минимум.
- Ритм: «сделай пролёт камеры плавнее, убери рывок на середине». Правка кривой анимации, а не пересборка сцены.
Формулировки выше это иллюстрация подхода, а не дословный лог автора. Общий принцип один: одно замечание, один адресат в коде.
Сколько времени добавляют правки
По цифрам кейса: 40 минут на первый рендер и около 2 часов суммарно с тремя промптами. Простая арифметика даёт примерно 25-30 минут на итерацию, если каждая прогоняет все 900 кадров заново. Здесь снова оговорка: это расчёт по заявленным таймингам, а не хронометраж из поста.
Вывод для планирования: время растёт примерно линейно от числа итераций и от длительности ролика. Для 15 секунд две-три правки терпимы. Для минуты видео каждая итерация превращается в часы, и это главный ограничитель метода.
Качество результата: где Qwen3.8 Flash Next уступает Opus
Оценку автор даёт сам, без дипломатии: с Opus результат не сравним, но для локального запуска он вполне хорош. Причины такой разницы объясняются без гадания. Во-первых, квант IQ3_XXS это около 3 бит на вес, то есть заметно урезанная модель. Во-вторых, класс модели ниже, а сложная 3D-сцена с освещением и типографикой требует аккуратной кодогенерации.
Сравнение с топовыми моделями в задачах на код и 3D полезно держать в голове: в разборе про сценарии Claude Opus 5.5 видно, насколько выше планка по качеству анимации и работы с three.js, когда модель не урезана. Локальный запуск покупает автономность и отсутствие лимитов, а платите вы качеством.
Что сломалось в первом рендере и что это говорит о границах метода
Три типовые проблемы первого прогона: тёмная картинка, отсутствие зданий на фоне, избыток и поломанный текст. Каждая показывает слабое место.
- Освещение. Модель уверенно строит геометрию, но композиция света и выбор экспозиции требуют отдельного внимания.
- Наполнение сцены. Объекты, которые вы подразумевали, но не назвали, не появятся сами.
- Текст в 3D. Мелкая типографика в сцене это классическая зона ошибок: шрифты, разметка и читаемость страдают первыми. Дешевле оставить один короткий заголовок или вынести надписи в постобработку.
Для шоурилов, заставок, простых 3D-сцен и прототипов уровня хватает с запасом. Ждать фотореализма, сложной физики и детальной типографики от сборки на 16 ГБ VRAM не стоит. Похожий вывод напрашивается и в кейсе с 3D-игрой на четырёх V620: модель тянет объёмную работу, но итог зависит от того, насколько аккуратно построен цикл правок. И отдельно стоит помнить, что сильная сторона этой линейки именно код, а не общие рассуждения о вкусе и композиции.
Ограничения пайплайна и отсутствие лимита длительности
Автор утверждает, что у подхода нет ограничения по длительности: ролик может быть каким угодно длинным. Логика верная, число кадров задаётся умножением, а не возможностями генератора. Но в источнике нет ни одного замера на длинных роликах, поэтому воспринимать это стоит как свойство архитектуры, а не как проверенный факт.
Что известно точно: время рендера и объём промежуточных файлов растут линейно. Пятнадцать секунд это 900 кадров, минута это 3600, пять минут это 18 000. При средних 2,7 секунды на кадр пятиминутный ролик уже требует более 13 часов машинного времени без единой правки. Плюс упор в кодогенерацию: чем длиннее сценарий, тем больше шансов, что модель потеряет связность между сценами.
Дополнительные ограничения: любая правка требует повторного рендера, детали настройки strata и opencode не раскрыты, а качество упирается в способности урезанной модели писать three.js-код.
Что проверить перед длинным рендером
- Посчитайте кадры: длительность × fps. Это и время, и место на диске.
- Заложите диск под последовательность кадров и держите свободным хотя бы вдвое больше расчётного объёма.
- Отрендерьте 2-3 секунды превью и посмотрите свет, композицию и текст. Полный прогон на исправление тёмной картинки это потраченные часы.
- Зафиксируйте версию сцены перед правками, иначе повторный рендер смешает старое и новое.
- Разделите ролик на сегменты, если длина перевалила за минуту: так и правки локальнее, и сбой не обнуляет весь прогресс.
Это рекомендации из логики пайплайна, а не шаги, которые автор описывал в посте.
Кому подходит этот пайплайн и что делать дальше
Подход оправдан, если у вас есть GPU с 16 ГБ VRAM и больше, вы готовы читать и править код, и вам нужна повторяемая motion-графика без подписки, лимитов длительности и внешних сервисов. Он же выручает, когда нужен предсказуемый результат: одинаковый рендер сегодня и через месяц.
Не подходит, если требуется фотореализм уровня топовых моделей, сложная физика, объёмная типографика или работа с живым видео. Здесь разрыв с Opus остаётся заметным.
Чек-лист старта:
- Поднимите Qwen3.8 Flash Next в квантовании, которое влезает в вашу VRAM, и проверьте decode и prefill на своей машине. Ориентир из кейса: ~95 tps decode и ~3000 tps prefill на RTX 4080.
- Соберите промпт по шаблону: инструменты и числа точно, сюжет и стиль словами.
- Отрендерьте 2-3 секунды и оцените свет, композицию и текст.
- Доведите короткий фрагмент правками, только потом запускайте полный ролик.
- Заложите на итерации хотя бы столько же времени, сколько занял первый рендер.
Если хочется сначала разобраться с окружением вокруг локальных моделей и агентских циклов, полезен разбор про сутки кодогенерации на двух GPU: там видно, как мелкие фазы с проверкой результата экономят часы. Тот же принцип работает и здесь: короткий превью-рендер дешевле, чем два часа на исправление тёмной сцены.