# ton premier llm local avec llama.cpp, sur une carte de 12go

compiler llama.cpp pour ta carte nvidia et faire tourner un modèle récent avec 256K de contexte sur 12go, en comprenant ce que fait chaque option

- date : 2026-10-22
- type : guide (ia locale)
- matériel : une 3080 Ti 12go
- source : mesures faites par l'auteur sur son propre matériel
- page html : https://homelaber.dev/guides/llama-cpp-premier-llm-local/

## pourquoi llama.cpp

[llama.cpp](https://github.com/ggml-org/llama.cpp) est le moteur open source sur lequel reposent la plupart des outils d'IA locale (Ollama, LM Studio et beaucoup d'autres). l'utiliser directement demande un peu plus d'efforts, mais tu vois et tu règles tout, et tu profites des nouveautés dès qu'elles sortent. il lit les modèles au format **GGUF**, que tu trouves par milliers sur Hugging Face.

[mème : Too Damn High]

**il te faut** : une carte nvidia (ici une 3080 Ti 12go, mais une 3060 12go fera pareil, en un peu plus lent), linux avec le pilote nvidia, le **CUDA toolkit**, `git`, `cmake` et un compilateur C++. sous ubuntu, `sudo apt install git cmake build-essential` couvre les trois derniers.

## 1. compiler llama.cpp pour ta carte

```sh
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j
```

`-DGGML_CUDA=ON` active le calcul sur la carte nvidia ; sans ça, tout tournerait sur le processeur. la compilation prend quelques minutes, et les programmes arrivent dans `build/bin/`. par défaut, llama.cpp est compilé pour la carte branchée au moment de la compilation, ce qui est exactement ce qu'on veut.

**garde-le à jour** : les nouveaux modèles ont souvent besoin d'une version récente. chez moi, un llama.cpp de mai 2026 ne reconnaissait pas l'architecture d'un modèle sorti en octobre. pour mettre à jour, `git pull` puis relance les deux commandes `cmake`.

## 2. choisir et télécharger le modèle

je prends **Spark-X2.6-4B**, un petit modèle récent qui accepte 256K tokens de contexte, dans sa version GGUF Q8_0 officielle (4,07 GiB). Q8_0 veut dire « compressé sur 8 bits » : quasiment aucune perte par rapport à l'original, et il tient largement dans 12go.

pour télécharger un gros fichier depuis Hugging Face, j'ai eu de mauvaises surprises : curl tout seul plafonnait à 0,8 Mo/s et le client officiel s'est bloqué à 57% avant de repartir de zéro. **aria2c** avec plusieurs connexions a fait le travail à ~7 Mo/s :

```sh
sudo apt install aria2
aria2c -x 16 -s 16 "<l'adresse du fichier .gguf sur hugging face>"
```

(sur la page du modèle, onglet « Files », le lien de téléchargement de chaque fichier)

## 3. le lancer avec 256K de contexte

```sh
./build/bin/llama-server \
  -m Spark-X2.6-4B-Q8_0.gguf \
  -ngl 99 \
  -fa on \
  -c 262144 \
  -ctk q8_0 -ctv q8_0 \
  -b 4096 -ub 1024 \
  --jinja
```

ce que fait chaque option :

| option | ce qu'elle fait |
|---|---|
| `-m` | le fichier du modèle |
| `-ngl 99` | met toutes les couches du modèle sur la carte (99 = « tout ») |
| `-fa on` | active la flash attention : plus rapide et moins gourmand en mémoire sur les longs contextes |
| `-c 262144` | la taille du contexte en tokens, ici 256K |
| `-ctk q8_0 -ctv q8_0` | compresse le cache du contexte en 8 bits, sinon 256K ne tiendrait pas dans 12go |
| `-b 4096 -ub 1024` | la taille des paquets de tokens quand il lit ton prompt ; plus gros = lecture plus rapide |
| `--jinja` | utilise le modèle de conversation fourni avec le modèle (indispensable pour les appels d'outils) |

une fois le serveur lancé, ouvre `http://127.0.0.1:8080` dans ton navigateur : llama.cpp a sa propre page de discussion, de quoi vérifier tout de suite que le modèle répond.

## 4. ce que ça donne

sur ma 3080 Ti, mesuré avec `llama-bench` (l'outil de bench fourni) :

| contexte déjà rempli | lecture du prompt | génération |
|---|---:|---:|
| vide | 7 925 tok/s | 136 tok/s |
| 32K | 4 701 tok/s | 106 tok/s |
| 128K | 1 993 tok/s | 57 tok/s |
| 254K | 1 066 tok/s | 35 tok/s |

**génération selon le contexte déjà rempli**

| | tok/s |
|---|---:|
| vide | 136,2 |
| 32K | 106,4 |
| 128K | 57,4 |
| 254K | 34,9 |

retiens surtout que **la vitesse baisse quand le contexte se remplit** : 136 tok/s à vide, 35 tok/s avec 254K tokens. c'est normal, le modèle relit tout son contexte à chaque mot. pour mesurer ta propre carte :

```sh
./build/bin/llama-bench -m Spark-X2.6-4B-Q8_0.gguf -fa 1 -ctk q8_0 -ctv q8_0 -p 2048 -n 128
```

## 5. le réglage à comprendre : compresser le cache ou non

compresser le cache en q8_0 permet d'aller très loin en contexte, mais ça coûte cher en vitesse : à 128K, je passe de 78 tok/s (cache non compressé, f16) à 57 tok/s (q8_0), soit -27%. donc si tu n'as pas besoin de plus de ~170K tokens sur une carte de 12go, **retire `-ctk q8_0 -ctv q8_0`** et réduis `-c` : tu iras nettement plus vite.

## la suite

- **un modèle plus gros que ta carte** : pour un modèle MoE (comme les Qwen « A3B »), l'option `--n-cpu-moe N` garde les experts des N premières couches en RAM, et le reste sur la carte. c'est ce qui permet de faire tourner des modèles de 30B et plus sur 12go.
- **le brancher à tes outils** : `llama-server` parle l'API d'OpenAI sur `http://127.0.0.1:8080/v1`, donc la plupart des clients et des agents s'y connectent directement.
- le détail de mes mesures et du test de codes cachés jusqu'à 245K tokens est dans [l'expérience](/labo/spark-4b-256k-3080ti/).