LLM on kenji.blog

Comment utiliser llama.cpp et introduction à la personnalisation en C++

Fri, 11 Sep 2026 11:00:00 +0900

Ces dernières années, l’évolution des grands modèles de langage (LLM) a été fulgurante et leur champ d’application s’élargit chaque jour. Cependant, faire tourner localement des modèles avec des milliards, voire des dizaines de milliards de paramètres, nécessite généralement des GPU haut de gamme dotés d’une énorme quantité de VRAM. C’est llama.cpp qui a brisé ce « mur matériel » et a rendu possible l’inférence pratique des LLM sur des PC classiques, des Mac, ou encore des appareils comme le Raspberry Pi.

Dans cet article, nous irons au-delà de la simple utilisation de l’outil en ligne de commande. Nous expliquerons en détail, pour les ingénieurs, l’architecture de ggml (sa technologie sous-jacente), le contexte mathématique des Transformers et de la quantification, ainsi que les méthodes pour intégrer et personnaliser des LLM dans vos propres applications en utilisant l’API C++.

1. Vue d’ensemble de llama.cpp et ggml

llama.cpp est un moteur d’inférence LLM léger écrit en C/C++ et développé par Georgi Gerganov. À l’origine, il a été créé dans le but de faire fonctionner rapidement le modèle LLaMA de Meta sur Apple Silicon (Mac M1/M2), mais il prend aujourd’hui en charge une grande variété d’architectures et de modèles.

Sa plus grande caractéristique est d’être une implémentation pure en C/C++ sans dépendances externes. Il ne nécessite pas d’écosystèmes massifs comme Python ou PyTorch et peut être compilé en un seul fichier exécutable, ce qui rend son déploiement extrêmement facile.

Le cœur de llama.cpp est la bibliothèque de calcul tensoriel ggml. ggml a été conçue de zéro pour optimiser à l’extrême les opérations matricielles en apprentissage automatique sur CPU (et partiellement sur GPU).

1.1 Pourquoi llama.cpp est-il si rapide ?

Utilisation du memory mapping (mmap) : Lors du chargement des poids du modèle en mémoire, l’utilisation de mmap du système d’exploitation permet d’éviter un chargement complet en RAM, assurant ainsi un démarrage rapide et une économie de mémoire.
Optimisation exhaustive des instructions SIMD : Il tire parti des jeux d’instructions spécifiques aux processeurs, tels que AVX2, AVX-512, ARM NEON, et Apple AMX, pour accélérer considérablement les multiplications matricielles.
Quantification (Quantization) : Les poids en nombres à virgule flottante 16 bits (FP16) sont compressés en entiers de 4, 5 ou 8 bits, ce qui élimine les goulots d’étranglement liés à la bande passante de la mémoire (les détails seront abordés plus loin).

2. Contexte mathématique : Transformer et Quantification (Quantization)

Pour comprendre profondément llama.cpp, il est nécessaire de connaître les formules mathématiques qu’il calcule et la manière dont il approche ces calculs.

2.1 Processus d’inférence des Transformers

Les modèles comme LLaMA adoptent une architecture de décodeur Transformer de type autorégressif (Auto-regressive). Le cœur de la génération de texte est le mécanisme de Self-Attention.

Pour la matrice des états cachés d’entrée $X \in \mathbb{R}^{N \times d}$, les requêtes $Q$, les clés $K$ et les valeurs $V$ sont calculés par le produit avec des matrices de poids.

$$ Q = X W_Q, \quad K = X W_K, \quad V = X W_V $$

Ici, la sortie de l’Attention est définie comme suit :

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

Dans la boucle d’inférence de llama.cpp, le goulot d’étranglement réside dans le produit de ces immenses matrices $W_Q, W_K, W_V$ et des matrices de poids du réseau feed-forward (FFN) avec le vecteur $X$ (lors de la phase de génération, un seul jeton est traité à la fois, donc $N=1$). C’est ce qu’on appelle la GEMV (General Matrix-Vector Multiplication).

2.2 Bases mathématiques de la quantification (Quantization)

Dans les inférences où la bande passante de l’accès à la mémoire devient un goulot d’étranglement, la quantification, qui représente les paramètres de poids avec un petit nombre de bits, est indispensable. Voici le principe de base de la quantification par blocs (par exemple Q4_K ou Q4_0) largement utilisée dans llama.cpp.

Par exemple, considérons un bloc $w = [w_1, w_2, \dots, w_B]$ de longueur $B$ (généralement 32 ou 64) faisant partie d’une matrice de poids $W$ en FP16. Ce bloc est approximé par des entiers de 4 bits $q_i \in [-8, 7]$ et un facteur d’échelle unique $\Delta$ (FP16 ou FP32).

