Installer llama.cpp sur votre propre machine, et voir ce qu’il envoie

Pour faire tourner llama.cpp, vous téléchargez 1 compilation toute prête pour votre machine, ou vous l’installez avec Homebrew, puis vous tapez 1 commande : llama serve -hf suivi d’un nom de modèle. Elle télécharge le modèle, ouvre un serveur compatible OpenAI et une page de conversation dans votre navigateur, le tout sur 127.0.0.1:9931 (8080 dans la v0.6.0 et les versions antérieures), et rien ne part nulle part de lui-même. 2 réglages à poser dès le premier jour : une taille de contexte avec -c 8192, et un CORS resserré avec --cors-origins localhost.

Avouons-le : c’est celui qui nous enthousiasme le plus. llama.cpp est le moteur tout en bas de la pile, le code C/C++ sur lequel s’appuient la plupart des logiciels d’IA locale, et le lancer directement, c’est un peu comme soulever le capot. C’est aussi celui qui bouge le plus vite de tout ce que nous suivons. Cette page s’appuie sur la version stable, la v0.7.0, publiée le 15 octobre 2026, et sur la compilation quotidienne b11321, publiée le 1er octobre 2026 à 14 h 09 UTC. Chaque valeur par défaut citée ici a été lue dans le code de la b11321 et de la v0.5.0, puis vérifiée à nouveau dans le code de la v0.6.0 le 6 octobre 2026 et dans celui de la v0.7.0 le 16 octobre 2026 : seul le port a changé, 9931 au lieu de 8080. Nous avons aussi démarré la compilation Linux officielle sur notre propre serveur pour voir ce qu’elle fait.

llama.cppFiche logiciel→

Ce qu’est llama.cpp, et la nouvelle commande llama

llama.cpp fait tourner des modèles de langage stockés en fichiers GGUF, un format créé par ce même projet, sur presque n’importe quel matériel : Apple Silicon via Metal, NVIDIA via CUDA, AMD via ROCm ou Vulkan, Intel via SYCL ou OpenVINO, et les processeurs tout seuls. Il est open source, sous licence MIT, et le moteur, le serveur et l’interface web vivent tous dans 1 seul dépôt. La fiche llama.cpp : ce qu’il envoie et si vous pouvez l’auditer couvre l’audit ; ce guide en est le versant pratique.

Le grand changement de 2026, c’est un exécutable unique baptisé llama. Ses sous-commandes visibles sont :

• llama serve : le serveur HTTP, avec l’API compatible OpenAI et l’interface web.
• llama cli : une conversation dans le terminal.
• llama download : récupère un modèle sans rien démarrer.
• llama version, llama licenses et llama help. llama help all liste en plus bench, quantize, perplexity et quelques autres.

Les classiques llama-server et llama-cli sont toujours dans le paquet Linux que nous avons décompressé, à côté de llama : les anciennes instructions continuent donc de marcher. Dans la b11321, llama --version affiche 0.5.0-dev (build 11321, commit b0aca3c65) : une compilation quotidienne, c’est la version stable plus tout ce qui a été fusionné depuis.

Si vous préférez cliquer plutôt que taper, Installer LM Studio et son serveur local, et voir ce qu’il envoie et Installer Ollama en local, vérifier qu’il tourne et voir ce qu’il envoie vous mènent à une première réponse avec moins de décisions à prendre. llama.cpp, c’est pour le jour où vous voulez tous les boutons.

Stable ou quotidienne : quelle version vous donne chaque installateur

llama.cpp a 2 canaux. Le stable porte des étiquettes comme v0.7.0 ; le quotidien publie une compilation numérotée, bNNNNN, chaque fois que la branche principale bouge. Entre le 30 septembre à 10 h 32 UTC et le 1er octobre à 14 h 09 UTC, il y en a eu 30. Les installateurs ne suivent pas tous le même, et le 1er octobre 2026, voici ce qu’ils donnaient :

