Запуск Qwen3 27B на 16 ГБ VRAM: квантизация IQ3_XXS, контекст 128K и 35 t/s в llama.cpp

Можно ли запустить Qwen3 27B на 16 ГБ VRAM

Да, запускается, но не «в лоб». Чтобы уложить 27B в 16 ГБ и сохранить контекст 128K, нужны агрессивная квантизация весов и сжатый KV-кэш. Автор конфигурации получил работающий llama-server с контекстом 131072 токена и скоростью около 35 t/s на RTX 5060 Ti 16 ГБ, Ryzen 9600X и 16 ГБ системной памяти (в сумме 32 ГБ с VRAM) в обсуждении на r/LocalLLaMA.

Считаем бюджет памяти грубо. 27 миллиардов параметров в FP16 занимают около 54 ГБ. Квант Q8 ужимает их примерно до 27 ГБ, Q4 - до 14-16 ГБ, IQ3_XXS - до 10-12 ГБ. Это оценки: точный размер зависит от архитектуры модели и конкретного файла GGUF. После загрузки весов IQ3_XXS на 16 ГБ карте остается запас под KV-кэш, буферы вычислений и служебную память драйвера.

Без квантизации кэша контекст 128K не влезает. KV-кэш растет линейно с длиной контекста, и на 128 тысячах токенов в fp16 он способен занять больше памяти, чем сами веса. Это и есть причина, по которой в подобных сборках K и V сжимают.

Почему 16 ГБ VRAM - это все еще тесно для 27B

Память на GPU расходуется на четыре группы задач:

• веса модели;
• KV-кэш, который растет с каждым токеном контекста;
• буферы вычислений под attention и батчи;
• оверхед драйвера, CUDA-контекста и рабочего стола.

Флаг --flash-attn on снижает пиковое потребление памяти на attention, но не отменяет необходимость квантизовать кэш. При 128K контекста и fp16-кэше карта упирается в OOM задолго до старта. Агрессивный квант весов и q4_0 для K/V сдвигают баланс в сторону рабочей конфигурации.

Системной памяти у автора 16 ГБ. Это ограничивает запас при выгрузке на CPU и работе с большими буферами, поэтому рассчитывать на RAM как на основной резерв не стоит. Конфигурации на 24 ГБ вытягивают куда больший контекст именно за счет запаса VRAM и объема системной RAM: там тот же класс моделей доходит до 194 048 токенов. Разбор такой сборки на RTX 4090 полезен как точка отсчета: он показывает, что именно дают лишние 8 ГБ.

Что дает квантизация IQ3_XXS

IQ3_XXS - это i-quant, квант, который подбирают итеративно под минимальный размер, примерно 3 бита на вес. Он агрессивнее привычных Q3_K и Q4_K_M и меньше по объему. За это приходится платить точностью восстановления весов.

В обсуждении автор отмечает, что квант Q3 UD его устраивал по качеству, но нужна была uncensored-модель, поэтому выбор пал на IQ3_XXS. Это компромисс между размером и качеством: относительно Q4_K_M он экономит память за счет точности. На сложных задачах, где нужны точные вычисления или длинные цепочки рассуждений, IQ3_XXS может давать заметные артефакты.

Какую модель выбрать: Qwen3.8-27B-GSQ-RCO-IQ3_XXS-Uncensored

Автор нашел на Hugging Face модель Qwen3.8-27B-GSQ-RCO-IQ3_XXS-Uncensored - ссылку подсказал пользователь u/_wortkarg_. Файл собран в GGUF и включает вариант с MTP, о чем говорит суффикс -mtp в имени.

Uncensored-модель обычно означает версию базовой модели, у которой ослаблены отказы и фильтры безопасности. Такие сборки получают дообучением или модификацией поведения, и они чаще ведут себя непоследовательно на чувствительных темах. За качество отвечает и квант, и исходный датасет дообучения, а его деталей в источнике нет.

