Passer au contenu principal
llama.cpp est l’environnement d’inférence locale le plus portable. Il fonctionne sur CPU, GPU NVIDIA, GPU AMD et Apple Silicon — souvent à partir du même binaire. Cette flexibilité s’accompagne d’une longue liste de drapeaux, et les valeurs par défaut ne sont pas toujours optimales pour votre matériel. Ce guide couvre les drapeaux les plus importants et les compromis derrière chacun.
Dernière vérification : 2026-10-14 — llama.cpp build b11609.
Tous les drapeaux de ce guide s’appliquent à llama-server et llama-cli à partir du build llama.cpp b11609 (14 octobre 2026). Les noms de drapeaux peuvent changer entre les builds — exécutez llama-server --help pour confirmer ce que votre binaire prend en charge.

​
Flash attention

Activez la flash attention avec -fa ou --flash-attn on. Dans la plupart des benchmarks, c’est ce qui se rapproche le plus d’une amélioration de performance gratuite offerte par llama.cpp — vous obtenez une inférence plus rapide avec la même utilisation mémoire voire moins, pour un coût en qualité négligeable.
La flash attention retravaille la façon dont le modèle calcule les scores d’attention entre les tokens. Au lieu de matérialiser la matrice d’attention complète en mémoire, elle calcule l’attention par blocs en tuiles qui tiennent dans la SRAM rapide. Le résultat :
  • Utilisation mémoire réduite pour le cache KV — le gain le plus important à de longues longueurs de contexte.
  • Inférence plus rapide — surtout sur GPU, où le calcul en tuiles correspond bien aux tensor cores.
  • Même qualité de sortie — la flash attention est mathématiquement équivalente à l’attention standard, pas une approximation.
Commencez toujours par -fa. Il n’y a aucune raison de le laisser désactivé sauf si vous rencontrez un problème de compatibilité avec un modèle ou une plateforme spécifique. C’est le drapeau à l’impact le plus élevé dans ce guide.

​
mmap vs mlock

llama.cpp charge les poids du modèle en mémoire en utilisant l’une des 2 stratégies. Par défaut, c’est --mmap, qui mappe le fichier modèle directement dans l’espace d’adresses virtuelles du processus. L’alternative est --mlock, qui épingle l’intégralité du modèle dans la RAM physique.

​
Quand mmap l’emporte

--mmap est la valeur par défaut car il fonctionne bien pour la plupart des usages interactifs. L’OS charge les pages du modèle à la demande, donc le démarrage est rapide et le fichier modèle ne double-compte pas dans votre RAM jusqu’à ce que les pages soient effectivement touchées. Si vous testez des modèles ou exécutez des sessions courtes, la valeur par défaut convient.

​
Quand mlock l’emporte

--mlock empêche l’OS d’évincer les pages du modèle vers le swap. Cela importe quand :
  • Vous exécutez le même modèle toute la journée et voulez une latence constante — pas de pénalité de démarrage à froid due aux défauts de page.
  • Votre système est sous pression mémoire d’autres processus et pourrait paginer les poids du modèle.
  • Vous êtes sur une machine avec un swap lent (ou sans swap) et un défaut de page bloquerait l’inférence pendant des secondes.
--mlock nécessite que l’intégralité du modèle tienne dans la RAM physique disponible. S’il ne tient pas, le processus ne démarre pas. Vérifiez votre mémoire disponible avec free -h sur Linux ou le Moniteur d’activité sur macOS avant de l’activer.

​
Réglage des threads

Le drapeau -t définit le nombre de threads CPU utilisés pour l’inférence. La bonne valeur dépend de la quantité de travail que le CPU effectue réellement.
Plus de threads n’est pas toujours plus rapide. Au-delà du nombre de cœurs physiques, les threads se disputent le cache et la bande passante mémoire et peuvent ralentir l’inférence. En cas de doute, commencez par le nombre de cœurs physiques et benchmarkez à partir de là.
Sur Apple Silicon, le réglage des threads importe moins car le GPU et le CPU partagent la mémoire unifiée et le backend Metal gère la planification. La valeur par défaut fonctionne généralement bien.

​
Stratégie de déchargement GPU

Le drapeau -ngl contrôle le nombre de couches du modèle que vous déchargez sur le GPU. Plus de couches sur le GPU signifie une inférence plus rapide, mais chaque couche consomme de la VRAM.

​
Déchargement partiel

Définissez -ngl au nombre de couches que vous pouvez faire tenir en mémoire GPU. Les couches restantes s’exécutent sur le CPU.
Utilisez le déchargement partiel quand le modèle complet ne tient pas dans la VRAM. Commencez par une valeur élevée et réduisez jusqu’à ce que le serveur démarre sans épuiser la mémoire.

​
Déchargement complet

Définissez -ngl 999 pour décharger toutes les couches. llama.cpp utilise 999 comme « toutes les couches restantes » — il n’essaie pas littéralement de décharger 999 couches.
Le déchargement complet donne la meilleure vitesse d’inférence car chaque passe avant s’exécute sur le GPU. Les poids du modèle et le cache KV doivent tous deux tenir en VRAM.

