На видеокарте с 12 ГБ VRAM можно запустить модель, полный файл которой занимает 76 ГБ, и получать около 15 токенов в секунду. Такой результат описал пользователь, прогнавший Qwen3.8-Flash-Next-GSQ-RCO-GGUF в квантовании IQ3_XXS (3 bpw) на RTX 5070 SFF, Ryzen 5 7600 и 64 ГБ DDR5-5600. Он заявляет стабильные 14-15 токенов/с на коротких и средних контекстах, просадку до 11,3 токенов/с на 90-100K и рабочий контекст 128K.
Сразу важная оговорка: это личный эксперимент одного человека. Цифры не проверялись независимо, методика описана не полностью, а сравнение качества с Q6-Q8 от Unsloth остаётся субъективной оценкой автора. Ниже разбираем, что именно он сделал, какие ограничения следуют из его же данных и стоит ли повторять эту конфигурацию.
Что за модель и почему её запуск на 12 ГБ VRAM - нетривиальная задача
Qwen3.8-Flash-Next-GSQ-RCO-GGUF - это GGUF-сборка модели Qwen3.8-Flash-Next, которую пользователь скачал и запустил локально. Префиксы в названии говорят о происхождении файла и типе квантования, а не о каких-то дополнительных возможностях модели.
Qwen3.8-Flash-Next в линейке Qwen3.8
Семейство Qwen развивает Alibaba Cloud минимум с 2023 года. Поколение Qwen3.8 включает несколько версий разного масштаба. Флагманская Qwen3.8-Max с 2,4 трлн параметров анонсирована в августе 2026 года, а Qwen3.8-27B с 27 млрд рабочих параметров рассчитана на запуск на персональном компьютере. По итогам независимого бенчмарка Intelligence Index Qwen3.8-27B набрала 41 балл, немногим меньше проприетарной GPT-5.6 Luna.
Qwen3.8-Flash-Next стоит особняком: это отдельная версия, о которой идёт речь в отчёте, и приписывать ей характеристики других моделей линейки не стоит. Чем Flash-Next отличается от полновесного Qwen4 и что известно о её локальном запуске, разобрано в отдельном материале про архитектуру и позиционирование Qwen3.8-Flash-Next.
Почему 76 ГБ GGUF не помещаются в 12 ГБ VRAM
Полный GGUF в отчёте занимает около 76 ГБ. Двенадцать гигабайт видеопамяти физически не вмещают такой объём, и никакая настройка этого не меняет. Автор пошёл другим путём: по его словам, шардировать нужно лишь 47 ГБ, а остальное подгружается с NVMe-накопителя на 1 ТБ.
Что это значит на практике. Часть слоёв и весов остаётся на диске и читается по мере необходимости. Каждое обращение к диску добавляет задержку, поэтому скорость генерации упирается и в вычислительную мощность GPU, и в пропускную способность NVMe. Формат IQ3_XXS (примерно 3 бита на вес) сокращает размер модели настолько, что она вообще помещается в описанную схему. Без агрессивного квантования такой запуск на 12 ГБ VRAM не имел бы смысла.
Как запускали: железо, софт и методика
Конфигурация целиком потребительская: игровая видеокарта, десктопный процессор, обычная DDR5 и один NVMe. Никаких серверных ускорителей или объединённых в пул GPU.
Конфигурация стенда
| Компонент | Значение из отчёта |
|---|---|
| GPU | RTX 5070 SFF, 12 ГБ VRAM |
| CPU | Ryzen 5 7600 |
| RAM | 64 ГБ DDR5-5600 |
| Накопитель | NVMe 1 ТБ |
| Квантование | IQ3_XXS (3 bpw) |
| Размер GGUF | около 76 ГБ, шардируется 47 ГБ |
Отдельно про оперативную память. 64 ГБ DDR5-5600 здесь не роскошь: часть весов и кэша проходит через системную память и диск, поэтому запас RAM напрямую влияет на то, сколько останется выгрузить на NVMe. Компактный корпус SFF накладывает своё ограничение: в такое шасси обычно не поставить вторую видеокарту или карту с большим объёмом памяти, так что 12 ГБ здесь потолок, а не выбор.
Программная часть и возможные ошибки
Запуск идёт через llama.cpp в связке с Unsloth Studio. Unsloth Studio умеет автоматически находить MTP-драфтер и стартовать сервер с флагами --model-draft … --spec-type ngram-mod,draft-mtp --spec-draft-n-max 3. Если вы собираете стек вручную, похожую схему запуска на Linux с llama.cpp и llama-swap описывает гайд по сборке локального стека для Qwen 3.8 27B на Debian.
С MTP-драфтером для этой модели связан известный баг. В issue для сборки b10995-mix-3e83366 драфтер Qwen3.8-Flash-Next падает при загрузке: nextn.hc_head_norm остаётся [hc_dim] после rebase, а llama-server аварийно завершается с кодом -6. Если попытаться загрузить драфтер отдельно от целевой модели, появляется ошибка:
error loading model: borrow_shared_tensor: this model is a draft head without its own 'token_embd.weight'; load it as a draft of its target model, not on its own
Там же в логе видно предупреждение n_ctx_seq (393216) > n_ctx_train (262144) -- possible training context overflow: запрошенный контекст превышает тренировочный. Это не обязательно означает поломку, но сигнализирует о риске деградации на больших окнах.
Утверждать, что вы столкнётесь ровно с этими ошибками, нельзя. Поведение зависит от версии llama.cpp, сборки драфтера и драйверов. Ошибки воспроизводились в конкретных условиях и в самом отчёте о конфигурации не упоминаются как решённые.
Скорость генерации: 14-15 токенов/с на коротких контекстах и просадка на длинных
Заявленные цифры выглядят так. На коротких и средних контекстах генерация держится на уровне 14-15 токенов/с. Это выше порога комфорта: большинство людей читает быстрее, чем модель печатает, но разница не настолько велика, чтобы ожидание раздражало. Для чат-сценариев и черновиков такой темп рабочий.
| Сценарий | Скорость |
|---|---|
| Генерация, короткий и средний контекст | 14-15 токенов/с |
| Генерация на контексте 90-100K | 11,3 токенов/с |
| Обработка промпта 20K | 104,7 токенов/с |
| Ожидание первого вывода на промпте 20K | около 3 минут |
| Максимальный протестированный контекст | 128K |
Почему скорость падает на длинном контексте
Падение с 14-15 до 11,3 токенов/с при росте контекста до 90-100K - закономерность, а не аномалия. Складываются две причины. Первая: механизм внимания обрабатывает все предыдущие токены, и вычислительная нагрузка растёт вместе с длиной окна. Вторая: если часть слоёв выгружена на диск, при длинном контексте чаще происходят обращения к NVMe. Автор отчёта точные причины не разбирал, поэтому ограничимся этими общими механизмами: вклад каждого фактора в его системе не измерялся.
Просадка примерно на четверть выглядит умеренной. Модель не срывается в единицы токенов в секунду, что для схемы с подкачкой с SSD можно считать неплохим результатом. Если узкое место смещается в сторону подкачки KV-кэша, помочь может стриминг KV из оперативной памяти: об этом подходе в форке llama.cpp мы писали в разборе адаптивного KV-стриминга от tsangberg.
Обработка промпта 20K: 104,7 токенов/с и 3 минуты ожидания
Отдельная цифра, которую легко пропустить: промпт на 20 000 токенов обрабатывается со скоростью 104,7 токенов/с, и до начала вывода проходит около трёх минут. Это время уходит на префилл, то есть на чтение и обсчёт входного текста. Пользователь в это время не видит ни одного сгенерированного токена.
Три минуты меняют сценарии использования. Для интерактивного чата, где вы задаёте вопрос и ждёте ответа, это много: разговор становится тягучим. Для пакетных задач, где вы один раз загрузили большой документ и потом задаёте десятки вопросов, ожидание уже не выглядит критичным, потому что префилл выполняется один раз.
Качество вывода: сопоставимо ли IQ3_XXS с Q6-Q8?
Автор утверждает, что качество вывода сопоставимо с квантованием Q6-Q8 от Unsloth. Разрыв между 3 битами на вес и 6-8 битами выглядит слишком большим, чтобы принимать такое заявление на веру, поэтому разберём, что здесь можно утверждать, а что нет.
Что такое IQ3_XXS и 2,40 bpw
bpw расшифровывается как bits per weight, то есть сколько бит приходится на один вес модели. IQ3_XXS - формат квантования в экосистеме llama.cpp, где на вес приходится примерно 3 бита. Чем меньше бит, тем компактнее файл и тем меньше памяти он требует. Плата за сжатие - потенциальная потеря точности: агрессивное квантование может заметнее искажать редкие случаи, длинные цепочки рассуждений и вызовы инструментов.
Версия 2,40 bpw, которую автор только планирует протестировать, сжимает сильнее. Для сравнения он приводит NVFP4 и Q4: четыре бита на вес и разреженный 4-битный формат соответственно. Логика простая: чем ниже bpw, тем больше шансов уместить модель в 12 ГБ VRAM, но и тем выше риск, что качество просядет на сложных задачах.
Почему заявление о качестве требует осторожности
Оценка «сопоставимо с Q6-Q8» субъективна. В отчёте нет ни публичных бенчмарков, ни слепого сравнения, ни набора задач, по которому выставлялись оценки. Один и тот же ответ две модели могут восприниматься по-разному в зависимости от того, что вы проверяете: связность текста, следование инструкции, работу с кодом или вызов инструментов. Квантование чаще всего бьёт именно по редким, но критичным случаям, которые не попадаются в коротком тесте.
Поэтому корректная формулировка такая: пользователь не увидел заметной для себя разницы на своих задачах. Из этого не следует, что IQ3_XXS равен Q6-Q8 вообще. Проверять нужно на своём сценарии, а сравнение агрессивного и умеренного квантования на одной линейке моделей мы разбирали в материале про IQ1_S против Q4: экономия памяти там реальная, а потеря качества зависит от задачи.
Практические выводы: кому подходит такая конфигурация
Собирать подобное имеет смысл, если у вас уже есть 12-16 ГБ VRAM и хотя бы 32-64 ГБ оперативной памяти, а задачи допускают ожидание. Если нужен быстрый отклик в диалоге или предсказуемое качество на сложных инструкциях, схема разочарует.
Сценарии, где это может быть полезно
- Разбор больших документов: контекст до 128K позволяет загрузить объёмный текст целиком и задавать по нему вопросы.
- Длинные диалоги и накопление истории, когда важнее удержать весь контекст, чем печатать быстро.
- Исследовательские и учебные прогоны, где вы хотите посмотреть, как модель ведёт себя на своих данных, не платя за API.
- Пакетная обработка: один дорогой префилл на 20K и затем серия коротких ответов.
Ограничения и риски
- Скорость генерации падает до 11,3 токенов/с на контексте 90-100K, а поведение выше 128K автор не проверял.
- Три минуты ожидания перед первым токеном на промпте 20K.
- Зависимость от NVMe: чем больше весов уходит на диск, тем сильнее всё упирается в его пропускную способность.
- Известные баги с MTP-драфтером в llama.cpp, включая падение llama-server с кодом -6 и ошибку загрузки драфтера без целевой модели.
- Результаты не воспроизводились независимо, качество оценивалось без бенчмарков.
- Тест версии 2,40 bpw только в планах, результатов пока нет.
Если у вас 6 ГБ VRAM, ориентироваться на эти цифры напрямую нельзя: там придётся выбирать между более агрессивными квантами и заметно меньшим контекстом, что разобрано в статье о запуске Qwen 3.8 Flash Next на 6 ГБ VRAM.
Что дальше: планы автора и альтернативы
Автор отчёта собирается протестировать версию 2,40 bpw и сравнить её по качеству с NVFP4 и Q4. Пока это намерение: результатов, цифр и выводов нет. Если сжатие до 2,40 bpw действительно удержит качество на уровне 4-битных вариантов, требования к диску и памяти заметно снизятся. До появления данных рассчитывать на это рано.
Альтернатива для тех же 12 ГБ VRAM - модель меньшего масштаба. Qwen3.8-27B с 27 млрд рабочих параметров в умеренном квантовании помещается в память без экзотических схем с подкачкой с SSD, а её результат в Intelligence Index составляет 41 балл. Контекста в 128K там не будет, зато скорость и предсказуемость окажутся выше, а настройка проще.
Практический шаг, если вы хотите повторить эксперимент: возьмите тот же GGUF в IQ3_XXS, посмотрите, сколько слоёв реально уходит на диск на вашей системе, и прогоните свой типовой промпт на 20K, замерив время до первого токена. Решение принимать по этим двум числам, а не по чужим 15 токенам в секунду.