> For the complete documentation index, see [llms.txt](https://unsloth.ai/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://unsloth.ai/docs/fr/notions-de-base/dynamic-3.0-ggufs.md). # GGUF dynamiques 3.0 d'Unsloth **Unsloth Dynamic V3.1** (nov. 2026) est notre dernier algorithme de quantification pour Qwen3.8-27B, DeepSeek-V4.1-Flash-1017 et Qwen3.8-Flash-Next, qui offre **une précision supérieure de 10 à 15 %** et **une consommation de jetons réduite de 50 %** par rapport aux autres quantifications de même taille. Nous travaillons à une version encore meilleure des quantifications Dynamic, qui sera appliquée à Qwen4 et à tous les modèles à venir. Unsloth [Qwen3.8-27B](/docs/fr/modeles/qwen3.8.md) Dynamic V3.1 repousse la frontière de Pareto pour toutes les quantifications, dépassant nos précédentes quantifications UD3, Exllama-3 et GSQ-RCO. [Qwen3.8-Flash-Next](/docs/fr/modeles/qwen3.8-next.md) La quantification 1 bit atteint 54,0 % sur DeepSWE v1.1 et 68,3 % sur Terminal Bench 2.1. [DeepSeek-V4.1-Flash-1017](/docs/fr/modeles/deepseek-v4.1-flash.md) Dynamic V3.1 IQ1\_S atteint 65,8 % sur DeepSWE v1.1, 69,5 % sur Terminal Bench 2.1 et 51,5 % sur Automation Bench v1.0.6.

Benchmarks de consommation de jetons et de vitesse de Qwen3.8-Flash-Next GGUF

### Dynamic v3.0 Vous trouverez ci-dessous les notes de version et les benchmarks de la précédente version Dynamic v3.0. Nous publions les quantifications [**Qwen3.8-27B**](/docs/fr/modeles/qwen3.8.md) Dynamic v3.0, qui offrent une **précision top-1 supérieure de >10 % à taille égale** par rapport à **tous les autres fournisseurs**. Il s’agit d’une mise à jour de notre première version partagée en **avant-première** de Dynamic v3.0. Les nouveaux fichiers GGUF 3.0 sont compatibles avec la plupart des moteurs d’inférence, notamment **llama.cpp** et [**Unsloth Desktop**](/docs/fr/desktop.md). {% columns %} {% column width="41.66666666666667%" %} Dans l’ensemble, Dynamic v3.0 préserve davantage la qualité du modèle à taille identique, avec de meilleurs résultats pour des mesures telles que **Divergence-300** @32 et **Divergence KL**. Un grand merci également pour tout votre soutien ! Nous avons enregistré plus de 5,1 millions de téléchargements d’Unsloth Qwen3.8 en seulement 5 jours ! {% endcolumn %} {% column width="58.33333333333333%" %}

Vous trouverez ci-dessous d’autres graphiques, benchmarks et analyses.

{% endcolumn %} {% endcolumns %} Notre nouvelle méthodologie repose sur de nombreuses nouvelles fonctionnalités et améliorations. Nous utilisons désormais un jeu de données de calibration imatrix de bien meilleure qualité, issu de sources variées. Ce jeu de données est affiné pour **le codage agentique et les conversations**, ainsi que pour les performances multilingues. Nous avons également amélioré la **sélection des couches** et introduit de nombreuses autres techniques de quantification afin de préserver au mieux la qualité du modèle. Nous **n’entraînons pas le modèle sur le jeu de données de calibration imatrix**, et nous n’utilisons PAS **QAT** ni **QAD**. Tout est réalisé par **quantification après entraînement**. Notre fichier imatrix est mis à la disposition de la communauté pour être testé, évalué et utilisé. Nous encourageons les chercheurs et les développeurs à créer des variantes et des versions affinées de Qwen3.8 à l’aide de nos quants/imatrix Unsloth. Vous pouvez également lire notre [analyse du surapprentissage](#not-overfitting) également. * Nous avons également supprimé le module MTP des quants plus petits que `UD-Q2_K_XL` (8,37 Go et moins) afin d’économiser environ 500 Mo d’espace disque. Vous pouvez utiliser le module MTP séparé `Q4_0` si nécessaire * Nous avons également créé des quants UD-1bit plus petits, dont `UD-IQ1_S` ne fait que 6,2 Go (sans MTP) et conserve environ 72 % de précision top-1, tout en étant 89 % plus petit. * `UD-Q2_K_XL` est environ 8 % plus précis en top-1 que le suivant, avec une taille de 9,83 Go, et a réussi à générer un programme HTML fonctionnel malgré un petit bug JS. Auparavant, il plantait.

Généré avec un GGUF Qwen3.8-27B quantifié sur 2 bits

### 🔀 Divergence-300 @32 En général, nous indiquons la précision top-1, par exemple lorsque nous disons que, pour Kimi-K3, « le 1-bit dynamique atteint **\~78.9%** de précision top-1 tout en étant **62 % plus petit**. Cependant, le top-1 correspond à un argmax sur une seule prédiction ; il ne permet donc pas vraiment d’évaluer l’inférence réelle. Nous avons créé un jeu de données de 300 exemples mis de côté (NON inclus dans le jeu de données d’étalonnage), issus de Terminal-Bench 2.1, DeepSWE, Harbor, MathArena 2025-26, ainsi que de prompts en langues non latines et de longs documents. Nous avons effectué un décodage glouton par argmax sur 32 jetons pour BF16, tous les quants et tous les fournisseurs. Consultez l’ [analyse du surapprentissage](#not-overfitting) pour en savoir plus sur le surapprentissage. Cela nous permet d’évaluer s’il y a surapprentissage et si les sorties des quants suivent des trajectoires similaires à celles de BF16 sur plusieurs jetons. Cette mesure est plus pertinente que la précision top-1, car nous étendons le KLD top-1 à 32 jetons.

### :question:Le 1-bit ne doit pas être utilisé pour les cas d’usage agentiques Comme on peut le voir dans [#divergence-300-32](#divergence-300-32 "mention"), la précision chute brutalement entre UD-Q2\_K\_XL et UD-IQ2\_S pour les prédictions sur 32 jetons, passant d’environ 25 % à moins de 8–10 %. Cette forte baisse signifie que l’appel d’outils et les modes sans réflexion ne fonctionnent plus correctement. Voici quelques problèmes et mesures d’atténuation pour l’utilisation du 1-bit : 1. **Boucles excessives**\ Vous constaterez de nombreuses boucles avec les quants inférieurs à UD-Q2\_K\_XL : utilisez `presence_penalty = 1.5` dans tous les cas (ou une valeur supérieure) 2. **Réponses vides**\ Avec les quants 1-bit, activez toujours la réflexion, au moins au niveau de raisonnement faible. Les modes sans raisonnement peuvent empêcher le modèle de produire la moindre sortie. 3. **Cas d’usage agentiques et appels d’outils**\ N’utilisez pas le modèle pour appeler des outils : seules les **connaissances générales sont préservées** lors d’une quantification poussée ; le modèle peut ne pas réussir à appeler les outils, les appeler sans cesse ou ne pas les appeler du tout. 4. **Les connaissances générales restent utilisables**\ Un taux de récupération top-1 de 77 % ne remplace pas Divergence-300 @32, qui atteint 8 % et constitue un meilleur indicateur des performances en inférence réelle. Vous pouvez utiliser le modèle pour répondre à de très courtes questions factuelles de culture générale, mais UD-Q2\_K\_XL reste préférable. ### 🔀 Benchmarks de divergence KL Nous avons également effectué des benchmarks KLD pour tous les fournisseurs et indiqué les moyennes top-1 et KLD. À tous les niveaux, en particulier pour les quants les plus petits, les quants Unsloth UD-3 offrent jusqu’à 10 % de précision top-1 supplémentaire à espace disque égal ! Pour garantir une comparaison équitable, tous les graphiques excluent la tête MTP de l’axe des x lors du calcul de l’espace disque.

### :dove:Pas de surapprentissage En comparant notre ancien UD-2 aux nouveaux jeux de données Wikitext et Code, nous constatons une nette amélioration du KLD. Le gain est moins marqué pour les modèles plus grands ; nous continuons donc d’utiliser notre ancien UD-2 pour les quants de grande taille. Nous prévoyons également de les tester et de les améliorer ! Nous limitons également le surapprentissage en utilisant des jeux de données d’étalonnage complètement différents et en éliminant autant que possible toute fuite de données. Nous évaluons le KLD sur ces jeux de données inédits et nous n’utilisons PAS QAD/QAT, mais uniquement du PTQ pur. Le risque de surapprentissage est donc moins préoccupant qu’avec d’autres approches QAD/QAT.

De même, [#divergence-300-32](#divergence-300-32 "mention") utilise un jeu de données inédit de 300 prompts issus de DeepSWE, Terminal Bench et d’autres sources ; il sert également à évaluer le surapprentissage et montre que nos nouvelles méthodes UD-3 ne surapprennent pas. *** ## Dynamic v2.0 (ancien) Nous présentons [Unsloth](https://github.com/unslothai/unsloth) Dynamic v2.0, une méthode de quantification qui constitue une amélioration majeure par rapport à nos anciens quants. Cette nouvelle méthode surpasse les principales méthodes de quantification et établit de nouveaux records pour [Aider Polyglot](/docs/fr/notions-de-base/dynamic-3.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md), MMLU à 5 exemples et divergence de Kullback-Leibler. Cela signifie que vous pouvez désormais exécuter et 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 avril 2026 :** Consultez 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évrier 2026 :](/docs/fr/modeles/qwen3.5/gguf-benchmarks.md) **Qwen3.5** est disponible. Nous avons corrigé certains problèmes liés aux modèles de conversation et aux appels d’outils, et évalué chaque GGUF en matière de perplexité et de divergence de Kullback-Leibler. [Consultez les benchmarks !](/docs/fr/modeles/qwen3.5/gguf-benchmarks.md) Le **principal avantage** de l’utilisation du [package Unsloth](https://github.com/unslothai/unsloth) et de ses quantifications, c’est que nous jouons un rôle actif dans la correction des bugs des principaux modèles. Nous avons collaboré directement avec les équipes à l’origine de [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 améliorent la précision. {% endcolumn %} {% column %}

Benchmarks de Gemma 4 26B A4B (plus bas est mieux)

{% 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) ✨

{% endhint %} {% hint style="success" %} [Mise à jour du 10 septembre 2025 :](/docs/fr/notions-de-base/dynamic-3.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md) Vous avez demandé des benchmarks plus exigeants ; voici donc les résultats d’Aider Polyglot ! Notre GGUF dynamique 3 bits de DeepSeek V3.1 obtient un score de **75.6%**, dépassant de nombreux LLM de pointe en précision complète. [En savoir plus.](/docs/fr/notions-de-base/dynamic-3.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md) DeepSeek-V3.2 Thinking Aider Benchmarks

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

Vous pouvez constater que les GGUF d’Unsloth sont plus performants que les quantifications non-Unsloth, bien qu’ils soient environ 8 Go plus petits. Vous trouverez plus bas une analyse détaillée de nos benchmarks et de notre évaluation. ### 💡 Nouveautés de Dynamic v2.0 ? * **Sélection des couches repensée pour GGUF et safetensors :** Unsloth Dynamic 2.0 quantifie désormais les couches de manière beaucoup plus intelligente et approfondie. Au lieu de ne modifier que certaines couches, nous ajustons désormais dynamiquement le type de quantification de toutes les couches possibles ; les combinaisons varient selon chaque couche et chaque modèle. * Les modèles actuellement sélectionnés ainsi que tous les futurs modèles GGUF importés utiliseront Dynamic 2.0 et notre nouveau jeu de données d’étalonnage. Celui-ci contient plus de 1,5 million de **tokens** (selon le modèle) et se compose de données de haute qualité, soigneusement sélectionnées et nettoyées, afin d’améliorer considérablement les performances conversationnelles. * Auparavant, notre quantification dynamique (GGUF DeepSeek-R1 1,58 bit) n’était efficace que pour les architectures MoE. **La quantification Dynamic 2.0 fonctionne désormais sur tous les modèles (y compris les modèles MoE et non-MoE).**. * **Quantifications spécifiques aux modèles :** Chaque modèle utilise désormais un schéma de quantification personnalisé. Par exemple, les couches quantifiées dans Gemma 3 diffèrent considérablement de celles de Llama 4. * Pour maximiser l’efficacité, en particulier sur les appareils Apple Silicon et ARM, nous ajoutons désormais également les formats Q4\_NL, Q5.1, Q5.0, Q4.1 et Q4.0. Pour garantir la précision de nos évaluations comparatives, nous avons créé un cadre d’évaluation interne afin de reproduire les scores officiels rapportés de Llama 4 et Gemma 3 au MMLU avec 5 exemples. Cela nous a permis de comparer directement la précision complète à Dynamic v2.0, **QAT** et aux quantifications standard **imatrix** au format GGUF.

Tous les prochains téléversements GGUF utiliseront Unsloth Dynamic 2.0, et nos quantifications Dynamic 4 bits au format SafeTensors en bénéficieront également à l’avenir. ## 📊 Pourquoi la divergence KL ? [La précision ne suffit pas](https://arxiv.org/pdf/2407.09141) montre que l’élagage de couches, même en sélectionnant des couches superflues, entraîne tout de même de grandes différences en matière de « basculements ». Un « basculement » désigne le passage d’une réponse incorrecte à une réponse correcte, ou inversement. L’article montre que le score MMLU peut ne pas baisser lorsque l’on élague des couches ou que l’on effectue une quantification, mais cela s’explique par le fait que certaines réponses incorrectes ont pu « basculer » et devenir correctes. Notre objectif étant de reproduire le modèle d’origine, mesurer les « basculements » constitue une bonne métrique.

{% hint style="info" %} **La divergence KL** devrait être **l’une des références incontournables pour rendre compte des erreurs de quantification** selon l’article de recherche « La précision ne suffit pas ». **Utiliser la perplexité est incorrect** car les valeurs des tokens de sortie peuvent s’annuler ; nous devons donc utiliser la divergence KL ou des benchmarks plus exigeants comme [Aider](/docs/fr/notions-de-base/dynamic-3.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md). {% endhint %} L’article montre également que, fait intéressant, la divergence KL est fortement corrélée aux basculements. Notre objectif est donc de réduire la divergence KL moyenne tout en limitant autant que possible l’augmentation de l’espace disque occupé par la quantification. ## ⚖️ Surapprentissage au jeu de calibration La plupart des frameworks calculent la perplexité et la divergence KL à l’aide d’un jeu de test composé d’articles de Wikipédia. Cependant, nous avons remarqué que l’utilisation d’un jeu de calibration également lié à Wikipédia entraîne un surapprentissage des quantifications et réduit les scores de perplexité. Nous utilisons les jeux de données [Calibration\_v3](https://gist.github.com/bartowski1182/eb213dccb3571f863da82e99418f81e8) et [Calibration\_v5](https://gist.github.com/tristandruyen/9e207a95c7d75ddf37525d353e00659c/) pour effectuer des tests équitables. Ils comprennent notamment des données de wikitext, ainsi que d’autres données. **De plus, les modèles de suivi d’instructions ont des formats de conversation qui leur sont propres, et les jeux de calibration composés uniquement de texte ne sont pas adaptés à ces modèles** (mais ils conviennent aux modèles de base). En fait, la plupart des fichiers GGUF imatrix sont généralement calibrés en tenant compte de ces problèmes. Par conséquent, ils obtiennent naturellement de meilleurs résultats aux benchmarks de divergence KL qui utilisent également des données de Wikipédia, puisque le modèle est essentiellement optimisé pour ce domaine. Afin de garantir une évaluation équitable et contrôlée, nous n’utilisons pas notre propre jeu de calibration (optimisé pour les performances en conversation) lors de l’évaluation de la divergence KL. Nous avons plutôt effectué des tests sur les mêmes jeux de données Wikipédia standard, ce qui nous permet de comparer directement les performances de notre méthode Dynamic 2.0 à celles de l’approche imatrix de référence. ## :1234: L’aventure de la reproduction du MMLU * Reproduire le MMLU avec 5 exemples a été un véritable cauchemar. Nous **n’avons pas pu** reproduire les résultats MMLU de nombreux modèles, notamment Llama 3.1 (8B) Instruct, Gemma 3 (12B) et d’autres, en raison de **problèmes subtils d’implémentation**. Par exemple, Llama 3.1 (8B) devrait obtenir environ 68,2 %, alors que des implémentations incorrectes peuvent donner **une précision de 35 %.**

* Llama 3.1 (8B) Instruct obtient une précision de 67,8 % au MMLU avec 5 exemples lorsqu’on utilise une implémentation naïve du MMLU. Nous constatons toutefois que Llama **tokenise « A » et « \_A » (A précédé d’une espace) en identifiants de token différents**. Si l’on prend en compte les tokens avec et sans espace, on obtient 68,2 % (+0.4%) * Fait intéressant, Llama 3, dans l’implémentation de [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 **« The best answer is »** à la question, conformément aux benchmarks MMLU d’origine de Llama 3. * Il existe de nombreux autres problèmes subtils. Pour évaluer tous les modèles dans un environnement contrôlé, nous avons donc conçu notre propre implémentation du MMLU à partir de zéro, en examinant directement [github.com/hendrycks/test](https://github.com/hendrycks/test) et en vérifiant nos résultats sur plusieurs modèles, puis en les comparant aux chiffres publiés. ## :sparkles: Reproduction de QAT pour Gemma 3 : benchmarks L’équipe Gemma a publié deux versions de Gemma 3 entraînées par QAT (quantification consciente de l’entraînement) : 1. GGUF Q4\_0 : quantifie toutes les couches en Q4\_0 selon la formule `w = q * block_scale` chaque bloc contenant 32 poids. Voir le [wiki de llama.cpp ](https://github.com/ggml-org/llama.cpp/wiki/Tensor-Encoding-Schemes)pour plus de détails. 2. version int4 — probablement le [style int4 de TorchAO](https://github.com/pytorch/ao/blob/main/torchao/quantization/README.md)? Nous avons évalué toutes les versions Q4\_0 au format GGUF et réalisé de nombreuses expériences avec le modèle 12B. Nous constatons que le modèle **12B Q4\_0 QAT obtient 67,07 %** tandis que la version complète 12B en bfloat16 obtient 67,15 % au test MMLU avec 5 exemples. C’est très impressionnant ! Le modèle 27B n’est presque plus loin !

Métrique	1B	4B	12B	27B
MMLU avec 5 exemples	26.12%	55.13%	67,07 % (67,15 % en BF16)	70,64 % (71,5 % en BF16)
Espace disque	0.93GB	2.94GB	7.52GB	16.05GB
Efficacité*	1.20	10.26	5.59	2.84

Nous avons conçu une nouvelle **métrique d’efficacité** qui calcule l’utilité du modèle tout en tenant compte de son espace disque et de son score au test MMLU avec 5 exemples : $$ \text{Efficiency} = \frac{\text{MMLU 5 shot score} - 25}{\text{Disk Space GB}} $$ {% hint style="warning" %} Nous devons **soustraire 25** car le test MMLU propose 4 choix : A, B, C ou D. Supposons que nous créions un modèle qui choisit simplement ses réponses au hasard : il obtiendrait une précision de 25 % et occuperait quelques octets sur le disque. Mais, de toute évidence, ce ne serait pas un modèle utile. {% endhint %} Voici un tableau présentant les améliorations mesurées par rapport au modèle de base en matière de divergence KL. Rappel : plus la divergence KL est proche de 0, mieux c’est (c’est-à-dire que 0 signifie que le modèle est identique au modèle en pleine précision). | Quantification | Divergence KL de référence | Go | Nouvelle divergence KL | 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 représentons le rapport entre l’augmentation de l’espace disque et la variation du rapport de divergence KL, les avantages sont beaucoup plus nets ! Notre quantification dynamique sur 2 bits Q2\_K\_XL réduit considérablement la divergence KL (d’environ 7,5 %).

Tableau tronqué des résultats au test MMLU pour Gemma 3 (27B). Voir ci-dessous. 1. **Notre version dynamique sur 4 bits occupe 2 Go de moins tout en offrant une précision supérieure de 1 % à celle de la version QAT !** 2. En matière d’efficacité, la version Q2\_K\_XL sur 2 bits et les autres semblent très performantes ! | Quantification | Unsloth | Unsloth + QAT | Taille sur 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** | | **QAT de Google** | | **70.64** | **17.2** | **2.65** |

Cliquez ici pour les benchmarks QAT complets de Gemma 3 (27B) de Google :

| Modèle | Unsloth | Unsloth + QAT | Taille sur 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 | | **QAT de Google** | | **70.64** | **17.2** | **2.65** |

## :llama: Correctifs de bugs pour Llama 4 + exécution Nous avons également contribué à corriger quelques bugs de Llama 4 : * Llama 4 Scout a modifié la configuration de mise à l’échelle RoPE dans son dépôt officiel. Nous avons contribué à résoudre les problèmes dans llama.cpp pour permettre cette [modification ici](https://github.com/ggml-org/llama.cpp/pull/12889)

* L’epsilon de QK Norm de Llama 4, pour Scout comme pour Maverick, doit provenir du fichier de configuration : il faut donc utiliser 1e-05 et non 1e-06. Nous avons contribué à corriger ces problèmes 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 lié au partage de QK Norm entre toutes les têtes (ce ne devrait pas être le cas) [ici](https://github.com/vllm-project/vllm/pull/16311). Le score d’exactitude à MMLU Pro est passé de 68,58 % à 71,53 %. * [Wolfram Ravenwolf](https://x.com/WolframRvnwlf/status/1909735579564331016) a montré que nos fichiers GGUF utilisés avec llama.cpp atteignent une exactitude bien supérieure à celle des fournisseurs d’inférence tiers. Cela s’explique probablement par une combinaison des problèmes mentionnés ci-dessus et, sans doute, de problèmes de quantification.

Comme le montre notre graphique, notre quantification QAT dynamique sur 4 bits offre de meilleures performances sur MMLU à 5 exemples, tout en occupant moins d’espace. ### Exécuter Llama 4 Scout : Pour exécuter Llama 4 Scout, par exemple, commencez par cloner 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 ``` Téléchargez ensuite 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, lançons 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\\nCreate a Flappy Bird game.<|eot|><|header_start|>assistant<|header_end|>\\n\\n" ``` {% endcode %} {% hint style="success" %} Pour en savoir plus sur l’exécution de Llama 4, consultez : {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://unsloth.ai/docs/fr/notions-de-base/dynamic-3.0-ggufs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.