Installateur	Commande	Version au 1er octobre 2026
Homebrew (Mac et Linux)	brew install llama.cpp	0.5.0, le canal stable
Script de llama.app (Mac et Linux)	curl -fsSL https://llama.app/install.sh | sh	b11200, une compilation quotidienne
winget (Windows)	winget install llama.cpp	b11193, une compilation quotidienne
Publications GitHub (tous les systèmes)	télécharger et décompresser	b11321, la compilation quotidienne que suit ce guide ; v0.5.0 pointe vers la compilation b11146

API des formules Homebrew, manifestes des paquets winget, script d’installation de llama.app et API des publications GitHub, lus le 1er octobre 2026 entre 14 h 52 et 14 h 59 UTC. Le 6 octobre 2026, Homebrew servait déjà la 0.6.0, la version stable publiée la veille, et depuis le 16 octobre 2026, il sert la 0.7.0.

Homebrew est la voie tranquille : il vous donne la version stable, avec des paquets pour Apple Silicon et pour Linux en x86_64 et arm64. Le script de llama.app est celui que le README du projet place désormais en tête. Il télécharge de petits programmes sondes qui détectent CUDA, puis ROCm, puis Vulkan, avant de se rabattre sur le processeur ; il installe la compilation correspondante dans ~/.llama-app et la copie dans ~/.local/bin/llama. Sur Mac, il cherche les puces M1 à M5 (et l’A18) ; sur un Mac Intel, le script s’arrête sur No prebuilt llama binary is available for your system, autrement dit : aucun binaire prêt pour votre système. C’est aussi la seule installation où llama update fonctionne, et la commande fonctionne en relançant ce même script. winget distribue des compilations quotidiennes, pas le canal stable.

Quelle compilation télécharger pour votre machine

La compilation b11321 sur GitHub compte 35 fichiers. Dans la plupart des cas, il vous en faut exactement 1 :

Votre machine	Le fichier à prendre (b11321)	Taille
Mac avec Apple Silicon	llama-b11321-bin-macos-arm64.tar.gz, avec Metal intégré	11,8 Mo
Linux avec une carte NVIDIA	llama-b11321-bin-ubuntu-cuda-13.4-x64.tar.gz (ou cuda-12.8-x64), plus son fichier de bibliothèques cudart-…	152,2 Mo + 440,2 Mo
Windows avec une carte NVIDIA	llama-b11321-bin-win-cuda-13.4-x64.zip (ou cuda-12.4-x64), plus cudart-llama-bin-win-cuda-13.4-x64.zip	152,8 Mo + 423,5 Mo
GPU AMD, Intel ou autres	la compilation vulkan : ubuntu-vulkan-x64 ou win-vulkan-x64. Des compilations ROCm 10.0 existent pour Linux et Windows	31,5 Mo / 33,2 Mo
Pas de GPU utilisable	ubuntu-x64 ou win-cpu-x64	17,5 Mo / 19,3 Mo

Noms et tailles des fichiers tirés des pièces jointes de la publication b11321 sur GitHub, lus le 1er octobre 2026.

La compilation pour Mac Intel existe, mais le projet la compile avec Metal désactivé : sur un Mac Intel, llama.cpp tourne donc sur le processeur seul. Si vous hésitez entre nos machines, voici les 3 que nous prenons comme exemples plus bas :

PC avec RTX 4060 8 GoFiche matériel→ PC avec RTX 3060 12 GoFiche matériel→ Mac avec M4 et 16 Go unifiésFiche matériel→

Décompressez le fichier, ouvrez un terminal dans ce dossier et lancez ./llama --version. Sous Linux, les bibliothèques sont posées à côté du programme ; nous avons démarré la compilation pour processeur depuis son propre dossier, avec LD_LIBRARY_PATH pointant dessus. Si vous aimez regarder quelqu’un faire une installation avant de vous lancer, cette démonstration est une bonne compagne de route. Les commandes bougent à chaque compilation : là où la vidéo et cette page divergent, cette page suit la compilation b11321.

