Перейти к содержанию
Новое AiManual теперь в MAX Подписаться
Публикация AiManual

LoRA и её скрытые требования к VRAM: разбираемся в потреблении памяти

Почему LoRA требует 40-50 ГБ VRAM для модели на 7B параметров? Разбираем реальное потребление памяти: веса базовой модели, градиенты, состояния AdamW и активаци

Коротко

Что будет в материале

  1. 01

    Почему LoRA не такая лёгкая, как обещают: главные потребители VRAM

  2. 02

    Реальные цифры: сколько VRAM нужно для популярных моделей

  3. 03

    Как снизить аппетиты LoRA: практические техники оптимизации

  4. 04

    LoRA vs Full Fine-Tuning: сравнение потребления VRAM

Главный потребитель видеопамяти при дообучении LoRA - это базовая модель, градиенты и оптимизатор, а не сами адаптеры. На модели с 7 млрд параметров в формате FP16 только веса занимают 14 ГБ. Добавьте сюда ещё 14 ГБ под градиенты и 28 ГБ под состояния оптимизатора AdamW - и получите 56 ГБ ещё до учёта активаций. Сами LoRA-адаптеры с рангом 8-64 добавляют меньше 1 ГБ. Это объясняет, почему запуск дообучения на видеокарте с 24 ГБ VRAM без специальных оптимизаций почти всегда заканчивается ошибкой Out Of Memory.

Практический ориентир: для модели LLaMA-7B с длиной последовательности 2048 токенов и размером батча 1 реальное потребление составляет 66-76 ГБ VRAM. С включённым gradient checkpointing цифра снижается до 40-50 ГБ. Разберём, из чего складываются эти гигабайты и как вписаться в доступный бюджет памяти.

Почему LoRA не такая лёгкая, как обещают: главные потребители VRAM

Метод Low-Rank Adaptation позиционируется как экономичный способ дообучения больших моделей. Он замораживает исходные веса и добавляет обучаемые низкоранговые матрицы. Память, занимаемая этими матрицами, действительно ничтожна. Однако процесс обучения требует разместить в VRAM всю базовую модель и служебные структуры для обратного распространения ошибки. Именно они создают основную нагрузку.

Базовая модель: фундамент, который никуда не деть

Замороженные веса всё равно должны находиться в видеопамяти. При прямом проходе каждый токен умножается на полную матрицу параметров, поэтому модель загружается целиком. Для 7B-модели в формате FP16 это 14 ГБ. Переход на FP32 удваивает цифру до 28 ГБ. На практике FP32 для весов используют редко - смешанная точность стала стандартом, но саму возможность нужно держать в голове при расчёте бюджета.

Некоторые фреймворки, например Hugging Face PEFT, добавляют небольшие накладные расходы на обёртки и метаданные, но они редко превышают 1-2% от размера модели.

Градиенты и оптимизатор: двойной удар по памяти

Обратное распространение вычисляет градиенты для всех обучаемых параметров. В классическом LoRA обучаются только адаптеры - это сотые доли процента от общего числа весов. Но оптимизатор AdamW, ставший стандартом де-факто, хранит для каждого из них два дополнительных состояния: экспоненциальное скользящее среднее градиента (m) и квадрата градиента (v). Оба состояния хранятся в FP32, даже если сама модель в FP16. Для 7B-модели с адаптерами ранга 16 это около 28 ГБ.

Сравнение с SGD показательно: стохастический градиентный спуск не хранит историю, ему нужны только градиенты - те же 14 ГБ. Экономия вдвое, но плата за неё - худшая сходимость на задачах с разреженными сигналами. AdamW остаётся разумным компромиссом, когда важен финальный результат.

Активации: скрытый резервуар, зависящий от длины контекста

При прямом проходе каждый слой модели порождает тензоры активаций. Для обратного распространения их нужно либо сохранить, либо пересчитать. Объём активаций линейно зависит от размера батча и длины последовательности. На модели 7B с батчем 1 и контекстом 2048 токенов активации занимают 10-20 ГБ в зависимости от архитектуры - наличия grouped-query attention, размера скрытого состояния и числа слоёв.

Без gradient checkpointing активации хранятся для всех слоёв одновременно. Это главный кандидат на оптимизацию, когда памяти не хватает.

Реальные цифры: сколько VRAM нужно для популярных моделей

Приводим цифры для конфигурации с FP16, AdamW и длиной последовательности 2048 токенов. Это базовая точка отсчёта, от которой можно отталкиваться при планировании.

МодельБез checkpointingС gradient checkpointing
LLaMA-7B, batch=166-76 ГБ40-50 ГБ
LLaMA-13B, batch=1120-140 ГБ80-100 ГБ
Mistral-7B, batch=160-70 ГБ38-48 ГБ

Mistral-7B использует Grouped-Query Attention и скользящее окно, что немного снижает потребление активаций по сравнению с LLaMA аналогичного размера. Для 13B-моделей без двух видеокарт уровня RTX 3090 или RTX 4090 заходить в дообучение практически бессмысленно. Если вы только выбираете оборудование, оцените наш разбор RTX 5090 против профессиональных карт для инференса и файнтюнинга.

Как снизить аппетиты LoRA: практические техники оптимизации

