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

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

Если у тебя длинный контекст, много одновременных запросов и нужен высокий throughput, vLLM обычно выигрывает за счёт paged attention и агрессивного batching. Но цена этого — более жёсткие требования к профилю нагрузки: при коротких одиночных запросах разница с TGI может исчезать, а p95 latency иногда хуже, чем ожидаешь.

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

Правило выбора простое:
— vLLM: много параллельных запросов, shared GPU, высокий token/sec
— TGI: более ровный трафик, важна стабильность и эксплуатация
— llama.cpp: маленькие модели, CPU/GGUF, edge и экономия памяти

Не сравнивай фреймворки только по токенам/сек. Смотри на time-to-first-token, p95 latency, max context под твою модель и сколько запросов сервер держит без деградации. На практике узкое место часто не GPU, а очередь, KV-cache и слишком агрессивный batching.

Если нужен один ответ на проде — выбирай по паттерну трафика, а не по чужому бенчмарку. Правильный стек тот, который держит твой SLA на твоём профиле нагрузки.