Сравнение Unsloth, Axolotl, TRL, LLaMA-Factory: какой фреймворк выбрат

В мире генеративного искусственного интеллекта тонкая настройка (fine-tuning) больших языковых моделей (LLM) перестала быть эксклюзивной прерогативой корпораций с бесконечными бюджетами. Сегодня это рутинная задача для исследователей, инженеров данных и энтузиастов. Однако выбор правильного инструмента для этой задачи может стать узким местом, определяющим успех всего проекта. На рынке доминируют четыре открытых проекта, которые, по сути, обертывают один и тот же базовый стек PyTorch и Hugging Face, но делают это совершенно по-разному: Unsloth, Axolotl, TRL и LLaMA-Factory.

На первый взгляд, все они решают одну задачу — обучение модели на ваших данных. Но за фасадом простоты скрывается глубокая инженерная философия. Unsloth переписывает ядра (kernels) на уровне Triton для максимальной скорости. Axolotl фокусируется на композиции стратегий параллелизма. TRL предоставляет базовые API-интерфейсы, на которых строятся остальные. А LLaMA-Factory делает ставку на широту покрытия моделей и работу «без кода» через веб-интерфейс.

В этой статье мы разберем, как эти фреймворки ведут себя в реальных условиях, сфокусировавшись на трех ключевых осях, которые волнуют любого инженера: скорость обучения (throughput), пиковое потребление видеопамяти (VRAM) и масштабирование на нескольких GPU. Мы не просто перечислим характеристики, а покажем, где каждый инструмент ломается, а где становится незаменимым.

01Понимание архитектуры: Кто есть кто?

Прежде чем погружаться в бенчмарки, важно понять архитектурную роль каждого инструмента. Это поможет вам выбрать не просто «быстрый», а «правильный» стек для вашей задачи.

TRL: Базовый слой истины

Transformer Reinforcement Learning (TRL) — это референсная реализация, фундамент. Именно здесь определены классы SFTTrainer, DPOTrainer, GRPOTrainer и другие. Axolotl и LLaMA-Factory фактически вызывают TRL «под капотом». Текущая стабильная версия — v1.8.0. TRL не всегда выигрывает в чистой скорости на одном GPU, но он предлагает наибольшую гибкость и широту настроек памяти и скорости, задокументированных в официальных руководствах. Если вы строите кастомные пайплайны обучения или экспериментируете с новыми алгоритмами пост-обучения, TRL — это ваш выбор.

Unsloth: Оптимизация на уровне ядер

Unsloth не просто использует стандартные библиотеки. Он заменяет части кода модели вручную написанными ядрами Triton. Шаги обратного распространения ошибки (backpropagation) выводятся вручную, а не генерируются автоматически через autograd. Это позволяет избежать накладных расходов PyTorch. Согласно собственному отчету Hugging Face, деградация точности по сравнению со стандартным QLoRA составляет 0%, так как не используются аппроксимации, влияющие на качество. Это инструмент для тех, кто хочет выжать максимум из одного GPU.

Axolotl: Мастер композиции

Axolotl — это YAML-управляемая обертка над Transformers, PEFT, TRL, Accelerate и DeepSpeed. Его главное отличие — не в написании собственных ядер (хотя они есть), а в умении комбинировать стратегии параллелизма. Axolotl позволяет легко переключаться между DeepSpeed ZeRO, FSDP и DDP, а также настраивать сложные сценарии распределенного обучения через конфигурационные файлы.

LLaMA-Factory: Широта и простота

LLaMA-Factory, представленная как системная демонстрация на ACL 2024, делает ставку на доступность. Она включает веб-интерфейс LlamaBoard и поддерживает более 100 LLM и VLM (Vision Language Models). LLaMA-Factory не пишет свои ядра, а делегирует эту работу другим инструментам через флаги конфигурации. Это идеальный выбор для операторов, не являющихся инженерами, или для быстрого прототипирования.

💡

Совет по выбору. Не рассматривайте эти инструменты как взаимоисключающие. LLaMA-Factory может использовать Unsloth в качестве бэкенда. TRL имеет официальную интеграцию с Unsloth. Axolotl вызывает тренера TRL внутренне. Вы можете начать с LLaMA-Factory для быстрого старта, а затем перейти к CLI-инструментам для масштабирования.

02Скорость обучения: Где кроется прирост?

Скорость — это первое, на что смотрят инженеры. Но цифры могут быть обманчивы, если не учитывать контекст (длину последовательности, тип модели и архитектуру GPU).

Unsloth vs Axolotl vs TRL vs LLaMA-Factory: Глубокое сравнение фреймворков для тонкой настройки LLM

Unsloth: Ядерные ускорения на одном GPU

