Unsloth, Axolotl, LLaMA-Factory and mlx-lm: Higher-Level Tools

By the end of this lesson you will be able to pick a fine-tuning tool for your platform and your task with a reason you can defend, say what each one adds on top of the reference recipe, and state what its own documentation supports on your hardware and on what date you read it. That last part is the one that changes fastest and the one nobody writes down.

Everything in this lesson sits on top of the same libraries. Underneath the configuration file, the notebook and the fused kernel there is still transformers holding the model, peft holding the adapter and, in most cases, trl holding the trainer. The tools differ in what they replace.

What each tool replaces

higher-level, fewer decisions

1. PyTorch or MLXTensors, autograd, the device. Part 11 installed this for your track.always there
2. transformers, datasets, peftThe architecture, the tokeniser and chat template, the adapter.
3. trl: SFTTrainerThe named method, the dataset shapes, the loss masking. The reference recipe stops here.
4. UnslothReplaces parts of the layers below with fused kernels and a quantised loading path, keeping a TRL-compatible surface.
5. Axolotl, LLaMA-Factory, NeMo AutoModelReplace the script with a YAML file and a command, and add methods, distributed launchers and export steps.
6. mlx-lmA separate stack, not a layer: MLX rather than PyTorch, with its own trainer and its own data format. Track M only.

A tool higher in the stack removes decisions and adds an opinion. When something breaks, the diagnosis usually happens one or two layers below where you were working, which is why the reference recipe is worth understanding even if you never run it directly.

Unsloth

Unsloth’s pitch is speed and memory on one GPU. Its documentation home page claims that it lets you “Train LLMs, diffusion, TTS, and embedding models 2× faster with 70% less VRAM with no accuracy loss”, and TRL’s own page describes it in similar terms, as training models “up to 2× faster with up to 70% less VRAM, while providing a streamlined, Hugging Face–compatible workflow”. Both are claims by the projects concerned rather than measurements this course has made; the honest version for your machine comes from running the same fine-tune both ways and comparing wall-clock and peak memory, which is an exercise the lab leaves open.

The mechanism is worth knowing because it explains the limits. Unsloth replaces parts of the attention and loss computation with hand-written kernels and changes how a quantised base is loaded, while keeping an interface close enough to transformers and trl that a recipe ports with small edits. That is why it is fast, why its coverage is model-family by model-family rather than universal, and why a brand-new architecture reaches TRL before it reaches Unsloth.

Installation, from its pip page: uv venv unsloth_env --python 3.13, then uv pip install unsloth --torch-backend=auto, or plain pip install unsloth. The same page notes that vLLM can be installed alongside it with uv pip install unsloth vllm --torch-backend=auto, which matters more in Part 14 than here.

Per track, as the documentation stated it on 2026-09-09. The home page says “Unsloth supports MacOS, Linux, Windows, NVIDIA, AMD, Intel and CPU setups”, and the per-platform pages qualify that considerably.

• Track S. Supported and specifically documented. Unsloth publishes a DGX Spark guide built around a Docker image FROM nvcr.io/nvidia/pytorch:25.09-py3, built with docker build -f Dockerfile -t unsloth-dgx-spark . and run with --gpus=all. Note what the guide pins inside that image: bitsandbytes==0.48.0 transformers==4.56.2 trl==0.22.2, which are older than this course’s transformers 5.16.1 · verified 2026-09-08 and TRL 1.12.0 · verified 2026-09-08. A recipe written against one set will not necessarily run against the other, and the guide’s pins are the ones its examples were tested with.
• Track X. Treat as unconfirmed for this chip. Unsloth’s AMD page states that “Unsloth supports AMD Radeon RDNA 3/3.5/4 (RX 6000–9000 series) on both Windows and Linux as well as data center GPUs including the MI300X (192GB)”, with “ROCm 6.0 or newer is required” and installation through uv pip install unsloth[amd]. The Ryzen AI Max+ 395’s integrated Radeon 8060S is an RDNA 3.5 part, but the page names the discrete RX series and the MI300X and does not name Strix Halo, gfx1151, the Ryzen AI Max family or the 8060S anywhere, as read on 2026-09-09. So this course’s Track X path is TRL and PEFT on ROCm PyTorch, with Unsloth as something to try and record rather than something the page tells you to expect.
• Track M. Not the Python training path. Unsloth’s macOS page is about Unsloth Desktop, a downloadable application “to run and train MLX or GGUF models on your Mac”, and an unsloth studio browser interface. That is a different product from the library the other three tracks install, and this course’s Mac training path stays mlx-lm.
• Track N. The primary target, and the one every published notebook assumes. Unsloth’s notebook index lists Qwen3 fine-tuning notebooks from Qwen3-4B up to Qwen3-32B, including the 30B-A3B mixture of experts, and states that the smaller ones run on Colab’s free tier while the largest need “Colab subscription or credits”. Those notebooks are the fastest way to read a complete Unsloth recipe for a model this course uses.

