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

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

Если у тебя один и тот же LLM то отвечает быстро, то внезапно «залипает», проблема часто не в весах, а в сервере инференса. vLLM и TGI решают разные задачи: vLLM обычно сильнее там, где важны высокий throughput и агрессивный batching, TGI удобнее, когда нужен предсказуемый serving и аккуратная эксплуатация.

Смотри не на «лучший фреймворк», а на три числа:
— средняя длина промпта;
— доля длинных генераций;
— пиковая конкуррентность.
Если промпты короткие, а запросов много, выигрывает система с хорошим continuous batching и управлением KV-cache. Если запросы длинные и их мало, разница часто съедается overhead’ом, и важнее стабильность, чем рекордный tokens/sec.

Типовая ошибка — мерить только decode speed. Для продакшена важнее p95 latency на первом токене, поведение на 2–4k входа и то, как сервер деградирует при росте очереди. Хороший тест — прогнать одинаковый набор запросов с разной длиной контекста и посмотреть, не начинает ли модель «сыпаться» после насыщения VRAM.

Ещё один фильтр: если тебе нужен строгий контроль памяти, простой деплой и отладка на CPU/GPU без сложной обвязки, иногда llama.cpp или более лёгкий стек даст меньше сюрпризов. Если же цель — обслуживать много параллельных диалогов на одной карте, vLLM обычно становится базовой точкой сравнения.

Выбирай не «самый быстрый сервер», а тот, который лучше совпадает с твоим профилем трафика: короткие запросы и высокий параллелизм — в одну сторону, длинный контекст и стабильность — в другую.