Опубликованные бенчмарки Unsloth показывают двукратное ускорение обучения для Llama 3.1 8B и Llama 3.3 70B. Тесты проводились на датасете Alpaca с размером батча 2 и накоплением градиентов 4. QLoRA запускался с рангом 32 на всех линейных слоях. Однако самые впечатляющие результаты показывают модели с экспертами (MoE).

Например, при тонкой настройке unsloth/gpt-oss-20b-BF16 на NVIDIA B200, Unsloth показал 712.33 мс на шаг при контексте 8K, в то время как стандартный Transformers v5 требовал 5,226.86 мс. Это разрыв в 7.3 раза! При контексте 4K разрыв составляет 4.82x, а при 1K — всего 1.37x. Интересно, что для модели Qwen3-30B-A3B на B200 тренд обратный: ускорение падает с 1.7x при 1K до 1.1x при 16K, хотя экономия памяти при этом растет с 2% до 15%.

На GPU AMD, в сотрудничестве с которыми проводились замеры, Llama-3.1-8B LoRA SFT на Unsloth занимал 2.07 с/шаг против 2.87 с/шаг у TRL + FlashAttention-2, что дает прирост в 1.39x при совпадающих кривых потерь.

Axolotl: Заимствованные ядра и нативное параллелизм

Axolotl добавил собственные ядра Triton и функции autograd для LoRA в феврале 2025 года, явно ссылаясь на Unsloth как на источник вдохновения. Эти опции включаются через флаги lora_mlp_kernel, lora_qkv_kernel и lora_o_kernel. Недавние обновления добавили поддержку SonicMoE LoRA, обеспечивающую ускорение до 1.45x и снижение памяти на 30% по сравнению с базовым grouped_mm для модели Qwen3.5-35B-A3B 8-bit LoRA на одном H100 SXM.

Axolotl также поддерживает широкий спектр оптимизаций: FlashAttention 2/3/4, xFormers, Flex Attention, SageAttention, Liger Kernel, Cut Cross Entropy и ScatterMoE. Это делает его мощным инструментом, который комбинирует лучшие практики из разных библиотек.

TRL: Базовая линия

TRL обычно служит точкой отсчета, а не победителем в чистой скорости. Он компенсирует это широтой рычагов управления памятью и скоростью, таких как упаковка данных, батчинг без заполнения (padding-free batching), усечение, использование Liger Kernel и режим сна vLLM для GRPO. Важно помнить, что TRL и Unsloth не исключают друг друга — TRL имеет официальную интеграцию с Unsloth.

LLaMA-Factory: Скорость через делегирование

LLaMA-Factory не пишет свои ядра. Она экспонирует работу других через флаги конфигурации. Установка use_unsloth: true активирует патч Unsloth, что, согласно журналу изменений проекта, дает относительное ускорение на 170%. Долгосрочное обучение с длинным контекстом показывает 117% ускорения и 50% экономии памяти. Также поддерживаются enable_liger_kernel: true и FlashAttention-2 через flash_attn: fa2.

⚠️

Важно. Направление тренда ускорения зависит от модели. Заявления Unsloth о скорости часто специфичны для определенных архитектур (например, gpt-oss). Всегда проверяйте бенчмарки для вашей конкретной модели и длины контекста.

03Потребление VRAM: Контекст — это король

Пиковое потребление VRAM при фиксированной длине контекста менее интересно, чем максимальная длина контекста, которую позволяет бюджет памяти. Здесь Unsloth демонстрирует поразительные результаты.

Минимальные требования

Unsloth публикует таблицу требований VRAM, отсортированную по количеству параметров. Для модели 8B в 4-битном QLoRA требуется всего 6 ГБ, а для 70B — 41 ГБ. LoRA в 16-битном формате для тех же моделей требует 22 ГБ и 164 ГБ соответственно. LLaMA-Factory показывает схожие цифры: 6 ГБ для 7B, 24 ГБ для 30B и 48 ГБ для 70B в 4-битном QLoRA. Полное обучение 70B в bf16 требует 600 ГБ, что делает такие задачи доступными только на кластерах.

Обе таблицы описывают минимумы. Реальное число зависит от размера батча, длины контекста и выбора оптимизатора.

Длина контекста: Разрыв становится очевидным

Самое яркое преимущество Unsloth раскрывается при работе с длинным контекстом. Бенчмарки для Llama 3.1 8B QLoRA (ранг 32, батч 1) показывают следующую картину:

8 ГБ VRAM: Unsloth обрабатывает 2,972 токена, Transformers + FA2 выдает OOM (Out Of Memory).
16 ГБ VRAM: Unsloth — 40,724 токена, Transformers — 2,551.
24 ГБ VRAM: Unsloth — 78,475 токенов, Transformers — 5,789.
48 ГБ VRAM: Unsloth — 191,728 токенов, Transformers — 15,502.
80 ГБ VRAM: Unsloth — 342,733 токена, Transformers — 28,454.

Для Llama 3.3 70B на 80 ГБ A100 Unsloth позволяет работать с 89,389 токенами, в то время как базовый FA2 достигает лишь 6,916. Это достигается за счет алгоритма градиентного чекпоинтинга в сочетании с Apple's Cut Cross Entropy.

История памяти в моделях MoE

Обучение моделей с экспертами (MoE) — это область, где поведение памяти изменилось в 2026 году. Unsloth сообщает, что может обучать gpt-oss-20b внутри 12.8 ГБ памяти, в то время как Qwen3-30B-A3B в 16-битном LoRA требует 63 ГБ.

На B200 запуск gpt-oss с контекстом 8K использовал 47.43 ГБ, тогда как Transformers v5 — 73.80 ГБ. При 16K контекста Transformers v5 выходил из памяти, а Unsloth использовал 55.13 ГБ. Механизм здесь — формулировка Split-LoRA. PEFT материализует дельту LoRA для всех экспертов перед умножением матриц MoE. Unsloth переупорядочивает операции, что математически эквивалентно, но избегает материализации.

Axolotl атакует эту проблему иначе. Его квантование экспертов MoE квантует веса экспертов во время загрузки модели, освобождая исходный тензор bf16 немедленно. Это стало необходимо из-за изменений в Transformers v5, где экспертные слои перешли от nn.Linear к слитым 3D-тензорам nn.Parameter, которые bitsandbytes больше не мог квантовать при загрузке. Документация Axolotl сообщает, что для GLM-4.7-Flash QLoRA зарезервированная память упала с ~127 ГБ до ~23 ГБ при включении quantize_moe_experts: true.

📌

Факт. Для моделей MoE выбор между Unsloth и Axolotl может зависеть от того, предпочитаете ли вы оптимизацию порядка операций (Unsloth) или квантование весов экспертов при загрузке (Axolotl).

04Многопроцессорное обучение (Multi-GPU): Где рейтинг инвертируется

Здесь лидерство Unsloth в скорости на одном GPU не переносится. Масштабирование — это та область, где Axolotl и TRL демонстрируют свое превосходство.

Axolotl: Глубочайшая матрица параллелизма

Axolotl предлагает три взаимоисключающие стратегии шардинга: DeepSpeed ZeRO (стадии 1-3), FSDP и DDP. FSDP2 является рекомендуемым путем, а FSDP1 устарел. Кроме того, Axolotl позволяет комбинировать data, tensor, context и expert parallelism через PyTorch's DeviceMesh. Поддерживаемые комбинации включают FSDP+TP, HSDP+TP, FSDP+CP, FSDP+TP+CP и FSDP+EP.

Две комбинации явно не поддерживаются: экспертный параллелизм не может быть составлен с TP или CP в версии 1. Чистый DDP также не может быть составлен с ними. Axolotl также поддерживает последовательный параллелизм (sequence parallelism) через библиотеку ring-flash-attention.

Опубликованный бенчмарк на H100 для Llama 3.1 8B QLoRA показывает компромисс:

При степени параллелизма (SP) 1: макс. контекст 17,408, скорость 9,104 токенов/сек.
При SP 2: контекст 34,816, скорость 15,806 (86.8% эффективности на GPU).
При SP 4: контекст 66,560, скорость 12,314 (33.8% эффективности).
При SP 8: контекст 129,024, скорость 11,096 (15.2% эффективности).

Контекст масштабируется почти линейно, но эффективность пропускной способности резко падает. На GPU RTX 4090 при SP 8 тот же бенчмарк зафиксировал ускорение 0.88x. Обучение стало медленнее, хотя контекст достиг 32,768 токенов. Axolotl также поддерживает многоузловое обучение через torchrun и Ray.

TRL: Два бэкенда разделения последовательностей

TRL проводит четкую границу. Context Parallelism означает Ring Attention на FSDP2. Sequence Parallelism означает ALST/Ulysses на DeepSpeed.

Ring Attention: Требует Accelerate 1.11.0+, использует cp_size с cp_backend="torch". Поддерживает только SDPA, FlashAttention не поддерживается. Последовательности должны делиться на cp_size * 2. Подходит для последовательностей 1M+ токенов и ограниченной топологии сети.
ALST/Ulysses: Требует DeepSpeed 0.18.1+ и Accelerate 1.12.0+. Использует sp_size с sp_backend="deepspeed" и работает с FlashAttention-2. Ограничено количеством голов внимания (num_heads >= sp_size). Подходит для NVLink или InfiniBand и последовательностей до ~500k токенов.