Votre premier modèle : llama serve -hf et llama cli

La commande que donne le README du projet :

llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

-hf prend un dépôt Hugging Face, éventuellement suivi d’une compression après deux-points, comme :Q4_K_M. Sans précision, llama.cpp choisit Q4_K_M, la même compression que celle de nos tailles de modèles, ou le premier fichier du dépôt s’il n’y a pas de Q4_K_M. Si le modèle a une partie vision, son fichier mmproj vient avec (--no-mmproj l’écarte). Ouvrez ensuite http://127.0.0.1:9931 dans votre navigateur : la page de conversation vous attend. C’est l’adresse de la version stable v0.7.0 et des compilations quotidiennes depuis la b11521 (9 octobre 2026). La v0.6.0 et les versions antérieures, ainsi que les compilations quotidiennes plus anciennes comme la b11321 du tableau ci-dessus, écoutent sur le 8080, tout comme une installation Homebrew antérieure au 16 octobre 2026, qui vous donnait la 0.6.0 : avec celles-ci, ouvrez donc http://127.0.0.1:8080, ou lancez-le avec --port 9931 et toutes les adresses de cette page fonctionnent telles quelles.

Pour converser plutôt dans le terminal :

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

Et pour vérifier l’API depuis un autre terminal :

curl http://127.0.0.1:9931/health
curl http://127.0.0.1:9931/v1/models

Pour un client OpenAI, l’URL de base est http://127.0.0.1:9931/v1.

Sans aucun modèle, llama serve démarre quand même. Nous avons essayé : il a affiché starting server in router mode. models will be automatically loaded on-demand (il démarre en mode routeur et chargera les modèles à la demande), a listé les modèles déjà présents dans son cache (0, sur un compte neuf) et les a chargés sur demande, jusqu’à 4 à la fois par défaut. Il a aussi affiché router mode enabled – do not expose to untrusted environments, soit : ne l’exposez pas à des environnements non fiables. Un bon conseil, que la partie sur le verrouillage transforme en commandes.

Si llama.cpp s’arrête sur une erreur, ici ou plus tard, notre guide des erreurs de llama.cpp en passe 8 en revue une par une, chacune avec le message exact que vous verrez et sa solution.

La mémoire : le contexte complet par défaut, et ce qu’en fait --fit

C’est la valeur par défaut qui surprend. La taille de contexte de llama.cpp, -c, vaut par défaut 0, ce qui veut dire loaded from model : reprise du modèle, c’est-à-dire le contexte le plus long pour lequel il a été entraîné. Pour qwen3-4b-2507, cela fait 262 144 tokens.

Quand ça ne tient pas, la suite n’a rien à voir avec vLLM, qui refuse de démarrer. llama.cpp a --fit, activé par défaut, qui ajuste chaque réglage que vous n’avez pas fixé vous-même, dans cet ordre : d’abord il réduit le contexte, jusqu’à un plancher de 4 096 tokens ; ensuite il décide combien de couches vont sur le GPU et met le reste en mémoire vive, en laissant 1 024 Mio libres sur chaque périphérique. -ngl, le nombre de couches sur le GPU, vaut par défaut auto, ce qui laisse cette décision à --fit, et l’attention flash, -fa, vaut elle aussi auto par défaut.

Le serveur démarre donc, mais pas forcément avec le contexte que vous attendiez, et peut-être avec une partie du modèle sur le processeur, ce qui est plus lent. Le remède, c’est de dire ce que vous voulez :

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

Notre trouveur de modèle et nos fiches de machine calculent tout à 8 192 tokens : avec -c 8192, llama.cpp colle aux chiffres de notre site. Voici ce que cela change sur nos 3 machines d’exemple, chaque modèle en Q4_K_M :

