vLLM vs TGI: сравнение inference-серверов для production

Deployment & Infra 6 июля 2026 г. 19 мин чтения · Редакция openpromt

vLLM и TGI (Text Generation Inference) — два самых зрелых inference-сервера для production-grade LLM. Оба обслуживают open-source модели с OpenAI-совместимым API, поддерживают continuous batching, batching, paged attention, и quantization. В этой статье — сравнение по архитектуре, throughput, операционным сложностям и рекомендации по выбору.

Архитектурные основы

Что такое vLLM

vLLM — open-source inference-сервер, разработанный в UC Berkeley (PhD-проект Университета) с контрибуторами из Anyscale, Google и других организаций. Первая стабильная версия вышла в начале 2023. Основная инновация — алгоритм PagedAttention, описанный в статье на SOSP 2023. Идея: KV-кэш attention-блоков выделяется через виртуальную память GPU по требованию, а не заранее, что устраняет фрагментацию и позволяет держать в 4-24 раза больше одновременных запросов в одной GPU-партиции.

# Минимальный запуск vLLM
docker run --gpus all -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model mistralai/Mistral-7B-Instruct-v0.2 \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.9 \
  --dtype bfloat16

После запуска сервер слушает на :8000 и принимает OpenAI-совместимые API-запросы. Любой код, работающий с OpenAI SDK через base_url=http://localhost:8000/v1, будет работать без изменений — полная drop-in замена.

Что такое TGI

TGI (Text Generation Inference) — inference-сервер от Hugging Face, активно развивается с 2022. Архитектурно проще — построен вокруг стандартных PyTorch primitives с оптимизациями на уровне Rust-шейдеров. Поддерживает Rust + Python, что даёт хорошие показатели на streaming-задачах (SSE-стриминг токенов).

# Минимальный запуск TGI
docker run --gpus all -p 8080:80 \
  ghcr.io/huggingface/text-generation-inference:latest \
  --model-id mistralai/Mistral-7B-Instruct-v0.2 \
  --max-input-length 4096 \
  --max-total-tokens 4096

TGI тоже предоставляет OpenAI-совместимое API через http://localhost:8080/v1. Различие в портах и CLI-параметрах.

PagedAttention vs классический KV-кэш

Ключевая техническая разница — управление памятью под KV-кэш (key-value cache attention слоёв). При генерации каждого токена для всех активных запросов нужно хранить key и value вектора всех ранее сгенерированных токенов. На серийном A100 80GB + Mistral 7B + bf16 KV-кэш каждого запроса занимает ~256K tokens в памяти.

Статическое выделение (как в TGI по умолчанию) резервирует большой блок заранее. Это приводит к фрагментации: запросы с короткими и длинными output’ами занимают одинаково, но реально используют по-разному. С 16 активными запросами в партиции реальная утилизация KV-кэша ~30-40%.

PagedAttention (vLLM) делит KV-кэш на страницы по 16 токенов каждая, выделяет по требованию, переиспользует освободившиеся блоки. С теми же 16 запросами реальная утилизация достигает 90%+ — можно держать в 4-5 раз больше одновременных запросов.

Метрика	TGI (статический KV-кэш)	vLLM (PagedAttention)
Concurrent requests на A100 80GB / Mistral 7B	~16-20	~80-100
Throughput (tokens/sec)	1500-2200	3000-4500
Latency (p50 / first-token)	~80 ms	~60 ms
Memory utilization	30-40%	90%+
Time to first token (TTFT)	~120 ms	~80 ms

Цифры — публичные benchmarks из докладов разработчиков и пользователей (Reddit, GitHub discussions). Реальные показатели на вашем железе и модели отличаются на 20-50%.

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

Оба сервера поддерживают широкий набор open-source моделей, но архитектура совместимости разная.

vLLM использует архитектуру с явными классами моделей: LLaMA, Mistral, Mixtral (MoE), Qwen 2.5, Gemma 2, DeepSeek, Phi-3, OPT, Falcon, MPT, BLOOM. Каждая модель реализована как Python-класс, наследующий от LlamaForCausalLM или аналогичного. Для новых архитектур нужно дописывать класс, но 95% моделей в HuggingFace Hub работают из коробки.

TGI использует Rust/Python-стек, который не зависит от конкретной архитектуры модели в такой степени — поддерживает custom kernels для популярных случаев, но конфигурация гибче. Документация Hugging Face отмечает поддержку Mistral, LLaMA 2/3, Qwen, Gemma, Phi, и других.

