В этом материале
Reserved включает память распределителя, а не только живые тензоры; один показатель не объясняет весь расход GPU.
Allocated и reserved в сообщении CUDA OOM обозначают разные уровни учёта памяти процесса. Allocated связано с размещёнными тензорами, reserved — с памятью, удерживаемой распределителем, включая доступные для повторного использования блоки. Складывать их как независимые расходы нельзя. Большое reserved само по себе ещё не доказывает утечку или фрагментацию.
Сначала установите источник показателей
Ошибка фреймворка, nvidia-smi и мониторинг контейнера видят разные слои. Первый знает внутренние выделения, второй показывает состояние устройства и процессов, третий может агрегировать данные. Поэтому различие цифр ожидаемо и требует пояснения, а не автоматического обвинения драйвера.
Сохраните версию библиотеки и полный текст исключения. Проверьте, относится ли сообщение к той же карте и процессу, которые вы наблюдаете. На сервере с несколькими GPU порядковые номера внутри контейнера могут отличаться от нумерации хоста; UUID устройства помогает сопоставить измерения.
Отличите живые данные от кеша
Веса модели и используемый контекст остаются необходимыми, пока выполняется работа. Освобождение неиспользуемых блоков кеша распределителя не удаляет эти данные. Поэтому популярный совет очистить кеш не позволяет разместить модель, чья минимальная память уже превышает доступную.
Механизм поясняет документация управления CUDA-памятью PyTorch. В диагностическом скрипте полезно сравнить состояние после загрузки, после запроса и после освобождения собственных ссылок на результат. Но не следует внедрять экспериментальный сборщик мусора в рабочий сервер без понимания жизненного цикла объектов.
Проверьте воспроизводимый рост
Практический опыт: выполните последовательность из десяти одинаковых коротких запросов, затем такую же последовательность с чередованием коротких и длинных входов. Записывайте показатели после завершения каждого обращения. Рост до устойчивого плато отличается от непрерывного увеличения живых выделений.
Прогрев, создание вычислительных графов и кеширование могут менять первые измерения. Поэтому снимок сразу после запуска нельзя напрямую сравнивать с прогретой системой. Сохраняйте отдельные отметки фазы, а для анализа повторяйте один и тот же сценарий с чистого запуска процесса.
Проверяйте фрагментацию по данным
Фрагментация означает, что свободная память распределена неудобными для нужного выделения блоками. Разница reserved и allocated может подсказать направление, но не заменяет дополнительную диагностику. Используйте средства снимка памяти и настройки распределителя только по документации установленной версии PyTorch.
Для vLLM сначала изучите собственные сообщения о кешах, профилировании и вытеснении, описанные в официальной оптимизации. Движок управляет памятью специфическим образом. Универсальная переменная окружения из чужого обсуждения способна оказаться неуместной для вашего распределителя или выбранного backend.
Если повторяемого роста нет, не называйте ситуацию утечкой. Сохраните плато и условия прогрева как отдельный результат, после чего проверяйте следующий профиль нагрузки с тем же измерительным подходом.
Подготовьте полезный отчёт о машине
В отчёте укажите модель, формат, начальную свободную VRAM, фазу ошибки и минимальный повторяющий её запрос. Для связи с физической картой пригодится проверка процессов GPU, а для нагрузки — проверка параллельности.
Владельцу этот разбор помогает отличить ограничения оборудования от удерживаемых приложением данных. Финансирование дополнительной карты имеет смысл обсуждать после такой развилки.