LLM auto hébergées · 6 September 2026

llama.cpp 2026 : la réécriture qui change tout pour l’IA locale

En avril 2026, une refonte majeure de llama.cpp a été fusionnée dans la branche principale, presque sans tambour ni trompette. Pourtant, elle redéfinit les performances, la compatibilité matérielle et l’écosystème des LLM locaux. Décryptage de ce qui a réellement changé, des gains concrets aux compromis assumés, pour ceux qui veulent faire tourner des modèles open source chez soi sans se ruiner.

Une réécriture passée sous les radars, mais qui redessine l’inférence locale

Il y a des révolutions qui font du bruit, et d’autres qui s’installent en silence. La réécriture de llama.cpp, fusionnée dans la branche main début avril 2026, appartient clairement à la seconde catégorie. Aucun communiqué de presse fracassant, aucune conférence keynote. Juste un commit, une discussion GitHub, et une poignée d’articles techniques pour relayer l’information. Pourtant, pour qui fait tourner des LLM open source sur du matériel grand public, c’est potentiellement le changement le plus important depuis la création du projet en mars 2023.

Rappelons le contexte : llama.cpp, créé par Georgi Gerganov, a été le premier moteur d’inférence à faire tourner des modèles LLaMA sur Apple Silicon en pur CPU, puis a étendu son support à CUDA, Metal et Vulkan. Avec plus de 75 000 étoiles sur GitHub, il est devenu le socle de dizaines d’outils, dont Ollama, le runner de modèles open source qui empaquette llama.cpp avec une API HTTP locale, un registre de modèles préemballés et une CLI qui se lit comme Docker. Mais ce succès s’est construit sur une architecture qui commençait à montrer ses limites. Le code monolithique, les backends dupliqués, la gestion mémoire fragmentée : autant de freins à l’évolution.

Cette réécriture, la plus grande depuis 2023, change les règles du jeu. Elle promet des gains de débit significatifs — jusqu’à 2,1x sur les modèles 70B quantifiés, selon une source tierce — et une simplification drastique du code. Mais que vaut réellement cette promesse ? Quels sont les changements concrets dans l’architecture ? Et surtout, qu’est-ce que cela signifie pour vous, avec votre RTX 3060, votre RX 7800 XT ou votre M3 Pro ? C’est ce que nous allons décortiquer.

Pourquoi tout casser ? Les limites structurelles de l’ancien ggml

Pour comprendre l’ampleur de la refonte, il faut d’abord mesurer l’ancienneté des fondations. Le noyau de llama.cpp, ggml, a été conçu en 2023 comme une bibliothèque de calcul tensoriel minimaliste, pensée pour l’inférence CPU sur Apple Silicon. Au fil des mois, des backends GPU ont été ajoutés : d’abord CUDA, puis Metal, puis Vulkan. Chaque ajout s’est fait par empilement, avec des chemins de code parallèles et dupliqués.

Le résultat ? Un monolithe où les intrinsèques SIMD écrits à la main (AVX2, AVX-512, NEON, Metal MSL, CUDA, ROCm HIP) se comptaient par milliers, avec des variations subtiles entre chaque backend. Une modification du comportement d’un opérateur devait être répercutée dans six ou sept implémentations différentes, avec le risque d’introduire des divergences. La gestion mémoire, elle, était fragmentée : le cache KV, par exemple, était organisé par couche (layer-interleaved), ce qui entraînait des lectures non coalescées sur les contextes longs — au-delà de 8K tokens — sur Metal comme sur CUDA.

La goutte d’eau ? La difficulté croissante à intégrer de nouveaux matériels, notamment les NPU (Neural Processing Units) qui commencent à équiper les PC portables et les mini-PC. Chaque nouvelle cible matérielle nécessitait d’écrire un backend complet, avec ses intrinsèques spécifiques. C’est dans ce contexte que Georgi Gerganov a ouvert la discussion #205 sur GitHub, posant les bases d’un manifeste technique : réduire la latence, unifier les backends, et rendre le code plus maintenable.

