Llama.cpp

Prérequis

• Un GPU est recommandé, idéalement NVIDIA avec le plus de VRAM possible. Contrairement à Ollama ou vLLM, llama.cpp permet cependant de répartir le modèle entre GPU et CPU si la VRAM est insuffisante, au prix d’une baisse de performances. Voir ce lien pour partager un GPU dans un LXC
• Les modèles peuvent fonctionner sur CPU uniquement, mais avec des performances très faibles (souvent inutilisables en pratique pour un usage interactif).
• VRAM recommandée : dépend du niveau d’offload GPU. Pour un usage optimal, prévoir environ la taille du modèle (en Q4) + 1 à 3 Go pour le KV cache. Il est toutefois possible de réduire la VRAM nécessaire en déportant une partie du modèle en RAM.
• RAM recommandée : au minimum équivalente à la taille du modèle, idéalement 1,5 à 2 fois, notamment si une partie du modèle est exécutée sur CPU.
• Espace disque à prévoir en fonction du ou des modèle que vous allez utiliser ou tester, Exemples :
  • qwen2.5:7b (Q4) ≈ 4–5 Go
  • qwen2.5:14b (Q4) ≈ 8–10 Go
  • llama3:70b (Q4) ≈ 35–40 Go
• Utiliser un SSD/NVMe améliore fortement les temps de chargement.
• CPU / vCPU recommandés :
  • Avec GPU : 4 à 8 vCPU recommandés (gestion du KV cache et offload partiel CPU)
  • Sans GPU : prévoir au minimum 8 à 16 vCPU, les performances restant très limitées.
• Note : Q4 correspond au niveau de "quantization", c’est-à-dire une réduction de la précision numérique du modèle afin de diminuer son utilisation en mémoire (VRAM). Les niveaux vont généralement de Q1 à Q8 : Q8 est le plus précis (proche du modèle original), mais aussi le plus gourmand en ressources. À l’inverse, Q1 est très léger mais fortement dégradé. En pratique, Q4 (voire Q5) est généralement considéré comme le meilleur compromis entre performances, consommation de VRAM et qualité de réponse.

Installation

Prérequis système

Installer les dépendances nécessaires :

# apt update && apt upgrade
# apt install -y git build-essential cmake curl libcurl4-openssl-dev ccache

Récupération du projet

# cd /opt
# git clone https://github.com/ggerganov/llama.cpp.git

Compilation

Choisir une seule méthode de compilation selon le matériel disponible.

Méthode	Description	Recommandation
CPU uniquement	Compilation sans accélération GPU.	Non testé / déconseillé pour de gros modèles.
GPU NVIDIA CUDA	Compilation avec accélération GPU via CUDA.	Recommandé avec une carte NVIDIA compatible.

En cas de changement de méthode de compilation, supprimer le dossier de compilation avant de relancer CMake :

# rm -rf /opt/llama.cpp/build

Option A — CPU uniquement
Cette méthode ne nécessite pas de GPU compatible, mais les performances seront limitées. # cd /opt/llama.cpp # cmake -B build # cmake --build build -j$(nproc)

Option B — GPU NVIDIA CUDA

Cette méthode est recommandée avec une carte NVIDIA compatible CUDA. Installation du support GPU NVIDIA CUDA (Optionnel) Vérifier la dernière version disponible du paquet cuda-keyring : # curl https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/ | grep keyring Installer le dépôt CUDA NVIDIA : # cd /opt # wget https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-keyring_1.1-1_all.deb # dpkg -i cuda-keyring_1.1-1_all.deb # apt update Installer le toolkit CUDA : # apt install -y cuda-toolkit Compilation avec support CUDA Quelques dépendances : # apt install libnccl2 libnccl-dev Connaître les versions de nvcc installées : # find /usr /opt -name nvcc 2>/dev/null Compiler llama.cpp avec le support CUDA : # cd /opt/llama.cpp # export CUDACXX=/usr/local/cuda-13.2/bin/nvcc # cmake -B build -DGGML_CUDA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON -DCMAKE_BUILD_TYPE=Release -DGGML_NATIVE=ON -DLLAMA_OPENSSL=ON -DGGML_LTO=ON # cmake --build build -j$(nproc)

Emplacement des binaires

Les binaires seront disponibles dans :

/opt/llama.cpp/build/bin/

Téléchargement d’un modèle (format GGUF)

Voir Client Hugging Face

Mode serveur (API compatible OpenAI)

# /opt/llama.cpp/build/bin/llama-server \
  -m /opt/llama.cpp/models/models--HauhauCS--Qwen3.5-9B-Uncensored-HauhauCS-Aggressive/snapshots/1234567890abcdef1234567890abcdef12345678/Qwen3.5-9B-Uncensored-HauhauCS-Aggressive-Q4_K_M.gguf \
  -c 2048 \
  -ngl 35 \
  --host 0.0.0.0 \
  --port 8080

0.0.0.0 pour autoriser toutes les interfaces réseau.

Le dossier snapshots/<hash> dépend du téléchargement Hugging Face et varie selon les versions. Il est recommandé de créer un lien symbolique vers le fichier .gguf pour simplifier son utilisation.

Le serveur est accessible via :

http://IP:8080

Test API

# curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local",
    "messages": [
      {"role": "user", "content": "Bonjour"}
    ]
  }'

API key

Pour activer une authentification par clé API, ajouter le paramètre --api-key ou --api-key-file :

--api-key masuperclef

ou :

--api-key-file /dossier/clef.txt

Le fichier contenant la clé API doit être stocké dans un emplacement non accessible aux autres utilisateurs, par exemple dans /root/ si le service tourne en root.

Exemple :

# chmod 600 /root/llama-api-key.txt

SSL

Pour que la clé API ne transite pas en clair sur le réseau, il convient d'utiliser HTTPS.

Certains services, comme Hermes, refusent les certificats auto-signés. Il faut alors utiliser soit un certificat émis par une autorité reconnue, soit une CA privée dont le certificat public a été installé sur les machines clientes.

Pour une utilisation avec Hermes, voir Utiliser une CA privée avec Hermes.

---

Avec certificat auto-signé (déconseillé)

Créer un dossier de configuration : # mkdir -p /etc/llama-server # chmod 700 /etc/llama-server Installer les outils nécessaires : # apt update && apt upgrade # apt install openssl curl Créer le fichier contenant l’API key si nécessaire : # vi /etc/llama-server/api-keys.txt masuperclef # chmod 600 /etc/llama-server/api-keys.txt Générer les fichiers SSL nécessaires : # openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \ -keyout /etc/llama-server/server.key \ -out /etc/llama-server/server.crt \ -subj "/CN=IP_SERVEUR" \ -addext "subjectAltName = IP:IP_SERVEUR" Sécuriser les fichiers : # chmod 600 /etc/llama-server/server.key # chmod 644 /etc/llama-server/server.crt

---

• Ajouter à la configuration de llama.cpp :

...
 --port 8080 \
 --api-key-file /etc/llama-server/api-keys.txt \
 --ssl-key-file /etc/llama-server/server.key \
 --ssl-cert-file /etc/llama-server/server.crt
...

Optimisation (KV cache, performances, latence)