$$ w_i \approx \Delta \times q_i $$

$\Delta$ est déterminé en fonction de la valeur absolue maximale dans le bloc.

$$ \Delta = \frac{\max_i |w_i|}{7} $$

Lors du calcul du produit scalaire $y = w \cdot x$ en utilisant les poids quantifiés, si le vecteur d’entrée $x$ est également quantifié de la même manière tel que $x_i \approx \Delta_x \times q_{x, i}$, on obtient :

$$ y = \sum_{i=1}^{B} w_i x_i \approx \Delta \Delta_x \sum_{i=1}^{B} q_i q_{x, i} $$

Cette partie $\sum q_i q_{x, i}$ devient une opération purement entière, ce qui permet de la calculer en parallèle de manière extrêmement rapide en utilisant des instructions SIMD. C’est le secret mathématique qui permet à llama.cpp d’atteindre des vitesses impressionnantes sur CPU.

3. Architecture et flux d’inférence

Pour comprendre le fonctionnement interne de llama.cpp, le diagramme Mermaid ci-dessous illustre l’architecture globale du système et le flux de données.

graph TD A["Entrée utilisateur (Chaîne de caractères)"] --> B["Tokenizer llama.cpp"] B --> C["IDs de jetons (tableau int32)"] C --> D["Tampon de contexte (Cache KV)"] D --> E["Graphe de calcul ggml"] E --> F["Couches Transformer"] subgraph "Moteur ggml" F --> G["Self-Attention (RoPE)"] G --> H["Réseau Feed Forward"] H --> F end F --> I["Logits (Taille du vocabulaire)"] I --> J["Échantillonneur (Température, Top-K, Top-P)"] J --> K["ID de jeton sélectionné"] K --> L["Detokenizer llama.cpp"] L --> M["Chaîne de caractères de sortie"] K -. "Boucle auto-régressive" .-> D

La génération de texte est une boucle auto-régressive où chaque jeton généré est ajouté au cache KV comme entrée suivante, puis passe à nouveau par le graphe de calcul.

4. Configuration de l’environnement et méthodes de build

Avant d’intégrer llama.cpp dans un projet C++, commençons par compiler le code source.

4.1 Clonage du dépôt

1
2


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

4.2 Compilation avec CMake

Pour l’intégrer en tant que projet C++ dans d’autres applications, l’utilisation de CMake est la méthode la plus standard. En activant les accélérateurs (backends) spécifiques à chaque plateforme, vous pouvez accélérer les calculs.

CPU uniquement (Compilation de base) :

1
2
3


mkdir build && cd build
cmake ..
cmake --build . --config Release -j 8

En cas d’utilisation d’un GPU NVIDIA (CUDA) :

1
2
3


mkdir build && cd build
cmake .. -DGGML_CUDA=ON
cmake --build . --config Release -j 8

En cas d’utilisation d’Apple Silicon (Metal) :

1
2
3


mkdir build && cd build
cmake .. -DGGML_METAL=ON
cmake --build . --config Release -j 8

Une fois la compilation réussie, des exécutables comme llama-cli ainsi que la bibliothèque llama (et la bibliothèque ggml) à lier avec l’API C++ expliquée plus loin seront générés dans le répertoire build/bin/.

5. Introduction à la personnalisation en C++ : Utilisation de l’API llama.cpp

À partir d’ici, nous allons aborder le cœur du sujet : le contrôle de llama.cpp depuis du code C++. Pour intégrer un LLM dans vos propres applications (par exemple, un moteur de jeu, une application de bureau, ou un système embarqué) au lieu de se contenter de l’outil en ligne de commande, il est nécessaire d’appeler directement l’API C++.

llama.cpp fournit principalement une interface en langage C via le fichier d’en-tête llama.h. Vous utiliserez également cette interface lors de l’appel depuis C++.

5.1 Inclusions et configurations minimales requises

Pour utiliser llama.cpp dans votre projet, incluez ce qui suit :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#include "llama.h"
#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>

// Macros pour la gestion des erreurs
#define LLAMA_ASSERT(x) \
 do { \
 if (!(x)) { \
 std::cerr << "Assertion failed: " << #x << std::endl; \
 std::terminate(); \
 } \
 } while (0)

5.2 Chargement du modèle et initialisation du contexte

Tout d’abord, vous chargez un fichier de modèle au format .gguf et allouez le contexte pour l’inférence (espace mémoire et cache KV).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