Machine (mémoire pour le modèle)	Modèle	Besoin à 8 192 tokens	Besoin au maximum du modèle	Contexte le plus long qui tient (cache 16 bits)
RTX 4060 8 Go (7,20 Gio)	qwen3-4b-2507	4,20 Gio	43,73 Gio à 262 144 (dont 36,0 Gio de cache)	16 384
RTX 4060 8 Go (7,20 Gio)	qwen3-8b	6,56 Gio, tout juste	11,66 Gio à 40 960	8 192
RTX 3060 12 Go (11,20 Gio)	gemma4-12b	7,82 Gio	16,35 Gio à 262 144	65 536
Mac avec M4 et 16 Go (13,00 Gio)	gpt-oss-20b	11,77 Gio, tout juste	16,83 Gio à 131 072	32 768

Notre calcul, avec le moteur qui fait tourner notre trouveur de modèle : fichier du modèle en Q4_K_M, plus le cache KV d’après la disposition réelle de l’attention de chaque modèle, plus la mémoire de travail ; données de modèles du 30 septembre (du 15 octobre pour gemma4-12b) et données machines du 1er octobre 2026. « Contexte le plus long » désigne la plus grande valeur parmi 4 096, 8 192, 16 384… jusqu’au maximum du modèle qui tienne encore. Ce n’est pas l’algorithme --fit de llama.cpp, qui peut aussi déplacer des couches vers la RAM.

qwen3-4b-2507Fiche modèle→ gemma4-12bFiche modèle→

Aucun des 4 modèles ne tient à son propre maximum sur la machine de sa ligne. Demandez le contexte complet sur une 4060 avec qwen3-4b-2507, et il lui faudrait plus de 5 fois la carte (un petit 4B qui réclame un datacenter, rien que ça).

Si vous préférez que llama.cpp vous prévienne au lieu de décider à votre place, --fit off coupe l’ajustement, et -ngl all demande toutes les couches sur le GPU. Demander explicitement -c 0 désactive aussi la réduction du contexte : vous avez le contexte complet, ou les couches partent en RAM.

Le verrouiller : CORS ouvert, aucune clé et un nouveau port

Réglé d’origine, llama serve n’écoute que sur 127.0.0.1, sur le port 9931 (8080 dans la v0.6.0 et les versions antérieures). Nous avons vérifié le socket sur notre serveur : rien sur les autres interfaces réseau. C’est la bonne nouvelle, et elle range llama.cpp avec Ollama, LM Studio et MLX, pas avec vLLM.

Le reste demande votre attention :

• Aucune clé. Quiconque peut joindre le port peut s’en servir.
• Le CORS renvoie n’importe quelle origine, avec les identifiants. Nous avons envoyé une requête avec l’en-tête Origin: https://some-site.example, et le serveur a répondu Access-Control-Allow-Origin: https://some-site.example et Access-Control-Allow-Credentials: true. En clair : une page web que vous ouvrez dans votre navigateur peut envoyer des requêtes à votre serveur local et lire les réponses, tant qu’il tourne. Le serveur le signale au démarrage : security: no API key is set and CORS allows all origins, autrement dit aucune clé d’API et un CORS ouvert à toutes les origines.
• La page de conversation est activée par défaut, sur le même port.

Ce qui le ferme :

export LLAMA_API_KEY="une-longue-chaine-aleatoire"
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF -c 8192 --cors-origins localhost

• --cors-origins localhost ne laisse dialoguer avec lui que les pages servies depuis localhost. Une liste d’origines exactes, séparées par des virgules, fonctionne aussi.
• LLAMA_API_KEY, ou --api-key, oblige les clients à envoyer la clé comme jeton Bearer. La variable garde la clé hors de la liste des processus. --api-key-file lit plusieurs clés depuis un fichier.
• --no-ui coupe la page de conversation si vous ne voulez que l’API.

