Cztery projekty open source dominują dziś w fine-tuningu dużych modeli językowych: Unsloth, Axolotl, TRL oraz LLaMA-Factory. Wszystkie cztery opakowują ten sam bazowy stos PyTorch i Hugging Face, ale różnią się tym, gdzie koncentrują wysiłek inżynieryjny. Unsloth przepisuje kernele pod kątem surowej szybkości. Axolotl skupia się na komponowalnych strategiach równoległości. TRL definiuje API trainerów, na których budują pozostałe narzędzia. LLaMA-Factory priorytetowo traktuje szerokie pokrycie modeli i pracę bez pisania kodu.

W miarę jak modele z otwartymi wagami od Meta, Alibaba, Google i innych zmniejszają lukę jakościową względem własnościowych API, przedsiębiorstwa coraz częściej wykonują fine-tuning lokalnie, zamiast płacić premie za każdy token — co sprawia, że warstwa frameworków staje się bezpośrednią dźwignią kosztową, ponieważ godziny GPU pozostają dominującym wydatkiem w każdym procesie dostosowywania modeli.

To porównanie ocenia trzy obszary, z którymi praktycy regularnie się mierzą: przepustowość treningu, szczytowe użycie VRAM oraz skalowanie na wiele GPU.

Przegląd frameworków

TRL pełni funkcję referencyjnej warstwy implementacyjnej. Dostarcza SFTTrainer, DPOTrainer, GRPOTrainer, KTOTrainer, RewardTrainer oraz RLOOTrainer. Zarówno Axolotl, jak i LLaMA-Factory wywołują go wewnętrznie. Obecna stabilna linia wydań to v1.8.0.

Unsloth zastępuje części kodu modelowania ręcznie pisanymi kernelami Triton. Kroki propagacji wstecznej są wyprowadzane ręcznie, a nie generowane przez autograd. Własny opis Hugging Face wskazuje, że degradacja dokładności wynosi 0% względem standardowego QLoRA, ponieważ nie wprowadzono przybliżeń.

Axolotl to sterowany YAML wrapper nad Transformers, PEFT, TRL, Accelerate i DeepSpeed. Jego kluczowym wyróżnikiem jest komponowalność strategii równoległości, a nie optymalizacja na poziomie kerneli.

LLaMA-Factory opisano w pracy demonstracyjnej systemu ACL 2024 i obejmuje webowy interfejs Gradio o nazwie LlamaBoard. Repozytorium obsługuje ponad 100 LLM i VLM.

Szybkość

Unsloth: zyski na poziomie kerneli na pojedynczym GPU

Opublikowane benchmarki Unsloth pokazują 2x szybkość treningu dla Llama 3.1 8B i Llama 3.3 70B. Konfiguracja testowa używała zbioru Alpaca, batch size 2 oraz gradient accumulation 4. QLoRA działała z rank 32 we wszystkich warstwach liniowych.

Wyniki dla modeli Mixture-of-Experts (MoE) są bardziej wyraźne. Unsloth przeprowadził fine-tuning unsloth/gpt-oss-20b-BF16 na NVIDIA B200, raportując 712.33 ms na krok przy kontekście 8K wobec 5,226.86 ms dla Transformers v5 — różnicę 7.3x. Przy kontekście 4K luka zmniejsza się do 4.82x, a przy 1K wynosi tylko 1.37x.

Kierunek trendu zależy od modelu. Dokumentacja MoE Unsloth ogranicza to konkretne twierdzenie do gpt-oss, gdzie przyspieszenie rośnie wraz z długością sekwencji, co przypisuje się Flex Attention oraz kernelom MoE.

Qwen3-30B-A3B na B200 wykazuje odwrotny wzorzec. Raportowane przyspieszenie spada z 1.7x przy kontekście 1K do 1.1x przy 16K. Oszczędności pamięci poruszają się w przeciwnym kierunku, rosnąc z około 2% do 15%.

Qwen3-30B-A3B na H100 osiąga do 1.77x. GLM-4.7-Flash na RTX PRO 6000 osiąga 2.1x. Współpraca z AMD zmierzyła Llama-3.1-8B LoRA SFT na poziomie 2.07 s/krok, podczas gdy TRL plus FlashAttention-2 zajęły 2.87 s/krok — różnica 1.39x przy zgodnych krzywych straty.

