LoRA vs Full fine-tuning: что выбрать

Краткий вывод по запросу «LoRA vs full fine-tuning»: универсального ответа нет, но для большинства первых пилотов с open-weight моделями разумнее начинать с LoRA, а не с полного дообучения всех весов.

• ✅ Выбирайте LoRA, если вам нужно уменьшить число обучаемых параметров, снизить training footprint, хранить небольшие task-specific артефакты и быстро проверить гипотезу на своей задаче.
• ✅ Выбирайте full fine-tuning, если на вашей задаче критичен максимум качества, вы готовы обновлять 100% параметров и принимать более тяжёлый training/deployment workflow.
• ⚠️ Проверяйте оба варианта, если задача чувствительна к качеству: свежие исследования прямо говорят, что LoRA и full fine-tuning не эквивалентны, а разрыв зависит от задачи, модели, размера данных и recipe.
• ❌ Оба не подходят, если у вас нет доступа к весам модели: тогда нужны другие варианты адаптации, а не LoRA или full fine-tuning.

Дата последней повторной проверки источников: 2026-08-15.

Условия сравнения	LoRA	Full fine-tuning
Фиксация версии / реализации	Официальный workflow из Hugging Face PEFT LoRA guide; на странице репозитория PEFT виден релиз v0.19.1 от 2026-04-16; интеграция Transformers требует peft >= 0.19.1.	В supplied source pack нет одной канонической «текущей» библиотеки или версии; метод зафиксирован как обновление 100% параметров под задачу.
Тариф / цена	Фиксированной цены в источниках нет; стоимость зависит от compute, базовой модели и лицензии.	Фиксированной цены в источниках нет; стоимость зависит от compute, базовой модели и лицензии.
Дата проверки	2026-08-15	2026-08-15
Одинаковый вход для практического теста	Один и тот же pretrained base model, одна и та же downstream-задача и данные; меняется только способ обновления параметров.	Один и тот же pretrained base model, одна и та же downstream-задача и данные; меняется только способ обновления параметров.

Критерий	LoRA	Full fine-tuning
Какие параметры обновляются	Базовые веса заморожены, обучаются low-rank update matrices.	Обновляются все параметры модели.
Training footprint	Оригинальная работа заявляет меньше обучаемых параметров и более высокий training throughput.	Выше, потому что обучаются 100% параметров.
Task-specific артефакты	Сохраняются adapter weights поверх исходного checkpoint; можно слить в базовую модель.	Под задачу сохраняется полная копия модели.
Инференс после обучения	После merge, по оригинальной работе, нет дополнительной inference latency.	Полная модель уже standalone по своей природе.
Качество на сложных задачах	Может быть конкурентным, но recent studies показывают task-dependent gap.	В одной недавней работе точнее на code и math задачах.
Sample efficiency	В одной недавней работе уступает full fine-tuning на code и math.	В той же работе выше на code и math.
Чувствительность к гиперпараметрам	Выше, по recent study.	Ниже относительно LoRA в том же исследовании.
Забывание исходного домена	Меньше забывает source domain в одной недавней работе.	Больше забывает source domain в той же работе.
Интеграции и API	Есть текущий официальный workflow в PEFT и интеграция с Transformers.	В source pack нет отдельной текущей специализированной интеграции уровня PEFT.
Приватность и цены	Зависят от вашей инфраструктуры; в supplied sources политики managed service не зафиксированы.	Зависят от вашей инфраструктуры; в supplied sources политики managed service не зафиксированы.

Редакционная оговорка: это source-led сравнение без собственного A/B-бенчмарка на фиксированных модели и датасете. Поэтому вывод по качеству опирается на цитируемые статьи и должен быть перепроверен на вашей задаче, особенно если для вас важны code, math или иные высокочувствительные сценарии.

Цена и лимиты

Для этого сравнения нельзя честно назвать точную цену ни для LoRA, ни для full fine-tuning: в supplied source pack нет официальных pricing pages, а речь идёт не о SaaS-продуктах, а о подходах к адаптации модели. Поэтому по критерию «что дешевле» можно зафиксировать только одно надёжное следствие из источников: LoRA обучает меньше параметров и в оригинальной работе ассоциируется с более высоким training throughput.

