In the Torchtune vs Unsloth choice, start with Unsloth for almost every new fine tuning project on one GPU. Unsloth is actively maintained, ships a desktop app, a Studio web UI and a Python Core library, and focuses on LoRA and QLoRA with lower memory use. torchtune is a PyTorch native recipe library that once covered SFT, DPO, PPO, GRPO and quantization aware training across one or many GPUs, but its repository states that development wound down in 2025 and that it is no longer actively maintained. Treat torchtune as a reference design or a freeze for an existing recipe, not as the stack for a new training pipeline.

This guide compares what each tool is for, how you run them, memory and hardware notes from their own docs, and when to reach for Axolotl or TRL instead. Facts were checked against the Unsloth docs and the torchtune repository on November 5, 2026. Nothing here was run first hand on this machine.

Torchtune vs Unsloth at a glance

ItemUnslothtorchtune
What it isFine tuning toolkit (Desktop, Studio, Core) with LoRA, QLoRA, RL and export helpersPyTorch native post training library with forkable recipes and YAML configs
2026 statusActively maintainedMaintenance mode (wound down in 2025)
Best fitSingle GPU (or small local) LoRA and QLoRA jobsReading or freezing older recipes; native FSDP style distributed work you already have
InterfacePython notebooks and scripts, desktop app, Studio UItune run CLI plus YAML configs and plain PyTorch recipes
Multi GPUStudio docs mention multi GPU setups; Core historically focused on one GPURecipes for one device, multi device and multi node (while the project was active)
LicenseDual: Apache 2.0 for Core, AGPL 3.0 for some Studio UI pieces (per the README)BSD 3 Clause
Parent stackBuilt on PyTorch, Transformers, PEFT and TRLBuilt as a first party PyTorch library

Status and licence wording come from the Unsloth README and the torchtune README. If you are still choosing a deep learning framework itself, see PyTorch vs JAX.

What Unsloth is

Unsloth packages local model running and fine tuning into three products, according to its requirements page: the Desktop app, the Studio web UI, and Unsloth Core (the original Python library). The fine tuning guide walks through LoRA, QLoRA, full fine tuning, preference methods and reinforcement learning (including GRPO and DPO), plus export paths such as GGUF for local runners.

The Core pitch is speed and memory on one device. The README claims about 2 times faster training with about 70 percent less VRAM and no accuracy loss relative to standard setups. Treat that as the vendor's own figure. The same page lists free Colab and Kaggle notebooks for common models. For the practical local path (data format, loss reading, GGUF export), see our guide to fine tuning an LLM locally. For when RL is worth it, see fine tuning an LLM with reinforcement learning.

Hardware floors for Core, from the requirements page: NVIDIA GPUs with CUDA capability 7.0 or higher (V100, T4, RTX 20 and newer, A100, H100 and similar). Studio training is documented for NVIDIA, AMD, Intel and Mac devices. Absolute minimum VRAM for QLoRA versus 16 bit LoRA is published by model size, for example about 6 GB QLoRA and 22 GB LoRA for an 8B model, and about 22 GB QLoRA and 64 GB LoRA for a 27B model. Longer context and larger batches raise those numbers. Our LoRA vs QLoRA guide explains the method tradeoff.

A typical Core install on Linux or WSL looks like creating a Python 3.11 to 3.13 environment and installing the package with your preferred torch backend, for example:

uv venv unsloth_env --python 3.13
source unsloth_env/bin/activate
uv pip install unsloth --torch-backend=auto

Then you load a model with FastLanguageModel, attach LoRA or QLoRA adapters, and hand the model to a TRL trainer. Unsloth's own notebooks are the safest templates for current APIs.

What torchtune is

torchtune was Meta's PyTorch native library for authoring LLM post training. The README describes hackable recipes for supervised fine tuning, knowledge distillation, DPO, PPO, GRPO and quantization aware training, with YAML configs and support for Llama, Gemma, Mistral, Phi and Qwen families while the project was active. You install it with pip install torchtune (it expects a recent stable PyTorch; the README cites 2.6.0 as the tested release at the time of writing) and drive jobs with the tune CLI:

tune run lora_finetune_single_device --config llama3_1/8B_lora_single_device

Distributed full fine tunes used torchrun style launchers through the same CLI. The design goal was readable PyTorch you could fork: little magic, native FSDP2 style scaling, and configs you could copy locally with tune cp.

That story changed in mid 2025. In issue 2883, The future of torchtune, the maintainers announced that active development was stopping immediately. Concretely they said torchtune would receive critical bug fixes and security patches during 2025, Discord and GitHub issues would stay open, and no new features would be added. The README banner now says the same thing: torchtune is no longer actively maintained, and development wound down in 2025. A later successor experiment (torchforge) was discussed in that thread; as of this writing, treat any successor status as something to verify on the PyTorch org pages before you depend on it.

So torchtune still installs, and existing recipes can still teach you how a clean PyTorch training loop looks. It is a weak bet for a new production pipeline that needs ongoing model support and bug fixes in 2026 and beyond.

How the workflows differ