Axolotl: pożyczone kernele, natywna równoległość

Axolotl dodał niestandardowe kernele Triton i funkcje autograd dla LoRA w lutym 2025 r., wyraźnie wskazując Unsloth jako inspirację. Są opcjonalne i włączane przez lora_mlp_kernel, lora_qkv_kernel oraz lora_o_kernel.

Najnowsze notatki wydań dodają obsługę SonicMoE LoRA, zapewniając do 1.45x przyspieszenia i 30% redukcji pamięci względem bazowego grouped_mm dla Qwen3.5-35B-A3B 8-bit LoRA na pojedynczym H100 SXM.

Axolotl dostarcza także FlashAttention 2/3/4, xFormers, Flex Attention, SageAttention, Liger Kernel, Cut Cross Entropy oraz ScatterMoE.

TRL: punkt odniesienia, do którego wszyscy porównują wyniki

TRL zwykle służy jako punkt referencyjny, a nie zwycięzca pod względem surowej przepustowości na pojedynczym GPU. Rekompensuje to szerokim zestawem dźwigni pamięci i szybkości opisanych w Reducing Memory Usage oraz Speeding Up Training. Obejmują one packing, batching bez paddingu, truncation, Liger Kernel oraz tryb uśpienia vLLM dla GRPO. TRL ma także oficjalną integrację z Unsloth, więc te dwa narzędzia się nie wykluczają.

LLaMA-Factory: szybkość przez delegowanie

LLaMA-Factory nie pisze własnych kerneli. Zamiast tego udostępnia optymalizacje innych frameworków przez flagi konfiguracyjne. Ustawienie use_unsloth: true aktywuje patch Unsloth, a changelog projektu raportuje 170% względnej szybkości tą ścieżką. Trening długich sekwencji Unsloth jest wymieniany jako 117% szybkości i 50% pamięci. LLaMA-Factory obsługuje także enable_liger_kernel: true oraz FlashAttention-2 przez flash_attn: fa2.

VRAM

Raportowane minima pamięci

Unsloth publikuje tabelę wymagań VRAM posortowaną według liczby parametrów. Wskazuje 6 GB dla modelu 8B w 4-bit QLoRA oraz 41 GB dla 70B. LoRA w 16-bit kosztuje odpowiednio 22 GB i 164 GB dla tych samych modeli.

Tabela sprzętowa README LLaMA-Factory obejmuje ten sam reżim 4-bit QLoRA, podając 6 GB przy 7B, 24 GB przy 30B oraz 48 GB przy 70B. Pełny fine-tuning bf16 modelu 70B jest wskazany na poziomie 600 GB.

Obie tabele opisują minima. Batch size, długość sekwencji i wybór optymalizatora wpływają na rzeczywiste zużycie.

Długość kontekstu jako ostrzejszy wyróżnik

Szczytowe VRAM przy stałej długości kontekstu ma mniejsze znaczenie niż maksymalny kontekst, na jaki pozwala dany budżet VRAM. Benchmarki długości kontekstu Unsloth dla Llama 3.1 8B QLoRA przy rank 32 i batch size 1 są wyraziste. Unsloth przypisuje to swojemu algorytmowi gradient checkpointing połączonemu z Apple Cut Cross Entropy. Dla Llama 3.3 70B na 80 GB A100 raportuje 89,389 tokenów — wobec 6,916 dla bazowego FA2.

Historia pamięci w MoE

Trening MoE to obszar, w którym zachowanie pamięci zmieniło się najbardziej w 2026 r. Unsloth raportuje fine-tuning gpt-oss-20b w granicach 12.8 GB, podczas gdy Qwen3-30B-A3B przy 16-bit LoRA wymaga 63 GB.

W uruchomieniu gpt-oss na B200 Unsloth użył 47.43 GB przy kontekście 8K, podczas gdy Transformers v5 użył 73.80 GB. Przy 16K Transformers v5 zabrakło pamięci, a Unsloth użył 55.13 GB.

