How to Fine-Tune Qwen 3.8 27B with Unsloth: Hardware, Setup, and Export (2026)

The first frontier-family model you can fine-tune on hardware a small team can actually rent.

Qwen 3.8 27B's weights landed on August 13, and Unsloth shipped official support the next day: run it, quantize it, or fine-tune it. That last part is the interesting one. A dense 28B model under Apache 2.0, with benchmark results that were frontier-class a month ago, is now something you can specialize on your own data without a cluster.

This guide covers what fine-tuning this model actually requires: the hardware, the QLoRA setup, the data question, and how to get the result back out into a serving stack. If you just want to run the model unmodified, that's a different (and easier) job, covered in our local setup guide and Ollama guide.

Why This Model Is Worth Fine-Tuning

Three reasons this release is a better fine-tuning target than most of what dropped this year:

• It's dense. 28B parameters, no mixture-of-experts routing. Dense models are simpler to fine-tune, simpler to reason about, and the tooling is mature. Most other frontier-class open releases this year (Kimi K3, DeepSeek V4 Flash, the 2.4T Qwen checkpoint) are MoE giants you can't realistically train on rented single-node hardware.
• The license is Apache 2.0. The adapter you train and the merged model you produce are yours, commercial use included. No revenue clauses, no attribution requirements that surprise your legal team later.
• The base is strong. The model card reports 61.7 on SWE-bench Pro and 84.3 on OSWorld, with a native vision encoder and 256K context. You're specializing a genuinely capable base, not compensating for a weak one.

Full specs and the VRAM math by precision are in our 27B hardware guide.

What Unsloth Support Means

Unsloth's v0.1.800 beta release (August 14) added Qwen 3.8 27B across the board: local inference through their Dynamic GGUF quants, an NVFP4 variant they report runs about 1.5x faster than BF16, and fine-tuning support. Unsloth's general pitch applies here: roughly 2x faster training with about 70% less VRAM than a stock Hugging Face setup, which is the difference between "needs a multi-GPU node" and "fits on one big card."

The official model uploads live at unsloth/Qwen3.8-27B and unsloth/Qwen3.8-27B-GGUF. Install is one line:

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

One honest caveat before the setup: this support is days old as of this writing (August 18, 2026). There's no official Unsloth notebook for the 27B yet, and the fine-tuning docs for this specific model are still thin. The setup below follows Unsloth's standard pattern, but expect their docs to firm up over the coming weeks, and check them before a long training run.

The Hardware Question

Two different budgets here, and mixing them up is the most common planning mistake.

Running the model (inference) with Unsloth's quants:

Fine-tuning costs more than running, because you're holding gradients, optimizer state, and activations on top of the weights. Unsloth hasn't published official training VRAM numbers for the 27B yet, so treat these as practical planning figures rather than spec sheet values:

• 24 GB (RTX 4090 class): the floor for QLoRA at short context and small batch. Workable for experiments, tight for real runs.
• 48 GB (RTX 6000, L40S class): the comfortable single-card QLoRA zone. Room for longer sequences, bigger batches, higher LoRA rank.
• 80 GB (H100, H200, A100 class): LoRA on top of 16-bit weights, long-context training, or QLoRA with headroom to spare.

Full fine-tuning (updating all 28B parameters) is a multi-GPU job and out of scope for this guide; for almost every real use case, LoRA or QLoRA gets you the behavior change at a fraction of the cost.

The QLoRA Setup

The standard Unsloth pattern, pointed at the 27B:

from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    "unsloth/Qwen3.8-27B",
    max_seq_length=4096,
    load_in_4bit=True,
)

model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    lora_alpha=16,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                    "gate_proj", "up_proj", "down_proj"],
)

From there it's a normal TRL SFTTrainer loop over your dataset. The settings that matter most in practice:

• max_seq_length drives memory harder than anything else. Set it to your real data's length, not the model's 256K ceiling.
• r (LoRA rank) of 16 is a sane default. Higher rank captures more, costs more VRAM, and overfits faster on small datasets.
• load_in_4bit=True is what makes this fit on a single card. Drop it only if you're on 80GB+ and want LoRA on 16-bit weights.

The Data Question

The part that decides whether this works has nothing to do with GPUs. Fine-tuning teaches the model behavior: your output format, your tone, your domain's conventions, your tool-call patterns. It is bad at injecting knowledge; if the goal is "answer questions about our internal docs," you want retrieval, not fine-tuning.

For behavior changes, quality beats volume. A few hundred to a few thousand carefully curated examples routinely outperform tens of thousands of scraped ones. If you can't explain what pattern each example teaches, it probably shouldn't be in the set.

Exporting the Result

Three ways out, depending on where the model is going:

• Keep the adapter. LoRA weights are small (megabytes, not gigabytes). Load them on top of the base model at inference time; easiest for iterating.
• Merge to 16-bit for serving with vLLM or SGLang. This is the production path; the engine choice is covered in vLLM vs SGLang, and the deployment shape in our Qwen 3.8 production guide.
• Export to GGUF for Ollama or llama.cpp if the destination is local machines.

One inference note for whatever you serve: Qwen publishes distinct sampling settings for the 27B's thinking mode (temperature 1.0, top_p 0.95) versus instruct mode (temperature 0.7, top_p 0.80, presence penalty 1.5). Your fine-tune inherits that machinery, so carry the right settings into your serving config.

Where to Run the Job

Fine-tuning runs are measured in hours, which changes the buy-versus-rent math completely. A 48GB or 80GB card you need for six hours is a rental, not a purchase.

Yotta GPU Pods rents exactly this range by the hour: RTX 6000 and L40S for the QLoRA sweet spot, H100 and H200 when you want long context or faster iterations. Spin up, train, export the adapter, shut down. The same pod then serves the merged model with vLLM if you want to eval it in place.

Frequently Asked Questions

Can I fine-tune Qwen 3.8 27B on a 24GB GPU? QLoRA at short context and small batch, yes, though it's tight. A 48GB card is where it stops being a memory management exercise.

LoRA or QLoRA for this model? QLoRA (LoRA on 4-bit quantized weights) for anything under 80GB of VRAM. LoRA on 16-bit weights needs the full 56GB of BF16 weights resident plus training overhead, so it's an 80GB-card job.

Can I fine-tune the vision encoder too? Unverified as of this writing. Unsloth has vision fine-tuning notebooks for smaller Qwen releases, but hasn't documented a vision path for the 27B yet. Text fine-tuning is the confirmed route today.

How much training data do I need? For style, format, or domain behavior: hundreds to a few thousand high-quality examples. If your goal is factual recall of your documents, use retrieval instead; fine-tuning is the wrong tool for that.

Can I fine-tune Qwen 3.8 Max instead? Not realistically. The open 2.4T checkpoint exists, but training a model that size is a cluster-scale job. The 27B is the practical fine-tuning target in this family, and it's also the one with the permissive Apache 2.0 license.

How do I serve the fine-tuned model? Merge the adapter and serve with vLLM or SGLang for production traffic, or export GGUF for Ollama locally. Same paths as the base model; our production guide walks through the server setup.

Bottom Line

Five days after the weights dropped, the fine-tuning path for Qwen 3.8 27B is already real: Unsloth support is live, the model is dense and Apache 2.0, and QLoRA fits on a single rentable card. The tooling will keep maturing over the next few weeks, but the practical loop works today: rent a 48GB pod, train on a few thousand curated examples, merge, and serve.

The hardware for every step of that loop, from a 4090 to an H200, rents by the hour on Yotta GPU Pods.