Am 22. September 2026 kündigte Hugging Face im offiziellen Blog an, dass transformers GGUF-quantisierte Modelle nun direkt lädt. Ein gguf_file-Argument an from_pretrained genügt, um einen GGUF-Checkpoint vom Hub in die vertraute transformers-API zu holen und auf dem lokalen Rechner laufen zu lassen. Dank der Wiederverwendung von ggmls Low-Level-Kernels liege die Inferenzleistung nahe an llama.cpp, so das Unternehmen.
Ein Argument, und GGUF ist in transformers
Die Nutzung ist einfacher als gedacht:
from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained( "unsloth/Qwen3.5-4B-GGUF", gguf_file="Qwen3.5-4B-Q4_K_M.gguf",
)Danach läuft der Standard-transformers-Workflow: Tokenizer, generate, eigene Logits-Prozessoren — alles wie gewohnt. Derselbe Checkpoint lässt sich per transformers serve als OpenAI-kompatible API exponieren und mit Clients wie Jan oder Pi als Chat-Frontend nutzen.
Die Leistung ist der überzeugendste Teil des Updates. Hugging Face vermaß drei Checkpoint-Typen auf einem MacBook Pro M2 Max (32 GB Unified Memory) — ein kleines dichtes Modell, ein größeres dichtes Modell und ein Mixture-of-Experts-Modell — und transformers' Generierungsdurchsatz lag praktisch gleichauf mit llama.cpps llama-bench-Werten. Das Geheimnis ist die Wiederverwendung von ggmls Metal-Kernels: quantisierte Matrixmultiplikation, fusionierte Normalisierung, Flash Attention und weitere Schlüsseloperatoren rufen direkt ggml-Implementierungen auf, Python orchestriert nur.
Für wen das ist: Forscher, nicht reine Geschwindigkeitsjäger
Der offizielle Blog benennt die Zielgruppe klar. Die Integration bedient vier Hauptbedürfnisse: mit GGUF in Python/PyTorch experimentieren, quantisierte Checkpoints mit bestehenden Evaluierungsworkflows bewerten, die Korrektheit von GGUF-Konvertierungen validieren und nach Dequantisierung aus GGUF weiter feintunen. Gelöst wird „Entwicklerkomfort", nicht „schneller" — im Blog steht ausdrücklich, dass llama.cpp die empfohlene Engine für effiziente lokale Inferenz bleibt.
Auch die Grenzen sind nennenswert: Der initiale Support gilt nur für Apple Silicon, beginnend mit der Qwen3.5-Architektur; nötig sind der main-Branch von transformers plus das kernels-Paket; ohne kompatiblen Quantisierungskernel fällt der Loader auf dequantisiertes Laden zurück, was deutlich mehr Speicher frisst. Wir haben llama.cpps Rolle als lokale Inferenzbasis bereits vorgestellt (Für wen ist llama.cpp? Eine schlanke Laufzeit für lokale Modelle, kein Chat-Produkt (/zh/article/1856-llama-cpp-shi-he-shui-ben-di-pao-mo-xing-de-qing-liang-di-zuo-bu-shi-liao-tian-c)); dieses Update liest sich so: Inferenz weiter mit llama.cpp, aber für Forschung und Prototypen lässt sich dieselbe GGUF-Datei jetzt direkt in transformers bearbeiten — kein Hin- und Herschieben von Gewichten zwischen zwei Toolchains mehr.
Für chinesische Entwickler gibt es zudem einen praktischen Aspekt: GGUF-Distributionen populärer Modelle wie Qwen3.5 (von Unsloth, bartowski u. a.) werden auf dem Hub millionenfach geladen. Wer sie im PyTorch-Ökosystem nutzen wollte, musste bisher eigene Ladelogik schreiben; der offizielle Weg ist nun geebnet.