Бенчмарк TRL с Ring Attention для Qwen3-8B на 8 GPU H100 показал, что при 8 GPU стали обучаемыми контексты длиной выше 300k токенов.

LLaMA-Factory: Стандартные движки с Megatron

Документация LLaMA-Factory охватывает DDP, DeepSpeed и FSDP, включая FSDP2 и Ray. Также описан DeepSpeed AutoTP, сочетающий тензорный параллелизм с ZeRO. Самым значимым добавлением 2025 года стал бэкенд обучения Megatron-core через mcore_adapter, открывающий путь к масштабной предобучению.

Путь FSDP+QLoRA позволяет тонко настроить модель 70B на двух GPU по 24 ГБ. Это самый дешевый задокументированный путь к 70B в данном сравнении. Однако есть нюанс: распределенная конфигурация живет в YAML и CLI, а не в LlamaBoard. Команды, которые выбрали LLaMA-Factory за ее zero-code UI, теряют это свойство при масштабировании более чем на один GPU.

Unsloth: Открытый пробел

Документация Unsloth утверждает, что многопроцессорное обучение работает через Accelerate и DeepSpeed, давая доступ к FSDP и DDP. Однако процесс сложен и требует ручной настройки, официальная поддержка все еще объявляется. Практический маршрут — accelerate launch train.py или torchrun --nproc_per_node N_GPUS train.py. Для моделей, слишком больших для одного GPU, device_map = "balanced" разделяет модель между устройствами.

Список PyPI Unsloth отмечает многопроцессорное обучение как доступное с крупными улучшениями в ожидании. В журнале изменений Studio описана предварительная автоматическая многопроцессорная аллокация для вывода и обучения с марта 2026 года. Позиция ясна: Unsloth поддерживает multi-GPU, но пока не предлагает композиционной матрицы параллелизма, как Axolotl и TRL.

⚠️

Важно. Если вам нужно масштабироваться на несколько GPU, особенно с длинным контекстом, Unsloth может стать узким местом. Axolotl и TRL предлагают более зрелые решения для распределенного обучения.

05Где каждый из них ломается

Понимание ограничений так же важно, как и преимуществ. Вот сценарии, в которых каждый инструмент может подвести:

Unsloth ломается, когда вам нужен тензорный, контекстный или экспертный параллелизм как первоклассная конфигурация. Он также ломается, когда ваша модель не входит в список поддерживаемых, так как преимущества приходят от архитектурно-специфичных ядер.
Axolotl ломается о кривую обучения. Вам нужно настроить FSDP2 против DeepSpeed, степень SP и ограничения делимости. Эти ограничения охватывают количество GPU, длину последовательности и головы внимания.
TRL ломается на настройках по умолчанию. Он дает вам правильные примитивы, но не настроенные. Вы должны предоставить конфигурацию Accelerate, оптимизации памяти и план параллелизма.
LLaMA-Factory ломается на границе UI. Ее абстракция отлична до одного узла и тонка выше него.

06Что это значит на практике

Выбор фреймворка зависит от ваших ресурсов и целей. Вот краткое руководство:

Один потребительский GPU, поддерживаемая архитектура, LoRA или QLoRA: Выбирайте Unsloth. Запас по длине контекста и скорость на одном GPU оправдывают его использование.
Два-восемь GPU, длинный контекст, полное тонкое обучение или пайплайны RLHF: Выбирайте Axolotl. FSDP2 плюс последовательный параллелизм — это самый хорошо задокументированный путь.
Кастомные пайплайны обучения, новые алгоритмы пост-обучения, тесная интеграция с Hugging Face: Выбирайте TRL. Вы строите на слое, который обертывают остальные.
Наибольшее покрытие моделей, операторы-не-инженеры, самый быстрый первый запуск: Выбирайте LLaMA-Factory. Затем переходите к CLI, когда масштабируетесь.

Эти выборы не исключают друг друга. LLaMA-Factory может запускать Unsloth как бэкенд. TRL имеет интеграцию с Unsloth. Axolotl вызывает тренеров TRL внутренне. Понимание этих взаимодействий позволит вам построить гибкий и эффективный стек для работы с большими языковыми моделями.

В заключение, экосистема тонкой настройки LLM в 2026 году зрела и разнообразна. Нет одного «лучшего» инструмента. Есть лучший инструмент для конкретной задачи, конкретных ресурсов и конкретной команды. Используйте сильные стороны каждого фреймворка, чтобы максимизировать производительность и минимизировать затраты.

Источник: MarkTechPost ↗