• Le paramètre de contexte (-c) influence directement la quantité de mémoire utilisée par le KV cache. Plus il est élevé, plus la consommation de VRAM augmente, ainsi que la latence de traitement du prompt.
• En pratique, une valeur de 2048 constitue souvent un bon compromis sur un GPU de 12 Go. Augmenter à 4096 peut améliorer la mémoire conversationnelle, mais au prix d’une consommation de VRAM plus importante.
• Le paramètre -ngl détermine le nombre de couches envoyées au GPU.
  • Plus la valeur est élevée, plus les performances augmentent.
  • Si la VRAM est insuffisante, réduire cette valeur permet de déporter une partie du modèle sur CPU.
  • Il est possible d’utiliser -ngl 999 afin de laisser llama.cpp charger automatiquement le maximum de couches possible sur le GPU.
• Le paramètre -fa active Flash Attention.
  • Cette option améliore généralement les performances de traitement du prompt et réduit légèrement la latence.
  • Elle est recommandée sur GPU NVIDIA récents.
• Le paramètre -b (batch size) influence la vitesse de traitement du prompt.
  • Une valeur plus élevée peut améliorer les performances, mais augmente également la consommation de mémoire.
  • En cas de manque de VRAM, réduire cette valeur peut stabiliser le serveur.
• Le paramètre -ub (micro-batch size) permet d’ajuster plus finement l’utilisation mémoire.
  • Une valeur plus faible réduit les pics de consommation mémoire.
  • Une valeur plus élevée peut améliorer légèrement les performances si la VRAM le permet.
• Le paramètre -np (n_parallel) détermine le nombre de requêtes pouvant être traitées en parallèle.
  • Une valeur élevée augmente la consommation de VRAM.
  • Pour un usage personnel ou mono-utilisateur, -np 1 est généralement recommandé.
  • Des valeurs supérieures sont surtout utiles pour une API ou un usage multi-utilisateurs.

• Pour les modèles multimodaux / vision, le fichier mmproj sert à projeter les données image vers le modèle texte.
  • Par défaut, les versions récentes de llama.cpp peuvent décharger ce projecteur multimodal sur le GPU.
  • Cela améliore généralement la vitesse d’analyse des images, mais consomme un peu plus de VRAM.
  • Si la VRAM est limitée, il est possible de forcer le mmproj à rester sur CPU avec :

# --no-mmproj-offload

• • Exemple :

# /opt/llama.cpp/build/bin/llama-server \
    -m /models/modele-vision.gguf \
    --mmproj /models/mmproj.gguf \
    --no-mmproj-offload \
    -ngl 999

• • Si aucune option --mmproj n’est utilisée, --no-mmproj-offload n’a pas d’intérêt.
  • En pratique :
    • VRAM suffisante : laisser le comportement par défaut, avec le mmproj sur GPU.
    • VRAM limitée : tester --no-mmproj-offload pour économiser de la VRAM, au prix d’une analyse d’image potentiellement plus lente.

Exemple de configuration optimisée pour un GPU de 12 Go :

# /opt/llama.cpp/build/bin/llama-server \
  -m /opt/llama.cpp/models/models--HauhauCS--Qwen3.5-9B-Uncensored-HauhauCS-Aggressive/snapshots/1234567890abcdef1234567890abcdef12345678/Qwen3.5-9B-Uncensored-HauhauCS-Aggressive-Q4_K_M.gguf \
  -c 2048 \
  -ngl 999 \
  -fa on \
  -b 1024 \
  -ub 512 \
  -np 1 \
  --host 0.0.0.0 \
  --port 8080

Explication :

-c    : taille du contexte
-ngl  : nombre de couches envoyées au GPU
-fa   : active Flash Attention
-b    : taille du batch de traitement
-ub   : taille du micro-batch
-np   : nombre de requêtes traitées en parallèle

• Si le serveur démarre correctement et qu’il reste de la marge en VRAM, il est possible d’augmenter progressivement -b ou le contexte.
• En cas d’erreur mémoire ou de performances instables :
  • réduire -b
  • réduire -ngl
  • réduire -c

Méthode d’ajustement recommandée

• Commencer avec :
  • -c 2048
  • -ngl 999
  • -fa on
  • -b 512
  • -ub 256
  • -np 1
• Vérifier ensuite l’utilisation mémoire :

# nvidia-smi

• Si la VRAM est presque saturée :
  • réduire -b
  • puis -ub
  • puis réduire -ngl si nécessaire
• Si au contraire une marge importante reste disponible :
  • essayer -b 1024
  • ou augmenter légèrement le contexte

Remarques

• Contrairement à Ollama, llama.cpp ne décharge pas automatiquement le modèle après inactivité lorsque le serveur reste lancé.
• Le meilleur réglage dépend du modèle utilisé, du niveau de quantization, du contexte choisi et de la quantité de VRAM disponible.
• Sur un petit GPU, il est généralement préférable de privilégier un contexte raisonnable et un nombre limité de requêtes parallèles.

Multi-GPU

llama.cpp peut utiliser plusieurs GPU afin de répartir le chargement du modèle lorsque celui-ci ne tient pas entièrement sur une seule carte graphique.

L'intérêt principal du multi-GPU avec llama.cpp est souvent de pouvoir charger un modèle plus gros en VRAM, plutôt que d'obtenir un gain de vitesse parfaitement linéaire.

Vérifier les GPU disponibles

Vérifier que les cartes NVIDIA sont bien visibles :

# nvidia-smi

Avec llama.cpp compilé avec CUDA, les GPU disponibles sont normalement détectés au lancement.

Options principales

Option	Description
-ngl ou --gpu-layers	Nombre de couches du modèle à envoyer sur GPU.
--split-mode	Méthode de répartition du modèle entre plusieurs GPU.
--tensor-split	Répartition manuelle de la charge entre les GPU.
--main-gpu	GPU principal utilisé notamment pour certaines allocations et opérations.

Split mode

Le paramètre --split-mode contrôle la façon dont llama.cpp répartit le modèle entre plusieurs GPU.

Mode	Description	Usage conseillé
none	Pas de répartition multi-GPU.	À utiliser si un seul GPU doit être utilisé.
layer	Répartit les couches du modèle entre les GPU.	Mode classique et généralement le plus simple.
row	Répartit certains tenseurs entre les GPU.	Plus spécifique, à tester selon le modèle et le matériel.

En pratique, le mode layer est souvent le plus simple pour commencer.

Exemple simple avec deux GPU

Lancer un serveur llama.cpp en utilisant plusieurs GPU :

# /opt/llama.cpp/build/bin/llama-server \
    -m /models/modele.gguf \
    -ngl 999 \
    --split-mode layer

Avec -ngl 999, llama.cpp tente de charger le maximum de couches possible sur les GPU.

Répartition manuelle avec tensor-split

Par défaut, llama.cpp peut répartir les couches de manière automatique. En cas de GPU avec des quantités de VRAM différentes, ou si une carte tombe en OOM, il peut être nécessaire d'utiliser --tensor-split.

Exemple avec deux GPU de 12 Go :

# /opt/llama.cpp/build/bin/llama-server \
    -m /models/modele.gguf \
    -ngl 999 \
    --split-mode layer \
    --tensor-split 12,12

Exemple avec un GPU de 24 Go et un GPU de 12 Go :

# /opt/llama.cpp/build/bin/llama-server \
    -m /models/modele.gguf \
    -ngl 999 \
    --split-mode layer \
    --tensor-split 24,12

Les valeurs de --tensor-split sont des proportions. Il n'est pas obligatoire d'indiquer exactement la VRAM en Go, mais c'est une méthode simple pour garder une répartition logique.

Ainsi, ces deux exemples sont équivalents dans l'idée :

