The sequence for your first run in Unsloth Desktop: The default is 30 steps, so start tweaking from the second run

When you open the training screen, you'll see models, datasets, parameters, and configurations lined up. If you open the parameters, you'll find the learning rate, rank, and gradient accumulation. I know exactly how it feels to get stuck here.

I found out why you don't need to get stuck by reading the official documentation and the bundled source code. The moment you select a model, the default values for that specific model are loaded. Almost every model is set to run for just 30 steps.

So, for your first run, all you need to do is select a model and a dataset, then press Start Training. You can start tweaking things from the second run onwards. Below is the sequence I'm about to verify. Since I haven't run it yet, I don't have the duration or loss figures. The numbers were gathered from official documentation and the actual configuration files.

Let's get the versioning out of the way first. The latest version tagged in the changelog is v0.1.51-beta (July 29, 2026), and the Studio actually bundled is v0.1.701-beta. My article this morning mentioning 0.1.61-beta was outdated.

The screen is divided into five parts

The Japanese UI lists four steps: Model, Dataset, Parameters, and Configuration. However, the internal definition consists of five stages: Model Type / Model / Dataset / Parameters / Summary, with model selection split into type and model. I couldn't determine from the code alone whether the actual screen displays four or five items.

You decide the type, choose the model and method, select the data, review the parameters, and then confirm to start. The default values are loaded at the second step, the moment you finalize the model.

Choose models by badge, not by table

There is an official VRAM table. For QLoRA (4bit), it's 3.5GB for 3B, 5GB for 7B, 6GB for 8B, and 41GB even for 70B. The LoRA (16bit) side jumps significantly: 8GB for 3B and 164GB for 70B.

However, the minimum row in this table is 3B. It doesn't list 1B, 2B, or 4B. Moreover, it is prefaced as an 'absolute minimum'.

The screen itself is more practical. Each model in the model selection list displays a `Needs ~XGB VRAM (GPU: YGB)` badge, and those that are risky are marked `Tight`, while those that won't fit are marked `OOM`. Since this is an estimate based on your actual GPU, it's faster than the table.

(Screenshot 1: Model selection list. Showing the `Needs ~XGB VRAM (GPU: YGB)` badge for each model, along with `Tight` or `OOM` badges simultaneously. To convey that you can choose just by looking here without checking the table)

There are four methods. The documentation only lists three

The Training Methods are QLoRA, LoRA, Full fine-tune, and Continued pretraining. While the official documentation table only lists the first three, the implementation includes CPT.

QLoRA uses 4-bit quantization for minimal VRAM, LoRA uses 16-bit adapters for a balanced approach, and Full fine-tuning updates all weights and consumes the most. For your first run, QLoRA is fine. There's nothing to worry about.

(Screenshot 2: Model Type (Text / Vision / Audio / Embeddings) and Training Method selection screen. Showing all four options: QLoRA / LoRA / Full fine-tune / Continued pretraining. I want to show that there is a fourth option not mentioned in the official documentation)

The bundled dataset combinations are the fastest way to start

There is no tutorial for a minimal configuration in the official documentation. Instead, two configuration YAML files that work out of the box are included. They contain the combination of `unsloth/Qwen2.5-0.5B` and `tatsu-lab/alpaca`.

If you open the Hub search bar while it's empty, a curated list will appear. The first one is `unsloth/alpaca-cleaned`. If you're unsure, just go with that.

For your own data, there are three formats. Alpaca requires `instruction` and `output`, with `input` being optional; ShareGPT uses `conversations` where `from` and `value` alternate between human and gpt; ChatML uses `messages` where `role` and `content` alternate between user and assistant. This is what it looks like when flattened into a single line of JSONL.

{"instruction": "...", "input": "", "output": "..."}

However, there is no official example of this single-line format itself. What is provided are formatted JSON fragments, and the format above is what I assembled based on those and the implementation's column requirements. You will have to verify if it's correct by checking if the column mapping dialog displays "Looks good".

