В этом материале
Возможность обслуживать поток важнее рекорда одного запроса. Проверяйте пакетирование постепенно, оценивая успешную работу всей группы и комфорт отдельного пользователя.
Свободный GPU может быстро отвечать одному пользователю, но значительную часть времени оставаться недозагруженным. При другом режиме та же машина получает много обращений и создаёт длинную очередь. Между этими крайностями находится задача планирования совместной работы, ради которой оператору нужны не только карты, но и подходящее программное окружение.
Что означает непрерывное пакетирование
Continuous batching — организация совместного выполнения поступающих запросов с изменением состава активной группы по мере их обработки. vLLM перечисляет эту возможность среди механизмов обслуживания моделей. Это полезная техническая отправная точка, но она не устанавливает оптимальный размер нагрузки для конкретного сервера.
Владелец может представить происходящее как работу кассы с несколькими незавершёнными заказами: важно продвигать общий поток, не заставляя короткий заказ бесконечно ждать длинные. Сравнение объясняет задачу планировщика, а не внутренний алгоритм движка.
Почему высокий процент загрузки недостаточен
Предположим, в условном эксперименте увеличение параллелизма повышает занятость GPU. При этом часть ответов начинает запаздывать или завершаться ошибкой. Формально карта работает интенсивнее, но полезный результат может не улучшиться.
Поэтому добавляйте в отчёт число успешных запросов, длительность ожидания и распределение задержек. Считать нужно завершённую работу в выбранных границах качества. Максимальная загрузка устройства сама по себе не является целью коммерческого сервиса.
Для владельца это важное отличие от предложения просто «держать GPU занятым». Обсуждать стоит конкретную нагрузку, которая даёт воспроизводимый пригодный результат.
Постройте лестницу параллелизма
Начните с небольшого количества одновременных обращений. На каждой ступени используйте одинаковый набор входов и лимиты ответа. Увеличивайте нагрузку только после сохранения предыдущего результата.
В таблицу пилота включите:
- количество активных запросов и интенсивность новых поступлений;
- время первого токена и полного ответа;
- долю успешных завершений;
- использованную память и появление очереди;
- потребление всей машины в сопоставимом интервале.
Отдельно пометьте холодный запуск и прогретое состояние. Нельзя смешивать их в одно среднее, а затем объяснять различия только числом запросов.
Найдите рабочую границу
Граница определяется не моментом аварии, а раньше: когда следующий шаг нагрузки ухудшает согласованный пользовательский результат. Например, короткий чат может перестать укладываться в допустимое ожидание, хотя ошибки памяти ещё не появляются.
Сравните одинаковые ограничения на разных машинах. Если одна конфигурация стабильно выдерживает меньший поток, это не делает её бесполезной: ей можно искать другую роль. Решение зависит от полного набора затрат и целей сервиса.
Сохраните настройки и повторите выбранную ступень длительным тестом. Кратковременный удачный запуск не проверяет температуру, восстановление и эксплуатационную доступность.
Практические выводы
Предлагаемый подход к пулу — подбирать нагрузку после измерений и согласовывать ограничения с владельцем. Мы не утверждаем, что для каждого GPU уже существует оплачиваемый поток.
Для подготовки разговора прочитайте о различии prefill и decode, экономике инференса и техническом пилоте.