​
Budget mémoire par couche

Chaque couche déchargée consomme de la VRAM pour les poids et le cache KV. Une estimation approximative :
Pour un modèle 7B en Q4_K_M (~4.5 bits par poids, ~40 couches) : Laissez 1 à 2 GB de marge VRAM pour le contexte CUDA et la surcharge.

​
Réglage de la taille de lot

Deux drapeaux contrôlent le nombre de tokens que llama.cpp traite à la fois pendant la phase de pré-remplissage :

​
Comment ils interagissent

  • -b définit la limite extérieure. Si un prompt a plus de tokens que -b, llama.cpp le divise en plusieurs lots.
  • -ub définit la taille de morceau intérieure. llama.cpp traite le lot en micro-lots d’un maximum de -ub tokens.
  • -ub doit être inférieur ou égal à -b.

​
Compromis

Pour le chat interactif avec des prompts courts (moins de 1K tokens), la valeur par défaut -b 512 convient. Augmentez-la seulement si vous ingérez régulièrement de longs documents et voulez un temps jusqu’au premier token plus rapide.

​
Précision du cache KV

Le cache KV stocke les tenseurs de clés et de valeurs pour chaque token dans chaque séquence active. Par défaut, llama.cpp utilise f16 (virgule flottante 16 bits) pour les clés et les valeurs. Vous pouvez passer à une précision quantifiée pour réduire l’utilisation mémoire avec un léger coût en qualité.
Vous pouvez définir les clés et les valeurs indépendamment. Un schéma courant est q8_0 pour les deux, ce qui divise par deux l’empreinte du cache KV avec moins de 1% de différence de qualité sur la plupart des benchmarks.
q4_0 dans le cache KV introduit une perte de qualité mesurable sur les tâches qui reposent sur une attention précise sur un contexte long — récupération needle-in-a-haystack, résumé multi-documents et longues conversations. Testez votre charge de travail spécifique avant de vous engager sur q4_0.

​
Optimisation MoE

Les modèles mixture-of-experts comme Qwen3.5-35B-A3B ou Mixtral stockent un grand nombre de sous-réseaux d’experts dans chaque couche, mais n’en activent que quelques-uns par token. Les poids des experts restent en mémoire même lorsqu’ils sont inactifs, ce qui rend les modèles MoE disproportionnément grands par rapport à leur nombre de paramètres actifs. Sur les systèmes multi-GPU, vous pouvez placer les couches d’experts sur le CPU quand la mémoire GPU est limitée :
--n-cpu-moe <num> garde le nombre spécifié de sous-couches d’experts sur le CPU tandis que le reste du modèle s’exécute sur GPU. Cela échange une légère augmentation de latence contre la possibilité de faire tenir un modèle plus grand en VRAM.
Commencez avec --n-cpu-moe 0 (tous les experts sur GPU) et augmentez seulement lorsque vous manquez de VRAM. Chaque expert déplacé vers le CPU ajoute de la latence car les données doivent traverser le bus PCIe pendant la passe avant.

​
Configurations exemples

​
Apple Silicon — optimisé pour les Mac série M

Cela épingle le modèle dans la mémoire unifiée, active la flash attention et quantifie le cache KV pour optimiser votre budget mémoire. La mémoire unifiée d’Apple Silicon signifie que le GPU peut accéder à l’ensemble du pool de RAM, donc le déchargement complet (-ngl 999) fonctionne tant que le modèle et le cache KV tiennent.
llama.cpp fonctionne bien sur Apple Silicon, mais si vous déployez exclusivement sur Mac, MLX est optimisé pour le backend Metal d’Apple et peut offrir une inférence plus rapide pour le même modèle. Utilisez llama.cpp quand vous avez besoin de portabilité multiplateforme ou d’un serveur compatible OpenAI.

​
Déchargement GPU — GPU discret NVIDIA ou AMD

Déchargement GPU complet avec flash attention et cache KV quantifié. Les 4 threads CPU gèrent l’orchestration et la tokenisation. Réduisez -ngl si le modèle ne tient pas — commencez au nombre total de couches et diminuez de 5 jusqu’à ce qu’il charge.

​
CPU uniquement — pas de GPU disponible

Pas de déchargement GPU, donc le CPU fait tout le travail. Le nombre de threads correspond aux cœurs physiques. La taille de lot plus petite maintient l’utilisation mémoire gérable. Utilisez une quantification Q4_K_M ou Q5_K_M pour les poids du modèle afin de garder l’empreinte réduite.

​
Prochaines étapes

Accès à distance llama.cpp

Exposez votre serveur llama.cpp à vos coéquipiers et agents via Tokios — sans ouvrir de ports.

Décodage spéculatif

Accélérez le décodage avec des modèles brouillon, des n-grammes et EAGLE — fonctionne avec les backends llama.cpp.

Testez votre déploiement

Mesurez la latence et le débit après le réglage pour confirmer l’amélioration.

Cache KV et contexte

Explication plus approfondie du fonctionnement du cache KV à travers les architectures de modèles et les environnements d’exécution.