int main(int argc, char ** argv) {
 if (argc < 2) {
 std::cerr << "Usage: " << argv[0] << " <model.gguf>" << std::endl;
 return 1;
 }
 std::string model_path = argv[1];

 // 1. Initialisation du backend (Configuration de l'environnement CPU/GPU, etc.)
 llama_backend_init();

 // 2. Obtention des paramètres par défaut du modèle
 llama_model_params model_params = llama_model_default_params();
 model_params.n_gpu_layers = 35; // Nombre de couches à décharger sur le GPU

 // 3. Chargement du modèle
 llama_model * model = llama_load_model_from_file(model_path.c_str(), model_params);
 if (model == nullptr) {
 std::cerr << "Failed to load model" << std::endl;
 return 1;
 }

 // 4. Configuration des paramètres du contexte
 llama_context_params ctx_params = llama_context_default_params();
 ctx_params.n_ctx = 2048; // Taille maximale du contexte (nombre de jetons)
 ctx_params.n_threads = 8; // Nombre de threads CPU utilisés pour l'inférence

 // 5. Création du contexte
 llama_context * ctx = llama_new_context_with_model(model, ctx_params);
 if (ctx == nullptr) {
 std::cerr << "Failed to create context" << std::endl;
 llama_free_model(model);
 return 1;
 }

 std::cout << "Model and context loaded successfully!" << std::endl;
 // ... Suite du traitement

5.3 Tokenisation du prompt (Tokenization)

Les LLM ne comprennent pas directement le texte, mais le traitent comme une séquence d’identifiants entiers (jetons). Il est nécessaire de convertir la chaîne d’entrée en jetons.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 std::string prompt = "Q: Quelle est la capitale du Japon ?\nA:";
 std::vector<llama_token> tokens_list;
 tokens_list.resize(prompt.length() + 4); // Taille du tampon avec une marge

 // Faut-il ajouter un jeton spécial (comme BOS : Begin of Sequence) au début ?
 bool add_special = true;
 // Convertir la chaîne en un tableau d'IDs de jetons
 int n_tokens = llama_tokenize(
 model,
 prompt.c_str(),
 prompt.length(),
 tokens_list.data(),
 tokens_list.size(),
 add_special,
 false // parse_special
 );

 if (n_tokens < 0) {
 // En cas de tampon insuffisant, une réallocation et un nouvel essai sont nécessaires (omis pour simplifier)
 std::cerr << "Failed to tokenize prompt" << std::endl;
 return 1;
 }
 tokens_list.resize(n_tokens);

5.4 Boucle d’inférence et échantillonnage

On construit une boucle qui fournit les jetons au modèle, obtient la distribution de probabilité des prochains jetons (Logits), puis effectue un échantillonnage pour déterminer le jeton suivant.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72


 // Nombre maximum de jetons à générer
 const int max_gen_tokens = 100;

 // Initialisation de la structure pour l'évaluation par lot (batch)
 llama_batch batch = llama_batch_init(512, 0, 1);

 // Ajout des jetons du prompt au lot
 for (size_t i = 0; i < tokens_list.size(); i++) {
 llama_batch_add(batch, tokens_list[i], i, { 0 }, false);
 }
 // Configurer pour n'émettre des logits (résultats de prédiction) que pour le dernier jeton du prompt
 batch.logits[batch.n_tokens - 1] = true;

 // Première évaluation (fournir le prompt au modèle)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "llama_decode() failed" << std::endl;
 return 1;
 }

 int n_cur = batch.n_tokens; // Longueur actuelle du contexte
 int n_decode = 0;

 std::cout << "\nOutput: ";

 // Initialisation du contexte de l'échantillonneur (Configuration de la Température, Top-K, Top-P, etc.)
 llama_sampler * smpl = llama_sampler_chain_init(llama_sampler_chain_default_params());
 llama_sampler_chain_add_top_k(smpl, 40);
 llama_sampler_chain_add_top_p(smpl, 0.9f, 1);
 llama_sampler_chain_add_temp(smpl, 0.7f);
 llama_sampler_chain_add_dist(smpl, 1234); // Graine aléatoire (seed)

 while (n_decode < max_gen_tokens) {
 // 1. Échantillonnage : Prédire le prochain jeton basé sur le contexte actuel
 llama_token new_token_id = llama_sampler_sample(smpl, ctx, -1);

 // 2. Si le jeton est EOS (End of Sequence), terminer la boucle
 if (llama_token_is_eog(model, new_token_id)) {
 break;
 }

 // 3. Décoder le jeton en chaîne de caractères (texte) et l'afficher
 char buf[128];
 int n_chars = llama_token_to_piece(model, new_token_id, buf, sizeof(buf), 0, false);
 if (n_chars > 0) {
 std::cout << std::string(buf, n_chars) << std::flush;
 }

 // 4. Préparer le jeton nouvellement généré comme le prochain lot
 llama_batch_clear(batch);
 llama_batch_add(batch, new_token_id, n_cur, { 0 }, true);

 // 5. Évaluation du modèle (Mettre à jour le cache KV et prédire la suite)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "Failed to evaluate" << std::endl;
 break;
 }

 n_cur += 1;
 n_decode += 1;
 }

 std::cout << std::endl;

 // Nettoyage
 llama_sampler_free(smpl);
 llama_batch_free(batch);
 llama_free(ctx);
 llama_free_model(model);
 llama_backend_free();

 return 0;
}

