Accueil › Glossaire › GGML

GGML (Georgi Gerganov Machine Learning)

GGML est une bibliothèque tensor écrite en C/C++ par Georgi Gerganov, conçue pour exécuter des opérations d’algèbre tensorielle (multiplications matricielles, calculs d’attention, fonctions d’activation) de manière optimisée sur du matériel grand public, en particulier les CPU. C’est le moteur de calcul bas niveau qui alimente llama.cpp, whisper.cpp et l’ensemble de l’écosystème d’inférence locale de LLM.

Si vous avez déjà lancé un modèle via Ollama, LM Studio ou Jan, c’est GGML qui effectuait les calculs en coulisse. La bibliothèque n’alloue pas de mémoire à l’exécution, n’a aucune dépendance externe, supporte la quantification native de 1,5 à 8 bits, et fonctionne sur un éventail de matériel allant du Raspberry Pi aux GPU NVIDIA Blackwell. En février 2026, Georgi Gerganov et son équipe GGML.ai ont rejoint Hugging Face, intégrant le moteur d’inférence locale le plus utilisé au monde directement dans le plus grand écosystème de modèles open source.

Histoire et contexte

Fin septembre 2022, Georgi Gerganov commence à développer GGML avec un objectif clair : créer une bibliothèque de calcul tensoriel en C qui soit rapide, portable, et qui gère la mémoire de manière stricte. L’inspiration vient de LibNC, un projet de Fabrice Bellard. Le premier projet construit sur GGML est whisper.cpp, une implémentation en C++ du modèle Whisper d’OpenAI pour la transcription audio.

En mars 2023, quand Meta publie les poids de LLaMA, Gerganov crée llama.cpp : une implémentation de l’inférence LLaMA en C/C++ pur, sans aucune dépendance. Le projet explose. Pour la première fois, des développeurs peuvent faire tourner un LLM de 7 milliards de paramètres sur un MacBook, un PC de bureau, voire un Raspberry Pi. C’est un moment fondateur pour l’IA locale.

En août 2023, le format de fichier GGUF remplace l’ancien format GGML pour résoudre les problèmes d’extensibilité et de rétrocompatibilité. Le terme « GGML » désigne désormais principalement la bibliothèque tensor, tandis que « GGUF » désigne le format de fichier.

En février 2026, Hugging Face acquiert GGML.ai. Georgi Gerganov et son équipe rejoignent Hugging Face, fusionnant le moteur d’inférence locale le plus populaire avec le plus grand hub de modèles IA. Cette acquisition signifie que les quantifications GGUF de première main seront produites directement par les mainteneurs du format, testées contre la CI de llama.cpp, et hébergées nativement sur le Hub.

Architecture technique

Exécution par graphe de calcul

GGML utilise une approche basée sur les graphes de calcul (computation graphs). Les opérations sont définies une fois sous forme de graphe (les tenseurs sont les nœuds, les opérations sont les arêtes), puis le graphe est exécuté. Cette approche permet d’optimiser l’ordonnancement des opérations, de réutiliser la mémoire entre opérations non concurrentes, et d’exécuter le même graphe plusieurs fois avec des entrées différentes sans le reconstruire.

Voici un exemple minimaliste avec le binding Python :

Gestion mémoire sans allocation dynamique

Une des caractéristiques les plus distinctives de GGML : la bibliothèque n’alloue pas de mémoire à l’exécution. Toute la mémoire est pré-allouée dans des « contextes » (ggml_context), qui sont des arènes de mémoire contiguë dans lesquelles les tenseurs sont alloués séquentiellement. Cela élimine les overhead du garbage collector et de l’allocateur dynamique, et rend le comportement mémoire parfaitement prédictible, un avantage crucial pour le déploiement embarqué et edge.

Quantification native

GGML intègre les types de quantification directement dans son système de types. Les opérations clés (notamment vec_dot, utilisée pour les multiplications matricielles) disposent d’implémentations optimisées pour chaque type de quantification : Q4_0, Q4_K, Q5_K, Q6_K, Q8_0, et les I-quants. Cela signifie que les calculs sur des poids quantifiés ne sont pas simplement des opérations flottantes sur des poids déquantifiés : ce sont des opérations natives en précision réduite, avec des kernels assembleur optimisés pour chaque architecture matérielle.

Système de backends multi-matériel

GGML utilise une architecture de backends abstraite qui permet d’exécuter les mêmes opérations sur différents accélérateurs matériels. Chaque backend implémente une interface commune (ggml_backend_i) :

Quand GGML est compilé avec GGML_CPU_ALL_VARIANTS=ON, toutes les variantes CPU sont construites comme des bibliothèques dynamiques, et le backend sélectionne automatiquement la meilleure variante à l’exécution en fonction des fonctionnalités CPU détectées. Sur un Intel récent avec AMX, par exemple, GGML activera les instructions de multiplication matricielle matérielle pour maximiser le throughput.

Performances d’inférence

Les performances de GGML via llama.cpp varient considérablement selon le matériel, la taille du modèle et le schéma de quantification. Voici des ordres de grandeur pour un modèle 7-8B en Q4_K_M :

CPU x86 seul (Intel/AMD récent) : 8 à 15 tokens/seconde en génération, selon le CPU et la mémoire. Suffisant pour de la conversation interactive mais lent pour du batch processing. L’utilisation d’AVX-512 ou AMX (Intel 13ème gen+) améliore sensiblement les résultats.

Apple Silicon (M2/M3/M4) : 30 à 50+ tokens/seconde grâce à la mémoire unifiée et l’accélération Metal. Un MacBook Pro M3 avec 36 Go de RAM peut faire tourner un modèle 32B en Q4_K_M de manière fluide. C’est l’une des meilleures plateformes pour l’inférence locale GGML.