Про GSQ и RCO в названии: это авторский нейминг конкретной сборки, расшифровку источник не дает. Воспринимайте их как метки репозитория, официального смысла за ними нет.

Практический момент: uncensored-модель и агрессивный квант складываются. Если обычная Qwen3 27B в Q4 ведет себя предсказуемо, то та же модель в IQ3_XXS с ослабленными отказами может быть менее стабильной. Проверять стоит на своих задачах, а не по названию репозитория.

Команда запуска llama-server с контекстом 131072

Автор приводит полную команду запуска сервера. Она рассчитана на конкретную сборку llama.cpp и конкретный файл модели, поэтому переносить ее один в один на другую версию или другой GGUF не стоит.

~/llama.cpp/build/bin/llama-server \
  --model ~/Documents/Models/Qwen3.8-27B-GSQ-RCO-IQ3_XXS-mtp.gguf \
  --alias "llamacpp" --host 0.0.0.0 --port 8001 \
  -ngl 99 --flash-attn on --ctx-size 131072 \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  --parallel 1 --batch-size 512 --ubatch-size 256 \
  --no-warmup --jinja \
  --spec-type draft-mtp,ngram-mod --spec-draft-n-max 2 \
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0

Разбор ключевых флагов:

• -ngl 99 - выгрузить на GPU максимальное число слоев; 99 означает «все слои», реальное число меньше.
• --flash-attn on - включает flash attention, снижая пиковую память на attention.
• --ctx-size 131072 - контекст 128K токенов.
• --cache-type-k q4_0 и --cache-type-v q4_0 - квантизация ключей и значений KV-кэша до 4 бит.
• --parallel 1 - один слот, то есть один активный диалог.
• --batch-size 512 и --ubatch-size 256 - размеры логического и физического батчей.
• --no-warmup - пропуск прогрева при старте, экономит время запуска.
• --jinja - рендеринг чат-шаблонов из репозитория модели.
• --spec-type draft-mtp,ngram-mod и --spec-draft-n-max 2 - спекулятивное декодирование.
• --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 - параметры сэмплинга.

Флаги --host 0.0.0.0 и --port 8001 открывают сервер по сети на всех интерфейсах. Значение 0.0.0.0 делает его доступным любому в локальной сети, поэтому для домашнего использования безопаснее 127.0.0.1.

Зачем нужны --cache-type-k q4_0 и --cache-type-v q4_0

KV-кэш хранит состояния attention для всех обработанных токенов, поэтому его размер линейно растет с контекстом. На 128K в fp16 он может занять больше VRAM, чем веса IQ3_XXS. Квантование K и V до q4_0 ужимает кэш примерно вчетверо относительно fp16. Это и делает контекст 131072 достижимым на 16 ГБ.

Побочный эффект - потеря точности на длинных зависимостях. Чем агрессивнее сжат кэш, тем выше шанс, что модель «забудет» деталь из начала длинного документа. Для чата и суммаризации это терпимо, для точных вычислений и длинных цепочек рассуждений - рискованно.

Не все сборки llama.cpp одинаково хорошо работают с квантизованным кэшем. Проверяйте версию и то, как она собрана под CUDA. Сборка стека на Debian с llama.cpp дает представление, какие параметры вообще поддерживает текущая ветка.

Speculative decoding: draft-mtp и ngram-mod

Идея спекулятивного декодирования простая. Черновая модель или n-gram предсказывает несколько следующих токенов, а основная модель проверяет их за один проход. Если предсказания совпали, за шаг принимается сразу несколько токенов и генерация ускоряется.

Здесь draft-часть задает флаг --spec-type draft-mtp,ngram-mod, а --spec-draft-n-max 2 ограничивает длину спекуляции двумя токенами. MTP - механизм многошагового предсказания токенов, ngram-mod - подсказки на основе совпадений n-грамм.

Автор прямо говорит, что MTP на практике не оправдал его ожиданий, хотя причин не объясняет. В итоговой команде спекулятивное декодирование включено, но с осторожным лимитом в два токена. Выигрыш сильно зависит от задачи: на предсказуемом тексте, коде или повторяющихся структурах ngram-mod помогает, на свободном креативном тексте - почти нет. Фиксированный прирост скорости здесь обещать нельзя.