✱Hardware note

The DGX Spark guide is also the clearest published statement of what a 128 GB unified-memory machine can fine-tune. It reports that gpt-oss-20b was trained with reinforcement learning on a DGX Spark, and that “gpt-oss-120b QLoRA 4-bit fine-tuning will use around 68GB of unified memory”, which is a figure reported by Unsloth rather than one measured here. Check it against Part 11’s arithmetic before you believe either: 117 billion parameters at roughly 0.55 bytes each is about 64 GB for the frozen base alone, so the two are consistent, which is a reassuring thing to be able to say about a vendor’s number.

Axolotl

Axolotl describes itself as “a free and open-source tool designed to streamline post-training and fine-tuning for the latest large language models (LLMs)”, and its distinguishing idea is that the whole pipeline is one file: “Re-use a single YAML configuration file across the full fine-tuning pipeline: dataset preprocessing, training, evaluation, quantization, and inference.”

That is a real advantage once you are running more than one experiment. The configuration is a diffable artefact, it goes in version control next to the run log, and the difference between two runs is a diff rather than a memory. It is the tool to reach for when the question is “which of these six settings mattered”.

The documented quickstart is axolotl fetch examples followed by axolotl train examples/llama-3/lora-1b.yml. The methods list covers “Full fine-tuning, LoRA, QLoRA, GPTQ, QAT (int8/int4/FP8/NVFP4/MXFP4), FP8 mixed-precision training” alongside preference methods. Requirements as documented: Python 3.11 or newer, PyTorch 2.11.0 or newer, and hardware stated as “NVIDIA GPU (Ampere or newer for bf16 and Flash Attention) or AMD GPU”. Axolotl 0.18.0 · verified 2026-09-08 is the pin this course records. Note the Ampere qualification: it is a statement about BF16 and Flash Attention rather than about the tool refusing to start, and it is the reason older cards on Track N should expect to train in float32 and slowly.

LLaMA-Factory

LLaMA-Factory is the broadest of the four in methods and the friendliest for someone who would rather not write Python at all. Its README lists “Full-tuning, Freeze-tuning, LoRA, QLoRA, OFT, QOFT” across pre-training, supervised fine-tuning, reward modelling and the preference family including PPO, DPO, KTO, ORPO and SimPO, which makes it a single tool that spans this part and Part 14.

Four command-line entry points do the work: llamafactory-cli train for a run, llamafactory-cli webui for the Gradio interface, llamafactory-cli chat for inference against the result, and llamafactory-cli export for merging a checkpoint and exporting it. Each takes a YAML configuration in the same spirit as Axolotl’s. The project is Apache-2.0 licensed, with the README noting that the models you use carry their own terms.

On hardware the README documents NVIDIA GPUs as the primary path with CUDA 12.2 recommended, a dedicated Ascend NPU path with pre-built Docker images, and an AMD ROCm Docker composition. The web interface is worth a mention for a specific reason: it is the fastest way to see every knob a trainer has, laid out, which makes it a good teaching tool even for readers who will run the CLI. LLaMA-Factory 0.9.5 · verified 2026-09-08 is the pin here, and NVIDIA lists the project among its DGX Spark fine-tuning playbooks.

NeMo AutoModel

NVIDIA’s entry, and the one to know about if your Track S or Track N machine is a step towards something larger. The documentation describes it as “a PyTorch DTensor-native SPMD open-source training library for scalable LLM and VLM training and fine-tuning with day-0 Hugging Face model support”, and the claim that distinguishes it is scale continuity: “PyTorch-native training that scales from 1 GPU to thousands with a single config change.”

It is “built on transformers for day-0 model support”, so a model that loads in the reference recipe loads here, and it supports LoRA for the case where “you want to fine-tune on limited GPU memory; updates <1% of parameters”, which is the same half-a-per-cent figure the adapter arithmetic gives. Installation is documented as uv pip install nemo-automodel, with Docker and source paths alongside, and launching on a local workstation or a SLURM cluster.

For a single machine it buys you little over TRL. It becomes the right answer when the same configuration has to run on one GPU today and eight tomorrow, which is where Part 18’s parallelism material picks the thread up.