Le port. Le changement qu’annonçait le serveur est désormais aussi dans le canal stable : le port par défaut est 9931 dans la v0.7.0, publiée le 15 octobre 2026, et dans les compilations quotidiennes depuis la b11521 (9 octobre). La v0.6.0 et les compilations antérieures écoutent sur 8080 et affichent alors notice: server default port will be changed to :9931 in a future release ; depuis la b11521, cet avis a disparu. Depuis le 16 octobre 2026, Homebrew installe la 0.7.0 : si vous avez encore une 0.6.0 installée avant cette date, brew upgrade vous fait passer de 8080 à 9931. Les images Docker du projet gardent 8080 à l’intérieur du conteneur. Si vos scripts dépendent de 8080, écrivez-y --port 8080 et aucune mise à jour ne le déplacera. --host accepte aussi le chemin d’un socket UNIX se terminant par .sock et, depuis la v0.5.0, plusieurs adresses séparées par des virgules.

Ce que llama.cpp envoie de lui-même, et ce qui part quand vous le demandez

De lui-même : rien. Nous avons cherché, dans le code de la compilation b11321 qui forme le moteur, le serveur, le client en terminal et l’interface web, des bibliothèques d’analytique, de télémétrie ou de pistage, et nous n’en avons trouvé aucune. Les adresses écrites dans ce code sont des liens affichés dans des messages et des textes d’aide, plus les services ci-dessous, que llama.cpp ne contacte que sur votre commande. Quand nous avons démarré le serveur sans modèle et avec un dossier personnel vide, son journal n’a montré aucune requête sortante et le dossier est resté vide. C’est ce que nous avons lu et ce que nous avons vu dans le journal ; nous n’avons pas capturé le trafic réseau.

Ce qui part quand vous le demandez :

• Les téléchargements de modèles, avec -hf, --model-url ou llama download, vont vers huggingface.co. La requête identifie le programme comme llama-cpp/ suivi du numéro de compilation et du commit, et transporte votre HF_TOKEN si vous en avez défini un.
• Les modèles empaquetés en images de conteneur, uniquement avec --docker-repo, vont vers le registre de Docker.
• llama update, uniquement sur les installations faites avec le script de llama.app, télécharge ce script et le relance.

Où vont les modèles. Dans le cache standard de Hugging Face, ~/.cache/huggingface/hub, avec la même arborescence que les outils de Hugging Face eux-mêmes : un modèle déjà téléchargé avec un autre programme ne l’est pas une seconde fois. LLAMA_CACHE, HF_HUB_CACHE ou HF_HOME le déplacent. Une fois vos modèles en place, --offline (ou LLAMA_ARG_OFFLINE=1) oblige llama.cpp à utiliser le cache et lui interdit l’accès au réseau.

Où vont les conversations. La page de conversation garde vos échanges dans le stockage de votre navigateur, pas dans un dossier du serveur, d’après notre audit de la fiche. Effacer les données du site dans le navigateur les supprime. Le cache de prompts du serveur vit en RAM, 8 192 Mio au maximum par défaut, et n’est pas écrit sur le disque sauf si vous le demandez.

L’ordre qui vous laisse un llama.cpp qui marche et qui reste fermé :

1. Choisissez votre canal : brew install llama.cpp pour la version stable, ou la compilation exacte pour votre machine sur la page des publications GitHub.
2. Vérifiez avec llama --version et notez le numéro de compilation.
3. Définissez LLAMA_API_KEY avant le premier llama serve.
4. Démarrez avec -c 8192 --cors-origins localhost, et ajoutez --port 8080 si quelque chose dépend de l’ancien port (depuis la v0.7.0, le port par défaut est 9931).
5. Si le modèle tient tout juste, ajoutez -ctk q8_0 -ctv q8_0 avant de baisser le contexte.
6. Une fois vos modèles téléchargés, ajoutez --offline.

Les autres guides de cette série couvrent Installer MLX sur Mac avec mlx-lm, et voir ce qu’il envoie et Installer vLLM sur votre propre machine, et voir ce qu’il envoie, et les 5 logiciels sont comparés côte à côte dans 5 logiciels d’IA locale : télémétrie, appels et audit. Si vous hésitez entre llama.cpp et Ollama, qui fait tourner en interne le serveur de llama.cpp, notre comparatif llama.cpp vs Ollama met leurs réglages d’origine côte à côte.