vLLM и TGI ломаются не на модели, а на неправильном профиле нагрузки

vLLM и TGI ломаются не на модели, а на неправильном профиле нагрузки

Если у тебя один и тот же чекпоинт, но разные паттерны запросов, итог по latency и throughput может отличаться в разы. Для длинного контекста и высокой конкуренции чаще выигрывает vLLM: PagedAttention лучше держит память, а continuous batching меньше простаивает на коротких хвостах.

TGI обычно удобнее, когда нужен более предсказуемый продовый контур: понятные параметры запуска, стабильная интеграция с Hugging Face-экосистемой, хороший дефолт для стандартного чат-инференса. Но если у тебя много параллельных сессий и плавающая длина промптов, проверь, как сервер ведёт себя при росте очереди и как быстро деградирует p95.

Проверяй не только tokens/sec, а три вещи:
— prefill latency на длинном промпте;
— decode latency под 8–32 concurrent users;
— падение throughput при увеличении max_model_len и включении kv-cache.
Именно здесь часто видно, что «быстрый» сервер в синтетике проигрывает в реальном проде.

Если выбираешь между ними без теста, бери оба в одинаковой квантизации, одинаковом batch/queue лимите и одинаковом контексте. Сравни на своих промптах, а не на бенчмарке из README: для одной и той же модели разница может быть не в качестве, а в том, сколько запросов ты обслужишь на одной GPU.