vLLM: установка, настройка и оптимизация для продакшена 2026

Что такое vLLM и чем он отличается от Ollama

vLLM (very Large Language Model) — это высокопроизводительный движок для инференса и serving'а LLM, разработанный в UC Berkeley. Его ключевая инновация — PagedAttention, система управления KV-кэшем постранично, аналогично виртуальной памяти в ОС. Благодаря этому vLLM использует почти 100% доступной видеопамяти против 60-80% у конкурентов, и может обслуживать в 2-4 раза больше concurrent-запросов на том же GPU.

Многие путают vLLM с Ollama, но это принципиально разные инструменты. Ollama — это user-friendly менеджер моделей с фокусом на локальный запуск одной инстанции. vLLM — это продакшен-сервер, рассчитанный на высокие нагрузки, кластеризацию, мониторинг и гибкую конфигурацию.

Ключевые отличия vLLM от Ollama

Если ваша задача — быстро запустить локальную LLM для экспериментов — Ollama проще и удобнее. Если вам нужно обслуживать сотни пользователей в продакшене с минимальной задержкой — vLLM даёт на порядок больше контроля и производительности.

Установка vLLM: pip, Docker, сборка из исходников

vLLM поддерживает несколько способов установки. Самый простой — через pip на Linux-системе с NVIDIA GPU. Перед установкой убедитесь, что у вас установлены CUDA Toolkit (версия 11.8 или выше) и драйверы NVIDIA.

Минимальные системные требования: Linux, Python 3.10-3.13, NVIDIA GPU с 8+ GB VRAM, CUDA 11.8+. Для CPU-only инференса vLLM тоже поддерживает Intel/AMD x86 и ARM — но производительность будет значительно ниже.

Установка через pip (NVIDIA CUDA)

Лучшая практика — устанавливать в свежее виртуальное окружение:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm

На системах с Python 3.12 и UV это занимает 2-3 минуты. Официальная документация vLLM рекомендует uv как самый быстрый менеджер окружений — в 10-100 раз быстрее pip.

Установка через Docker

Для продакшена проще использовать готовый Docker-образ — он уже содержит все собранные зависимости, CUDA и runtime:

docker pull vllm/vllm-openai:latest
docker run --gpus all -p 8000:8000 -v ~/models:/models vllm/vllm-openai --model Qwen/Qwen2.5-7B-Instruct

Docker-образ весит около 12 GB и включает оптимизированные библиотеки: Flash Attention 2, cutlass, NCCL для multi-GPU. Это рекомендуемый способ для продакшен-деплоя на vLLM.

Сборка из исходников

Если нужна нестандартная конфигурация (например, поддержка AMD ROCm или специфическая версия CUDA), собирайте из исходников:

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

Сборка занимает 10-30 минут в зависимости от CPU. На GitHub vllm-project/vllm есть подробные инструкции для AMD ROCm, Intel XPU и Apple Silicon (через vLLM-Metal).

Установка на системы без GPU

vLLM работает и на CPU — используйте vllm install --target cpu или соберите с флагом VLLM_TARGET_DEVICE=cpu. Скорость будет значительно ниже (10-30 токенов/с против 200-500 на GPU), но это рабочий вариант для тестирования или разработки на ноутбуке.

Быстрый старт: запуск первой модели

После установки запустить vLLM-сервер можно одной командой. Выберем Qwen2.5-7B-Instruct — компактную, но мощную модель, которая работает на GPU с 16+ GB VRAM в 4-bit квантизации:

vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000

Сервер загрузит веса модели с Hugging Face (первый раз — скачает ~15 GB) и откроет HTTP endpoint на localhost:8000. Теперь к нему можно обращаться через любой OpenAI-совместимый клиент:

curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen2.5-7B-Instruct",
"messages": [{"role": "user", "content": "Расскажи про vLLM"}],
"max_tokens": 256
}'

Для Python-клиента используйте стандартную библиотеку openai:

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="token-abc123")
response = client.chat.completions.create(
model="Qwen/Qwen2.5-7B-Instruct",
messages=[{"role": "user", "content": "Hello vLLM"}]
)

Всё работает из коробки — никаких дополнительных прокси или адаптеров. vLLM полностью реализует OpenAI API, включая chat completions, completions, embeddings, и streaming.

Offline batched inference

Если вам не нужен HTTP-сервер, можно использовать vLLM напрямую из Python для пакетной обработки:

