LoRA на своём сервере: обучаем стиль под себя

MAATRIX

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

Что решает LoRA и чем она отличается от полного дообучения

Базовая диффузионная модель — это десятки слоёв со множеством параметров, обученных на огромном разнородном датасете. Чтобы «научить» её новому узкому навыку — например, рисовать конкретного персонажа в одной и той же манере — можно пойти двумя путями.

Первый — дообучить (fine-tune) саму модель целиком: пересчитать веса всех слоёв под новые данные. Это работает, но по ресурсам сравнимо с обучением модели заново: нужны серьёзные объёмы видеопамяти, время и десятки гигабайт под каждую новую версию модели на диске. Для одной задачи «нарисуй мне этого персонажа» это явно избыточно.

Второй путь — LoRA (Low-Rank Adaptation). Вместо изменения всех параметров базовой модели вы замораживаете её целиком и обучаете только небольшой дополнительный набор весов — низкоранговые матрицы, которые встраиваются в ключевые слои сети (обычно в блоки внимания). При генерации эти матрицы «накладываются» поверх неизменной базовой модели и слегка сдвигают её поведение в нужную сторону — в сторону вашего стиля, персонажа или объекта.

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

Важное следствие: базовая модель остаётся нетронутой. Вы можете держать одну и ту же базовую модель на диске и подключать к ней разные LoRA под разные задачи — не храня десяток полных копий модели ради десятка стилей.

Как LoRA встраивается в архитектуру модели

Технически LoRA не трогает исходные веса слоя напрямую. Для выбранных слоёв (чаще всего это слои внимания в U-Net или в трансформерных блоках современных архитектур) добавляется параллельная ветка из двух небольших матриц низкого ранга. Их произведение даёт поправку той же размерности, что и исходный вес слоя, но само количество обучаемых чисел в этой поправке многократно меньше, чем в самом слое — за счёт того, что внутренняя размерность («ранг») этой ветки выбирается маленькой.

При инференсе поправка складывается с замороженным весом слоя с определённым коэффициентом — это и есть та самая «сила» (strength/weight) LoRA, которую вы задаёте при генерации. При нуле адаптер не влияет вообще, при единице влияет с той силой, с которой обучался, выше единицы — эффект усиливается (иногда ценой артефактов).

Из этого прямо следует, почему LoRA так экономна по памяти на этапе обучения: обратное распространение ошибки считает градиенты только по добавленным матрицам, а не по всей сети. Сама базовая модель участвует в прямом проходе (нужна, чтобы понять, куда двигать веса адаптера), но её параметры не обновляются и не требуют хранения оптимизаторных состояний — а именно они на практике съедают львиную долю видеопамяти при полном дообучении.

Собираем датасет: качество и однородность важнее количества

Для LoRA не нужен датасет масштаба базовой модели — счёт идёт не на миллионы изображений, а на заметно более скромный набор примеров. Конкретное число, которое стоит закладывать, зависит от того, что именно вы обучаете (персонаж, стиль, объект), от используемой архитектуры модели и от инструмента обучения — рекомендации по объёму датасета у разных инструментов разные и меняются по мере их развития. Проверяйте актуальные рекомендации в документации конкретного инструмента, который используете (kohya_ss, sd-scripts, diffusers-скрипты), прежде чем закупать или размечать материал — не ориентируйтесь на цифры из старых статей.

Что важнее конкретного числа — это качество и однородность подборки:

• Последовательность стиля. Если вы обучаете художественный стиль, все примеры должны быть выполнены в одной узнаваемой манере. Разнородная подборка (то реализм, то мультяшность, то разное освещение) заставит модель «усреднять» и размывать результат — LoRA получится нечётким, генерации будут непредсказуемыми.
• Разнообразие ракурсов и контекста при обучении персонажа. Здесь наоборот: если все фото персонажа — в одной позе на одном фоне, модель выучит не персонажа, а именно эту позу и этот фон, и будет вставлять их в любую генерацию. Нужны разные ракурсы, освещение, окружение — но при этом стабильные узнаваемые черты (лицо, костюм, характерные детали).
• Чистота изображений. Уберите артефакты, водяные знаки, чужие лишние объекты в кадре, которые не относятся к обучаемому объекту — модель выучит и их тоже.
• Разрешение и кадрирование. Изображения обычно приводят к разрешению, с которым работает базовая модель, кадрируют по объекту обучения и по возможности убирают лишний фон, если обучаете конкретный объект, а не сцену целиком.
• Подписи (captions). Для большинства инструментов обучения к каждому изображению нужна текстовая подпись, описывающая, что на нём изображено. От того, насколько точно и последовательно вы формулируете подписи, напрямую зависит, что именно выучит модель — это отдельная и не менее важная часть подготовки, чем сами картинки.

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

Требования к железу: меньше, чем полное обучение, но не «на глаз»

Обучение LoRA заметно дешевле по ресурсам, чем полное дообучение модели, — но это не значит, что подойдёт любая видеокарта. Ключевой момент, который часто упускают: требования к GPU для обучения и для одной лишь генерации (инференса) на той же базовой модели — это разные требования. Обучение, даже в компактном варианте LoRA, дополнительно держит в видеопамяти:

• саму базовую модель (в прямом проходе она нужна целиком, даже если её веса не обновляются);
• активации промежуточных слоёв, нужные для обратного распространения;
• градиенты и состояния оптимизатора — но только для обучаемых LoRA-матриц, а не для всей модели, в этом и главная экономия по сравнению с полным дообучением.

