Hugging Face a annoncé le 22 septembre 2026 la prise en charge des modèles GGUF dans Transformers. Les développeurs peuvent sélectionner un checkpoint GGUF sur le Hub, le charger avec from_pretrained et générer du texte depuis les API habituelles de Transformers, comme le détaille l’annonce de l’entreprise.
Le chargement passe par le Hub et from_pretrained
Le format GGUF regroupe les poids et les métadonnées d’un modèle dans un seul fichier. Il peut également contenir les informations du tokenizer et, lorsqu’il est disponible, un modèle conversationnel. Dans l’exemple fourni par Hugging Face, l’utilisateur indique l’identifiant du modèle sur le Hub ainsi que le nom du fichier avec gguf_file.
Cette méthode rapproche le chargement d’un modèle quantifié du fonctionnement habituel de Transformers. L’exemple présenté ne demande pas de configuration supplémentaire spécifique à GGUF. Pour les développeurs qui utilisent déjà les API de la bibliothèque, le changement se situe donc surtout dans le choix du checkpoint et du fichier à charger.
Le format permet aussi de comparer rapidement l’espace de stockage occupé par différentes représentations d’un même modèle. Pour l’exemple Qwen3.5-4B d’Unsloth, Hugging Face indique 8,42 Go pour le fichier GGUF BF16, contre 2,74 Go pour la variante quantifiée Q4_K_M. Cette différence décrit la taille des fichiers. Elle ne permet pas de comparer directement les performances ou les capacités des deux représentations.
Une intégration fondée sur les noyaux de llama.cpp
Le chemin d’inférence compact réutilise les noyaux ggml de llama.cpp au moyen de la bibliothèque kernels. Hugging Face cherche ainsi à rapprocher les performances de celles de llama.cpp tout en réduisant la surcharge liée à generate.
La comparaison publiée place Transformers près de llama.cpp sur trois checkpoints GGUF. Elle doit toutefois être lue avec prudence, car les mesures ne reposent pas sur des méthodes identiques. Le résultat de Transformers inclut le préremplissage, tandis que llama-bench mesure le débit de décodage sans préremplissage. Ces chiffres illustrent donc la direction de l’intégration, sans garantir un niveau de performance identique sur tous les modèles ou tous les appareils.
Apple Silicon constitue la première cible
La première cible de cette voie compacte est l’inférence locale sur Apple Silicon, avec une prise en charge limitée à MPS. L’arrivée de GGUF dans Transformers ne signifie donc pas que les noyaux compacts fonctionnent déjà sur chaque matériel. L’importation d’un fichier GGUF par déquantification reste une option distincte de ce chemin d’inférence.
La couverture actuelle du chargeur compact comprend les architectures Qwen3.5 denses et à mélange d’experts, ainsi que les checkpoints Qwen3.8 compatibles. Le même checkpoint GGUF peut aussi être servi avec transformers serve, qui expose une API compatible avec l’API OpenAI.
Cette compatibilité ne couvre pas encore le traitement par lots dans la même mesure. Hugging Face indique vouloir étendre le travail réalisé sur MPS à generate_batch. Dans l’état décrit, l’intégration répond donc plus directement au besoin d’exécuter localement une requête à la fois qu’à celui de faire fonctionner un service par lots pleinement mature.
Pour les développeurs équipés d’un Mac Apple Silicon et travaillant avec les checkpoints Qwen pris en charge, la mise à jour réduit les étapes nécessaires pour intégrer un modèle GGUF quantifié dans un flux fondé sur Transformers. Le gain porte surtout sur le chargement et l’accès aux API existantes. La couverture des architectures, les capacités du matériel et l’absence actuelle d’un traitement par lots équivalent restent les principales limites de cette première étape.
Transformers devient ainsi une voie plus directe vers certains modèles GGUF, mais l’intégration reste ciblée. Elle simplifie l’usage local sur Apple Silicon sans effacer les différences de matériel, de quantification ou de scénario d’exécution.