Runpod показала, как GuideLLM помогает выжать максимум из vLLM

Runpod выпустила в блоге руководство по связке vLLM и GuideLLM. Идея простая: прежде чем отдавать модель пользователям, прогоните по ней имитацию реального трафика и посмотрите на три числа, время до первого токена, задержку между токенами и пропускную способность. Именно они определяют, сколько GPU вам понадобится и сколько вы заплатите за миллион токенов. Исходная публикация короткая, это скорее анонс практического гайда, поэтому конкретных бенчмарков на карточках в ней нет. Но сама методика заслуживает разбора.

Почему «быстро на моём ноутбуке» ничего не значит

vLLM давно стал одним из стандартных движков для инференса открытых моделей. Он использует непрерывный батчинг и PagedAttention для управления KV-кэшем, и на нескольких запросах работает отлично. Проблемы начинаются под нагрузкой. Когда одновременно приходят десятки запросов с разной длиной промптов, кэш заполняется, очередь растёт, а задержка первого токена может вырасти в разы.

Одиночный запрос этого не покажет. Нужен генератор нагрузки, который ведёт себя как пользователи: запросы приходят не по одному, а волнами, промпты и ответы разной длины. GuideLLM для этого и создан. Это открытый инструмент из экосистемы vLLM. Он обращается к OpenAI-совместимому эндпоинту, шлёт синтетические или заданные вами запросы и собирает статистику.

Как выглядит прогон

Схема на Runpod типовая. Вы поднимаете под или serverless-воркер с vLLM, получаете адрес эндпоинта и запускаете GuideLLM с него или с другой машины. Дальше задаёте профиль нагрузки: длину входа и выхода в токенах, режим подачи запросов и длительность. Обычно доступны фиксированная скорость, пуассоновский поток, режим максимальной пропускной способности и последовательное прогонение, при котором сервер не перегружается. Для первой разведки удобен sweep: он проходит по нарастающей нагрузке и показывает, где кривая задержки ломается. Точные названия флагов меняются от версии к версии, их лучше сверять с документацией.

На выходе вы получаете отчёт со следующими показателями:

• TTFT, время до первого токена: определяет, насколько отзывчиво выглядит чат;
• ITL, задержка между токенами: от неё зависит плавность стриминга;
• сквозная задержка запроса целиком, важна для API и агентных цепочек;
• запросы в секунду, которые сервер выдерживает до деградации;
• токены в секунду на карту, ключевая величина для расчёта стоимости;
• число одновременных запросов, при котором растут очереди.

Смысл в сопоставлении. Если TTFT укладывается в целевое значение при определённой нагрузке, а дальше уходит вверх, это ваш рабочий потолок на текущей конфигурации.

Практика: от метрик к счёту за GPU

Порядок действий такой.

1. Опишите свой реальный трафик: средняя и максимальная длина промпта, длина ответа, пиковая нагрузка. Если логов ещё нет, возьмите осторожные оценки и позже уточните. 2. Задайте целевые значения TTFT и ITL. Для чат-интерфейса и для пакетной обработки документов они будут разными. 3. Прогоните sweep на нескольких конфигурациях: разные GPU, разная квантизация, разные значения максимальной длины контекста и доли памяти под KV-кэш. 4. Для каждой конфигурации найдите максимальную нагрузку, при которой цели выполняются, и разделите почасовую цену карты на полученное число токенов. Это реальная цена токена. 5. Для serverless-развёртывания проверьте ещё холодный старт и поведение при резком росте очереди, статичный бенчмарк их не покажет.

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

Главная польза такого гайда в дисциплине. Выбор GPU и настроек по ощущениям обычно заканчивается переплатой за запас, которым никто не пользуется. Полчаса нагрузочного теста дают цифры, которые можно положить на стол финансисту.