mlx-lm on the Mac

Track M’s path is not a wrapper around the others; it is a different stack. MLX rather than PyTorch, its own trainer, and its own data layout.

The essentials from the LoRA documentation. A run is mlx_lm.lora --model <path_to_model> --train --data <path_to_data> --iters 600. Fine-tuning type is --fine-tune-type, documented with lora as the default and dora and full as the alternatives, which makes DoRA a one-word change here. --num-layers controls how many layers are adapted, with a documented default of 16, and it is the memory knob: fewer layers, less memory, less capacity. --mask-prompt computes “loss only for completions”, which is the equivalent of TRL’s completion_only_loss. Evaluation is --test with --adapter-path, and a run can be continued with --resume-adapter-file.

The data layout is three files in a directory: train.jsonl required, valid.jsonl optional and test.jsonl for evaluation, in one of three shapes documented as chat ({"messages": [...]}), completions ({"prompt": ..., "completion": ...}) or text ({"text": ...}), with chat templates applied for the first two. Those are the same three shapes TRL accepts, under slightly different names, so one dataset generator can serve both paths, which is what this part’s lab does.

Export is a separate command, mlx_lm.fuse, which takes --model, --adapter-path and --save-path (defaulting to fused_model), and can additionally --upload-repo to the Hub, --dequantize to produce a dequantised model, or --export-gguf with --gguf-path. The GGUF export is documented as supporting a limited set of architectures in fp16, so on the Mac the reliable route to llama.cpp is to fuse and then convert with llama.cpp’s own converter, which the export lesson covers. mlx-lm 0.31.3 · verified 2026-09-08 is the pin.

Tools this course does not teach

Two, and the reason in each case is maintenance rather than quality.

torchtune. PyTorch’s own fine-tuning library, widely recommended in material written in 2024 and 2025, and a genuinely good design. Its repository now carries a notice at the top: “⚠️ Torchtune is no longer actively maintained: torchtune development wound down in 2025”. As read on 2026-09-09 the repository is still public and not marked read-only, and it names no successor. A course that pins versions cannot teach a library whose pin will not move, so torchtune is named here and not used, and a reader who meets a torchtune recipe should port it to TRL rather than install it.

AutoAWQ. The library most tutorials name for producing AWQ checkpoints. vLLM’s own AWQ page now states plainly that “The AutoAWQ library is deprecated” and points at llm-compressor for the same job. The export lesson in this part uses llm-compressor accordingly.

The general rule is worth stating because it will apply again: a tool’s last release date is part of its documentation. Check it before you build a pipeline on top of something, and record the date you checked, because “unmaintained” is a fact with a timestamp.

Choosing

If you are…	Use	Because
Learning what the settings do	TRL and PEFT directly	Every layer above hides something you are trying to see, and every error message you get is one layer from the cause.
On Track M	mlx-lm	It is the only path that uses the Mac GPU for training, and DoRA is one flag away.
Short of memory on Track S or N	Unsloth	Its whole design goal is memory and speed on one accelerator, and it has a documented DGX Spark path.
Running many experiments	Axolotl or LLaMA-Factory	One YAML file per run, diffable and committable, is a better experiment record than a script you edited.
Spanning SFT and preference methods	LLaMA-Factory	One tool covers this part and Part 14, with the same configuration shape.
Planning to scale past one machine	NeMo AutoModel	The same configuration is documented to run from one GPU to many.
On Track X	TRL and PEFT on ROCm, and try Unsloth	The documentation for the higher-level tools does not name this chip, so anything that works here is a finding worth recording with its date.

∴Research note

Whichever you choose, the measurement does not change. Every one of these tools produces an adapter or a merged model, and the question asked of all of them is the same: what does the Part 10 harness say, compared with the base model, at the same settings, on the same tasks. A tool that trains twice as fast and scores the same has saved you time; a tool that trains twice as fast and scores lower has not.

Compare recipes by their resolved configuration

Different training tools can expose the same idea under different configuration names, and can choose different defaults for packing, loss masking, optimiser, precision and checkpoint selection. Translating a recipe requires comparing the resolved behaviour, not just matching learning rate and rank.

Create a small translation table: dataset format, rendered prompt, supervised tokens, target modules, effective batch, sequence length, optimiser and saved artefact. Run the same tiny subset through each candidate and inspect a batch before comparing loss. If one tool trains on the whole conversation and another only on the completion, the losses do not measure the same objective.

