Qwen 3.8 Flash Next в квантизации Q6_K_XL можно запустить локально на конфигурации из четырёх RTX 3090 через llama-server. Главная проблема начинается после загрузки весов: свободную VRAM быстро расходуют KV-кэш, временные буферы и обработка длинного промпта. Поэтому четыре карты дают необходимый запас для тяжёлой сборки, но не превращают её в быстрый и безусловно стабильный рабочий режим.
Прямого бенчмарка именно Q6_K_XL на 4x RTX 3090 в доступных материалах нет. Числа из похожих запусков нужно использовать как ориентиры: prefilling встречается в диапазоне примерно 59-87 tokens/s, а generation держится около 7-10 tokens/s. Для ежедневной работы чаще разумнее выбрать Q4_K_XL, а Q6_K_XL оставить для задач, где приоритетом выступает качество и допустима более строгая настройка памяти.
Короткий ответ: Q6_K_XL запускается, но память важнее самого факта загрузки
Схема с 4x RTX 3090 подходит для размещения тяжёлой Q6_K_XL, если llama-server корректно распределяет слои по GPU и в системе хватает памяти под служебные структуры. При этом сам факт, что модель загрузилась, ещё не подтверждает пригодность сервиса: OOM может появиться при длинном запросе, увеличении batch или работе с несколькими слотами.
В описываемом режиме используются mmap, --load-mode none, --split-mode layer, --ctx-size 200000, мульти-GPU раскладка и отключённая KV-квантизация. Заявленный размер контекста выступает параметром запуска. Безопасный предел для конкретной системы может оказаться ниже, поскольку его определяют свободная VRAM, распределение слоёв, размер запроса и временные буферы.
Что можно утверждать по имеющимся данным
Подтверждённые наблюдения описывают несколько режимов, но не дают точного результата для Q6_K_XL на четырёх RTX 3090:
- увеличение
batchиubспособно дать кратный прирост prefilling на больших промптах; - высокие значения
batchиubпотребляют дополнительную видеопамять; - для Qwen3.8-Flash-Next IQ4_XS при 64 ГБ RAM приводится ориентир около 50 tokens/s на prefilling;
- на схеме 16 ГБ VRAM + 32 ГБ RAM + NVMe встречаются значения около 20 tokens/s на prefilling и около 10 tokens/s на генерации, но режим описан как нестабильный;
- в логах похожей сессии prompt processing проходит примерно на уровне 59-87 tokens/s, а generation составляет около 7-10 tokens/s.
Эти показатели нельзя переносить на Q6_K_XL механически. На результат влияют файл GGUF, версия llama.cpp, длина промпта, размер контекста, batch, ub, распределение слоёв и состояние памяти всех GPU.
Почему Qwen 3.8 Flash Next особенно чувствительна к памяти
Потребление памяти складывается из нескольких частей. Вес квантизированной модели занимает основной объём, но после загрузки остаются KV-кэш, рабочая область вычислений, буферы для prompt processing и служебные структуры мульти-GPU режима. При длинных запросах свободная память сокращается ещё до начала генерации ответа.
Q6_K_XL оставляет меньше запаса, чем Q4_K_XL. Разница проявляется в выборе контекста, устойчивости к большим batch и возможности обслуживать несколько запросов. На четырёх RTX 3090 суммарный объём VRAM помогает разместить модель, однако распределённая память не всегда ведёт себя как единый бесконечный пул: отдельной карте может не хватить места под слой или буфер, даже если на остальных GPU свободно больше.
Контекст, KV-кэш и причина OOM
Параметр --ctx-size 200000 задаёт верхнюю планку контекста для сервера. Он не гарантирует, что любой запрос на 200 000 токенов завершится без ошибки памяти. При росте контекста увеличивается KV-кэш, в котором сервер хранит состояния уже обработанных токенов. Чем больше окно, тем больше VRAM или другой доступной памяти требуется для продолжения диалога.
В описываемой схеме KV-квантизация отсутствует. Это упрощает интерпретацию результата, но оставляет KV-кэш в более требовательном формате. Связка большой квантизации весов и длинного контекста быстро сокращает запас памяти, особенно если одновременно повышать batch и ub.
Поэтому практический порядок выглядит так:
- запустить сервер с заявленным значением контекста;
- проверить короткий запрос;
- постепенно увеличить длину входного промпта;
- зафиксировать момент роста потребления памяти или OOM;
- снизить контекст до устойчивого значения и только затем подбирать batch и ub.
Если ошибка появляется во время длинного запроса, успешная загрузка весов не считается достаточной проверкой. Сначала уменьшают контекст или нагрузку на KV-кэш, затем проверяют batch и ub.
Почему prefilling становится узким местом
Prefilling, или prompt processing, обрабатывает входной текст до появления первого нового токена. Generation, или decode, создаёт ответ последовательно. Эти стадии используют память и вычислительные ресурсы по-разному, поэтому одна цифра tokens/s не описывает весь пользовательский опыт.
Длинный prompt увеличивает время до первого токена, то есть TTFT. При этом последующая генерация может идти с другой скоростью. Для Qwen3.8-Flash-Next в предоставленных наблюдениях длинные входы обрабатывались примерно на 59-87 tokens/s в одной похожей сессии, тогда как generation находилась около 7-10 tokens/s. Это ориентир по поведению конкретного режима, а не измерение Q6_K_XL на 4x RTX 3090.
Рост batch и ub помогает эффективнее загружать GPU во время prefilling. Цена ускорения, дополнительная память. Если свободного запаса мало, увеличение параметров способно дать прирост на одном запросе и одновременно сделать длинный контекст нестабильным.
Запуск Qwen 3.8 Flash Next локально через llama-server
Для повторения схемы нужна сборка llama-server с поддержкой используемой модели и CUDA для RTX 3090. Затем указывают GGUF-файл Q6_K_XL, включают раскладку по нескольким GPU и задают параметры загрузки. Полную команду с конкретными значениями GPU-слотов, batch и ub нельзя корректно восстановить из имеющихся данных, поэтому эти параметры придётся подобрать под конкретную систему.
Опорный набор настроек выглядит так:
mmap
--load-mode none
--split-mode layer
--ctx-size 200000
multi-GPU layer split
KV quantization: disabledЭто схема параметров, а не готовая универсальная команда. Имена и синтаксис отдельных опций зависят от версии сборки. Перед запуском нужно сверить их с выводом llama-server --help.
Зачем нужны mmap и --load-mode none
mmap отображает файл модели через механизм memory mapping. Сервер получает доступ к данным модели через отображённый файл, а фактическое поведение памяти зависит от операционной системы, загрузчика и выбранной раскладки. Этот параметр полезно рассматривать как часть общей схемы работы с файлом весов, а не как способ увеличить доступную VRAM.
--load-mode none входит в описанный режим загрузки. Его назначение нужно проверять по версии конкретного сервера, поскольку смысл и доступность опции зависят от сборки. При диагностике фиксируют сам факт принятия параметра, сообщения о загрузке модели и распределение памяти после старта.
Ошибочно ожидать, что mmap или --load-mode none сами по себе решат проблему нехватки VRAM. Они задают способ обращения загрузчика с моделью, но не отменяют требования к KV-кэшу, рабочим буферам и контексту.
Как работает --split-mode layer на нескольких GPU
--split-mode layer распределяет слои модели между видеокартами. В конфигурации 4x RTX 3090 это позволяет разместить тяжёлую сборку, которая не помещается на одной карте. Каждая RTX 3090 получает часть слоёв, а сервер организует передачу данных между устройствами.
Идеального масштабирования ждать не следует. На результат влияют баланс слоёв, свободная VRAM на каждой карте, служебные буферы и скорость обмена между GPU. Если одна карта получила слишком тяжёлую часть, она способна стать ограничителем для всей генерации.
Распределение нужно проверять по логам и мониторингу. Суммарные 96 ГБ VRAM, которые дают четыре RTX 3090, не означают, что все 96 ГБ доступны под веса и кэш без накладных расходов. Часть памяти занимает сама CUDA-среда, часть нужна для вычислений и обмена.
Какие строки логов подтверждают корректный запуск
В логах описанной сессии есть несколько полезных признаков:
load_model: loaded multimodal model, сервер распознал модель как мультимодальную и завершил загрузку;n_ctx_slot = 131072, для слота установлен контекст 131 072 токена;kv_unified = 'true', включён unified KV-cache;- строка о прослушивании HTTP на
0.0.0.0:5813, сервер открыл сетевой порт.
n_ctx_slot = 131072 нельзя автоматически считать безопасным пределом для каждого запроса. Это значение из лога конкретной сессии. Параметр --ctx-size 200000 в командной схеме и фактический размер слота в логе могут различаться из-за настроек сервера, ограничений сборки или выбранного режима обслуживания.
Готовность HTTP-сервера означает, что процесс принимает соединения. Она не подтверждает устойчивость длинного prefilling или генерации при заполненном KV-кэше.
Qwen 3.8 Flash Next Q6_K_XL: как читать скорость без самообмана
В тестах локальных LLM нужно разделять обработку входа и создание ответа. Смешивание этих стадий приводит к неправильным выводам: высокая скорость prompt processing не означает такой же скорости generation, а быстрый decode не компенсирует большой TTFT на длинном документе.
Prefilling и generation speed, это разные показатели
Prefilling показывает, как быстро сервер обрабатывает уже переданный текст. Показатель особенно важен для RAG, анализа документов, программного кода и длинных инструкций.
Generation speed показывает скорость создания новых токенов после обработки входа. Для короткого запроса именно она сильнее влияет на ощущение плавности диалога. При длинном prompt пользователь сначала ждёт TTFT, затем наблюдает generation.
В логах похожего запуска встречаются значения prompt processing 78.31, 87.22, 59.40, 67.01 и 65.60 tokens/s. Для n_gen указаны значения примерно 7.07-8.06 tokens/s, а кратковременный показатель tg_3s доходил до 10.96 tokens/s. Такие цифры нужно читать вместе с длиной входа, контекстом и настройками сервера.
Как batch и ub влияют на throughput
batch задаёт объём работы, который сервер способен обрабатывать в одной общей пачке. ub, microbatch, ограничивает размер отдельного шага вычислений. Большие значения могут заметно ускорить prefilling на длинных промптах, поскольку GPU получает более крупные порции работы.
Плата за throughput, дополнительное потребление VRAM. На конфигурации, где Q6_K_XL уже занимает большую часть доступного пространства, агрессивный рост параметров способен вызвать OOM раньше, чем закончится обработка входа.
Подбирать значения нужно ступенчато. После каждого изменения записывают скорость, пик VRAM, объём RAM и факт завершения запроса. Если увеличение batch ускорило prefilling, но сделало длинные запросы нестабильными, для рабочего режима оно не принесло практической пользы.
Какие метрики записывать при сравнении режимов
| Метрика | Что фиксировать | Зачем нужна |
|---|---|---|
| Версия сервера | Версия llama.cpp или llama-server | Разные сборки могут по-разному распределять память и считать скорость |
| Модель | Точный GGUF и Q6_K_XL или Q4_K_XL | Сравнение квантов должно проходить на конкретных файлах |
| Вход | Длина и содержание prompt | Prefilling сильно зависит от объёма входного текста |
| Контекст | Заданный и фактически использованный размер | Показывает запас под KV-кэш |
| Настройки | batch, ub, число GPU и split mode | Позволяет повторить режим |
| Скорость | Prefilling, generation, TTFT | Разделяет задержку до первого токена и скорость ответа |
| Память | VRAM каждой карты и системная RAM | Помогает найти конкретный ограничитель |
| Стабильность | Завершение запроса без OOM | Отделяет разовый запуск от пригодного сервиса |
Для сравнения Q6_K_XL и Q4_K_XL нужно оставить одинаковыми prompt, контекст, batch, ub, число GPU и версию сервера. Иначе разница в tokens/s может объясняться настройками, а не квантизацией.
Q6_K_XL или Q4_K_XL: что выбрать для ежедневной работы
Выбор между двумя квантизациями сводится к балансу качества, размера весов, скорости и свободной памяти под контекст. Q6_K_XL требует более тяжёлой конфигурации. Q4_K_XL оставляет больше пространства для KV-кэша и рабочих буферов, поэтому чаще подходит для регулярных запросов.
Когда Q4_K_XL рациональнее
Q4_K_XL логично выбрать для ежедневных диалогов, частой работы с длинными промптами, RAG-сценариев и ситуаций, где важна стабильная отзывчивость. Запас памяти можно направить на контекст или более крупные batch и ub, если конкретный сервер получает от этого измеримый прирост.
Более лёгкий квант не гарантирует лучший результат во всех задачах. Его преимущество проявляется в требованиях к памяти и удобстве настройки. Итоговую скорость всё равно нужно измерять на своей сборке, поскольку файл GGUF и раскладка по GPU влияют на результат.
При выборе между Q4, Q5 и Q6 полезно учитывать размер VRAM, RAM, способ offload и желаемый контекст. Практический разбор таких компромиссов для более ограниченной конфигурации есть в статье о выборе квантизации Qwen 3.8 Flash Next.
Когда Q6_K_XL имеет смысл держать как запасной вариант
Q6_K_XL подходит для контрольных прогонов, сравнения ответов и сложных задач, где пользователь готов пожертвовать скоростью ради потенциально меньшей потери качества при квантовании. Такой режим полезен и при проверке результата перед публикацией или передачей в рабочий процесс.
Запасной режим лучше держать с заранее установленным устойчивым контекстом и известными значениями batch и ub. Иначе запуск тяжёлой модели каждый раз превращается в подбор параметров с риском OOM.
Для архитектурных сравнений с другими локальными конфигурациями полезен материал о запуске Qwen3.8-Flash-Next на четырёх R9700 через vLLM: разбор мульти-GPU запуска через vLLM. Его цифры нельзя переносить на RTX 3090, но подход к проверке памяти, prefill и generation остаётся применимым.
Если основная задача связана с программированием и частыми длинными запросами, полезно отдельно изучить влияние KV-cache, speculative decoding и распределения нагрузки в локальном стеке для Qwen 3.8 27B на двух RTX 3090: практический разбор конфигурации на двух RTX 3090.
Практический чек-лист перед запуском на 4x RTX 3090
Перед стартом нужно проверить не одну общую цифру VRAM, а состояние каждой части системы:
- свободную VRAM на всех четырёх RTX 3090;
- объём системной RAM;
- свободное место и скорость NVMe;
- версию llama-server и поддержку нужной модели;
- целостность и точное имя GGUF-файла;
- режим
--split-mode layerи распределение слоёв; - заданный контекст и предполагаемый безопасный предел;
- значения
batchиub; - наличие строк о загрузке мультимодальной модели, unified KV и HTTP-листенинге.
Как отличить нехватку памяти от проблем с настройкой
Сначала нужно сохранить полный лог запуска и определить момент ошибки. Сбой при чтении файла или инициализации GPU указывает на проблему сборки, пути к модели или параметров запуска. Ошибка после распределения слоёв может говорить о нехватке памяти на конкретной карте. OOM во время длинного prompt чаще связан с контекстом, KV-кэшем или временными буферами.
Полезно смотреть нагрузку и свободную память отдельно на каждой GPU. Если одна карта заполнена заметно сильнее остальных, причина может быть в балансе split, а не в недостатке общей VRAM. Если все карты имеют запас, но процесс использует много RAM и обращается к NVMe, ограничителем может стать host memory или обмен данными.
Изменения вносят по одному. Сначала проверяют контекст, затем batch и ub, после этого оценивают раскладку слоёв. Одновременная смена пяти параметров скрывает причину сбоя.
Минимальный протокол проверки стабильности
- Запустить короткий запрос и убедиться, что сервер возвращает ответ.
- Повторить несколько последовательных запросов и проверить, не растёт ли расход памяти.
- Подать длинный prompt с заранее известным размером.
- Проверить выбранный верхний предел контекста.
- Записать prefilling, generation, TTFT, VRAM, RAM и факт завершения без OOM.
- Повторить тот же протокол для Q4_K_XL, сохранив остальные параметры.
Проверка должна включать сценарий, ради которого модель запускается. Если сервер выдерживает короткий диалог, но падает на документе или большом запросе, конфигурация пригодна лишь для ограниченного режима. Запись одного удачного ответа не заменяет проверку серии запросов.
Итог: тяжёлая сборка для качества, лёгкая для рабочего темпа
Qwen 3.8 Flash Next Q6_K_XL запускается на 4x RTX 3090 через llama-server, но рабочий результат определяется запасом памяти после загрузки весов. Контекст, KV-кэш, batch, ub и распределение слоёв влияют на стабильность сильнее, чем сам факт наличия четырёх GPU.
Для Q6_K_XL нельзя честно назвать точные tokens/s без прямого замера на этой конфигурации. Доступные ориентиры показывают, что prefilling может находиться примерно в диапазоне 59-87 tokens/s, а generation, около 7-10 tokens/s в похожих сессиях. Эти значения помогают понять порядок поведения, но не заменяют собственный тест.
Практичная схема выбора выглядит так: Q4_K_XL использовать как основной ежедневный режим, когда важны запас по памяти и стабильная работа, Q6_K_XL держать для контрольных и более требовательных задач. Сначала нужно найти устойчивый контекст и измерить обе сборки на одинаковом протоколе. После этого станет понятно, оправдывает ли потенциальное преимущество Q6_K_XL потерю скорости и свободной VRAM.