Transformers exécute nativement les quants GGUF de llama.cpp

22 septembre 2026. Hugging Face publie le billet « Transformers now runs llama.cpp quants », signé par Marc Sun, Arthur Zucker et Lysandre. 22 septembre 2026. Transformers sait charger un GGUF via from_pretrained et le servir derrière une API compatible OpenAI. 22 septembre 2026. Le support démarre sur Apple Silicon, avec l’architecture Qwen3.5. Pourquoi c’est important : les deux plus grands écosystèmes de l’inférence locale — la bibliothèque Transformers et le moteur llama.cpp — convergent enfin, et GGUF s’impose comme le format d’échange de fait pour les modèles quantifiés.

Ce qu’est GGUF et pourquoi ce format domine

GGUF est le format de fichiers développé par l’équipe de llama.cpp. Il regroupe en un seul fichier les poids du modèle et ses métadonnées — y compris le tokenizer et, en option, un chat template. Son intérêt tient à la quantification : on peut décliner un même modèle en plusieurs niveaux de précision, en troquant un peu de qualité contre un encombrement mémoire bien plus faible.

Ce format est devenu la colonne vertébrale de l’inférence locale. llama.cpp alimente Ollama, LM Studio et Jan, et l’organisation ggml-org publie des checkpoints quantifiés directement sur le Hub. Des éditeurs comme Unsloth, LM Studio Community et bartowski maintiennent des collections de GGUF prêts à l’emploi, téléchargés des millions de fois.

La variante Q4_K_M illustre le compromis : elle mélange des précisions par tenseur, en gardant la majorité des poids en 4 bits tout en conservant les tenseurs sensibles à plus haute précision. Le billet donne la déclinaison exacte du modèle Qwen3.5-4B d’Unsloth :

La recommandation de Hugging Face est explicite : commencer en Q4_K_M, puis monter en Q5_K_M ou Q6_K si la mémoire le permet. Une quantification plus agressive fait tenir de plus gros modèles, mais le compromis de qualité dépend du modèle et de la tâche — il faut l’évaluer sur le travail réellement visé.

Charger un GGUF avec Transformers

Jusqu’ici, charger un modèle quantifié en Python imposait de sortir de Transformers — soit en passant par les bindings llama-cpp-python, soit en convertissant les poids. Le nouveau support rend l’opération aussi simple qu’un chargement classique, avec une seule étape spécifique : passer le paramètre gguf_file à from_pretrained.

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "unsloth/Qwen3.5-4B-GGUF"
filename = "Qwen3.5-4B-Q4_K_M.gguf"

tokenizer = AutoTokenizer.from_pretrained(model_id, gguf_file=filename)
model = AutoModelForCausalLM.from_pretrained(model_id, gguf_file=filename)

Tout le reste reste l’API Transformers standard — apply_chat_template, generate, etc. Aucune configuration supplémentaire n’est nécessaire : quand les poids restent empaquetés sur Metal, Transformers charge automatiquement les noyaux ggml/Metal compatibles et utilise ggml-org/ggml-attn comme implémentation d’attention. Si ce noyau ne peut pas être récupéré, le modèle bascule sur sdpa avec un avertissement — et l’on peut forcer attn_implementation="sdpa" explicitement. Sans noyau de quantification compatible, le chargeur déquantifie le modèle et consomme plus de mémoire.

Le support vise d’abord Apple Silicon et l’architecture Qwen3.5. C’est un choix de concentration assumé : plutôt que de couvrir toutes les plateformes à moitié, l’équipe réutilise les noyaux ggml de llama.cpp via la bibliothèque kernels, et réduit la surcharge de generate. Les prérequis sont un Mac Apple Silicon, une version PyTorch compatible avec les builds de noyaux ggml-quantization publiés (en pratique les deux dernières versions), et la branche main de Transformers jusqu’à la prochaine release.

Servir un GGUF derrière une API OpenAI

Le même checkpoint se sert via transformers serve, qui expose une API compatible OpenAI sans code supplémentaire. Le format de l’argument est <model_id>:<filename>.gguf — avant les deux-points, le dépôt du Hub ; après, le fichier précis à charger. Cela permet de sélectionner une quantification particulière dans un dépôt qui en contient plusieurs.