Практически это означает следующее: если вы выбираете между двумя методами именно как инженерный workflow, LoRA чаще выглядит как более экономный старт. Но точную стоимость в GPU-часах, памяти и инфраструктуре вам всё равно придётся считать в своём стеке, потому что источники этого не фиксируют.

Что меняется в модели: LoRA vs full fine-tuning

Если упростить до сути, LoRA не переписывает весь base model. По оригинальной работе LoRA базовые pretrained weights остаются замороженными, а обучение идёт через low-rank update matrices. Это и создаёт основной выигрыш по числу trainable parameters и эксплуатационному удобству.

Full fine-tuning устроен иначе. В работе про adapters прямо сказано, что fine-tuning копирует и подстраивает исходные веса, а full fine-tuning обучает 100% параметров для каждой задачи. В терминах transfer learning это более полный, но и более тяжёлый путь адаптации.

Разница важна не только для обучения, но и для того, что вы потом храните и разворачиваете. Для LoRA task-specific слой может жить как отдельный adapter checkpoint поверх исходной модели. Для full fine-tuning под каждую задачу у вас появляется собственная полная версия модели.

Качество на задаче: где разрыв реально бывает

Самая частая ошибка в обсуждении «LoRA vs full fine-tuning» — считать, что LoRA просто «дешевле при том же качестве». Источники это не подтверждают как универсальное правило. Оригинальная работа LoRA показывает конкурентоспособность на ряде задач, но более свежие статьи прямо предупреждают: эквивалентности с full fine-tuning нет.

Работа LoRA vs Full Fine-tuning: An Illusion of Equivalence пишет, что LoRA и full fine-tuning не эквивалентны по структуре весов и поведению обобщения, а разрыв зависит от задачи. Другая недавняя статья, LoRA Learns Less and Forgets Less, сообщает более конкретный компромисс: full fine-tuning точнее и sample-efficient на code и math задачах, тогда как LoRA сильнее зависит от гиперпараметров, но меньше забывает исходный домен.

Практический вывод отсюда простой. Если вам нужен максимум точности на структурных задачах, похожих на code или math, full fine-tuning нельзя заранее вычёркивать. Если же ваш приоритет — безопасная и дешёвая адаптация с более мягким риском forgetting, LoRA остаётся очень сильной отправной точкой.

Скорость, память и размер артефактов

По этому критерию преимущество LoRA подтверждается лучше всего. Оригинальная статья заявляет меньше обучаемых параметров, более высокий training throughput и отсутствие дополнительной inference latency после merge. Это одно из немногих мест, где у метода есть устойчивое инженерное преимущество уже на уровне механики.

Microsoft reference implementation дополнительно объясняет operational side: LoRA checkpoints загружаются поверх исходного pretrained checkpoint, сохраняются как adapter weights и сливаются с base model в eval mode. В документации PEFT тот же принцип отражён через merge_and_unload(), который объединяет adapter layers с базовой моделью для standalone use.

У full fine-tuning workflow прямолинейнее, но тяжелее: вы обучаете и сохраняете всю модель. Это удобно, если вам нужна одна монолитная версия под конкретную задачу. Но если у вас десятки сценариев на одном base model, накопление полных checkpoint обычно менее удобно, чем хранение небольших адаптеров.

Стабильность результатов и чувствительность к гиперпараметрам

Здесь у LoRA есть важное ограничение, которое часто недооценивают. В source pack отдельно отмечено, что выбор между LoRA и full fine-tuning зависит от семейства модели, задачи, rank, target modules, размера данных и training recipe. То есть LoRA — не кнопка «сделать как full fine-tuning, только дешевле».

Работа LoRA Learns Less and Forgets Less прямо называет LoRA более чувствительной к гиперпараметрам. Практически это значит, что неудачный выбор rank, placement или рецепта обучения может съесть ту выгоду, ради которой вы вообще брали адаптеры.

