vLLM и TGI ломают прод в разных местах — проверь это до миграции

vLLM и TGI ломают прод в разных местах — проверь это до миграции

Если модель крутится на одной GPU и у тебя короткий контекст, оба сервера могут дать похожий throughput. Но различие вылезает на пачках запросов, длинном контексте и при высокой конкуренции за KV-cache: один лучше держит параллелизм, другой чаще упирается в память и batching-паттерн.

Смотри на 4 вещи:
— модель и квантизация: fp16, int8, int4, GGUF дают разный баланс качества и скорости;
— длина контекста: заявленные 128k не равны рабочим 128k, latency растёт нелинейно;
— форма трафика: много коротких запросов, один длинный диалог или смешанный поток;
— механизм batch/prefill/decode: именно он решает, сколько tokens/sec ты увидишь в проде.

vLLM обычно берут, когда нужен агрессивный continuous batching и высокая утилизация GPU. TGI удобен, если важнее предсказуемость, простая эксплуатация и интеграция в типовой inference-стек. На практике узкое место часто не в самой модели, а в том, как сервер режет память под KV-cache и как он переживает пики.

Перед выбором сделай один честный тест: одинаковая модель, одинаковая квантизация, одинаковый prompt set, одинаковый лимит concurrency. Сравни не только tokens/sec, но и p95 latency, OOM-поведение и деградацию на длинном контексте.

Сначала меряй свой профиль нагрузки, потом выбирай сервер. Иначе ты оптимизируешь не инференс, а иллюзию throughput.