# --tensor-split 24,12

# --tensor-split 2,1

Choisir le GPU principal

Le paramètre --main-gpu permet de choisir le GPU principal.

Exemple avec le GPU 0 comme carte principale :

# /opt/llama.cpp/build/bin/llama-server \
    -m /models/modele.gguf \
    -ngl 999 \
    --split-mode layer \
    --tensor-split 12,12 \
    --main-gpu 0

Si le GPU 0 est déjà utilisé par l'affichage ou par un autre service, il peut être utile de choisir un autre GPU principal.

Sélectionner les GPU visibles

Pour limiter llama.cpp à certaines cartes NVIDIA, il est possible d'utiliser CUDA_VISIBLE_DEVICES.

Exemple pour n'utiliser que les GPU 1 et 2 :

# CUDA_VISIBLE_DEVICES=1,2 /opt/llama.cpp/build/bin/llama-server \
    -m /models/modele.gguf \
    -ngl 999 \
    --split-mode layer \
    --tensor-split 12,12

Dans ce cas, les GPU visibles par llama.cpp seront renumérotés à partir de 0.

Ainsi, avec :

# CUDA_VISIBLE_DEVICES=1,2

le GPU physique 1 devient le GPU 0 pour llama.cpp, et le GPU physique 2 devient le GPU 1.

Exemple avec trois GPU

Exemple avec trois RTX 3060 12 Go :

# /opt/llama.cpp/build/bin/llama-server \
    -m /models/modele.gguf \
    -ngl 999 \
    --split-mode layer \
    --tensor-split 12,12,12 \
    --main-gpu 0

Exemple avec une RTX 3090 24 Go et deux RTX 3060 12 Go :

# /opt/llama.cpp/build/bin/llama-server \
    -m /models/modele.gguf \
    -ngl 999 \
    --split-mode layer \
    --tensor-split 24,12,12 \
    --main-gpu 0

Vérifier l'utilisation mémoire

Pendant le lancement et l'inférence, surveiller la VRAM :

# watch -n 1 nvidia-smi

Si une carte arrive en manque de mémoire, il faut réduire la charge :

• diminuer -c ;
• diminuer -b ;
• diminuer -ub ;
• ajuster --tensor-split ;
• réduire -ngl ;
• utiliser un quant plus léger.

Performances attendues

Le multi-GPU dans llama.cpp ne donne pas toujours une accélération proportionnelle au nombre de GPU.

En pratique :

• si le modèle tient déjà entièrement sur un seul GPU, ajouter un second GPU peut parfois ne pas améliorer les performances ;
• si le modèle ne tient pas sur un seul GPU, le multi-GPU peut permettre d'éviter l'offload CPU, ce qui améliore fortement les performances ;
• les performances dépendent beaucoup du PCIe, du modèle, du quant, du contexte et du mode de split ;
• deux GPU identiques sont plus simples à exploiter que deux GPU très différents.

Résumé pratique

Pour commencer avec deux GPU identiques :

# /opt/llama.cpp/build/bin/llama-server \
    -m /models/modele.gguf \
    -ngl 999 \
    --split-mode layer \
    --tensor-split 12,12 \
    -c 4096 \
    -fa

Pour un usage personnel, il est conseillé de garder :

# -np 1

afin d'éviter une consommation mémoire inutilement élevée.

Service systemd

Création d'un service pour automatiser le lancement du serveur llama.cpp, tout d'abord créer un lien propre vers le modèle si nécessaire :

# ln -s /opt/llama.cpp/models/models--HauhauCS--Qwen3.5-9B-Uncensored-HauhauCS-Aggressive/snapshots/1234567890abcdef1234567890abcdef12345678/Qwen3.5-9B-Uncensored-HauhauCS-Aggressive-Q4_K_M.gguf /opt/llama.cpp/models/qwen35-9b-uncensored-q4km.gguf

Créer le service :

# vi /etc/systemd/system/llama-server.service

[Unit]
Description=llama.cpp server
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp
ExecStart=/opt/llama.cpp/build/bin/llama-server -m /opt/llama.cpp/models/qwen35-9b-uncensored-q4km.gguf -c 2048 -ngl 999 -fa on -b 1024 -ub 512 -np 1 --host 0.0.0.0 --port 8080
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

# systemctl daemon-reload
# systemctl enable llama-server
# systemctl start llama-server

Proxy OpenClaw

Source

Il est possible d'utiliser un proxy Python afin de contourner certaines incompatibilités (rôles, outils, gestion du « thinking ») entre OpenClaw et llama.cpp.

Cependant, pour un usage stable, il est recommandé d’utiliser un backend nativement compatible tel que Ollama (usage personnel) ou vLLM (usage avancé / multi-utilisateurs).

Mise à jour

Pour mettre à jour llama.cpp vers la dernière version disponible :

# cd /opt/llama.cpp
# git pull

Après une mise à jour, il est recommandé de supprimer l’ancien dossier de compilation puis de recompiler :

# rm -rf build

Recompiler ensuite avec la même méthode que lors de l’installation initiale.

Recompilation CPU uniquement

# cmake -B build
# cmake --build build -j$(nproc)

Recompilation GPU NVIDIA CUDA

# export CUDACXX=/usr/local/cuda-13.2/bin/nvcc
# cmake -B build -DGGML_CUDA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON -DCMAKE_BUILD_TYPE=Release -DGGML_NATIVE=ON -DLLAMA_OPENSSL=ON -DGGML_LTO=ON
# cmake --build build -j$(nproc)

Llama bench

• Commande de base :

# /opt/llama.cpp/build/bin/llama-bench

Exemple de test de stabilité avec MoE

On récupère la commande réellement exécutée par llama (le service doit être actif) :

# tr '\0' ' ' < /proc/$(pidof llama-server)/cmdline

Résultat :

/opt/llama.cpp/build/bin/llama-server -m /opt/llama.cpp/models/Qwen3.6-35B-A3B-APEX-I-Balanced.gguf --mmproj /opt/llama.cpp/models/mmproj-F16.gguf -ngl 999 -t 8 -tb 16 -b 4096 -ub 4096 -c 131072 --cache-ram 2048 -np 1 --kv-unified -fa on --no-mmproj-offload --no-mmap -ncmoe 35 -ctk q8_0 -ctv q8_0 --reasoning on --jinja --chat-template-kwargs {"preserve_thinking": true} --reasoning-budget 8096 --reasoning-budget-message D'accord, assez réfléchi, plus d'attente. Passons à l'action. --temp 0.6 --top-k 20 --top-p 0.95 --min-p 0.0 --presence-penalty 0.0 --repeat-penalty 1.0 --swa-full --cache-reuse 512 --host IP_SERVEUR --port 8080 --api-key-file /etc/llama-server/api-keys.txt --ssl-key-file /etc/llama-server/server.key --ssl-cert-file /etc/llama-server/server.crt

On peut entre autre voir les deux valeurs en rouge, à savoir la taille du context : 131072 et le nombre d'experts automatiquement déchargé en RAM : 35, on commence par arrêter le service :

# systemctl stop llama-server

Puis on lance le test :

 # /opt/llama.cpp/build/bin/llama-bench \
  -m "/opt/llama.cpp/models/Qwen3.6-35B-A3B-APEX-I-Balanced.gguf" \
  -ngl 999 \
  -t 8 \
  -b 4096 \
  -ub 4096 \
  -fa 1 \
  -mmp 0 \
  -ncmoe 35 \
  -ctk q8_0 \
  -ctv q8_0 \
  -p 1000 \
  -n 128 \
  -d 0,16000,32000,64000,96000,120000 \
  -r 3

