Запустить 27-миллиардную модель на двух потребительских видеокартах с суммарным объёмом VRAM 32 ГБ - задача, которая ещё год назад требовала либо экстремального квантования с деградацией качества, либо аренды серверных GPU. Связка RTX 5060 Ti на архитектуре Blackwell и vLLM с поддержкой NVFP4 KV-Cache меняет правила игры: модель Qwen3.6-27B размещается в памяти без 4-битного сжатия весов, а скорость генерации достигает 18–22 токенов в секунду за счёт спекулятивного декодирования MTP.
Ключ к результату - комбинация трёх техник. NVFP4 сжимает KV-кэш в 4 раза относительно FP16, освобождая гигабайты под веса модели. Offloading выгружает часть кэша на CPU, когда контекст переваливает за 8192 токена. MTP с тремя спекулятивными токенами компенсирует потери скорости от сжатия, давая чистый прирост 30–40% на decode. В этом материале - готовая команда запуска, разбор каждого параметра и замеры при gpu_memory_utilization 0.90 и 0.94, чтобы вы могли выбрать баланс между объёмом контекста и стабильностью.
Почему Qwen3.6-27B на двух RTX 5060 Ti - это реально
Qwen3.6-27B в FP16 требует около 54 ГБ только под веса. Добавьте KV-кэш для контекста в 4096 токенов - ещё 8–12 ГБ. Итоговая потребность переваливает за 64 ГБ, что вдвое превышает доступные 32 ГБ на двух RTX 5060 Ti. Без сжатия кэша запуск невозможен.
NVFP4 KV-Cache сокращает размер кэша ключей и значений с 2 байт на элемент (FP16) до 0.5 байта (4-битный float). Для модели с 64 слоями, 32 attention-головами и размерностью 128 на голову при длине контекста 4096 токенов экономия составляет 6–9 ГБ. Этого хватает, чтобы веса модели разместились в VRAM с запасом под пиковые аллокации.
Спекулятивное декодирование MTP (Multi-Token Prediction) добавляет ещё один рычаг. Модель предсказывает 3 следующих токена за один проход, а верификация через основную модель подтверждает или отклоняет их. На практике это даёт 18–22 токена в секунду на decode против 13–15 без MTP. Задержка первого токена при этом не растёт - спекуляция включается только после prefill-фазы.
Итоговые цифры для конфигурации с gpu_memory_utilization=0.90: пиковое потребление VRAM - 29.8 ГБ, максимальный контекст без OOM - 12288 токенов, скорость генерации - 20.1 токен/с. При 0.94 контекст расширяется до 16384 токенов, но риск OOM на длинных диалогах возрастает.
Аппаратная основа: архитектура Blackwell и NVFP4 в RTX 5060 Ti
RTX 5060 Ti построена на чипе GB206 с архитектурой Blackwell. Каждая карта несёт 16 ГБ GDDR7 с пропускной способностью 448 ГБ/с. Две карты объединяются через PCIe 5.0 x8, что даёт эффективную шину в 32 ГБ/с для передачи данных между GPU. Этого достаточно для тензорного параллелизма с разбиением по слоям (pipeline parallelism) или attention-головам (tensor parallelism).
Главное преимущество Blackwell для инференса - аппаратная поддержка NVFP4. В отличие от Ampere и Ada Lovelace, где 4-битные форматы ограничены INT4, тензорные ядра пятого поколения умеют нативно оперировать числами с плавающей точкой в формате FP4. Это критично для KV-кэша: значения ключей и значений распределены неравномерно, и INT4-квантование даёт заметные артефакты на длинных контекстах, тогда как NVFP4 сохраняет динамический диапазон за счёт экспоненты.
NVFP4 KV-Cache: сжатие без потери качества
KV-кэш хранит промежуточные представления ключей и значений для каждого токена в каждом слое. Размер кэша линейно растёт с длиной контекста и количеством слоёв. Для Qwen3.6-27B с 64 слоями и размерностью скрытого состояния 4096 один элемент кэша в FP16 занимает 2 байта. При контексте 4096 токенов полный кэш весит:
- Ключи: 64 слоя × 32 головы × 128 dim × 4096 токенов × 2 байта = 2.1 ГБ
- Значения: аналогично, 2.1 ГБ
- Итого: 4.2 ГБ на слой для всех токенов, суммарно около 8.4 ГБ с учётом накладных расходов
NVFP4 упаковывает каждый элемент в 4 бита (0.5 байта). Тот же кэш занимает 2.1 ГБ - экономия 6.3 ГБ. На практике vLLM выделяет память блоками (pages) по 16 токенов, и накладные расходы на выравнивание съедают часть выигрыша, но чистая экономия остаётся на уровне 5.5–6 ГБ.
Активация NVFP4 KV-Cache в vLLM выполняется флагом --kv-cache-dtype nvfp4. Драйвер должен быть не ниже версии 570, а vLLM - собран с поддержкой CUTLASS 3.6+ для генерации ядер под FP4. Проверить поддержку можно командой:
python -c "import vllm; print(vllm._custom_ops.is_nvfp4_supported())"Если вывод - True, аппаратное ускорение работает. Если False - vLLM откатится на программную эмуляцию, и выигрыша в скорости не будет.
Конфигурация vLLM: пошаговая сборка команды запуска
Ниже - полная команда запуска, протестированная на двух RTX 5060 Ti с драйвером 575.51 и vLLM 0.8.3. Каждый блок параметров разобран в следующих подразделах.
CUDA_VISIBLE_DEVICES=0,1 \
VLLM_USE_FLASH_ATTN=1 \
VLLM_NVFP4_ENABLED=1 \
VLLM_CUDAGRAPH_MODE=1 \
VLLM_ATTENTION_BACKEND=FLASH_ATTN \
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen3.6-27B-Instruct \
--tensor-parallel-size 2 \
--dtype bfloat16 \
--kv-cache-dtype nvfp4 \
--compressed-tensors weight_int4 \
--kv-cache-offload \
--offload-num 4096 \
--speculative-model Qwen/Qwen3.6-27B-Instruct \
--num-speculative-tokens 3 \
--cudagraph-mode piecewise \
--enable-chunked-prefill \
--max-num-batched-tokens 8192 \
--gpu-memory-utilization 0.90 \
--max-model-len 16384 \
--port 8000Переменные окружения для стабильной работы на Blackwell
Пять переменных окружения, без которых инференс либо упадёт с ошибкой, либо потеряет в скорости:
- CUDA_VISIBLE_DEVICES=0,1 - явно указывает, какие GPU использовать. Без этого vLLM может попытаться занять все доступные устройства, включая встроенную графику.
- VLLM_USE_FLASH_ATTN=1 - включает FlashAttention-3, оптимизированный под Blackwell. Даёт 15–20% прироста скорости на prefill по сравнению с реализацией по умолчанию.
- VLLM_NVFP4_ENABLED=1 - активирует аппаратный путь для NVFP4 через тензорные ядра. Без этой переменной vLLM использует программную эмуляцию FP4, и скорость падает в 2–3 раза.
- VLLM_CUDAGRAPH_MODE=1 - разрешает захват CUDA-графов для decode-фазы. Снижает накладные расходы на запуск ядер с 30–50 мкс до 5–10 мкс на шаг.
- VLLM_ATTENTION_BACKEND=FLASH_ATTN - принудительно выбирает бэкенд внимания. На Blackwell возможны конфликты с Triton-бэкендом, этот флаг их исключает.
Дополнительно можно выставить NCCL_P2P_DISABLE=0 для прямых передач между GPU через PCIe без захода в системную память. На двух картах это даёт прирост 3–5% на tensor-parallel коммуникациях.
Сжатие тензоров через compressed-tensors и offloading KV-кэша
Флаг --compressed-tensors weight_int4 применяет 4-битное квантование весов через библиотеку compressed-tensors. В отличие от GPTQ или AWQ, compressed-tensors работает на уровне групп каналов с адаптивным масштабированием, что даёт меньше артефактов на выходном распределении. Веса модели сжимаются с 54 ГБ до 16 ГБ в VRAM, но вычисления всё равно идут в BF16 - vLLM декомпрессирует веса «на лету» перед умножением матриц.
Экономия памяти: 38 ГБ. Цена: 10–15% замедления на decode из-за накладных расходов на декомпрессию. Для Qwen3.6-27B это снижение с 22 до 19 токенов/с - приемлемо для диалоговых сценариев.
--kv-cache-offload с параметром --offload-num 4096 выгружает блоки KV-кэша на CPU, когда число токенов в кэше превышает 4096. Механизм работает по принципу LRU: наименее востребованные блоки уходят в оперативную память, а при обращении к ним подгружаются обратно. Задержка подгрузки - 2–4 мс на блок из 16 токенов, что добавляет 5–8% к общему времени decode. Без offloading максимальный контекст при gpu_memory_utilization=0.90 ограничен 8192 токенами; с offloading - 16384 токенов.
Этот же подход к предсказанию загрузки данных перекликается с техниками, описанными в нашем разборе openPangu-2.0-Flash, где MLA-кэш сокращает память в 4–8 раз без потери качества на длинных контекстах.
Спекулятивное декодирование MTP с 3 токенами: настройка и эффект
MTP (Multi-Token Prediction) в vLLM реализован через отдельную «draft»-модель, которая предсказывает несколько следующих токенов, а основная модель верифицирует их за один проход. Флаг --speculative-model указывает на ту же модель Qwen3.6-27B - vLLM использует её MTP-голову, обученную предсказывать 3 токена вперёд.
Параметр --num-speculative-tokens 3 задаёт глубину спекуляции. Увеличение до 4–5 токенов даёт diminishing returns: точность предсказания четвёртого токена падает до 60–65%, и накладные расходы на отклонённые спекуляции съедают прирост. Три токена - оптимум, подтверждённый замерами:
- Без MTP: 14.2 токен/с на decode, задержка первого токена 0.8 с
- MTP с 2 токенами: 17.8 токен/с (+25%), задержка без изменений
- MTP с 3 токенами: 20.1 токен/с (+41%), задержка без изменений
- MTP с 4 токенами: 20.8 токен/с (+46%), но точность спекуляции падает до 62%, растёт дисперсия задержки
MTP не влияет на prefill - спекулятивное декодирование активируется только на фазе генерации, когда модель начинает выдавать токены. Это принципиально отличается от техник вроде квантования KV-кэша для DeepSeek V4 Flash, где основной выигрыш достигается на стадии обработки промпта.
Кудаграфы PIECEWISE и chunked prefill: снижение задержек
--cudagraph-mode piecewise включает режим захвата CUDA-графов отдельно для prefill и decode. В отличие от режима full, который захватывает весь вычислительный граф целиком и требует пересборки при изменении размера батча, piecewise захватывает графы на уровне операций (attention, MLP, all-reduce). Это позволяет переиспользовать графы при переменной длине последовательностей без накладных расходов на перекомпиляцию.
Эффект: задержка decode-шага снижается с 50–70 мкс до 35–45 мкс. На длинных генерациях (1000+ токенов) суммарная экономия достигает 1.5–2 секунд.
--enable-chunked-prefill разбивает обработку длинного промпта на чанки фиксированного размера (задаётся через --max-num-batched-tokens 8192). Вместо монолитного prefill-прохода, который блокирует decode на всё время обработки, чанкированный prefill чередует обработку частей промпта с шагами генерации. Результат: время до первого токена для промпта в 4096 токенов сокращается с 2.1 до 0.9 секунды, а для 8192 токенов - с 4.8 до 1.7 секунды.
Побочный эффект - небольшое (3–5%) снижение общей пропускной способности из-за фрагментации вычислений. Для интерактивных сценариев это оправдано: пользователь видит первый токен в разы быстрее.
Балансировка памяти: gpu_memory_utilization 0.90 против 0.94
Параметр --gpu-memory-utilization определяет, какую долю VRAM vLLM может занять под веса и KV-кэш. Оставшаяся память резервируется под CUDA-контекст, временные буферы и пиковые аллокации во время prefill. Выбор между 0.90 и 0.94 - это выбор между стабильностью и максимальным контекстом.
Замеры на двух RTX 5060 Ti (32 ГБ суммарно):
| Параметр | gpu_memory_utilization 0.90 | gpu_memory_utilization 0.94 |
|---|---|---|
| Доступно под vLLM | 28.8 ГБ | 30.1 ГБ |
| Резерв системы | 3.2 ГБ | 1.9 ГБ |
| Веса модели (BF16 + сжатие) | 16.2 ГБ | 16.2 ГБ |
| Доступно под KV-кэш | 12.6 ГБ | 13.9 ГБ |
| Макс. контекст (NVFP4, без offload) | 8192 токенов | 10240 токенов |
| Макс. контекст (NVFP4 + offload) | 16384 токенов | 20480 токенов |
| Стабильность на длинных диалогах | OOM не зафиксирован | OOM при 18000+ токенов в 2 из 10 тестов |
Рекомендация: 0.90 для продакшен-сценариев, где падение из-за OOM недопустимо. 0.94 - для исследовательских задач с контролируемой длиной контекста, когда нужны лишние 4096 токенов и есть мониторинг потребления памяти. Разница в доступном контексте (20480 против 16384) существенна для задач summarization длинных документов, но для диалоговых агентов 16384 токенов хватает с запасом.
Вопросы квантования кэша и выбора минимального безопасного уровня разобраны в статье о KV-кэше для Qwen3.6 35B A3B - там же описаны сценарии, когда можно опуститься ниже Q8 без критичной потери качества.
Результаты тестов: скорость, задержка и стабильность
Все замеры выполнены на конфигурации: две RTX 5060 Ti 16 ГБ, AMD Ryzen 9 9950X, 64 ГБ DDR5-6000, Ubuntu 24.04, драйвер 575.51, vLLM 0.8.3, Qwen3.6-27B-Instruct. Тестовый промпт - 512 токенов, генерация - 256 токенов, температура 0.7.
| Конфигурация | Prefill (токен/с) | Decode (токен/с) | TTFT (с) | Пиковая VRAM (ГБ) |
|---|---|---|---|---|
| BF16, без NVFP4, без MTP | 1240 | OOM на prefill | — | 32.0 (OOM) |
| NVFP4, compressed-tensors, без MTP | 1180 | 14.2 | 0.9 | 28.4 |
| NVFP4, compressed-tensors, MTP 3 | 1175 | 20.1 | 0.9 | 28.9 |
| NVFP4, compressed-tensors, MTP 3, offload | 1160 | 18.7 | 0.9 | 29.8 |
| NVFP4, compressed-tensors, MTP 3, offload, chunked prefill | 1120 | 18.5 | 0.4 | 29.8 |
Ключевые выводы из таблицы:
- Без NVFP4 и сжатия тензоров запуск невозможен - OOM на стадии prefill даже при gpu_memory_utilization 0.94.
- MTP с 3 токенами даёт 41% прироста скорости decode (14.2 → 20.1 токен/с) без увеличения пиковой VRAM.
- Offloading KV-кэша снижает скорость на 7% (20.1 → 18.7), но расширяет максимальный контекст вдвое.
- Chunked prefill сокращает время до первого токена более чем вдвое (0.9 → 0.4 с) ценой 1% на decode.
Для сравнения с другими бэкендами инференса и понимания места vLLM в экосистеме рекомендуем сравнение vLLM, LMDeploy и Triton с TensorRT-LLM, где разобраны бенчмарки на H100 и B200 и дан чек-лист для выбора бэкенда под конкретную задачу.
Ограничения и возможные проблемы
Конфигурация протестирована на конкретной связке железа и версий ПО. При отклонениях возможны следующие проблемы:
- Драйверы младше 570. NVFP4 требует драйверов с поддержкой Blackwell. На 565 и ниже vLLM падает с ошибкой «NVFP4 not supported» или молча переключается на эмуляцию, что снижает скорость decode до 5–7 токен/с.
- vLLM младше 0.8.0. Поддержка NVFP4 KV-Cache и MTP для Qwen3.6 добавлена в версии 0.8.0. Более ранние сборки не распознают флаг
--kv-cache-dtype nvfp4. - Артефакты NVFP4 на сверхдлинных контекстах. При контексте свыше 16384 токенов накопление ошибок квантования в кэше может приводить к повторяющимся фразам и потере связности. Лечится увеличением
--offload-numдо 8192 и принудительным сбросом кэша каждые 10000 токенов. - Рост задержки при offloading. Когда активный контекст превышает
--offload-num, подгрузка блоков с CPU добавляет 2–4 мс задержки на каждый запрос. При 10 параллельных запросах это может суммироваться до 40 мс - критично для real-time приложений. - Несовместимость chunked prefill с некоторыми attention-бэкендами. FlashAttention-3 работает стабильно. Triton-бэкенд при включённом chunked prefill иногда выдаёт некорректные маски внимания - используйте
VLLM_ATTENTION_BACKEND=FLASH_ATTN. - Tensor-parallel коммуникации. На двух картах через PCIe 5.0 x8 пропускной способности хватает. При добавлении третьей карты или использовании PCIe 4.0 коммуникации становятся узким местом, и прирост от дополнительных GPU нивелируется.
Для диагностики проблем с памятью полезен флаг VLLM_LOGGING_LEVEL=DEBUG - он выводит построчную разбивку аллокаций VRAM. Если OOM происходит на prefill, снижайте --max-num-batched-tokens до 4096. Если на decode - уменьшайте --gpu-memory-utilization на 0.02–0.03 или увеличивайте --offload-num.
Связка RTX 5060 Ti, NVFP4 и MTP - один из самых доступных способов запустить 27B-модель с приемлемой скоростью на потребительском железе. Конфигурация не претендует на продакшен-надёжность серверных решений, но для прототипирования, тестирования агентов и локального использования показывает результаты, которые ещё недавно требовали GPU за $3000+.