Ce code implémente une boucle d’inférence personnalisée en utilisant l’API de base de llama.cpp. Il utilise la structure llama_batch pour gérer un ensemble de jetons et exécute la passe avant (forward pass) du réseau neuronal avec llama_decode.

6. Cas de personnalisation avancée : Manipulation des logits et contrôle des pénalités en C++

Si vous souhaitez aller au-delà de la simple génération de texte et forcer la sortie dans un format spécifique (par exemple, uniquement du JSON), ou contrôler la sortie pour empêcher certains mots interdits, vous manipulerez directement les logits avant l’échantillonnage du côté C++.

Vous pouvez obtenir le tableau des scores bruts (les valeurs avant conversion en probabilités) juste avant que le modèle ne sorte chaque jeton.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Obtenir le tableau des logits bruts juste après l'inférence et avant l'échantillonnage
float * logits = llama_get_logits_ith(ctx, batch.n_tokens - 1);
int n_vocab = llama_n_vocab(model);

// Liste des IDs des jetons interdits (par exemple 1234, 5678)
std::vector<llama_token> forbidden_tokens = { 1234, 5678 };

// Mettre la probabilité d'apparition des jetons interdits à 0 (Logit à moins l'infini)
for (llama_token bad_tok : forbidden_tokens) {
 logits[bad_tok] = -INFINITY;
}

De cette façon, la manipulation directe de l’API C++ rend possible une “intervention à la microseconde pour chaque cycle d’inférence”, ce qui serait difficile ou entraînerait une forte surcharge via LangChain ou Python.

7. Les secrets du réglage des performances (Performance Tuning)

Une fois l’implémentation en C++ terminée, voici quelques points de contrôle pour maximiser la vitesse en vue d’une utilisation en production.

Optimisation du traitement par lots (Batching) : Si vous traitez simultanément les requêtes de plusieurs utilisateurs, incluez plusieurs séquences dans llama_batch et appelez llama_decode en une seule fois (Continuous Batching). Cela permet de mutualiser les accès mémoire et d’améliorer considérablement le débit.
Activation de Flash Attention : En configurant ctx_params.flash_attn = true; dans les paramètres du contexte, vous pouvez accélérer le calcul de l’Attention tout en réduisant l’utilisation de la mémoire. C’est un paramètre indispensable lorsque vous manipulez de longs contextes (des dizaines de milliers de jetons).
Prise en charge NUMA : Dans un environnement de serveur multiprocesseur (multi-socket), configurer correctement NUMA avant llama_backend_init() permet de réduire la latence d’accès à la mémoire.

8. Conclusion

Dans cet article, nous avons détaillé les bases mathématiques de llama.cpp, expliqué son architecture et montré comment construire un moteur d’inférence personnalisé en exploitant l’API C++.

Si l’écosystème Python est extrêmement pratique pour le prototypage, le contrôle direct via llama.cpp en C/C++ montre une puissance écrasante dans des environnements de production nécessitant un déploiement sur des appareils Edge, une intégration dans des jeux ou un traitement en temps réel.

N’hésitez pas à écrire vous-même du code C++ et à faire l’expérience du plaisir de manipuler librement des LLM dans votre propre environnement local.

Liens de référence

llama.cpp Official Repository

ggml - Tensor Library

Attention Is All You Need (Vaswani et al., 2017)

【Dernière version 2026】Guide complet pour exécuter un LLM local sous Windows

Fri, 11 Sep 2026 10:00:00 +0900

1. Introduction : Pourquoi un LLM local sous Windows aujourd’hui ?

En 2026, l’évolution de l’IA générative et des grands modèles linguistiques (LLM) montre un changement de paradigme majeur, passant des services API massifs sur le cloud aux “LLM locaux” fonctionnant sur des PC personnels ou dans des environnements sur site. Les IA cloud comme GPT-5 d’OpenAI ou Claude 3.5 d’Anthropic sont extrêmement puissantes, mais les entreprises et les particuliers ne peuvent pas toujours envoyer toutes leurs données sur le cloud. Du point de vue de la confidentialité, de la sécurité, de la latence et des coûts à long terme et durables, la demande de LLM locaux a explosé comme jamais auparavant.