На практике для популярных моделей разницы нет — оба работают. Для менее распространенных (custom fine-tunes, экзотические MoE-архитектуры) vLLM обычно требует меньше настройки благодаря строгой типизации моделей.

Квантизация и оптимизация памяти

Квантизация моделей критична для production — позволяет запускать бо́льшие модели на меньшем железе или обслуживать больше запросов параллельно на том же железе.

vLLM поддерживает:

GPTQ (4-bit, посттренировочная) — стандартный формат
AWQ (4-bit, активационно-осведомлённая) — лучше качество на 4-bit чем GPTQ
BitsAndBytes (NF4) — для quick-prototyping, качество ниже
SmoothQuant — для INT8 с минимальной потерей качества
AQLM (2-bit!) — экстремальное сжатие, потеря качества заметная
FP8 — нативная поддержка на H100/Ada

TGI поддерживает GPTQ и AWQ напрямую, остальные форматы — через bitsandbytes. Список поддерживаемых форматов у vLLM шире, и качество quantization-benchmarks у vLLM стабильно выше за счёт постоянного тюнинга алгоритмов.

Streaming и latency

Оба сервера поддерживают Server-Sent Events (SSE) для streaming-генерации. TGI исторически был быстрее на streaming-задачах благодаря Rust-шейдерам, но в 2025-2026 разница сократилась — vLLM догнал и в отдельных benchmarks обгоняет.

Latency-оптимизации:

vLLM: prefix-caching (повторное использование KV-кэша для общих префиксов), chunked prefill (обработка prompt и generation в одной партиции), speculative decoding
TGI: similar set, но через Rust-уровень

Для чат-ботов и agent-систем, где latency важнее throughput, обе системы дают p50 TTFT (time to first token) 50-150 ms. Разница 10-30 ms обычно не критична.

Continuous batching

Continuous batching — это способность обрабатывать несколько запросов одновременно, переиспользуя compute между ними. Оба сервера поддерживают, но реализация разная.

vLLM (начиная с v0.4+) использует PagedAttention, который позволяет динамически добавлять новые запросы в партицию по мере завершения предыдущих. Это известно как iteration-level scheduling.

TGI использует request-level batching с поддержкой continuous batching через Rust scheduler. По throughput уступает vLLM на 20-50% в mixed-workload сценариях.

Когда выбрать vLLM

Идеальные сценарии для vLLM:

Высокий throughput на одном GPU (10+ tokens/sec для моделей 7B+)
Mixed-workload с разной длиной запросов (RAG, agent-системы, batch-JOB)
Чувствительность к memory-utilization (важно держать много concurrent requests)
Использование специализированных форматов (AWQ, FP8)
Активная community, свежие обновления каждые 2-4 недели

Оптимальные настройки для начала:

docker run --gpus all -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-72B-Instruct \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --dtype bfloat16 \
  --enable-prefix-caching \
  --max-num-seqs 256

enable-prefix-caching — главная оптимизация для RAG и chat-сценариев: одинаковый system prompt кэшируется между запросами, экономя KV-кэш и ускоряя TTFT.

Когда выбрать TGI

Идеальные сценарии для TGI:

Single-stream задачи с приоритетом latency (50-100 ms p50)
Развёртывание в среде с уже работающим Hugging Face-стеком (Hub, Inference Endpoints)
Предпочтение Rust-based reliability (если в команде есть Rust-экспертиза)
Использование специфических HF-фичей (BitsAndBytes из коробки)
Зрелость API и стабильность релизов (TGI 1.x стабилен уже 2+ года)

Дополнительные inference-серверы в 2026

Помимо vLLM и TGI, есть несколько альтернатив:

SGLang — RadixAttention optimization для структурированной генерации, LMQL-programs. Хорош для structured-output задач.
MLServer от Seldon — для multi-framework serving (PyTorch, TensorFlow, ONNX). Не специфичен для LLM.
NeuronX (для AWS Inferentia/Trainium) — оптимизированный inference на AWS-чипах.
Ollama — для desktop/single-user работы, не для high-throughput.

В production-сетупации в 2026 выбор сужается до vLLM vs TGI, оба доминируют. SGLang нишевый, MLServer шире но менее LLM-оптимизирован.

Операционные сложности

Оба проекта предоставляют Docker-образы и Helm-чарты. Multi-GPU обслуживание (tensor-parallel для моделей 70B+) поддерживается обоими.