Le dernier test utilisera environ :

120000 + 1000 + 128 = 121128 tokens

Cela reste proche de la limite configurée de 131072 tokens, avec une marge d'environ 9944 tokens. Si ce test ne plante pas et que les performances restent cohérentes, la configuration devrait tenir en mémoire et être raisonnablement stable avec ce niveau de contexte.

Information commande de test :

• /opt/llama.cpp/build/bin/llama-bench : lance l’outil de benchmark de llama.cpp.
• -m "/opt/llama.cpp/models/Qwen3.6-35B-A3B-APEX-I-Balanced.gguf" : indique le modèle GGUF à tester.
• -ngl 999 : demande à envoyer un maximum de couches sur le GPU.
• -t 8 : utilise 8 threads CPU.
• -b 4096 : définit la taille de batch utilisée pour le traitement du prompt.
• -ub 4096 : définit la taille du micro-batch, pour limiter la consommation mémoire.
• -fa 1 : active Flash Attention.
• -ncmoe 35 : valeurs de --n-cpu-moe ( pour tester plusieurs valeurs, exemple : -ncmoe 24,26,28,31)
• -ctk q8_0 : définit le type de quantification du cache KV pour les clés (K, pour Key). Ici, q8_0 réduit la mémoire nécessaire par rapport au cache par défaut en f16, tout en restant relativement conservateur sur la qualité.
• -ctv q8_0 : définit le type de quantification du cache KV pour les valeurs (V, pour Value). Comme pour -ctk, q8_0 permet de réduire fortement la consommation mémoire du contexte, ce qui aide à atteindre de grands contextes comme 64k ou 128k.
• -p 1000 : utilise un prompt de test de 1000 tokens. Dans les résultats, cela correspond à pp1000.
• -n 128 : génère 128 tokens. Dans les résultats, cela correspond à tg128.
• -d 0,16000,32000,64000,96000,120000 : teste plusieurs profondeurs de contexte, de 0 à 32000 tokens déjà présents dans le contexte.
• -r 3 : répète chaque test 3 fois afin d’obtenir une mesure plus stable.

---

Information tableau des résultats :

• pp : vitesse de traitement du prompt, importante quand le contexte est long.
• tg : vitesse de génération des nouveaux tokens, généralement la valeur la plus importante pour la fluidité de réponse.
• d0 : contexte vide, équivalent à un nouveau chat.
• d16000 : contexte déjà chargé, proche d’un usage agent ou assistant avec historique important.
• pp1000 @ d16000 : traitement d’un prompt de 1000 tokens avec 16000 tokens déjà présents dans le contexte.
• tg128 @ d16000 : génération de 128 tokens avec 16000 tokens déjà présents dans le contexte.

Benchmark multi-GPU

Tester les performances avec llama-bench :

# /opt/llama.cpp/build/bin/llama-bench \
    -m /models/modele.gguf \
    -ngl 999 \
    --split-mode layer \
    --tensor-split 12,12

Comparer avec un seul GPU :

# CUDA_VISIBLE_DEVICES=0 /opt/llama.cpp/build/bin/llama-bench \
    -m /models/modele.gguf \
    -ngl 999

Puis avec deux GPU :

# CUDA_VISIBLE_DEVICES=0,1 /opt/llama.cpp/build/bin/llama-bench \
    -m /models/modele.gguf \
    -ngl 999 \
    --split-mode layer \
    --tensor-split 12,12

Les résultats à comparer sont principalement :

pp : prompt processing
tg : token generation

Utilisation d'un LoRA

Installation des dépendances

# cd /opt/llama.cpp
# python3 -m venv .venv-convert
# source .venv-convert/bin/activate
# pip install -U pip
# pip install -e .

Conversion

# cd /opt/llama.cpp
# source .venv-convert/bin/activate
# python3 convert_lora_to_gguf.py --base-model-id tencent/Hy-MT2-1.8B --trust-remote-code --outtype f16 --outfile /opt/models/Hy-MT2-1.8B/mon_lora.gguf /opt/lora/mon_lora/

Exemple avec tencent/Hy-MT2-1.8B, identifiant Hugging Face.

Utilisation dans Llama.cpp

Ajouter simplement la ligne suivante :

--lora /opt/models/Hy-MT2-1.8B/mon_lora.gguf \

Exemple de configuration d’un modèle MoE avec déchargement des experts en RAM

Machine de test :

• LXC Debian 13
• 8 vCPU (E5-2667 v2)
• RTX 3060 12GB (PCIe 3.0 x8)
• DDR3-1866
  • À noter que la mémoire des experts déchargés en RAM est consommée sur l’hôte, et non comptabilisée dans le LXC, car elle transite via le pilote Nvidia.
  • Dans une VM ou sur une machine physique, prévoir au minimum la taille du modèle en RAM, avec idéalement 30 à 50 % de marge supplémentaire selon le contexte, le KV cache et les buffers.

Qwen3.6-35B-A3B-GGUF:UD-Q5_K_XL

# /opt/llama.cpp/build/bin/llama-cli -hf unsloth/Qwen3.6-35B-A3B-GGUF:UD-Q5_K_XL
# ln -s /opt/llama.cpp/models/models--unsloth--Qwen3.6-35B-A3B-GGUF/snapshots/1234567890abcdef1234567890abcdef12345678/Qwen3.6-35B-A3B-UD-Q5_K_XL.gguf /opt/llama.cpp/models/Qwen3.6-35B-A3B-UD-Q5_K_XL.gguf
# ln -s /opt/llama.cpp/models/models--unsloth--Qwen3.6-35B-A3B-GGUF/snapshots/1234567890abcdef1234567890abcdef12345678/mmproj-BF16.gguf /opt/llama.cpp/models/mmproj-F16.gguf

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/llama.cpp/models/Qwen3.6-35B-A3B-UD-Q5_K_XL.gguf \
  --mmproj /opt/llama.cpp/models/mmproj-F16.gguf \
  -ngl 999 \
  -t 8 \
  -tb 16 \
  -b 4096 \
  -ub 4096 \
  -c 131072 \
  --cache-ram 2048 \
  -np 1 \
  --kv-unified \
  -fa on \
  --no-mmproj-offload \
  --no-mmap \
  -ncmoe 35 \
  -ctk q8_0 \
  -ctv q8_0 \
  --reasoning on \
  --jinja \
  --chat-template-kwargs '{"preserve_thinking": true}' \
  --reasoning-budget 8096 \
  --reasoning-budget-message "D'accord, assez réfléchi, plus d'attente. Passons à l'action." \
  --temp 0.6 \
  --top-k 20 \
  --top-p 0.95 \
  --min-p 0.0 \
  --presence-penalty 0.0 \
  --repeat-penalty 1.0 \
  --swa-full \
  --cache-reuse 512 \
  --host 192.168.1.123 \
  --port 8080

• --mmproj : Charge le fichier projecteur multimodal. Il est utilisé pour les modèles capables de traiter des images ou d’autres entrées multimodales.

• -ngl : Nombre de couches à offloader sur le GPU. Une valeur très élevée comme 999 revient en pratique à dire « mets sur le GPU tout ce qui peut y être placé ».

• -t : Nombre de threads CPU utilisés pour l’inférence principale.