The official guideline is a minimum of 100 lines, preferably 1000 lines or more. PDF and DOCX files cannot be uploaded directly to the training tab; you are told to use Data Recipes instead.

You don't need to touch the parameters

This is the point I most want to emphasize this time. The official documentation itself states, "When you select a model, settings are retrieved from the backend, and reasonable default values are pre-filled for all hyperparameters."

The reality of this lies in the YAML files under `model_defaults/`. Out of 78 total files, 75 have `max_steps: 30` and `num_epochs: 0`. The remaining ones include two with 50 and one with 60. Regardless of which model you choose, a setting to run for only 30 steps is entered first.

The maximum number of steps and the number of epochs are mutually exclusive; setting one to 0 yields to the other. The tooltip for the number of epochs also states, "If set to 0, it will execute based on the maximum number of steps." The default is set to the steps side.

Another thing is that the parameter screen has a toggle between "Simple" and "Advanced". Since the default is Simple, not all items are visible from the start. Switch to Advanced when you want to check everything.

(Screenshot 3: Parameter screen. Showing the toggle between "Simple" and "Advanced", with the maximum number of steps readable as 30. A shot showing that 30 is entered even though nothing has been touched.)

Even so, you should take a look at the contents

Default values you should look at at least once before pressing start. These are the values from default.yaml, which may be overwritten depending on the model.

• Context length 2048

• Learning rate 2e-4 (The screen lists 5e-5 for CPT and 2e-5 for full as recommended values)

• Rank 16, Alpha 16 (The tooltip says "usually twice the rank")

• Batch size 2, Gradient accumulation 4

• Optimizer AdamW 8-bit, Seed value 3407

• Gradient checkpointing unsloth

There is one pitfall. The Eval Steps interval is not the number of steps, but a ratio from 0 to 1 relative to the total steps. The tooltip even gives an example: "0.01 = run evaluation every 1% of steps." If you enter 100 here, something different from your intention will happen.

The item previously called "Train on Completions" has been renamed to "Train on assistant response only". You won't find it if you search by the old name. While values for W&B and TensorBoard remain, I could not confirm if the Logging tab appears in the current UI.

Look at Run preview before Start Training

There is a card labeled "Run preview" before the Start button. It lists Total steps, Batch, Context, LR, and Hardware; if a GPU is not found, it will display "No GPU detected".

You only need to check the total number of steps. If it says 30, it is a short run as intended.

As far as I have searched, there is no official estimate for "how many minutes it will take." You have to estimate it yourself based on the number of steps and the "steps/sec" shown on the progress screen.

(Screenshot 4: The Run preview card right before Start Training. With Total steps, Batch, Context, LR, and Hardware all clearly visible. Make it clear that this is the only thing you need to check before pressing the button.)

There are two things to know about while it is running and how to stop it.

Once training begins, the progress, Loss, LR, Grad Norm, elapsed time, and remaining time (ETA) are displayed. The GPU monitor on the right shows usage, temperature, VRAM, and power, updating every few seconds.

There are four types of charts: Training Loss, Learning Rate, Gradient Norm, and Evaluation Loss, which only appears if you have set an evaluation split. If not set, it simply displays "Set eval dataset & eval_steps to track eval loss".

It is worth remembering the difference in how to stop. "Stop & Save" writes a checkpoint that can be resumed later, whereas stopping without saving means it cannot be resumed. The resume function in the History tab only works for runs where a checkpoint remains.

