vLLM и TGI ломают прод не фичами, а режимом доступа к памяти и батчингу

vLLM и TGI ломают прод не фичами, а режимом доступа к памяти и батчингу

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

TGI чаще выбирают там, где важнее предсказуемость и простота обвязки. У него понятная схема деплоя, удобнее контролировать параметры сервинга и легче встроить в существующий стек. Но на плотной многопользовательской нагрузке он нередко отдаёт часть эффективности ради стабильного поведения.

Проверять надо не «скорость модели», а три вещи: токены/сек на запрос, p95 latency и сколько контекста реально держится без заметной деградации. На бумаге 128k контекста выглядит красиво, но в проде важнее, как сервер ведёт себя после роста очереди и при смешанных длинах промптов.

Если у тебя асинхронный продукт с неравномерным трафиком и дорогая VRAM, начинай с vLLM. Если нужен более прямолинейный сервинг с меньшей сложностью интеграции — смотри в сторону TGI. Один и тот же чек-лист для обоих: замер на своей модели, своей квантизации и своём профиле запросов.