• -tb : Nombre de threads CPU utilisés pour le traitement par batch. Cela peut améliorer le débit de préremplissage du contexte.

• -b : Taille du batch logique. Plus elle est élevée, plus le traitement du prompt peut être rapide, mais cela augmente aussi les besoins en mémoire.

• -ub : Taille du micro-batch. C’est une sous-division du batch principal, utile pour ajuster plus finement l’équilibre entre débit et mémoire.

• -c : Taille du contexte actif utilisée par le serveur. Elle détermine combien de tokens peuvent être conservés en mémoire dans la fenêtre de contexte.

• --cache-ram : Taille maximale du cache en RAM, exprimée en MiB. Ce cache permet de conserver des états utiles pour éviter de tout recalculer inutilement.

• -np : Nombre de slots serveur. Avec 1, une seule requête est traitée activement à la fois.

• --kv-unified : Utilise un buffer KV unifié partagé entre les séquences. Cela peut améliorer la gestion du cache dans certains scénarios serveur.

• -fa : Active Flash Attention, ce qui améliore généralement les performances mémoire et la vitesse sur GPU compatibles.

• --no-mmproj-offload : Empêche l’offload du projecteur multimodal sur le GPU. Le mmproj reste alors côté CPU/RAM.

• --no-mmap : Désactive le memory mapping du fichier modèle. Le modèle est alors chargé plus directement en mémoire, ce qui peut parfois être préférable selon le stockage ou le comportement recherché.

• -ncmoe : Définit combien d’experts MoE sont forcés côté CPU/RAM. C’est un réglage particulièrement utile pour les modèles Mixture-of-Experts sur des GPU limités en VRAM.

• -ctk : Type de quantification du cache KV pour les clés. Ici q8_0 privilégie une bonne qualité tout en réduisant la pression mémoire.

• -ctv : Type de quantification du cache KV pour les valeurs. Même logique que pour -ctk.

• --reasoning : Active le mode de raisonnement pris en charge par le serveur pour les modèles/templates compatibles.

• --jinja : Active l’utilisation des chat templates Jinja, afin de formater correctement les messages pour les modèles qui en ont besoin.

• --chat-template-kwargs : Passe des paramètres supplémentaires au template de chat. Ici, {"preserve_thinking": true} demande au template de préserver la partie de raisonnement lorsqu’elle est supportée.

• --reasoning-budget : Définit le budget maximal de tokens alloués au raisonnement interne.

• --reasoning-budget-message : Message injecté lorsque le budget de raisonnement est atteint, afin d’inciter le modèle à conclure et passer à la réponse utile.

• --temp : Température d’échantillonnage. Plus elle est basse, plus la réponse est déterministe.

• --top-k : Limite l’échantillonnage aux K tokens les plus probables.

• --top-p : Active un échantillonnage nucleus en conservant uniquement la masse de probabilité cumulée visée.

• --min-p : Écarte les tokens dont la probabilité est trop faible.

• --presence-penalty : Pénalité de présence. Elle pousse le modèle à introduire de nouveaux tokens ou idées plutôt que de répéter ce qui a déjà été dit.

• --repeat-penalty : Pénalité de répétition. Elle réduit la probabilité de répéter les mêmes tokens.

• --swa-full : Active le mode SWA complet lorsqu’il est pris en charge par le modèle ou le backend.

• --cache-reuse : Définit un seuil de réutilisation du cache. Cela peut améliorer les performances sur des requêtes proches ou répétées.

Qwen3.6-35B-A3B-APEX-I-Balanced

# /opt/llama.cpp/build/bin/llama-cli --hf-repo mudler/Qwen3.6-35B-A3B-APEX-GGUF --hf-file Qwen3.6-35B-A3B-APEX-I-Balanced.gguf
# ln -s /opt/llama.cpp/models/models--mudler--Qwen3.6-35B-A3B-APEX-GGUF/snapshots/1234567890abcdef1234567890abcdef12345678/Qwen3.6-35B-A3B-APEX-I-Balanced.gguf /opt/llama.cpp/models/Qwen3.6-35B-A3B-APEX-I-Balanced.gguf
# ln -s /opt/llama.cpp/models/models--mudler--Qwen3.6-35B-A3B-APEX-GGUF/snapshots/1234567890abcdef1234567890abcdef12345678/mmproj.gguf /opt/llama.cpp/models/mmproj-F16.gguf

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/llama.cpp/models/Qwen3.6-35B-A3B-APEX-I-Balanced.gguf \
  --mmproj /opt/llama.cpp/models/mmproj-F16.gguf \
  -ngl 999 \
  -t 8 \
  -tb 16 \
  -b 4096 \
  -ub 4096 \
  -c 131072 \
  --cache-ram 2048 \
  -np 1 \
  --kv-unified \
  -fa on \
  --no-mmproj-offload \
  --no-mmap \
  -ncmoe 35 \
  -ctk q8_0 \
  -ctv q8_0 \
  --reasoning on \
  --jinja \
  --chat-template-kwargs '{"preserve_thinking": true}' \
  --reasoning-budget 8096 \
  --reasoning-budget-message "D'accord, assez réfléchi, plus d'attente. Passons à l'action." \
  --temp 0.6 \
  --top-k 20 \
  --top-p 0.95 \
  --min-p 0.0 \
  --presence-penalty 0.0 \
  --repeat-penalty 1.0 \
  --swa-full \
  --cache-reuse 512 \
  --host 192.168.1.123 \
  --port 8080

Exemple de configuration d’un modèle MTP + sm tensor

Qwen3.6-27B-UD-Q4_K_XL + kvcache Q8 Q8 (2x 12 Go de VRAM)

# hf download unsloth/Qwen3.6-27B-MTP-GGUF  --include Qwen3.6-27B-UD-Q4_K_XL.gguf --include "mmproj-BF16.gguf" --local-dir /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL

[Unit]
Description=llama.cpp Qwen3.6-27B MTP server
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL/Qwen3.6-27B-UD-Q4_K_XL.gguf \
  --mmproj /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL/mmproj-BF16.gguf \
  --no-mmproj-offload \
  --image-min-tokens 1024 \
  -ngl 999 \
  -sm tensor \
  -ts 1/1 \
  -t 4 \
  -tb 4 \
  -b 1024 \
  -ub 1024 \
  -c 98304 \
  -np 1 \
  -fa on \
  --load-mode none \
  -ctk q8_0 \
  -ctv q8_0 \
  --spec-type draft-mtp \
  --spec-draft-n-max 3 \
  --spec-draft-n-min 0 \
  --spec-draft-p-min 0.75 \
  --reasoning on \
  --reasoning-preserve \
  --jinja \
  --chat-template-file /opt/models/Qwen-Fixed-Chat-Templates/chat_template.jinja \
  --chat-template-kwargs '{"preserve_thinking": true}' \
  --reasoning-format none \
  --reasoning-budget 16192 \
  --reasoning-budget-message "D'accord, assez réfléchi, plus d'attente. Passons à l'action." \
  --slot-save-path /kv_cache/ \
  --temp 0.6 \
  --top-k 20 \
  --top-p 0.95 \
  --min-p 0.0 \
  --presence-penalty 0.0 \
  --repeat-penalty 1.0 \
  --host 0.0.0.0 \
  --port 8080 \
  --api-key-file /etc/ai/ssl/api-keys.txt \
  --ssl-key-file /etc/ai/ssl/server.key \
  --ssl-cert-file /etc/ai/ssl/server.crt

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Exemple de configuration d’un modèle MTP + sm tensor +ngram

