« Llama.cpp » : différence entre les versions
De Le Wiki de Lug
Autres actions
| Ligne 1 : | Ligne 1 : | ||
== Prérequis == | == Prérequis == | ||
* Un GPU est recommandé, idéalement NVIDIA avec le plus de VRAM possible. | |||
* Les modèles peuvent fonctionner sur CPU uniquement, mais avec des performances très faibles | * Un GPU est recommandé, idéalement NVIDIA avec le plus de VRAM possible. ik_llama.cpp met particulièrement l’accent sur CUDA, le multi-GPU et les configurations hybrides GPU/CPU. Comme llama.cpp, il permet de répartir une partie du modèle entre GPU et CPU si la VRAM est insuffisante, au prix d’une baisse de performances. [[GPU_Passthrough|Voir ce lien pour partager un GPU dans un LXC]] | ||
* VRAM recommandée : dépend du niveau d’offload GPU. Pour un usage optimal, prévoir environ la taille du modèle | * Les modèles peuvent fonctionner sur CPU uniquement, mais avec des performances très faibles pour les gros modèles, souvent inutilisables en pratique pour un usage interactif. | ||
* 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. | * VRAM recommandée : dépend du niveau d’offload GPU et de la taille du contexte utilisé. Pour un usage optimal, prévoir environ la taille du modèle quantifié + 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. | ||
* Espace disque à prévoir en fonction du ou des | * 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 ou si l’on utilise une configuration hybride GPU/CPU. | ||
** qwen2.5:7b (Q4) ≈ 4–5 Go | * Espace disque à prévoir en fonction du ou des modèles que vous allez utiliser ou tester. Exemples : | ||
** qwen2.5:14b (Q4) ≈ 8–10 Go | ** qwen2.5:7b (Q4) ≈ 4–5 Go | ||
** llama3:70b (Q4) ≈ 35–40 Go | ** qwen2.5:14b (Q4) ≈ 8–10 Go | ||
* Utiliser un SSD/NVMe améliore fortement les temps de chargement. | ** llama3:70b (Q4) ≈ 35–40 Go | ||
* Utiliser un SSD/NVMe améliore fortement les temps de chargement des modèles. | |||
* CPU / vCPU recommandés : | * CPU / vCPU recommandés : | ||
** Avec GPU : 4 à 8 vCPU recommandés | ** Avec GPU : 4 à 8 vCPU recommandés, notamment pour la gestion du serveur, du KV cache et d’un éventuel offload partiel CPU. | ||
** Sans GPU : prévoir au minimum 8 à 16 vCPU, les performances restant très limitées. | ** Sans GPU : prévoir au minimum 8 à 16 vCPU, les performances restant très limitées sur les modèles importants. | ||
* Note : Q4 correspond au niveau de | * 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, notamment en 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 ou Q5 est généralement considéré comme le meilleur compromis entre performances, consommation de VRAM et qualité de réponse. | ||
== Installation == | == Installation == | ||
Version du 3 juin 2026 à 15:09
Prérequis
- Un GPU est recommandé, idéalement NVIDIA avec le plus de VRAM possible. ik_llama.cpp met particulièrement l’accent sur CUDA, le multi-GPU et les configurations hybrides GPU/CPU. Comme llama.cpp, il permet de répartir une partie du 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 pour les gros modèles, souvent inutilisables en pratique pour un usage interactif.
- VRAM recommandée : dépend du niveau d’offload GPU et de la taille du contexte utilisé. Pour un usage optimal, prévoir environ la taille du modèle quantifié + 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 ou si l’on utilise une configuration hybride GPU/CPU.
- Espace disque à prévoir en fonction du ou des modèles 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 des modèles.
- CPU / vCPU recommandés :
** Avec GPU : 4 à 8 vCPU recommandés, notamment pour la gestion du serveur, du KV cache et d’un éventuel offload partiel CPU. ** Sans GPU : prévoir au minimum 8 à 16 vCPU, les performances restant très limitées sur les modèles importants.
- 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, notamment en 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 ou 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
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 CUDAConnaî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 # 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)
Plateformes de modèles :
- Hugging Face Plateforme principale.
Quantization custom (souvent mieux optimisé) :
Créer un dossier pour les modèles :
# mkdir -p /opt/llama.cpp/models
On configure le dossier des modèles :
# echo 'export LLAMA_CACHE=/opt/llama.cpp/models' >> ~/.bashrc # source ~/.bashrc
Exemple de chargement automatique d’un modèle depuis Hugging Face :
- Exemple avec Qwen/Qwen3-8B-GGUF:Q4_K_M :
# /opt/llama.cpp/build/bin/llama-cli -hf Qwen/Qwen3-8B-GGUF:Q4_K_M -n 0
- Exemple avec bartowski/Jackrong_Qwen3.5-9B-Neo-GGUF:Q4_K_M :
# /opt/llama.cpp/build/bin/llama-cli -hf bartowski/Jackrong_Qwen3.5-9B-Neo-GGUF:Q4_K_M -n 0
- Exemple avec HauhauCS/Qwen3.5-9B-Uncensored-HauhauCS-Aggressive:Q4_K_M :
# /opt/llama.cpp/build/bin/llama-cli -hf HauhauCS/Qwen3.5-9B-Uncensored-HauhauCS-Aggressive:Q4_K_M -n 0
Test rapide
Trouver le fichier .gguf :
# find /opt/llama.cpp/models -iname "*.gguf"
Exemple avec Qwen3.5-9B-Uncensored-HauhauCS-Aggressive :
# /opt/llama.cpp/build/bin/llama-cli \ -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 \ -ngl 35 \ -c 2048 \ -p "Explique moi ce qu'est llama.cpp"
Explication :
-ngl : nombre de couches envoyées au GPU -c : taille du contexte
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
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.
| Avec certificat auto-signé (déconseillé) |
|---|
# mkdir -p /etc/llama-server # chmod 700 /etc/llama-server
# apt update && apt upgrade # apt install openssl curl
# vi /etc/llama-server/api-keys.txt masuperclef # chmod 600 /etc/llama-server/api-keys.txt
# 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"
# 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.
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.
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
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 # 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.
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
- Test :
# journalctl -u llama-server -n 200 --no-pager | grep -E "offloaded|model buffer|KV buffer|compute buffer|n_ctx|n_batch|n_ubatch"
print_info: n_ctx_train = 262144 print_info: n_ctx_orig_yarn = 262144 load_tensors: offloaded 41/41 layers to GPU load_tensors: CUDA0 model buffer size = 4972.80 MiB load_tensors: CUDA_Host model buffer size = 20377.31 MiB llama_context: n_ctx = 131072 llama_context: n_ctx_seq = 131072 llama_context: n_batch = 4096 llama_context: n_ubatch = 4096 llama_context: n_ctx_seq (131072) < n_ctx_train (262144) -- the full capacity of the model will not be utilized llama_kv_cache: CUDA0 KV buffer size = 1360.00 MiB sched_reserve: CUDA0 compute buffer size = 3976.02 MiB sched_reserve: CUDA_Host compute buffer size = 2112.42 MiB alloc_compute_meta: CPU compute buffer size = 248.10 MiB slot load_model: id 0 | task -1 | new slot, n_ctx = 131072
Explique pourquoi un système peut sembler rapide en usage normal, mais devenir frustrant dans un workflow réel. Je veux une réponse qui distingue clairement : vitesse brute ; latence initiale ; fluidité perçue ; fiabilité ; confort à long terme. Termine par une conclusion pratique en 5 lignes maximum.
Vitesse : (apres plusieurs essais mais a confirmer..)
prompt eval time = 5194.60 ms / 2896 tokens ( 1.79 ms per token, 557.50 tokens per second) eval time = 16383.19 ms / 284 tokens ( 57.69 ms per token, 17.33 tokens per second) total time = 21577.79 ms / 3180 tokens
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
- Test :
# journalctl -u llama-server -n 200 --no-pager | grep -E "offloaded|model buffer|KV buffer|compute buffer|n_ctx|n_batch|n_ubatch"
print_info: n_ctx_train = 262144 print_info: n_ctx_orig_yarn = 262144 load_tensors: offloaded 41/41 layers to GPU load_tensors: CPU model buffer size = 333.44 MiB load_tensors: CUDA0 model buffer size = 4763.95 MiB load_tensors: CUDA_Host model buffer size = 19330.00 MiB llama_context: n_ctx = 131072 llama_context: n_ctx_seq = 131072 llama_context: n_batch = 4096 llama_context: n_ubatch = 4096 llama_context: n_ctx_seq (131072) < n_ctx_train (262144) -- the full capacity of the model will not be utilized llama_kv_cache: CUDA0 KV buffer size = 1360.00 MiB sched_reserve: CUDA0 compute buffer size = 3976.02 MiB sched_reserve: CUDA_Host compute buffer size = 2112.42 MiB alloc_compute_meta: CPU compute buffer size = 248.10 MiB slot load_model: id 0 | task -1 | new slot, n_ctx = 131072
Explique pourquoi un système peut sembler rapide en usage normal, mais devenir frustrant dans un workflow réel. Je veux une réponse qui distingue clairement : vitesse brute ; latence initiale ; fluidité perçue ; fiabilité ; confort à long terme. Termine par une conclusion pratique en 5 lignes maximum.
Premier essai :
prompt eval time = 5805.15 ms / 3969 tokens ( 1.46 ms per token, 683.70 tokens per second) eval time = 12018.11 ms / 210 tokens ( 57.23 ms per token, 17.47 tokens per second) total time = 17823.27 ms / 4179 tokens
Deuxième essai :
prompt eval time = 5803.15 ms / 3969 tokens ( 1.46 ms per token, 683.94 tokens per second) eval time = 9580.92 ms / 209 tokens ( 45.84 ms per token, 21.81 tokens per second) total time = 15384.07 ms / 4178 tokens