Что произошло: суть кейса в двух абзацах
Пользователь Thin_Pollution8843 запустил Qwen3.8-Flash-Next локально в квантованном варианте Intel Autoround W4A16 на четырёх GPU V620. Заявленная производительность: около 2 тыс. токенов prefill и порядка 70 токенов/с на декодировании. Прогон занял примерно три часа, причём работа шла циклами: модель писала код, открывала его в браузере, находила ошибку и правила. Отчёт опубликован в сабреддите r/LocalLLaMA.
Промпт был намеренно кривым: с опечатками, без структуры, зато с четырьмя жёсткими рамками. Нужна была 3D-игра про космического путешественника в скафандре на ракете, который уклоняется от астероидов и отстреливается от врагов, на HTML и JS с любой библиотекой. Отдельным пунктом шло указание всегда запускать браузер для отладки. Модель выдала играбельный результат, хотя сам автор назвал его в заголовке «slop game», то есть поделкой, а не витринным проектом. Большую часть времени модель держала два браузера параллельно и правила код сама. Автор считает, что заметный вклад внёс harness на базе OMP.
| Параметр | Что указано в отчёте |
|---|---|
| Модель | Qwen3.8-Flash-Next |
| Квантование | Intel Autoround W4A16 |
| Железо | 4 GPU V620 |
| Prefill | около 2 тыс. токенов |
| Декодирование | около 70 токенов/с |
| Длительность прогона | около 3 часов |
Оговорка сразу: это единичное сообщение одного пользователя, независимо не подтверждённое. Версия модели, объём памяти V620, конкретные библиотеки для 3D-графики и параметры запуска в отчёте не раскрыты. Что известно о самой Qwen3.8-Flash-Next, её архитектуре и требованиях к железу, разобрано в отдельном материале о модели.
Железо и запуск: что значит 4xV620 и W4A16 на практике
V620 упомянуты без характеристик: нет ни объёма памяти одной карты, ни способа соединения, ни схемы распределения модели по ускорителям. Оценивать конфигурацию приходится по косвенным признакам. Четыре карты в одной системе нужны ради одной цели: чтобы весов хватило в суммарную видеопамять. Дальше начинается инженерия, и она редко бывает бесплатной.
Почему W4A16, а не полная точность
Запись W4A16 означает 4 бита на вес и 16 бит на активации. Веса занимают примерно вчетверо меньше места, чем при 16-битном хранении, и именно это позволяет запустить крупную модель на железе, где полная точность просто не влезет. Плата за экономию известна: огрубление весов заметнее всего бьёт по задачам с длинными цепочками рассуждений и по точным вычислениям.
В этом кейсе модель удержала многошаговый цикл: генерацию кода, запуск в браузере, поиск ошибок и правки. Для такой задачи 4 бит хватило. Утверждать, что деградации нет, нельзя: прогонов в полной точности на том же железе автор не приводил, сравнивать не с чем. Остаётся открытым и вопрос, сколько именно итераций модель потратила на ошибки, которые в FP16 не возникли бы.
Что даёт мульти-GPU на четырёх картах
Несколько GPU увеличивают доступную память, но добавляют обмен данными между картами. Чем медленнее связь, тем сильнее просадка на декодировании, потому что каждый шаг генерации требует синхронизации. Как именно в этом прогоне разложены слои и с какой пропускной способностью работала связка, неизвестно, поэтому 70 токенов/с стоит читать как результат конкретной сборки, а не как свойство метода.
Практический ориентир: смотреть на суммарную VRAM и пропускную способность памяти, а не на число карт. Четыре медленных ускорителя дают больше памяти и часто меньшую скорость, чем одна быстрая карта сопоставимой стоимости. Для сравнения масштаба: в другом пользовательском отчёте Qwen3.8-Flash-Next в квантовании IQ3_XXS работала на одной RTX 5070 с 12 ГБ VRAM, выдавая 14-15 токенов/с и обрабатывая промпт на 20K примерно за три минуты. Цифры получены на разном железе и при разном квантовании, поэтому прямое сопоставление некорректно, но порядок величин показателен: десятки токенов в секунду - обычный режим крупных локальных моделей на потребительских конфигурациях. Подробнее эти цифры разобраны в разборе запуска на 12 ГБ VRAM.
Из формулировки автора про prefill неясно, идёт ли речь о скорости обработки промпта или о его длине. Пока это не уточнено, опираться на цифру как на технический показатель нельзя.
Промпт, который не должен был сработать
create a game where a space traveller in the space he neets eniemes who shoots in him and asteroids which he should avoid. he have a blaster gun to shoot enemies and asteroid. space traveller in scafandr and fyoing on the rocket. game should be very lifelike detailed and done with html and js (use any lib you want). 3d game photorealistic. ofc run the browser to debug and fix stuff always
Разбор текста: опечатки (neets, eniemes, scafandr, fyoing), рваные предложения, никакой структуры. При этом все ключевые рамки на месте: цель (3D-игра), персонаж (космонавт в скафандре на ракете), механики (стрельба по врагам и астероидам, уклонение), стек (HTML и JS, библиотека на выбор), требование к визуалу (photorealistic) и прямое указание запускать браузер и править код.
Последняя строка, судя по результату, оказалась решающей. Промпт задал не столько спецификацию, сколько разрешение на автономную отладку. Модель не тратила итерации на уточняющие вопросы, а начала работать и проверять себя в реальном окружении.
Практический вывод: рассчитывать на кривой промпт как на рабочий метод не стоит. Короткая и небрежная постановка снимает часть планирования, и агентный цикл компенсирует это только там, где у модели есть доступ к результату своей работы: консоль браузера, пустой экран, неработающее управление. Без запуска кода тот же промпт дал бы заметно более слабый результат.
Три часа автономной работы: как модель тестировала и правила код
Схема, которую описывает автор: модель пишет файл, открывает его в браузере, смотрит на поведение и ошибки, исправляет, повторяет. Два браузера одновременно указывают на параллельные ветки проверки. Что именно проверялось в каждой сессии, автор не уточняет.
Арифметика простая: при 70 токенах/с модель способна генерировать до 250 тыс. токенов в час, если считать только вывод. Значительная часть трёх часов уходит на другое: запуск браузера, загрузку страницы, возврат результатов в контекст. Поэтому реальный объём кода и число итераций заметно меньше этой оценки, а общая длительность прогона отражает не скорость генерации, а количество витков цикла.
Именно итеративность отличает такой результат от одной генерации. Модель доводила код до рабочего состояния через собственные проверки, а не выдавала финальный ответ вслепую. Похожий сценарий с более длинным циклом описан в отчёте о локальной разработке на одной рабочей станции DGX Spark, где прогон занял около восьми часов.
Роль harness на базе OMP
Harness - это обвязка вокруг модели: она принимает задачу, передаёт её модели, вызывает инструменты (запись файлов, запуск браузера), возвращает результат обратно в контекст и решает, когда цикл завершён. Автор пишет, что harness построен на базе OMP и что эта часть, по его мнению, дала большой эффект. Что именно представляет собой OMP и как он повлиял на результат, в отчёте не расшифровано.
Логика здесь понятна и без деталей. Модель определяет качество отдельного куска кода, harness определяет, сколько итераций она выдержит до того, как контекст забьётся логами и выводом браузера. Слабый harness разваливается на первых ошибках: результат не возвращается, цикл останавливается, и модель остаётся с кодом, который никто не проверял.
Что это говорит о локальных LLM и агентных пайплайнах
Кейс показывает распределение вклада в результат. Модель дала код и правки, квантование позволило ей поместиться в память, harness обеспечил повторяемость цикла, а браузер дал обратную связь из реального окружения. Промпт в этой цепочке оказался самым слабым звеном, и результат от этого не развалился.
Кому это может быть полезно
Разработчикам, которым нужно быстро собрать прототип: игру, интерактивную страницу, демо. Энтузиастам, изучающим агентные пайплайны и поведение локальных моделей на длинных задачах. Специалистам, для которых важна локальность: код и результаты отладки не уходят на сторонние серверы.
Для простых задач такое железо избыточно: ту же игру проще проверить на меньшем квантовании и одной карте. Для сложных проектов, где нужны точные вычисления и длинная память, конфигурации может не хватить. Сгенерированные игры хорошо показывают разницу между «работает» и «готово к использованию»: пример с клоном Super Mario Bros разобран в отдельном кейсе генерации игр, где как раз видно, какие проверки нужны перед запуском такого кода.
Ограничения и что осталось за кадром
- версия Qwen3.8-Flash-Next не указана;
- объём памяти V620 и схема соединения карт не раскрыты;
- библиотека для 3D-графики не названа, поэтому нельзя судить о сложности сгенерированного кода;
- влияние harness OMP описано одной фразой без деталей;
- сравнения с полной точностью нет, значит о цене квантования по качеству судить нечем;
- неизвестно, сколько ошибок модель нашла и сколько итераций потратила.
Все сведения идут из одного сообщения и не проверялись независимо. Переносить выводы на другие модели, квантования и конфигурации нельзя: исходный отчёт описывает одну сборку и одну задачу.
Итог: что реально даёт такой запуск
Сухие факты: Qwen3.8-Flash-Next в квантовании Intel Autoround W4A16 на четырёх GPU V620 выдала около 2 тыс. токенов prefill и порядка 70 токенов/с на декодировании, за три часа собрала 3D-игру по промпту с опечатками, а ключевыми факторами стали агентный цикл с двумя браузерами и harness на базе OMP. Независимого подтверждения нет, часть технических деталей не раскрыта.
Если хотите повторить такой сценарий, порядок действий другой, чем при обычном локальном запуске. Сначала считайте суммарную VRAM и выбирайте квантование под неё, затем проверьте, что модель стабильно тянет длинный контекст на вашей задаче, и только после этого собирайте harness. Обвязка должна уметь записывать файлы, запускать браузер, забирать оттуда ошибки и обрезать историю, иначе цикл упрётся в лимит контекста на первом же десятке итераций. Модель в этой схеме важна, но потолок результата задаёт именно обвязка.