from vllm import LLM, SamplingParams
llm = LLM(model="Qwen/Qwen2.5-7B-Instruct")
params = SamplingParams(temperature=0.7, max_tokens=512)
outputs = llm.generate(["Prompt 1", "Prompt 2"], params)
for o in outputs:
print(o.outputs[0].text)

Этот режим подходит для batch-обработки датасетов, офлайн-генерации синтетических данных или тестирования — без поднятия HTTP-сервера.

Ключевые фичи: PagedAttention, AWQ, Prefix Caching, Speculative Decoding

vLLM включает несколько уникальных технологий, которые радикально повышают производительность инференса. Разберём каждую.

PagedAttention

Это главная инновация vLLM. В обычных инференс-движках KV-кэш (ключи и значения attention-слоёв для каждого токена) хранится в непрерывных блоках памяти. Это приводит к фрагментации — используется только 60-80% VRAM. PagedAttention разбивает KV-кэш на страницы по 16-32 токена, как виртуальная память в ОС, и аллоцирует их по мере необходимости. Результат: использование VRAM близко к 100%, возможность обслуживать больше concurrent-запросов на том же GPU.

Continuous Batching

В отличие от статического batching (собрали батч запросов — обработали — вернули результаты), vLLM использует динамическое пакетирование внутри GPU: когда один запрос закончил генерацию, на его место сразу поступает следующий из очереди. Это даёт прирост пропускной способности до 9x относительно инструментов без continuous batching (включая Ollama).

Automatic Prefix Caching (APC)

vLLM кэширует KV-кэш для повторяющихся префиксов промптов (system prompt, инструкция, контекст). Если несколько запросов имеют одинаковое начало — кэш переиспользуется, и время ответа сокращается на 30-60%. Для мульти-тенантных систем с общим system prompt это даёт колоссальную экономию. Официальная документация приводит пример: для RAG-системы с длинным контекстным префиксом APC снижает latency first token с 2 секунд до 200 мс.

Speculative Decoding

vLLM поддерживает speculative decoding — техника, при которой маленькая быстрая модель (drafter) генерирует черновик, а большая модель верифицирует его за один forward pass. Если черновик совпадает с тем, что выдала бы большая модель — получаем ускорение в 1.5-2x без потери качества. vLLM поддерживает EAGLE, Medusa и другие draft-модели.

Квантизация: AWQ, GPTQ, FP8

vLLM нативно поддерживает несколько форматов квантизации, что критически важно для продакшена, где каждый гигабайт VRAM на счету. AWQ даёт наилучшее соотношение качество/скорость (96-98% от FP16 при 3.5-4.2 GB на 7B модель). GPTQ — классический выбор, чуть медленнее, но с хорошей совместимостью. FP8 — новый стандарт на H100/H200, даёт почти без потерь качества при 8-bit.

Продакшен-конфигурация: тюнинг производительности

Дефолтные настройки vLLM — неоптимальны для продакшена. Вот что стоит настроить для максимальной производительности.

Параметры запуска

vllm serve Qwen/Qwen2.5-72B-Instruct \
--port 8000 \
--max-model-len 65536 \
--gpu-memory-utilization 0.95 \
--tensor-parallel-size 4 \
--max-num-seqs 256 \
--enable-prefix-caching \
--speculative-model "Qwen/Qwen2.5-7B-Instruct" \
--num-scheduler-steps 8

gpu-memory-utilization 0.95 — резервировать 95% VRAM для vLLM (дефолт 0.90). На production-сервере можно ставить 0.98, если не запускаете другие GPU-процессы.

tensor-parallel-size 4 — распределение одной модели на 4 GPU. vLLM автоматически делит слои между видеокартами. Для 70B модели в 4-bit нужно минимум 4 GPU по 24 GB.

enable-prefix-caching — включает APC. Обязательно для production, если ваши запросы имеют повторяющиеся префиксы.

num-scheduler-steps 8 — количество шагов шедулера за один GPU-запуск. Увеличивает пропускную способность на 20-30% ценой небольшого роста latency.

Выбор attention backend

На NVIDIA CUDA vLLM поддерживает FLASH_ATTN (дефолт) и FLASHINFER. Red Hat в своём гайде 2026 рекомендует FLASH_ATTN как наиболее стабильный. FLASHINFER даёт +5-10% скорости, но требует отдельной установки через pip install flashinfer. Для AMD ROCm используйте TRITON_ATTN или ROCM_AITER_FA.

Дополнительная оптимизация для небольших моделей

Для моделей до 8B параметров на GPU с 24+ GB VRAM можно включить CUDA Graphs — захват CUDA-графа выполнения, который ускоряет инференс на 15-30%:

vllm serve Qwen/Qwen2.5-7B-Instruct --enforce-eager --use-v2-block-manager

CUDA Graphs особенно эффективны для моделей с короткими контекстами (до 4096 токенов). Для длинных контекстов выгода меньше из-за динамической природы KV-кэша.

Бенчмарки: vLLM vs Ollama vs TGI vs SGLang

Во втором квартале 2026 года сравнительный бенчмарк четырёх основных инференс-движков показал следующие результаты:

Тесты проводились на Llama 3.1 70B (AWQ, 4-bit) на двух H100 (80 GB) с tensor parallel. vLLM уверенно лидирует по throughput — 4,250 токенов в секунду против 2,800 у TGI от Hugging Face. SGLang близок по производительности, но уступает в стабильности на длинных контекстах. Ollama — предсказуемо последний, так как не рассчитан на высокие concurrent-нагрузки.

Важный нюанс: бенчмарки измеряют throughput в идеальных условиях. В реальном продакшене с разными длинами промптов и временами между запросами разрыв может быть меньше, но vLLM всё равно остаётся лидером.

Мониторинг и логирование в продакшене

vLLM предоставляет несколько встроенных механизмов для мониторинга, без которых запускать production-сервер не стоит.

Prometheus метрики

Включите экспорт метрик флагом --enable-prometheus — vLLM начнёт отдавать данные на /metrics в формате Prometheus. Метрики включают:

• avg_request_latency — средняя задержка на запрос (ms)
• num_requests_running / num_requests_waiting — количество выполняемых и ожидающих запросов
• gpu_cache_usage_pct — использование KV-кэша в процентах
• tokens_generated_total — общее количество сгенерированных токенов

Для базового мониторинга достаточно Grafana + Prometheus. Для более глубокой обсервабильности можно использовать логирование запросов в JSON-формате.

Логирование запросов

vLLM умеет логировать каждый входящий запрос в JSON-формате — модель, промпт, latency, количество токенов. Это удобно для аудита, анализа использования и расчёта стоимости:

vllm serve Qwen/Qwen2.5-7B-Instruct --log-requests --log-stats --max-log-len 1000

Best practice для production: комбинировать Prometheus метрики + JSON-логи + Grafana дашборд. Это покрывает 90% сценариев инцидентов — падение throughput, рост latency, утечка VRAM.

OpenAI-совместимый API: интеграция с клиентами

Полная OpenAI-совместимость — одна из главных причин выбирать vLLM. Вы просто меняете base_url в вашем клиенте и API-ключ (vLLM принимает любой), и всё работает. Никаких прокси, адаптеров или SDK.

Поддерживаемые endpoints

/v1/chat/completions — основной эндпоинт для чат-моделей. Полностью совместим с API OpenAI, включая streaming (server-sent events), функции (tool calls), logprobs, stop sequences, frequency/presence penalty, seed для воспроизводимости.

/v1/completions — для completion-моделей (text-davinci-стиль). Полезен для специфических задач вроде заполнения шаблонов.

/v1/embeddings — получение эмбеддингов. Пригодится для RAG-пайплайнов — один сервер может одновременно обслуживать и генерацию, и эмбеддинги.

/v1/models — список загруженных моделей. Полезен для Service Discovery.

Rate Limiting и аутентификация

Встроенного rate limiting у vLLM нет — это делается снаружи через API Gateway (LiteLLM, Portkey, Kong). Аутентификация минимальная — любой API-ключ принимается. Для продакшена обязательно ставить API Gateway с rate limiting, аутентификацией и observability.

Пример интеграции с LiteLLM:

# config.yaml
model_list:
- model_name: vllm-qwen
litellm_params:
model: openai/Qwen/Qwen2.5-7B-Instruct
api_base: http://vllm-server:8000
api_key: sk-vllm

LiteLLM берёт на себя rate limiting, балансировку между несколькими vLLM-серверами и мониторинг.

Коротко: что выбрать

vLLM — выбор для production. Если вам нужно обслуживать десятки и сотни concurrent-запросов с минимальной задержкой, vLLM даёт наилучшую производительность (до 9x быстрее Ollama), полный контроль над инференсом (PagedAttention, continuous batching, speculative decoding) и готовую OpenAI-совместимую API.

Ollama — для экспериментов. Если вы тестируете модель локально, пишете proof-of-concept или запускаете AI-ассистента для себя — начинайте с Ollama. Это проще, быстрее, и не требует разбираться в параметрах шедулера.

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

Что ещё важно знать