L’évolution de l’écosystème des LLM locaux, en particulier dans l’environnement Windows, est remarquable. Il y a quelques années, il était de notoriété publique que “le développement et l’exécution de l’IA se font sous Linux”, mais en 2026, Windows s’est transformé en une plateforme d’IA extrêmement puissante et facile d’accès.

Cet article fournit un guide complet pour configurer, exploiter et optimiser les LLM locaux dans un environnement Windows, sur la base des dernières tendances technologiques de 2026. Nous expliquerons tout en détail avec un volume impressionnant, de la configuration facile avec Ollama pour les débutants, à l’optimisation extrême utilisant llama.cpp pour les utilisateurs avancés, en passant par l’approche mathématique des calculs VRAM, la compréhension approfondie de l’architecture et le fine-tuning (ajustement fin) en local.

1.1 Tendances technologiques entourant les LLM locaux en 2026

Les principales tendances qui façonnent l’écosystème actuel des LLM locaux sont les suivantes :

Adoption complète du format GGUF : GGUF (GPT-Generated Unified Format), qui intègre les métadonnées et les tenseurs dans un seul fichier, est devenu le standard de facto absolu. Ainsi, en téléchargeant un seul fichier depuis Hugging Face, il peut être exécuté dans n’importe quel environnement.
Démocratisation de l’architecture MoE (Mixture of Experts) : De nombreux modèles MoE, petits mais performants, ont été publiés. En activant seulement certains experts lors de l’inférence, ils atteignent des performances comparables aux modèles géants tout en réduisant la charge de calcul sur les PC grand public.
Abstraction et optimisation avancées des moteurs d’inférence : Des outils comme Ollama, LM Studio et AnythingLLM ont été affinés, éliminant le besoin pour les utilisateurs de se soucier des dépendances complexes telles que l’installation des pilotes CUDA. De plus, la prise en charge native de FlashAttention 3 sous Windows a considérablement amélioré la vitesse d’inférence.
Utilisation des NPU et essor des PC Windows Copilot+ : La technologie permettant d’exécuter de petits LLM (SLM : Small Language Models) avec une faible consommation d’énergie en utilisant le NPU (Neural Processing Unit) intégré, même sur les ordinateurs portables sans GPU, est entrée dans la phase pratique.

2. Exigences matérielles et préparation du système d’exploitation

Pour qu’un LLM local fonctionne à une vitesse pratique (15 à 30 tokens ou plus par seconde), le choix du matériel est le plus important.

2.1 Configuration matérielle recommandée

Avec l’évolution des PC IA, les spécifications requises évoluent également.

Système d’exploitation (OS) : Windows 11 Pro (24H2 ou ultérieur). Indispensable pour utiliser toutes les fonctionnalités de WSL2, la gestion avancée de la mémoire, ainsi que les dernières API de DirectML.
CPU : Intel Core Ultra série 200 ou supérieur, ou AMD Ryzen série 9000 ou supérieur. Lors de l’utilisation conjointe de l’inférence CPU, une communication mémoire à large bande passante est essentielle.
RAM : Minimum 32 Go, 64 Go ou plus recommandés. La bande passante de la mémoire principale (Mo/s) devient un goulot d’étranglement décisif lors de l’inférence CPU ou du déchargement. Une mémoire rapide DDR5-6000 ou supérieure est idéale.
GPU : Séries NVIDIA RTX 4000/5000. Pour les LLM locaux, le plus important n’est pas la puissance de calcul, mais la “capacité de la VRAM”.
- Entrée de gamme : RTX 4060 Ti (version 16 Go) - Le meilleur rapport qualité-prix. Idéal pour les modèles de la classe 8B à 14B.
- Milieu de gamme : RTX 4070 Ti SUPER (16 Go) / RTX 4080 SUPER (16 Go)
- Haut de gamme : RTX 4090 (24 Go) / RTX 5090 (32 Go) - Nécessaire pour exécuter des modèles quantifiés de la classe 30B à 70B.
Stockage : SSD NVMe PCIe Gen4 ou Gen5. Réduit considérablement le temps de chargement des modèles de plusieurs dizaines de gigaoctets.

2.2 Configuration de WSL2 (Windows Subsystem for Linux 2)

Bien que de nombreux outils GUI fonctionnent nativement sous Windows, WSL2 est très pratique pour le développement avec Python, la compilation des derniers outils et le fine-tuning LoRA décrit plus loin. Dans les environnements Windows 11 récents, en installant simplement le pilote NVIDIA sur l’hôte, le GPU (CUDA) peut être utilisé de manière transparente depuis WSL2.

Ouvrez PowerShell avec les droits d’administrateur et exécutez ce qui suit :

1
2
3
4
5


