> 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/modelle/tutorials/grok-2.md). # Grok 2 Führe xAIs Grok-2-Modell lokal aus! Du kannst jetzt **Grok 2** (auch bekannt als Grok 2.5), das 270B-Parameter-Modell von xAI. Volle Präzision erfordert **539 GB**, während die Unsloth Dynamic 3-Bit-Version die Größe auf nur **118 GB** (eine Reduzierung um 75 %). GGUF: [Grok-2-GGUF](https://huggingface.co/unsloth/grok-2-GGUF) Der **3-Bit Q3\_K\_XL** Modell läuft auf einem einzigen **128-GB-Mac** oder **24 GB VRAM + 128 GB RAM**, wodurch **mehr als 5 Token/s** Inference. Dank an das llama.cpp-Team und die Community für [die Unterstützung von Grok 2](https://github.com/ggml-org/llama.cpp/pull/15539) und das möglich zu machen. Wir haben uns außerdem gefreut, unterwegs ein wenig geholfen zu haben! Alle Uploads verwenden Unsloth [Dynamic 2.0](/docs/de/grundlagen/dynamic-3.0-ggufs.md) für SOTA 5-Shot-MMLU- und KL-Divergenz-Performance, was bedeutet, dass Sie quantisierte Grok-LLMs mit minimalem Genauigkeitsverlust ausführen können. Tutorial zur Ausführung in llama.cpp ## :gear: Empfohlene Einstellungen Die dynamische 3-Bit-Quantisierung benötigt 118 GB (126 GiB) Festplattenspeicher – das funktioniert gut auf einem Mac mit 128 GB RAM und Unified Memory oder auf einer einzelnen 24-GB-Karte und 128 GB RAM. Es wird empfohlen, mindestens 120 GB RAM zu haben, um diese 3-Bit-Quantisierung auszuführen. {% hint style="warning" %} Sie müssen `--jinja` für Grok 2. Sie könnten falsche Ergebnisse erhalten, wenn Sie nicht `--jinja` {% endhint %} Die 8-Bit-Quantisierung ist mit \~300 GB groß und passt auf eine einzelne 80-GB-GPU (wobei MoE-Schichten in den RAM ausgelagert werden). Erwarten Sie mit diesem Setup etwa 5 Token/s, wenn Sie zusätzlich 200 GB RAM haben. Um zu erfahren, wie Sie die Generierungsgeschwindigkeit erhöhen und längere Kontexte unterbringen können, [lesen Sie hier](#improving-generation-speed). {% hint style="info" %} Obwohl es nicht zwingend erforderlich ist, sollte für beste Leistung Ihr kombinierter VRAM + RAM der Größe der heruntergeladenen Quantisierung entsprechen. Andernfalls funktioniert das Auslagern auf Festplatte/SSD mit llama.cpp, die Inferenz wird jedoch langsamer sein. {% endhint %} ### Sampling-Parameter * Grok 2 hat eine maximale Kontextlänge von 128K, daher verwenden Sie `131,072` Kontext oder weniger. * Verwenden Sie `--jinja` für llama.cpp-Varianten Es gibt keine offiziellen Sampling-Parameter, um das Modell auszuführen, daher können Sie für die meisten Modelle die Standardwerte verwenden: * Setzen Sie **temperature = 1.0** * **Min\_P = 0.01** (optional, aber 0.01 funktioniert gut, der Standardwert von llama.cpp ist 0.1) ## Tutorial zum Ausführen von Grok 2: Derzeit können Sie Grok 2 nur in llama.cpp ausführen. ### ✨ In llama.cpp ausführen {% stepper %} {% step %} Installieren Sie den spezifischen `llama.cpp` PR für Grok 2 auf [hier auf GitHub](https://github.com/ggml-org/llama.cpp/pull/15539). Sie können auch die folgenden Build-Anweisungen befolgen. Ändern Sie `-DGGML_CUDA=ON` zu `-DGGML_CUDA=OFF` wenn Sie keine GPU haben oder nur CPU-Inferenz möchten. **Für Apple-Mac-/Metal-Geräte**, setzen Sie `-DGGML_CUDA=OFF` und fahren Sie dann wie gewohnt fort – Metal-Unterstützung ist standardmäßig aktiviert. ```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 cd llama.cpp && git fetch origin pull/15539/head:MASTER && git checkout MASTER && cd .. 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-quantize llama-cli llama-gguf-split llama-mtmd-cli llama-server cp llama.cpp/build/bin/llama-* llama.cpp ``` {% endstep %} {% step %} Wenn Sie `llama.cpp` um Modelle direkt zu laden, können Sie Folgendes tun: (:Q3\_K\_XL) ist der Quantisierungstyp. Sie können auch über Hugging Face herunterladen (Punkt 3). Dies ist ähnlich wie `ollama run` . Verwenden Sie `export LLAMA_CACHE="folder"` um zu erzwingen `llama.cpp` um an einem bestimmten Ort zu speichern. Denken Sie daran, dass das Modell nur eine maximale Kontextlänge von 128K hat. {% hint style="info" %} Bitte probieren Sie `-ot ".ffn_.*_exps.=CPU"` um alle MoE-Layer auf die CPU auszulagern! Dadurch können Sie effektiv alle Nicht-MoE-Layer auf 1 GPU unterbringen, was die Generierungsgeschwindigkeit verbessert. Sie können den Regex-Ausdruck anpassen, um mehr Layer unterzubringen, wenn Sie mehr GPU-Kapazität haben. Wenn Sie etwas mehr GPU-Speicher haben, versuchen Sie `-ot ".ffn_(up|down)_exps.=CPU"` Dadurch werden Up- und Down-Projektions-MoE-Layer ausgelagert. Versuchen Sie `-ot ".ffn_(up)_exps.=CPU"` wenn Sie noch mehr GPU-Speicher haben. Dadurch werden nur Up-Projektions-MoE-Layer ausgelagert. Und schließlich alle Layer auslagern über `-ot ".ffn_.*_exps.=CPU"` Dies verwendet am wenigsten VRAM. Sie können den Regex auch anpassen, zum Beispiel `-ot "\.(6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(gate|up|down)_exps.=CPU"` bedeutet, Gate-, Up- und Down-MoE-Layer auszulagern, aber nur ab dem 6. Layer aufwärts. {% endhint %} ```bash export LLAMA_CACHE="unsloth/grok-2-GGUF" ./llama.cpp/llama-cli \\ -hf unsloth/grok-2-GGUF:Q3_K_XL \\ --jinja \ --n-gpu-layers 99 \\ --temp 1.0 \\ --top-p 0.95 \\ --min-p 0.01 \\ --ctx-size 16384 \\ --seed 3407 \\ -ot ".ffn_.*_exps.=CPU" ``` {% endstep %} {% step %} Lade das Modell über (nach der Installation von `pip install huggingface_hub hf_transfer` ). Sie können `UD-Q3_K_XL` (dynamische 3-Bit-Quantisierung) oder andere quantisierte Versionen wie `Q4_K_M` . Wir **empfehlen unsere dynamische 2,7-Bit-Quantisierung**** ****`UD-Q2_K_XL`**** ****oder höher, um Größe und Genauigkeit auszubalancieren**. ```python # !pip install huggingface_hub hf_transfer import os os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "0" # Kann manchmal durch Ratenbegrenzung gebremst werden, daher auf 0 setzen, um zu deaktivieren from huggingface_hub import snapshot_download snapshot_download( repo_id = "unsloth/grok-2-GGUF", local_dir = "unsloth/grok-2-GGUF", allow_patterns = ["*UD-Q3_K_XL*"], # Dynamische 3-Bit ) ``` {% endstep %} {% step %} Du kannst `--threads 32` für die Anzahl der CPU-Threads, `--ctx-size 16384` für die Kontextlänge, `--n-gpu-layers 2` für GPU-Offloading auf wie viele Layer. Versuche, ihn anzupassen, wenn deiner GPU der Speicher ausgeht. Entferne ihn auch, wenn du nur CPU-Inferenz hast. {% code overflow="wrap" %} ```bash ./llama.cpp/llama-cli \\ --model unsloth/grok-2-GGUF/UD-Q3_K_XL/grok-2-UD-Q3_K_XL-00001-of-00003.gguf \\ --jinja \ --threads -1 \\ --n-gpu-layers 99 \\ --temp 1.0 \\ --top-p 0.95 \\ --min-p 0.01 \\ --ctx-size 16384 \\ --seed 3407 \\ -ot ".ffn_.*_exps.=CPU" ``` {% endcode %} {% endstep %} {% endstepper %} ## Modell-Uploads **ALLE unsere Uploads** - einschließlich derjenigen, die nicht auf imatrix basieren oder dynamisch sind, nutzen unser Kalibrierungsdatenset, das speziell für Gesprächs-, Coding- und Sprachaufgaben optimiert ist. | MoE-Bits | Typ + Link | Festplattengröße | Details | | -------- | ----------------------------------------------------------------------------------- | ---------------- | ------------- | | 1,66 Bit | [TQ1\_0](https://huggingface.co/unsloth/grok-2-GGUF/blob/main/grok-2-UD-TQ1_0.gguf) | **81,8 GB** | 1,92/1,56 Bit | | 1,78 Bit | [IQ1\_S](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-IQ1_S) | **88,9 GB** | 2,06/1,56 Bit | | 1,93 Bit | [IQ1\_M](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-IQ1_M) | **94,5 GB** | 2.5/2.06/1.56 | | 2,42 Bit | [IQ2\_XXS](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-IQ2_XXS) | **99,3 GB** | 2,5/2,06 Bit | | 2,71 Bit | [Q2\_K\_XL](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-Q2_K_XL) | **112 GB** | 3,5/2,5 Bit | | 3,12 Bit | [IQ3\_XXS](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-IQ3_XXS) | **117 GB** | 3,5/2,06 Bit | | 3,5 Bit | [Q3\_K\_XL](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-Q3_K_XL) | **126 GB** | 4,5/3,5 Bit | | 4,5 Bit | [Q4\_K\_XL](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-Q4_K_XL) | **155 GB** | 5,5/4,5 Bit | | 5,5 Bit | [Q5\_K\_XL](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-Q5_K_XL) | **191 GB** | 6,5/5,5 Bit | ## :snowboarder: Die Generierungsgeschwindigkeit verbessern Wenn Sie mehr VRAM haben, können Sie versuchen, mehr MoE-Layer oder ganze Layer selbst auszulagern. Normalerweise `-ot ".ffn_.*_exps.=CPU"` lagert alle MoE-Layer auf die CPU aus! Dadurch können Sie effektiv alle Nicht-MoE-Layer auf 1 GPU unterbringen, was die Generierungsgeschwindigkeit verbessert. Sie können den Regex-Ausdruck anpassen, um mehr Layer unterzubringen, wenn Sie mehr GPU-Kapazität haben. Wenn Sie etwas mehr GPU-Speicher haben, versuchen Sie `-ot ".ffn_(up|down)_exps.=CPU"` Dadurch werden Up- und Down-Projektions-MoE-Layer ausgelagert. Versuchen Sie `-ot ".ffn_(up)_exps.=CPU"` wenn Sie noch mehr GPU-Speicher haben. Dadurch werden nur Up-Projektions-MoE-Layer ausgelagert. Sie können den Regex auch anpassen, zum Beispiel `-ot "\.(6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(gate|up|down)_exps.=CPU"` bedeutet, Gate-, Up- und Down-MoE-Layer auszulagern, aber nur ab dem 6. Layer aufwärts. Der [neueste llama.cpp-Version](https://github.com/ggml-org/llama.cpp/pull/14363) führt außerdem den High-Throughput-Modus ein. Verwenden Sie `llama-parallel`. Lesen Sie mehr darüber [hier](https://github.com/ggml-org/llama.cpp/tree/master/examples/parallel). Sie können auch **den KV-Cache auf 4 Bit quantisieren** zum Beispiel, um VRAM-/RAM-Bewegungen zu reduzieren, was den Generierungsprozess ebenfalls beschleunigen kann. ## 📐Wie man langen Kontext unterbringt (volle 128K) Um längeren Kontext unterzubringen, können Sie **KV-Cache-Quantisierung** verwenden, um die K- und V-Caches auf niedrigere Bits zu quantisieren. Dies kann auch die Generierungsgeschwindigkeit erhöhen, da weniger RAM-/VRAM-Datenbewegung nötig ist. Die erlaubten Optionen für die K-Quantisierung (Standard ist `f16`) sind die folgenden. `--cache-type-k f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1` Sie sollten die `_1` Varianten für etwas höhere Genauigkeit verwenden, obwohl sie etwas langsamer ist. Zum Beispiel `q4_1, q5_1` Sie können auch den V-Cache quantisieren, aber dafür müssen Sie **llama.cpp mit Flash-Attention-Unterstützung kompilieren** über `-DGGML_CUDA_FA_ALL_QUANTS=ON`, und `--flash-attn` verwenden, um es zu aktivieren. Dann können Sie es zusammen mit `--cache-type-k` : `--cache-type-v f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1` --- # 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/modelle/tutorials/grok-2.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.