Qwen 3.8 Next Flash при локальном запуске: почему падает производительность с ростом контекста и какие флаги llama.cpp помогают

Пользователь r/LocalLLaMA опубликовал пост о том, что не может стабилизировать Qwen 3.8 Next Flash при локальном запуске. Все эксперты модели, кроме грамматического, размещены в VRAM, но производительность остаётся неудовлетворительной. Самая заметная проблема - резкое падение скорости по мере роста контекста: чем длиннее промпт и история диалога, тем медленнее идёт генерация.

Для сравнения он приводит Qwen 3.8, которая, по его опыту, работает стабильнее, и просит сообщество поделиться подходящими флагами llama.cpp. Данных о конфигурации железа, версии модели и замерах в посте нет. Это опыт одного человека, а не подтверждённый результат, и воспринимать его стоит как сигнал "здесь что-то не так", а не как готовый диагноз.

Короткий ответ на главный вопрос: перенос экспертов в VRAM снимает часть задержек, но не отменяет рост KV-кэша и не гарантирует стабильную скорость на длинном контексте. Причина просадки почти всегда лежит в одном из трёх мест: не хватает видеопамяти под растущий кэш, упирается пропускная способность памяти GPU или часть вычислений уходит на CPU. Ниже - как проверить каждую версию и какие ключи llama.cpp имеют смысл.

Похожие жалобы всплывают у всех, кто гоняет MoE-модели на бытовом железе. Схема "все эксперты в VRAM" давно стала народным рецептом, и когда она не срабатывает, начинается перебор флагов без понимания того, что именно тормозит. Если вы ещё не разбирались, что это за модель и почему её часто путают с Qwen4, полезно начать с материала о том, что такое Qwen3.8-Flash-Next.

Почему скорость может падать с ростом контекста: технические причины

Рост контекста бьёт по двум местам сразу: увеличивается KV-кэш и растёт нагрузка на механизм внимания. Лечатся эти проблемы разными настройками, поэтому разберём их отдельно. Дальше речь о механике локального инференса, а не об измеренных данных конкретного пользователя: замеров в его сообщении нет.

Роль VRAM и экспертов в MoE-моделях

В MoE-архитектуре веса разбиты на наборы-эксперты, обычно это блоки прямого прохода. На каждом токене роутер выбирает несколько экспертов, и считаются только они. Если Qwen 3.8 Next Flash построена по этой схеме, полный набор экспертов всё равно должен где-то лежать в памяти, а активных за шаг немного.

Что даёт перенос экспертов в VRAM: их веса не приходится тянуть через PCIe на каждом шаге генерации. Обычно это и есть главный источник ускорения. Автор поста такую оптимизацию сделал, оставив вне видеопамяти только грамматический эксперт, и результата не получил.

Дальше начинается арифметика памяти. VRAM занята не одними весами модели: там же KV-кэш, буферы для вычислений, граф-буферы CUDA и служебные структуры. Простой пример: модель с экспертами занимает 20 ГБ из 24 ГБ. На коротком промпте свободных 4 ГБ хватает с запасом, на длинном контексте кэш съедает их, и система начинает вытеснять данные, перекладывать слои или обращаться к системной RAM. Каждое лишнее обращение стоит микросекунды, а на каждый токен таких обращений тысячи.

Эксперт, оставшийся вне GPU, добавляет задержку на каждом токене: его веса приходится подгружать или считать на CPU. Если он активен часто, просадка копится, и потому "почти всё в VRAM" не равно "всё быстро".

Как контекст влияет на KV-кэш и пропускную способность памяти

KV-кэш растёт линейно с длиной контекста. Чем больше слоёв и голов внимания у модели, тем быстрее он съедает память: на 32k токенов в fp16 это уже гигабайты, а не мегабайты. Кэш приходится читать и записывать на каждом шаге генерации, так что узким местом становится пропускная способность памяти GPU.

Отсюда типовая картина: на 2k токенов скорость нормальная, на 8k падает примерно вдвое, на 16k работать неприятно. Пропускная способность карты при этом не меняется, растёт объём данных на каждый токен.

Часть давления снимает квантизация KV-кэша. В llama.cpp за неё отвечают --cache-type-k и --cache-type-v: значение q8_0 уменьшает объём кэша примерно вдвое без заметной потери качества, более агрессивные варианты экономят сильнее, но на длинном контексте качество проседает. По умолчанию кэш обычно хранится в fp16, так что этот резерв часто остаётся неиспользованным. Как считать бюджет памяти под кэш на конкретной карте, разобрано в материале про Qwen3.8-27B в Q4_K_M на RTX 5080.

Ещё одна версия, которую стоит держать в голове: при длинных контекстах меняется то, как llama.cpp раскладывает данные между устройствами. Наблюдения из разбора про VRAM, PLE и контекст показывают, что перенос отдельных частей модели между CPU и GPU даёт провалы, которые легко принять за свойство самой модели или GPU. Точная причина в случае пользователя не установлена: все перечисленные версии остаются гипотезами до замеров.

