vLLM и TGI ломаются не на модели, а на ваших паттернах запросов

vLLM и TGI ломаются не на модели, а на ваших паттернах запросов

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

Главный trade-off такой: vLLM лучше раскрывается на high-concurrency и длинных контекстах, но требует аккуратнее смотреть на память под KV cache и лимиты по max model len. TGI чаще проще в эксплуатации, но на некоторых профилях нагрузки может проигрывать в утилизации GPU, особенно когда очередь состоит из разнокалиберных запросов.

Для выбора смотрите не на «какой фреймворк быстрее», а на три метрики: median latency, p95 latency и effective throughput на вашем распределении длины промптов. Если у вас 80% запросов укладываются в короткий контекст, а 20% — тяжёлые, тестируйте именно этот микс, иначе бенчмарк будет врать. И отдельно проверяйте поток генерации при 1, 8, 32 и 64 одновременных сессиях.

Ещё один практический фильтр: если команда часто меняет модели и нужен быстрый rollout, удобнее сервер, где проще управлять batch size, tensor parallel и лимитами памяти без ручной сборки костылей. Если же приоритет — максимальная выжимка из одной конкретной модели, vLLM обычно становится первым кандидатом.