Les objectifs étaient clairs : sortir du modèle « un backend par matériel » pour passer à une architecture où une description d’opérateur partagée génère du code adapté à chaque cible. Un pari audacieux, car il remettait en question le cœur même du projet. Mais l’équipe a décidé d’assumer, quitte à casser la compatibilité avec les versions précédentes.

Trois piliers techniques : générateur de kernels, KV cache contigu, dispatch unifié

La nouvelle architecture repose sur trois changements majeurs, décrits par la source technique qui a suivi la fusion. Le premier est l’introduction d’un générateur de kernels écrit en C pur. Ce générateur émet du code par backend au moment de la compilation, remplaçant la plupart des intrinsèques SIMD écrits à la main. Il ne s’agit pas d’un JIT (compilation à l’exécution), mais d’une génération statique : au build, le générateur produit les kernels adaptés à la cible (AVX2, AVX-512, NEON, Metal MSL, CUDA, ROCm HIP). Cela supprime des milliers de lignes de code dupliqué — environ 11 000 lignes d’intrinsèques, selon la même source — sans introduire de couche IR (intermediate representation) lourde.

Le deuxième pilier concerne le cache KV, réorganisé d’une disposition entrelacée par couche à une disposition contiguë par tête d’attention (head-contiguous). Concrètement, cela améliore la coalescence des lectures lors de l’attention, surtout sur les longs contextes. L’ancienne disposition provoquait des accès mémoire épars, pénalisant les modèles avec des fenêtres de contexte étendues. La nouvelle organisation regroupe les données par tête, ce qui permet des lectures séquentielles plus efficaces.

Le troisième pilier est la fusion des backends Metal et CUDA en une seule passe d’abaissement de graphe d’opérations (op-graph lowering pass). Au lieu d’avoir deux chemins de code parallèles qui dupliquaient la logique, il existe désormais un chemin unique qui traduit le graphe d’opérations en appels aux kernels générés. Cela simplifie considérablement la maintenance et réduit les risques de divergence entre les plateformes.

Ces trois changements sont interdépendants : le générateur de kernels fournit les briques, le KV cache optimisé améliore l’accès mémoire, et le dispatch unifié orchestre le tout. L’ensemble forme une architecture plus cohérente, où la logique est centralisée et les optimisations spécifiques à chaque matériel sont déléguées à la génération de code.

2,1x sur 70B, 1,4x sur 7B : des chiffres à décrypter avec prudence

Les chiffres annoncés font rêver : une amélioration de débit de 2,1x sur les modèles 70B quantifiés (mesurée sur Apple M3 Ultra) et de 1,4x sur les modèles 7B (mesurée sur Nvidia H100). Mais il faut les prendre avec des pincettes. Ces mesures proviennent d’une seule source tierce, mlsystemsreview.com, et n’ont pas été confirmées indépendamment — ni par l’équipe de llama.cpp, ni par des benchmarks communautaires. Aucun chiffre absolu en tokens/s n’est fourni, seulement des ratios.

Surtout, le matériel utilisé n’est pas représentatif des configurations grand public. Le M3 Ultra est une puce prosumer haut de gamme, et la H100 est un GPU datacenter à plusieurs dizaines de milliers d’euros. Aucune mesure n’a été publiée pour des cartes comme la RTX 3060 12 Go, la RX 7800 XT ou le M3 Pro 18 Go. Or, c’est précisément sur ce type de matériel que la réécriture pourrait avoir le plus d’impact — ou le moins, selon les cas.

Il faut aussi noter que ces gains sont relatifs aux versions stables de 2025 de llama.cpp. La question est de savoir si la réécriture a réellement amélioré les performances sur du matériel grand public, ou si elle a simplement optimisé les cas les plus favorables (GPU haut de gamme, modèles volumineux). Sans tests A/B rigoureux sur des configurations courantes, il est impossible de trancher.

Pour vérifier soi-même, la méthode est simple : compiler la branche main actuelle, mesurer les tokens/s sur son propre modèle et son propre GPU, puis comparer avec une version stable de 2025. Les outils comme llama-bench intégrés au projet permettent de faire ces mesures facilement. Les résultats communautaires commencent à affluer sur les forums et les discussions GitHub, mais ils restent fragmentaires.