(Screenshot 5: The entire screen during training. Showing the GPU monitor's usage, temperature, VRAM, and power, along with the four live charts simultaneously. Ensure the Stop & Save and Cancel buttons are also within the frame.)

If an OOM occurs, start with the batch size.

There is only one point where the official documentation is explicit: "The cause of OOM is that the batch size is too high. Setting it to 1, 2, or 3 will reduce VRAM usage."

Compensate for the reduction by increasing gradient accumulation. This is also an official instruction, aimed at reducing VRAM while maintaining the effective batch size. Since gradient checkpointing is the recommended default in `unsloth`, do not disable it.

"Lowering the context" should also be effective, but I could not find any official documentation explicitly stating this as a countermeasure for OOM. I distinguish it as a general theory.

There are three ways to export.

Merged Model is a 16-bit model with the adapter merged into the base weights, intended for when you want to load it directly into vLLM or TGI. LoRA Only is just the adapter, around ~100 MB, used in combination with the base model. GGUF / Llama.cpp is for llama.cpp, Ollama, and LM Studio.

When you select GGUF, Quantization Levels appear. There are 12 types of quantization, with a recommendation mark on `Q4_K_M`. If you select multiple, a file will be generated for each. Selecting low-bit IQ types forces the imatrix toggle on, which can also be used to improve quality in standard quantization.

The Merged side also has precision options, listing FP8 and INT4 types in addition to 16-bit. Most of these are for NVIDIA environments and vLLM. There is no explicit documentation on where the exported files go; you select the save destination during the export process.

(Screenshot 6: The Export screen. Showing the three methods: Merged Model / LoRA Only / GGUF, the list of Quantization Levels (with the recommendation mark on Q4_K_M), and the imatrix toggle. I want to show that there are three exits and that multiple quantizations can be selected.)

Compare in Chat to see if it worked.

When training finishes, a toast notification appears. It says, "Next step: Compare the base model with the fine-tuned output," and includes a "Compare in chat" button.

The Model Arena in Chat is a feature that throws the same prompt at two models to compare them side-by-side, and the official documentation suggests using this to compare before and after training. The final step of the Export guide is also 'Test by comparing outputs in Chat.' There is no visible feature for automatic scoring, so the official answer is to compare them visually.

(Screenshot 7: Toast notification upon completion of training. With the 'Compare in Chat' button visible. To show that this is the flow immediately after training finishes)

The most common trouble is the chat template

It works fine within Unsloth, but the results break when exported and taken to another environment. Symptoms include garbled text, never-ending generation, or repeating the same output. The official documentation lists four causes.

Applying a different chat template than the one used during training. The eos token is incorrect. The inference engine is adding an extra start token, or conversely, not adding one. It also states that you can usually fix this by forcing the template in the conversation notebook.

I think the most practical workaround is to use models in the `unsloth/` namespace. Errors can sometimes be included in the `chat_template` at the time of the original upload, and Unsloth states that they inspect and fix them every time they upload a quantized version. This also aligns with why all recommended models start with `unsloth/`.

The current state of Mac, CPU, and AMD/Intel

In this morning's article, I wrote that 'official documentation for Apple Silicon is inconsistent.' That was due to a difference in scope. The requirements page states that for Mac, it 'supports training, MLX, and GGUF inference.' The version being developed is the code-based `pip install` version.

There are limitations on the MLX side. Streaming is not supported, and some LoRA variants cannot be used on Apple Silicon.

Only Chat and Data Recipes can be done with CPU alone. Training is not included in the list. For AMD and Intel, training on Studio was officially supported in v0.1.51-beta (July 29, 2026).

Once you've run it once, change it on the second run

I don't believe the first 30 steps are for checking the quality of the training. It's for checking if the download works, if the mapping is correct, if there is enough VRAM, and if it can reach the export stage. It's a check of the path.

For the second run, start by setting the maximum steps to 0 and switching to the number of epochs. Add an evaluation split to get the evaluation Loss, and adjust the batch size and gradient accumulation to match your local GPU. Rank and Alpha come after that.

I'd like to hear if anyone has felt any change with the default 30 steps. I also want to know from how many lines the default settings become insufficient. If you got stuck, please let me know in the comments at which step you gave up.

#Unsloth #UnslothDesktop #FineTuning #LoRA #QLoRA #LocalLLM #LLM #GGUF #llamacpp #MachineLearning #AI