У full fine-tuning свои риски — прежде всего вычислительные и организационные, — но именно по линии «настроил не тот adapter recipe» он проще для интерпретации: обновляются все веса, а не специально выбранные места в модели. Поэтому при жёстком KPI по качеству full fine-tuning иногда оказывается не только сильнее, но и понятнее как baseline.

Приватность и работа с данными

По критерию приватности в этом материале нельзя честно объявить победителя. Supplied sources — это papers, GitHub-репозитории и документация, а не privacy policies управляемых облачных сервисов. Из них нельзя вывести, как именно ваши данные будут храниться или использоваться в конкретной платформе.

Практический вывод такой: сравнивайте не слова «LoRA» и «full fine-tuning», а инфраструктуру, где вы запускаете обучение. Если это локальный или self-hosted стек, приватность определяется вашей архитектурой. Если это managed platform, проверяйте уже её policy отдельно — в текущем source pack таких данных нет.

Интеграции и API

У LoRA сейчас есть самый ясный и проверяемый workflow в supplied sources. Официальный гайд Hugging Face рекомендует: загрузить base model, создать LoraConfig, обернуть модель через get_peft_model(), а затем обучать получившийся PeftModel. Для верификации доступны print_trainable_parameters() и get_nb_trainable_parameters().

Для деплоя и упаковки артефактов это тоже удобно: в документации PeftModel есть merge_and_unload(), который объединяет adapter layers с base model для самостоятельного использования. Плюс текущая интеграция Transformers указывает на требование peft >= 0.19.1, а в репозитории PEFT на момент проверки виден релиз v0.19.1 от 2026-04-16.

Отдельно стоит знать про версионные тонкости. Release notes PEFT документируют поддержку target_parameters, позволяющую направлять LoRA на nn.Parameter напрямую; там же отмечены MoE-сценарии и более высокое использование памяти. Для full fine-tuning в source pack нет сопоставимой «специализированной» обвязки уровня PEFT: это не недостаток метода, а просто ограничение доступных источников.

Практический тест

Задача: адаптировать один и тот же pretrained base model под узкую downstream-задачу на одном и том же датасете, а затем подготовить артефакт для инференса. Ниже — не benchmark по качеству, а сравнение workflow на одинаковом входе, потому что supplied sources не дают единого независимого бенчмарка с фиксированными моделями и числами.

Заранее объявленные критерии

• Что именно становится trainable.
• Как проверяется объём обучаемых параметров.
• Что вы сохраняете после обучения.
• Как выглядит путь к standalone inference.
• Какие риски по качеству и стабильности прямо названы в источниках.

Результат LoRA

1) Load base model
2) Create LoraConfig
3) Wrap model with get_peft_model()
4) Verify trainable params via print_trainable_parameters() or get_nb_trainable_parameters()
5) Train resulting PeftModel
6) Save adapter weights
7) If needed, call merge_and_unload() for standalone use

Это лучший задокументированный workflow в current source pack. Он хорош тем, что вы явно видите reduced trainable set, храните компактный task-specific артефакт и при необходимости можете получить standalone model через merge.

Результат full fine-tuning

1) Load the same base model
2) Keep all model parameters trainable
3) Train the full model on the same downstream data
4) Save the full checkpoint for the task

Этот маршрут концептуально проще, но operationally тяжелее. В supplied sources для него нет столь же детализированного current wrapper-level workflow, как в PEFT, зато сама логика прозрачна: под задачу переобучается и сохраняется вся модель.

Вывод по тесту

Если критерием выбора является инженерный workflow, LoRA выглядит практичнее: меньше trainable parameters, небольшие adapters, понятные методы проверки и merge в standalone inference. Если же ключевой критерий — качество на сложной задаче, такой workflow-test сам по себе не решает вопрос: тогда нужен ваш собственный A/B-пилот, потому что recent studies показывают task-dependent gap в пользу то одного, то другого подхода.

Кому подойдёт LoRA

