> 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/jp/moderu/tutorials/grok-2.md). # Grok 2 xAIのGrok 2モデルをローカルで実行しましょう！ これで実行できます **Grok 2** （別名 Grok 2.5）、xAI の 2700億パラメータモデルです。フル精度には **539GB**が必要ですが、Unsloth Dynamic 3-bit版ではサイズがわずか **118GB** になります（75%削減）。GGUF： [Grok-2-GGUF](https://huggingface.co/unsloth/grok-2-GGUF) その **3-bit Q3\_K\_XL** モデルは単一の **128GB Mac** または **24GB VRAM + 128GB RAM**で、 **5+ tokens/s** の推論速度を達成します。llama.cpp チームとコミュニティの [Grok 2 のサポートと](https://github.com/ggml-org/llama.cpp/pull/15539) この実現に感謝します。私たちも途中で少しお手伝いできてうれしかったです！ すべてのアップロードは Unsloth の [Dynamic 2.0](/docs/jp/ji-chu/dynamic-3.0-ggufs.md) SOTA の 5-shot MMLU および KL Divergence 性能のため、量子化された Grok LLM を精度低下を最小限にして実行できることを意味します。 llama.cppで実行するチュートリアル ## :gear: 推奨設定 3-bit の動的量子化は 118GB（126GiB）のディスク容量を使用します。これは 128GB RAM のユニファイドメモリMac、または 1x24GB カードと 128GB RAM でうまく動作します。この 3-bit 量子化を実行するには、少なくとも 120GB RAM を推奨します。 {% hint style="warning" %} 使用する必要があります `--jinja` Grok 2 用です。 `--jinja` {% endhint %} 8-bit の量子化はサイズが約 300GB で、1x 80GB GPU（MoE レイヤーを RAM にオフロード）に収まります。加えて 200GB の RAM もあれば、この構成で約 5 tokens/s が期待できます。生成速度を上げてより長いコンテキストに対応する方法を学ぶには、 [こちらを読む](#improving-generation-speed). {% hint style="info" %} 必須ではありませんが、最高の性能のためには、VRAM + RAM の合計がダウンロードする量子化版のサイズと同じになるようにしてください。そうでない場合でも、ハードドライブ / SSD へのオフロードは llama.cpp で動作しますが、推論は遅くなります。 {% endhint %} ### サンプリングパラメータ * Grok 2 の最大コンテキスト長は 128K なので、 `131,072` コンテキスト以下を使用してください。 * 次を使います: `--jinja` llama.cpp 版用 モデルを実行するための公式サンプリングパラメータはないため、ほとんどのモデルでは標準のデフォルトを使用できます： * 次を設定してください **temperature = 1.0** * **Min\_P = 0.01** （任意ですが、0.01 はよく機能します。llama.cpp のデフォルトは 0.1 です） ## Grok 2 チュートリアルを実行： 現在、Grok 2 を実行できるのは llama.cpp のみです。 ### ✨ llama.cpp で実行 {% stepper %} {% step %} 特定の `llama.cpp` Grok 2 用 PR を [GitHubこちら](https://github.com/ggml-org/llama.cpp/pull/15539)。以下のビルド手順に従うこともできます。変更してください `-DGGML_CUDA=ON` を `-DGGML_CUDA=OFF` GPUがない場合、またはCPU推論のみを使いたい場合は。 **Apple Mac / Metalデバイスの場合**、次を設定します `-DGGML_CUDA=OFF` その後は通常どおり続けてください。Metalサポートはデフォルトで有効です。 ```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 %} を使いたい場合は `llama.cpp` モデルを直接読み込むには、以下のようにできます：（:Q3\_K\_XL）は量子化タイプです。Hugging Face（3番）からダウンロードすることもできます。これは次と似ています `ollama run` に似ています。 `export LLAMA_CACHE="folder"` を使って `llama.cpp` で、特定の場所に保存するためのものです。モデルの最大コンテキスト長は 128K であることを忘れないでください。 {% hint style="info" %} ぜひお試しください `-ot ".ffn_.*_exps.=CPU"` を試して、すべての MoE 層を CPU にオフロードしてください！これにより、非MoE層すべてを1枚のGPUに収められるようになり、生成速度が向上します。GPU容量がさらにあれば、正規表現を調整してより多くの層を収めることもできます。 GPU メモリがもう少し多ければ、 `-ot ".ffn_(up|down)_exps.=CPU"` を試してください。これは up と down の projection MoE 層をオフロードします。 試してみてください `-ot ".ffn_(up)_exps.=CPU"` GPU メモリがさらに多い場合はこちら。これは up projection の MoE 層のみをオフロードします。 そして最後に、すべての層を `-ot ".ffn_.*_exps.=CPU"` でオフロードします。 これは最も少ない VRAM を使用します。 `-ot "\.(6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(gate|up|down)_exps.=CPU"` は、6層目以降から gate、up、down の MoE 層をオフロードすることを意味します。 {% 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 %} 以下をインストールした後、( `pip install huggingface_hub hf_transfer` をインストール後）。 `UD-Q3_K_XL` （dynamic 3-bit 量子化）や、次のような他の量子化版 `Q4_K_M` をインストールした後で）。 **2.7bit の動的量子化版を使うことを推奨します**** ****`UD-Q2_K_XL`**** ****など、サイズと精度のバランスを取るための**. ```python # !pip install huggingface_hub hf_transfer import os os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "0" # 速度制限されることがあるため、無効化するには 0 に設定 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*"], # 動的 3bit ) ``` {% endstep %} {% step %} 編集できます `--threads 32` CPUスレッド数は `--ctx-size 16384` コンテキスト長は `--n-gpu-layers 2` GPUオフロードする層数です。GPUがメモリ不足になったら調整してみてください。CPUのみで推論する場合は削除してください。 {% 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 %} ## モデルのアップロード **すべてのアップロード** - その中には imatrix ベースでも動的でもないものも含まれますが、会話、コーディング、言語タスク向けに特別に最適化されたキャリブレーションデータセットを使用しています。 | MoE ビット数 | 種類 + リンク | ディスクサイズ | 詳細 | | -------- | ----------------------------------------------------------------------------------- | ----------- | ------------- | | 1.66bit | [TQ1\_0](https://huggingface.co/unsloth/grok-2-GGUF/blob/main/grok-2-UD-TQ1_0.gguf) | **81.8 GB** | 1.92/1.56bit | | 1.78bit | [IQ1\_S](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-IQ1_S) | **88.9 GB** | 2.06/1.56bit | | 1.93bit | [IQ1\_M](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-IQ1_M) | **94.5 GB** | 2.5/2.06/1.56 | | 2.42bit | [IQ2\_XXS](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-IQ2_XXS) | **99.3 GB** | 2.5/2.06bit | | 2.71bit | [Q2\_K\_XL](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-Q2_K_XL) | **112 GB** | 3.5/2.5bit | | 3.12bit | [IQ3\_XXS](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-IQ3_XXS) | **117 GB** | 3.5/2.06bit | | 3.5bit | [Q3\_K\_XL](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-Q3_K_XL) | **126 GB** | 4.5/3.5bit | | 4.5bit | [Q4\_K\_XL](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-Q4_K_XL) | **155 GB** | 5.5/4.5bit | | 5.5bit | [Q5\_K\_XL](https://huggingface.co/unsloth/grok-2-GGUF/tree/main/UD-Q5_K_XL) | **191 GB** | 6.5/5.5bit | ## :snowboarder: 生成速度の向上 VRAM がさらにあれば、より多くの MoE 層、または層全体のオフロードを試せます。 通常は、 `-ot ".ffn_.*_exps.=CPU"` すべての MoE 層を CPU にオフロードします！これにより、非MoE層すべてを1枚のGPUに収められるようになり、生成速度が向上します。GPU容量がさらにあれば、正規表現を調整してより多くの層を収めることもできます。 GPU メモリがもう少し多ければ、 `-ot ".ffn_(up|down)_exps.=CPU"` を試してください。これは up と down の projection MoE 層をオフロードします。 試してみてください `-ot ".ffn_(up)_exps.=CPU"` GPU メモリがさらに多い場合はこちら。これは up projection の MoE 層のみをオフロードします。 これは最も少ない VRAM を使用します。 `-ot "\.(6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(gate|up|down)_exps.=CPU"` は、6層目以降から gate、up、down の MoE 層をオフロードすることを意味します。 その [最新のllama.cppリリース](https://github.com/ggml-org/llama.cpp/pull/14363) には高スループットモードも導入されています。 `llama-parallel`を使用してください。 [ここ](https://github.com/ggml-org/llama.cpp/tree/master/examples/parallel)について詳しくはこちらを読む **KV キャッシュを 4bit に量子化する** ことで、VRAM / RAM の移動を減らし、生成処理をさらに高速化できます。 ## 📐 長いコンテキスト（最大 128K）に対応させる方法 より長いコンテキストに対応するには、 **KV キャッシュ量子化** を使って K と V のキャッシュをより低い bit に量子化できます。これにより、RAM / VRAM のデータ移動が減るため生成速度も上がります。K の量子化で使用できるオプション（デフォルトは `f16`）は以下の通りです。 `--cache-type-k f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1` 少し精度が向上する `_1` 版を使うべきです。少し遅くなりますが。たとえば `q4_1, q5_1` V キャッシュも量子化できますが、その場合は **Flash Attention 対応で llama.cpp をコンパイルする必要があります** を `-DGGML_CUDA_FA_ALL_QUANTS=ON`で有効にし、 `--flash-attn` を使って有効化します。その後、 `--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/jp/moderu/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.