Какие флаги llama.cpp стоит попробовать для стабилизации Qwen 3.8 Next Flash

Набора флагов, который гарантированно лечит просадку на длинном контексте, не существует. Эффект зависит от версии llama.cpp, сборки под вашу карту, драйвера и самой модели. Меняйте по одному параметру и замеряйте токены в секунду на одинаковых промптах, иначе выводы будут случайными.

Параметр	Что делает	На что смотреть
--n-gpu-layers (-ngl)	Задаёт, сколько слоёв выгружается на GPU	Поднимайте до предела без OOM и проверяйте не на коротком промпте, а на длинном контексте
--override-tensor (-ot)	Точечно управляет размещением тензоров, включая экспертов MoE	Основной инструмент, если часть экспертов нужно убрать из VRAM ради KV-кэша
--split-mode, --tensor-split	Делит слои и тензоры между несколькими GPU	На одной карте эффекта не дают
--cache-type-k, --cache-type-v	Определяет тип данных KV-кэша	q8_0 обычно безопасен, q4_0 экономит больше, но качество может просесть
--flash-attn	Считает внимание блоками с меньшим расходом памяти	Поддержка зависит от GPU и сборки, на части конфигураций не даёт эффекта
--ctx-size	Задаёт длину контекста	Ставьте по задаче: 8k вместо 32k освобождает гигабайты и возвращает скорость
--batch-size, --ubatch-size	Размер пакета при обработке промпта	Меньшие значения снижают пик памяти, но prefill идёт медленнее
--no-mmap, --mlock	Отключают mmap и запрещают выгрузку в swap	--mlock требует запаса RAM, иначе система начнёт душить процесс
--threads, --numa	Настраивают CPU-часть вычислений	Число потоков ставьте по физическим ядрам, а не по логическим

Флаги для управления VRAM и распределением слоёв

--n-gpu-layers решает, сколько слоёв уходит на GPU. Если эксперты уже в видеопамяти, попробуйте поднять число слоёв до предела, при котором ещё нет OOM, и отдельно проверьте поведение на длинном контексте. Настройка, которая держится на коротком промпте, легко рассыпается на 16k токенов.

--override-tensor задаёт размещение отдельных тензоров, включая экспертов MoE. Флагами вида -ot "exps=CPU" часть экспертов переносят в RAM, чтобы освободить видеопамять под KV-кэш. Для схемы "почти всё в VRAM, кроме одного эксперта" это основной инструмент тонкой настройки, и перебор вариантов здесь даёт больше, чем смена общих ключей.

--split-mode и --tensor-split нужны на нескольких GPU: они определяют, как делить слои и тензоры между картами. На одной видеокарте эти ключи ничего не меняют, сколько их ни перебирай.

--no-mmap отключает отображение файла модели в память, и иногда это снимает лишнюю нагрузку на диск. --mlock запрещает выгрузку в swap, но требует запаса RAM. Оба флага способны как помочь, так и сделать хуже, поэтому проверяйте их по отдельности.

Флаги для оптимизации KV-кэша и внимания

Комбинация --cache-type-k q8_0 --cache-type-v q8_0 - самый предсказуемый способ сократить кэш, и именно она чаще всего даёт прирост на длинном контексте. Переход на q4_0 экономит ещё больше, но качество ответов и стабильность длинного контекста могут пострадать: сначала проверьте на своих задачах, потом решайте.

--flash-attn включает flash attention: вычисления внимания идут блоками, памяти нужно меньше, скорость часто выше. Поддержка зависит от GPU и сборки, на части конфигураций флаг не даёт эффекта или работает нестабильно.

--ctx-size стоит выставлять по задаче. Если реально нужны 8k токенов, держать 32k нет смысла: вы платите памятью и скоростью за неиспользуемый запас, а именно этого запаса и не хватает под другие данные.

--batch-size и --ubatch-size влияют на пиковое потребление памяти при обработке промпта. Уменьшение снижает пик и риск OOM, но prefill становится медленнее: длинный промпт будет обрабатываться дольше.

Дополнительные параметры: потоки, NUMA и mmap

--threads имеет смысл ставить по числу физических ядер, а не логических: гипертрединг в CPU-части вычислений часто добавляет конкуренцию за память. --numa помогает на многосокетных системах, где важен доступ к локальной памяти.

Порядок перебора, который экономит время: сначала --ctx-size и тип KV-кэша, затем --n-gpu-layers и -ot, после них --flash-attn, и только в конце CPU-параметры. Замеряйте каждую конфигурацию минимум на двух длинах контекста, иначе просадка просто не попадёт в ваши цифры.

Как диагностировать узкое место: пошаговый план

Перебор флагов без замеров превращается в лотерею. Порядок действий, который отвечает на вопрос "что именно тормозит", выглядит так.