# Installation de WSL2 et du dernier Ubuntu
wsl --install -d Ubuntu-24.04

# Mise à jour du noyau
wsl --update

Après l’installation, exécutez nvidia-smi dans le terminal WSL2. Si le GPU est correctement reconnu, c’est un succès.

3. Architecture et mécanisme d’inférence des LLM locaux

Comprendre la structure interne, c’est-à-dire la manière dont les modèles génèrent du texte dans un environnement local, est extrêmement utile pour le dépannage et l’optimisation.

Le diagramme Mermaid suivant montre le pipeline d’inférence typique d’un LLM local.

graph TD User["Entrée utilisateur (Prompt)"] --> Tokenizer["Tokeniseur (Tokenizer)"] Tokenizer --> Embedding["Couche de plongement (Embedding)"] subgraph "Transformer Block (x Layers)" Embedding --> Attn["Auto-attention (Self-Attention)"] Attn --> KVCache["Cache KV (Maintien Key/Value)"] Attn --> FFN["Réseau Feed-Forward (FFN)"] end FFN --> Logits["Calcul des Logits (Logits)"] Logits --> Sampler["Échantillonneur (Temperature, Top-K, Top-P)"] Sampler --> OutputToken["Token de sortie"] OutputToken --> |"Génération autorégressive"| Tokenizer OutputToken --> Decoder["Détokeniseur (Detokenizer)"] Decoder --> FinalOutput["Texte de sortie final"]

3.1 Deux phases : Prefill et Decode

La génération de texte des LLM est divisée en deux phases aux caractéristiques de calcul différentes.

Phase de Prefill (traitement du prompt) : C’est la phase où l’ensemble du prompt entré est traité et compris en une seule fois. Étant donné que le calcul parallèle est possible, la capacité de calcul (FLOPS) du GPU est directement liée à la vitesse. Si le prompt est long, cette phase peut prendre plusieurs secondes.
Phase de Decode (génération de tokens) : C’est la phase de prédiction token par token, en transmettant à l’entrée suivante (autorégressif). Comme le calcul parallèle est limité dans cette phase, la bande passante de la VRAM du GPU (Memory Bandwidth) devient le goulot d’étranglement décisif.

4. Calcul de la consommation de VRAM et compréhension mathématique de la taille du modèle

Pour juger correctement de “quel modèle fonctionnera sur mon PC ?”, il est nécessaire de comprendre la formule de calcul de la VRAM. Lorsqu’un repli sur la mémoire système (RAM) se produit en raison d’un manque de VRAM, la vitesse d’inférence devient 10 à 100 fois plus lente.

4.1 VRAM de base basée sur la taille des paramètres

Il s’agit de la quantité de mémoire nécessaire pour charger les poids (weights) du modèle dans la VRAM. Elle se calcule à l’aide de la taille du modèle $P$ (nombre de paramètres, unité : 1 milliard = 1B) et du nombre d’octets par paramètre $B$.

$$ V_{base} = P \times B \quad \text{(GB)} $$

Par exemple, pour charger un modèle de 8B (8 milliards) de paramètres en FP16 (virgule flottante demi-précision, 16 bits = 2 octets) :

$$ V_{base} = 8 \times 2 = 16 \text{ GB} $$

En d’autres termes, même avec un GPU doté de 16 Go de VRAM, on atteint presque la limite rien qu’en chargeant le modèle.

4.2 La magie de la quantification (Quantization)

C’est là qu’intervient la “quantification”. En réduisant la précision des paramètres, la taille du modèle est considérablement réduite. Dans le cas de la quantification 4 bits la plus courante (ex: Q4_K_M), la moyenne est d’environ 0,55 octet par paramètre.

$$ V_{base\_4bit} = 8 \times 0.55 = 4.4 \text{ GB} $$

Grâce à cela, si vous avez 16 Go de VRAM, vous pouvez exécuter un modèle 8B avec une marge suffisante.

4.3 Calcul du cache KV (Version compatible GQA)

Lors de l’inférence, le “cache KV” utilisé pour conserver le contexte passé consomme de la VRAM. Dans les modèles récents comme Llama 3, la GQA (Grouped Query Attention) est adoptée pour économiser de la mémoire.

La consommation du cache KV $V_{kv}$ (en gigaoctets) est exprimée par la formule mathématique suivante :

$$ V_{kv} = 2 \times b \times s \times l \times \left( \frac{h_{kv}}{h_q} \right) \times h_q \times d \times B_{kv} \div 10^9 $$

En simplifiant, cela peut être calculé facilement à l’aide du nombre de têtes clés et valeurs $h_{kv}$.

$$ V_{kv} = 2 \times b \times s \times l \times h_{kv} \times d \times B_{kv} \div 10^9 $$