Аспект	vLLM	TGI
Multi-GPU tensor parallel	Да	Да
Pipeline parallel	Да (экспериментально)	Нет в стандартном Docker, кастомный
Speculative decoding	Да	Да
LoRA-swap на одной базе	Да (LoRA Request)	Нет из коробки
Production deployments	vLLM Production Stack (Anyscale)	HF Inference Endpoints
Self-hosted cluster	Kubernetes + custom	Kubernetes + custom
Мониторинг	Prometheus metrics endpoint	Prometheus metrics endpoint
OpenAI API совместимость	Полная	Полная

Операционно — паритет. Выбор по производительности и специфическим фичам (AWQ, prefix-caching, PagedAttention).

Заключение

vLLM выигрывает на throughput-задачах благодаря PagedAttention и более широкой поддержке квантизации. TGI выигрывает на latency-задачах и зрелости API. Для production выбирайте по результатам load-тестов на вашем workload — конкретные цифры сильно зависят от модели, длины запросов, и GPU-конфигурации. Если production-high-throughput — vLLM. Если важно latency-качество streaming — TGI. Оба бесплатны, оба open-source, оба OpenAI-совместимы.

Для тех, кто поднимает inference впервые и хочет максимально простой путь — начните с Ollama на laptop или одном GPU, а когда понадобится production-throughput — мигрируйте на vLLM. Ollama разрабатывался как simple-and-good-enough для desktop, а vLLM — для серверов под нагрузкой. Переход с Ollama на vLLM прозрачный (OpenAI-совместимый API у обоих), код клиента не меняется.

Часто задаваемые вопросы

vLLM быстрее TGI или наоборот

vLLM обычно быстрее TGI на 20-50% в throughput-задачах (batch-inference). На single-stream latency-задачах разница меньше — обычно в пределах 10-15%. Преимущество vLLM вытекает из PagedAttention — эффективного управления KV-кэшем через виртуальную память GPU, что позволяет держать больше одновременных запросов в одной партиции. Точные цифры зависят от модели и GPU — публичные benchmarks показывают разброс от 10% до 100% разницы.

vLLM поддерживает Mistral / LLaMA / Qwen из коробки

Да, vLLM поддерживает большинство популярных open-source моделей: LLaMA 2/3, Mistral / Mixtral, Qwen 2.5, Gemma 2, DeepSeek, OPT, Falcon и другие. Поддержка реализована через vLLM-имплементации моделей, которые наследуются от базового класса. Для кастомных архитектур нужен свой класс, но 95% open-source моделей работают из коробки без модификации.

Можно ли использовать vLLM и TGI одновременно на одном GPU

Технически да, но не рекомендуется. Каждый сервер занимает видеопамять под свои модели + KV-кэш. На одном GPU удобнее запустить один сервер, который обрабатывает запросы к нескольким моделям через OpenAI-совместимое API. vLLM поддерживает LoRA-swap, что позволяет держать одну базовую модель и несколько LoRA-адаптеров в одной видеопамяти.

Какой inference-сервер проще в развертывании

TGI проще в развертывании — один Docker-контейнер с model_id, и сервер готов. vLLM требует немного больше конфигурации: явный max-model-len, gpu-memory-utilization, enforce-eager (если нужно), dtype. Для простых кейсов разница минимальна — оба запускаются через docker. Для production-нагрузок vLLM требует тюнинга параметров под hardware, но это даёт больше контроля над memory utilization.

Какой сервер поддерживает квантизацию из коробки

Оба. vLLM поддерживает GPTQ, AWQ, BitsAndBytes (NF4), SmoothQuant, AQLM для inference. TGI тоже поддерживает GPTQ и AWQ напрямую через bitsandbytes. Для совместимости с контейнерной доставкой рекомендую GPTQ или AWQ — оба формата стандартизированы и хорошо поддерживаются обеими системами. AWQ даёт лучшее quality-per-bit чем GPTQ на большинстве моделей.

Стоит ли вообще использовать vLLM или TGI, или проще через Ollama

Для production-нагрузок (10+ req/s, batch-inference, требования к latency 100-500 ms) vLLM и TGI существенно обходят Ollama. Ollama оптимизирован для desktop и small-batch case, разрабатывался как single-user. vLLM и TGI были созданы для server-grade-нагрузки. Если у вас один пользователь с запросами раз в минуту — Ollama отлично подойдет. Если нужно обслуживать web-сервис или API с десятками concurrent requests — выбирайте vLLM или TGI.