Ollama 0.30 bascule sur llama.cpp : la révolution architecturale qui change le local AI
🔎 Le backend historique GGML vient de mourir — et c'est la meilleure nouvelle pour le local AI
Ollama dominait le paysage de l'IA locale depuis deux ans avec une promesse simple : un ollama run et c'est parti. Derrière cette simplicité, le moteur utilisait GGML, un backend d'inférence créé par Georgi Gerganov avant qu'il ne pivote vers llama.cpp. Le problème ? GGML était devenu un fantôme. Les modèles GGUF (le format successeur) évoluaient sans cesse, et le support dans GGML traînait des pieds. Résultat : des modèles qui ne chargeaient pas, des architectures ignorées, des performances en berne sur certaines machines.
En juin 2026, Ollama 0.30 change tout. L'équipe a arraché le backend GGML pour le remplacer par llama.cpp en natif. Ce n'est pas une mise à jour de plus. C'est une refonte du cœur moteur qui touche chaque utilisateur qui fait tourner un LLM sur sa machine. La compatibilité GGUF explose, les performances s'améliorent sur une gamme de hardware beaucoup plus large, et de nouveaux modèles comme le NVIDIA Nemotron 3 Ultra arrivent dans l'écosystème. Le tout avec un revers de la médaille : des bugs de tokenisation et une tension communautaire sur l'attribution open-source qui ne va pas se taire.
L'essentiel
- Ollama 0.30 abandonne le backend GGML historique et migre vers llama.cpp en natif pour toute l'inférence GGUF.
- La flash-attention est activée par défaut sur les modèles Qwen et Gemma, avec des gains de vitesse mesurables.
- Le moteur MLX reste conservé sur Apple Silicon — Ollama ne fait pas de tout-llama.cpp, il choisit le meilleur moteur par plateforme.
- NVIDIA Nemotron 3 Ultra (55B actifs, 550B totaux) arrive en mode cloud via Ollama, optimisé pour les workflows agents.
- Des bugs de tokenisation multi-bytes ont été signalés lors de la migration, notamment sur certains caractères Unicode.
- La tension communautaire sur l'attribution entre Ollama et le projet llama.cpp refait surface.
Outils recommandés
| Outil | Usage principal | Prix (juin 2026, vérifiez sur ollama.com) | Idéal pour |
|---|---|---|---|
| Ollama 0.30 | Inférence LLM locale | Gratuit (open source) | Tous les utilisateurs local AI |
| Ollama vs LM Studio | Comparatif d'outils locaux | Gratuit | Choisir son outil d'inférence |
| Meilleurs modèles Ollama | Sélection de modèles | Variable | Trouver le bon modèle GGUF |
| Agents IA Ollama | Workflows agents en local | Gratuit | Automatiser avec des LLM locaux |
| Hostinger | Hébergement pour APIs IA | À partir de 2,99 €/mois | Déployer des interfaces web |
GGML → llama.cpp : ce qui change réellement sous le capot
Ollama ne changeait pas de moteur d'inférence depuis sa création. GGML faisait le travail, mais avec des limites devenues insupportables en 2026. Le format GGUF a continué d'évoluer grâce au travail autour de llama.cpp, et GGML n'a pas suivi. Chaque nouvelle version de GGUF ajoutait des fonctionnalités que le backend historique ne supportait pas.
La migration vers llama.cpp résout ça d'un coup. Selon le blog officiel d'Ollama, ce changement améliore la compatibilité GGUF sur une gamme beaucoup plus large de hardware. Concrètement, les modèles qui refusaient de se charger sur certaines architectures GPU ou CPU chargent maintenant sans problème. Le backend v0.30.0 n'utilise plus du tout le format GGML pour charger les modèles. Tout passe par llama.cpp nativement.
Ce qui est fascinant, c'est que Ollama ne sacrifie pas ses optimisations plateforme. Sur Apple Silicon, le moteur MLX reste actif. Ollama 0.30 sélectionne intelligemment le backend le plus adapté : MLX sur Mac, llama.cpp partout ailleurs. C'est du pragmatisme pur, pas du dogmatisme technique.
Pour ceux qui veulent aller plus loin dans le choix de leur setup, notre guide d'installation LLM local détaille les configurations recommandées selon votre machine.
Flash-attention et gains de performance : les chiffres
La migration vers llama.cpp ne sert pas qu'à la compatibilité. Elle débloque des optimisations qui étaient jusqu'ici inaccessibles. La plus notable : la flash-attention activée par défaut sur les modèles Qwen et Gemma.
La flash-attention réduit drastiquement l'usage mémoire lors de la génération de tokens. Au lieu de stocker la matrice d'attention complète en VRAM, elle la calcule par blocs. Le résultat ? Une génération plus rapide et la possibilité de faire tourner des modèles plus gros sur des GPU avec moins de VRAM.
D'après l'analyse d'InsiderLLM, les gains sont particulièrement visibles sur les modèles de la famille Qwen3.5 comme le Qwen3.5-122B-A10B ou le Qwen3.6-27B. Sur un GPU avec 16 Go de VRAM, le temps de génération par token peut baisser de 15 à 25 % selon le contexte. Ce n'est pas un doublement de vitesse, mais c'est la différence entre une expérience fluide et une attente pénible.
Le tableau ci-dessous résume les améliorations mesurées par la communauté depuis la release :
| Modèle | Avant 0.30 (GGML) | Après 0.30 (llama.cpp) | Amélioration |
|---|---|---|---|
| Qwen3.6-27B | Flash-attention désactivée | Flash-attention par défaut | +15-20% tokens/s |
| Gemma 3 (via GGUF) | Compatibilité partielle | Support complet | Stabilité accrue |
| Qwen3.5-122B-A10B | VRAM limitée | Meilleur gestion mémoire | Contexte plus long possible |
| Modèles multi-bytes | Tokenisation fiable | Bugs signalés | Régression ponctuelle |
Pour exploiter ces modèles au mieux, consultez notre sélection des meilleurs LLM à run en local.
NVIDIA Nemotron 3 Ultra : le modèle agent qui débarque dans Ollama
La migration vers llama.cpp ouvre la porte à des architectures de modèles qui étaient jusque-là incompatibles. Et NVIDIA a saisi l'occasion. Au Computex 2026, la firme a présenté le Nemotron 3 Ultra, un modèle de 550 milliards de paramètres dont seulement 55 milliards sont actifs à l'inference grâce au MoE (Mixture of Experts).
Nemotron 3 Ultra n'est pas un modèle généraliste classique. Il est explicitement conçu pour les workflows agents. Selon la fiche registry d'Ollama, il est optimisé pour un raisonnement haute throughput avec des centaines d'appels outils par session. C'est exactement le profil d'usage qui intéresse les développeurs qui construisent des agents IA open source avec Ollama.
Le point important : Nemotron 3 Ultra est disponible via Ollama en mode cloud. Vous ne le faites pas tourner en local sur votre laptop — personne n'a 550B de paramètres en VRAM. Mais l'intégration dans l'écosystème Ollama signifie que vous pouvez l'appeler avec la même API que vos modèles locaux. Même interface, même workflow, mais avec la puissance d'un modèle cloud quand vous en avez besoin. C'est une approche hybride qui a du sens pour les cas réels.
Si vous hésitez entre modèles locaux et cloud pour vos agents, notre comparatif Claude, GPT, Gemini, Llama peut vous aider à trancher.
L'architecture Laguna : un patch llama.cpp intégré
Ollama 0.30 n'a pas seulement migré vers llama.cpp tel quel. L'équipe a contribué au projet amont en ajoutant le support d'une nouvelle architecture : Laguna, développée par poolside. Les notes de release sur GitHub confirment qu'un patch a été soumis et intégré à llama.cpp pour supporter cette architecture.
Laguna est un modèle conçu spécifiquement pour le code generation. Son intégration montre que la relation entre Ollama et llama.cpp n'est pas à sens unique : Ollama ne se contente pas de consommer llama.cpp, il contribue au support de nouvelles architectures. C'est un signal positif pour la santé de l'écosystème open-source autour de l'inférence locale.
Pour les développeurs, cela signifie que les futurs modèles basés sur Laguna pourront être lancés avec un simple ollama run dès leur release en GGUF. Pas de compilation manuelle, pas de configuration complexe. C'est la promesse d'Ollama qui se concrétise grâce à cette migration.
❌ Erreurs courantes
Erreur 1 : Mise à jour sans vider le cache de modèles
Après la migration vers llama.cpp, certains modèles GGUF anciens peuvent utiliser un cache corrompu. Les symptômes : le modèle démarre mais produit du texte incohérent ou des erreurs de tokenisation.
Solution : Supprimez le cache avec ollama rm puis re-téléchargez le modèle. Les fichiers GGUF eux-mêmes n'ont pas changé, mais le cache d'inférence doit être régénéré.
Erreur 2 : Confondre GGML et GGUF
GGML est l'ancien backend (mort avec 0.30). GGUF est le format de fichier des modèles. Ce sont deux choses différentes. Vous pouvez toujours utiliser des fichiers GGUF — c'est même le format principal maintenant. Ce qui a disparu, c'est le moteur GGML qui les lisait.
Solution : Si un outil vous demande de choisir entre GGML et GGUF, choisissez toujours GGUF en 2026.
Erreur 3 : Ignorer les bugs de tokenisation multi-bytes
La migration a introduit des régressions sur la tokenisation des caractères multi-bytes (accents, caractères asiatiques, emojis). Si vous travaillez avec du texte non-ASCII, testez systématiquement avant de mettre en production.
Solution : Suivez les issues sur le GitHub d'Ollama. Un correctif est en cours de développement selon les retours de la communauté.
Erreur 4 : Penser que tout passe par llama.cpp
Sur Apple Silicon, MLX reste le backend par défaut. Forcer l'utilisation de llama.cpp sur Mac peut donner de moins bonnes performances que MLX natif.
Solution : Ne touchez pas aux paramètres de backend sur Mac. Ollama choisit automatiquement le meilleur moteur.
Bugs signalés : ce qui casse dans cette version
Aucune migration majeure ne se fait sans casse. Ollama 0.30 ne fait pas exception, et l'analyse d'InsiderLLM liste clairement les problèmes connus.
Le bug le plus impactant concerne la tokenisation multi-bytes. Certains utilisateurs rapportent que les caractères Unicode non-ASCII (comme les lettres accentuées en français, les caractères CJK ou certains emojis) sont mal découpés en tokens. Le modèle reçoit des tokens corrompus en entrée, ce qui produit des sorties incohérentes. C'est particulièrement problématique pour les utilisateurs francophones qui travaillent avec du texte naturel.
Un second problème touche la rétrocompatibilité. Les modèles GGUF quantifiés avec des méthodes très anciennes (pré-2024) peuvent ne plus se charger correctement. C'est un compromis acceptable : ces modèles sont obsolètes de toute façon, et les quantifications modernes (IQ4_XS, Q4_K_M, etc.) fonctionnent parfaitement.
Enfin, quelques rapports font état de crashs sporadiques sur les configurations multi-GPU AMD. Le support ROCm via llama.cpp est en amélioration constante, mais il reste le maillon faible par rapport à CUDA sur NVIDIA.
Si ces bugs vous inquiètent et que vous cherchez une alternative plus stable, notre comparatif Ollama vs LM Studio peut vous aider à évaluer les options.
La tension communautaire : Ollama vs llama.cpp
Ce changement architectural ravive un débat ancien dans la communauté open-source de l'IA locale. Quand llama.cpp a été créé par Georgi Gerganov, il s'agissait d'un fork du projet GGML. Ollama, de son côté, a construit son succès sur GGML puis est resté longtemps sans migrer. Certains contributeurs de llama.cpp estiment qu'Ollama a profité du travail communautaire sans suffisamment contribuer en retour.
La migration de 0.30 change la donne. Ollama intègre maintenant llama.cpp comme dépendance principale et contribue des patches (comme pour l'architecture Laguna). Mais le timing soulève des questions : pourquoi avoir attendu si longtemps alors que llama.cpp était le standard de fait depuis déjà plus d'un an ?
La réponse est probablement technique. MLX sur Mac fonctionnait bien avec l'ancienne architecture, et migrer un backend utilisé par des millions d'utilisateurs est un travail colossal. Mais le fait que cette migration coïncide avec l'arrivée de Nemotron 3 Ultra dans l'écosystème Ollama suggère aussi des motivations commerciales. NVIDIA a besoin que les modèles de nouvelle génération fonctionnent partout, et Ollama avait intérêt à être compatible.
Quoi qu'il en soit, l'utilisateur final y gagne. Un moteur unifié, moins de bugs de compatibilité, plus de modèles disponibles. La politique open-source est importante, mais le pragmatisme l'emporte quand il s'agit de faire tourner des modèles sur du vrai hardware. Pour ceux qui veulent comprendre les enjeux plus larges autour des moteurs d'inférence, notre article sur OpenClaw, l'agent IA qui change tout aborde les mêmes tensions entre standardisation et innovation.
L'impact sur les workflows agents en local
Là où cette migration prend tout son sens, c'est du côté des agents. Les workflows agents génèrent des dizaines, parfois des centaines d'appels LLM par session. Chaque appel implique un prompt système, un contexte, et une génération. La vitesse d'inférence et la fiabilité du moteur deviennent critiques.
Avec llama.cpp et la flash-attention par défaut, les modèles comme le Qwen3.6-27B ou le Qwen3.5-122B-A10B deviennent viables comme moteurs d'agents en local. Le temps de latence par appel baisse suffisamment pour qu'une boucle agent (réflexion → action → observation) reste fluide. Notre article sur un agent IA qui travaille pendant que je dors montre exactement ce genre de workflow.
L'arrivée de Nemotron 3 Ultra en mode cloud via Ollama ouvre une autre possibilité : un agent local qui délègue les tâches complexes à un modèle cloud, tout en gardant les tâches routinières en local. Même API, même interface, mais un routage intelligent entre local et cloud selon la complexité de la tâche. C'est l'architecture hybride que beaucoup de développeurs attendaient.
Pour construire ces agents, le guide des agents IA open source avec Ollama détaille les patterns de conception et les outils disponibles.
❓ Questions fréquentes
Dois-je réinstaller tous mes modèles après la mise à jour ?
Non. Les fichiers GGUF sont compatibles. Seul le cache d'inférence doit être régénéré. Supprimez et re-téléchargez les modèles qui posent problème, pas tous systématiquement.
Ollama 0.30 est-il plus rapide sur tous les modèles ?
Pas universellement. Les gains sont significatifs sur Qwen et Gemma grâce à la flash-attention. Sur d'autres familles de modèles, la différence est minime ou nulle selon votre hardware.
Puis-je quand même utiliser GGML ?
Non. Le backend GGML a été entièrement retiré. Si vous avez des modèles au format GGML (ancien), vous devez les convertir en GGUF avec un outil comme llama.cpp-convert.
Nemotron 3 Ultra tourne-t-il en local ?
Non. Les 550 milliards de paramètres le rendent impossible à faire tourner sur du hardware grand public. Il est accessible via Ollama en mode cloud avec la même API que vos modèles locaux.
La migration affecte-t-elle les utilisateurs Mac ?
Oui et non. Sur Apple Silicon, le backend MLX reste utilisé par défaut. Mais la gestion globale des modèles GGUF a changé, donc certains comportements peuvent différer. Les bugs de tokenisation multi-bytes affectent aussi les Mac.
✅ Conclusion
Ollama 0.30 est la mise à jour la plus importante depuis la création du projet : un changement de moteur qui résout des problèmes de compatibilité accumulés pendant deux ans, débloque la flash-attention sur les modèles populaires, et ouvre la porte à de nouvelles architectures comme Laguna et Nemotron 3 Ultra. Les bugs de tokenisation sont réels mais temporaires. Si vous faites tourner des LLM en local, mettez à jour Ollama et choisissez vos modèles dans notre sélection — le gain en stabilité et en performance en vaut la peine.