# GGUF dynamiques 2.0 d'Unsloth

Nous sommes ravis de présenter [Unsloth](https://github.com/unslothai/unsloth) La quantification dynamique v2.0 — une amélioration majeure par rapport à nos quantifications précédentes. Cette nouvelle méthode surpasse les principales méthodes de quantification et établit de nouveaux références pour [Aider Polglot](/docs/fr/bases/unsloth-dynamic-2.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md), MMLU en 5 shots et la divergence KL.

Cela signifie que vous pouvez désormais exécuter + affiner [des LLM quantifiés](/docs/fr/modeles/tutorials.md) tout en préservant autant que possible la précision ! Vous pouvez exécuter les GGUF 2.0 sur la plupart des moteurs d’inférence comme llama.cpp, [Unsloth Studio](/docs/fr/nouveau/studio.md) etc.

{% columns %}
{% column %}
**Mise à jour du 20 avr. 2026 :** Découvrez nos nouveaux benchmarks GGUF pour [Qwen3.6](/docs/fr/modeles/qwen3.6.md#unsloth-gguf-benchmarks) et [Gemma 4](/docs/fr/modeles/gemma-4.md#unsloth-gguf-benchmarks).

[Mise à jour du 27 févr. 2026 :](/docs/fr/modeles/qwen3.5/gguf-benchmarks.md) **Qwen3.5** est sorti et nous avons corrigé certains problèmes de modèles de chat pour l’appel d’outils, et benchmarké chaque GGUF sur la perplexité et la divergence KL. [Voir les benchmarks !](/docs/fr/modeles/qwen3.5/gguf-benchmarks.md)

L’ **avantage clé** d’utiliser le [package Unsloth](https://github.com/unslothai/unsloth) et les quantifications est notre rôle actif dans la correction de bogues dans les grands modèles. Nous avons collaboré directement avec les équipes derrière [Qwen3](https://www.reddit.com/r/LocalLLaMA/comments/1kaodxu/qwen3_unsloth_dynamic_ggufs_128k_context_bug_fixes/), [Meta (Llama 4)](https://github.com/ggml-org/llama.cpp/pull/12889), [Mistral (Devstral)](https://app.gitbook.com/o/HpyELzcNe0topgVLGCZY/s/xhOjnexMCB3dmuQFQ2Zq/~/changes/618/basics/tutorials-how-to-fine-tune-and-run-llms/devstral-how-to-run-and-fine-tune), [Google (Gemma 1–3)](https://news.ycombinator.com/item?id=39671146) et [Microsoft (Phi-3/4)](https://simonwillison.net/2025/Jan/11/phi-4-bug-fixes), en apportant des correctifs qui augmentent la précision.
{% endcolumn %}

{% column %}

<figure><img src="/files/e81ee98f746b03b836788438360431e6fa3c153a" alt=""><figcaption><p>Benchmarks Gemma 4 26B A4B (plus bas est mieux)</p></figcaption></figure>

<figure><img src="/files/7d93795853898894656b195d5eef3eab9ccb68ba" alt=""><figcaption><p>Benchmarks Qwen3.6 (plus bas est mieux)</p></figcaption></figure>
{% endcolumn %}
{% endcolumns %}

{% hint style="success" %}
Les GGUF dynamiques d’Unsloth peuvent désormais être exécutés dans [Unsloth Studio](/docs/fr/nouveau/studio.md) ✨

<img src="/files/d1de7323ac3c7ff8b6fa77fe0acb51771c26a735" alt="" data-size="original">
{% endhint %}

{% hint style="success" %}
[Mise à jour du 10 sept. 2025 :](/docs/fr/bases/unsloth-dynamic-2.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md) Vous avez demandé des benchmarks plus difficiles, alors voici les résultats d’Aider Polyglot ! Notre GGUF Dynamic 3 bits DeepSeek V3.1 obtient **75.6%**, dépassant de nombreux LLM SOTA en précision complète. [En savoir plus.](/docs/fr/bases/unsloth-dynamic-2.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md)

<img src="/files/a44459c063e628a7b3329db8bacc5515eff252fd" alt="DeepSeek-V3.2 Thinking Aider Benchmarks" data-size="original"><img src="/files/dff82e69eae54fe7e1dfc70f3a364059c61243cb" alt="Llama 4 5-shot MMLU Benchmarks" data-size="original">
{% endhint %}

Vous pouvez également consulter des benchmarks d’utilisation en conditions réelles réalisés par Benjamin Marie pour LiveCodeBench v6, MMLU Pro, etc. :

<div><figure><img src="/files/f321cef04ad4b89bb6fd902546aad9817950e88b" alt="" width="563"><figcaption></figcaption></figure> <figure><img src="/files/2394d4676318d3a483203b406c78b42df0847f96" alt="" width="450"><figcaption></figcaption></figure></div>

Vous pouvez voir comment les GGUF d’Unsloth sont plus performants que les quantifications non-Unsloth malgré une taille d’environ 8 Go plus petite.

Analyse détaillée de nos benchmarks et évaluation plus bas.

### 💡 Quoi de neuf dans Dynamic v2.0 ?

* **Sélection des couches remaniée pour les GGUF + safetensors :** Unsloth Dynamic 2.0 quantifie désormais les couches de manière beaucoup plus intelligente et plus étendue, de façon sélective. Plutôt que de modifier seulement certaines couches, nous ajustons désormais dynamiquement le type de quantification de chaque couche possible, et les combinaisons différeront pour chaque couche et chaque modèle.
* Les uploads GGUF sélectionnés actuellement et tous les futurs utiliseront Dynamic 2.0 et notre nouvel ensemble de données de calibration. L’ensemble de données contient plus de >1,5 M **tokens** (selon le modèle) et se compose de données de haute qualité, sélectionnées à la main et nettoyées — afin d’améliorer considérablement les performances en conversation.
* Auparavant, notre quantification dynamique (DeepSeek-R1 GGUF 1,58 bit) n’était efficace que pour les architectures MoE. <mark style="background-color:green;">**La quantification Dynamic 2.0 fonctionne désormais sur tous les modèles (y compris les MoE et les non-MoE)**</mark>.
* **Quantifications spécifiques au modèle :** Chaque modèle utilise désormais un schéma de quantification sur mesure. Par exemple, les couches quantifiées dans Gemma 3 diffèrent considérablement de celles de Llama 4.
* Afin de maximiser l’efficacité, en particulier sur Apple Silicon et les appareils ARM, nous ajoutons désormais aussi les formats Q4\_NL, Q5.1, Q5.0, Q4.1 et Q4.0.

Pour garantir un benchmark précis, nous avons construit un cadre d’évaluation interne afin de correspondre aux scores MMLU 5 shots officiels rapportés de Llama 4 et Gemma 3. Cela a permis des comparaisons équitables entre la précision complète et Dynamic v2.0, **QAT** et les quantifications GGUF standard **imatrix** .

<div><figure><img src="/files/7b889d2941adceab9d3b367dfa4e47d780a61233" alt="" width="563"><figcaption></figcaption></figure> <figure><img src="/files/bb8dbe7a539c2b30f808067280787afb78348837" alt="" width="563"><figcaption></figcaption></figure></div>

Tous les futurs uploads GGUF utiliseront Unsloth Dynamic 2.0, et nos quantifications safe tensor Dynamic 4 bits en bénéficieront également à l’avenir.

## 📊 Pourquoi la divergence KL ?

[La précision ne fait pas tout](https://arxiv.org/pdf/2407.09141) montre comment l’élagage de couches, même en sélectionnant des couches inutiles, produit malgré tout d’énormes différences en termes de « flips ». Un « flip » est défini comme un changement de réponse, d’incorrecte à correcte ou inversement. L’article montre que le score MMLU peut ne pas diminuer lorsque nous élaguons des couches ou effectuons une quantification, mais c’est parce que certaines réponses incorrectes peuvent avoir « basculé » pour devenir correctes. Notre objectif est de faire correspondre le modèle d’origine, donc mesurer les « flips » est une bonne métrique.

<div><figure><img src="/files/2d13a1182345a379c31365663d1ca5143aee72e3" alt=""><figcaption></figcaption></figure> <figure><img src="/files/d76cf52dab8009a39976600905518fdb0888a723" alt=""><figcaption></figcaption></figure></div>

{% hint style="info" %}
**La divergence KL** devrait être **l’un des critères de référence pour signaler les erreurs de quantification** selon l’article de recherche « Accuracy is Not All You Need ». **Utiliser la perplexité est incorrect** car les valeurs des tokens de sortie peuvent s’annuler, donc nous devons utiliser la KLD ou des benchmarks plus difficiles comme [Aider](/docs/fr/bases/unsloth-dynamic-2.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md).
{% endhint %}

L’article montre aussi, de manière intéressante, que la divergence KL est fortement corrélée aux flips, et notre objectif est donc de réduire la divergence KL moyenne tout en augmentant le moins possible l’espace disque de la quantification.

## ⚖️ Surapprentissage de l’ensemble de données de calibration

La plupart des cadres rapportent la perplexité et la divergence KL à l’aide d’un ensemble de test d’articles Wikipédia. Cependant, nous avons constaté que l’utilisation de l’ensemble de données de calibration, qui est également lié à Wikipédia, entraîne un surapprentissage des quantifications, et permet d’obtenir des scores de perplexité plus bas. Nous utilisons [Calibration\_v3](https://gist.github.com/bartowski1182/eb213dccb3571f863da82e99418f81e8) et [Calibration\_v5](https://gist.github.com/tristandruyen/9e207a95c7d75ddf37525d353e00659c/) des ensembles de données pour des tests équitables, comprenant notamment des données wikitext parmi d’autres données. <mark style="background-color:red;">**De plus, les modèles instruct ont des modèles de chat uniques, et l’utilisation d’ensembles de calibration uniquement textuels n’est pas efficace pour les modèles instruct**</mark> (pour les modèles de base, oui). En fait, la plupart des GGUF imatrix sont généralement calibrés avec ces problèmes. Par conséquent, ils obtiennent naturellement de meilleurs résultats sur les benchmarks de divergence KL qui utilisent également des données Wikipédia, puisque le modèle est essentiellement optimisé pour ce domaine.

Pour garantir une évaluation équitable et contrôlée, nous n’utilisons pas notre propre ensemble de données de calibration (qui est optimisé pour les performances de chat) lors du benchmark de la divergence KL. À la place, nous avons effectué les tests en utilisant les mêmes ensembles de données Wikipédia standards, ce qui nous a permis de comparer directement les performances de notre méthode Dynamic 2.0 à l’approche imatrix de base.

## :1234: L’aventure de réplication de MMLU

* La réplication du MMLU 5 shots a été cauchemardesque. Nous <mark style="background-color:red;">**n’avons pas pu**</mark> répliquer les résultats MMLU pour de nombreux modèles, y compris Llama 3.1 (8B) Instruct, Gemma 3 (12B) et d’autres, en raison de <mark style="background-color:yellow;">**problèmes subtils d’implémentation**</mark>. Llama 3.1 (8B), par exemple, devrait obtenir environ 68,2 %, alors qu’en utilisant des implémentations incorrectes on peut atteindre <mark style="background-color:red;">**35 % de précision.**</mark>

<figure><img src="/files/648daff56c184774997fd26f37a77547b4889a00" alt="" width="375"><figcaption><p>Problèmes d’implémentation du MMLU</p></figcaption></figure>

* Llama 3.1 (8B) Instruct a une précision MMLU 5 shots de 67,8 % en utilisant une implémentation MMLU naïve. Nous constatons cependant que Llama **tokenise « A » et « \_A » (A avec un espace devant) comme des ids de tokens différents**. Si nous prenons en compte à la fois les tokens avec espace et sans espace, nous obtenons 68,2 % <mark style="background-color:green;">(+0.4%)</mark>
* Fait intéressant, Llama 3 selon [LLM Harness](https://github.com/EleutherAI/lm-evaluation-harness/blob/main/lm_eval/tasks/llama3/instruct/mmlu/_continuation_template_yaml) d’Eleuther AI ajoute également <mark style="background-color:purple;">**« La meilleure réponse est »**</mark> à la question, suivant les benchmarks MMLU originaux de Llama 3.
* Il existe de nombreux autres problèmes subtils, et pour tout benchmarker dans un environnement contrôlé, nous avons conçu notre propre implémentation MMLU de zéro en étudiant [github.com/hendrycks/test](https://github.com/hendrycks/test) directement, et nous avons vérifié nos résultats sur plusieurs modèles en les comparant aux chiffres rapportés.

## :sparkles: Réplication QAT de Gemma 3, Benchmarks

L’équipe Gemma a publié deux versions QAT (quantization aware training) de Gemma 3 :

1. GGUF Q4\_0 - quantifie toutes les couches en Q4\_0 via la formule `w = q * block_scale` avec chaque bloc contenant 32 poids. Voir [le wiki llama.cpp ](https://github.com/ggml-org/llama.cpp/wiki/Tensor-Encoding-Schemes)pour plus de détails.
2. version int4 - vraisemblablement [style TorchAO int4](https://github.com/pytorch/ao/blob/main/torchao/quantization/README.md)?

Nous avons benchmarké toutes les versions GGUF Q4\_0, et réalisé des expériences approfondies sur le modèle 12B. Nous constatons que le **modèle QAT 12B Q4\_0 obtient 67,07 %** tandis que la version bfloat16 12B complète obtient 67,15 % sur le MMLU 5 shots. C’est très impressionnant ! Le modèle 27B est quasiment au niveau !

<table><thead><tr><th>Métrique</th><th>1B</th><th valign="middle">4B</th><th>12B</th><th>27B</th></tr></thead><tbody><tr><td>MMLU 5 shots</td><td>26.12%</td><td valign="middle">55.13%</td><td><mark style="background-color:blue;"><strong>67,07 % (67,15 % BF16)</strong></mark></td><td><strong>70,64 % (71,5 % BF16)</strong></td></tr><tr><td>Espace disque</td><td>0,93 Go</td><td valign="middle">2,94 Go</td><td><strong>7,52 Go</strong></td><td>16,05 Go</td></tr><tr><td><mark style="background-color:green;"><strong>Efficacité*</strong></mark></td><td>1.20</td><td valign="middle">10.26</td><td><strong>5.59</strong></td><td>2.84</td></tr></tbody></table>

Nous avons conçu une nouvelle **métrique d’efficacité** qui calcule l’utilité du modèle tout en prenant également en compte sa taille disque et son score MMLU 5 shots :

$$
\text{Efficiency} = \frac{\text{MMLU 5 shot score} - 25}{\text{Disk Space GB}}
$$

{% hint style="warning" %}
Nous devons **soustraire 25** car MMLU comporte 4 choix multiples — A, B, C ou D. Supposons que nous fabriquions un modèle qui se contente de choisir des réponses au hasard — il obtiendra 25 % de précision, et occupera quelques octets d’espace disque. Mais clairement, ce n’est pas un modèle utile.
{% endhint %}

Concernant la divergence KL par rapport au modèle de base, voici un tableau présentant les améliorations. Rappel : plus la divergence KL est proche de 0, mieux c’est (c.-à-d. 0 signifie identique au modèle en précision complète)

| Quant     | KLD de base | Go    | Nouvelle KLD | Go    |
| --------- | ----------- | ----- | ------------ | ----- |
| IQ1\_S    | 1.035688    | 5.83  | 0.972932     | 6.06  |
| IQ1\_M    | 0.832252    | 6.33  | 0.800049     | 6.51  |
| IQ2\_XXS  | 0.535764    | 7.16  | 0.521039     | 7.31  |
| IQ2\_M    | 0.26554     | 8.84  | 0.258192     | 8.96  |
| Q2\_K\_XL | 0.229671    | 9.78  | 0.220937     | 9.95  |
| Q3\_K\_XL | 0.087845    | 12.51 | 0.080617     | 12.76 |
| Q4\_K\_XL | 0.024916    | 15.41 | 0.023701     | 15.64 |

Si nous traçons le ratio de l’augmentation de l’espace disque et la variation du ratio de divergence KL, nous pouvons voir un bénéfice beaucoup plus clair ! Notre Q2\_K\_XL dynamique 2 bits réduit la KLD assez nettement (environ 7,5 %).

<figure><img src="/files/7fd782041d75573ef8d2d75dab767f600d7f12a6" alt=""><figcaption></figcaption></figure>

Tableau tronqué des résultats MMLU pour Gemma 3 (27B). Voir ci-dessous.

1. **Notre version dynamique 4 bits est plus petite de 2 Go tout en ayant +1 % de précision supplémentaire par rapport à la version QAT !**
2. Du point de vue de l’efficacité, les versions 2 bits Q2\_K\_XL et autres semblent très bien fonctionner !

| Quant          | Unsloth   | Unsloth + QAT | Taille disque | Efficacité |
| -------------- | --------- | ------------- | ------------- | ---------- |
| IQ1\_M         | 48.10     | 47.23         | 6.51          | 3.42       |
| IQ2\_XXS       | 59.20     | 56.57         | 7.31          | 4.32       |
| IQ2\_M         | 66.47     | 64.47         | 8.96          | 4.40       |
| Q2\_K\_XL      | 68.70     | 67.77         | 9.95          | 4.30       |
| Q3\_K\_XL      | 70.87     | 69.50         | 12.76         | 3.49       |
| **Q4\_K\_XL**  | **71.47** | **71.07**     | **15.64**     | **2.94**   |
| **Google QAT** |           | **70.64**     | **17.2**      | **2.65**   |

<details>

<summary><mark style="color:vert;">Cliquez ici</mark> pour l’ensemble complet des benchmarks QAT de Gemma 3 (27B) de Google :</summary>

| Modèle         | Unsloth   | Unsloth + QAT | Taille disque | Efficacité |
| -------------- | --------- | ------------- | ------------- | ---------- |
| IQ1\_S         | 41.87     | 43.37         | 6.06          | 3.03       |
| IQ1\_M         | 48.10     | 47.23         | 6.51          | 3.42       |
| IQ2\_XXS       | 59.20     | 56.57         | 7.31          | 4.32       |
| IQ2\_M         | 66.47     | 64.47         | 8.96          | 4.40       |
| Q2\_K          | 68.50     | 67.60         | 9.78          | 4.35       |
| Q2\_K\_XL      | 68.70     | 67.77         | 9.95          | 4.30       |
| IQ3\_XXS       | 68.27     | 67.07         | 10.07         | 4.18       |
| Q3\_K\_M       | 70.70     | 69.77         | 12.51         | 3.58       |
| Q3\_K\_XL      | 70.87     | 69.50         | 12.76         | 3.49       |
| Q4\_K\_M       | 71.23     | 71.00         | 15.41         | 2.98       |
| **Q4\_K\_XL**  | **71.47** | **71.07**     | **15.64**     | **2.94**   |
| Q5\_K\_M       | 71.77     | 71.23         | 17.95         | 2.58       |
| Q6\_K          | 71.87     | 71.60         | 20.64         | 2.26       |
| Q8\_0          | 71.60     | 71.53         | 26.74         | 1.74       |
| **Google QAT** |           | **70.64**     | **17.2**      | **2.65**   |

</details>

## :llama: Corrections de bugs Llama 4 + exécution

Nous avons aussi aidé et corrigé quelques bugs de Llama 4 :

* Llama 4 Scout a modifié la configuration de RoPE Scaling dans son dépôt officiel. Nous avons aidé à résoudre des problèmes dans llama.cpp pour permettre ce [changement ici](https://github.com/ggml-org/llama.cpp/pull/12889)

  <figure><img src="/files/a5cde5fe5f571b04d484e7a0b472df6fa12d62c7" alt=""><figcaption></figcaption></figure>
* L’epsilon du QK Norm de Llama 4 pour Scout et Maverick devrait provenir du fichier de configuration — cela signifie utiliser 1e-05 et non 1e-06. Nous avons aidé à résoudre cela dans [llama.cpp](https://github.com/ggml-org/llama.cpp/pull/12889) et [transformers](https://github.com/huggingface/transformers/pull/37418)
* L’équipe Llama 4 et vLLM ont également corrigé indépendamment un problème où le QK Norm était partagé entre toutes les têtes (ce qui ne devrait pas être le cas) [ici](https://github.com/vllm-project/vllm/pull/16311). MMLU Pro est passé de 68,58 % à 71,53 % de précision.
* [Wolfram Ravenwolf](https://x.com/WolframRvnwlf/status/1909735579564331016) a montré comment nos GGUF via llama.cpp atteignent une précision bien plus élevée que les fournisseurs d’inférence tiers — cela était très probablement une combinaison des problèmes expliqués ci-dessus, et probablement aussi due à des problèmes de quantification.

  <figure><img src="/files/7c8b4f3616ef0e87a1a63363b8f6bda43d70d617" alt=""><figcaption></figcaption></figure>

Comme le montre notre graphique, notre quantification QAT dynamique 4 bits offre de meilleures performances sur le MMLU 5 shots tout en étant également plus petite en taille.

### Exécution de Llama 4 Scout :

Pour exécuter Llama 4 Scout par exemple, clonez d’abord llama.cpp :

```bash
apt-get update
apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
git clone https://github.com/ggml-org/llama.cpp
cmake llama.cpp -B llama.cpp/build \
    -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON -DLLAMA_CURL=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-gguf-split
cp llama.cpp/build/bin/llama-* llama.cpp
```

Ensuite, téléchargez notre nouvelle quantification dynamique v2.0 pour Scout :

```python
# !pip install huggingface_hub hf_transfer
import os
os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "1"
from huggingface_hub import snapshot_download
snapshot_download(
    repo_id = "unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF",
    local_dir = "unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF",
    allow_patterns = ["*IQ2_XXS*"],
)
```

Et maintenant, faisons l’inférence !

{% code overflow="wrap" %}

```bash
./llama.cpp/llama-cli \
    --model unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF/Llama-4-Scout-17B-16E-Instruct-UD-IQ2_XXS.gguf \
    --threads 32 \
    --ctx-size 16384 \
    --n-gpu-layers 99 \
    -ot ".ffn_.*_exps.=CPU" \
    --seed 3407 \
    --prio 3 \
    --temp 0.6 \
    --min-p 0.01 \
    --top-p 0.9 \
    -no-cnv \
    --prompt "<|header_start|>user<|header_end|>\n\nCrée un jeu Flappy Bird.<|eot|><|header_start|>assistant<|header_end|>\n\n"
```

{% endcode %}

{% hint style="success" %}
En savoir plus sur l’exécution de Llama 4 ici : <https://docs.unsloth.ai/basics/tutorial-how-to-run-and-fine-tune-llama-4>
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://unsloth.ai/docs/fr/bases/unsloth-dynamic-2.0-ggufs.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.