vLLM и TGI — это не «какой сервер лучше», а какой trade-off нужен под вашу нагрузку

vLLM и TGI — это не «какой сервер лучше», а какой trade-off нужен под вашу нагрузку

Если у вас батчится много коротких запросов, нужен высокий throughput и предсказуемая задержка на GPU, vLLM обычно выигрывает за счёт continuous batching и эффективной работы с KV cache. Если важнее интеграция в продовый стек, контролируемые пайплайны и более консервативное поведение, TGI часто удобнее как сервисный слой.

Смотрите не на «tokens/sec в вакууме», а на профиль нагрузки:
• короткие промпты + много параллельных клиентов → vLLM
• длинный контекст + редкие, но тяжёлые ответы → TGI
• жёсткий SLO по p95 latency → тестируйте оба на своём распределении запросов

Критичный момент — память. На одной и той же GPU разница между fp16 и int4 может решить, влезет ли модель с 32k контекстом вообще, но throughput упадёт по-разному: у одной модели упор в compute, у другой — в memory bandwidth. Поэтому сравнивать надо на одинаковой квантизации, одинаковом max context и одинаковом числе одновременных сессий.

Ещё одна типовая ошибка — мерить только one-shot benchmark. В проде решает смесь: prefill latency, decode throughput, падение скорости на длинном контексте и поведение при росте очереди. Если сервер хорош в демо, но начинает «плыть» после 8–16 concurrent requests, это не production-ready конфигурация.