Hvad vægter mest i jeres næste træningsjob: fart, hukommelse eller fleksibilitet. MarkTechPost publicerede 22. juli 2026 en sammenligning af fire dominerende open source‑rammer til LLM‑fine‑tuning — Unsloth, Axolotl, TRL og LLaMA‑Factory — med fokus på træningshastighed, peak VRAM og multi‑GPU. Ifølge kilden bygger alle fire oven på PyTorch og Hugging Face, men de trækker i forskellige retninger teknisk. Det kan mærkes i praksis, især ved lange sekvenser og større modeller.
Kort fortalt: Unsloth går i dybet med håndskrevne kerner. Axolotl satser på komponerbar parallelisering og YAML‑styret orkestrering. TRL er laget med træner‑API’er, andre kalder ind i. LLaMA‑Factory dækker bredt på modeller og stiller et UI til rådighed for zero‑code‑kørsler. Sammenligningen er ikke bare overskrifter; den kobler designvalg til målbare forskelle i fart, VRAM og skalering, med kildeangivelser til hvert udsagn.
Fælles fundament, forskellige kompromisser
MarkTechPost slår fast, at alle fire projekter hviler på PyTorch og Hugging Face. Det skaber genkendelige datastrukturer, checkpointer og træningsmønstre på tværs. Forskellene viser sig i de dele, der ikke er standard: kerneskrivning, parallelisering, og hvor meget logik man lægger i konfiguration frem for kode. Det er her, valget begynder at lugte af drift snarere end demo.
TRL optræder i artiklen som referenceskiktet med trænere som SFTTrainer, DPOTrainer, GRPOTrainer, KTOTrainer, RewardTrainer og RLOOTrainer (kilden citerer stabil linje v1.8.0). Axolotl og LLaMA‑Factory kalder ind i TRL, mens Unsloth og Axolotl hver især lægger ekstra optimeringslag ovenpå. Det betyder, at mange teams i praksis ender med at kombinere lagene frem for at vælge ét alene.
Unsloth og kerneoptimering under motorhjelmen
Unsloth erstatter dele af modelkoden med håndskrevne Triton‑kerner, og backpropagation er manuelt afledt i stedet for autograd. Ifølge MarkTechPost (der gengiver Unsloths egne tal) rapporteres cirka 2x træningshastighed for Llama 3.1 8B og Llama 3.3 70B på Alpaca med batch 2, grad‑acc 4 og QLoRA rank 32 på alle lineære lag. Det er en markant forskel, når GPU‑tiden betales pr. sekund.
Artiklen gengiver også Unsloths per‑step målinger for unsloth/gpt‑oss‑20b‑BF16 på NVIDIA B200: 712,33 ms pr. step ved 8K kontekst mod 5.226,86 ms i Transformers v5 — 7,3x hurtigere per‑step. Ved 4K er forskellen 4,82x og ved 1K 1,37x. Disse benchmarks er egenrapporterede af Unsloth, og kilden noterer, at gevinsterne er modelafhængige, med tendens til større effekter i MoE‑scenarier.
Axolotl og komponerbar parallelisering
Axolotl beskrives som en YAML‑drevet wrapper over Transformers, PEFT, TRL, Accelerate og DeepSpeed. Differentieringen er komponerbarhed i paralleliseringsstrategier, ikke primært kerneskrivning. Den tilgang gør det lettere at beskrive komplekse opsætninger, dele dem mellem teams og genbruge dem i nye træningsjobs uden at skrive meget ny kode.
MarkTechPost fremhæver, at Axolotl også tilbyder opt‑in Triton‑kerner for LoRA samt en række opmærksomheds‑ og hukommelsesoptimeringer gennem eksisterende biblioteker. Men i modsætning til Unsloth er pointen ikke at erstatte større dele af standardstakken. Det ændrer karakteren af performancegevinsterne og den måde, man fejlsøger og vedligeholder pipelines på.
TRL som fælles trænerlag
TRL udgør ifølge kilden et fælles API‑lag, som mange måler imod, og som andre frameworks bygger ovenpå. Med SFT, DPO og andre træner‑klasser definerer TRL en stabil overflade, der gør det enklere at skifte mellem opsætninger uden at starte forfra. Det kan være mere værd end en teoretisk procentpoint i throughput, når man planlægger måneder med løbende eksperimenter.
MarkTechPost noterer TRL’s rolle eksplicit: et referencepunkt snarere end single‑GPU‑rekordholder. Det passer med, at fleksibilitet og kompatibilitet ofte vægter tungt i produktionsmiljøer, hvor pipelines og governance er lige så vigtige som rå hastighed.
LLaMA‑Factorys brede modelsupport og UI
LLaMA‑Factory er fremhævet som en ACL 2024 systemdemonstration og har et Gradio‑baseret web‑UI kaldet LlamaBoard. Repoet dækker 100+ LLMs og VLMs ifølge kilden. Formålet er tydeligt: lav tærskel for at komme i gang, også når man hopper mellem modelarkitekturer. Den vej kan være hurtigere til PoC og intern validering, selv om tophastighed ikke altid er målet.
I praksis reducerer den tilgang ventetiden fra idé til første kørsel. Det gør LLaMA‑Factory relevant, når opgaven er at afprøve flere modeller på kort tid, eller når teams uden tung CUDA‑erfaring skal levere en baseline.
Sådan bør benchmarks læses
MarkTechPost er tydelig om proveniens: flere af Unsloths stærkeste tal er egenrapporterede og gengives som sådanne. Kilden skriver også, at observerede trends er model‑ og kontekstafhængige, og at MoE‑cases i de nævnte eksempler giver større gevinster. Konklusionen er ikke, at ét framework altid er hurtigst, men at designvalgene slår forskelligt igennem alt efter setup.
Der peges endvidere på variationer mellem GPU‑generationer og, for nogle modeller, stigende memory‑besparelser med længere sekvenser. Det gør hardware‑valg og realistiske sekvenslængder til et driftsanliggende, ikke en fodnote. Læs: mål på jeres egne data før I binder jer.
Hvad det betyder i drift
Kernel‑optimeringer a la Unsloth kan forkorte træningstiden markant ved lange kontekster og store modeller, hvilket slår direkte igennem på cloud‑regningen. Axolotls komponerbarhed giver smidigere multi‑GPU‑opsætninger og nemmere genbrug i CI/CD, ofte med færre specialtilpasninger. TRL som fælles trænerlag mindsker låsning til et enkelt projekt og gør pipeline‑logik mere portabel. LLaMA‑Factory sænker friktionen for hurtig eksperimentering på tværs af 100+ modeller.
Bag kulissen ligger også fejlhåndtering og reproducérbarhed. Jo dybere man afviger fra standardkerner, jo vigtigere bliver versionsstyring, tests og målepunkter. Den gevinst kan være det hele værd, men den kræver disciplin i build‑ og release‑processen.
Tre beslutningsmønstre der går igen
- Lang sekvens, stram GPU‑budget: Vælg Unsloth, når per‑step‑gevinster ved 4K–8K sekvenser kan omsættes direkte til kortere wall‑clock og lavere omkostninger. Husk at tallene i kilden for de største gevinster er egenrapporterede.
- Komplekse multi‑GPU‑kørsler og mange kombinationer: Axolotl egner sig, når orkestrering, YAML og integration med Accelerate/DeepSpeed er vigtigere end absolut single‑GPU‑rekord.
- Hurtige PoC’er på tværs af mange modeller: LLaMA‑Factory er genvejen til “få det til at køre nu” med UI og bred modelsupport. Brug det til at vælge retning, ikke til at jage sidste millisekund.
Multi‑GPU, VRAM og sekvenslængder
Artiklen beskriver, at memory‑besparelser for visse modeller kan stige med sekvenslængde, mens hastighedsgevinster kan flade ud eller variere. Det påvirker beslutningen om at blive på én GPU eller splitte ud over flere. Med nye GPU‑generationer i spil (B200, H100, RTX PRO 6000 nævnes i kilden) ændrer billedet sig igen — derfor er lokale tests uundgåelige.
Praktisk konsekvens: planlæg jeres tests efter realistiske kontekster, ikke bare 1K. Hvis jeres målprodukt kræver 8K, så mål 8K. Ellers risikerer man at optimere efter en profil, der ikke matcher virkeligheden.
Reproducerbarhed og en kort POC‑tjekliste
For at vurdere de rammer fair internt er en stram POC‑procedure nødvendig. Kilden giver pejlemærker, men ikke fuld standardisering på tværs af hardware og konfiguration. Brug derfor en fast skabelon og hold jer til den, når I sammenligner.
- Specificér model, sekvenslængde, batch, grad‑acc og adapter‑konfiguration (fx QLoRA‑rank).
- Fastfrys softwarestak: PyTorch, Transformers, TRL/PEFT, eventuel Triton‑/attention‑variant.
- Notér GPU‑generation og memory‑profil; mål throughput, per‑step tid, peak VRAM, og læringskurve.
- Marker tydeligt hvilke benchmarks, der er egenrapporterede, og hvilke I selv har reproduceret.
Bundlinjen
Valget af framework er et valg af kompromis. Unsloth søger topfart via kerneskrivning og rapporterer store gevinster ved lange sekvenser (kilden gengiver egenrapporterede tal som 7,3x per‑step ved 8K). Axolotl prioriterer komponerbarhed og skalerbar orkestrering. TRL er det fælles trænerlag, der holder tingene sammen. LLaMA‑Factory giver bred modeldækning og UI, som gør PoC’er hurtige at komme i gang med.
Det fornuftige næste skridt er ikke at diskutere tal på Slack, men at køre en kort, veldefineret POC med jeres egne data og realistiske sekvenser. Man opdager først forskellen, når man sidder med det i hænderne.
