В этом материале
Количество подключённых клиентов и количество одновременно выполняемых последовательностей нужно учитывать отдельно.
CUDA out of memory при нескольких запросах часто связано с совокупной памятью активных последовательностей. Каждому обращению нужны данные контекста, а движок объединяет работу в пакеты. Карта, успешно ответившая одному человеку, не становится автоматически сервером для произвольного числа клиентов. Сначала зафиксируйте одиночный профиль и отдельно увеличивайте параллельность.
Различайте клиентов, очередь и выполнение
Десять открытых соединений могут означать один исполняемый запрос и девять ожидающих. Или десять одновременно растущих контекстов. Для VRAM эти режимы различаются. Смотрите ограничения планировщика и метрики выполняемых последовательностей, а не только число HTTP-соединений.
Ограничение приёма запросов полезно согласовать с очередью приложения. Бесконечное ожидание убирает немедленный OOM, но не создаёт приемлемый сервис. Зафиксируйте предельное время ожидания и понятный ответ при перегрузке. Общий подход рассмотрен в планировании ёмкости.
Подготовьте одинаковую нагрузку
Практический сценарий: одна модель отвечает на документы по 2000 входных токенов с резервом 400 выходных. Проверьте один, два и четыре одновременных запроса, сохраняя остальные настройки. Числа задают эксперимент; они не подтверждают производительность какого-либо GPU.
Затем повторите тот же ряд с более длинным входом. Результат покажет, зависит ли граница главным образом от количества сессий или от их суммарного контекста. Не используйте один постоянно повторяющийся промпт как единственный тест: общий префикс способен сделать нагрузку слишком удобной для кеша.
Не путайте экономию пакета с бесплатной памятью
Объединение обращений повышает эффективность выполнения, но не отменяет хранение отдельных последовательностей. Длинные ответы продолжают занимать кеш после завершения обработки входа. Поэтому пакет коротких задач и несколько долгих диалогов с одинаковым числом клиентов могут расходовать память по-разному.
Документация vLLM по оптимизации описывает влияние планировщика, памяти кеша и вытеснения. Применяйте настройки из своей версии: подходящее значение зависит от модели и профиля обращений. Сам механизм описан в статье continuous batching.
Установите управляемую границу
Сначала уменьшите число активных запросов, сохранив полезный размер контекста. Если это решает проблему, сравните задержку очереди с требованиями приложения. Следующим отдельным опытом уменьшите допустимый контекст либо выход. Не меняйте сразу четыре параметра: тогда нельзя будет объяснить улучшение.
Учитывайте отменённые обращения и медленных клиентов. Проверьте, прекращается ли вычисление после разрыва соединения и возвращается ли память в рабочий пул. Резкое повышение нагрузки должно завершаться управляемой очередью или отказом, а не перезапуском всей модели и потерей остальных ответов.
В контрольном наборе оставьте независимые запросы с одинаковыми размерами, но разным содержанием. Это снижает влияние случайного повторного использования общих данных и делает вывод о рабочей границе понятнее.
Практические выводы
В отчёте достаточно таблицы с параллельностью, фактическими токенами, ошибками и задержкой. Метрики выбирайте по официальному описанию vLLM, сохраняя названия из установленной версии. Отдельно укажите, наблюдались ли повторные вычисления и рост времени до первого токена.
Для владельца GPU такая таблица объясняет рабочий режим карты. Финансовому партнёру она помогает сравнить дополнительную реплику с увеличением памяти одного сервера.