pip install -U "transformers[serving] @ git+https://github.com/huggingface/transformers.git" kernels
transformers serve "unsloth/Qwen3.5-4B-GGUF:Qwen3.5-4B-Q4_K_M.gguf"

Pour les modèles dont le chat template gère le raisonnement, l’option --reasoning off le désactive, --reasoning on l’active, et --reasoning auto — la valeur par défaut — suit le template. Un client comme Jan ou Pi se connecte alors en ajoutant un fournisseur OpenAI personnalisé, avec http://localhost:8000/v1 comme URL de base. Transformers exécute le modèle sur le Mac, pendant que le client fournit l’interface de conversation.

Ce que disent les benchmarks, et ce qui reste à faire

La référence de performance reste llama.cpp. Le billet compare les deux sur trois checkpoints GGUF — un modèle dense petit, un dense plus grand et un mixture-of-experts. L’objectif affiché n’est pas de battre llama.cpp, mais de s’en rapprocher suffisamment pour que l’API Transformers devienne une alternative acceptable, en particulier grâce aux noyaux ggml partagés.

Les limites actuelles sont honnêtes. Le support est encore sur la branche main, pas dans une release stabilisée. Il cible Apple Silicon et Qwen3.5, et le choix du noyau de quantification dépend de la version PyTorch. Les architectures au-delà de Qwen3.5 arriveront ensuite, de même que la généralisation à d’autres plateformes. Autrement dit, le jour de publication, c’est une capacité de pointe pour les utilisateurs de Mac, pas une solution universelle.

Ce que ça change pour l’écosystème local

Le rapprochement dépasse la simple commodité d’API. Il y a trois ans, exécuter un modèle local en Python imposait un choix net : l’ergonomie de Transformers (tokenizers, chat templates, écosystème du Hub) ou la vitesse de llama.cpp (quantification, noyaux optimisés). On sacrifiait l’un pour l’autre. En réutilisant les noyaux ggml de llama.cpp sous l’API Transformers, Hugging Face abolit ce compromis pour la première fois.

Les conséquences se lisent en cascade. Ollama, LM Studio et Jan, qui reposent sur llama.cpp, voient leur format de prédilection devenir aussi un format de première classe pour la pile Python. Les éditeurs de quants — Unsloth, bartowski, LM Studio Community — publient un seul fichier qui sert désormais aux deux mondes. Et les équipes qui prototypent en Python puis déploient derrière un serveur local peuvent garder le même checkpoint du notebook à la production, via transformers serve.

Cette consolidation a une portée immédiate. Les projets qui distribuent des modèles GGUF n’ont plus à maintenir deux jeux d’instructions — un pour llama.cpp, un pour transformers. Un seul checkpoint Q4_K_M couvre désormais les utilisateurs d’Ollama, de LM Studio et les scripts Python. C’est exactement le genre de convergence qui, dans les faits, décide de la survie d’un format.

Le choix d’Apple Silicon comme point de départ n’est pas neutre non plus. C’est la plateforme où l’inférence locale a basculé du hobby au quotidien professionnel — et où Metal impose des noyaux dédiés plutôt que les chemins CUDA historiques. En collant aux noyaux ggml/Metal, Transformers reconnaît implicitement que le futur proche de l’inférence locale se joue d’abord sur Mac.

Verdict

Ce rapprochement acte un fait d’écosystème : GGUF n’est plus un format de niche de llama.cpp, mais le format d’interchange des modèles locaux quantifiés. Si vous développez en Python sur Apple Silicon et que vous jonglez aujourd’hui entre llama-cpp-python et vos scripts de conversion, basculez sur from_pretrained avec l’argument gguf_file dès que la prochaine release de Transformers sortira — vous récupérez l’écosystème Hugging Face (tokenizers, chat templates, serve) sans renoncer à la vitesse des noyaux ggml. Si vous cherchez le maximum de performance brute sur des architectures non couvertes, restez sur llama.cpp natif. Dans tous les cas, évaluez la quantification sur votre propre tâche en Q4_K_M puis en montant : le bon niveau de précision est une mesure, pas un dogme.

Références

• Hugging Face Blog — Transformers now runs llama.cpp quants (22 septembre 2026)
• Documentation GGUF du Hub Hugging Face
• Dépôt ggml-org sur le Hub