«Qwen 3.8 Flash Next» - вымышленная будущая модель. В обсуждении на r/LocalLLaMA, откуда взялась вся фактура, это сказано прямо: Qwen3 существует, а Flash Next звучит фиктивно, и архитектура с выгрузкой n-gram весов не совпадает ни с одной известной архитектурой Qwen (тред на Reddit). Там же модель называют «вымышленной будущей моделью, которая существует в описываемом окружении». Ниже разбирается не релиз, а сценарий запуска из этого обсуждения.
Сценарий такой. 1-битное квантование UD-IQ1_S занимает 67,6 ГБ и в 64 ГБ резидентной памяти не помещается. Около 27 ГБ файла приходится на n-gram lookup-таблицу: её кладут на NVMe и подключают через mmap. Остальные ~41 ГБ весов умещаются в 32 ГБ VRAM плюс 32 ГБ системной RAM.
Цифра по скорости в треде одна: примерно 15-27 ток/с. Её получил пользователь с 24 ГБ VRAM и 32 ГБ DDR5. Прогноз, что 32 ГБ VRAM выведут систему на верхнюю границу диапазона или выше, остаётся прогнозом: замеров на такой конфигурации в обсуждении нет.
Что такое Qwen 3.8 Flash Next и почему это сценарий, а не релиз
Модели с таким названием нет в опубликованных карточках и каталогах. Тред, из которого выросли все числа, описывает её как элемент вымышленного окружения и попутно фиксирует нестыковку: у известных Qwen нет архитектуры «Flash Next» с выгрузкой n-gram весов в системную память. Это первый ограничитель достоверности: 67,6 ГБ, 27 ГБ таблицы и 41 ГБ весов описывают гипотетическую сборку, а не файл, который можно скачать и проверить.
Второй ограничитель - природа цифр. Часть из них арифметика из треда: сколько занимает таблица, сколько остаётся на веса. Другая часть - один пользовательский замер скорости. Официальных спецификаций, карточки модели и воспроизводимых бенчмарков за этими числами не стоит.
Откуда взялись цифры: что именно обсуждается в Reddit-треде
Сводка утверждений из обсуждения, с пометкой, чем каждое из них по сути выступает.
| Утверждение из треда | Значение | Что это на самом деле |
|---|---|---|
| Размер файла UD-IQ1_S | 67,6 ГБ | Оценка размера квантованной сборки |
| n-gram lookup-таблица | около 27 ГБ файла | Табличная часть, которую предлагается держать на NVMe |
| Нетабличные веса | около 41 ГБ | Плотные веса для VRAM и системной RAM |
| Целевая конфигурация | 32 ГБ VRAM + 32 ГБ RAM | Суммарно 64 ГБ резидентной памяти |
| Измеренная скорость | 15-27 ток/с | Один замер на 24 ГБ VRAM + 32 ГБ DDR5 |
| Прогноз для 32 ГБ VRAM | верхняя граница диапазона или выше | Предположение без замера |
Читать таблицу стоит сверху вниз как цепочку: размер файла задаёт проблему, деление на таблицу и веса даёт решение, конфигурация объясняет, куда что кладут, а скорость - единственная измеренная величина, причём на другом железе.
Чем «Flash Next» отличается от известной архитектуры Qwen
Нестандартность сценария в одном: крупная n-gram таблица вынесена за пределы резидентной памяти и живёт на диске. Обычные модели грузят веса целиком в VRAM или делят их между VRAM и RAM, и это деление определяет скорость. Здесь появляется третий уровень, SSD, к которому идут обращения прямо во время генерации.
В треде сказано, что такая схема не совпадает с известной архитектурой Qwen (обсуждение). Значит, обсуждать имеет смысл не устройство несуществующей модели, а эффект от выноса большой таблицы на накопитель. Приём применим к любой модели, у которой есть крупная табличная компонента.
Арифметика памяти: почему 67,6 ГБ не влезают в 64 ГБ, а модель всё равно запускается
67,6 ГБ против 64 ГБ. Разница 3,6 ГБ, и её достаточно, чтобы модель не поместилась целиком. Выручает структура файла: 27 ГБ таблицы плюс 41 ГБ весов дают примерно 68 ГБ, в треде округляют, но таблица не обязана быть резидентной. Как только она уезжает на NVMe, в памяти остаются 41 ГБ, а это меньше 64 ГБ.
Запас в 23 ГБ идёт не на роскошь, а на KV-кэш, буферы и служебные структуры рантайма. При длинном контексте кэш растёт, и этот запас тает: на промпте в сотню тысяч токенов свободной памяти останется куда меньше.
Что такое n-gram lookup-таблица и почему она занимает 27 ГБ
Lookup-таблица - структура, к которой обращаются по ключу: пришла последовательность токенов, из неё считается адрес, из адреса читается значение. Плотные матрицы весов в это время перемножаются, а таблица просто читается. Чтение по ключу даёт другую картину доступа: вместо потокового умножения идут отдельные выборки из крупного массива.
Именно табличная природа делает 27 ГБ кандидатом на вынос. Плотные веса нужны под рукой на каждом шаге, к таблице обращаются иначе, и её отсутствие в памяти не ломает вычисление, а только замедляет его. В треде не раскрыто, как таблица встроена в модель и что лежит в её ячейках; известно лишь, что она составляет около 27 ГБ файла. Додумывать за авторов обсуждения не стоит.
Почему 41 ГБ весов умещаются в 32 ГБ VRAM + 32 ГБ RAM
41 ГБ меньше 64 ГБ, но больше 32 ГБ. Отсюда простая раскладка: часть весов остаётся в VRAM, часть уезжает в системную RAM, и это уже влияет на скорость, потому что RAM для GPU заметно медленнее собственной видеопамяти. Схема распределения выглядит так:
- VRAM (32 ГБ): активные слои, всё, что успевает поместиться, и KV-кэш.
- RAM (32 ГБ): остаток весов, к которому GPU обращается через PCIe.
- NVMe: 27 ГБ n-gram таблицы, подкачиваемой через mmap.
Что именно окажется в VRAM, зависит от рантайма: одни движки держат в видеопамяти первые слои, другие распределяют веса по частоте обращений. Конкретная политика в треде не указана, так что 41 ГБ в 64 ГБ - арифметическая возможность, а не гарантия удачной раскладки.
Как mmap и NVMe SSD влияют на запуск и скорость
mmap без магии: что происходит при обращении к таблице
mmap отображает файл в адресное пространство процесса. Программа читает по адресу, ядро проверяет, есть ли страница в памяти; если нет, происходит page fault, чтение с диска и попадание страницы в page cache. Вся таблица при старте не загружается, работа идёт по требованию.
Ловушка в том, что page cache не бесконечен. Когда RAM занята весами модели, ядру приходится вытеснять страницы таблицы, и при следующем обращении к ним диск читается заново. Каждый такой промах - пауза, которая складывается в общую задержку декодирования или обработки промпта.
Какой NVMe нужен и где узкое место
Узкое место в такой схеме - накопитель, а не GPU, если промахов много. Подкачка страниц даёт мелкие чтения, поэтому важнее случайное чтение, глубина очереди и задержка, а не паспортные гигабайты в секунду на последовательном доступе. NVMe здесь предпочтительнее SATA-накопителей, у которых потолок по интерфейсу ниже и задержки выше.
Чек-лист перед попыткой:
- NVMe, а не SATA и не внешний USB-накопитель.
- Запас свободного места: 67,6 ГБ под файл плюс место под кэш, обновления и систему.
- Понимание, что запись на тот же диск во время генерации отнимает полосу.
- Контроль температуры: при троттлинге скорость чтения падает, и промахи становятся дороже.
Конкретных замеров о том, как скорость SSD отражается на ток/с именно в этой схеме, в обсуждении нет, есть только общая логика. Практические отчёты с выгрузкой части модели на накопитель разбирались в материалах о запуске Qwen3.8-Flash-Next на 12 ГБ VRAM и о GGUF-сборке Qwen на 27B с выносом mmproj в RAM. Там диск тоже становится частью архитектуры запуска, но цифры получены на другом железе и других квантах.
Скорость генерации: откуда 15-27 ток/с и что дадут дополнительные 8 ГБ VRAM
Диапазон 15-27 ток/с - это измерение пользователя с 24 ГБ VRAM и 32 ГБ DDR5. Ширина диапазона объясняется условиями: короткий промпт даёт одну цифру, длинный контекст другую, часть обращений к таблице попадает в кэш, часть нет. Тред не разбивает результаты по длине контекста, поэтому диапазон остаётся диапазоном.
Почему +8 ГБ VRAM могут дать прирост, но не гарантируют его
Логика простая: 32 ГБ VRAM вместо 24 ГБ позволяют удержать в видеопамяти больше весов, реже обращаться к системной RAM и оставить больше места под KV-кэш. Меньше вытеснений - меньше дисковых чтений. При таком раскладе скорость должна оказаться у верхней границы 15-27 ток/с или выше, и именно так прогноз сформулирован в треде.
Оговорка: если основная задержка приходит от SSD на промахах в таблицу, лишние 8 ГБ VRAM помогут лишь частично, и прирост окажется меньше ожидаемого. Замера на 32 ГБ VRAM в обсуждении нет, это предположение.
Что ещё влияет на ток/с помимо объёма памяти
- Пропускная способность памяти GPU: она ограничивает декодирование сильнее, чем объём.
- Поколение карты и драйверы.
- Версия рантайма и форк llama.cpp: разные сборки по-разному работают с offload.
- Длина контекста: чем она больше, тем крупнее KV-кэш и тем ниже скорость.
- Размер батча и настройки сэмплинга.
- Температура и троттлинг под длительной нагрузкой.
1-битное квантование против 4-битного: что выбрать на практике
В треде вопрос поставлен ребром: «1-bit lobotomized model или q4 3.8 27B?» (тред). Ответа в обсуждении нет. Есть формулировка, которая многое говорит о репутации 1-битных квантов: «лоботомизированная». Это оценка пользователей, а не результат замеров.
Что теряется при 1-битном квантовании
UD-IQ1_S укладывает веса примерно в один бит на параметр и компенсирует это групповыми масштабами и более точными компонентами; детали реализации формата в треде не разбираются. Общий принцип такой: чем ниже битность, тем сильнее искажаются веса и тем выше шанс, что модель начнёт путать форматы, терять инструкции и ошибаться в многошаговых задачах. Процентов падения качества без источника называть нельзя, поэтому ограничусь качественной оценкой: риск деградации на сложных задачах высокий, на простых заметно ниже.
Когда 4-битная модель 3.8 27B выгоднее
4-битная модель класса 27B меньше по размеру, обычно целиком помещается в 24-32 ГБ VRAM, не требует подкачки таблицы с SSD и даёт предсказуемую скорость. Плата - другой масштаб модели: это не тот же Qwen 3.8 Flash Next, поэтому сравнение качества в треде не проводилось, а на гипотетической модели провести его невозможно.
Рамка выбора: если задача в том, чтобы запустить максимально крупную модель на ограниченной памяти и есть быстрый NVMe, 1-битный сценарий с выносом таблицы имеет смысл как эксперимент. Если важнее качество ответов и стабильность, 4-битная модель меньшего размера обычно разумнее. Как сильное квантование бьёт по качеству, разобрано в материале IQ3_XXS против Q8_0, а расчёт бюджета VRAM для 4-битной Flash Next на нескольких GPU - в статье про переход с 27B на четырёх RTX 3090.
Ограничения сценария и кому он подходит
Чего в сценарии нет и почему это важно
- Подтверждённых характеристик модели: «Qwen 3.8 Flash Next» названа вымышленной, архитектура не совпадает с известной Qwen.
- Бенчмарков качества: ни для 1-битного UD-IQ1_S, ни в сравнении с 4-битным вариантом.
- Замеров на разных SSD: влияние накопителя на ток/с не измерено.
- Данных для 32 ГБ VRAM: все цифры получены на конфигурации 24 ГБ VRAM + 32 ГБ DDR5.
- Разбивки скорости по длине контекста и по типу задачи.
Без этих данных выводы о реальной производительности были бы догадкой. Диапазон 15-27 ток/с стоит читать как единичный пользовательский замер, а не как эталон для похожих сборок.
Практический вывод для владельцев 24-32 ГБ VRAM
Полезное здесь - сам приём гибридного размещения. Разделение плотных весов и крупной таблицы, которую можно отдать на NVMe через mmap, объясняет, почему файл больше суммарной памяти иногда всё-таки запускается. Проверять приём стоит на реальных моделях с реальными квантованиями, следя за тремя вещами: сколько весов остаётся в RAM, как часто идут промахи в таблицу и насколько быстро читает накопитель.
Если у вас 24-32 ГБ VRAM и быстрый NVMe, схема заслуживает эксперимента при условии, что качество 1-битного кванта вы готовы принять. Если накопитель один и на нём же живёт система, отдельный SSD под модели даст больше, чем ожидание прироста от лишних гигабайтов VRAM.