Choose a tool partly by the artefact you need afterwards. An adapter, fused checkpoint and engine-specific quantised model have different deployment paths. Verify export and a basic served request early, before a long run. A tool’s speed claim is relevant only when your architecture, hardware, precision and training settings use the supported path. Keep the simpler working recipe as a control when experimenting with accelerated implementations.

Recap

All of these tools sit on the same foundation, and they differ in which layer they replace. Unsloth replaces kernels and the quantised loading path for speed and memory, with a documented DGX Spark guide whose pinned versions are older than this course’s, an AMD page that names RDNA 3/3.5/4 RX cards and the MI300X but not the Ryzen AI Max+ chip as of 2026-09-09, and a macOS product that is a desktop application rather than the library. Axolotl and LLaMA-Factory replace the script with a YAML configuration, the first with a single file spanning the whole pipeline and the second with the broadest method list and a web interface. NeMo AutoModel is NVIDIA’s PyTorch-native library built on transformers, whose argument is that one configuration scales from one GPU to thousands. mlx-lm is a separate stack for the Mac, with --fine-tune-type covering LoRA, DoRA and full, --num-layers as the memory knob and mlx_lm.fuse for export. torchtune is no longer maintained and AutoAWQ is deprecated, so the course names both and uses neither. And the tool never changes the measurement.

Check your understanding

Question 1. A reader on a Ryzen AI Max+ 395 asks whether Unsloth supports their machine. What is the accurate answer as of 2026-09-09?

• Yes, it is listed explicitly
• The AMD page names RDNA 3/3.5/4 RX 6000–9000 cards and the MI300X and requires ROCm 6.0 or newer, but does not name Strix Halo, gfx1151 or the integrated Radeon 8060S, so it is worth trying and recording rather than assuming
• No, AMD is not supported at all
• Only through Unsloth Desktop

Show the answer and why

Answer: The AMD page names RDNA 3/3.5/4 RX 6000–9000 cards and the MI300X and requires ROCm 6.0 or newer, but does not name Strix Halo, gfx1151 or the integrated Radeon 8060S, so it is worth trying and recording rather than assuming

The chip is an RDNA 3.5 part, and the page names RDNA 3.5, but by discrete RX series and data-centre parts rather than by this integrated GPU. That gap is exactly the kind of thing to state with a date rather than resolve by inference, and the course keeps TRL on ROCm as Track X's primary path.

Question 2. Why does this course name torchtune and then not teach it?

• It is proprietary
• Its repository states that development wound down in 2025 and that it is no longer actively maintained, so a course that pins versions cannot build on it
• It does not support LoRA
• It only runs on TPUs

Show the answer and why

Answer: Its repository states that development wound down in 2025 and that it is no longer actively maintained, so a course that pins versions cannot build on it

The library is well designed and widely cited in older material, which is precisely why a reader needs to be told its status and its date. A torchtune recipe should be ported to TRL rather than installed.

Question 3. Which mlx-lm flag makes the loss apply only to the completion, matching what completion_only_loss does in TRL?

• --fine-tune-type
• --mask-prompt
• --num-layers
• --test

Show the answer and why

Answer: --mask-prompt

The LoRA documentation describes --mask-prompt as computing loss only for completions. --num-layers is the memory knob, --fine-tune-type chooses between lora, dora and full, and --test runs evaluation with an adapter attached.

Question 4. You want one artefact per experiment that can be committed and diffed. Which tools are designed around that?

• Axolotl, whose documentation describes reusing a single YAML file across preprocessing, training, evaluation, quantisation and inference
• LLaMA-Factory, whose CLI entry points take YAML configurations
• A hand-edited training script
• The Unsloth notebooks

Show the answer and why

Answer: Axolotl, whose documentation describes reusing a single YAML file across preprocessing, training, evaluation, quantisation and inference, LLaMA-Factory, whose CLI entry points take YAML configurations

A configuration file is a record; an edited script and a notebook are both states you have to remember to capture. That is the main practical argument for the configuration-driven tools once you are past the first experiment.

Question 5. Unsloth's DGX Spark guide pins bitsandbytes 0.48.0, transformers 4.56.2 and trl 0.22.2 inside its Docker image, which are older than the versions this course pins. What follows?

• The course pins are wrong
• A recipe written against one set will not necessarily run against the other, and the guide's examples were tested with its own pins
• The Docker image cannot be used
• Nothing; versions do not affect training

Show the answer and why

Answer: A recipe written against one set will not necessarily run against the other, and the guide's examples were tested with its own pins

Both sets are internally consistent and neither is wrong. Training APIs move quickly enough that the version a recipe was written against is part of the recipe, which is why every run log in this course records the installed package versions.

Check my answersClear