# CUDA out of memory при нескольких запросах: память параллельности

CUDA OOM появляется только под несколькими запросами? Проверяем число активных последовательностей, общий контекст, очередь и пиковую память GPU.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/cuda-oom-concurrent-requests/
Language: ru

CUDA out of memory при нескольких запросах часто связано с совокупной памятью активных последовательностей. Каждому обращению нужны данные контекста, а движок объединяет работу в пакеты. Карта, успешно ответившая одному человеку, не становится автоматически сервером для произвольного числа клиентов. Сначала зафиксируйте одиночный профиль и отдельно увеличивайте параллельность.

## Различайте клиентов, очередь и выполнение

Десять открытых соединений могут означать один исполняемый запрос и девять ожидающих. Или десять одновременно растущих контекстов. Для VRAM эти режимы различаются. Смотрите ограничения планировщика и метрики выполняемых последовательностей, а не только число HTTP-соединений.

Ограничение приёма запросов полезно согласовать с очередью приложения. Бесконечное ожидание убирает немедленный OOM, но не создаёт приемлемый сервис. Зафиксируйте предельное время ожидания и понятный ответ при перегрузке. Общий подход рассмотрен в [планировании ёмкости](/ru/journal/inference-capacity-planning/).

## Подготовьте одинаковую нагрузку

Практический сценарий: одна модель отвечает на документы по 2000 входных токенов с резервом 400 выходных. Проверьте один, два и четыре одновременных запроса, сохраняя остальные настройки. Числа задают эксперимент; они не подтверждают производительность какого-либо GPU.

Затем повторите тот же ряд с более длинным входом. Результат покажет, зависит ли граница главным образом от количества сессий или от их суммарного контекста. Не используйте один постоянно повторяющийся промпт как единственный тест: общий префикс способен сделать нагрузку слишком удобной для кеша.

## Не путайте экономию пакета с бесплатной памятью

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

[Документация vLLM по оптимизации](https://docs.vllm.ai/en/stable/configuration/optimization/) описывает влияние планировщика, памяти кеша и вытеснения. Применяйте настройки из своей версии: подходящее значение зависит от модели и профиля обращений. Сам механизм описан в статье [continuous batching](/ru/journal/continuous-batching/).

## Установите управляемую границу

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

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

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

## Практические выводы

В отчёте достаточно таблицы с параллельностью, фактическими токенами, ошибками и задержкой. Метрики выбирайте по [официальному описанию vLLM](https://docs.vllm.ai/en/stable/usage/metrics/), сохраняя названия из установленной версии. Отдельно укажите, наблюдались ли повторные вычисления и рост времени до первого токена.

Для владельца GPU такая таблица объясняет рабочий режим карты. Финансовому партнёру она помогает сравнить дополнительную реплику с увеличением памяти одного сервера.