• Тем, кто хочет начать с минимально тяжёлого baseline для open-weight модели.
• Командам, которым нужно много task-specific вариантов поверх одного base model.
• Сценариям, где важны компактные артефакты и удобная версионизация адаптаций.
• Проектам, где риск forgetting нежелателен, а абсолютный максимум качества пока не доказан.
• Тем, кто хочет работать в текущем экосистемном workflow PEFT/Transformers, а не собирать всё вручную.

Кому подойдёт full fine-tuning

• Тем, кто измеряет успех по жёсткому quality KPI, а не по стоимости запуска первого эксперимента.
• Задачам, похожим на code и math, где cited study показала преимущество full fine-tuning по точности и sample efficiency.
• Случаям, где допустимо хранить отдельную полную модель под каждую задачу.
• Командам с достаточным compute-budget и готовностью вести более тяжёлый training/deployment lifecycle.

Когда оба не подходят

Есть несколько сценариев, где спор «LoRA или full fine-tuning» вообще преждевременный.

• Если у вас нет доступа к весам модели, ни LoRA, ни full fine-tuning в обычном смысле не применяются.
• Если задача решается на уровне few-shot или prompt engineering, сначала сравните это с дообучением: см. Few-shot vs Fine-tuning: что выбрать для адаптации LLM.
• Если вам нужна более лёгкая адаптация поведения без переподготовки всей модели, посмотрите на prompt tuning как на соседний PEFT-подход.

Иначе говоря, сам факт, что LoRA дешевле по training footprint, ещё не означает, что fine-tuning вообще нужен. Иногда правильный ответ — не выбирать между двумя этими методами, а отказаться от изменения весов.

Итог

Для практики вердикт такой: LoRA — более разумный стартовый baseline почти в любом проекте, где у вас есть доступ к весам и нет заранее доказанной необходимости обновлять 100% параметров. На стороне LoRA — меньше trainable parameters, более высокий throughput в оригинальной работе, компактные adapters и удобный merge в standalone inference.

Full fine-tuning стоит держать как обязательный второй вариант, если качество действительно критично и пилот показывает заметный разрыв. Свежие исследования не подтверждают универсальную эквивалентность методов: для одних задач LoRA достаточно, для других полный fine-tuning объективно остаётся сильнее.

Практический вердикт редакции: начинайте с LoRA, но не называйте его заменой full fine-tuning без A/B-проверки на вашей модели и данных.

Источники

• LoRA: Low-Rank Adaptation of Large Language Models
• GitHub – microsoft/LoRA
• LoRA · Hugging Face
• Models · Hugging Face
• Parameter-Efficient Transfer Learning for NLP
• GitHub – huggingface/peft: PEFT: State-of-the-art Parameter-Efficient Fine-Tuning
• Parameter-Efficient Fine-Tuning · Hugging Face
• Releases · huggingface/peft · GitHub
• LoRA vs Full Fine-tuning: An Illusion of Equivalence
• LoRA Learns Less and Forgets Less

Вопросы и ответы

Что выбрать по умолчанию для первого пилота?

Обычно LoRA. Источники подтверждают, что метод обучает меньше параметров, даёт более высокий training throughput в оригинальной работе и хранит task-specific адаптацию отдельным артефактом.

Когда full fine-tuning реально стоит дороже, но всё равно оправдан?

Когда качество важнее экономии. В одной недавней работе full fine-tuning оказался точнее и sample-efficient на code и math задачах, поэтому в quality-critical сценариях его нельзя исключать заранее.

Даёт ли LoRA дополнительную задержку на инференсе?

После merge — нет дополнительной inference latency, согласно оригинальной работе. В документации PEFT для standalone use есть merge_and_unload(), который объединяет adapter layers с base model.

Что проще хранить и версионировать?

LoRA обычно проще: adapter weights живут поверх одного и того же base checkpoint. При full fine-tuning под каждую задачу хранится полная копия модели.

Можно ли сравнивать методы без фиксации версии PEFT и Transformers?

Нежелательно. В source pack отдельно отмечена чувствительность функций PEFT к версии, а документация Transformers указывает требование peft >= 0.19.1. Перед воспроизведением эксперимента версии лучше зафиксировать явно.