> 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/de/grundlagen/dynamic-3.0-ggufs.md). # Unsloth Dynamic 3.0 GGUFs [**Unsloth**](https://github.com/unslothai/unsloth) **Dynamic v3.0** ist die nächste Iteration unserer Dynamic-Quantisierung und eine große Verbesserung gegenüber Dynamic v2.0. Heute veröffentlichen wir [**Qwen3.8-27B**](/docs/de/modelle/qwen3.8.md) Dynamic v3.0-Quantisierungen, die liefern **>10 % bessere Top-1-Genauigkeit bei gleicher Größe** im Vergleich zu **jedem anderen Anbieter**. Dies ist ein Update unserer ersten gemeinsamen **frühen Vorschau** Version von Dynamic v3.0. Die neuen 3.0-GGUFs funktionieren mit den meisten Inferenz-Engines, einschließlich **llama.cpp** und [**Unsloth Desktop**](/docs/de/desktop.md). {% columns %} {% column width="41.66666666666667%" %} Dynamic v3.0 bewahrt insgesamt mehr Modellqualität bei gleicher Größe und liefert stärkere Ergebnisse bei Metriken wie **Divergence-300** @32 und **KL-Divergenz**. Außerdem ein riesiges Dankeschön für all eure Unterstützung! Wir haben in nur 5 Tagen über 5,1 Millionen Unsloth-Qwen3.8-Downloads gesehen! {% endcolumn %} {% column width="58.33333333333333%" %}

Siehe unten für mehr Diagramme/Benchmarks und Analysen