Où :

$b$ : Taille du lot (généralement 1 pour un usage local individuel)
$s$ : Longueur de séquence (longueur du contexte, ex: 8192)
$l$ : Nombre de couches (ex: 32)
$h_{kv}$ : Nombre de têtes KV (ex: 8)
$d$ : Nombre de dimensions par tête (ex: 128)
$B_{kv}$ : Nombre d’octets du cache KV (2 pour FP16)

Exemple de calcul (Llama 3 8B, contexte 8192, cache FP16) : $V_{kv} = 2 \times 1 \times 8192 \times 32 \times 8 \times 128 \times 2 \div 10^9 \approx 1.07 \text{ GB}$

Veuillez noter que plus la longueur du contexte $s$ est longue, plus la VRAM requise augmente linéairement.

5. Pratique 1 : Configuration la plus rapide et la plus courte avec Ollama

Maintenant que vous comprenez la théorie, essayons de faire fonctionner un LLM dans un environnement Windows. En 2026, l’outil le plus convivial est “Ollama”. Il fournit une CLI intuitive de type Docker.

5.1 Installation et exécution

Téléchargez et exécutez le programme d’installation Windows depuis le site officiel d’Ollama.
Ouvrez PowerShell et entrez la commande suivante. Ici, nous utiliserons llama3:8b, qui prend en charge le japonais (et le français).

1

ollama run llama3:8b

Lors de la première exécution, le modèle sera téléchargé. Une fois terminé, vous pouvez interagir directement dans le terminal.

5.2 Création d’une IA personnalisée avec Modelfile

Vous pouvez facilement créer une IA avec un persona spécifique. Créez un fichier Modelfile à l’emplacement de votre choix.

1
2
3
4
5
6
7
8
9


FROM llama3:8b

