В этом материале
Сначала определите фазу сбоя: загрузка весов, преобразование формата и прогрев требуют разного запаса памяти.
CUDA out of memory при загрузке модели означает, что процесс не смог выделить очередной блок видеопамяти. Причина может быть в размере весов, временном преобразовании, уже работающем приложении или прогреве движка. Уменьшение длины пользовательского запроса помогает только тогда, когда ошибка связана с соответствующими буферами. Начинать лучше с последней успешно завершённой стадии журнала.
Отличите загрузку весов от первого запроса
Сохраните сообщение целиком вместе с несколькими десятками предшествующих строк. Отметьте, были ли скачаны файлы, создана модель, распределены веса по устройствам и запущено профилирование. Одинаковая надпись OOM после разных этапов требует разных действий. Если сервер ещё не принимает обращения, пользовательский промпт причиной быть не может.
Составьте короткую хронологию: запуск процесса, начало чтения checkpoint, окончание загрузки, резервирование кеша, готовность API. Время между событиями помогает отделить медленный диск от нехватки VRAM. О проверке доступности отдельно рассказано в материале о готовности vLLM.
Посчитайте нижнюю границу весов
Для условной плотной модели с восемью миллиардами параметров два байта на параметр дают около шестнадцати миллиардов байт. Это ещё не общий расход сервера. Масштабы квантования, часть весов другой точности, активации и кеш добавляются сверху. Размер скачанного архива также не обязан совпадать с размещением на GPU.
Если такая модель запускается на карте с небольшой памятью, сначала выберите поддерживаемый квантованный checkpoint либо меньшую модель. Произвольное указание слова «int4» не превращает любой файл в подходящий формат. Принцип расчёта разобран в оценке памяти 8B.
Проверьте чужие процессы и устройства
В качестве диагностического примера выполните nvidia-smi до старта и в момент ошибки. Сравните UUID устройств, используемую память и список процессов. Карта, выбранная оболочкой, может отличаться от ожидаемой; графическая сессия тоже занимает ресурсы. На общей машине сначала согласуйте остановку чужой работы.
После корректного завершения своего старого процесса повторите тот же запуск. Не меняйте одновременно формат, контекст и версию драйвера: иначе успешный результат не покажет, какое изменение помогло. Снимки состояния сохраняйте рядом с командой запуска, убрав секреты и приватные пути.
Проверьте временный пик и программную сборку
Модель иногда помещается после загрузки, но преобразование или построение вычислительных графов создаёт более высокий кратковременный расход. Сопоставьте этап с инструкцией конкретного движка. Для vLLM ориентируйтесь на оптимизацию памяти и поддержку используемого оборудования.
Сообщения allocated и reserved описывают разные части распределителя, а не две независимые видеокарты. Их смысл объясняет документация CUDA в PyTorch. Освобождение кеша не выгружает живые веса и не исправляет фундаментально недостаточную ёмкость.
Как зафиксировать результат диагностики
Практический результат проверки — два воспроизводимых запуска: исходный сбой и рабочая конфигурация с понятным ограничением. Запишите точный checkpoint, GPU, формат, версию движка и свободную память перед стартом. Затем проверьте короткий запрос и следующий рабочий сценарий: прохождение загрузки само по себе ещё не подтверждает пригодность сервера.
Владельцу это позволяет предложить карту под подходящий класс моделей. Финансовому партнёру — отличить необходимость дополнительной VRAM от ошибки настройки.