Speichern in GGUF

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

Lokal

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

model.save_pretrained_gguf("directory", tokenizer, quantization_method = "q4_k_m")
model.save_pretrained_gguf("directory", tokenizer, quantization_method = "q8_0")
model.save_pretrained_gguf("directory", tokenizer, quantization_method = "f16")

Um zum Hugging Face Hub zu pushen:

model.push_to_hub_gguf("hf_username/directory", tokenizer, quantization_method = "q4_k_m")
model.push_to_hub_gguf("hf_username/directory", tokenizer, quantization_method = "q8_0")

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. Behält 100% Genauigkeit, ist 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 gut läuft und gute Ergebnisse liefert, aber wenn Sie es auf einer anderen Plattform wie Ollama oder vLLM verwenden, die Ergebnisse schlecht sind oder Sie Kauderwelsch, endlose/immerwährende Generierungen erhalten oder wiederholte Ausgaben.

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

• Sie müssen das richtige eos-Token. Wenn nicht, können Sie bei längeren Generierungen Kauderwelsch erhalten.

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

• Verwenden Sie unsere konversationellen Notebooks, um die Chat-Vorlage 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-Dokumenten

Speichern nach GGUF / vLLM 16bit stürzt ab

Sie können versuchen, die maximale GPU-Auslastung während des Speichervorgangs zu verringern, indem Sie maximum_memory_usage.

Der Standard ist model.save_pretrained(..., maximum_memory_usage = 0.75). Reduzieren Sie ihn auf z. B. 0.5, um 50% des maximalen GPU-Speichers oder weniger zu verwenden. Dies kann OOM-Abstürze während des Speicherns 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