Mechanizmem jest formulacja split-LoRA. PEFT materializuje deltę LoRA we wszystkich ekspertach przed mnożeniem macierzy MoE. Unsloth zamiast tego zmienia kolejność operacji, co jest matematycznie identyczne, ale unika kroku materializacji.

Axolotl rozwiązuje ten sam problem przez kwantyzację ekspertów MoE, kwantyzując wagi ekspertów podczas ładowania modelu i natychmiast zwalniając oryginalny tensor bf16. Stało się to konieczne po zmianie w Transformers v5, która przeniosła warstwy ekspertów z nn.Linear do scalonych tensorów 3D nn.Parameter, uniemożliwiając bitsandbytes ich kwantyzację przy ładowaniu. Dokumentacja Axolotl raportuje spadek zarezerwowanej pamięci dla GLM-4.7-Flash QLoRA z około 127 GiB do około 23 GiB przy quantize_moe_experts: true.

Multi-GPU

Multi-GPU to obszar, w którym ranking z pojedynczego GPU się odwraca. Przewaga Unsloth na pojedynczym GPU nie przenosi się dalej.

Axolotl: najgłębsza macierz równoległości

Przewodnik multi-GPU Axolotl oferuje trzy wzajemnie wykluczające się strategie shardingu: DeepSpeed ZeRO etapy od 1 do 3, FSDP oraz DDP. FSDP2 jest zalecaną ścieżką, a FSDP1 jest przestarzałe.

Ponadto jego przewodnik N-D Parallelism komponuje równoległość danych, tensorów, kontekstu i ekspertów przez PyTorch DeviceMesh. Udokumentowana macierz wsparcia potwierdza FSDP+TP, HSDP+TP, FSDP+CP, FSDP+TP+CP oraz FSDP+EP. Dwie kombinacje są wyraźnie niewspierane: równoległość ekspertów nie może być komponowana z TP ani CP w v1, a czysty DDP również nie może być z nimi komponowany.

Równoległość sekwencji Axolotl używa biblioteki ring-flash-attention. Jego opublikowany benchmark H100 dla Llama 3.1 8B QLoRA ilustruje kompromis: kontekst skaluje się niemal liniowo, ale efektywność przepustowości spada gwałtownie. Na 4090 przy stopniu SP 8 ten sam benchmark odnotowuje 0.88x przyspieszenia — trening faktycznie zwolnił, choć kontekst osiągnął 32,768 tokenów.

Axolotl obsługuje także trening wielowęzłowy przez torchrun i Ray.

TRL: dwa backendy dzielenia sekwencji

Przewodnik treningu rozproszonego TRL jasno rozróżnia dwa podejścia. Context Parallelism używa Ring Attention na FSDP2, wymaga Accelerate 1.11.0+, korzysta z cp_size z cp_backend="torch" i obecnie obsługuje tylko SDPA — FlashAttention nie jest wspierany na tej ścieżce. Sekwencje muszą dzielić się równo przez cp_size * 2.

Sequence Parallelism używa ALST/Ulysses na DeepSpeed, wymaga DeepSpeed 0.18.1+ oraz Accelerate 1.12.0+. Korzysta z sp_size z sp_backend="deepspeed" i działa z FlashAttention-2, ale ogranicza go liczba głów uwagi, wymagając num_heads >= sp_size.

Wskazówki TRL są konkretne: Ring Attention nadaje się do sekwencji 1M+ tokenów i ograniczonej topologii sieci, podczas gdy Ulysses pasuje do połączeń NVLink lub InfiniBand oraz sekwencji do około 500k tokenów. Własny benchmark Ring Attention TRL fine-tunował Qwen3-8B na 1, 2, 4 i 8 GPU H100, a przy 8 GPU długości kontekstu powyżej 300k tokenów stały się trenowalne.

LLaMA-Factory: standardowe silniki z Megatron

Dokumentacja treningu rozproszonego LLaMA-Factory obejmuje DDP, DeepSpeed i FSDP, w tym FSDP2 oraz Ray dla uruchomień jedno- i wielowęzłowych. Dokumentacja opisuje także DeepSpeed AutoTP, które łączy równoległość tensorów z ZeRO.