1. Зафиксируйте версию llama.cpp с указанием commit, точное имя файла модели, версию драйвера и ОС. Без этого любые сравнения бессмысленны.
2. Замерьте токены в секунду на нескольких длинах контекста: 512, 2048, 4096, 8192, 16384. Один и тот же промпт, одинаковая температура, несколько прогонов.
3. Следите за VRAM во время генерации: подойдут nvidia-smi, rocm-smi или системный монитор. Смотрите не только занятый объём, но и момент, когда он упирается в предел.
4. Проверьте логи llama.cpp с подробным выводом: там видно, сколько слоёв и тензоров реально ушло на GPU. Фразу "все эксперты в VRAM" стоит подтвердить логом, а не строкой запуска.
5. Посмотрите, растёт ли нагрузка на CPU при увеличении контекста. Если да, часть вычислений уходит на процессор, и видеопамять тут уже ни при чём.
6. Сравните с Qwen 3.8 на тех же промптах и том же железе. Разная архитектура даст разное поведение, но цифры нужны свои.

Какие данные собрать для обращения к сообществу

Чтобы вопрос вроде поста получил ответ, к нему стоит приложить полный контекст эксперимента, а не только описание симптома.

Список: версия llama.cpp и способ сборки; имя файла модели и квантизация; полная командная строка запуска; GPU, объём VRAM, RAM, модель CPU; таблица токенов в секунду на разных длинах контекста; вывод утилиты мониторинга в момент просадки; логи llama.cpp. Такой набор позволяет воспроизвести ситуацию на другом железе, а без него остаётся только угадывать.

Qwen 3.8 Next Flash vs Qwen 3.8: что может объяснять разницу в стабильности

Сравнение в посте строится на одной фразе: Qwen 3.8 работает стабильнее, чем Qwen 3.8 Next Flash. Это личное наблюдение без цифр, и универсальным выводом оно быть не может.

Гипотезы, которые стоит проверить. Первая: разная архитектура. Если одна модель плотная (dense), а вторая MoE, у плотной нет роутера и пересылок экспертов, и на длинном контексте она ведёт себя предсказуемее при том же объёме памяти. Вторая: разное число экспертов и, значит, разный объём служебных вычислений на каждом токене. Третья: оптимизации в llama.cpp заточены под конкретные архитектуры сильнее, чем под другие, и новая модель может просто ждать обновлений.

Отдельный фактор - условия запуска. Разные квантизации, разные длины контекста и разные версии llama.cpp дают настолько разную картину, что лобовое сравнение двух моделей часто некорректно. Как именно условия меняют результат, разобрано в материале про Qwen 3.8 Flash Next на сервере с большим объёмом RAM и слабой GPU.

Стоит ли запускать Qwen 3.8 Next Flash локально: ограничения и альтернативы

Ответ зависит от сценария, и обещать стабильность на длинном контексте сейчас никто не может. Опыт пользователя показывает, что даже почти полная загрузка экспертов в VRAM не гарантирует приемлемую скорость.

Сценарии, где модель имеет смысл пробовать: 24 ГБ VRAM и больше, готовность экспериментировать с -ot и типами KV-кэша, рабочие контексты в пределах 8-16k токенов. Здесь есть шанс получить нормальную скорость при разумных настройках.

Сценарии, где время лучше потратить иначе: скорость критична, контексты длинные и стабильные, а тюнинг не входит в планы. Разумно подождать обновлений llama.cpp и оптимизаций от сообщества или взять модель, которая на вашем железе уже ведёт себя предсказуемо.

Альтернативы: Qwen 3.8, которая по опыту автора поста стабильнее, и модели с меньшим числом экспертов, где бюджет памяти проще. Как выбор квантизации влияет на длинный контекст, показано в разборе Q2 и Q3 для Qwen 3.8 27B: там же описаны признаки того, что экономия памяти обошлась слишком дорого. Локальный запуск даёт приватность и контроль, но требует времени на настройку, и это честная часть сделки.

Что в итоге: практические выводы для локального запуска Qwen 3.8 Next Flash

Чек-лист, если вы попали в похожую ситуацию:

• Начните с диагностики, а не с перебора флагов: замеры на 512, 2048, 4096, 8192 и 16384 токенах покажут, где именно ломается кривая скорости.
• Проверьте по логам, сколько слоёв и экспертов реально на GPU. Настройка и факт - разные вещи.
• Меняйте по одному: --ctx-size по задаче, --cache-type-k q8_0 и --cache-type-v q8_0, --flash-attn, --n-gpu-layers, -ot для экспертов, затем --batch-size и --ubatch-size.
• Если просадка осталась, зафиксируйте конфигурацию и поделитесь логами и цифрами в сообществе.
• Держите в запасе альтернативу на своём железе, чтобы рабочие задачи не зависели от одной модели.

Главное ограничение этого материала: все исходные утверждения взяты из одного сообщения в r/LocalLLaMA, где нет ни конфигурации железа, ни замеров. Проблема с падением скорости при росте контекста у этого пользователя реальна, но её причины пока не подтверждены. Чем больше людей соберут собственные цифры и поделятся ими, тем быстрее найдётся рабочая комбинация флагов и стабильная конфигурация для Qwen 3.8 Next Flash.

Подписаться на канал