Скорость около 35 t/s: откуда берется и от чего зависит

Автор сообщает о скорости примерно 35+ t/s на этой конфигурации в том же обсуждении. Цифра получена на RTX 5060 Ti 16 ГБ, Ryzen 9600X и 16 ГБ RAM и не гарантируется на другом железе.

На итоговую скорость влияет несколько факторов:

• квант весов: чем агрессивнее, тем меньше данных читается из памяти;
• квант KV-кэша: q4_0 ускоряет работу с длинным контекстом, потому что кэш занимает меньше памяти;
• длина контекста: чем ближе к 131072, тем медленнее генерация;
• размеры батчей --batch-size и --ubatch-size;
• спекулятивное декодирование и качество draft-предсказаний;
• версия llama.cpp, драйвер и сборка под CUDA.

Одна оговорка, важная на практике: 35 t/s - это скорость генерации токенов, а не обработки промпта. Когда в контекст загружается длинный документ, время уходит на prompt processing, и он может идти существенно медленнее. Замеров prompt processing для этой конфигурации источник не приводит, так что определять их придется самостоятельно.

Сравнить порядок цифр полезно с другими сборками. На 12 ГБ та же схема с IQ3_XXS и контекстом 128K выдает 14-15 t/s, а на 24 ГБ такие модели доходят до 40-80 t/s в зависимости от MTP и длины контекста. Отчет по запуску на 12 ГБ с тем же квантом показывает, как падает скорость при нехватке VRAM. 35 t/s на 16 ГБ укладывается между этими крайностями.

Компромиссы: качество, контекст и стабильность

Запуск 27B на 16 ГБ - это набор компромиссов. Перечислим их честно.

• Качество. IQ3_XXS может давать артефакты на сложных задачах: математика, длинные рассуждения, точный код. Для чата и пересказа обычно терпимо.
• Длинные зависимости. Кэш q4_0 экономит память, но снижает точность на больших расстояниях внутри контекста.
• Предсказуемость. Uncensored-модель менее стабильна на чувствительных темах, чем обычная.
• Системная память. 16 ГБ RAM ограничивают запас при выгрузке на CPU и работе с большими буферами.
• Незавершенность схемы. Автор открыто ищет лучшую команду, то есть конфигурация не финальная.

Отсюда вывод про сценарии. Для диалога, суммирования и черновиков конфигурация рабочая. Для задач, где нужны точность и стабильность, IQ3_XXS плюс сжатый кэш - не лучший выбор: здесь либо идут на большее железо, либо жертвуют длиной контекста.

Что попробовать, если конфигурация не подошла

Есть несколько направлений, которые можно перебрать, прежде чем менять железо.

• Сменить квант. Q3 UD автор называл удовлетворительным, это разумная отправная точка. Если хватает VRAM, попробуйте Q4_K_M: качество выше, но контекст придется урезать.
• Сократить контекст. Если 128K не нужен постоянно, ctx-size 64K или 32K освободят память под более жирный квант или под кэш в fp16.
• Отключить спекулятивное декодирование. Если прироста нет, флаги --spec-type и --spec-draft-n-max просто убирают.
• Обновить сборку llama.cpp. Поддержка квантизованного кэша и MTP меняется от версии к версии.
• Взять полноценную draft-модель вместо ngram-mod, если есть чем ее разместить.
• Посмотреть в сторону vLLM и большей VRAM, если длинный контекст нужен постоянно. Пример такого запуска на RTX 3090 с контекстом 144K показывает другой путь, требующий 24 ГБ.

Универсального рецепта «получишь 35 t/s и не думай» здесь нет. Конфигурация автора - рабочая точка на конкретном железе, и ее ценность в том, что она показывает достижимый потолок для 16 ГБ. Начните с кванта и длины контекста, а флаги подгоняйте под свои задачи.

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