---
title: "Unsloth en profondeur : fine-tuning rapide et GGUF dynamiques"
description: Comment Unsloth accélère le fine-tuning LoRA et produit des GGUF
  Dynamic supérieurs, avec un exemple sur Qwen3.6-27B.
date: 2026-06-01T00:00:00.000Z
dateModified: 2026-06-01T00:00:00.000Z
author:
  name: Antoine Michéa
  url: https://sobercloud.fr/
  sameAs:
    - https://altilink.eu/
tags:
  - unsloth
  - fine-tuning
  - lora
  - quantification
section: Fine-tuning
canonical: https://sobercloud.fr/decouvertes/unsloth-en-profondeur/
---

# Unsloth en profondeur : fine-tuning rapide et GGUF dynamiques

Unsloth est un framework d'optimisation qui accélère drastiquement le fine-tuning et produit des quantifications GGUF de qualité supérieure grâce à sa technique de Dynamic Quantization. C'est l'outil de référence pour entraîner des modèles sur GPU consumer, et la source des GGUF « UD- » que SoberCloud utilise en production.

## Pourquoi Unsloth ?

Unsloth optimise les kernels d'entraînement et les workflows LoRA pour offrir des gains substantiels sans sacrifier la qualité. Sur du matériel grand public, les ordres de grandeur typiques sont :

- environ **2× plus rapide** à l'entraînement ;
- jusqu'à **-70 % de VRAM** utilisée ;
- **aucune perte de précision** mesurable par rapport à un fine-tuning classique.

## Dynamic Quantization — le secret d'Unsloth

La **Dynamic Quantization** d'Unsloth ne quantifie pas tous les paramètres de la même manière. Elle analyse chaque couche et applique une précision variable selon son importance.

### Principe de base

- Les couches `down_proj` (surtout les premières) sont les plus sensibles à la quantification.
- Unsloth garde ces couches critiques en 8 ou 16 bits.
- Les couches moins importantes sont quantifiées plus agressivement (1 à 6 bits).
- Résultat : compression maximale avec qualité préservée.

### Dynamic 2.0

La version 2.0 étend la quantification dynamique à **tous les modèles** (pas seulement les MoE) et optimise chaque couche individuellement avec un « quant plan » spécifique par architecture.

Sur un MoE comme **Qwen3.6-35B-A3B** (3B actifs par token), cette logique est particulièrement utile : seuls quelques experts s'activent à chaque pas, et préserver les routeurs et les couches `down_proj` critiques en haute précision évite l'effondrement de qualité qu'on observe avec une quantification uniforme agressive. Sur un dense comme **Qwen3.6-27B**, le « quant plan » répartit le budget de bits entre attention et MLP couche par couche.

## Nomenclature des fichiers Unsloth

```
Qwen3.6-27B-Instruct-UD-Q4_K_XL.gguf
                      │  │      │
                      │  │      └── XL = blocs Extra Large
                      │  └── Q4_K = base K-quant 4-bit
                      └── UD = Unsloth Dynamic

Qwen3.6-35B-A3B-UD-IQ2_M.gguf
                │   │
                │   └── IQ2_M = quant 2-bit (importance-aware)
                └── UD = Unsloth Dynamic
```

## Utiliser Unsloth pour le fine-tuning

```python
from unsloth import FastLanguageModel
from trl import SFTTrainer
from transformers import TrainingArguments
from datasets import load_dataset

# Charger le modèle optimisé Unsloth (4-bit automatique)
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Qwen3.6-27B-Instruct-bnb-4bit",
    max_seq_length=8192,
    load_in_4bit=True,
)

# Ajouter les adaptateurs LoRA
model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                    "gate_proj", "up_proj", "down_proj"],
    lora_alpha=16,
    lora_dropout=0,
    use_gradient_checkpointing="unsloth",  # Économise ~30 % de VRAM
)

dataset = load_dataset("json", data_files="train.json")

trainer = SFTTrainer(
    model=model,
    train_dataset=dataset["train"],
    dataset_text_field="text",
    max_seq_length=2048,
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,
        warmup_steps=5,
        max_steps=60,
        learning_rate=2e-4,
        fp16=True,
        output_dir="outputs",
    ),
)
trainer.train()
```

## Exporter en GGUF

Après l'entraînement, Unsloth facilite l'export vers différents formats :

```python
# Option A : export GGUF direct
model.save_pretrained_gguf(
    "model-gguf",
    tokenizer,
    quantization_method="q4_k_m"  # ou "q8_0", "f16"
)

# Option B : merge LoRA puis export
model.save_pretrained_merged(
    "model-merged",
    tokenizer,
    save_method="merged_16bit"
)

# Puis conversion manuelle avec llama.cpp pour plus de contrôle
# ./llama-quantize model-merged/model.safetensors output.gguf Q4_K_M
```

Le GGUF obtenu se charge ensuite directement dans llama.cpp, Ollama ou LM Studio.

## Unsloth Dynamic vs GGUF standard

| Modèle | Type | Taille | Perplexité | Benchmark |
|---|---|---|---|---|
| Dense 8B | Q4_K_M standard | 4.9 Go | Baseline | Baseline |
| Dense 8B | UD-Q4_K_M | ~5.1 Go | -0.15 | +2.3 % |
| MoE 671B | Standard Q2 | ~180 Go | Baseline | Baseline |
| MoE 671B | UD-IQ1.58 | 192 Go | -0.3 | Supérieur |

À taille quasi identique, la variante Dynamic récupère une part significative de la qualité perdue par une quantification uniforme : l'écart de perplexité se resserre et les scores de benchmark remontent.

## Hardware supporté

Unsloth supporte les GPU NVIDIA (CUDA), AMD (ROCm) et Intel. **Apple Silicon n'est pas supporté pour le fine-tuning local** (utilisez MLX dans ce cas). En revanche, les GGUF exportés fonctionnent ensuite partout via llama.cpp ou MLX, y compris sur le backend Vulkan d'un iGPU Strix Halo.

C'est précisément cet écosystème que SoberCloud réutilise : on ne ré-entraîne pas systématiquement, mais on s'appuie sur les **GGUF « UD- » (Unsloth Dynamic)** et sur les presets de sampling d'Unsloth pour servir des modèles quantifiés de qualité, notamment sur Strix Halo.

## Pour aller plus loin

- [Fine-tuning complet : LoRA, QLoRA, Spectrum](/decouvertes/fine-tuning-complet/)
- [Quantification avancée](/decouvertes/quantification-avancee/)
- [Logiciels d'inférence](/decouvertes/logiciels-inference/)