Qwen3.6-27B-UD-Q4_K_XL + kvcache Q8 Q8 (2x 12 Go de VRAM)

# hf download unsloth/Qwen3.6-27B-MTP-GGUF  --include Qwen3.6-27B-UD-Q4_K_XL.gguf --include "mmproj-BF16.gguf" --local-dir /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL

[Unit]
Description=llama.cpp Qwen3.6-27B MTP server
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL/Qwen3.6-27B-UD-Q4_K_XL.gguf \
  --mmproj /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL/mmproj-BF16.gguf \
  --no-mmproj-offload \
  --image-min-tokens 1024 \
  -ngl 999 \
  -sm tensor \
  -ts 1/1 \
  -t 4 \
  -tb 4 \
  -b 1024 \
  -ub 1024 \
  -c 98304 \
  -np 1 \
  -fa on \
  --load-mode none \
  -ctk q8_0 \
  -ctv q8_0 \
  --spec-type ngram-mod,draft-mtp \
  --spec-ngram-mod-n-match 24 \
  --spec-ngram-mod-n-min 12 \
  --spec-ngram-mod-n-max 48 \
  --spec-draft-n-max 3 \
  --spec-draft-n-min 0 \
  --spec-draft-p-min 0.75 \
  --reasoning on \
  --reasoning-preserve \
  --jinja \
  --chat-template-file /opt/models/Qwen-Fixed-Chat-Templates/chat_template.jinja \
  --chat-template-kwargs '{"preserve_thinking": true}' \
  --reasoning-format none \
  --reasoning-budget 16192 \
  --reasoning-budget-message "D'accord, assez réfléchi, plus d'attente. Passons à l'action." \
  --slot-save-path /kv_cache/ \
  --temp 0.6 \
  --top-k 20 \
  --top-p 0.95 \
  --min-p 0.0 \
  --presence-penalty 0.0 \
  --repeat-penalty 1.0 \
  --host 0.0.0.0 \
  --port 8080 \
  --api-key-file /etc/ai/ssl/api-keys.txt \
  --ssl-key-file /etc/ai/ssl/server.key \
  --ssl-cert-file /etc/ai/ssl/server.crt

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

La combinaison ngram-mod,draft-mtp permet d'utiliser deux formes de génération spéculative complémentaires. Le MTP prédit quelques tokens à l'avance grâce aux têtes intégrées au modèle, tandis que ngram-mod recherche dans le contexte des séquences déjà rencontrées afin de proposer directement des blocs plus longs. Cela peut fortement accélérer les régénérations, les reprises de code, les structures répétitives ou les réponses proches d'un texte déjà présent, sans ajouter de second modèle de draft.

Les paramètres --spec-ngram-mod-n-match 24, --spec-ngram-mod-n-min 12 et --spec-ngram-mod-n-max 48 définissent respectivement la longueur minimale de correspondance recherchée, puis la taille minimale et maximale des blocs proposés. Avec ces valeurs, le mécanisme reste assez sélectif tout en pouvant accélérer nettement les passages répétitifs. Sur du contenu entièrement nouveau, le gain est généralement faible et le MTP reste le principal mécanisme spéculatif.

Modèles RAG

Embedding

microsoft/harrier-oss-v1-0.6b

# hf download SuperPauly/harrier-oss-v1-0.6b-gguf --include "*Q8_0*.gguf" --local-dir /opt/models/harrier-oss-v1-0.6b/Q8_0

# vi /etc/systemd/system/llama-embedding.service

[Unit]
Description=llama-server Embedding
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/harrier-oss-v1-0.6b/Q8_0/harrier-oss-v1-0.6B-Q8_0.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  --api-key masuperclef \
  --embedding \
  --pooling last \
  -c 4096 \
  -np 1 \
  -b 1024 \
  -ub 1024 \
  -ctk q8_0 \
  -ctv q8_0 \
  -ngl 999 \
  -t 4 \
  --sleep-idle-seconds 300

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

--sleep-idle-seconds 300 : décharge le modèle après 300 secondes d’inactivité.

-c 4096 : définit le contexte maximal accepté par le serveur, ici 4096 tokens. Cette valeur est recommandée pour un serveur d’embedding utilisé avec RAGFlow, car les documents sont normalement découpés en chunks plus petits, souvent autour de 1024 à 2048 tokens. Ce modèle peut monter jusqu’à 32768, au prix d’une consommation mémoire beaucoup plus élevée.

Pour les modèles d’embedding, les paramètres n_batch et n_ubatch doivent être configurés avec la même valeur. Par exemple : -b 1024 -ub 1024. Si n_batch est supérieur à n_ubatch, llama-server peut ramener automatiquement les deux valeurs à celle de n_ubatch afin d’éviter une erreur d’assertion.

Rerank

bge-reranker-v2-m3-Q8_0-GGUF

# hf download Felladrin/gguf-Q8_0-bge-reranker-v2-m3 --include "*q8_0*.gguf" --local-dir /opt/models/bge-reranker-v2-m3/Q8_0

# vi /etc/systemd/system/llama-rerank.service

[Unit]
Description=llama-server Rerank
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/bge-reranker-v2-m3/Q8_0/bge-reranker-v2-m3-q8_0.gguf \
  --host 0.0.0.0 \
  --port 8081 \
  --api-key masuperclef \
  --reranking \
  --pooling rank \
  -c 8192 \
  -np 1 \
  -b 4096 \
  -ub 4096 \
  -ctk q8_0 \
  -ctv q8_0 \
  -ngl 999 \
  -t 4 \
  --sleep-idle-seconds 300

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

--sleep-idle-seconds 300 : décharge le modèle après 300 secondes d’inactivité.

jinaai/jina-reranker-v3.5-GGUF

Jina Reranker 3.5 n'est pas encore pris en charge par la version officielle de llama.cpp. Ce modèle nécessite un mode encodeur non causal ainsi qu'une option spécifique --output-token-ids, actuellement absents de la branche officielle. Une pull request est ouverte pour ajouter cette prise en charge : ggml-org/llama.cpp#26286 En attendant son intégration, il faut utiliser le fork de littlewine/llama.cpp.

# hf download jinaai/jina-reranker-v3.5-GGUF --include "*Q8_0*.gguf" --local-dir /opt/models/jina-reranker-v3.5/Q8_0

# vi /etc/systemd/system/llama-rerank.service

[Unit]
Description=llama-server Rerank
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/jina-reranker-v3.5/Q8_0/jina-reranker-v3.5-Q8_0.gguf \
  --host 0.0.0.0 \
  --port 8081 \
  --api-key masuperclef \
  --reranking \
  --pooling rank \
  -c 16384 \
  -np 1 \
  -b 4096 \
  -ub 4096 \
  -ctk q8_0 \
  -ctv q8_0 \
  -ngl 999 \
  -t 4 \
  --sleep-idle-seconds 300

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

--sleep-idle-seconds 300 : décharge le modèle après 300 secondes d’inactivité.

-c 16384 : valeur confortable pour un serveur de rerank utilisé avec RAGFlow. Le modèle jina-reranker-v3.5 reçoit la requête utilisateur ainsi qu’une liste de chunks candidats à comparer, ce qui nécessite davantage de contexte qu’un modèle d’embedding traitant les chunks individuellement. Il prend théoriquement en charge jusqu’à 131072 tokens de contexte, mais une telle valeur augmente fortement la consommation de VRAM ou de RAM et n’est généralement pas utile pour un serveur local. Une fenêtre de 16384 tokens offre donc une marge importante pour les requêtes et les chunks habituellement envoyés par RAGFlow.

