Запуск 27-миллиардной модели на одной видеокарте с 32 ГБ VRAM - задача, в которой стандартные параметры llama.cpp оставляют до 30% производительности неиспользованной. Для связки Qwen 3.6 27B (GGUF Q6_K) и RTX 5090 подобран рабочий конфиг: скорость инференса 80-100 токенов/с на обычных запросах и около 40 токенов/с при полностью заполненном контексте в 262 тысячи токенов. Разберём каждый параметр, который к этому привёл.
Ключевые настройки, давшие результат: размер батча обработки промпта -b 512, размер батча генерации -ub 128, бюджет рассуждений --reasoning-budget 16384, квантованный KV-кэш cache-type q8_0 и спекулятивное декодирование через встроенный механизм draft-MTP. Статья содержит готовую команду запуска и анализ того, какие из этих параметров критичны, а какие можно оставить по умолчанию без измеримой потери скорости.
Тестовый стенд и методика измерений
Все замеры выполнены на системе с видеокартой NVIDIA GeForce RTX 5090 (32 ГБ GDDR7), процессором AMD Ryzen 9 9950X и 64 ГБ оперативной памяти DDR5-6000. Использовалась сборка llama.cpp от 2 августа 2026 года (коммит b4473), драйвер NVIDIA 570.52, CUDA 12.8.
Модель: Qwen3.6-27B в формате GGUF, квантование Q6_K. Размер файла - 22.1 ГБ. При загрузке с выбранными настройками модель занимает около 28.5 ГБ VRAM, оставляя резерв под растущий KV-кэш.
Методика: каждый замер повторялся пять раз, в таблицах приведено медианное значение. Скорость измерялась в токенах в секунду (tok/s) отдельно для фазы обработки промпта (prefill) и фазы генерации (decode). Короткий промпт - 128 токенов, длинный - заполнение контекста до 262 144 токенов с последующей генерацией 512 токенов ответа. Температура зафиксирована на 0.0 для воспроизводимости.
Ключевые параметры запуска и их влияние на производительность
Размеры батчей: -b 512 и -ub 128
Параметр -b определяет, сколько токенов промпта обрабатывается за один проход GPU. При значении 512 видеокарта утилизируется на 94-97% во время prefill-фазы. Увеличение до 1024 даёт прирост всего в 3-5% по скорости обработки промпта, но съедает дополнительно 1.2 ГБ VRAM под промежуточные буферы. Уменьшение до 256 снижает утилизацию до 70-75% и роняет скорость prefill на 35-40%.
Параметр -ub (micro-batch size) управляет размером батча на фазе генерации. Значение 128 - компромисс между пропускной способностью и задержкой первого токена. При -ub 256 задержка перед началом генерации вырастает на 120-150 мс, что заметно в интерактивных сценариях. При -ub 64 падает общая скорость decode на 15-18% из-за недозагрузки тензорных ядер.
Типичные рекомендации сообщества для 24-гигабайтных карт - -b 2048 и -ub 512. Они оправданы, когда модель занимает меньше места и есть свободная VRAM под большие буферы. На RTX 5090 с 27B-моделью в Q6_K свободной памяти после загрузки весов остаётся около 3.5 ГБ - этого хватает на батчи 512/128, но не на 2048/512 без риска OOM при росте контекста.
Практический вывод: пара -b 512 -ub 128 - потолок для данной конфигурации. Дальнейшее увеличение упирается в объём VRAM, а не в вычислительную мощность.
Бюджет рассуждений: --reasoning-budget 16384
Qwen 3.6 использует механизм внутреннего «мышления» - модель генерирует скрытую цепочку рассуждений перед выдачей финального ответа. Параметр --reasoning-budget задаёт максимальное количество токенов, которое модель может потратить на этот внутренний процесс.
Значение 16384 выбрано по двум причинам. Во-первых, это покрывает задачи средней сложности: отладка кода, анализ логов, написание документации. На задачах вроде «объясни архитектуру трансформера» модель использует 2000-4000 токенов рассуждений. На сложных многошаговых запросах - 8000-12000. Во-вторых, бюджет напрямую влияет на latency: каждый токен рассуждения генерируется с той же скоростью, что и обычный токен. При 80 tok/s лимит в 16384 токенов означает до 205 секунд на «размышление» в худшем случае.
Сравнение: значение по умолчанию - 4096. На задачах разработки приложений этого часто не хватает, модель обрывает рассуждение на полуслове и выдаёт неполный ответ. Увеличение до 32768 не дало измеримого прироста качества в тестах на бенчмарке HumanEval (разница в 1.2% по pass@1), но добавило риск упереться в лимит контекста при длинных диалогах.
Бюджет 16384 - рациональный максимум для практической работы. Он покрывает 95% сценариев разработки и не создаёт проблем с длиной контекста.
Кэш ключей и значений: cache-type q8_0
KV-кэш хранит ключи и значения внимания для всех предыдущих токенов. В llama.cpp доступны три основных типа: f16 (половинная точность, 2 байта на элемент), q8_0 (8-битное квантование, 1 байт) и q4_0 (4-битное, 0.5 байта).
Для 27B-модели с 64 слоями и размерностью скрытого состояния 4096 один токен контекста в f16 занимает примерно 0.52 МБ в KV-кэше. При контексте 262K это 136 ГБ - заведомо не помещается в 32 ГБ VRAM. Квантование q8_0 сокращает объём вдвое, до 68 ГБ - всё ещё много, но llama.cpp выгружает часть кэша в оперативную память, когда VRAM заполняется.
На практике с q8_0 модель держит в VRAM примерно 40-50 тысяч токенов кэша, остальное уходит в RAM. Скорость при этом падает плавно: 100 tok/s на 8K контекста, 70 tok/s на 64K, 40 tok/s на 262K. Переход на q4_0 экономит ещё 40% памяти, но вносит артефакты: модель начинает путать позиции токенов на контекстах длиннее 100K, что приводит к повторениям и потере связности.
q8_0 - минимальное квантование, при котором качество генерации на длинных контекстах неотличимо от f16. Для RTX 5090 с 32 ГБ это оптимальный выбор.
Спекулятивное декодирование через draft-MTP
Механизм Multi-Token Prediction (MTP) встроен в архитектуру Qwen 3.6. Модель на каждом шаге предсказывает не один следующий токен, а сразу несколько - в данной конфигурации до трёх. Основной проход модели проверяет эти предсказания и принимает или отвергает их.
В llama.cpp поддержка MTP включается автоматически при обнаружении соответствующей архитектуры модели. Никаких дополнительных флагов не требуется - механизм работает из коробки. Эффект: на коротких контекстах скорость генерации вырастает с 65-70 tok/s (без MTP) до 80-100 tok/s. На длинных контекстах прирост скромнее - с 28-32 до 38-42 tok/s, потому что узким местом становится вычисление внимания, а не генерация токенов.
Важный нюанс: MTP не влияет на качество. Отвергнутые спекулятивные токены отбрасываются, финальный ответ идентичен тому, что модель сгенерировала бы без MTP. Это чистое ускорение без каких-либо компромиссов.
Подобный подход мы разбирали в статье о спекулятивном декодинге на MoE-моделях, где неправильная настройка verify-батчей приводила к двукратному падению скорости. В случае Qwen 3.6 с плотной архитектурой таких проблем нет - MTP работает стабильно без дополнительного тюнинга.
Результаты: скорость инференса в разных сценариях
Замеры с оптимизированными параметрами (-b 512, -ub 128, --reasoning-budget 16384, cache-type q8_0, MTP включён) против базовой конфигурации (-b 512, -ub 512, без MTP, cache-type f16):
| Сценарий | Prefill (opt) | Decode (opt) | Prefill (base) | Decode (base) |
|---|---|---|---|---|
| Короткий промпт (128 tok) | 1850 tok/s | 94 tok/s | 1780 tok/s | 67 tok/s |
| Контекст 64K | 320 tok/s | 72 tok/s | 290 tok/s | 48 tok/s |
| Контекст 262K | 85 tok/s | 41 tok/s | 78 tok/s | 30 tok/s |
Основной прирост дают два фактора: спекулятивное декодирование (+30-40% к скорости генерации) и квантованный кэш, который позволяет держать больше контекста в VRAM до начала деградации. Размеры батчей влияют на prefill: при -b 512 против стандартных 2048 разница в скорости обработки промпта минимальна, зато нет риска OOM.
Падение до 40 tok/s на 262K контексте - фундаментальное ограничение. Вычисление внимания имеет квадратичную сложность по длине контекста, и на 262 тысячах токенов даже RTX 5090 упирается в пропускную способность памяти. Дальнейшая оптимизация возможна через FlashAttention-3 или разреженное внимание, но это требует модификации бэкенда llama.cpp.
Практические рекомендации: что действительно важно, а что можно оставить по умолчанию
Три параметра, которые дали измеримый прирост:
- cache-type q8_0 - критичен для работы с длинными контекстами. Без него модель падает в OOM на 100K+ токенов.
- Встроенный MTP - работает автоматически, даёт +30-40% к скорости генерации. Не требует настройки.
- -ub 128 - снижение относительно стандартных 512 улучшает отзывчивость без заметной потери пропускной способности.
Параметры, которые не показали значимого эффекта:
- --threads - при полной загрузке GPU дополнительные CPU-потоки не влияют на скорость. Значение по умолчанию (8) адекватно.
- --no-mmap - на NVMe-накопителе разница во времени загрузки модели менее секунды.
- --mlock - предотвращает свопинг, но на системе с 64 ГБ RAM при загруженной 22 ГБ модели свопинга не происходит.
- --repeat-penalty, --temperature - влияют на качество генерации, но не на производительность инференса.
Готовая команда запуска:
./llama-cli \
-m Qwen3.6-27B-Q6_K.gguf \
-b 512 \
-ub 128 \
--cache-type q8_0 \
--reasoning-budget 16384 \
-ngl 99 \
-c 262144 \
--temp 0.7 \
--repeat-penalty 1.1Флаг -ngl 99 загружает все слои модели на GPU. Если нужно освободить VRAM под другие задачи, можно снизить до 80-90 ценой падения скорости на 15-25%.
Для тех, кто собирает локальную AI-лабораторию на младших картах, рекомендуем гайд по подбору моделей для RTX 5070 Ti - там разбирается аналогичная оптимизация llama.cpp для Qwen-семейства в Q4-квантовании.
Ограничения и дальнейшие шаги
Результаты получены на одном экземпляре RTX 5090 с драйвером 570.52. На других картах Blackwell (RTX 5060 Ti, RTX 5080) цифры будут отличаться пропорционально числу тензорных ядер и пропускной способности памяти. Квантование Q6_K выбрано как баланс качества и размера; Q4_K_M даст на 15-20% выше скорость ценой измеримой деградации на сложных промптах, Q8_0 не поместится в 32 ГБ с запасом под контекст.
Не тестировались: tensor parallelism на нескольких GPU, бэкенд Vulkan, ROCm-сборка llama.cpp. Стабильность на сверхдлинных сессиях (несколько часов непрерывной генерации) не проверялась - на контекстах 200K+ возможна фрагментация KV-кэша и постепенное снижение скорости.
Проблема падения скорости на длинных контекстах - общая для всех Transformer-моделей. Аналогичное поведение мы фиксировали при разборе ошибок GLM-5.2 на контекстах больше 32K, где причина была в переполнении f16. Здесь ограничение чисто вычислительное: O(n²) внимание на 262K токенов требует 68 миллиардов операций на каждый новый токен. Будущие версии llama.cpp с FlashAttention-3 должны поднять скорость decode на длинных контекстах в 1.5-2 раза.
Для горизонтального масштабирования на несколько карт стоит изучить опыт запуска моделей через llama.cpp RPC - подход применим и к Qwen 3.6, хотя для 27B-модели одна RTX 5090 остаётся оптимальной по соотношению цена/производительность.