Сократить потребление VRAM на 30-50% реально без замены видеокарты. Комбинация трёх-четырёх техник позволяет вписать дообучение 7B-модели в бюджет 24 ГБ - уровень одной RTX 3090 или 4090.

Gradient checkpointing: компромисс между памятью и скоростью

Механизм прост: вместо хранения активаций всех слоёв сохраняются только активации контрольных точек, а промежуточные пересчитываются при обратном проходе. Потребление памяти активаций падает с O(n) до O(sqrt(n)), где n - число слоёв. Для 7B-модели экономия составляет 10-20 ГБ. Плата - рост времени обучения на 20-30% из-за повторных вычислений.

В Hugging Face Transformers gradient checkpointing включается флагом --gradient_checkpointing. В PyTorch - вызовом model.gradient_checkpointing_enable(). Это первая техника, которую стоит применить при нехватке памяти.

Смешанная точность и выбор формата весов

Стандартный подход: веса и градиенты в FP16, состояния оптимизатора в FP32. BF16 предпочтительнее FP16 при обучении - он сохраняет диапазон FP32 для экспоненты, что снижает риск потери значимости градиентов на длинных последовательностях. Полный FP32 удваивает потребление всех компонентов и не даёт соразмерного прироста качества.

Квантизация базовой модели - отдельное направление. 8-битная загрузка весов (bitsandbytes) сокращает их объём до ~7 ГБ для 7B-модели. QLoRA объединяет 4-битную квантизацию с LoRA и позволяет дообучать 13B-модель на 24 ГБ VRAM. Это уже не классическая LoRA, но прямой наследник с теми же принципами.

Тюнинг гиперпараметров: batch size, rank и sequence length

Уменьшение размера батча линейно снижает память активаций. Батч размером 1 даёт минимальное потребление. Эффективный размер батча сохраняют через накопление градиентов: 4 шага с батчем 1 эквивалентны одному шагу с батчем 4 по вкладу в обновление весов, но требуют вчетверо меньше памяти активаций в каждый момент времени.

Ранг LoRA влияет на число обучаемых параметров адаптеров. Переход с r=64 на r=8 экономит десятки мегабайт - пренебрежимо мало на фоне остальных потребителей. Выбирайте ранг по качеству дообучения, а не по бюджету памяти. Для большинства задач r=8-16 даёт результаты, неотличимые от более высоких рангов.

Длина последовательности - рычаг с наибольшим эффектом после gradient checkpointing. Сокращение контекста с 2048 до 1024 токенов уменьшает память активаций почти вдвое. Если задача позволяет обрабатывать более короткие примеры, это даёт быструю и существенную экономию.

LoRA vs Full Fine-Tuning: сравнение потребления VRAM

Полное дообучение 7B-модели требует хранить градиенты и состояния оптимизатора для всех 7 млрд параметров. Это 14 ГБ градиентов и 28 ГБ AdamW - итого 56 ГБ только на оптимизатор и градиенты, плюс 14 ГБ весов и 10-20 ГБ активаций. Суммарно 80-90 ГБ с checkpointing и 120-160 ГБ без него.

LoRA сокращает обучаемые параметры до адаптеров, поэтому градиенты и состояния оптимизатора занимают меньше 1 ГБ. Базовая модель остаётся в памяти, но её градиенты не вычисляются и не хранятся. Выигрыш - 40-50 ГБ для 7B-модели. Это разница между «нужен кластер» и «запускается на одной карте». Подробный пример воспроизводимого пайплайна LoRA-дообучения с кодом и метриками разобран в пошаговом руководстве по дообучению OpenVLA.

Чек-лист: как оценить VRAM перед запуском LoRA

Упрощённая формула для быстрой прикидки:

VRAM ≈ веса_модели + градиенты_адаптеров + состояния_оптимизатора_адаптеров + активации

Для 7B-модели в FP16 с AdamW и рангом 16:

  • Веса: 14 ГБ
  • Градиенты адаптеров: ~0.1 ГБ
  • Состояния AdamW: ~0.2 ГБ
  • Активации: 10-20 ГБ (без checkpointing), 2-5 ГБ (с checkpointing)

Итог: 24-34 ГБ с checkpointing, 40-50 ГБ без. Это базовый диапазон для планирования.

Перед запуском проверьте три пункта:

  1. Загружается ли базовая модель в выбранном формате (FP16/BF16/8-bit) на вашу карту при инференсе. Если нет - дообучение не запустится.
  2. Включён ли gradient checkpointing. Без него бюджет активаций взлетает кратно.
  3. Какой реальный объём VRAM доступен после загрузки драйверов и окружения. Обычно это на 1-2 ГБ меньше номинала.

Hugging Face предоставляет калькулятор использования памяти, который учитывает архитектуру модели и параметры обучения. Он даёт оценку с точностью до гигабайта и помогает избежать сюрпризов при запуске.

Если памяти всё равно не хватает, присмотритесь к QLoRA - 4-битная квантизация базовой модели снижает её объём до 3.5-4 ГБ для 7B, что позволяет дообучать на картах с 12-16 ГБ VRAM. Для тех, кто работает на нескольких GPU, гибридные сборки вроде Nvidia + AMD для расширения VRAM разобраны в материале про гибридную сборку для LLM.

Подписаться на канал