Unsloth pushes you toward a short Python script or a notebook. You pick a Hugging Face model id (often an Unsloth dynamic 4 bit build), set load_in_4bit=True for QLoRA or keep 16 bit for LoRA, call get_peft_model, then train with TRL. Saving can mean a small adapter folder, a merge, or a direct GGUF export for Ollama and friends. Studio and Desktop wrap much of that for people who prefer a UI.

torchtune pushes you toward a named recipe and a YAML config. You download weights with tune download, optionally copy a config, override fields on the command line, and run. Memory knobs in the docs include packing, torch.compile, activation checkpointing, activation offloading and 8 bit AdamW. The README publishes example peak memory and tokens per second for Llama 3.1 sizes on specific GPUs; those are torchtune's own measurements from when the project was active, not a live head to head with Unsloth on the same day.

Neither workflow invents LoRA. Both sit on the same ideas as PEFT. The practical difference in 2026 is maintenance and packaging: Unsloth keeps shipping model guides and installers; torchtune does not add features.

Speed and memory: what the vendors claim

Do not treat blog screenshots as a universal ranking. Hardware, sequence length, packing and compile flags move the numbers.

  • Unsloth states about 2 times faster training and about 70 percent less VRAM than standard fine tuning setups, with no accuracy loss, on its README and marketing pages. Its requirements table is the useful planning artifact for VRAM floors by model size.
  • torchtune published detailed tables for Llama 3.1 and Llama 3.2 under fixed settings (for example batch size 2, packed sequence length 2048, compile on). One LoRA run of Llama 3.1 8B on a single RTX 4090 is listed at about 16.2 GiB peak and about 3083 tokens per second; QLoRA on the same card is listed at about 7.4 GiB and about 2413 tokens per second. Those figures describe torchtune, not Unsloth.

Third party writeups have compared the two on fixed GPUs, but results depend on the day and the commit. Prefer your own short smoke test on your card if both stacks still run for your model.

When to pick each (and when to pick neither)

Pick Unsloth when:

  • You are starting a new LoRA or QLoRA job on one NVIDIA GPU, or you want Studio or Desktop on a Mac or Windows box.
  • You want Colab notebooks, GGUF export and current model guides (Qwen, Gemma, gpt-oss and similar).
  • You care about ongoing fixes in 2026.

Pick torchtune only when:

  • You already have a torchtune recipe frozen in a repo and it still runs on your PyTorch version.
  • You are reading recipes as teaching material for how native PyTorch post training is structured.
  • You accept that no new features will land on that library.

Pick something else when:

  • You need YAML driven multi GPU or multi node experiment grids: look at Axolotl first.
  • You want maximum control inside Hugging Face trainers without Unsloth's wrappers: use TRL and PEFT directly.
  • You are on Apple Silicon and want the mlx native path: see mlx-lm notes inside fine tune an LLM locally.

Migrating off torchtune

If an older tutorial tells you to tune run ..., map the job to Unsloth or TRL like this:

  1. Keep the same base model id and chat template.
  2. Keep the same dataset rows (JSONL messages or the instruct columns you already have).
  3. Recreate LoRA rank, alpha, target modules, learning rate and max sequence length in Unsloth or a TRL SFTConfig.
  4. Train a short smoke run and compare loss curves and a handful of held out prompts before you throw away the old checkpoints.
  5. Export with the path you actually serve (adapter, merged weights or GGUF).

You do not need feature parity with every torchtune recipe. Most local jobs are SFT LoRA or QLoRA, which Unsloth and TRL cover well. Preference and GRPO flows are covered in Unsloth's RL docs and in our GRPO vs PPO explainer.

FAQ

Is torchtune still maintained?

No, not as an actively developed library. The torchtune README and issue 2883 say development wound down in 2025, with critical fixes only during that year and no new features. Prefer Unsloth, Axolotl or TRL for new work.

Is Unsloth better than torchtune?

For new single GPU fine tunes in 2026, yes in the practical sense: Unsloth is maintained and packaged for exactly that job. torchtune's distributed recipes were strong when the project was live, but a winding down library is a poor foundation for new pipelines. "Better" still depends on whether you need a UI, multi node YAML configs or raw TRL control.

Can I use torchtune and Unsloth together?

Not as one trainer. They are separate stacks. You can study a torchtune recipe and reimplement the same hyperparameters in Unsloth or TRL. Sharing a dataset and evaluation script across both is fine.

Does Unsloth support multi GPU training?

Studio documentation mentions multi GPU setups. Unsloth Core historically focused on single GPU speed and memory. If your bottleneck is a multi node cluster with many YAML experiments, evaluate Axolotl as well.

What license does each use?

torchtune is BSD 3 Clause per its README. Unsloth uses a dual model: Apache 2.0 for the core package and AGPL 3.0 for some optional Studio UI components, per the Unsloth README. Read the licence files for the components you ship.

Should I learn torchtune in 2026?

Only as historical or educational material. Learning LoRA concepts, PEFT configs and TRL trainers transfers to Unsloth and Axolotl. Investing weeks in the tune CLI for a greenfield project is a poor use of time given the maintenance notice.