{% endcolumn %} {% endcolumns %} Unsere neue Methodik besteht aus vielen neuen Funktionen und Verbesserungen. Wir verwenden jetzt einen deutlich hochwertigeren imatrix-Kalibrierungsdatensatz aus vielfältigen Quellen. Der Datensatz ist verfeinert für **agentisches Coding, Chat**, und mehrsprachige Leistung. Wir haben auch **Schichtauswahl** verbessert und viele weitere Quantisierungstechniken eingeführt, um so viel Modellqualität wie möglich zu erhalten. Wir **trainieren nicht auf dem imatrix-Kalibrierungsdatensatz**, und wir verwenden NICHT **QAT** oder **QAD**. Alles geschieht über **Post-Training-Quantisierung**. Unsere verwendete imatrix-Datei steht der Community zum Testen, Evaluieren und Verwenden zur Verfügung. Wir ermutigen Forschende und Entwickelnde, Varianten und Fine-Tunes von Qwen3.8 mithilfe unserer Unsloth-Quants/imatrix zu erstellen. Sie können auch unsere [Überfitting-Analyse](#not-overfitting) lesen. * Wir haben auch das MTP-Modul aus kleineren Quants unter `UD-Q2_K_XL` (8,37 GB und kleiner) entfernt, um rund 500 MB Speicherplatz zu sparen – Sie können das `Q4_0` MTP-Separatmodul bei Bedarf verwenden * Wir haben außerdem einige kleinere UD-1bit-Quants mit `UD-IQ1_S` 6,2 GB (ohne MTP) erstellt, die etwa 72 % Top-1-Genauigkeit beibehalten und dabei 89 % kleiner sind. * `UD-Q2_K_XL` ist rund +8 % genauer bei Top-1 als der nächstbeste und hat 9,83 GB; außerdem gelang es, ein funktionierendes HTML-Programm mit 1 kleinem JS-Bug zu erstellen – zuvor wäre es abgestürzt.

Generiert mit einem 2-Bit-Qwen3.8-27B-GGUF

### 🔀 Divergence-300 @32 Wir berichten im Allgemeinen die Top-1-Genauigkeit so, wie bei Kimi-K3 „Dynamic 1-bit erreicht **\~78.9%** Top-1-Genauigkeit bei **62 % kleiner**.“ Allerdings ist Top-1 ein Argmax auf 1 Vorhersage, also ist es nicht wirklich effektiv, um die tatsächliche Inferenz zu bewerten. Wir haben einen Datensatz mit 300 zurückgehaltenen Beispielen (NICHT im Kalibrierungsdatensatz) aus Terminal-Bench 2.1 + DeepSWE + Harbor + MathArena 2025-26 + nicht-lateinischen/langen Dokument-Prompts erstellt und für BF16 vs. alle Quants und Anbieter ein greediges Argmax-Decoding für 32 Tokens durchgeführt. Siehe [Überfitting-Analyse](#not-overfitting) für weitere Details zum Overfitting. Dies ermöglicht uns zu bewerten, ob Overfitting vorliegt und ob die Quant-Ausgaben über mehrere Tokens hinweg den Trajektorien von BF16 ähneln. Dies ist eine bessere Metrik als Top-1-Genauigkeit, da wir KLD-Top-1 zu eher KLD-Top-1 bei 32 Tokens erweitern.

### :question:1-bit sollte nicht für agentische Anwendungsfälle verwendet werden Wie in [#divergence-300-32](#divergence-300-32 "mention"), ist ein starker Einbruch von UD-Q2\_K\_XL zu UD-IQ2\_S bei der Vorhersage von 32 Tokens von etwa 25 % Genauigkeit auf unter 8–10 % zu sehen. Dieser starke Einbruch bedeutet, dass Tool-Calling und Nicht-Denk-Modi zusammenbrechen. Einige Probleme und Gegenmaßnahmen bei Verwendung von 1-bit: 1. **Übermäßige Schleifen**\ Sie werden viel Schleifenbildung sehen, wenn Sie Quants unterhalb von UD-Q2\_K\_XL verwenden – verwenden Sie `presence_penalty = 1.5` in allen Fällen (oder höher) 2. **Leere Antworten**\ Aktivieren Sie Denken bei 1-bit-Quants immer zumindest auf niedriger Reasoning-Stufe – Nicht-Reasoning-Modi führen dazu, dass das Modell ohnehin nichts ausgibt 3. **Agentische Anwendungsfälle und Tool-Calling**\ Verwenden Sie das Modell nicht für Tool-Calling – nur **allgemeines Wissen bleibt erhalten** wenn stark quantisiert wird, und das Modell wird entweder keine Tools aufrufen, weiter Tools aufrufen oder sie nicht einmal aufrufen. 4. **Allgemeines Wissen funktioniert**\ Eine Top-1-Wiederherstellung von 77 % ist kein Ersatz für Divergence-300 @32 bei 8 %, das ein besserer Indikator für tatsächliche Inferenz-Workloads ist – Sie können das Modell für sehr kurze allgemeine Faktenfragen verwenden, aber am besten UD-Q2\_K\_XL nutzen. ### 🔀 KL-Divergenz-Benchmarks Wir haben ebenfalls KLD-Benchmarks für alle Anbieter durchgeführt und berichten Top-1 und den KLD-Mittelwert. Auf allen Ebenen, insbesondere bei den kleineren Quant-Größen, erreichen Unsloth-UD-3-Quants bis zu +10 % zusätzliche Top-1-Genauigkeit bei gleichem Speicherplatz! Alle Diagramme entfernen den MTP-Head von der x-Achse bei der Berechnung des Speicherplatzes, um einen fairen Vergleich mit allen zu ermöglichen.

### :dove:Nicht überangepasst Beim Vergleich mit unserem älteren UD-2 auf ungesehenem Wikitext und Code zeigen wir eine starke Verbesserung bei KLD – bei den größeren jedoch nicht so sehr, daher verwenden wir für die größeren Quants weiterhin unser altes UD-2 – wir planen, auch dort zu experimentieren und zu verbessern! Wir kontrollieren Overfitting auch, indem wir für Kalibrierung und Bewertung völlig unterschiedliche Datensätze verwenden und alle Leckagen so weit wie möglich entfernen. Wir testen KLD auf diesen ungesehenen Datensätzen, und außerdem machen wir KEIN QAD / QAT, sondern nur reines PTQ, sodass Overfitting im Vergleich zu anderen QAD / QAT-Ansätzen weniger problematisch ist.

Ebenso [#divergence-300-32](#divergence-300-32 "mention") verwendet einen ungesehenen Datensatz mit 300 Prompts aus DeepSWE, Terminal Bench und anderen und dient als weiterer Datensatz zur Bewertung von Overfitting – und zeigt, dass unsere neuen UD-3-Methoden nicht overfitten. *** ## Dynamic v2.0 (Alt) Wir führen ein [Unsloth](https://github.com/unslothai/unsloth) Dynamic v2.0-Quantisierung ein – ein großes Upgrade gegenüber unseren vorherigen Quants. Diese neue Methode übertrifft führende Quantisierungsmethoden und setzt neue Benchmarks für [Aider Polyglot](/docs/de/grundlagen/dynamic-3.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md), 5-Shot-MMLU und KL-Divergenz. Das bedeutet, dass Sie jetzt [quantisierte LLMs](/docs/de/modelle/tutorials.md) ausführen und feinabstimmen können, während möglichst viel Genauigkeit erhalten bleibt! Sie können die 2.0-GGUFs auf den meisten Inferenz-Engines wie llama.cpp ausführen, [Unsloth Studio](/docs/de/neu/studio.md) usw. {% columns %} {% column %} **Update vom 20. Apr. 2026:** Sehen Sie unsere neuen GGUF-Benchmarks für [Qwen3.6](/docs/de/modelle/qwen3.6.md#unsloth-gguf-benchmarks) und [Gemma 4](/docs/de/modelle/gemma-4.md#unsloth-gguf-benchmarks). [Update vom 27. Feb. 2026:](/docs/de/modelle/qwen3.5/gguf-benchmarks.md) **Qwen3.5** ist da und wir haben einige Probleme mit Chat-Templates für das Tool-Calling behoben und jeden GGUF hinsichtlich Perplexity und KL-Divergenz benchmarked. [Siehe Benchmarks!](/docs/de/modelle/qwen3.5/gguf-benchmarks.md) Der **zentrale Vorteil** bei der Verwendung des [Unsloth-Pakets](https://github.com/unslothai/unsloth) und Quants ist unsere aktive Rolle beim Beheben von Fehlern in großen Modellen. Wir haben direkt mit Teams zusammengearbeitet hinter [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) und [Microsoft (Phi-3/4)](https://simonwillison.net/2025/Jan/11/phi-4-bug-fixes), und dabei Korrekturen beigetragen, die die Genauigkeit erhöhen. {% endcolumn %} {% column %}

Gemma 4 26B A4B-Benchmarks (niedriger ist besser)

{% endcolumn %} {% endcolumns %} {% hint style="success" %} Unsloth Dynamic GGUFs können jetzt ausgeführt werden in [Unsloth Studio](/docs/de/neu/studio.md) ✨

{% endhint %} {% hint style="success" %} [Update vom 10. Sept. 2025:](/docs/de/grundlagen/dynamic-3.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md) Ihr habt nach härteren Benchmarks gefragt, also hier sind die Aider-Polyglot-Ergebnisse! Unser Dynamic-3-bit-DeepSeek-V3.1-GGUF erzielt **75.6%**, und übertrifft damit viele vollständige SOTA-LLMs. [Mehr lesen.](/docs/de/grundlagen/dynamic-3.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md) DeepSeek-V3.2 Thinking Aider Benchmarks

{% endhint %} Sie können sich auch reale Anwendungsfall-Benchmarks ansehen, die von Benjamin Marie für LiveCodeBench v6, MMLU Pro usw. durchgeführt wurden:

Sie können sehen, dass Unsloths GGUFs besser abschneiden als die Non-Unsloth-Quants, obwohl sie \~8 GB kleiner sind. Detaillierte Analyse unserer Benchmarks und Evaluierung weiter unten. ### 💡 Was ist neu in Dynamic v2.0? * **Überarbeitete Schichtauswahl für GGUFs + safetensors:** Unsloth Dynamic 2.0 quantisiert jetzt Schichten selektiv deutlich intelligenter und umfassender. Anstatt nur ausgewählte Schichten zu verändern, passen wir nun dynamisch den Quantisierungstyp jeder möglichen Schicht an, und die Kombinationen unterscheiden sich je nach Schicht und Modell. * Derzeit ausgewählte und alle zukünftigen GGUF-Uploads werden Dynamic 2.0 und unseren neuen Kalibrierungsdatensatz nutzen. Der Datensatz enthält mehr als >1,5 Mio. **Tokens** (je nach Modell) und besteht aus hochwertigen, handkuratierten und bereinigten Daten – um die Gesprächsleistung deutlich zu verbessern. * Zuvor war unsere Dynamic-Quantisierung (DeepSeek-R1 1,58-bit GGUF) nur für MoE-Architekturen wirksam. **Dynamic 2.0-Quantisierung funktioniert jetzt bei allen Modellen (einschließlich MOEs und Nicht-MOEs)**. * **Modellspezifische Quants:** Jedes Modell verwendet jetzt ein maßgeschneidertes Quantisierungsschema. Z. B. unterscheiden sich die in Gemma 3 quantisierten Schichten deutlich von denen in Llama 4. * Um die Effizienz zu maximieren, insbesondere auf Apple-Silicon- und ARM-Geräten, fügen wir jetzt auch die Formate Q4\_NL, Q5.1, Q5.0, Q4.1 und Q4.0 hinzu. Um ein genaues Benchmarking zu gewährleisten, haben wir ein internes Evaluierungsframework gebaut, das die offiziell berichteten 5-Shot-MMLU-Werte von Llama 4 und Gemma 3 nachbildet. Dies ermöglichte einen Vergleich von Äpfeln mit Äpfeln zwischen voller Präzision und Dynamic v2.0, **QAT** und standardmäßigen **imatrix** GGUF-Quants.

Alle zukünftigen GGUF-Uploads werden Unsloth Dynamic 2.0 nutzen, und unsere Dynamic-4-bit-Safetensor-Quants werden davon in Zukunft ebenfalls profitieren. ## 📊 Warum KL-Divergenz? [Genauigkeit ist nicht alles, was Sie brauchen](https://arxiv.org/pdf/2407.09141) zeigt, wie das Beschneiden von Schichten, selbst wenn unnötige ausgewählt werden, immer noch enorme Unterschiede in Bezug auf „Flips“ erzeugt. Ein „Flip“ ist definiert als der Wechsel von falschen zu richtigen Antworten oder umgekehrt. Das Papier zeigt, wie MMLU möglicherweise nicht sinkt, wenn wir Schichten beschneiden oder quantisieren, aber das liegt daran, dass einige falsche Antworten möglicherweise „geflippt“ sind und korrekt wurden. Unser Ziel ist es, das ursprüngliche Modell zu reproduzieren, daher ist die Messung von „Flips“ eine gute Metrik.

{% hint style="info" %} **KL-Divergenz** sollte **einer der Goldstandards für die Berichterstattung über Quantisierungsfehler sein** gemäß dem Forschungspapier „Accuracy is Not All You Need“. **Perplexity zu verwenden ist falsch** da sich Ausgabetoken-Werte aufheben können, also müssen wir KLD oder härtere Benchmarks wie [Aider](/docs/de/grundlagen/dynamic-3.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot.md). {% endhint %} Das Papier zeigt auch interessanterweise, dass KL-Divergenz stark mit Flips korreliert, und unser Ziel ist es daher, die mittlere KL-Divergenz zu verringern und gleichzeitig den benötigten Speicherplatz der Quantisierung so wenig wie möglich zu erhöhen. ## ⚖️ Überanpassung des Kalibrierungsdatensatzes Die meisten Frameworks berichten Perplexity und KL-Divergenz mithilfe eines Testdatensatzes aus Wikipedia-Artikeln. Wir haben jedoch festgestellt, dass die Verwendung des Kalibrierungsdatensatzes, der ebenfalls Wikipedia-bezogen ist, dazu führt, dass Quants overfitten und niedrigere Perplexity-Werte erzielen. Wir verwenden [Calibration\_v3](https://gist.github.com/bartowski1182/eb213dccb3571f863da82e99418f81e8) und [Calibration\_v5](https://gist.github.com/tristandruyen/9e207a95c7d75ddf37525d353e00659c/) Datensätze für faire Tests, die unter anderem einige Wikitext-Daten enthalten. **Außerdem haben Instruct-Modelle einzigartige Chat-Templates, und die Verwendung reiner Text-Kalibrierungsdatensätze ist für Instruct-Modelle nicht effektiv** (bei Basismodellen schon). Tatsächlich werden die meisten imatrix-GGUFs typischerweise mit diesen Problemen kalibriert. Dadurch schneiden sie bei KL-Divergenz-Benchmarks, die ebenfalls Wikipedia-Daten verwenden, natürlicherweise besser ab, da das Modell im Wesentlichen für diese Domäne optimiert ist. Um eine faire und kontrollierte Bewertung sicherzustellen, verwenden wir unseren eigenen Kalibrierungsdatensatz (der für Chat-Leistung optimiert ist) nicht beim Benchmarking der KL-Divergenz. Stattdessen führten wir Tests mit denselben standardmäßigen Wikipedia-Datensätzen durch, was uns erlaubte, die Leistung unserer Dynamic-2.0-Methode direkt mit dem Basis-imatrix-Ansatz zu vergleichen. ## :1234: Abenteuer der MMLU-Replikation * Die Replikation von MMLU 5-shot war ein Albtraum. Wir **konnten nicht** MMLU-Ergebnisse für viele Modelle replizieren, darunter Llama 3.1 (8B) Instruct, Gemma 3 (12B) und andere, aufgrund von **subtilen Implementierungsproblemen**. Llama 3.1 (8B) sollte zum Beispiel \~68,2 % erreichen, während fehlerhafte Implementierungen **35 % Genauigkeit erzielen können.**

* Llama 3.1 (8B) Instruct hat mit einer naiven MMLU-Implementierung eine MMLU-5-Shot-Genauigkeit von 67,8 %. Wir stellen jedoch fest, dass Llama **tokenisiert „A“ und „\_A“ (A mit Leerzeichen davor) als unterschiedliche Token-IDs**. Wenn wir sowohl Tokens mit als auch ohne Leerzeichen berücksichtigen, erhalten wir 68,2 % (+0.4%) * Interessanterweise hängt Llama 3 laut Eleuther AIs [LLM Harness](https://github.com/EleutherAI/lm-evaluation-harness/blob/main/lm_eval/tasks/llama3/instruct/mmlu/_continuation_template_yaml) fügt auch **„Die beste Antwort ist“** an die Frage an, entsprechend Llama 3s ursprünglichen MMLU-Benchmarks. * Es gibt viele weitere subtile Probleme, und um alles in einer kontrollierten Umgebung zu benchmarken, haben wir unsere eigene MMLU-Implementierung von Grund auf entworfen, indem wir direkt [github.com/hendrycks/test](https://github.com/hendrycks/test) untersucht und unsere Ergebnisse über mehrere Modelle hinweg verifiziert und mit berichteten Zahlen verglichen haben. ## :sparkles: Gemma 3 QAT-Replikation, Benchmarks Das Gemma-Team veröffentlichte zwei QAT-(Quantisierung-bewusstes Training-)Versionen von Gemma 3: 1. Q4\_0 GGUF – quantisiert alle Schichten auf Q4\_0 mittels der Formel `w = q * block_scale` wobei jeder Block 32 Gewichte hat. Siehe [llama.cpp-Wiki ](https://github.com/ggml-org/llama.cpp/wiki/Tensor-Encoding-Schemes)für weitere Details. 2. int4-Version – vermutlich [TorchAO-int4-Stil](https://github.com/pytorch/ao/blob/main/torchao/quantization/README.md)? Wir haben alle Q4\_0-GGUF-Versionen benchmarked und umfangreiche Experimente am 12B-Modell durchgeführt. Wir sehen, dass das **12B Q4\_0 QAT-Modell 67,07 % erreicht** während die vollständige bfloat16-12B-Version 67,15 % bei 5-Shot-MMLU erreicht. Das ist sehr beeindruckend! Das 27B-Modell ist größtenteils schon fast dort!

Metrik	1B	4B	12B	27B
MMLU 5-Shot	26.12%	55.13%	67,07 % (67,15 % BF16)	70,64 % (71,5 % BF16)
Speicherplatz	0,93 GB	2,94 GB	7,52 GB	16,05 GB
Effizienz*	1.20	10.26	5.59	2.84

Wir haben eine neue **Effizienzmetrik** entwickelt, die den Nutzen des Modells berechnet und dabei auch seine Festplattengröße und den MMLU-5-Shot-Score berücksichtigt: $$ \text{Efficiency} = \frac{\text{MMLU 5 shot score} - 25}{\text{Disk Space GB}} $$ {% hint style="warning" %} Wir müssen **minus 25** weil MMLU 4 Antwortmöglichkeiten hat – A, B, C oder D. Nehmen wir an, wir bauen ein Modell, das einfach zufällig Antworten auswählt – es würde 25 % Genauigkeit erzielen und nur wenige Bytes Festplattenspeicher belegen. Aber klarerweise ist das kein nützliches Modell. {% endhint %} Zur KL-Divergenz gegenüber dem Basismodell zeigt die folgende Tabelle die Verbesserungen. Erinnerung: Je näher die KL-Divergenz bei 0 liegt, desto besser (d. h. 0 bedeutet identisch mit dem Modell voller Präzision) | Quant | Basis-KLD | GB | Neue KLD | GB | | --------- | --------- | ----- | -------- | ----- | | 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 | Wenn wir das Verhältnis aus der Zunahme des Speicherplatzes und der Änderung des KL-Divergenz-Verhältnisses auftragen, sehen wir einen viel klareren Vorteil! Unser dynamisches 2bit Q2\_K\_XL reduziert KLD deutlich (etwa 7,5 %).

Gekürzte Ergebnistabelle für MMLU für Gemma 3 (27B). Siehe unten. 1. **Unsere dynamische 4-bit-Version ist 2 GB kleiner und hat gleichzeitig +1 % zusätzliche Genauigkeit gegenüber der QAT-Version!** 2. Was die Effizienz angeht, scheinen 2bit Q2\_K\_XL und andere sehr gut abzuschneiden! | Quant | Unsloth | Unsloth + QAT | Festplattengröße | Effizienz | | -------------- | --------- | ------------- | ---------------- | --------- | | 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** |

Hier klicken für vollständige Benchmarks von Googles Gemma 3 (27B) QAT:

| Modell | Unsloth | Unsloth + QAT | Festplattengröße | Effizienz | | -------------- | --------- | ------------- | ---------------- | --------- | | 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** |

## :llama: Llama 4 Fehlerbehebungen + Ausführen Wir haben außerdem bei einigen Llama-4-Fehlern geholfen und sie behoben: * Llama 4 Scout hat die RoPE-Scaling-Konfiguration in ihrem offiziellen Repo geändert. Wir haben geholfen, Probleme in llama.cpp zu lösen, um dies zu ermöglichen [Änderung hier](https://github.com/ggml-org/llama.cpp/pull/12889)

* Llama 4s QK-Norm-Epsilon für sowohl Scout als auch Maverick sollte aus der Konfigurationsdatei stammen – das bedeutet 1e-05 und nicht 1e-06 zu verwenden. Wir haben bei der Behebung dieser Probleme in [llama.cpp](https://github.com/ggml-org/llama.cpp/pull/12889) und [transformers](https://github.com/huggingface/transformers/pull/37418) * Das Llama-4-Team und vLLM haben außerdem unabhängig ein Problem behoben, bei dem QK Norm über alle Heads geteilt wurde (sollte nicht so sein) [hier](https://github.com/vllm-project/vllm/pull/16311). MMLU Pro stieg von 68,58 % auf 71,53 % Genauigkeit. * [Wolfram Ravenwolf](https://x.com/WolframRvnwlf/status/1909735579564331016) zeigte, dass unsere GGUFs über llama.cpp eine deutlich höhere Genauigkeit erreichen als Inferenzanbieter von Drittanbietern – dies war sehr wahrscheinlich eine Kombination aus den oben erklärten Problemen und vermutlich auch auf Quantisierungsprobleme zurückzuführen.

Wie in unserem Diagramm gezeigt, liefert unsere 4-bit Dynamic QAT-Quantisierung eine bessere Leistung bei 5-Shot-MMLU und ist gleichzeitig kleiner. ### Llama 4 Scout ausführen: Um beispielsweise Llama 4 Scout auszuführen, klonen Sie zunächst 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 ``` Laden Sie dann unsere neue Dynamic-v2.0-Quantisierung für Scout herunter: ```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*"], ) ``` Und los geht's mit der Inferenz! {% 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\nErstelle ein Flappy-Bird-Spiel.<|eot|><|header_start|>assistant<|header_end|>\n\n" ``` {% endcode %} {% hint style="success" %} Mehr zum Ausführen von Llama 4 hier lesen: {% 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/de/grundlagen/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.