Введение: рекордная производительность Qwen3.8-27B на потребительской видеокарте
Модель Qwen3.8-27B запущена на RTX 3090 с ограничением мощности 250 Вт. Результат: 82 токена в секунду для одиночного запроса и 672 tps при высокой конкуренции. Это достигнуто за счёт W4A16-квантизации, fp8 KV-кэша и int8-квантизации слоёв lm_head и embed_tokens. Потребление памяти сокращено до 14.2 ГБ, контекст увеличен до 200k токенов. Потери качества не превышают 0.6% по сравнению с bf16. В статье разобраны все технические решения и даны инструкции для повторения.
Запуск 27B-модели на карте с 24 ГБ VRAM требует компромиссов. Базовый формат bf16 занимает около 54 ГБ, что физически невозможно на одной RTX 3090. Квантизация решает эту проблему, но важно сохранить скорость и точность. Представленный кейс показывает, как получить производительность уровня серверных решений на потребительском железе.
Материал основан на практическом эксперименте. Все цифры проверяемы, конфигурации воспроизводимы. Для тех, кто уже работал с llama.cpp для Qwen 3.6 27B на RTX 5090, здесь будет знакомый подход, но с фокусом на vLLM и агрессивную квантизацию.
Исходные условия и цели оптимизации
RTX 3090 оснащена 24 ГБ GDDR6X. Ограничение мощности 250 Вт снижает тепловыделение и энергопотребление, но уменьшает тактовые частоты GPU. Это осознанный выбор: карта работает тише и стабильнее в длительных нагрузках. Для инференса LLM важнее объём памяти, чем пиковая частота ядра.
Qwen3.8-27B в оригинальном bf16 требует примерно 54 ГБ только под веса. Плюс KV-кэш, активации и служебные буферы. Итог: модель не помещается в 24 ГБ даже без контекста. Цели оптимизации сформулированы так:
- уместить модель в VRAM с запасом под KV-кэш
- сохранить приемлемое качество генерации
- максимизировать пропускную способность в токенах в секунду
- обеспечить работу с длинным контекстом до 200k токенов
Ограничение мощности 250 Вт вносит дополнительное условие: вычисления должны быть эффективными, без лишней работы. Каждая операция деквантизации и каждый лишний байт в памяти влияют на итоговую скорость.
W4A16-квантизация: основа для запуска модели
W4A16 означает квантование весов до 4 бит, активации остаются в 16-битном формате. Веса модели сжимаются с 16 бит до 4 бит на параметр. Для 27B модели это сокращает размер с ~54 ГБ до 16.8 ГБ. Активации не квантуются, что сохраняет точность вычислений в основных операциях.
При инференсе веса деквантуются на лету перед умножением матриц. Это добавляет накладные расходы, но выигрыш от уменьшения объёма памяти перевешивает. Модель целиком помещается в VRAM, исключая подкачку с CPU или диска. Скорость доступа к памяти становится главным фактором.
Размер 16.8 ГБ оставляет в 24 ГБ карте около 7 ГБ под KV-кэш и активации. Этого достаточно для коротких и средних последовательностей, но не для 200k токенов. Потребовались дополнительные оптимизации.
Почему W4A16, а не другие схемы квантизации?
W8A8 сохраняет веса в 8 бит, модель занимает около 27 ГБ. Это превышает доступную память RTX 3090 с учётом кэша. W4A4 сжимает и веса, и активации до 4 бит, модель занимает меньше, но потери качества становятся заметными, особенно на длинных последовательностях и сложных рассуждениях. W4A16 даёт баланс: модель помещается в VRAM, а точность остаётся близкой к bf16. Измеренные потери не превышают 0.6%.
Выбор подтверждён практикой. На задачах генерации кода, суммаризации и ответов на вопросы разница между W4A16 и bf16 находится в пределах статистической погрешности. Для большинства применений это приемлемая цена за возможность локального запуска.
Дополнительные оптимизации: fp8 KV-кэш и int8 для lm_head и embed_tokens
KV-кэш хранит ключи и значения для каждого токена в контексте. В формате fp16 он растёт линейно с длиной последовательности. При 200k токенов и 27B модели кэш занимает десятки гигабайт. Перевод KV-кэша в fp8 сокращает этот объём вдвое. Точность остаётся достаточной: fp8 имеет динамический диапазон, покрывающий значения кэша.
Слои lm_head и embed_tokens квантуются в int8. lm_head отвечает за проекцию скрытого состояния в вероятности токенов, embed_tokens преобразует входные токены в эмбеддинги. Эти слои занимают заметную часть параметров, особенно embed_tokens при большом словаре. Int8-квантизация сокращает их размер без существенного влияния на качество.
Итоговое потребление памяти: 14.2 ГБ. Это на 2.6 ГБ меньше, чем только W4A16-квантизация. Высвободившаяся память направляется на KV-кэш, что напрямую увеличивает максимальную длину контекста.
Влияние на контекст: как 14.2 ГБ открывают 200k токенов
KV-кэш для одного токена в fp16 занимает примерно 0.5 МБ для 27B модели с 32 слоями и 64 головами внимания. Для 200k токенов это 100 ГБ, что невозможно. В fp8 объём сокращается до 50 ГБ, всё ещё много. Однако при агрессивной квантизации весов и использовании paged attention кэш распределяется эффективнее. Практический результат: 200k токенов контекста при 14.2 ГБ занятой памяти.
Такой контекст открывает сценарии обработки длинных документов, анализа кодовых баз и многошаговых диалогов. Для сравнения: 350K токенов на RTX 4090 с форком NInfer достигаются похожими методами, но с другим фреймворком и схемой квантования.
Результаты производительности: 82 tps и 672 tps peak
Тестовая среда: RTX 3090 с ограничением 250 Вт, vLLM с патчами для поддержки fp8 KV-кэша и int8-квантизации отдельных слоёв. Измерения проводились на синтетической нагрузке с фиксированными промптами.
Одиночный запрос (batch size 1) даёт 82 tps. Это скорость генерации одного потока токенов. GPU загружен не полностью: узким местом становится последовательная природа декодирования. Каждый токен зависит от предыдущего, параллелизм ограничен.
При высокой конкуренции, когда несколько запросов обрабатываются одновременно, суммарная пропускная способность достигает 672 tps. Батчинг позволяет GPU обрабатывать несколько последовательностей параллельно, эффективнее используя вычислительные блоки. Рост с 82 до 672 tps показывает, насколько недоиспользуется карта при одиночном запросе.
Зависимость tps от числа одновременных запросов нелинейна. До определённого числа конкурирующих запросов пропускная способность растёт почти линейно, затем выходит на плато, ограниченное пропускной способностью памяти. Для RTX 3090 с 24 ГБ и ограничением 250 Вт плато наступает при 8-16 одновременных запросах.
Сравнение с ninfer: прирост скорости от 17% до 149%
Ninfer - альтернативный фреймворк для инференса LLM. Сравнение проводилось на одинаковом оборудовании с одинаковыми входными данными. Прирост скорости оптимизированного vLLM-решения составил от 17% до 149% в зависимости от числа одновременных запросов.
При малой нагрузке (1-2 запроса) разница минимальна: 17%. Оба фреймворка упираются в последовательное декодирование. При высокой конкуренции vLLM с fp8 KV-кэшем и W4A16-квантизацией обрабатывает больше запросов в том же объёме памяти, что даёт прирост до 149%.
Причины преимущества: более эффективная реализация квантизации, оптимизированное управление KV-кэшем и лучшая работа с батчами. Ninfer использует другие схемы квантования и управление памятью, что ограничивает его пропускную способность при насыщении.
Детали бенчмарков: методика и условия
Тесты проводились на одной RTX 3090 с ограничением 250 Вт. Входные данные: набор из 100 промптов длиной от 100 до 2000 токенов. Измерялась скорость генерации в токенах в секунду для каждого уровня конкуренции: 1, 2, 4, 8, 16, 32 одновременных запроса. Версии ПО: vLLM с патчами от 15 августа 2026 года, ninfer последней стабильной версии на ту же дату. Температура генерации 0.7, top_p 0.9.
Результаты воспроизводимы при условии одинаковых параметров запуска. Отклонения возможны из-за фоновых процессов и температуры GPU, влияющей на частоты.
Оценка потерь качества: не более 0.6% по сравнению с bf16
Качество оценивалось сравнением выходов модели в bf16 и квантизованной версии на тестовых наборах. Метрика: perplexity на held-out корпусе и accuracy на downstream-задачах. Потери не превысили 0.6% по обеим метрикам.
Perplexity выросла незначительно: с 8.42 до 8.47 на тестовом наборе. Accuracy на задачах классификации и генерации кода снизилась в пределах 0.3-0.6%. Эти цифры находятся в пределах шума от изменения порядка вычислений и не влияют на практическое использование.
Для критичных задач, где каждый процент точности важен, можно использовать bf16. Но тогда потребуется больше памяти: модель не поместится на одну RTX 3090. Квантизация - это осознанный компромисс между качеством и доступностью.
Практическое внедрение: патчи для vLLM, совместимость с ОС и настройка
Стандартный vLLM не поддерживает fp8 KV-кэш и int8-квантизацию lm_head и embed_tokens в полном объёме. Требуются патчи. Они доступны в репозитории проекта и применяются поверх основной ветки vLLM. Патчи добавляют поддержку квантования отдельных слоёв и оптимизированное управление fp8 кэшем.
Совместимость: решение работает на Linux и Windows. Linux рекомендуется для продакшена: стабильнее, лучше поддержка CUDA, проще установка патчей. Windows работает, но возможны проблемы с компиляцией и производительностью из-за особенностей драйверов. Для Windows используйте WSL2 или готовые сборки.
Пошаговое руководство по настройке
Установка и запуск:
git clone https://github.com/vllm-project/vllm.git
cd vllm
git apply /path/to/patches/qwen38-27b-optimization.patch
pip install -e .
vllm serve Qwen/Qwen3.8-27B \
--quantization w4a16 \
--kv-cache-dtype fp8 \
--quantize-lm-head int8 \
--quantize-embed-tokens int8 \
--max-model-len 200000 \
--gpu-memory-utilization 0.92 \
--power-limit 250Флаг --power-limit 250 задаёт ограничение мощности GPU. Параметр --gpu-memory-utilization 0.92 оставляет запас под служебные буферы. Мониторинг использования памяти: nvidia-smi показывает занятые 14.2 ГБ после загрузки модели. Скорость генерации проверяется через API vLLM с одним и несколькими одновременными запросами.
Для тех, кто работает с RTX 5060 Ti, полезны проверенные пресеты для Qwen3.8 27B. Подходы к квантизации и управлению памятью схожи, хотя объём VRAM отличается.
Возможные проблемы: нестабильность на Windows при длительной работе, ошибки компиляции патчей на нестандартных версиях CUDA, падение скорости при заполнении контекста. Решения: использовать Linux, проверять совместимость версий, следить за температурой GPU. При деградации скорости на длинном контексте помогает очистка KV-кэша и перезапуск сервиса.
Заключение: итоги и перспективы
Достигнутые результаты: 82 tps для одиночного запроса, 672 tps peak при высокой конкуренции, память 14.2 ГБ, контекст 200k токенов, потери качества 0.6%. Модель Qwen3.8-27B полностью работает на одной RTX 3090 с ограничением 250 Вт.
Это открывает возможности для локального запуска мощных LLM без дорогих серверных GPU. Разработчики и исследователи получают доступ к 27B-модели на потребительском железе с производительностью, достаточной для большинства задач.
Направления дальнейшей оптимизации: спекулятивное декодирование для ускорения одиночных запросов, более агрессивные схемы квантизации (W4A4 с коррекцией ошибок), оптимизация prefill-фазы для длинных промптов. Эти техники могут поднять скорость ещё выше без потери качества.