GPU NVIDIA (RTX 4090, full offload) : 60 à 120+ tokens/seconde selon le modèle. La bande passante mémoire GDDR6X (1 To/s) est le facteur limitant en génération token par token. Sur les modèles plus gros (70B), le split CPU+GPU est possible mais ralentit proportionnellement.

Pour les modèles plus gros, les performances chutent proportionnellement à la taille. Un 70B en Q4_K_M sur CPU seul génère 1 à 3 tokens/seconde, ce qui est utilisable pour du batch mais pas pour du temps réel. L’offloading GPU partiel ou total est fortement recommandé pour les modèles au-delà de 13B.

Offloading hybride CPU+GPU

L’une des fonctionnalités les plus pratiques de GGML est l’offloading partiel. Le paramètre -ngl (number of GPU layers) dans llama.cpp contrôle combien de couches du modèle sont chargées sur le GPU. Les couches restantes restent sur CPU. Cela permet de faire tourner des modèles qui ne tiennent pas entièrement dans la VRAM du GPU.

Par exemple, pour un modèle 32B en Q4_K_M (~19 Go) sur un GPU de 12 Go : vous pouvez offloader environ 20 couches sur le GPU (qui consomment ~12 Go de VRAM) et laisser les ~15 couches restantes sur CPU. L’inférence sera plus lente qu’en GPU complet, mais nettement plus rapide qu’en CPU pur. C’est un compromis que ni GPTQ ni AWQ natifs ne permettent.

GGML vs PyTorch / TensorFlow

GGML et PyTorch ciblent des cas d’usage fondamentalement différents :

En résumé : GGML est un moteur d’inférence minimaliste et portable. PyTorch est un framework complet de machine learning. On ne choisit pas entre les deux, on les utilise dans des contextes différents : PyTorch pour entraîner et fine-tuner, GGML (via llama.cpp) pour déployer et inférer localement.

Les projets construits sur GGML

llama.cpp : le projet phare. Moteur d’inférence pour les LLM, support de 50+ architectures, format GGUF, serveur OpenAI-compatible. C’est le projet qui a démocratisé l’inférence LLM locale. Il alimente indirectement Ollama, LM Studio et Jan.

whisper.cpp : implémentation de Whisper (modèle de speech-to-text d’OpenAI) en C++. Permet la transcription audio en temps réel sur du matériel grand public, sans Python ni GPU.

llama.vim / llama.vscode : extensions pour la complétion de code/texte assistée par LLM, directement intégrées dans Vim et VS Code, alimentées par GGML.

ggml-python : binding Python pour GGML, permettant d’utiliser la bibliothèque depuis Python pour le prototypage et la recherche.

L’acquisition par Hugging Face (février 2026)

L’acquisition de GGML.ai par Hugging Face en février 2026 est un événement structurant pour l’écosystème IA locale. Concrètement, elle signifie :

Quantifications GGUF de première main sur le Hub. Les mainteneurs du format GGUF produiront directement les quantifications officielles, testées contre la CI de llama.cpp. Fini la dépendance aux re-quantifications tierces de qualité variable.

Pipeline unifié de bout en bout. La découverte de modèles (Hugging Face Hub), la quantification, et le déploiement local partageront un seul pipeline, un seul système d’authentification, et un seul jeu d’outils. Le chemin de « je cherche un modèle » à « il tourne sur mon PC » se simplifie radicalement.

Intégration GGUF dans Transformers. À terme, la bibliothèque Transformers pourrait charger nativement des fichiers GGUF et router vers le backend GGML pour l’inférence, sans passer par un outil externe.

GGML (la bibliothèque) vs GGUF (le format)

La confusion entre GGML et GGUF est fréquente. Clarifions :

GGML = la bibliothèque tensor en C/C++. C’est le moteur de calcul qui effectue les multiplications matricielles, les opérations d’attention, etc. Elle existe depuis septembre 2022 et continue d’évoluer.

GGUF = le format de fichier binaire qui stocke les poids quantifiés et les métadonnées d’un modèle. Introduit en août 2023, il remplace l’ancien format de fichier (aussi appelé « GGML format ») qui était moins extensible.

L’ancien « format GGML » = un format de fichier aujourd’hui obsolète, remplacé par GGUF. Si vous rencontrez des fichiers .bin étiquetés « GGML format », ils ne sont plus supportés par les versions récentes de llama.cpp. Reconvertissez depuis les poids FP16 originaux.

En résumé : GGML (la bibliothèque) charge et exécute des fichiers GGUF (le format). Les deux portent le nom de leur créateur (Georgi Gerganov) mais désignent des choses différentes.

Limites de GGML

Pas conçu pour l’entraînement. GGML dispose d’un support basique de la différentiation automatique, mais il n’est pas adapté à l’entraînement de gros modèles. Pour l’entraînement et le fine-tuning, utilisez PyTorch (avec bitsandbytes pour le fine-tuning quantifié).

Throughput GPU pur inférieur aux solutions spécialisées. Sur GPU NVIDIA pur, vLLM avec des kernels Marlin (pour GPTQ/AWQ) offre un throughput significativement supérieur à llama.cpp/GGML. GGML excelle sur CPU, sur Apple Silicon, et en configuration hybride CPU+GPU, mais n’est pas le meilleur choix pour le serving haute concurrence sur GPU datacenter.

Écosystème C/C++. Le développement de plugins ou d’extensions pour GGML requiert des compétences en C/C++, ce qui limite l’accessibilité par rapport à l’écosystème Python de PyTorch. Les bindings Python existent mais restent moins matures.

Support Windows partiel. Bien que llama.cpp compile sous Windows, certaines fonctionnalités (notamment les modules fusionnés et certains backends GPU) sont plus stables sous Linux et macOS.