jinaai/jina-reranker-v3-GGUF

# hf download jinaai/jina-reranker-v3-GGUF --include "*Q8_0*.gguf" --local-dir /opt/models/jina-reranker-v3/Q8_0

# vi /etc/systemd/system/llama-rerank.service

[Unit]
Description=llama-server Rerank
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/jina-reranker-v3/Q8_0/jina-reranker-v3-Q8_0.gguf \
  --host 0.0.0.0 \
  --port 8081 \
  --api-key masuperclef \
  --reranking \
  --pooling cls \
  -c 16384 \
  -np 1 \
  -b 4096 \
  -ub 4096 \
  -ctk q8_0 \
  -ctv q8_0 \
  -ngl 999 \
  -t 4 \
  --sleep-idle-seconds 300

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

--sleep-idle-seconds 300 : décharge le modèle après 300 secondes d’inactivité.

-c 16384 : valeur confortable pour un serveur de rerank utilisé avec RAGFlow. Contrairement au modèle d’embedding, le reranker peut recevoir la requête utilisateur avec plusieurs chunks candidats à comparer, ce qui nécessite plus de contexte. Le modèle jina-reranker-v3 supporte théoriquement jusqu’à 131072 tokens, mais cette valeur consomme énormément de VRAM ou de RAM et n’est généralement pas nécessaire en local.

Img2txt

mradermacher/LightOnOCR-2-1B-GGUF

# hf download mradermacher/LightOnOCR-2-1B-GGUF --include "*Q8_0*.gguf" --include "*mmproj-f16*.gguf" --local-dir /opt/models/LightOnOCR-2-1B/Q8_0
# rm -f /opt/models/LightOnOCR-2-1B/Q8_0/LightOnOCR-2-1B.mmproj-Q8_0.gguf

# vi /etc/systemd/system/llama-img2txt.service

[Unit]
Description=llama-server Img2txt LightOnOCR-2-1B
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/LightOnOCR-2-1B/Q8_0/LightOnOCR-2-1B.Q8_0.gguf \
  --mmproj /opt/models/LightOnOCR-2-1B/Q8_0/LightOnOCR-2-1B.mmproj-f16.gguf \
  --host 0.0.0.0 \
  --port 8082 \
  --api-key masuperclef \
  -c 8192 \
  -np 1 \
  -ctk q8_0 \
  -ctv q8_0 \
  -ngl 999 \
  -t 4 \
  --sleep-idle-seconds 300

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

--sleep-idle-seconds 300 : décharge le modèle après 300 secondes d’inactivité.

-c 8192 : valeur recommandée pour un serveur Img2txt/OCR utilisé avec LightOnOCR-2-1B. Le modèle supporte jusqu’à 16384 tokens, mais 8192 offre déjà une marge confortable pour traiter une image ou une page scannée avec beaucoup de texte.

Modèles auxiliaires

Vision

Qwen3-VL-4B-Thinking (Dépôt officiel)

# hf download Qwen/Qwen3-VL-4B-Thinking-GGUF --include "*Q4_K_M*.gguf" --include "*mmproj-Qwen3VL-4B-Thinking-Q8_0*.gguf" --local-dir /opt/models/Qwen3-VL-4B-Thinking/Q4_K_M

[Unit]
Description=llama-server Vision
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/Qwen3-VL-4B-Thinking/Q4_K_M/Qwen3VL-4B-Thinking-Q4_K_M.gguf \
  --mmproj /opt/models/Qwen3-VL-4B-Thinking/Q4_K_M/mmproj-Qwen3VL-4B-Thinking-Q8_0.gguf \
  --host 0.0.0.0 \
  --port 8083 \
  --api-key masuperclef \
  -c 16384 \
  -np 1 \
  -ctk q8_0 \
  -ctv q8_0 \
  -ngl 999 \
  -t 4 \
  -b 1024 \
  -ub 512 \
  --flash-attn on \
  --jinja \
  --top-p 0.95 \
  --top-k 20 \
  --temp 1.0 \
  --min-p 0.0 \
  --presence-penalty 0.0 \
  --image-min-tokens 1024 \
  --image-max-tokens 4096 \
  --sleep-idle-seconds 300

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Qwen3-VL-4B-Instruct (Dépôt officiel)

# hf download Qwen/Qwen3-VL-4B-Instruct-GGUF --include "*Q4_K_M*.gguf" --include "*mmproj-Qwen3VL-4B-Instruct-Q8_0*.gguf" --local-dir /opt/models/Qwen3-VL-4B-Instruct/Q4_K_M

• Environ 5,25gb de vram consommée :

[Unit]
Description=llama-server Vision
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/Qwen3-VL-4B-Instruct/Q4_K_M/Qwen3VL-4B-Instruct-Q4_K_M.gguf \
  --mmproj /opt/models/Qwen3-VL-4B-Instruct/Q4_K_M/mmproj-Qwen3VL-4B-Instruct-Q8_0.gguf \
  --host 0.0.0.0 \
  --port 8083 \
  --api-key masuperclef \
  -c 16384 \
  -np 1 \
  -ctk q8_0 \
  -ctv q8_0 \
  -ngl 999 \
  -t 4 \
  -b 1024 \
  -ub 512 \
  --flash-attn on \
  --jinja \
  --top-p 0.8 \
  --top-k 20 \
  --temp 0.7 \
  --min-p 0.0 \
  --presence-penalty 1.5 \
  --image-min-tokens 1024 \
  --image-max-tokens 4096 \
  --sleep-idle-seconds 300

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Qwen3-VL-2B-Instruct (Dépôt officiel)

# hf download Qwen/Qwen3-VL-2B-Instruct-GGUF --include "*Q4_K_M*.gguf" --include "mmproj-Qwen3VL-2B-Instruct-Q8_0.gguf" --local-dir /opt/models/Qwen3-VL-2B-Instruct/Q4_K_M

• Environ 3gb de vram consommée :

[Unit]
Description=llama-server Vision
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/Qwen3-VL-2B-Instruct/Q4_K_M/Qwen3VL-2B-Instruct-Q4_K_M.gguf \
  --mmproj /opt/models/Qwen3-VL-2B-Instruct/Q4_K_M/mmproj-Qwen3VL-2B-Instruct-Q8_0.gguf \
  --host 0.0.0.0 \
  --port 8083 \
  --api-key masuperclef \
  -c 16384 \
  -np 1 \
  -ctk q8_0 \
  -ctv q8_0 \
  -ngl 999 \
  -t 4 \
  -b 1024 \
  -ub 512 \
  --flash-attn on \
  --jinja \
  --top-p 0.8 \
  --top-k 20 \
  --temp 0.7 \
  --min-p 0.0 \
  --presence-penalty 1.5 \
  --image-min-tokens 1024 \
  --image-max-tokens 4096 \
  --sleep-idle-seconds 300

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Modèles de langage spécialisés en traduction

[Hy-MT2-7B]

# hf download unsloth/Hy-MT2-7B-GGUF --include "*UD-Q6_K_XL*.gguf" --local-dir /opt/models/Hy-MT2-7B/UD-Q6_K_XL

# vi /etc/systemd/system/llama-translation.service

[Unit]
Description=Llama Translation Server
After=network.target

[Service]
Type=simple
User=root