Ce que ça change pour votre RTX 3060, RX 7800 XT ou M3 Pro

Traduisons maintenant les gains architecturaux en bénéfices concrets pour le matériel grand public. Le premier impact concerne l’utilisation de la VRAM. La réorganisation du cache KV et l’unification du dispatch devraient réduire les transferts mémoire inutiles, ce qui est crucial sur des cartes avec 12 Go ou 16 Go de VRAM. Pour un modèle 7B en quantification Q4_K_M, qui nécessite environ 4-5 Go de VRAM, cela laisse plus de marge pour le contexte et les buffers intermédiaires. Pour un modèle 13B en Q8 ou 20B en Q4, qui demandent environ 16 Go, chaque octet économisé compte.

Le deuxième impact concerne la vitesse de génération. L’amélioration de la coalescence des lectures sur les longs contextes devrait bénéficier aux utilisateurs qui poussent les fenêtres de contexte au-delà de 8K tokens. C’est typiquement le cas pour l’analyse de documents, la synthèse de code ou les conversations longues. Sur du matériel grand public, où la bande passante mémoire est le facteur limitant (la RTX 3060 plafonne à 360 Go/s, le M3 Pro à 150 Go/s), une meilleure efficacité des accès mémoire peut se traduire par des gains perceptibles, même si les ratios annoncés (2,1x, 1,4x) ne sont probablement pas reproductibles sur ces configurations.

Le troisième impact concerne la quantification. La réécriture vise notamment à combler l’écart de performances entre les backends pour la quantification INT4 Q4_K_M : excellente en AVX-512, bonne en Metal, mais moyenne en CUDA. L’unification du dispatch devrait harmoniser ces performances, ce qui est une bonne nouvelle pour les utilisateurs NVIDIA qui utilisaient des quantifications plus agressives pour compenser.

Reste la question des différences entre fabricants. NVIDIA reste le plus mature, avec CUDA et une optimisation de longue date. AMD, via ROCm/HIP, bénéficie de la même unification, mais le support reste moins éprouvé. Apple Silicon, avec Metal, était déjà bien optimisé pour l’inférence locale ; la réécriture pourrait maintenir cet avantage tout en simplifiant la maintenance. Pour les utilisateurs de cartes exotiques (Intel Arc, par exemple), le générateur de kernels pourrait faciliter l’ajout de support, mais rien n’est garanti à ce stade.

Ollama, vLLM, SGLang : l’écosystème s’adapte, mais à quel rythme ?

La réécriture de llama.cpp n’est pas un événement isolé : elle impacte directement tous les projets qui en dépendent. Ollama, qui utilise llama.cpp comme backend, est le plus concerné. Avec sa récente levée de fonds de 65 millions de dollars et ses 8,9 millions de développeurs, Ollama est devenu le visage de l’IA locale pour le grand public. Mais son modèle « clé en main » repose sur des versions stables et testées de llama.cpp. L’intégration de la nouvelle version demande du travail : vérification de la compatibilité des modèles GGUF, tests de régression, ajustement des paramètres par défaut.

Les autres runtimes locaux, comme LM Studio, suivent une logique similaire : ils embarquent llama.cpp en interne et doivent s’adapter. Pour vLLM et SGLang, qui sont davantage orientés vers le serving multi-utilisateurs et les GPU datacenter, la réécriture est moins critique, mais elle pourrait à terme bénéficier d’optimisations partagées.

Le risque principal est une fragmentation temporaire : pendant que certains outils restent sur l’ancienne version, d’autres basculent sur la nouvelle, avec des différences de performances et de comportement. Pour l’utilisateur final, cela signifie qu’il faut vérifier quelle version de llama.cpp est embarquée dans son outil préféré avant de comparer les benchmarks.

Les mini PC à mémoire unifiée : une alternative qui monte

