# CUDA out of memory при загрузке модели: порядок проверки

Разбираем CUDA OOM при загрузке LLM: веса, временные буферы, занятая VRAM и совместимость формата. Порядок диагностики до покупки GPU.

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

CUDA out of memory при загрузке модели означает, что процесс не смог выделить очередной блок видеопамяти. Причина может быть в размере весов, временном преобразовании, уже работающем приложении или прогреве движка. Уменьшение длины пользовательского запроса помогает только тогда, когда ошибка связана с соответствующими буферами. Начинать лучше с последней успешно завершённой стадии журнала.

## Отличите загрузку весов от первого запроса

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

Составьте короткую хронологию: запуск процесса, начало чтения checkpoint, окончание загрузки, резервирование кеша, готовность API. Время между событиями помогает отделить медленный диск от нехватки VRAM. О проверке доступности отдельно рассказано в [материале о готовности vLLM](/ru/journal/vllm-health-ready/).

## Посчитайте нижнюю границу весов

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

Если такая модель запускается на карте с небольшой памятью, сначала выберите поддерживаемый квантованный checkpoint либо меньшую модель. Произвольное указание слова «int4» не превращает любой файл в подходящий формат. Принцип расчёта разобран в [оценке памяти 8B](/ru/journal/llm-8b-weight-memory/).

## Проверьте чужие процессы и устройства

В качестве диагностического примера выполните `nvidia-smi` до старта и в момент ошибки. Сравните UUID устройств, используемую память и список процессов. Карта, выбранная оболочкой, может отличаться от ожидаемой; графическая сессия тоже занимает ресурсы. На общей машине сначала согласуйте остановку чужой работы.

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

## Проверьте временный пик и программную сборку

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

Сообщения allocated и reserved описывают разные части распределителя, а не две независимые видеокарты. Их смысл объясняет [документация CUDA в PyTorch](https://docs.pytorch.org/docs/2.15/notes/cuda.html). Освобождение кеша не выгружает живые веса и не исправляет фундаментально недостаточную ёмкость.

## Как зафиксировать результат диагностики

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

Владельцу это позволяет предложить карту под подходящий класс моделей. Финансовому партнёру — отличить необходимость дополнительной VRAM от ошибки настройки.