Отчёт о локальном запуске Qwen3.8-Flash-Next в формате NVFP4 с контекстом 262K на одной рабочей станции NVIDIA DGX Spark опубликован 18 сентября 2026 года в сообществе r/LocalLLaMA. Автор утверждает, что прошёл полный цикл разработки за 8 часов: планирование, написание кода, тестирование.
Метрики, которые он приводит: около 10 000 сгенерированных строк кода, около 800 000 израсходованных токенов, скорость порядка 35 токенов в секунду. Стек - VSCode Copilot в режиме автопилота и SGLang. Модель описана как полностью локальная MoE примерно на 180B параметров. Оговорка, без которой разбор теряет смысл: все числа взяты со слов автора, независимых замеров нет.
Практический вывод для читателя короткий. Кейс показывает, что 180B-модель в 4-битном квантовании способна отработать полный агентный цикл на одном устройстве, а цифры внутри отчёта согласуются между собой арифметически. Повторить сценарий по опубликованным данным нельзя: не раскрыты конфигурация железа, версии софта, параметры запуска и методика подсчёта.
Что именно заявлено в отчёте
Сведём заявления без оценок.
- Модель: Qwen3.8-Flash-Next, запуск полностью локальный. О том, что это за модель и как она соотносится с линейкой Qwen, мы писали в отдельном разборе.
- Квантование: NVFP4.
- Контекст: 262K токенов.
- Железо: одна рабочая станция NVIDIA DGX Spark.
- Стек: VSCode Copilot в режиме автопилота плюс SGLang.
- Время: около 8 часов на планирование, код и тесты.
- Объём: примерно 10 000 строк кода.
- Расход: примерно 800 000 токенов.
- Скорость: около 35 токенов в секунду.
- Оценка автора: уровня топовых проприетарных моделей результат не достигает, но для локальной MoE на ~180B на одном устройстве выглядит достойно.
За пределами описания осталось многое: какой проект генерировался, на каком языке и фреймворке, сколько кода прошло тесты, сколько правок внёс человек.
Почему это интересно: контекст локального AI-стека
MoE-модель на ~180B параметров - класс, который ещё недавно требовал серверной стойки. Ключевое свойство таких архитектур: на каждый токен срабатывает лишь часть экспертов, поэтому вычислений на токен нужно меньше, чем у плотной модели того же размера. Память при этом определяется полным набором весов, а не активными параметрами. Отсюда практическое следствие: узкое место при локальном запуске - объём памяти, а не вычислительная мощность.
Рынок движется в ту же сторону. Платформа Nvidia RTX Spark объединяет GPU архитектуры Blackwell RTX и CPU Grace; конфигурация для настольных систем включает до 6144 ядер CUDA, 20-ядерный процессор Arm и до 128 ГБ унифицированной памяти LPDDR5X. Nvidia оценивает вычислительную мощность такого чипа в 1 Пфлопс (FP4) при энергопотреблении в пределах 140 Вт. Пример устройства на этой платформе - Honor Tiangong AXB35 Ultra со 128 ГБ памяти (3DNews).
Осторожность здесь обязательна: RTX Spark и DGX Spark - разные продукты, характеристики одного не переносятся на другой. Конфигурация конкретного устройства из отчёта не названа. Общий принцип, который источник подтверждает прямо: реальные возможности зависят от квантования, длины контекста, степени параллелизма и используемого программного обеспечения. Именно эти четыре параметра определяют результат, и именно они в отчёте не раскрыты.
Технические детали: что известно и что осталось за кадром
Пять элементов определяют поведение такой системы: формат квантования, длина контекста, архитектура модели, инференс-фреймворк и клиент, который отправляет запросы. По каждому есть подтверждённая часть и пробел.
NVFP4 и 262K контекст: что это даёт на практике
NVFP4 - 4-битный формат с блочным масштабированием, рассчитанный на GPU поколения Blackwell. Группы весов получают собственные коэффициенты масштаба, за счёт чего точность держится лучше, чем при равномерном 4-битном квантовании. Арифметика простая: 180B параметров в 4 битах занимают порядка 90 ГБ, те же веса в FP16 - около 360 ГБ. Без 4-битного формата такая модель на одном компактном устройстве не разместилась бы.
Плата за это - потеря качества, величина которой зависит от модели и калибровки. В отчёте нет ни сравнения NVFP4 с другими форматами, ни оценки качества сгенерированного кода. О том, как NVFP4 ведёт себя на практике и чем отличаются prefill и decode, мы разбирали в материале о запуске Qwen 3.8 27B в NVFP4 на одной RTX 5090.
262K контекста решают другую задачу: агентный цикл быстро накапливает историю. Каждая правка файла, вывод тестов и результат команды добавляются в окно, поэтому длинное окно снижает частоту сбросов контекста. Обратная сторона - KV-кэш, который растёт линейно с длиной контекста. Сколько памяти он занял, применялось ли квантование кэша (INT8 или FP8) и какая доля из 262K реально была заполнена, отчёт не сообщает.
SGLang и VSCode Copilot: как мог выглядеть стек
SGLang - открытый фреймворк для обслуживания LLM. Среди его особенностей - префиксное кэширование, поддержка MoE и работа с длинным контекстом. Для агентного кодинга это важно: повторяющиеся префиксы промптов не пересчитываются с нуля. Версию фреймворка, флаги запуска, режим квантования KV-кэша и ограничения на размер батча в отчёте не привели. О том, какие параметры инференса реально влияют на скорость MoE-моделей, у нас есть разбор с замерами на RTX 4080.
VSCode Copilot в режиме автопилота - клиентская часть: агент сам формирует шаги, правит файлы и запускает команды, а запросы уходят на локальный сервер. Как именно трафик шёл от Copilot к SGLang, не сказано. Вариантов несколько: промежуточный прокси, настройка эндпоинта, отдельный слой маршрутизации. Без этой детали стек не воспроизводится.
Ещё один неизвестный параметр - конфигурация самой DGX Spark: объём доступной унифицированной памяти, версии драйверов и прошивки, режим работы с памятью. Для модели, чьи веса занимают десятки гигабайт, эти детали определяют, что вообще запустится.
Насколько заявленные метрики реалистичны
Проверим числа на внутреннюю согласованность. 8 часов - это 28 800 секунд. При скорости 35 токенов в секунду теоретический максимум за это время - примерно 1 008 000 токенов. Заявленные 800 000 укладываются в потолок с запасом около 20%, который уходит на обработку промптов, паузы, запуск тестов и действия человека. Средняя скорость за весь цикл получается около 28 токенов в секунду.
Соотношение строк и токенов тоже выглядит правдоподобно: 800 000 / 10 000 = примерно 80 токенов на строку кода. Для генерации кода с учётом промптов, объяснений и повторных правок это разумный порядок величины.
| Метрика | Заявлено | Что неизвестно |
|---|---|---|
| Время | ~8 часов | как фиксировалось время, входили ли паузы и обзор кода |
| Строк кода | ~10 000 | как считались строки, учитывались ли пустые и перегенерированные |
| Токенов | ~800 000 | входят ли токены промптов или только сгенерированные |
| Скорость | ~35 ток/с | decode или среднее по циклу, при какой длине контекста |
| Контекст | 262K | какая длина была задействована в реальной работе |
| Квантование | NVFP4 | как измерялось влияние на качество кода |
Отдельная поправка, важная для интерпретации: скорость генерации в токенах в секунду не равна скорости решения задачи. Агент делает много промежуточных шагов, и модель, которая пишет быстрее, но чаще переписывает файл заново, в итоге закончит позже. Разницу между этими метриками мы разбирали на примере сравнения DeepSeek-V4-Flash-Vision и Qwen3.8-Flash-Next в Q8.
Итог по метрикам: противоречий внутри отчёта нет, но подтверждений тоже. Доля кода, прошедшего тесты, не указана, методика подсчёта не описана. Проверить цифры можно только по исходному сообщению автора, где они и приведены.
Сравнение с топовыми проприетарными моделями: чего ждать
Автор сам оговаривает, что уровня топовых проприетарных моделей результат не достигает, и не приводит для сравнения ни метрик, ни результатов замеров. Такое сопоставление остаётся оценочным: непонятно, о какой именно задаче и каком разрыве речь.
Общая логика выбора выглядит так. Облачные модели сильнее на сложных задачах, где нужны длинные цепочки рассуждений, редкие библиотеки и нестандартные архитектурные решения. Локальный запуск даёт другое: код не покидает периметр, нет оплаты за токены, нет зависимости от доступности сервиса. На типовых задачах (CRUD, тесты, рефакторинг по шаблону, миграции) разрыв на практике может быть небольшим, на задачах у границы возможностей модели он заметен. Готовых бенчмарков в отчёте нет, поэтому оценивать разрыв придётся на своих задачах.
Кому и зачем нужен локальный запуск MoE-модели для разработки
Сценарий имеет смысл в нескольких случаях:
- Код по требованиям или договору не может уходить в облако.
- Нужна предсказуемая стоимость: одно устройство вместо счёта за токены.
- Работа идёт в изолированной сети или без стабильного доступа к интернету.
- Нужен полный контроль над версиями модели, квантования и параметрами инференса.
Ограничения тоже конкретные. Стоимость устройства для запуска 180B-модели в 4 битах измеряется тысячами долларов, и это без учёта времени на настройку. Скорость порядка 35 токенов в секунду комфортна для чтения вывода, но в агентном цикле с длинным контекстом эффективная скорость ниже: часть времени уходит на обработку промпта. Качество кода в 4-битном квантовании требует проверки, а тесты и ревью остаются на человеке. Сборка стека из SGLang, клиента и окружения модели занимает часы даже при наличии готовой инструкции.
Вывод для решения: локальная MoE-модель такого размера подходит командам с жёсткими требованиями к приватности и энтузиастам с подходящим железом. Для повседневной разработки без таких требований облачные модели остаются проще и на большинстве задач сильнее.
Что осталось невыясненным и что проверить перед повторением
Если вы хотите повторить сценарий, начните с вопросов, ответов на которые в отчёте нет:
- Конфигурация DGX Spark: объём унифицированной памяти, версии драйверов и прошивки, режим работы с памятью.
- Версия SGLang и полный набор флагов запуска: размер батча, лимиты контекста, chunked prefill, режим квантования KV-кэша.
- Способ подключения VSCode Copilot к локальному серверу.
- Методика подсчёта строк и токенов: что именно считалось и каким инструментом.
- Доля кода, прошедшего тесты, и объём ручных правок.
- Характер проекта: язык, фреймворк, сложность задач.
- Как измерялась скорость: decode, среднее по циклу или отдельный короткий замер.
Часть этих данных стоит уточнять у автора отчёта или сверять с документацией SGLang и самого устройства. Придумывать значения за него смысла нет: именно от них зависит, воспроизведётся результат или нет.
Вывод: что этот кейс говорит о локальном AI
Отчёт показывает, что планка локального запуска сместилась: MoE-модель на ~180B параметров в 4-битном квантовании отработала полный агентный цикл на одном устройстве, а заявленные цифры не противоречат друг другу арифметически. Одновременно это набор пользовательских метрик без независимой проверки и без деталей, по которым сценарий можно повторить.
Практическая позиция читателя: относиться к таким отчётам как к сигналу, а не как к бенчмарку. Сигнал стоит проверять на своей задаче, с учётом квантования, длины контекста, параллелизма и софта, которые и определяют итог. Если нужен ориентир для собственного запуска, начните с сопоставления требований модели к памяти и возможностей вашего железа, а затем уточняйте параметры инференса по документации фреймворка.