Najważniejszym dodatkiem w 2025 r. był backend treningowy Megatron-core przez mcore_adapter, otwierający rzeczywistą ścieżkę pretreningu na dużą skalę. Ścieżka FSDP+QLoRA fine-tunuje model 70B na dwóch GPU 24 GB — to najtańsza udokumentowana droga do 70B w tym porównaniu.

Punktem tarcia jest sam interfejs. Konfiguracja rozproszona znajduje się w YAML i CLI, a nie w LlamaBoard. Zespoły, które wybrały LLaMA-Factory ze względu na bezkodowy UI, tracą tę właściwość przy skalowaniu poza jedno GPU.

Unsloth: otwarta luka

Dokumentacja multi-GPU Unsloth stwierdza, że multi-GPU działa przez Accelerate i DeepSpeed, dając dostęp do FSDP i DDP. Jednocześnie wskazuje jednak, że proces jest złożony i wymaga ręcznej konfiguracji, a oficjalne wsparcie wciąż jest zapowiadane. Praktyczna ścieżka to accelerate launch train.py albo torchrun --nproc_per_node N_GPUS train.py. Dla modeli zbyt dużych na jedno GPU, device_map = "balanced" dzieli model między urządzenia.

Wpis PyPI Unsloth oznacza multi-GPU jako dostępne, ale z dużymi usprawnieniami w toku. Changelog Studio opisuje wstępną automatyczną alokację multi-GPU dla inferencji i treningu według stanu na marzec 2026 r.

Łącznie pozycja jest jasna: Unsloth obsługuje multi-GPU, ale nie oferuje jeszcze komponowalnej macierzy równoległości dokumentowanej przez Axolotl i TRL.

Ograniczenia każdego frameworka

Unsloth przestaje być wystarczający, gdy równoległość tensorów, kontekstu lub ekspertów jest potrzebna jako pierwszoklasowa konfiguracja. Problem pojawia się także wtedy, gdy model nie znajduje się na liście wspieranych, ponieważ zyski wynikają z kerneli specyficznych dla architektury.

Axolotl ma barierę w postaci krzywej uczenia. Użytkownicy muszą konfigurować FSDP2 kontra DeepSpeed, stopień SP oraz ograniczenia podzielności obejmujące liczbę GPU, długość sekwencji i liczbę głów uwagi.

TRL ma słabość w domyślnych ustawieniach. Dostarcza poprawne prymitywy, a nie dostrojone konfiguracje — użytkownicy muszą zapewnić konfigurację Accelerate, optymalizacje pamięci i plan równoległości.

LLaMA-Factory napotyka ograniczenie na granicy UI. Jego abstrakcja jest skuteczna do jednego węzła, ale powyżej tego poziomu staje się płytka.

Praktyczne wskazówki

Dla pojedynczego konsumenckiego GPU ze wspieraną architekturą i LoRA lub QLoRA, Unsloth jest najmocniejszym wyborem — sam zapas długości kontekstu to uzasadnia.

Dla dwóch do ośmiu GPU, długiego kontekstu oraz pełnego fine-tuningu lub potoków RLHF zalecany jest Axolotl. FSDP2 plus równoległość sekwencji to najlepiej udokumentowana ścieżka.

Dla niestandardowych pętli treningowych, nowych algorytmów post-trainingu lub ścisłego powiązania z Hugging Face, TRL jest fundamentem do budowy, ponieważ to warstwa, którą opakowują inni.

Dla najszerszego pokrycia modeli, operatorów niebędących inżynierami i najszybszych pierwszych uruchomień optymalny jest LLaMA-Factory — z przejściem do CLI przy skalowaniu.

Te wybory nie wykluczają się wzajemnie. LLaMA-Factory może uruchamiać Unsloth jako backend. TRL dostarcza integrację z Unsloth. Axolotl wewnętrznie wywołuje trainery TRL. Frameworki wyraźnie zbliżają się do swoich mocnych stron — Unsloth dodaje multi-GPU, LLaMA-Factory dodaje Megatron, a Axolotl przyjmuje sztuczki na poziomie kerneli — co sugeruje, że w kolejnym cyklu różnicowanie może przesunąć się z surowej wydajności w stronę ergonomii dla deweloperów i szerokości integracji.

Źródło: MarkTechPost