Guide llama.cpp v1.0 : nouveautés et procédure de mise à niveau

Sorti le 13 novembre 2026, llama.cpp v1.0.0 inaugure la première version stable régie par semver : toute modification incompatible de l’API C publique nécessite désormais un changement de version majeure. GitHub marque le tag Latest. Les notes de version présentent une release de nettoyage et de compatibilité, avec la suppression d’API, de nouveaux caches et une prise en charge élargie des modèles.

v1.0 garantit une version stable, pas un gain de vitesse

D’après la section consacrée aux changements d’API dans les notes de version, la promesse de compatibilité concerne l’API C publique de llama.h. Les options CLI, les routes du serveur et le comportement des versions nightly restent donc susceptibles d’évoluer. Utilisez le tag v1.0.0 pour obtenir des builds reproductibles ; réservez les nightly par commit — la page de la release référence la nightly b12359 aux côtés de v1.0.0 — aux cas où vous avez besoin de correctifs plus récents.

« Est-ce que cela signifie qu’ils vont enfin stabiliser les paramètres CLI, au lieu de les modifier à chaque release au point qu’aucune application ne puisse vraiment dépendre d’upstream ? » — u/halvacoffee sur r/LocalLLaMA

Avant la mise à niveau : 4 vérifications pour vos scripts et intégrations

Ces changements de compatibilité touchent surtout les installations anciennes. Commencez par rechercher les occurrences suivantes :

grep -rn "llama_set_warmup\|clip\.h\|--mmap\|--no-mmap\|--defrag-thold\|:8080\|localhost:8080" .

Vérification 1 : les fonctions C supprimées — mettez vos bindings à jour

D’après les notes de version, v1.0 supprime 35 fonctions obsolètes de llama.h, dont llama_set_warmup, ainsi que le champ defrag_thold et l’option --defrag-thold. Un symbole est renommé : llama_set_embd_state_src devient llama_set_ctx_state_src. L’API NextN est par ailleurs intégrée à llama.h. La liste complète des suppressions figure dans le changelog de la release indiqué plus haut.

Vérification 2 : le port du serveur passe de 8080 à 9931 — corrigez vos URL

llama-server écoute désormais par défaut sur http://127.0.0.1:9931. Les anciens exemples utilisent encore 8080, comme le rappelle le guide d’installation d’Axiomi. Mettez à jour les vérifications d’état et les URL de base de vos éditeurs, ou ajoutez --port 8080 pour conserver l’ancien port.

Vérification 3 : --mmap n’est plus accepté — passez aux modes de chargement -lm

Si votre build rejette --mmap avec error: invalid argument: --mmap, utilisez son remplacement documenté -lm, --load-mode (auto, none, mmap, mlock, mmap+mlock, dio). Commencez par -lm auto, puis vérifiez le comportement avec llama-cli --help et un test de chargement représentatif.

Vérification 4 : clip.h disparaît — migrez le code vision vers mtmd

Les intégrations vision basées sur clip.h doivent migrer vers mtmd, qui partage les buffers de calcul entre les sous-contextes, conformément aux notes de version. Consultez la section consacrée à la multimodalité dans la release pour connaître les particularités de chaque modèle avant de mettre à niveau vos pipelines vision.

Les vraies nouveautés de llama.cpp v1.0

Cinq ajouts sont particulièrement intéressants pour l’exécution en local, selon les notes de version.

Installer le serveur compatible avec l’API OpenAI

Cette procédure s’appuie sur les nouveaux paramètres par défaut — port 9931, llama-cli / llama-server et téléchargements via -hf — présentés dans la documentation officielle d’installation et le guide de configuration d’Axiomi.

1. Installer :

curl -LsSf https://llama.app/install.sh | sh

Vous pouvez aussi utiliser un gestionnaire de paquets ou télécharger un ZIP précompilé depuis la page des releases. Vérifiez l’installation avec llama-cli --version. Pour du matériel non pris en charge, des patches personnalisés ou des correctifs non fusionnés, compilez plutôt depuis les sources.

2. Converser dans le terminal :

llama-cli -hf ggml-org/Qwen3.5-0.8B-GGUF -c 8192

Comme l’explique le guide d’Axiomi, -hf met les modèles en cache depuis Hugging Face et choisit Q4_K_M lorsqu’aucun suffixe :quant n’est fourni. La valeur par défaut --fit on ajuste les paramètres non définis pour tenir compte de la mémoire disponible sur l’appareil.

3. Exposer une API locale :

llama-server -hf ggml-org/Qwen3.5-0.8B-GGUF -c 8192
# open http://127.0.0.1:9931

Les routes disponibles comprennent /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/messages et /v1/audio/speech (liste des routes d’Axiomi). Pour effectuer un test rapide :

curl http://localhost:9931/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Explain GGUF in one sentence."}]}'

Le même guide propose, dans son exemple Python, base_url="http://localhost:9931/v1" avec api_key="no-key" pour servir localement un seul modèle. Pour un usage local, conservez 127.0.0.1.

v1.0, nightly, wrappers ou API hébergée : que choisir ?

FAQ

v1.0 est-elle stable, et mon installation actuelle fonctionnera-t-elle toujours ?

La promesse de stabilité concerne l’API C publique ; les options CLI, les routes serveur et les nightly n’en bénéficient pas. Avant la mise à niveau, recherchez llama_set_warmup, clip.h, --mmap, --defrag-thold et les occurrences codées en dur de 8080.

De combien de mémoire un modèle 8B a-t-il besoin ?

Le tableau de tailles de Tech Insider indique environ 4,9 Go pour un 8B en Q4_K_M, contre 32,1 Go sans quantification, avant de tenir compte du contexte et du runtime. Comme règle générale, mesurez votre propre machine avec llama-bench : les chiffres CPU obtenus sur de petits modèles ne sont pas transposables.

Épinglez v1.0 pour tout ce que vous livrez

Épinglez le tag dans votre CI, gardez une machine sur les nightly et retestez vos wrappers avec le serveur épinglé avant de les mettre à niveau.