vLLM или TGI: 4 параметра, по которым выбирают inference-стек в проде

vLLM или TGI: 4 параметра, по которым выбирают inference-стек в проде

Если модель одна и та же, разница в ощущениях почти всегда упирается не в quality, а в scheduling, batching и память. Смотрите на четыре вещи: 1) длина контекста и доля длинных запросов; 2) нужен ли continuous batching; 3) насколько важен стабильный p95 latency; 4) как вы будете шарить GPU между несколькими моделями.

vLLM обычно берут там, где нужен высокий throughput на mixed load и много параллельных запросов. Его сильная сторона — paged attention и агрессивная утилизация VRAM. Это особенно заметно, когда входы короткие, а генераций много: токены на GPU растут, пока очередь не начинает упираться в decode. Для chat-API и automation-пайплайнов это часто самый удобный вариант.

TGI чаще выбирают, когда важнее предсказуемость и более «серверный» режим обслуживания. Он хорошо ложится в сценарии, где есть фиксированные SLA, аккуратный контроль очередей и понятная эксплуатация. Если запросы длинные, а задержка на первом токене критична, TGI нередко ведёт себя стабильнее за счёт более консервативного профиля планирования.

Практика простая: если вы строите внутренний API для агентов, начните с vLLM; если нужен более дисциплинированный inference-сервис под SLA и понятные лимиты на очередь — смотрите TGI. Потом прогоняйте одинаковый бенч: одинаковая модель, одна квантизация, один batch profile, иначе сравнение превращается в шум.

Выбирают не «лучшую библиотеку», а стек под профиль нагрузки: сначала измеряете p95, затем throughput, и только потом трогаете квантизацию и железо.