Le 22 septembre 2026, Hugging Face a annoncé sur son blog officiel que transformers charge désormais directement les modèles quantifiés GGUF. Il suffit de passer un argument gguf_file à from_pretrained pour monter un checkpoint GGUF du Hub dans l'API transformers familière et l'exécuter sur une machine locale. Grâce à la réutilisation des kernels bas niveau de ggml, les performances d'inférence seraient proches de celles de llama.cpp, indique l'entreprise.
Un argument, et GGUF est dans transformers
L'usage est plus simple qu'on ne l'imagine :
from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained( "unsloth/Qwen3.5-4B-GGUF", gguf_file="Qwen3.5-4B-Q4_K_M.gguf",
)Ensuite, c'est le workflow transformers standard : tokenizer, generate, processeurs de logits personnalisés — tout fonctionne comme d'habitude. Le même checkpoint peut aussi être exposé comme API compatible OpenAI via transformers serve, avec des clients comme Jan ou Pi en frontal de discussion.
La performance est l'aspect le plus convaincant de cette mise à jour. Hugging Face a mesuré trois types de checkpoints sur un MacBook Pro M2 Max (32 Go de mémoire unifiée) — un petit modèle dense, un modèle dense plus grand et un modèle mixture-of-experts — et le débit de génération de transformers est pratiquement à égalité avec les scores llama-bench de llama.cpp. Le secret : la réutilisation des kernels Metal de ggml — multiplication matricielle quantifiée, normalisation fusionnée, flash attention et autres opérateurs clés appellent directement les implémentations ggml, Python ne faisant qu'orchestrer.
Pour qui : les chercheurs, pas les seuls chasseurs de vitesse
Le blog officiel est explicite sur le public visé. L'intégration répond à quatre besoins principaux : expérimenter avec GGUF en Python/PyTorch, évaluer des checkpoints quantifiés avec les workflows d'évaluation existants, valider l'exactitude des conversions GGUF, et déquantifier depuis GGUF pour poursuivre le fine-tuning. Ce qu'elle résout, c'est la « commodité de développement », pas la « vitesse » — le blog précise noir sur blanc que llama.cpp reste le moteur recommandé pour l'inférence locale efficace.
Les limites méritent d'être notées : le support initial est réservé à Apple Silicon, en commençant par l'architecture Qwen3.5 ; il faut la branche main de transformers plus le paquet kernels ; et sans kernel de quantification compatible, le chargeur bascule vers un chargement déquantifié, nettement plus gourmand en mémoire. Nous avions déjà présenté le rôle de llama.cpp comme base d'inférence locale (llama.cpp, pour qui ? Un runtime léger pour modèles locaux, pas un produit de chat (/zh/article/1856-llama-cpp-shi-he-shui-ben-di-pao-mo-xing-de-qing-liang-di-zuo-bu-shi-liao-tian-c)) ; cette mise à jour se lit ainsi : l'inférence reste l'affaire de llama.cpp, mais pour la recherche et le prototypage, on peut désormais manipuler le même fichier GGUF directement dans transformers — fini les allers-retours de poids entre deux chaînes d'outils.
Il y a aussi un angle pratique pour les développeurs chinois : les distributions GGUF de modèles populaires comme Qwen3.5 (Unsloth, bartowski et autres) sont téléchargées massivement sur le Hub. Les utiliser dans l'écosystème PyTorch exigeait jusqu'ici d'écrire sa propre logique de chargement ; la voie officielle est désormais tracée.
