Speichern in GGUF

Modelle als 16-Bit für GGUF speichern, damit du sie für Ollama, Jan AI, Open WebUI und mehr verwenden kannst!

Lokal

Um in GGUF zu speichern, verwenden Sie Folgendes, um lokal zu speichern:

Unsloth unterstützt das direkte Speichern in GGUF:
model.save_pretrained_gguf("directory", tokenizer, quantization_method = "q4_k_m")
model.save_pretrained_gguf("directory", tokenizer, quantization_method = "q8_0")

Um in das Hugging Face Hub zu pushen:

Oder GGUFs zu Hugging Face hochladen:
model.push_to_hub_gguf("hf_username/directory", tokenizer, quantization_method = "q4_k_m")

Alle unterstützten Quantisierungsoptionen für quantization_method sind unten aufgeführt:

# https://github.com/ggml-org/llama.cpp/blob/master/examples/quantize/quantize.cpp#L19
ALLOWED_QUANTS = \
{
    "not_quantized"  : "Empfohlen. Schnelle Konvertierung. Langsame Inferenz, große Dateien.",
    "fast_quantized" : "Empfohlen. Schnelle Konvertierung. Akzeptable Inferenz, akzeptable Dateigröße.",
    "quantized"      : "Empfohlen. Langsame Konvertierung. Schnelle Inferenz, kleine Dateien.",
    "f32"     : "Nicht empfohlen. Beibehaltung von 100% Genauigkeit, aber sehr langsam und speicherintensiv.",
    "f16"     : "Schnellste Konvertierung + behält 100% Genauigkeit. Langsam und speicherintensiv.",
    "q8_0"    : "Schnelle Konvertierung. Hoher Ressourcenverbrauch, aber im Allgemeinen akzeptabel.",
    "q4_k_m"  : "Empfohlen. Verwendet Q6_K für die Hälfte der attention.wv- und feed_forward.w2-Tensoren, sonst Q4_K",
    "q5_k_m"  : "Empfohlen. Verwendet Q6_K für die Hälfte der attention.wv- und feed_forward.w2-Tensoren, sonst Q5_K",
    "q2_k"    : "Verwendet Q4_K für die attention.vw- und feed_forward.w2-Tensoren, Q2_K für die anderen Tensoren.",
    "q3_k_l"  : "Verwendet Q5_K für die attention.wv-, attention.wo- und feed_forward.w2-Tensoren, sonst Q3_K",
    "q3_k_m"  : "Verwendet Q4_K für die attention.wv-, attention.wo- und feed_forward.w2-Tensoren, sonst Q3_K",
    "q3_k_s"  : "Verwendet Q3_K für alle Tensoren",
    "q4_0"    : "Ursprüngliche Quantisierungsmethode, 4-Bit.",
    "q4_1"    : "Höhere Genauigkeit als q4_0, aber nicht so hoch wie q5_0. Hat jedoch schnellere Inferenz als q5-Modelle.",
    "q4_k_s"  : "Verwendet Q4_K für alle Tensoren",
    "q4_k"    : "Alias für q4_k_m",
    "q5_k"    : "Alias für q5_k_m",
    "q5_0"    : "Höhere Genauigkeit, höherer Ressourcenverbrauch und langsamere Inferenz.",
    "q5_1"    : "Noch höhere Genauigkeit, höherer Ressourcenverbrauch und langsamere Inferenz.",
    "q5_k_s"  : "Verwendet Q5_K für alle Tensoren",
    "q6_k"    : "Verwendet Q8_K für alle Tensoren",
    "iq2_xxs" : "2.06 bpw Quantisierung",
    "iq2_xs"  : "2.31 bpw Quantisierung",
    "iq3_xxs" : "3.06 bpw Quantisierung",
    "q3_k_xs" : "3-Bit extra kleine Quantisierung",
}

Manuelles Speichern

Das Ausführen in Unsloth funktioniert gut, aber nach dem Exportieren und Ausführen auf anderen Plattformen sind die Ergebnisse schlecht

Manchmal kann es vorkommen, dass Ihr Modell in Unsloth gute Ergebnisse liefert, aber wenn Sie es auf einer anderen Plattform wie Ollama oder vLLM verwenden, die Ergebnisse schlecht sind oder Sie Kauderwelsch/unsinnige, endlose/generierende Ausgaben erhalten oder wiederholte Ausgaben.

• Die häufigste Ursache für diesen Fehler ist die Verwendung einer falschen Chatvorlage. Es ist wichtig, DIE GLEICHE Chatvorlage zu verwenden, die beim Training des Modells in Unsloth verwendet wurde und später, wenn Sie es in einem anderen Framework wie llama.cpp oder Ollama ausführen. Beim Inferencing von einem gespeicherten Modell ist es entscheidend, die richtige Vorlage anzuwenden.

• Sie müssen das richtige eos-Token. Andernfalls könnten Sie bei längeren Generierungen Kauderwelsch erhalten.

• Es könnte auch daran liegen, dass Ihre Inferenz-Engine ein unnötiges "Start-of-Sequence"-Token hinzufügt (oder im Gegenteil dessen Fehlen), prüfen Sie also unbedingt beide Hypothesen!

• Verwenden Sie unsere konversationellen Notebooks, um die Chatvorlage zu erzwingen – das behebt die meisten Probleme.

  • Qwen-3 14B Konversationelles Notebook In Colab öffnen

  • Gemma-3 4B Konversationelles Notebook In Colab öffnen

  • Llama-3.2 3B Konversationelles Notebook In Colab öffnen

  • Phi-4 14B Konversationelles Notebook In Colab öffnen

  • Mistral v0.3 7B Konversationelles Notebook In Colab öffnen

  • Mehr Notebooks in unseren Notebook-Dokumentationen

Speichern in GGUF / vLLM 16bit stürzt ab

Sie können versuchen, die maximale GPU-Nutzung beim Speichern zu reduzieren, indem Sie maximum_memory_usage.

Der Standard ist model.save_pretrained(..., maximum_memory_usage = 0.75). Reduzieren Sie ihn z. B. auf 0,5, um 50% des maximalen GPU-Speichers zu verwenden oder niedriger. Dies kann OOM-Abstürze beim Speichern reduzieren.

Wie speichere ich manuell in GGUF?

Speichern Sie Ihr Modell zuerst in 16bit über:

model.save_pretrained_merged("merged_model", tokenizer, save_method = "merged_16bit",)

Kompilieren Sie llama.cpp aus dem Quellcode wie unten:

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-mtmd-cli llama-server llama-gguf-split
cp llama.cpp/build/bin/llama-* llama.cpp

Speichern Sie dann das Modell in F16:

python llama.cpp/convert_hf_to_gguf.py merged_model \
    --outfile model-F16.gguf --outtype f16 \
    --split-max-size 50G

# Für BF16:
python llama.cpp/convert_hf_to_gguf.py merged_model \
    --outfile model-BF16.gguf --outtype bf16 \
    --split-max-size 50G
    
# Für Q8_0:
python llama.cpp/convert_hf_to_gguf.py merged_model \
    --outfile model-Q8_0.gguf --outtype q8_0 \
    --split-max-size 50G