vLLM и TGI: где ломается продовый инференс, если выбрать не тот сервер

vLLM и TGI: где ломается продовый инференс, если выбрать не тот сервер

Если модель крутится через OpenAI-совместимый API, сервер решает больше, чем кажется: batching, paged attention, KV-cache, очереди и обрезка контекста. На одинаковой GPU один стек может держать ровную латентность, другой — упираться в head-of-line blocking уже на среднем concurrency.

vLLM обычно берут, когда нужен высокий throughput на генерации и много коротких запросов. Его сильная сторона — continuous batching и эффективная работа с KV-cache; слабая — сложнее предсказать p95 при длинных ответах и тяжёлых system prompts. Если у вас смесь чатов и tool-calls, обязательно меряйте не только tokens/sec, но и время до первого токена.

TGI удобен там, где важны стабильность пайплайна, понятная эксплуатация и интеграция в production-инфраструктуру. Он часто проще для команды, но на том же железе может проигрывать vLLM по утилизации GPU при высокой конкуррентности. Для длинного контекста и больших batch-ей сравнивайте не “скорость модели”, а реальную пропускную способность под вашим профилем трафика.

Чек-лист перед выбором: 1) фиксируйте размер контекста и долю длинных ответов; 2) гоняйте нагрузку с реальными prompt-ами, а не синтетикой; 3) смотрите p50/p95 latency, OOM-поведение и деградацию при росте очереди; 4) проверяйте, как сервер ведёт себя при нескольких моделях на одном узле. Правильный выбор — это не “быстрее на бенче”, а меньше сюрпризов в проде.