Unsloth Studio vs LM Studio: Fine-Tuning Workbench or Model Runner? (2026)

Unsloth Studio vs LM Studio comes down to training. Unsloth Studio is an open-source web UI and desktop app, under AGPL-3.0, that fine-tunes, runs and exports open models. LM Studio is a free, closed-source app for downloading, chatting with and serving GGUF and MLX models. Choose Unsloth Studio to train or build datasets, LM Studio for the simplest model runner, or use both.

Both apps search Hugging Face, run GGUF models on llama.cpp and expose an OpenAI-style API, which is why they get compared. The split is upstream of inference: Unsloth began as a fine-tuning library, and Studio puts training, dataset building and export in the same window as chat. Facts below come from Unsloth’s documentation, GitHub repository and release notes, and from LM Studio’s documentation, terms and changelog, checked 14 October 2026, when Unsloth Studio was at v0.1.907-beta (13 October) and LM Studio at 0.4.26.

For when fine-tuning is worth the effort at all, see our fine-tuning explainer; for how LM Studio compares with server-grade engines, see the inference server comparison.

Unsloth Studio vs LM Studio at a glance

What Unsloth Studio is

Unsloth started as an open-source Python library for faster, lower-memory fine-tuning. On 17 March 2026 its team released Unsloth Studio as a beta: a no-code web interface for training, running and exporting open models locally. The project now ships in three forms:

• Unsloth Desktop, a native app for Windows (x64 and ARM64), macOS and Linux (.deb and AppImage), introduced on 11 August 2026 and described as the easiest way to install Studio.
• Unsloth Studio, the web interface you start with the unsloth studio command or run from the unsloth/unsloth Docker image.
• Unsloth Core, the code-based library and notebooks.

So the choice between Unsloth Studio and Unsloth Desktop is about packaging, not features: Desktop wraps the same Studio interface in a native app.

Beyond chat, Studio offers tool calling with code execution, web search and Deep Research, retrieval over your own files, MCP tools, image and video diffusion models, and Data Recipes, which build training datasets from PDF, CSV, DOCX or JSON files using NVIDIA’s NeMo Data Designer. Unsloth says Studio can run fully offline, collects no usage telemetry and records only the hardware details it needs for compatibility, such as GPU type.

The licence deserves a second look. The core library is Apache 2.0, but the Studio interface is AGPL-3.0, a copyleft licence written with network software in mind. Its section 13 says that if you modify the program, everyone who uses your modified version over a network must be offered its source. Running Studio unchanged is the common case; changing it and hosting it for colleagues is the case to clear with your legal team first.

Download Studio only from unsloth.ai or the unslothai/unsloth repository on GitHub, because searches for the name also surface unofficial mirrors and look-alike repositories.

Running models in each app

For plain inference the two overlap, with differences that matter once other people or programs are involved.

• Engines. Unsloth describes Studio as powered by llama.cpp and Hugging Face, and it also runs MLX models on Macs with Apple chips. LM Studio runs llama.cpp on macOS, Windows and Linux and adds Apple’s MLX on Apple silicon. Both pull GGUF files from Hugging Face.
• Sharing one machine. LM Studio’s llama.cpp engine batches parallel requests continuously, with Max Concurrent Predictions set to 4 by default. Studio’s accounts keep each person’s work separate while sharing a loaded model when settings match.
• API. Studio serves OpenAI Chat Completions and Responses, Anthropic Messages and a model list on whatever port it started on. Every request needs a sk-unsloth- key created under Settings > API, shown once and stored only as a hash. LM Studio listens on port 1234 with OpenAI-, Anthropic- and REST-style endpoints and asks for no authentication unless you switch on API tokens, available since 0.4.0.
• Tools. Unsloth’s README and LAN guide say server-side tools, including web search, Python and terminal execution, are on by default, and advise --disable-tools when you expose Studio. LM Studio has been an MCP host since 0.3.17 and warns that MCP servers can run arbitrary code, read local files and use your network.
• Network access. Starting Studio with -H 0.0.0.0 serves unencrypted HTTP to your network, while --secure publishes an HTTPS link through a free Cloudflare tunnel. LM Studio’s Serve on Local Network option binds beyond localhost, and its docs recommend turning on authentication when you use it.

Fine-tuning: what only Unsloth Studio does

LM Studio does not train models. Its own December 2025 guide to customising FunctionGemma does the training in an Unsloth notebook and only imports the finished file. Studio brings that whole workflow into one interface:

• Methods. LoRA, QLoRA, full fine-tuning and pretraining, reinforcement learning with GRPO, preference tuning with DPO, and FP8 training.
• Data. Data Recipes turn unstructured or structured files into training sets.
• Export. Trained models export to safetensors, or to GGUF for llama.cpp, vLLM, Ollama and LM Studio, and to formats such as NVFP4 and FP8.
• Speed claims. Unsloth says training is up to twice as fast with up to 70% less VRAM and no loss of accuracy. These are the vendor’s figures, so test them on your own model and data.

Memory decides what you can train. Unsloth’s requirements page lists these absolute minimums and warns that some models need more:

Platform support differs by task:

• Windows runs Studio without WSL, but training needs an NVIDIA GPU; Intel GPUs have a separate guide.
• Linux and WSL train on NVIDIA GPUs with drivers installed, with CUDA 12.4 or newer recommended and 12.8 or newer for Blackwell cards. AMD GPUs are supported through ROCm, including a dedicated Docker image.
• Macs run chat, training and MLX models in Studio, according to its install guide, although the requirements page for the code-only library still describes Apple silicon support as in progress.
• CPU-only machines get GGUF chat and Data Recipes, not training.