ExecStart=/opt/llama.cpp/build/bin/llama-server \
    -m /opt/models/Hy-MT2-7B/UD-Q6_K_XL/Hy-MT2-7B-UD-Q6_K_XL.gguf \
    --host 0.0.0.0 \
    --port 8084 \
    --api-key masuperclef \
    -ngl 999 \
    -c 32768 \
    -n 4096 \
    -ctk q8_0 \
    -ctv q8_0 \
    -np 1 \
    -b 2048 \
    -ub 1024 \
    -fa on \
    --jinja \
    --temp 0.7 \
    --top-k 20 \
    --top-p 0.6 \
    --repeat-penalty 1.05 \
    --sleep-idle-seconds 300

Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

[Hy-MT2-1.8B]

# hf download unsloth/Hy-MT2-1.8B-GGUF --include "*UD-Q6_K_XL*.gguf" --local-dir /opt/models/Hy-MT2-1.8B/UD-Q6_K_XL

# vi /etc/systemd/system/llama-translation.service

[Unit]
Description=Llama Translation Server
After=network.target

[Service]
Type=simple
User=root

ExecStart=/opt/llama.cpp/build/bin/llama-server \
    -m /opt/models/Hy-MT2-1.8B/UD-Q6_K_XL/Hy-MT2-1.8B-UD-Q6_K_XL.gguf \
    --host 0.0.0.0 \
    --port 8084 \
    --api-key masuperclef \
    -ngl 999 \
    -c 32768 \
    -n 4096 \
    -ctk q8_0 \
    -ctv q8_0 \
    -np 1 \
    -b 2048 \
    -ub 1024 \
    -fa on \
    --jinja \
    --temp 0.7 \
    --top-k 20 \
    --top-p 0.6 \
    --repeat-penalty 1.05 \
    --sleep-idle-seconds 300

Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

Hunyuan-MT-7B

Modèle ancien et dépassé. De plus, sa licence interdit son utilisation dans de nombreux territoires, dont l'Union européenne.

# hf download mradermacher/Hunyuan-MT-7B-GGUF --include "*Q6*.gguf" --local-dir /opt/models/Hunyuan-MT-7B/Q6_K

# vi /etc/systemd/system/llama-translation.service

[Unit]
Description=Llama Translation Server
After=network.target

[Service]
Type=simple
User=root

ExecStart=/opt/llama.cpp/build/bin/llama-server \
    -m /opt/models/Hunyuan-MT-7B/Q6_K/Hunyuan-MT-7B.Q6_K.gguf \
    --host 0.0.0.0 \
    --port 8084 \
    --api-key masuperclef \
    -ngl 999 \
    -c 32768 \
    -ctk q8_0 \
    -ctv q8_0 \
    -np 1 \
    -b 2048 \
    -ub 1024 \
    -fa on \
    --temp 0.7 \
    --top-k 20 \
    --top-p 0.6 \
    --repeat-penalty 1.05 \
    --sleep-idle-seconds 300

Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

gemma-4-26B-A4B-it-qat pour test traduction intelligente rapide

# hf download unsloth/gemma-4-26B-A4B-it-qat-GGUF --include "*Q4*.gguf" --local-dir /opt/models/gemma-4-26B-A4B-it-qat/UD-Q4_K_XL

# vi /etc/systemd/system/llama-translation.service

Avec certaines versions récentes de llama.cpp, le serveur peut planter lors de l'utilisation de Gemma 4 avec MTP et le mode de répartition multi-GPU -sm tensor / --split-mode tensor. Le problème semble lié à la réutilisation des graphes de calcul (graph reuse) dans cette configuration. En attendant une correction upstream, ajouter temporairement dans la section [Service] du service systemd :

Environment="LLAMA_GRAPH_REUSE_DISABLE=1"

[Unit]
Description=Llama Translation Server
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
    -m /opt/models/gemma-4-26B-A4B-it-qat/UD-Q4_K_XL/gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf \
    --host 0.0.0.0 \
    --port 8084 \
    --api-key masuperclef \
    -ngl 999 \
    -sm tensor \
    --tensor-split 1,1 \
    -c 32768 \
    -ctk bf16 \
    -ctv bf16 \
    -np 1 \
    -b 1024 \
    -ub 1024 \
    -fa on \
    --jinja \
    --spec-type ngram-mod,draft-mtp \
    --spec-ngram-mod-n-match 24 \
    --spec-ngram-mod-n-min 12 \
    --spec-ngram-mod-n-max 48 \
    --spec-draft-model /opt/models/gemma-4-26B-A4B-it-qat/UD-Q4_K_XL/MTP/mtp-gemma-4-26B-A4B-it-Q4_0.gguf \
    --spec-draft-n-max 4 \
    --spec-draft-n-min 0 \
    --spec-draft-p-min 0.75 \
    --slot-save-path /kv_cache/ \
    --temp 1.0 \
    --top-p 0.95 \
    --top-k 64 \
    --min-p 0.0 \
    --presence-penalty 0.0 \
    --repeat-penalty 1.0

Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

gemma-4-31B-it-qat pour test traduction intelligente (2x 12 Go de VRAM)

# hf download unsloth/gemma-4-31B-it-qat-GGUF --include "*UD-Q4_K_XL*.gguf" --include "MTP/mtp-gemma-4-31B-it-Q8_0.gguf" --local-dir /opt/models/gemma-4-31B-it-qat/UD-Q4_K_XL

# vi /etc/systemd/system/llama-translation.service

Avec certaines versions récentes de llama.cpp, le serveur peut planter lors de l'utilisation de Gemma 4 avec MTP et le mode de répartition multi-GPU -sm tensor / --split-mode tensor. Le problème semble lié à la réutilisation des graphes de calcul (graph reuse) dans cette configuration. En attendant une correction upstream, ajouter temporairement dans la section [Service] du service systemd :

Environment="LLAMA_GRAPH_REUSE_DISABLE=1"

[Unit]
Description=Llama Translation Server
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/llama.cpp

ExecStart=/opt/llama.cpp/build/bin/llama-server \
    -m /opt/models/gemma-4-31B-it-qat/UD-Q4_K_XL/gemma-4-31B-it-qat-UD-Q4_K_XL.gguf \
    --host 0.0.0.0 \
    --port 8084 \
    --api-key masuperclef \
    -ngl 999 \
    -sm tensor \
    --tensor-split 1,1 \
    -c 32768 \
    -ctk q8_0 \
    -ctv q8_0 \
    -np 1 \
    -b 1024 \
    -ub 1024 \
    -fa on \
    --jinja \
    --spec-type ngram-mod,ngram-map-k4v,draft-mtp \
    --spec-ngram-mod-n-match 24 \
    --spec-ngram-mod-n-min 12 \
    --spec-ngram-mod-n-max 48 \
    --spec-ngram-map-k4v-size-n 12 \
    --spec-ngram-map-k4v-size-m 48 \
    --spec-ngram-map-k4v-min-hits 1 \
    --spec-draft-model /opt/models/gemma-4-31B-it-qat/UD-Q4_K_XL/MTP/mtp-gemma-4-31B-it-Q8_0.gguf \
    --spec-draft-n-max 4 \
    --spec-draft-n-min 0 \
    --spec-draft-p-min 0.75 \
    --slot-save-path /kv_cache/ \
    --temp 1.0 \
    --top-p 0.95 \
    --top-k 64 \
    --min-p 0.0 \
    --presence-penalty 0.0 \
    --repeat-penalty 1.0

Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target