Ollama suffit à la plupart des usages. Quand vous devez comprendre ce qui se passe sous le capot — backend CUDA, Metal ou Vulkan, nombre de couches offloadées, taille de contexte — llama.cpp devient l’outil de référence. Ce tutoriel s’adresse aux profils développeurs : compiler, lancer `llama-server`, lire les flags, et mesurer chez vous. Pas de tableau de records : une méthode pour gagner en contrôle sur un PC de Douai, un Mac de Lille ou un serveur associatif à Amiens.
Pourquoi passer sous Ollama
Ollama emballe llama.cpp (ou des briques proches) avec une UX simple. En descendant d’une couche, vous choisissez le backend exact, des flags expérimentaux, et un serveur HTTP que vous branchez où vous voulez. Utile pour du tuning, du debug, ou un environnement contraint où vous ne pouvez pas installer Ollama. Moins utile si votre seul besoin est un chat stable pour l’équipe — dans ce cas, restez sur Open WebUI + Ollama.
Le format GGUF domine l’échange de poids quantifiés pour cet écosystème. Téléchargez toujours depuis une source que vous assumez (dépôt Hugging Face clair, checksum si fourni). Un fichier « q4 magic » trouvé au hasard sur un forum n’a pas sa place sur le poste d’une collectivité à Cambrai.
Choisir le backend : CUDA, Metal, Vulkan, CPU
NVIDIA bien supporté côté CUDA : pilotes à jour, toolkit selon la doc llama.cpp du commit que vous compilez. Apple Silicon : Metal est le chemin naturel (voir aussi Mac MLX pour une autre famille). AMD et certains GPU variés : Vulkan est souvent la porte d’entrée pragmatique ; ROCm est un autre monde, traité dans GPU AMD. CPU only : possible pour apprendre ou tout petits modèles.
| Backend | Quand le viser | Point de vigilance |
|---|---|---|
| CUDA | GPU NVIDIA récent | Versions CUDA / pilote alignées au README |
| Metal | Mac Apple Silicon | Build sur machine native arm64 |
| Vulkan | AMD ou portabilité | Pilotes, et perf variables |
| CPU | Smoke test / secours | Lenteur sur gros GGUF |
Pas à pas : de la compile au serveur
Installer la chaîne de compilation
Sur Linux, paquets de build essentiels et, selon backend, CUDA toolkit ou dépendances Vulkan. Sur Windows, une toolchain CMake/Visual Studio selon la doc. Sur Mac, clang et CMake. Vérifiez `cmake --version` et un compilateur C++ avant de cloner. Sur un poste verrouillé d’entreprise à Lille, cette étape peut demander un ticket DSI : anticipez. Si quelque chose échoue, arrêtez-vous et notez le message exact avant de retenter. Une capture d’écran des logs vaut mieux qu’une reformulation de mémoire, surtout quand un collègue de Douai ou Arras reprendra le dossier le lendemain.
Cloner le dépôt et épingler un commit
Clonez le dépôt officiel llama.cpp. Notez le hash de commit ou le tag dans votre README interne. Compiler « n’importe quelle main » un lundi puis un vendredi produit des binaires différents : pour un service interne à Arras, la reproductibilité compte. Créez un dossier de build séparé du sources. Gardez un bloc-notes ouvert : commande tapée, résultat attendu, résultat obtenu. Cette trace courte accélère le dépannage et évite de croire qu’« on a déjà essayé » sans preuve. Complétez par un test de non-régression : refaites le même geste après avoir fermé puis rouvert l’outil, afin de confirmer que la configuration survit au redémarrage et reste compréhensible pour un collègue qui n’a pas suivi toute la session.
Configurer CMake avec le bon backend
Invoquez CMake en activant les options documentées pour CUDA, Metal ou Vulkan sur votre version. Lisez le README du commit : les flags `-D...` ont déjà renommé plusieurs fois. En cas d’échec, un build CPU d’abord prouve que la chaîne compile. Ne cherchez pas à activer tous les backends « pour voir ». Vérifiez aussi l’environnement : VPN, proxy, antivirus, espace disque. Beaucoup d’échecs attribués au modèle viennent d’un réseau d’entreprise à Lille ou d’un disque plein après plusieurs pulls.
Compiler et vérifier les binaires
Lancez la compile (`cmake --build` avec le niveau de parallélisme adapté à votre RAM). Repérez les binaires utiles : CLI de chat, `llama-server`, outils de bench du dépôt. Un échec de lien CUDA pointe souvent vers des chemins de librairies, pas vers « le modèle ». Gardez le dossier de build pour ne pas recompiler sans raison. Quand l’étape réussit, marquez-la explicitement dans votre checklist. Les bascules trop rapides vers l’étape suivante masquent des configs demi-installées qui cassent plus tard en démo publique.
Récupérer un GGUF et lancer llama-server
Téléchargez un GGUF dont la quantification correspond à votre mémoire (guide machine). Lancez `llama-server` avec `-m` vers le fichier, le port local, et des flags initiaux conservateurs pour le contexte. Ouvrez l’UI web embarquée si présente, ou pointez un client compatible. Smoke test : une phrase en français. Si vous travaillez à deux, faites reformuler le geste par la personne la moins technique. Ce qui n’est pas dit clairement maintenant reviendra en ticket flou après l’atelier.
Régler -ngl, threads, contexte — puis seulement peaufiner
Augmentez progressivement les couches GPU (`-ngl` ou équivalent documenté), ajustez les threads CPU, fixez un contexte réaliste. Changez un paramètre à la fois. Pour comparer deux réglages, réutilisez les mêmes prompts. Les outils de type `llama-bench` du dépôt aident à comparer chez vous : ne republiez pas leurs sorties comme des vérités universelles. Testez une fois « à froid » après redémarrage de la machine. Un service qui ne survit pas au reboot n’est pas prêt pour une permanence à Valenciennes ou Amiens.
Compile : gestes et pièges
Épinglez les versions. Documentez OS, GPU, pilote, commit. Un binaire CUDA compilé sur une machine ne se copie pas forcément sur une autre avec pilote plus ancien. Sur un parc hétérogène (Mabuege, Laon, siège), compilez par profil matériel ou utilisez Ollama pour uniformiser.
git clone https://github.com/ggerganov/llama.cpp cd llama.cpp git checkout COMMIT_OU_TAG_EPINGLE cmake -S . -B build -DGGML_CUDA=ON # exemple NVIDIA — lisez le README cmake --build build --config Release -j # Binaires typiquement sous build/bin/
llama-server : exposer une API locale
`llama-server` expose une API HTTP utile pour brancher des fronts ou des scripts. Écoutez sur localhost par défaut pour les essais. Ouvrir sur `0.0.0.0` dans un open space de Roubaix sans authentification revient à offrir votre GPU aux voisins de Wi-Fi. Placez un reverse proxy et une auth si vous partagez sur le LAN.
./build/bin/llama-server \ -m /chemin/vers/modele.gguf \ -c 4096 \ -ngl 99 \ --host 127.0.0.1 \ --port 8080 # -c et -ngl : valeurs d’exemple à ajuster ; 99 = « autant que possible » selon versions
Si le serveur refuse de charger, regardez le message : fichier GGUF incomplet, manque mémoire, backend non compilé. Si le serveur charge mais répond très lentement, baissez contexte ou augmentez l’offload GPU (quand la VRAM le permet). Si la VRAM explose, faites l’inverse.
Paramètres clés à comprendre
Le contexte (`-c`) fixe la fenêtre de tokens de travail : plus grand n’est pas toujours mieux. Les threads CPU aident surtout la partie non offloadée. L’offload GPU (`-ngl`) envoie des couches au GPU : trop bas sous-utilise la carte ; trop haut fait échouer le chargement. La quantification est dans le fichier GGUF lui-même : changer de flag ne « requantifie » pas un modèle.
Batch, flash attention, mmap et autres options avancées existent selon les versions : activez-les seulement si vous comprenez le trade-off et si le README les mentionne pour votre backend. Le tuning sans méthode produit des configurations impossibles à reproduire le lundi matin.
Mesurer sans folklore
Utilisez les outils fournis dans le dépôt (souvent `llama-bench` ou équivalent) pour comparer deux builds sur la même machine. Gardez les résultats dans un fichier daté, pour vous. Ne les transformez pas en classement public absolu. Une mesure sur un PC gamer de Valenciennes ne dit rien d’un Mac Mini d’association.
Pour un usage pédagogique, chronométrez aussi le temps jusqu’à la première réponse utile sur un prompt métier (mail, résumé d’une délibération courte). Ce chronomètre « ressenti usager » complète le banc technique. Si le banc est brillant mais le mail met trop longtemps à apparaître pour un agent à Arras, le réglage n’est pas bon pour le service. Notez ces deux mesures côte à côte dans le journal : elles divergent souvent, et c’est précisément cette divergence qui guide le preset « quotidien » plutôt que le preset « vanity bench ». En atelier IAHDF, montrez les deux chronos au public : cela désamorce la course aux captures hors contexte.
Quand garder Ollama, quand garder llama.cpp
Gardez Ollama (+ UI) pour l’équipe, les ateliers, le support. Gardez llama.cpp pour le labo, le serveur dédié, le besoin d’un flag précis. Certains profils exposent llama-server derrière leur propre front. D’autres ne compilent qu’une fois pour comprendre, puis reviennent à Ollama. Les deux attitudes sont saines.
Pour l’AMD, validez Vulkan ou la piste ROCm avant d’accuser le modèle : IA locale GPU AMD. Pour choisir la taille du GGUF, modèle selon machine.
Dépannage compile et runtime
CMake ne trouve pas CUDA : toolkit et variables d’environnement. Erreur Metal sur Mac Intel : vous n’êtes pas sur Apple Silicon. Vulkan qui marche mal : pilotes, ou backend encore rugueux sur votre GPU précis — testez un build CPU pour isoler. Segfault au chargement : GGUF tronqué (re-téléchargez). Port occupé : changez `--port`. Réponses absurdes : mauvais fichier, pas « CUDA trop rapide ».
Build qui réussit mais binaire absent du chemin attendu : selon générateurs CMake (Ninja, Visual Studio), les chemins `build/bin` vs `build/Release` diffèrent. Cherchez le nom du binaire plutôt que de recopier un chemin Linux sur Windows. Sur un poste CI d’une startup lilloise, formalisez ces chemins dans un script `run-server.sh` / `.ps1` versionné.
Méthode pour explorer un nouveau flag
Quand la doc mentionne une option séduisante (flash attention, mmap, batch…), appliquez une discipline : lire l’aide du binaire de votre commit, noter la valeur par défaut, changer une option, rejouer trois prompts fixes, observer mémoire et stabilité. Si le gain n’est pas évident, revenez en arrière. Les flags « magiques » cumulés produisent des configs impossibles à expliquer à un collègue de Douai.
Gardez un fichier `presets.env` ou une liste de lignes de commande nommées (`fast-local`, `long-context`, `cpu-fallback`). En médiation numérique à Arras, pouvoir basculer de preset évite de retaper des commandes sous le stress d’un public.
- Preset smoke : petit GGUF, contexte court, localhost
- Preset quotidien : quantification confort, offload GPU mesuré
- Preset secours : CPU ou -ngl bas si le pilote crash
- Preset doc : même commande utilisée pour rédiger le README
Intégrer llama.cpp dans une petite équipe HdF
Un développeur compile, deux collègues consomment l’API. Documentez l’URL, le modèle chargé, les limites (pas de données personnelles), et la procédure de redémarrage. Placez un healthcheck simple (requête HTTP périodique). Sur un NAS ou un mini PC à Valenciennes, un redémarrage systemd / service Windows après reboot évite le ticket « l’IA est morte » chaque lundi.
Ne mélangez pas le serveur d’expérimentation et le serveur vu par les métiers sans étiquette claire. Un flag expérimental le vendredi soir ne doit pas se retrouver en production associative le samedi atelier. La séparation des environnements, même artisanale (deux ports, deux dossiers), sauve des week-ends.
Ajoutez une routine mensuelle : tirer éventuellement un nouveau GGUF sur l’environnement labo, rejouer vos prompts fixes, et seulement ensuite proposer le bascule métier. Cette cadence calme évite la course au dernier poids publié sur Hugging Face. Pour le choix de taille, croisez avec modèle selon machine ; pour AMD, validez le backend via ROCm ou Vulkan avant d’accuser llama.cpp.
Questions fréquentes
Dois-je recompiler à chaque modèle ?
Non. Vous recompilez quand le backend, le commit ou les options de build changent. Les GGUF se chargent ensuite en ligne de commande. Recompiler pour chaque tag serait une perte de temps. En revanche, notez quel binaire (commit) a servi pour une démo importante, au cas où un bug de frontière apparaît plus tard. Pour trancher chez vous, reproduisez le scénario sur la machine réelle avec un protocole court écrit à l’avance. Une conclusion d’atelier à Roubaix ne se transfère pas telle quelle sur un portable différent.
llama.cpp remplace-t-il Open WebUI ?
Non. llama-server offre une API et parfois une petite UI ; Open WebUI couvre comptes, RAG, UX équipe. Vous pouvez enchaîner les deux si vous maîtrisez les endpoints, mais ce n’est pas le chemin le plus simple. Pour la plupart des TPE des Hauts-de-France, Ollama + Open WebUI reste le duo pédagogique. Gardez une fiche datée : question, hypothèse, test, résultat. Cette hygiène évite les débats sans fin et construit une mémoire utile pour la prochaine personne référente. Ajoutez une vérification métier : demandez à une personne du terrain de reformuler le besoin en une phrase, puis vérifiez que votre réglage répond vraiment à cette phrase, pas seulement au scénario technique imaginé au départ.
Quel GGUF télécharger ?
Celui dont la fiche indique clairement l’auteur, la quantification et la licence, sur une source fiable. Adaptez la quantification à votre mémoire. Méfiez-vous des renommages fantaisistes. Si votre structure exige une traçabilité, archivez l’URL et la date de téléchargement avec le fichier. Si deux camps s’opposent dans l’équipe, imposez un A/B sur la même batterie de prompts plutôt qu’un vote d’opinion. Le terrain tranche plus vite que les digressions de salon. Documentez le contournement éventuel (petit modèle, localhost, hors VPN) pour ne pas rester bloqué en démonstration publique : un plan B écrit vaut mieux qu’une improvisation sous le regard d’un public à Lille ou Amiens.
Windows est-il un bon citoyen ici ?
Oui, avec une toolchain correcte et des pilotes GPU sains. Les scripts et chemins diffèrent de Linux ; suivez le README Windows du commit. WSL2 ajoute une couche : pratique pour certains, source de confusion GPU pour d’autres. Choisissez une voie et documentez-la. Méfiez-vous des captures hors contexte trouvées en ligne. Sans connaître quantification, contexte et charge machine, un chiffre spectaculaire ne dit rien de votre poste à Beauvais. Mesurez aussi le confort subjectif (bruit, chaleur, temps d’attente ressenti) : un réglage « correct » sur le papier mais pénible au quotidien ne sera pas adopté par une équipe de collectivité ou d’association.
Par où commencer si je débute en compile ?
Build CPU d’abord, petit GGUF, llama-server en localhost. Puis activez le backend GPU. Cette progressivité évite de déboguer dix problèmes à la fois. Un atelier pair-programmation dans un meetup Lille aide souvent plus qu’une nuit seule face à CMake. Quand le problème semble intermittent, journalisez l’heure, la température perçue et les autres apps ouvertes. Les coïncidences thermiques et mémoire sont fréquentes sur machines partagées. Si le résultat est ambigu, changez une seule variable et rejouez immédiatement le même protocole : c’est la seule façon d’apprendre quelque chose d’exploitable plutôt que d’empiler des impressions contradictoires.