SYSTEM """
Vous êtes un ingénieur logiciel senior extrêmement compétent.
Répondez toujours aux questions des utilisateurs de manière logique et concise, en incluant des exemples de code.
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

Construisez et exécutez votre propre modèle avec les commandes suivantes :

1
2


ollama create SeniorDev -f ./Modelfile
ollama run SeniorDev

5.3 Utilisation depuis des applications externes (Éditeurs IA)

Ollama expose un point de terminaison API compatible OpenAI sur http://localhost:11434. En spécifiant simplement cette URL dans les paramètres de backend d’extensions VS Code comme Cursor ou Continue.dev, et en définissant le nom du modèle sur SeniorDev, etc., vous obtenez un puissant assistant de codage local gratuit.

6. Pratique 2 : Optimisation extrême des performances avec llama.cpp

Si vous souhaitez gérer la mémoire en détail ou être le premier à essayer les derniers formats (EXL2, quantification IQ, etc.), vous pouvez manipuler directement le moteur de base llama.cpp.

6.1 Procédure de compilation de llama.cpp

Dans un environnement Windows, il est préférable de compiler à partir des sources en utilisant CUDA Toolkit et CMake.

1
2
3
4
5
6
7
8


git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build
cd build

# Configuration et compilation avec prise en charge de CUDA
cmake .. -DLLAMA_CUBLAS=ON -DBUILD_SHARED_LIBS=OFF
cmake --build . --config Release -j 16

6.2 Lancement avancé en mode serveur

Utilisez llama-server.exe compilé pour héberger le modèle.

1
2
3
4
5
6
7


.\bin\Release\llama-server.exe `
 --model "C:\models\Llama-3-8B-Instruct.Q4_K_M.gguf" `
 --ctx-size 8192 `
 --n-gpu-layers 99 `
 --threads 8 `
 --flash-attn `
 --port 8080

--n-gpu-layers 99 : Décharge autant de couches que possible vers la VRAM du GPU.
--flash-attn : Active FlashAttention 3, permettant d’améliorer la vitesse d’inférence et de réduire la consommation VRAM du cache KV.

7. Front-end GUI : LM Studio et construction d’un RAG local

Si vous êtes réticent à utiliser la ligne de commande ou si vous souhaitez effectuer un RAG (Génération Augmentée par la Recherche) de manière intuitive, utilisez une interface graphique (GUI).

7.1 LM Studio

LM Studio est une excellente application qui regroupe la recherche de modèles, le téléchargement, la vérification préalable des exigences système et une interface utilisateur de chat en un seul endroit. En appuyant simplement sur le bouton “Local Server” dans l’application, une API compatible OpenAI démarre.

7.2 Architecture RAG à l’aide d’AnythingLLM

Voici un diagramme de l’architecture d’un environnement RAG permettant d’importer des documents d’entreprise ou des notes personnelles.

graph LR Document["Document (PDF, MD)"] --> Chunking["Découpage en morceaux"] Chunking --> EmbedModel["Modèle de plongement"] EmbedModel --> VectorDB["Base de données vectorielle"] UserQuery["Question de l'utilisateur"] --> EmbedQuery["Plongement de la question"] EmbedQuery --> VectorDB VectorDB --> |"Recherche de similarité"| RetrievedDocs["Extraction de documents pertinents"] UserQuery --> PromptBuilder["Génération du prompt"] RetrievedDocs --> PromptBuilder PromptBuilder --> LocalLLM["LLM local"] LocalLLM --> Answer["Réponse finale"]

Avec la version de bureau d’AnythingLLM (Windows), il suffit de spécifier Ollama (LLM et Embedding) dans l’écran des paramètres et de configurer l’utilisation d’une base de données vectorielle locale (LanceDB) pour compléter cette architecture en quelques minutes. C’est la naissance d’une IA privée qui n’envoie aucune donnée à l’extérieur.

8. Fine-tuning sur Windows WSL2 (LoRA)

Si vous ne voulez pas seulement l’exécuter localement, mais aussi rendre le modèle plus intelligent avec vos propres données, un fine-tuning à l’aide de LoRA (Low-Rank Adaptation) est possible. En 2026, grâce à une bibliothèque appelée “Unsloth”, l’apprentissage d’un modèle 8B peut être achevé en quelques heures dans un environnement Windows WSL2, même avec 16 Go de VRAM.

Exécutez ce qui suit dans Ubuntu sur WSL2 pour configurer l’environnement :

1
2
3
4


conda create --name unsloth_env python=3.11
conda activate unsloth_env
pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git"
pip install --no-deps trl peft accelerate bitsandbytes

Unsloth optimise les noyaux CUDA à l’extrême, rendant la vitesse d’apprentissage environ deux fois plus rapide et la consommation de VRAM réduite de moitié par rapport à la bibliothèque standard Hugging Face. En lançant simplement un Jupyter Notebook et en chargeant un jeu de données (format JSONL), l’apprentissage sur plusieurs époques est possible même avec une RTX 4060 Ti dotée de 12 à 16 Go de VRAM.

9. Dépannage des performances

Voici les problèmes fréquemment rencontrés et leurs solutions.

1. La vitesse d’inférence est extrêmement lente (1 à 2 tokens/s)

Cause : Le modèle ne rentre pas dans la VRAM et est déchargé sur la mémoire système (RAM). Solution : Vérifiez la “Mémoire GPU dédiée” dans le Gestionnaire des tâches. Si elle atteint sa limite, réduisez la taille du contexte (-c) ou utilisez un modèle avec un niveau de quantification inférieur (comme Q4_K_M).

2. Erreur “CUDA out of memory”

Cause : La VRAM est complètement épuisée. Cela se produit notamment lorsque la conversation se prolonge et que le cache KV augmente de manière excessive. Solution : Limitez intentionnellement la valeur de num_ctx pour Ollama, ou -c pour llama.cpp.

3. La génération du japonais est étrange

Cause : Incohérence dans le modèle de prompt, ou modèle non compatible. Solution : Utilisez un modèle dont le nom inclut Instruct et assurez-vous que le modèle de prompt correct (format ChatML, format Llama3, etc.) spécifié par le créateur du modèle est sélectionné du côté de l’outil.

10. Conclusion et perspectives d’avenir

En 2026, la mise en place d’un LLM local dans un environnement Windows n’est plus un privilège réservé à une poignée d’ingénieurs. Avec l’adoption généralisée du format GGUF, l’émergence d’écosystèmes raffinés comme Ollama et LM Studio, ainsi que les optimisations matérielles telles que FlashAttention, n’importe qui peut facilement obtenir un environnement d’IA de niveau entreprise.

N’hésitez pas à tirer parti des points expliqués dans cet article :

Utiliser le calcul mathématique de la VRAM pour choisir logiquement la taille de modèle et le niveau de quantification optimaux pour les spécifications de votre PC.
Utiliser Ollama pour configurer l’environnement le plus rapidement possible et l’intégrer à un éditeur d’IA pour améliorer considérablement la productivité.
Exploiter les limites de performance du matériel avec le contrôle avancé des paramètres de llama.cpp.
Construire un système RAG local sécurisé qui gère les données confidentielles avec AnythingLLM.
Tirer parti d’Unsloth (WSL2) pour développer une IA personnalisée avec votre propre expertise.

La “démocratisation” de l’IA n’est plus un buzzword, mais un système réel fonctionnant sur votre bureau Windows. Libérez-vous des coûts d’utilisation des API cloud et des risques de fuite d’informations, et entrez dès maintenant dans le monde libre et puissant de l’IA privée.