Pendant que llama.cpp se réécrit, une autre tendance transforme le paysage de l’IA locale : les mini PC à mémoire unifiée. Portés par les APU AMD Strix Halo, Ryzen AI Halo et Gorgon Halo, ces boîtiers de moins d’un litre promettent de faire tourner des modèles jusqu’à 120-200 milliards de paramètres en 4-bit, là où il fallait auparavant une tour GPU à plusieurs milliers d’euros.

Le Strix Halo, lancé en 2025, offre jusqu’à 128 Go de mémoire unifiée LPDDR5X avec une bande passante de 256 Go/s. L’entrée de gamme, à 1 500 $, supporte les modèles 70B-120B en 4-bit. Le Ryzen AI Halo officiel, à 3 999 $, pousse à 128 Go et 120B+. Et le Gorgon Halo, annoncé pour 2026, va jusqu’à 192 Go de mémoire unifiée, ouvrant la porte aux modèles 200B+.

Pour qui veut faire tourner des LLM chez soi sans se ruiner, ces mini PC changent la donne : ils offrent une capacité mémoire bien supérieure aux GPU grand public (12-24 Go de VRAM) pour un coût total de possession inférieur à une tour GPU équipée d’une RTX 4090 (environ 2 900 $). Et avec la réécriture de llama.cpp qui améliore l’efficacité mémoire, ces configurations deviennent encore plus pertinentes.

Le décodage spéculatif : le complément naturel

Autre technique qui gagne du terrain en 2026 : le décodage spéculatif. Le principe : un petit modèle « draft » propose des tokens, qu’un gros modèle vérifie en parallèle. Résultat : jusqu’à 2x de vitesse en plus, sans perte de qualité, et sans dépenser un euro de plus. Des outils comme SpecForge et l’intégration native dans llama.cpp et vLLM ont démocratisé la technique.

Combiné à la réécriture de llama.cpp, le décodage spéculatif pourrait offrir des gains cumulés intéressants sur du matériel grand public. Sur une RTX 3090, par exemple, un modèle 70B en Q4 qui génère 15 tokens/s pourrait atteindre 25-30 tokens/s avec un bon draft model. De quoi rendre l’expérience enfin fluide pour de l’usage quotidien.

En pratique : que faire en septembre 2026 ?

Si vous voulez profiter des avancées de llama.cpp sans attendre que l’écosystème s’adapte, voici la marche à suivre :

1. Vérifiez votre outil : si vous utilisez Ollama ou LM Studio, surveillez les notes de version pour savoir quand ils intégreront la nouvelle version de llama.cpp. En attendant, vous pouvez compiler llama.cpp directement depuis la branche main pour tester les gains.

2. Mesurez vos performances : utilisez llama-bench pour comparer votre configuration actuelle avec la nouvelle version. Les gains varient considérablement selon le matériel et le modèle.

3. Optimisez votre VRAM : avec les nouvelles optimisations du cache KV, vous pourrez peut-être passer à un modèle plus gros ou augmenter la fenêtre de contexte. Un modèle 8B avec un contexte 128K, qui nécessitait 10-20 Go de VRAM en pleine précision, peut désormais tenir dans 2-4 Go avec la quantification TurboQuant 3-bit.

4. Explorez les alternatives : si votre GPU est limité, regardez du côté des mini PC à mémoire unifiée ou du décodage spéculatif. Les deux approches sont complémentaires et peuvent considérablement améliorer votre expérience.

Sources

• Ollama : faire tourner les LLM en local pour vos workflows dev
• LLM locaux pour managers : ce que vous pouvez vraiment faire tourner chez vous
• Configuration matérielle LLM local 2026 : de 8 Go à 70B par VRAM
• Installer un LLM en local en 2026 : Ollama, LM Studio, vLLM…
• Qu’est-ce qu’Ollama ? Faire tourner des LLM en local en 2026
• Meilleurs outils LLM local 2026 : Ollama et rivaux
• LLM local sur Mac M5 : MLX écrase désormais llama.cpp
• Ollama vs LM Studio vs llama.cpp: Which Local AI Runtime Should You Use in 2026?

Article recherché et rédigé automatiquement · Magazine Electrosens