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

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

Если у тебя короткие запросы, много параллельных сессий и нужен высокий throughput, vLLM обычно выигрывает за счёт continuous batching и paged attention. Он лучше переваривает «рваный» поток запросов и меньше страдает от фрагментации памяти.

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

Смотри не только на tokens/sec, а на три вещи:
— p95 latency по first token
— стабильность throughput при росте concurrency
— реальный max context без деградации качества и OOM

Если модель 7B/8B и у тебя одна GPU с ограниченной VRAM, чаще побеждает хорошая квантизация + vLLM. Если инфраструктура уже завязана на HF stack, а команда ценит простоту деплоя и контроль пайплайна, TGI может быть дешевле в сопровождении. Для длинного контекста 128k всегда тестируй отдельно: в синтетике он живёт красиво, в проде «дальняя память» часто проседает раньше.

Выбирай не «лучший сервер», а сервер под свою форму трафика: короткие ответы, длинные промпты, пики concurrency и бюджет на RAM/GPU.