Поэтому видеокарты, которых достаточно для комфортной генерации, не всегда достаточно для обучения на ней же — запас видеопамяти для обучения нужен больше. Конкретный объём VRAM, который потребуется, зависит от нескольких переменных сразу: архитектуры и размера базовой модели (SD 1.5, SDXL и более новые модели требуют принципиально разного объёма), разрешения, на котором вы обучаете, размера батча, выбранного ранга LoRA и того, какие оптимизации памяти включает конкретный инструмент обучения (смешанная точность, градиентный чекпоинтинг, восьмибитные оптимизаторы и подобное — они снижают требования, но за счёт скорости или части качества).

Практический совет: не подбирайте железо «на глаз» по старым цифрам из чужих статей. Инструменты обучения (kohya_ss, sd-scripts, diffusers) активно развиваются, а актуальные минимальные и рекомендуемые объёмы VRAM для конкретной базовой модели и конкретного режима обучения указаны в документации самого инструмента — там же обычно расписано, какие флаги включить, если видеопамяти не хватает впритык. Перед арендой сервера под конкретную задачу стоит свериться именно с этими актуальными рекомендациями, а не с усреднёнными цифрами.

Если самостоятельно держать сервер с постоянно занятой мощной видеокартой ради нечастых тренировок невыгодно, вариант — арендовать GPU по часам под саму тренировку, а для постоянного применения готовых LoRA (инференса) держать более скромный сервер — требования к видеопамяти для одной лишь генерации заметно ниже, чем для обучения, и там счёт идёт по другой методике.

Готовим сервер и инструмент обучения

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

1. Базовая система. Свежий Ubuntu LTS, установленные проприетарные драйверы NVIDIA и CUDA/cuDNN нужной для вашего инструмента обучения версии. Проверка после установки:

nvidia-smi
nvcc --version

1. Изолированное окружение. Отдельное виртуальное окружение под инструмент обучения, чтобы не конфликтовать с другими ИИ-сервисами на сервере:

python3 -m venv ~/lora-train
source ~/lora-train/bin/activate
pip install --upgrade pip

1. Сам инструмент обучения. Например, kohya_ss (одна из самых распространённых обёрток для обучения LoRA под Stable Diffusion и его производные):

git clone https://github.com/bmaltais/kohya_ss.git
cd kohya_ss
./setup.sh

Следуйте мастеру установки — он сам подтянет нужные версии PyTorch под вашу видеокарту и CUDA. На разных версиях инструмента шаги установки могут отличаться — актуальный порядок всегда смотрите в README самого репозитория на момент запуска.

1. Структура датасета. Большинство инструментов ждёт папку с изображениями и текстовыми файлами подписей рядом с каждым изображением (одно и то же имя, разное расширение):

dataset/
  10_mystyle/
    img001.png
    img001.txt
    img002.png
    img002.txt
    ...

Число в начале имени папки (в примере — 10) в kohya_ss задаёт число повторов эпохи на это подмножество данных — механизм, специфичный для конкретного инструмента, читайте, как он работает, именно в его документации, прежде чем полагаться на цифры из чужих конфигов.

1. Конфигурация обучения. Ключевые параметры, которые вы задаёте перед запуском: путь к базовой модели, путь к датасету, ранг LoRA (обычно чем выше — тем точнее адаптер учит детали, но тем больше его размер на диске и риск переобучения на конкретных примерах датасета вместо обобщения стиля), число эпох, скорость обучения. Конкретные стартовые значения этих параметров у каждого инструмента свои и приведены в его официальных примерах — начинайте с них, а не с параметров из случайных туториалов, и корректируйте по результату, а не заранее.

1. Запуск. В kohya_ss обучение обычно запускается через accelerate launch с указанием конфигурационного файла или через GUI-обёртку инструмента, если она развёрнута на сервере. Логи обучения (loss, промежуточные семплы генерации) стоит проверять по ходу — большинство инструментов позволяют сохранять промежуточные чекпоинты LoRA каждые несколько эпох, чтобы сравнить разные стадии обучения между собой, а не только смотреть на итог.

Проверяем и подключаем обученный LoRA

Обучение завершилось файлом LoRA (обычно .safetensors, размером в разы, а то и на порядки меньше базовой модели). Дальше — проверка и применение.

Разверните на сервере интерфейс генерации, который умеет подключать LoRA поверх базовой модели, — например, ComfyUI или другой веб-интерфейс на выбор. Файл адаптера кладётся в отведённую для LoRA папку модели (например, models/loras/ в ComfyUI), после чего становится доступен для подключения в узле/поле LoRA прямо в интерфейсе — без перезапуска базовой модели.

Ключевой параметр применения — сила (strength/weight), с которой LoRA накладывается на базовую модель при генерации. Практический совет: не полагайтесь на одно значение по умолчанию, а прогоните серию генераций с разной силой на одном и том же промпте и сиде. На низких значениях сила стиля/персонажа слабая, но общее разнообразие и стабильность базовой модели выше; на высоких — стиль воспроизводится точнее, но растёт риск артефактов, «перетягивания» цветов или потери гибкости композиции. Оптимум для конкретного вашего адаптера и конкретной задачи вы найдёте только экспериментально — он отличается от датасета к датасету.

Отдельный практический момент: несколько LoRA можно подключать одновременно (например, один адаптер под стиль, другой под конкретного персонажа), у каждого своя сила влияния, и они комбинируются. Здесь стоит быть аккуратным — сильное наложение сразу нескольких адаптеров чаще приводит к взаимной интерференции и артефактам, чем к «сумме» эффектов; начинайте с умеренных значений силы для каждого и добавляйте постепенно.

Частые вопросы