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

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

Если у вас короткие запросы, много параллельных пользователей и важен высокий throughput, vLLM чаще выигрывает за счёт paged attention и агрессивного batching. Если важнее предсказуемость, строгий контроль очереди и привычная эксплуатация в Kubernetes, TGI обычно проще в поддержке.

Смотрите не на «лучший фреймворк», а на три вещи:
— длина промпта и ответа;
— доля длинных контекстов;
— нужен ли streaming без скачков latency.
Для коротких чатов разница часто видна в токенах/сек, для длинного контекста — в том, как быстро растёт задержка после заполнения KV-cache.

Практическое правило: если модель 7B-14B и у вас плотный трафик, сначала прогоняйте vLLM с batch-size и max-num-batched-tokens под свою очередь. Если модель крупнее, а GPU упирается в память, сравнивайте не только throughput, но и стабильность p95 latency на одинаковом числе одновременных сессий.

Не забывайте про квантизацию: AWQ/GPTQ/FP16 могут дать одинаковое качество на ваших задачах, но разный ceiling по скорости и памяти. Самый частый баг в проде — мерить один запрос и считать, что сервер «летает».

Вывод простой: сначала рисуйте профиль нагрузки, потом выбирайте стек. Для высокой плотности запросов чаще берут vLLM, для более прямолинейной эксплуатации — TGI; без теста на своих промптах это всегда гадание.