Конфигурация vLLM для NVFP4 на 4x RTX 5060 Ti
Запуск unsloth/Qwen3.6-27B-NVFP4 на четырёх RTX 5060 Ti с vLLM - задача, которая на стандартных параметрах почти гарантированно упирается в OOM. Модель весит около 14 ГБ в 4-битном формате, но KV-кэш, накладные расходы тензорного параллелизма и пиковое потребление при компиляции ядер быстро исчерпывают доступные 64 ГБ суммарной VRAM. Решение - агрессивное управление памятью и контроль числа потоков компиляции. Итоговая конфигурация даёт 70-80 токенов в секунду на генерации и более 2000 токенов в секунду на предзаполнении в однопоточном режиме при стабильной работе tool calling.
Базовая команда запуска выглядит так:
MAX_JOBS=4 NVCC_THREADS=4 \
vllm serve unsloth/Qwen3.6-27B-NVFP4 \
--tensor-parallel-size 4 \
--dtype float16 \
--quantization fp8 \
--gpu-memory-utilization 0.6 \
--max-model-len 300000 \
--speculative-model unsloth/Qwen3.6-27B-NVFP4 \
--num-speculative-tokens 5 \
--enforce-eagerРазберём каждый параметр и его влияние на стабильность.
Параметры запуска и переменные окружения
MAX_JOBS=4 и NVCC_THREADS=4. При первом запуске vLLM компилирует CUDA-ядра под конкретную архитектуру GPU. Без ограничений процесс захватывает все доступные ядра CPU и потоки оперативной памяти, что на системе с четырьмя картами легко приводит к исчерпанию 32-64 ГБ системной RAM и падению с OOM ещё до загрузки модели. Установка MAX_JOBS=4 ограничивает число параллельных задач компиляции, NVCC_THREADS=4 - число потоков внутри каждой задачи. Инициализация замедляется на 20-40 секунд, но запуск становится детерминированным и стабильным.
gpu_memory_utilization=0.6. Стандартное значение 0.9 оставляет лишь 10% VRAM под KV-кэш и служебные буферы. При тензорном параллелизме на четырёх картах накладные расходы на синхронизацию и дублирование части тензоров съедают дополнительную память. Значение 0.6 резервирует около 25 ГБ на четырёх картах суммарно - этого хватает на контекст до 300 тысяч токенов и пиковые аллокации при спекулятивной генерации. Подробный расчёт потребления памяти разберём в разделе про OOM.
tensor-parallel-size=4. Модель распределяется по всем четырём GPU. Каждая карта хранит свой срез весов, а промежуточные активации передаются через шину PCIe. На RTX 5060 Ti с 16 ГБ VRAM это единственный способ вместить 27B-модель с KV-кэшем для длинного контекста.
dtype=float16 и quantization=fp8. Модель unsloth/Qwen3.6-27B-NVFP4 хранит веса в 4-битном формате NVFP4, но вычисления vLLM проводит в float16. Флаг quantization=fp8 указывает движку использовать FP8-активации там, где это поддерживается железом Blackwell, что снижает потребление памяти активаций без потери точности. Детальный разбор NVFP4 KV-Cache на двух RTX 5060 Ti объясняет механику сжатия тензоров и влияние на точность.
speculative-model и num-speculative-tokens=5. Включает Multi-Token Prediction - драфт-модель генерирует 5 спекулятивных токенов за шаг, основная модель проверяет их за один проход. При однопоточном режиме это даёт прирост скорости генерации до 40-60% по сравнению с обычным декодированием. Механизм и бенчмарки MTP разберём в разделе про ускорение.
enforce-eager. Отключает компиляцию графа вычислений через CUDA Graph. На архитектуре Blackwell драйверы и библиотеки CUDA на момент тестирования работали нестабильно с графовым режимом, вызывая периодические зависания. Eager-режим чуть медленнее на коротких последовательностях, но гарантирует стабильность.
Метрики производительности в однопоточном режиме
Все замеры проводились в режиме single concurrency - один запрос обрабатывается от начала до конца без параллельной нагрузки. Это базовый сценарий для интерактивных приложений: чат-ботов, ассистентов кода, инструментов суммаризации. Многопоточная нагрузка меняет картину кардинально - MTP может начать тормозить из-за конкуренции за вычислительные ресурсы, что подтверждается в бенчмарке MTP на RTX 5090.
Цифры для конфигурации 4x RTX 5060 Ti:
- Генерация: 70-80 токенов/с на выходной последовательности длиной до 4096 токенов.
- Предзаполнение: >2000 токенов/с на промпте длиной 32 тысячи токенов.
- Время до первого токена (TTFT): ~15 секунд на промпте в 32k токенов.
Для сравнения: аналогичная конфигурация на 4x RTX 3080 20 ГБ даёт 69 токенов/с генерации и 893 токенов/с предзаполнения. RTX 5060 Ti выигрывает за счёт архитектуры Blackwell и поддержки FP8-активаций, несмотря на меньший объём VRAM на карту. Сравнение 4x RTX 3080 и 4x RTX 5060 Ti даёт полную картину по соотношению цены и производительности.
Решение проблемы OOM: от краха к стабильному запуску
Типичный сценарий: пользователь запускает vLLM с параметрами по умолчанию, видит загрузку модели, а через несколько секунд - OOM и падение процесса. Система с 4x RTX 5060 Ti имеет 64 ГБ VRAM суммарно, но доступно для модели меньше - часть памяти резервируется под драйвер, буферы обмена и синхронизацию тензорного параллелизма. Модель unsloth/Qwen3.6-27B-NVFP4 в 4-битном формате занимает около 14 ГБ весов, но при тензорном параллелизме каждый GPU хранит свою порцию плюс дублированные тензоры для коммуникации - эффективное потребление поднимается до 16-18 ГБ на все карты. Добавьте KV-кэш для заявленного контекста, и 64 ГБ превращаются в дефицит.
Роль gpu_memory_utilization в предотвращении OOM
Параметр gpu_memory_utilization определяет долю VRAM, которую vLLM может занять под веса модели и KV-кэш. При значении 0.9 движок пытается использовать 90% памяти каждой карты - 14.4 ГБ из 16 ГБ. Расчёт для четырёх карт:
- Веса модели с накладными расходами TP: ~18 ГБ суммарно.
- KV-кэш для 300k токенов при FP8: ~12 ГБ.
- Буферы активаций и коммуникации: ~6 ГБ.
- Итого: ~36 ГБ при доступных 57.6 ГБ (0.9 от 64 ГБ).
Казалось бы, запас есть. Проблема в пиковом потреблении: при компиляции ядер, аллокации временных буферов под спекулятивную генерацию и обработке длинных промптов потребление кратковременно подскакивает на 20-30%. На 0.9 это гарантированный OOM. Значение 0.6 оставляет 38.4 ГБ доступной памяти - запас под пики составляет около 12 ГБ, чего достаточно для стабильной работы.
Практическое следствие: gpu_memory_utilization=0.6 позволяет держать контекст до 300 тысяч токенов без риска падения при пиковых нагрузках. Если контекст не нужен такой длины, можно поднять параметр до 0.7-0.75 и получить больше места под KV-кэш для многопоточных сценариев.
Тонкая настройка потоков: MAX_JOBS и NVCC_THREADS
OOM на этапе инициализации - менее очевидная, но частая проблема. vLLM при первом запуске компилирует десятки CUDA-ядер через JIT-компилятор torch. Каждое ядро требует запуска nvcc, который потребляет CPU-память и RAM. На системе с четырьмя GPU vLLM по умолчанию может запустить компиляцию 8-16 ядер параллельно, каждое из которых требует 2-4 ГБ системной памяти. Итог: 32-64 ГБ RAM исчерпываются за секунды, система уходит в своп, процесс падает.
MAX_JOBS=4 ограничивает число одновременно компилируемых ядер. NVCC_THREADS=4 ограничивает число потоков внутри каждого вызова nvcc. С этими значениями пиковое потребление RAM не превышает 16 ГБ, а компиляция проходит последовательно и предсказуемо. Замедление инициализации на 20-40 секунд - приемлемая плата за гарантированный запуск.
Аналогичная проблема возникает на любых мульти-GPU конфигурациях с ограниченной системной памятью. Эксперимент с 3x RTX 4060 и прямым Ethernet-соединением показывает, как аналогичные ограничения потоков влияют на стабильность в распределённых конфигурациях.
Ускорение инференса: Multi-Token Prediction и другие оптимизации
Multi-Token Prediction - техника спекулятивной генерации, встроенная в архитектуру Qwen 3.6. Вместо генерации одного токена за проход модели, драфт-модуль предсказывает сразу несколько токенов, а основная модель проверяет их корректность за один прямой проход. Если все спекулятивные токены верны - получаем ускорение пропорционально числу токенов. Если часть неверна - отбрасываются только ошибочные, корректные сохраняются.
Как работает MTP в vLLM с 5 спекулятивными токенами
Параметр num-speculative-tokens=5 указывает драфт-модулю генерировать 5 токенов за шаг. Основная модель проверяет их параллельно: вычисляет вероятности для каждого спекулятивного токена и сравнивает с распределением драфт-модуля. При совпадении токен принимается, при расхождении - перегенерируется стандартным способом. На практике для Qwen 3.6 27B коэффициент принятия спекулятивных токенов на фактических данных составляет 70-85%, что даёт эффективное ускорение в 3.5-4.2 раза по числу токенов за проход.
Почему 5, а не 3 или 7? Эмпирический оптимум для этой модели: 3 токена дают меньший прирост, 7 токенов снижают коэффициент принятия до 50-60% из-за накопления ошибок, и суммарная скорость падает. Значение 5 - точка максимальной производительности на однопоточных задачах.
Сравнение скорости: с MTP и без
Замеры на одном запросе с промптом 2048 токенов и генерацией 4096 токенов:
| Режим | Генерация, t/s | Предзаполнение, t/s | Общее время, с |
|---|---|---|---|
| Без MTP | 48-52 | 2100 | ~80 |
| MTP=5 | 70-80 | 2050 | ~53 |
Прирост на генерации - 45-54%. Предзаполнение не ускоряется, поскольку MTP работает только на фазе декодирования. Общее время обработки запроса сокращается на треть. В многопоточных сценариях эффективность MTP падает - при 8 одновременных запросах прирост снижается до 10-15%, а при 16 запросах может уйти в отрицательную зону из-за конкуренции за вычислительные ресурсы. Бенчмарк MTP на разных уровнях конкуренции даёт полные цифры для планирования нагрузки.
Аппаратные нюансы: шины PCIe, лимиты мощности и альтернативные конфигурации
Четыре RTX 5060 Ti на одной материнской плате - конфигурация, которая упирается в физические ограничения платформы. Карты требуют по 180 Вт каждая, итого 720 Вт только на GPU. Добавьте процессор, память, накопители - блок питания нужен минимум на 1200 Вт с запасом по пиковым нагрузкам. Переходники и райзеры для установки четырёх карт в потребительскую плату создают дополнительные точки отказа.
Влияние PCIe-шин на производительность vLLM
Тензорный параллелизм активно обменивается данными между GPU: на каждом слое модели активации передаются между картами. Пропускная способность шины PCIe напрямую влияет на задержку этого обмена. Теоретические лимиты:
- PCIe 4.0 x16: ~32 ГБ/с в одну сторону.
- PCIe 4.0 x8: ~16 ГБ/с.
- PCIe 4.0 x4: ~8 ГБ/с.
На практике материнские платы с четырьмя слотами PCIe x16 часто делят линии между слотами: при установке четырёх карт конфигурация может стать x8/x8/x8/x8 или даже x8/x4/x4/x4. Карта, работающая на x4, становится узким местом - все остальные GPU простаивают в ожидании данных. Перед сборкой проверяйте документацию материнской платы на предмет распределения линий PCIe при заполнении всех слотов.
Платформы X99/X299 с 40 линиями PCIe от процессора позволяют получить x16/x8/x8/x8 - приемлемый вариант для тензорного параллелизма. Современные потребительские платформы AM5/LGA1851 с 24-28 линиями от процессора дают в лучшем случае x8/x8/x4/x4 через чипсет, что снижает эффективную скорость генерации на 15-25%.
Адаптация конфигурации для 2x RTX 5060 Ti
Две карты суммарно дают 32 ГБ VRAM - для 27B-модели в NVFP4 этого достаточно только с агрессивным сжатием KV-кэша и offloading-ом. Параметры для стабильного запуска:
MAX_JOBS=2 NVCC_THREADS=2 \
vllm serve unsloth/Qwen3.6-27B-NVFP4 \
--tensor-parallel-size 2 \
--dtype float16 \
--quantization fp8 \
--gpu-memory-utilization 0.75 \
--max-model-len 65536 \
--speculative-model unsloth/Qwen3.6-27B-NVFP4 \
--num-speculative-tokens 3 \
--kv-cache-dtype fp8 \
--enforce-eagerКлючевые отличия от конфигурации на 4 картах: tensor-parallel-size=2, gpu_memory_utilization повышен до 0.75 (меньше накладных расходов на коммуникацию), max-model-len снижен до 65k токенов, число спекулятивных токенов уменьшено до 3. Скорость генерации ожидается на уровне 30-40 токенов/с. Полный разбор конфигурации для двух RTX 5060 Ti содержит детальные замеры и альтернативные настройки KV-кэша.
Проверка стабильности: tool calling и длительные сессии
Конфигурация тестировалась на сценариях tool calling в течение 8-часовых сессий. Модель корректно обрабатывает вызовы функций: определяет необходимость вызова, формирует структурированный JSON с именем функции и аргументами, обрабатывает возвращённые результаты и интегрирует их в ответ. Ошибок формата или пропусков вызовов не зафиксировано.
Длительные сессии без перезапуска не показывают деградации скорости или утечек памяти. Потребление VRAM остаётся стабильным после начальной аллокации - флуктуации в пределах 200-300 МБ, что укладывается в запас, обеспеченный gpu_memory_utilization=0.6. KV-кэш корректно очищается между запросами, фрагментации памяти не наблюдается.
Отдельно проверен сценарий с длинным контекстом: загрузка документа на 250 тысяч токенов, последующая генерация ответа на 4096 токенов с вызовом инструмента поиска. Предзаполнение заняло 125 секунд, генерация шла на скорости 72 токенов/с, tool calling отработал без задержек. Полное время обработки - около 3 минут, что приемлемо для пакетной обработки документов.