These are training figures; inference is sized differently, and our VRAM tier guide and GPU buying guide cover that side.

Unsloth Studio vs llama.cpp

These are layers, not rivals. llama.cpp is the MIT-licensed C/C++ engine behind the GGUF format, written without external dependencies, with backends ranging from CUDA, HIP and Metal to Vulkan, SYCL and CANN. Its llama serve command starts an OpenAI-compatible server with a built-in web UI.

Unsloth maintains its own fork of llama.cpp, publishes prebuilt llama.cpp releases in its repository, and lets you force the backend at install time by setting UNSLOTH_LLAMA_CPP_BACKEND to cpu, cuda, rocm, vulkan or auto. On top of the engine, Studio adds model search, chat, tools, training, datasets, export, accounts and remote access.

Run llama.cpp directly when you want the smallest footprint, exact control over server flags, or an edge device without Python. Use Studio when you want a graphical workbench or the same machine will also train models. If you want Studio for inference only, the installer accepts UNSLOTH_NO_TORCH=1 to skip PyTorch and run in GGUF-only mode.

Unsloth Studio install, update and default password

Native install

1. Run the installer. On macOS, Linux or WSL:

   curl -fsSL https://unsloth.ai/install.sh | sh

   On Windows, in PowerShell:

   irm https://unsloth.ai/install.ps1 | iex

2. Accept the prompt to start Studio on port 8888, or start it later with unsloth studio -p 8888, then open http://127.0.0.1:8888.

3. Create your password when Studio asks on first launch.

4. To update, run the same install command again. Developer installs update with git pull followed by ./install.sh --local.

Unsloth Desktop installs from a downloaded package, with brew install --cask unsloth on macOS, or with winget install --id UnslothAI.Unsloth -e on Windows.

Docker and the first password

Unsloth’s Docker guide runs Studio and JupyterLab in one NVIDIA container. Replace mypassword before you run it:

docker run -d --name unsloth --gpus all --ipc=host \
  --ulimit memlock=-1 --ulimit stack=67108864 \
  -p 8000:8000 -p 8888:8888 \
  -e JUPYTER_PASSWORD="mypassword" \
  -v "$PWD":/workspace/host \
  -v "$HOME/.cache/huggingface":/workspace/.cache/huggingface \
  -v unsloth-studio:/opt/unsloth-studio \
  unsloth/unsloth

Port 8000 serves Studio and port 8888 serves JupyterLab. NVIDIA hosts need driver 570.26 or newer and the NVIDIA Container Toolkit; AMD hosts use the unsloth/unsloth-rocm image.

There is no fixed default password. Studio’s user is unsloth, and its first password is generated and printed in the container logs:

docker logs unsloth

Sign in with it and choose a new password when prompted. If the generated password is never changed, Studio shuts down after UNSLOTH_STUDIO_BOOTSTRAP_TIMEOUT, 3,600 seconds by default, and needs a container restart. UNSLOTH_STUDIO_PASSWORD sets the first password instead, but only the first time the unsloth-studio volume is used. To reset it later:

docker exec unsloth unsloth studio reset-password --username unsloth

The reset also signs out every session and revokes API keys. JupyterLab has its own password, from JUPYTER_PASSWORD or generated into the same logs, and anyone who can sign in to JupyterLab can run any command in the container.

Before you expose either service:

• Published Docker ports listen on all interfaces, so on a shared or cloud host bind them to 127.0.0.1 or set UNSLOTH_STUDIO_SECURE=1.
• Studio and JupyterLab speak plain HTTP; never put them directly on the internet.
• The container runs as root and Studio’s tools can run commands inside it, so mount only folders you are happy for it to change.
• Values passed with -e, including passwords and tokens, are visible to anyone who can run docker inspect.

Using both: train in Unsloth, run in LM Studio

The two apps chain naturally, and LM Studio’s FunctionGemma guide follows this route:

1. Fine-tune in Unsloth Studio or an Unsloth notebook.

2. Export to GGUF. The guide notes that Unsloth writes Q8_0, F16 or BF16 directly; for a smaller file, merge the LoRA adapter into the base model and quantize it, for example to Q4_K_M.

3. Import the file into LM Studio, load it and start the server:

   lms import ./my-model.gguf
   lms load <model-key>
   lms server start

Choose the quantization deliberately. Dropping from 16-bit to 4-bit saves most of the memory but can cost accuracy on some tasks; our quantization trade-off guide and quantization explainer cover how to judge it.

Which one should you install?

If your goal is a desktop chat app rather than training, our Jan and LM Studio comparison is the closer match, and LM Studio’s new agent app is covered in our LM Studio Bionic guide.

How VDF AI fits

Once a model has been trained and tested on a workstation, putting it in front of employees raises new questions: who may call it, which company documents it may draw on, and what gets recorded about each request.

VDF AI is the governed on-premises platform for that stage. It runs on your own infrastructure, or as VDF AI Cloud, and provides governed agents and workflows, private RAG over company data and chat, with role-based access control on every plan, audit logs and, on-premises, native Microsoft Entra ID sign-in. It does not run, host or connect to Unsloth Studio or LM Studio.

The bridge is the model endpoint. Serve your exported GGUF model with Ollama, and VDF AI Router can register that Ollama endpoint as a model deployment, route requests to it next to approved cloud models, and keep all traffic on local models in air-gap mode. Licensing is explained on the pricing page.