LLM on kenji.blog

Comment affiner TinyLLaMA le plus rapidement possible dans un environnement sur site

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

1. Introduction : Pourquoi TinyLLaMA et le sur site aujourd’hui ?

L’évolution des grands modèles de langage (LLM) progresse à une vitesse fulgurante, et avec elle, le nombre de paramètres des modèles continue de s’étendre pour atteindre des centaines de milliards. Si des modèles gigantesques comme GPT-4 et Claude 3 offrent des performances inégalées, les coûts de calcul pour l’inférence et l’apprentissage, ainsi que les problèmes de sécurité et de confidentialité des données lors de l’utilisation d’API externes, constituent des obstacles majeurs pour les entreprises. En particulier pour les tâches impliquant des données internes hautement confidentielles ou des informations personnelles, l’envoi de données à des API LLM publiques dans le cloud est souvent inacceptable du point de vue de la conformité (RGPD, APPI, etc.).

C’est là que les petits modèles de langage (SLM : Small Language Models) et le déploiement local dans des environnements sur site (on-premises) entrent en jeu. Parmi eux, “TinyLLaMA” se distingue. Avec une taille compacte de seulement 1,1B (1,1 milliard) de paramètres, il a été pré-entraîné sur un ensemble de données massif d’environ 3 billions de jetons (tokens), offrant des performances exceptionnelles par rapport aux modèles de la même catégorie.

Cet article fournit un guide complet pour affiner (fine-tuning) TinyLLaMA de manière “ultra-rapide et très efficace” pour vos tâches spécifiques dans un environnement sur site (serveur local ou station de travail). Nous couvrirons tout de manière exhaustive, des fondements mathématiques aux dernières techniques d’optimisation, en passant par le code d’implémentation concret en PyTorch.

2. Architecture et caractéristiques de TinyLLaMA

TinyLLaMA suit l’architecture LLaMA (Large Language Model Meta AI) développée par Meta. Tout en maintenant le nombre de paramètres à 1,1B, il utilise la même pile technologique que LLaMA 2, ce qui rend son écosystème hautement compatible.

Principaux composants de l’architecture

RMSNorm (Root Mean Square Normalization) : Une méthode de normalisation qui améliore l’efficacité des calculs en omettant la soustraction de la moyenne des calculs LayerNorm traditionnels. Elle augmente le débit tout en maintenant la stabilité de l’apprentissage.
Fonction d’activation SwiGLU : Dans le Feed Forward Network (FFN), SwiGLU est utilisé à la place des classiques ReLU ou GELU. Mathématiquement, cela s’exprime comme suit : $$ \text{SwiGLU}(x, W, V) = \text{Swish}(xW) \otimes (xV) $$ Ici, $\otimes$ représente le produit élément par élément (produit de Hadamard), et la fonction Swish est $\text{Swish}(z) = z \cdot \sigma(\beta z)$. Cela améliore considérablement la puissance de représentation.
RoPE (Rotary Position Embedding) : Une méthode qui combine les avantages de l’encodage de position absolu et relatif. Elle présente de fortes performances de généralisation même lorsque la longueur de la séquence est étendue.
Grouped Query Attention (GQA) : Une approche intermédiaire entre la Multi-Head Attention (MHA) et la Multi-Query Attention (MQA), qui permet d’économiser la bande passante mémoire et d’améliorer considérablement la vitesse d’inférence en regroupant les têtes de clé (key) et de valeur (value).

Le diagramme Mermaid ci-dessous illustre le flux de données global de TinyLLaMA et la structure du bloc Transformer.

graph TD A["Texte d'entrée"] --> B["Tokeniseur (BPE)"] B --> C["Couche d'intégration (Embedding)"] C --> D["Blocs Transformer (x22 Couches pour TinyLLaMA)"] D --> E["RMSNorm (Final)"] E --> F["Projection Linéaire (Taille du vocabulaire)"] F --> G["Probabilités de sortie (Softmax)"] subgraph "Anatomie du bloc Transformer" D1["État caché d'entrée"] --> D2["RMSNorm"] D2 --> D3["Grouped Query Attention (GQA)"] D3 --> D4["Ajout Résiduel"] D4 --> D5["RMSNorm"] D5 --> D6["FFN SwiGLU"] D6 --> D7["Ajout Résiduel"] D7 --> D8["Sortie vers la couche suivante"] D1 -.-> D4 D4 -.-> D7 end

3. La révolution du Fine-Tuning : LoRA et QLoRA

Pour effectuer un fine-tuning avec tous les paramètres dans un environnement sur site, même avec un modèle de 1,1B, il faut consommer des dizaines de gigaoctets de VRAM (mémoire vidéo) pour stocker les états de l’optimiseur et les gradients. Les méthodes PEFT (Parameter-Efficient Fine-Tuning) telles que “LoRA” et son extension quantifiée “QLoRA” sont essentielles pour un apprentissage efficace avec des ressources limitées.

3.1 Contexte mathématique de LoRA (Low-Rank Adaptation)

LoRA est une méthode qui fixe (gèle) la matrice de poids pré-entraînée et approxime la quantité de mise à jour de ce poids ($\Delta W$) par le produit de deux petites matrices de rang inférieur.

Soit $W_0 \in \mathbb{R}^{d \times k}$ le poids pré-entraîné. Dans un fine-tuning complet, $W_0$ lui-même est mis à jour en $W_0 + \Delta W$. Cependant, avec LoRA, la matrice de mise à jour $\Delta W$ est décomposée comme suit :

$$ \Delta W = B \times A $$

Ici, $B \in \mathbb{R}^{d \times r}$ et $A \in \mathbb{R}^{r \times k}$, et $r$ est un hyperparamètre appelé rang (Rank), qui est une très petite valeur (généralement 8, 16, 32, etc.) satisfaisant $r \ll \min(d, k)$.

Le calcul de la passe avant (forward pass) est le suivant :

$$ h = W_0 x + \Delta W x = W_0 x + B A x $$

À l’état initial, la matrice $A$ est initialisée de manière aléatoire avec une distribution normale (distribution gaussienne), et la matrice $B$ est initialisée avec une matrice nulle. Ainsi, $\Delta W$ au début de l’apprentissage est zéro, ce qui permet de commencer l’apprentissage tout en conservant parfaitement la sortie du modèle de base.

graph LR X["Vecteur d'entrée x"] --> W0["Poids pré-entraîné gelé (W_0)"] X --> A["Matrice LoRA entraînable A (r x k)"] A --> B["Matrice LoRA entraînable B (d x r)"] W0 --> Add["Addition vectorielle"] B --> Add Add --> Y["Vecteur de sortie h"]

3.2 L’innovation de QLoRA (Quantized LoRA)

QLoRA pousse l’approche LoRA encore plus loin en quantifiant le modèle de base $W_0$ avec une précision de 4 bits (NormalFloat 4, NF4) et en le chargeant en mémoire. Cela réduit considérablement la consommation de VRAM.

QLoRA intègre trois technologies importantes :

Quantification 4-bit NormalFloat (NF4) : Un type de données théoriquement optimal pour les poids suivant une distribution normale.
Double Quantification (Double Quantization) : Économise encore plus de mémoire en quantifiant également la constante de quantification (facteur d’échelle) elle-même.
Paged Optimizers : Utilise la fonction de mémoire unifiée de NVIDIA pour évacuer temporairement le statut de l’optimiseur vers la RAM du processeur lorsque la VRAM est insuffisante.

Grâce à cela, un fine-tuning qui nécessite normalement 16 à 24 Go de VRAM peut être exécuté confortablement même sur des GPU grand public (comme la RTX 3060 12 Go ou la RTX 4070).

4. Exigences matérielles et configuration dans un environnement sur site

Les exigences matérielles pour affiner TinyLLaMA (1,1B) avec QLoRA sont extrêmement faibles.

Spécifications matérielles recommandées

GPU : NVIDIA RTX 3060 (12 Go), RTX 3090/4090 (24 Go), ou NVIDIA A10G/A100, etc. Un minimum de 8 Go de VRAM est nécessaire pour fonctionner, mais 12 Go ou plus sont recommandés pour augmenter la taille du lot (batch size).
CPU : Processeur moderne à 8 cœurs ou plus (Intel Core i7/i9, AMD Ryzen 7/9)
RAM : 32 Go ou plus (Important comme destination d’évacuation depuis la VRAM lors de l’utilisation de Paged Optimizers)
Stockage : SSD NVMe (Pour accélérer le chargement des ensembles de données et la sauvegarde du modèle)

Configuration de l’environnement logiciel

Voici les étapes d’installation prévues pour un environnement Ubuntu 22.04 LTS. Nous utiliserons Python 3.10 ou une version ultérieure.

1
2
3
4
5
6
7
8
9


# Création et activation de l'environnement virtuel
python3 -m venv tinyllama_env
source tinyllama_env/bin/activate

# Installation de PyTorch (pour CUDA 12.1)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# Installation des bibliothèques liées aux Transformers
pip install transformers datasets peft trl accelerate bitsandbytes

5. Techniques d’optimisation pour le fine-tuning le plus rapide

Pour terminer le fine-tuning “le plus rapidement possible” plutôt que de simplement exécuter un script, il est nécessaire de combiner les techniques d’optimisation suivantes.

5.1 Flash Attention 2

Le mécanisme d’Attention standard a une complexité temporelle et spatiale de $O(N^2)$ pour une longueur de séquence $N$. Flash Attention 2 optimise l’accès mémoire entre la SRAM du GPU et la HBM (High Bandwidth Memory), éliminant ainsi les goulots d’étranglement d’E/S sans réduire la quantité de calcul, augmentant la vitesse d’apprentissage de plusieurs fois et réduisant considérablement la consommation de mémoire.

5.2 Gradient Checkpointing (Point de contrôle du gradient)

Une technique dans laquelle, au lieu de sauvegarder toutes les activations intermédiaires calculées lors de la passe avant dans la VRAM, seule une partie est sauvegardée, et elles sont recalculées lorsqu’elles sont nécessaires lors de la passe arrière. Le temps de calcul augmente d’environ 20 %, mais la consommation de mémoire peut être considérablement réduite, ce qui permet de définir une taille de lot plus importante et d’améliorer le débit global.

5.3 Mixed Precision Training (Apprentissage en précision mixte) et Bfloat16

Pour maximiser l’utilisation des Tensor Cores du GPU, les calculs pendant l’apprentissage sont effectués en bfloat16 (Brain Floating Point). Par rapport à float16, la longueur en bits de l’exposant est la même que celle de float32, de sorte que le risque de dépassement de capacité (overflow) ou de sous-dépassement (underflow) est extrêmement faible, ce qui stabilise l’apprentissage.

6. Pratique : Code de fine-tuning QLoRA pour TinyLLaMA

Nous allons maintenant expliquer le script PyTorch pour le fine-tuning le plus rapide intégrant toutes les optimisations ci-dessus. Nous utiliserons ici SFTTrainer de la bibliothèque trl (Transformer Reinforcement Learning) de Hugging Face.

6.1 Préparation de l’ensemble de données et chargement du modèle

 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


import torch
from datasets import load_dataset
from transformers import (
 AutoModelForCausalLM,
 AutoTokenizer,
 BitsAndBytesConfig,
 TrainingArguments
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer

# 1. Spécification du modèle et du tokeniseur
model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

# 2. Paramètres de quantification 4-bit pour QLoRA
bnb_config = BitsAndBytesConfig(
 load_in_4bit=True,
 bnb_4bit_use_double_quant=True,
 bnb_4bit_quant_type="nf4",
 bnb_4bit_compute_dtype=torch.bfloat16 # Les calculs sont effectués en bfloat16
)

# 3. Chargement du modèle (Activation de Flash Attention 2)
print("Chargement du modèle...")
model = AutoModelForCausalLM.from_pretrained(
 model_id,
 quantization_config=bnb_config,
 device_map="auto",
 use_flash_attention_2=True # La clé de l'accélération
)

# 4. Chargement du tokeniseur
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right" # Défini sur right pour éviter un bug lors de l'entraînement fp16/bf16

6.2 Application de l’adaptateur LoRA et formatage des données

 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


# 5. Préparation de l'apprentissage k-bit et activation du gradient checkpointing
model.gradient_checkpointing_enable()
model = prepare_model_for_kbit_training(model)

# 6. Configuration de LoRA
peft_config = LoraConfig(
 r=16, # Rang
 lora_alpha=32, # Facteur d'échelle
 lora_dropout=0.05,
 bias="none",
 task_type="CAUSAL_LM",
 target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"] # Cibler toutes les couches Linear améliore les performances
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()
# Exemple de sortie : trainable params: 14,286,848 || all params: 1,114,335,232 || trainable%: 1.282%

# 7. Chargement de l'ensemble de données (ici, un ensemble de données d'instructions en japonais est utilisé comme exemple)
# En réalité, vous chargerez un fichier JSONL privé sur site, etc.
dataset = load_dataset("kunishou/databricks-dolly-15k-ja", split="train")

def format_instruction(sample):
 """
 Formate la chaîne pour correspondre au format ChatML ou au modèle de prompt
 """
 prompt = f"<|im_start|>user\n{sample['instruction']}"
 if sample.get("input", "") != "":
 prompt += f"\n{sample['input']}"
 prompt += f"<|im_end|>\n<|im_start|>assistant\n{sample['output']}<|im_end|>"
 return {"text": prompt}

dataset = dataset.map(format_instruction)

6.3 Exécution de l’entraînement

 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


# 8. Configuration des arguments d'entraînement
training_args = TrainingArguments(
 output_dir="./tinyllama-lora-output",
 per_device_train_batch_size=8, # Augmenter s'il y a assez de VRAM
 gradient_accumulation_steps=2, # Taille de lot effective = 8 * 2 = 16
 optim="paged_adamw_32bit", # Économie de VRAM avec Paged Optimizer
 save_steps=100,
 logging_steps=10,
 learning_rate=2e-4,
 fp16=False,
 bf16=True, # Apprentissage en précision mixte (bfloat16)
 max_grad_norm=0.3,
 max_steps=500, # 500 étapes pour les tests. En production, spécifier par nombre d'époques
 warmup_ratio=0.03,
 group_by_length=True,
 lr_scheduler_type="cosine",
)

# 9. Démarrage de l'apprentissage avec SFTTrainer
trainer = SFTTrainer(
 model=model,
 train_dataset=dataset,
 peft_config=peft_config,
 dataset_text_field="text",
 max_seq_length=1024, # Ajuster selon la longueur d'entrée prévue
 tokenizer=tokenizer,
 args=training_args,
)

print("Démarrage de l'entraînement...")
trainer.train()

# 10. Sauvegarde de l'adaptateur LoRA
trainer.model.save_pretrained("./tinyllama-lora-final")
tokenizer.save_pretrained("./tinyllama-lora-final")
print("Entraînement terminé et modèle sauvegardé.")

7. Évaluation des performances et dépannage

Voici les problèmes courants rencontrés lors de l’exécution de l’apprentissage dans un environnement sur site et leurs solutions.

OOM (Out Of Memory) se produit :
- Réduisez per_device_train_batch_size à 1.
- Augmentez gradient_accumulation_steps pour maintenir la taille de lot effective.
- Raccourcissez max_seq_length de 2048 à 1024 ou 512.
La perte (Loss) ne diminue pas / diverge :
- Le taux d’apprentissage (learning_rate) peut être trop élevé. Essayez de le réduire de 2e-4 à environ 5e-5.
- Si vous utilisez Float16 au lieu de Bfloat16, un sous-dépassement de gradient peut se produire. Vérifiez bf16=True.
Des chaînes de caractères mystérieuses sont générées lors de l’inférence :
- Assurez-vous que padding_side="right" est correctement défini. Il est également nécessaire de vérifier si le format du jeu de données (les tokens spéciaux comme <|im_start|>) est cohérent avec celui de la phase de pré-entraînement du modèle de base.

8. Déploiement du modèle après le fine-tuning

Une fois le fine-tuning terminé, ce qui est sauvegardé n’est pas “l’ensemble du modèle de base”, mais seulement “l’adaptateur LoRA (poids différentiels)” de quelques mégaoctets à quelques dizaines de mégaoctets. Pour effectuer une inférence à grande vitesse, ce poids LoRA doit être fusionné (intégré) dans le modèle de base d’origine et exporté en tant que modèle unique.

Script de fusion de modèle

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


import torch
from peft import AutoPeftModelForCausalLM
from transformers import AutoTokenizer

output_dir = "./tinyllama-lora-final"

# Charger le modèle et l'adaptateur en FP16/BF16
model = AutoPeftModelForCausalLM.from_pretrained(
 output_dir,
 device_map="auto",
 torch_dtype=torch.bfloat16
)
tokenizer = AutoTokenizer.from_pretrained(output_dir)

# Fusionner les poids et sauvegarder
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./tinyllama-merged", safe_serialization=True)
tokenizer.save_pretrained("./tinyllama-merged")
print("Modèle fusionné et sauvegardé avec succès !")

Lancement d’un serveur d’inférence ultra-rapide avec vLLM

Pour un déploiement dans un environnement sur site, afin de maximiser la vitesse d’inférence (Jetons par seconde), il est fortement recommandé d’utiliser vLLM ou TGI (Text Generation Inference) au lieu du pipeline standard de Hugging Face. vLLM utilise la technologie PagedAttention pour éviter la fragmentation de la mémoire GPU, améliorant considérablement la capacité de traitement des requêtes simultanées.

Le diagramme Mermaid ci-dessous montre le pipeline allant de l’apprentissage au déploiement du serveur d’inférence.

graph TD A["Données privées brutes"] --> B["Prétraitement et formatage (JSONL)"] B --> C["Fine-Tuning QLoRA (SFTTrainer)"] C --> D["Poids de l'adaptateur LoRA (.safetensors)"] D --> E["Fusion avec le TinyLLaMA 1.1B de base"] E --> F["Modèle fusionné"] F --> G["Déploiement via le serveur vLLM"] G --> H["Point de terminaison API / UI (par ex. Chatbot)"]

Le démarrage du serveur d’API avec vLLM s’effectue avec la commande suivante.

1
2
3
4
5
6


python -m vllm.entrypoints.openai.api_server \
 --model ./tinyllama-merged \
 --host 0.0.0.0 \
 --port 8000 \
 --max-model-len 2048 \
 --dtype bfloat16

Avec cela, un point de terminaison compatible avec l’API OpenAI est construit dans l’environnement sur site, vous permettant d’utiliser l’IA locale de manière sécurisée et à haute vitesse.

9. Conclusion

Dans cet article, nous avons expliqué la méthode de fine-tuning de “TinyLLaMA”, qui offre des performances élevées malgré son poids léger de 1,1B de paramètres, de manière très rapide et économe en mémoire dans un environnement sur site.

LoRA / QLoRA permet un véritable fine-tuning de LLM même sur des GPU grand public.
En exploitant Flash Attention 2 et Gradient Checkpointing, le temps d’apprentissage et la consommation de VRAM sont optimisés à l’extrême.
Le déploiement utilisant vLLM permet d’atteindre un débit élevé même dans des environnements de production.

L’exploitation locale de LLM sur site protège non seulement la confidentialité des données, mais constitue également l’arme ultime pour construire à faible coût une IA spécialisée pour un domaine spécifique (juridique, médical, réglementations internes, etc.). N’hésitez pas à utiliser ce guide comme référence pour développer votre propre TinyLLaMA.

Procédure de développement de petits modèles d'IA (TinyLLaMA, etc.) avec C++

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

Procédure de développement de petits modèles d’IA (TinyLLaMA, etc.) avec C++

Ces dernières années, l’intérêt pour l’exécution locale de grands modèles de langage (LLM) a augmenté rapidement. En particulier, les petits modèles tels que TinyLLaMA (1,1B paramètres) peuvent effectuer des inférences à une vitesse pratique même sur des appareils périphériques aux ressources limitées ou des PC portables standards (y compris les environnements Windows). Bien que le développement utilisant Python et PyTorch soit courant, lorsqu’il s’agit d’atteindre des performances et une efficacité mémoire ultimes, la combinaison du C++ et de « ggml », une bibliothèque de tenseurs basée sur le langage C, est devenue la norme de facto.

Cet article explique en détail la procédure de développement pour construire un moteur d’inférence à partir de zéro (ou comprendre en profondeur l’architecture interne du llama.cpp existant) afin de charger TinyLLaMA et de générer du texte en utilisant C++.

1. Pourquoi C++ et ggml ?

Dans la phase d’apprentissage de l’IA, Python, avec sa flexibilité et son écosystème riche, a un avantage écrasant. Cependant, dans les phases de déploiement ou d’« inférence (Inference) », C++ devient un choix puissant pour les raisons suivantes.

Réduction des surcoûts : Le Global Interpreter Lock (GIL) de Python et les surcoûts d’exécution peuvent être complètement éliminés.
Efficacité de la mémoire et allocation d’arène : L’allocation et la libération de la mémoire pouvant être contrôlées manuellement, les pics imprévisibles causés par le ramasse-miettes (garbage collection) sont évités.
Accès direct au matériel : Il est possible d’appeler directement des fonctions intrinsèques SIMD (Intrinsics) telles que AVX-512, AVX2 et ARM NEON, exploitant ainsi la puissance de calcul du processeur à son maximum.
Élimination des dépendances : ggml est une bibliothèque C/C++ sans aucune dépendance (Zero dependencies), et peut être facilement compilée même dans un environnement MSVC sous Windows tant qu’il y a un compilateur.

2. Vue d’ensemble de l’architecture

Le diagramme Mermaid ci-dessous montre le flux complet du pipeline d’inférence. Il s’agit d’une série de processus commençant par le texte d’entrée de l’utilisateur et se terminant par la génération du jeton suivant.

graph TD A["Texte d'entrée utilisateur"] --> B["Tokeniseur BPE"] B --> C["Tableau d'ID de jetons"] C --> D["Recherche de couche d'intégration"] D --> E["Blocs Transformer"] E --> F["RMSNorm"] F --> G["Couche LM Head"] G --> H["Tableau des logits"] H --> I["Module échantillonneur"] I --> J["ID du jeton suivant"] J --> K["Détokeniseur"] K --> L["Morceau de texte de sortie"] J -.-> |"Ajouter au contexte"| C

Puisqu’il s’agit d’un modèle autorégressif, le jeton produit est à nouveau ajouté au contexte et circule en tant qu’entrée pour la prédiction du jeton suivant (la partie en pointillé du diagramme).

3. Format de modèle et mappage en mémoire (mmap)

Le principal obstacle à la gestion des poids des grands réseaux de neurones est l’I/O disque et la consommation de mémoire. Dans l’implémentation C++ , cela est résolu par le mappage en mémoire (mmap).

3.1 Mécanisme du mappage en mémoire et implémentation sous Windows

L’utilisation de mmap permet de mapper le contenu d’un fichier directement dans l’espace mémoire virtuel du processus.

Zéro copie (Zero-copy) : Les données sont lues directement depuis le disque vers le cache de pages du noyau, évitant ainsi des copies supplémentaires vers l’espace utilisateur.
Chargement à la demande (Page Fault) : Au moment précis où le processeur accède à cette adresse mémoire, un défaut de page (page fault) se produit, et seul le morceau (chunk) requis (généralement 4 Ko) est chargé dans la mémoire physique.

Dans l’environnement Windows, au lieu du mmap de POSIX, on utilise les API Win32 CreateFileMapping et MapViewOfFile.

sequenceDiagram participant OS["Système d'exploitation Windows"] participant RAM["Mémoire physique"] participant App["Application C++"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "Pointeur d'adresse de mémoire virtuelle" App->>App: "Lire les données du tenseur au pointeur" OS->>RAM: "Défaut de page / Charger la page depuis le disque" RAM-->>App: "Données prêtes pour le calcul SIMD"

3.2 Structure binaire du format GGUF

Converti à partir de formats tels que .safetensors de Hugging Face, le GGUF (GPT-Generated Unified Format) est le format ultime pour l’inférence. Il possède la disposition binaire stricte suivante.

Octets magiques (Magic Bytes) : 0x46554747 (GGUF).
Version : Numéro de version du format.
Nombre de tenseurs et de métadonnées : Nombre de tenseurs et de paires clé-valeur de métadonnées.
Métadonnées (Paires Clé-Valeur) : Clés avec préfixe de longueur de chaîne, et valeurs typées.
Infos sur le tenseur : Nom de chaque tenseur, nombre de dimensions, type de données (FP16, Q4_K, etc.), et position de décalage (offset) dans le fichier.
Remplissage (Padding) : Remplissage inséré de sorte que les données du tenseur soient alignées sur une limite spécifique (généralement 32 octets ou 64 octets). Indispensable pour un accès rapide à la mémoire avec les instructions SIMD (en particulier AVX).
Données du tenseur : Tableau des données de poids réelles alignées.

4. Fondements mathématiques de TinyLLaMA et algorithmes C++

TinyLLaMA intègre plusieurs améliorations architecturales avancées pour l’efficacité. Nous expliquons ici les expressions mathématiques pour les implémenter correctement en C++.

4.1 RMSNorm (Root Mean Square Normalization)

Il omet le centrage de la moyenne du LayerNorm et n’effectue que la mise à l’échelle de la variance, ce qui réduit les coûts de calcul.

$$ \text{RMSNorm}(x) = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d} x_i^2 + \epsilon}} \odot \gamma $$

$d$ est le nombre de dimensions, $\gamma$ est le tenseur de mise à l’échelle appris. Lors de l’implémentation en C++, on optimise d’abord en calculant rapidement la somme des carrés du tableau avec _mm256_fmadd_ps d’AVX2, etc., et en la multipliant par la racine carrée inverse (par ex., avec l’instruction _mm256_rsqrt_ps).

4.2 RoPE (Rotary Position Embedding)

C’est une technique qui applique l’information de position du jeton sous forme de rotation (Rotate) dans l’espace tensoriel. Elle peut être considérée comme une rotation sur un plan complexe, appliquant la rotation suivante à la paire de dimensions adjacentes $(x_1, x_2)$ du vecteur $x$.

$$ \text{RoPE}(x, m) = \begin{pmatrix} x_{1} \cos(m\theta) - x_{2} \sin(m\theta) \\ x_{1} \sin(m\theta) + x_{2} \cos(m\theta) \end{pmatrix} $$

Ici, $m$ est l’index de position absolu du jeton, $\theta$ est la fréquence fondamentale précalculée. Dans ggml, elle s’exécute en parallèle simplement en ajoutant l’opérateur ggml_rope pendant la construction du graphe d’inférence.

4.3 Grouped-Query Attention (GQA)

Dans le Multi-Head Attention (MHA) standard, on a le même nombre de têtes (heads) pour Query, Key et Value. Cependant, TinyLLaMA utilise le Grouped-Query Attention (GQA) pour réduire drastiquement la bande passante mémoire et la consommation du cache KV.

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

Dans le GQA, plusieurs têtes Query partagent une seule tête Key/Value. L’implémentation C++ nécessite une opération de diffusion (broadcast) du tenseur KV pour correspondre au nombre de Query avant d’exécuter la multiplication matricielle ggml_mul_mat.

4.4 Fonction d’activation SwiGLU

Dans la couche de réseau à propagation avant (Feed-Forward Network, FFN), SwiGLU est utilisé à la place de GELU.

$$ \text{SwiGLU}(x) = \text{Swish}(x W_{\text{gate}}) \otimes (x W_{\text{up}}) $$ $$ \text{Swish}(z) = z \cdot \sigma(z) = z \cdot \frac{1}{1 + e^{-z}} $$

Dans le graphe de calcul, ceci est exprimé en combinant les opérateurs ggml_silu et ggml_mul.

5. Construction du graphe de calcul avec ggml et gestion de la mémoire

ggml adopte une approche « Define-and-Run », construisant un graphe de calcul statique pour l’inférence et l’évaluant (evaluate) par la suite.

5.1 ggml_context et allocateur d’arène

Le point le plus unique de ggml est l’« allocation d’arène » qui n’effectue aucune allocation de mémoire dynamique (malloc ou new) à l’intérieur de la boucle d’inférence. Lors de l’initialisation, une énorme zone mémoire contiguë (arène) est allouée, et chaque fois que ggml_new_tensor etc. est appelé, le pointeur de cette zone est incrémenté. Une fois qu’une étape d’inférence est terminée, il suffit de réinitialiser le pointeur d’allocation à sa position initiale pour terminer instantanément l’allocation de mémoire pour l’étape d’inférence suivante.

5.2 Exemple concret de construction de graphe

À chaque étape d’inférence, le graphe de calcul suivant est assemblé en mémoire.

graph TD A["ID d'entrée des jetons"] --> B["Recherche d'intégration"] B --> C["ggml_rms_norm"] C --> D["Projections Q / K / V"] D --> E["ggml_rope Positionnel"] E --> F["Stockage du cache KV"] E --> G["Chargement du cache KV"] G --> H["Auto-Attention"] H --> I["Échelle & Softmax"] I --> J["Sortie de l'Attention"] J --> K["Projection de Sortie"] K --> L["Ajout Résiduel"]

6. Quantification (Quantization) et optimisation Windows / SIMD

Traiter TinyLLaMA (1.1B) en FP16 nécessite environ 2,2 Go de mémoire, mais cela peut être considérablement réduit à environ 600 Mo grâce à la quantification 4 bits (comme Q4_K).

6.1 Architecture de quantification par blocs

ggml ne quantifie pas l’intégralité du tenseur uniformément, mais le fait par unités de « blocs ». Dans le format Q4_0, 32 valeurs FP16 sont regroupées en un seul bloc.

Facteur d’échelle (Scale factor) : 1 valeur FP16 (2 octets)
Données quantifiées : 32 valeurs 4 bits (16 octets) Cela minimise l’impact des valeurs aberrantes locales.

6.2 Accélération du produit scalaire avec AVX2

Lors de la compilation pour les derniers processeurs x86 dans un environnement Windows, en utilisant des indicateurs de compilation (flags) tels que /arch:AVX2, le traitement SIMD est effectué via le flux suivant.

Chargement (Load) : Charge les données quantifiées 4 bits depuis la mémoire dans un registre AVX de 256 bits.
Expansion et déballage (Unpack) : Développe les valeurs 4 bits en Int8 ou Int16 avec un masque de bits et des opérations de décalage.
Déqualification (Dequantize) : Multiplie par le facteur d’échelle pour convertir en virgule flottante.
Opération FMA : Exécute en parallèle les opérations de multiplication-addition avec les valeurs d’activation en utilisant _mm256_fmadd_ps (Fused Multiply-Add).

7. Détails d’implémentation du cache KV

Dans la génération autorégressive, le « cache KV » est une fonctionnalité indispensable pour omettre le calcul des Key et Value des jetons passés.

Les points clés lors de l’implémentation en C++ sont les suivants.

Pré-allocation du tenseur : Initialiser un énorme tenseur pour le cache KV correspondant à la longueur de contexte maximale (ex. : 2048 jetons) (FP16 recommandé).
Copie avec décalage (Offset copy) : Lorsque le calcul pour la position du jeton $N$ est effectué, les vecteurs K et V obtenus à cette étape sont stockés à la $N$-ième ligne du tenseur de cache KV en utilisant ggml_cpy etc.
Création de la vue (view) lors de l’Attention : Lors du calcul de l’Attention, créer une « vue » pointant uniquement sur la partie des jetons de 0 à $N$, et la transmettre à la multiplication matricielle.

8. Tokeniseur BPE et décodage

Traite la chaîne d’entrée sous forme d’une séquence d’octets UTF-8 et la compare à un vocabulaire prédéfini. En C++, pour accélérer la recherche dans le vocabulaire, on implémente un algorithme utilisant un Trie (arbre de préfixes) ou une file de priorité.

À partir des logits sortis du LM Head, les probabilités sont mises à l’échelle en utilisant le paramètre de température (Temperature), les candidats sont réduits par des méthodes d’extraction Top-K ou Top-P (Nucleus Sampling), et le jeton suivant final est déterminé à l’aide de nombres aléatoires.

9. Lancement d’un projet C++ (Environnement Windows / PowerShell)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


cmake_minimum_required(VERSION 3.14)
project(TinyLLaMACpp)

set(CMAKE_CXX_STANDARD 17)

# Optimisation pour Windows (MSVC) et configuration du flag AVX2
if(MSVC)
 add_compile_options(/O2 /arch:AVX2 /fp:fast)
 add_link_options(/STACK:8388608)
else()
 add_compile_options(-O3 -march=native -ffast-math)
endif()

add_library(ggml OBJECT ggml/ggml.c ggml/ggml-alloc.c)
target_compile_definitions(ggml PRIVATE GGML_USE_AVX2 GGML_USE_F16C GGML_USE_FMA)

add_executable(main main.cpp)
target_link_libraries(main ggml)

Exemple de commande de build dans PowerShell :

1
2
3
4


mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release

10. Conclusion

Implémenter à partir de zéro un moteur d’inférence pour un petit modèle d’IA comme TinyLLaMA en utilisant C++ et ggml est une excellente occasion de révéler la boîte noire de l’apprentissage profond et d’apprendre la beauté du contrôle matériel de bas niveau. Tout en profitant pleinement de l’essence de la programmation système, telle que le chargement zéro copie à l’aide du mappage mémoire, l’optimisation SIMD et la construction du cache KV, ouvrons la voie à l’avenir de l’IA périphérique (Edge AI).

【Introduction à l'implémentation de RAG】 Comment faire lire vos propres documents à une 'IA locale'

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

Introduction

Ces dernières années, l’évolution des grands modèles de langage (LLM) a été remarquable, et de nombreuses IA telles que ChatGPT et Claude ont imprégné nos vies et nos entreprises. Cependant, les LLM généraux présentent une faiblesse évidente. Ils ne connaissent que les « informations publiques au moment de leur entraînement ». Naturellement, ils ne peuvent pas répondre aux questions concernant des « documents privés » tels que les règlements internes d’une entreprise, les notes personnelles ou les documents de projets non publiés. Si vous essayez de les forcer à répondre, le risque qu’ils génèrent des mensonges plausibles qui ne correspondent pas aux faits (hallucinations) augmente considérablement.

C’est pourquoi l’architecture technologique appelée RAG (Retrieval-Augmented Generation : Génération Augmentée par la Recherche) connaît actuellement une diffusion explosive dans le monde entier. L’utilisation du RAG permet de fournir dynamiquement des connaissances propres au LLM à partir d’une base de données externe, ce qui lui permet de générer des réponses précises et fondées.

De plus, lors du traitement d’informations confidentielles d’entreprise ou personnelles, l’envoi de données à des API basées sur le cloud telles qu’OpenAI est souvent inacceptable du point de vue de la politique de sécurité. C’est là qu’intervient la construction d’un « RAG local » combiné à une IA locale (un LLM qui fonctionne entièrement sur votre propre PC ou serveur sur site).

Dans cet article, nous expliquerons en détail la théorie de base du RAG, les méthodes concrètes d’implémentation d’un RAG local avec Python, le contexte mathématique (le fonctionnement de la recherche vectorielle) et les techniques avancées pour faire fonctionner le système en production.

1. Architecture globale du RAG

Le RAG n’est pas un modèle d’IA unique, mais une architecture système dans laquelle plusieurs composants collaborent. Il se compose principalement de deux phases : la « phase d’ingestion (importation des données) » et la « phase de recherche et de génération (Retrieval & Generation) ».

Le diagramme Mermaid ci-dessous montre la vue d’ensemble du système RAG.

graph TD subgraph "Phase d'ingestion (Préparation)" Doc["Documents propres (PDF, TXT, etc.)"] --> Loader["Chargeur de documents"] Loader --> Splitter["Division du texte (Chunking)"] Splitter --> EmbedModel1["Modèle de plongement (Embedding)"] EmbedModel1 --> VectorDB["Base de données vectorielle"] end subgraph "Phase d'inférence (Lors de la requête de l'utilisateur)" User["Question de l'utilisateur (Requête)"] --> EmbedModel2["Modèle de plongement (Embedding)"] EmbedModel2 --> QueryVector["Vecteur de requête"] QueryVector --> Search["Recherche de similarité (Recherche vectorielle)"] VectorDB --> Search Search --> Context["Extraction des morceaux pertinents (Contexte)"] User --> PromptBuilder["Construction du prompt"] Context --> PromptBuilder PromptBuilder --> LocalLLM["LLM local"] LocalLLM --> Answer["Génération de la réponse finale"] end

Phase d’ingestion (Préparation)

Chargement des documents : Chargez des données non structurées telles que des PDF, des documents Word, des fichiers texte, etc.
Chunking (Division du texte) : Divisez les textes longs en blocs significatifs (chunks) pour les adapter à la limite d’entrée (fenêtre de contexte) du LLM et pour améliorer la précision de la recherche.
Embedding (Vectorisation) : Entrez les chunks divisés dans un modèle de plongement (Embedding Model) et convertissez-les en un tableau de nombres (vecteur) de plusieurs centaines à plusieurs milliers de dimensions.
Enregistrement dans la base de données : Enregistrez les vecteurs convertis et les données textuelles d’origine associées dans une base de données vectorielle (Vector DB).

Phase d’inférence (Lors de l’exécution)

Vectorisation de la requête : Vectorisez la question de l’utilisateur en utilisant le même modèle de plongement que celui de la préparation.
Recherche de similarité : Calculez la similarité entre le vecteur de la requête et les vecteurs des documents dans la base de données, et récupérez les chunks de texte les plus proches sémantiquement (les plus pertinents).
Construction du prompt : Combinez les textes pertinents obtenus comme « contexte (connaissances de base) » avec la question de l’utilisateur pour créer le prompt d’entrée pour le LLM.
Génération de la réponse : Le LLM reçoit le prompt augmenté et génère une réponse basée sur les informations de contexte fournies.

2. Compréhension approfondie de la recherche vectorielle et des plongements (Embeddings)

Le cœur du RAG est la « recherche vectorielle (recherche sémantique) ». Alors que la recherche par mots-clés traditionnelle (comme BM25) est basée sur la correspondance exacte et la fréquence des mots, la recherche vectorielle est basée sur la « similarité de sens ». Par exemple, même des mots différents comme « chien » et « chiot », ou « PC » et « ordinateur » seront trouvés si leur sens est proche.

Qu’est-ce qu’un modèle de plongement (Embedding Model) ?

Un modèle de plongement est un réseau de neurones qui prend un texte en langage naturel en entrée et génère un vecteur dense de longueur fixe (Dense Vector). Les modèles courants (par exemple, text-embedding-3-small ou l’open source multilingual-e5-large) associent le texte à un vecteur de nombres réels de 384 ou 1024 dimensions.

Dans cet espace multidimensionnel (espace latent), l’apprentissage est fait de manière à ce que les textes ayant des significations similaires soient plus proches en termes de distance dans l’espace des coordonnées.

Contexte mathématique du calcul de similarité : Similarité cosinus

Lorsque la base de données vectorielle recherche des documents pertinents, la mesure de distance la plus couramment utilisée est la similarité cosinus (Cosine Similarity). Contrairement à la distance euclidienne (distance spatiale absolue), la similarité cosinus se concentre sur « l’angle entre deux vecteurs ». Étant donné qu’elle est peu affectée par la longueur du texte (la norme du vecteur), elle est très adaptée au calcul de similarité de textes.

Exprimée mathématiquement, la similarité cosinus des vecteurs $\mathbf{A}$ et $\mathbf{B}$ est la suivante :

$$ \text{Cosine Similarity}(\mathbf{A}, \mathbf{B}) = \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}} $$

$\mathbf{A} \cdot \mathbf{B}$ représente le produit scalaire (Dot Product).
$\|\mathbf{A}\|$ représente la norme L2 (longueur) du vecteur $\mathbf{A}$.
$n$ est le nombre de dimensions du vecteur.

La similarité cosinus prend une valeur comprise entre -1 et 1.

Proche de 1 : Les directions des deux vecteurs sont presque les mêmes (les sens sont très similaires)
Proche de 0 : Les deux vecteurs sont orthogonaux (aucun rapport)
Proche de -1 : Les directions des deux vecteurs sont opposées (les sens sont opposés)

Les bases de données vectorielles récentes (Chroma, FAISS, Qdrant, etc.) adoptent un algorithme de recherche des plus proches voisins approximatifs (ANN) appelé HNSW (Hierarchical Navigable Small World), optimisé pour rechercher des documents ayant une similarité cosinus élevée en millisecondes, même à partir de millions de données vectorielles.

3. Pile technologique pour construire un RAG local

Pour construire un RAG local complet qui ne dépend pas du cloud, nous tirerons parti de l’écosystème open source. Voici la pile technologique recommandée.

Modèle de langage (LLM)
- Outils : Ollama ou Llama.cpp
- Modèles : Des modèles ouverts légers et performants tels que Llama-3-8B-Instruct, Gemma-2-9B-It, Qwen2-7B-Instruct. Pour les tâches en japonais, des modèles ajustés pour le japonais comme Llama-3-ELYZA-JP-8B sont appropriés.
Modèle de plongement (Embedding)
- Modèles : intfloat/multilingual-e5-large ou BAAI/bge-m3. Lors de l’exécution locale, il est courant de les télécharger depuis Hugging Face et de les exécuter avec Sentence-Transformers.
Base de données vectorielle (Vector DB)
- ChromaDB : Basée sur Python, son installation est extrêmement simple. Idéale pour le développement local.
- FAISS : Une bibliothèque de recherche vectorielle rapide développée par Meta.
- Qdrant / Milvus : À plus grande échelle et destinées aux environnements de production.
Framework d’orchestration
- LangChain : Le standard de facto pour relier les composants (Chain).
- LlamaIndex : Un framework de connexion de données spécialement conçu pour le RAG.

Cette fois, nous l’implémenterons avec la combinaison la plus simple à introduire : LangChain + ChromaDB + Ollama + HuggingFaceEmbeddings.

4. Tutoriel d’implémentation : Construction complète d’un RAG local avec Python

À partir d’ici, nous allons construire un RAG local tout en écrivant du code Python. Au préalable, veuillez installer Ollama sur votre PC et le lancer en arrière-plan. De plus, téléchargez un modèle sur Ollama (exemple : ollama run llama3).

Étape 1 : Installation des bibliothèques nécessaires

1
2


pip install langchain langchain-community langchain-huggingface
pip install chromadb sentence-transformers pypdf

Étape 2 : Vue d’ensemble du code d’implémentation

Voici un script Python complet pour lire un fichier PDF, le vectoriser et permettre à un LLM local de répondre aux questions.

 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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93


import os
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.llms import Ollama
from langchain_core.prompts import PromptTemplate
from langchain.chains import RetrievalQA

def main():
 # 1. Chargement des documents
 print("Chargement des documents...")
 # Spécifiez le chemin du PDF que vous souhaitez charger
 file_path = "sample_company_policy.pdf"
 loader = PyPDFLoader(file_path)
 documents = loader.load()

 # 2. Division en chunks (Text Splitting)
 # Diviser en tailles appropriées pour ne pas détruire le sens du texte
 text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=500, # Nombre maximum de caractères par chunk
 chunk_overlap=50, # Nombre de caractères qui se chevauchent entre les chunks (empêche la rupture du contexte)
 separators=["\n\n", "\n", "。", "、", " ", ""]
 )
 chunks = text_splitter.split_documents(documents)
 print(f"Divisé en {len(chunks)} chunks.")

 # 3. Initialisation du modèle de plongement (Local HuggingFace Model)
 # Utilisation d'un modèle multilingue performant
 print("Chargement du modèle de plongement...")
 embeddings = HuggingFaceEmbeddings(
 model_name="intfloat/multilingual-e5-large",
 model_kwargs={'device': 'cpu'} # Si vous avez un GPU, 'cuda' ou 'mps'
 )

 # 4. Construction de la base de données vectorielle (Chroma)
 print("Construction de la base de données vectorielle...")
 persist_directory = "./chroma_db"
 vectorstore = Chroma.from_documents(
 documents=chunks,
 embedding=embeddings,
 persist_directory=persist_directory
 )
 # Création du système de recherche (Retriever). Configuration pour récupérer les 3 documents les plus pertinents
 retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

 # 5. Initialisation du LLM local (Ollama)
 print("Connexion au LLM local...")
 # Assurez-vous d'obtenir le modèle au préalable avec 'ollama pull llama3' par exemple
 llm = Ollama(model="llama3")

 # 6. Définition du modèle de prompt
 prompt_template = """Vous êtes un excellent assistant qui connaît bien les règlements de l'entreprise et les informations internes.
Veuillez répondre en détail à la question de l'utilisateur en français, en utilisant uniquement le contexte (informations de base) ci-dessous.
Si vous ne trouvez pas la réponse dans le contexte, ne devinez pas et répondez honnêtement « Je ne sais pas à partir des informations fournies ».

【Contexte】
{context}

【Question】
{question}

【Réponse】:
"""
 PROMPT = PromptTemplate(
 template=prompt_template,
 input_variables=["context", "question"]
 )

 # 7. Construction de la chaîne RAG
 qa_chain = RetrievalQA.from_chain_type(
 llm=llm,
 chain_type="stuff",
 retriever=retriever,
 return_source_documents=True, # Définir s'il faut renvoyer la source d'information
 chain_type_kwargs={"prompt": PROMPT}
 )

 # 8. Exécution de la question
 query = "Veuillez m'expliquer les conditions de remboursement des frais de transport pour le télétravail."
 print(f"\nQuestion : {query}\n")

 result = qa_chain.invoke({"query": query})

 print("【Réponse】")
 print(result['result'])
 print("\n---")
 print("【Sources consultées】")
 for doc in result['source_documents']:
 print(f"- Page {doc.metadata.get('page', 'inconnue')} : {doc.page_content[:50]}...")

if __name__ == "__main__":
 main()

Explication des points clés du code

RecursiveCharacterTextSplitter : C’est le diviseur le plus recommandé pour la division du langage naturel. Il tente de diviser dans l’ordre par paragraphe (\n\n), ligne (\n) et point (。), en gardant les blocs de sens autant que possible tout en respectant la taille spécifiée chunk_size. En définissant chunk_overlap, on évite de perdre des informations aux limites du contexte.
HuggingFaceEmbeddings : intfloat/multilingual-e5-large est un modèle de plongement open source très puissant qui prend en charge plusieurs langues. Sans utiliser d’API cloud (telles que text-embedding-ada-002 d’OpenAI), vous pouvez vectoriser le texte hors ligne en mémoire locale.
ChromaDB : Étant donné qu’il fonctionne en mémoire ou sur le stockage local (basé sur SQLite), il n’est pas nécessaire de mettre en place un serveur de base de données complexe. En spécifiant persist_directory, vous pouvez ignorer le processus de vectorisation lors de la réexécution et charger la base de données à partir du disque.

5. Techniques avancées de RAG (Advanced RAG Techniques)

Bien que le système RAG de base (Naive RAG) construit dans le tutoriel ci-dessus fonctionne, si une précision de réponse élevée est requise en production, l’introduction de techniques avancées telles que les suivantes sera nécessaire.

5.1 Recherche hybride (Hybrid Search)

Bien que la recherche vectorielle excelle à saisir le « sens », elle peut avoir des difficultés avec les recherches de mots-clés exacts tels que des « noms propres spécifiques », des « numéros de modèles de produits » ou des « identifiants d’employés ». Par conséquent, en effectuant parallèlement une recherche sémantique basée sur la recherche vectorielle et une recherche par mot-clé utilisant un algorithme tel que BM25, puis en évaluant et en fusionnant les deux résultats (en utilisant des méthodes telles que Reciprocal Rank Fusion ; RRF), il est possible de réduire considérablement les omissions de recherche.

5.2 Re-classement (Re-ranking)

La recherche vectorielle est rapide, mais elle n’évalue pas nécessairement la pertinence contextuelle exacte du contexte. Un pipeline courant pour améliorer la précision de la recherche est le suivant :

Recherche initiale (First-stage Retrieval) : Récupérez largement et superficiellement environ 20 à 30 chunks pertinents à partir de la base de données vectorielle.
Réévaluation (Re-ranking) : Utilisez un autre modèle d’apprentissage automatique plus lourd appelé Cross-Encoder (par exemple : bge-reranker, etc.) pour entrer la paire de la requête de l’utilisateur et du chunk récupéré, et recalculez le score de pertinence sémantique.
Sélection : Seuls les 3 à 5 premiers résultats ayant les scores les plus élevés sont passés au prompt du LLM en tant que contexte final.

Cette méthode empêche les informations bruyantes non pertinentes d’être transmises au LLM et peut considérablement augmenter la précision (Precision) des réponses.

graph LR Query["Requête"] --> VSearch["Recherche vectorielle (Top 20)"] VSearch --> Reranker["Modèle de re-classement (Cross-Encoder)"] Query --> Reranker Reranker --> TopK["Top 3 de haute précision"] TopK --> LLM["Génération par le LLM"]

5.3 Chunking sémantique et recherche de document parent

Plutôt que de diviser mécaniquement le texte par un nombre fixe de caractères, il existe une technique appelée « Semantic Chunking » qui utilise l’IA pour détecter les changements de sens dans les phrases et les diviser. De plus, dans une technique appelée « Parent Document Retriever (Recherche de document parent) », la vectorisation est effectuée en très petites unités (comme des phrases) pour la recherche afin d’obtenir une recherche très précise. Mais lorsqu’elle est transmise au LLM, c’est le « grand paragraphe d’origine (document parent) » contenant cette phrase qui est fourni, offrant ainsi un contexte suffisant au LLM.

6. Défis et solutions lors de l’exploitation d’un RAG local

Lors de la construction et de l’exploitation d’un RAG dans un environnement local, des obstacles spécifiques existent.

Épuisement de la VRAM (Mémoire vidéo) : Pour faire fonctionner un LLM local à une vitesse pratique (des dizaines de tokens par seconde), le modèle doit être chargé dans la VRAM du GPU. Pour exécuter un modèle de classe 8B en fp16 (virgule flottante 16 bits), environ 16 Go de VRAM sont nécessaires. Cependant, en utilisant des technologies de quantification (Quantization) (techniques de compression en 4 bits ou 8 bits telles que les formats GGUF ou AWQ), il est possible de le faire fonctionner suffisamment vite même avec 8 Go de VRAM (PC de jeu standard, etc.). Llama.cpp et Ollama prennent en charge ces formats quantifiés de manière native.
Limite de la fenêtre de contexte : Si la quantité de contexte récupérée par la recherche est trop importante, elle peut dépasser la limite d’entrée du LLM (limite de tokens), ou le modèle peut oublier les parties intermédiaires de l’information (phénomène de Lost in the middle). L’ajustement du nombre de chunks extraits et la sélection stricte à l’aide de la technologie de re-classement mentionnée ci-dessus sont essentiels.
Gestion de la fraîcheur des données : Lorsque le document source est mis à jour, les vecteurs du document correspondant dans la base de données vectorielle doivent également être mis à jour/supprimés (opérations CRUD). Étant donné que ChromaDB prend en charge les mises à jour basées sur les identifiants de documents, il est pratique de mettre en place un traitement par lots qui gère les valeurs de hachage des fichiers et ne synchronise que les différences.

Conclusion

Le RAG (Génération Augmentée par la Recherche) est un paradigme puissant qui fait évoluer l’IA d’un assistant généraliste typique vers « votre expert exclusif » ou un « expert spécialisé dans les opérations internes ».

Nous avons vu que même pour des exigences hautement confidentielles où les services cloud ne peuvent pas être utilisés, un environnement « RAG local » complet peut être construit relativement facilement en combinant l’écosystème open source comme Ollama, LangChain et ChromaDB.

En vous basant sur la compréhension mathématique de l’espace vectoriel, la division de texte et les approches avancées telles que le re-classement expliquées dans cet article, n’hésitez pas à développer votre propre système d’IA original en utilisant vos propres données. La vitesse d’évolution de l’IA locale est stupéfiante, et le système que vous construisez aujourd’hui peut voir ses performances mises à jour instantanément, simplement en le remplaçant par un modèle léger encore plus intelligent qui sortira demain.

Dans ce blog, nous continuerons à publier des articles approfondis sur la technologie de l’IA et le RAG. Si vous avez des questions ou des commentaires, n’hésitez pas à nous en faire part dans la section des commentaires.

Comparaison complète des API ChatGPT, Gemini et Claude ! Laquelle choisir ?

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

Comparaison complète des API ChatGPT, Gemini et Claude ! Laquelle choisir ?

L’évolution de la technologie de l’IA est remarquable, en particulier dans le domaine des grands modèles de langage (LLM : Large Language Model), où ChatGPT (série GPT) d’OpenAI, Gemini de Google et Claude d’Anthropic se livrent une lutte acharnée pour la suprématie à trois. En 2026, chaque entreprise publie de nouveaux modèles et fonctionnalités d’API en l’espace de quelques mois, voire de quelques semaines, et pour les développeurs ou les architectes informatiques des entreprises, la question de savoir “quelle API intégrer dans un produit” est devenue une décision cruciale qui peut déterminer le succès ou l’échec d’un projet.

Dans cet article, nous comparerons et expliquerons en détail les API de ces 3 principaux fournisseurs d’IA du point de vue des développeurs, sans nous limiter à une simple liste de spécifications, mais en allant jusqu’à la conception de l’architecture, la structure tarifaire détaillée, l’analyse mathématique de la latence, des exemples d’implémentation concrets avec Python et Node.js, et les dernières méthodes d’optimisation des coûts telles que le cache de prompts.

Nous visons à ce que cela devienne un guide complet pour que nos lecteurs puissent sélectionner l’API LLM la plus adaptée à leur propre cas d’utilisation, et construire des applications d’IA évolutives et rentables.

1. Philosophie et concepts de conception de chaque API LLM

Lors du choix technologique, il est d’abord très important de comprendre avec quelle philosophie chaque entreprise construit ses modèles et API.

1.1 OpenAI (ChatGPT)

OpenAI s’est donné pour mission la “réalisation de l’intelligence artificielle générale (IAG)” et continue de tirer vers le haut les standards de facto de l’industrie. Ils fournissent une variété de modèles adaptés à chaque cas d’utilisation, tels que GPT-4o, GPT-4o-mini, et le modèle o1 spécialisé dans le raisonnement. Leur écosystème est le plus mature, et ils possèdent l’abondance de bibliothèques et de documentation la plus importante, qu’elle soit officielle ou non.

1.2 Google (Gemini)

Google met en avant la politique “AI First” et fait de sa scalabilité, qui exploite au maximum sa propre infrastructure (réseau TPU), son arme principale. Gemini 1.5 Pro/Flash possède une fenêtre de contexte impressionnante allant jusqu’à 2 millions de jetons (tokens), ce qui lui permet de traiter d’énormes documents, ainsi que des heures de vidéo et d’audio en une seule fois, ce qui constitue sa principale caractéristique. L’intégration forte avec Google Cloud (Vertex AI) est également très attrayante pour les entreprises.

1.3 Anthropic (Claude)

Anthropic est une entreprise fondée par d’anciens membres d’OpenAI, adoptant une approche unique de sécurité appelée “Constitutional AI” (IA Constitutionnelle). Claude 3.5 Sonnet et Opus recueillent un soutien enthousiaste de la part de nombreux développeurs grâce à leur grande capacité de raisonnement, leur compétence en génération de code, et surtout leurs “conversations naturelles, semblables à celles des humains” et leur “faible taux d’hallucinations”.

2. Comparaison détaillée des spécifications des familles de modèles

Nous comparons les spécifications des modèles phares actuels en 2026.

Fournisseur	Modèle phare	Longueur max du contexte	Principaux atouts	Cas d’utilisation recommandés
OpenAI	GPT-4o	128K	Vitesse, reconnaissance visuelle, prise en charge audio	Applications interactives, tâches d’ordre général
OpenAI	o1-preview	128K	Raisonnement logique avancé, mathématiques, codage	Génération d’algorithmes complexes, recherche
Google	Gemini 1.5 Pro	2,000K	Traitement de textes très longs, multimodal (vidéo, audio)	Analyse de bases de code gigantesques, résumé de vidéos
Google	Gemini 1.5 Flash	2,000K	Faible latence, haut débit, coût extrêmement bas	Traitement en temps réel, traitement par lots de données massives
Anthropic	Claude 3.5 Sonnet	200K	Capacité de codage, génération de textes naturels	Assistance au développement logiciel, support client avancé
Anthropic	Claude 3.5 Haiku	200K	Réponse ultra-rapide, rapport coût-performance	IA Edge (en périphérie), chatbots en temps réel

3. Plongée dans l’architecture : les coulisses des requêtes API

Lorsque l’on appelle une API LLM, quel type de traitement a lieu en arrière-plan ? Pour optimiser les performances, il est nécessaire de comprendre cette architecture.

Le diagramme Mermaid ci-dessous montre la vue d’ensemble, depuis l’envoi de la requête API par le client jusqu’au retour des jetons (tokens) en streaming.

graph TD A["Application Client"] -->|HTTP/REST or gRPC| B["Passerelle API"] B --> C["Équilibreur de charge"] C --> D["Cluster d'inférence"] D --> E["Tokeniseur (BPE / SentencePiece)"] E --> F["Cache KV & Mécanisme d'attention"] F --> G["Blocs Transformer (Passe avant)"] G --> H["Couche de sortie (Logits)"] H --> I["Échantillonneur (Temperature, Top-p, Top-k)"] I --> J["Détokeniseur"] J -->|Réponse en streaming (Morceau)| A

3.1 Algorithmes de Tokenisation

Le texte saisi dans l’API est divisé en interne en unités appelées “jetons” (tokens).

OpenAI (tiktoken) : Adopte l’encodage Byte-Pair Encoding (BPE). Il offre une compression extrêmement efficace, en particulier en anglais, mais a tendance à gonfler le nombre de jetons pour les langues non alphabétiques comme le japonais.
Google (Gemini) : Adopte SentencePiece (Unigram Language Model). Il est performant en multilingue et tend à pouvoir représenter des textes, même en japonais, avec un nombre de jetons relativement faible.
Anthropic (Claude) : Utilise une version personnalisée de BPE. Le support multilingue a été renforcé, et depuis Claude 3, l’efficacité des jetons pour le japonais a également été considérablement améliorée.

4. Analyse mathématique de la latence et des performances

Dans les applications en temps réel, la latence affecte directement l’expérience utilisateur (UX). La latence d’une API LLM, $T_{total}$, peut être modélisée mathématiquement de la manière suivante.

$$ T_{total} = T_{network} + T_{TTFT} + (N \times T_{TPOT}) $$

Ici, chaque variable a la signification suivante :

$T_{network}$ : Temps d’aller-retour du réseau (RTT).
$T_{TTFT}$ (Time To First Token) : Temps nécessaire pour générer le premier jeton. Dépend fortement du coût de calcul de l’attention, qui est proportionnel au carré de la longueur du prompt (nombre de jetons d’entrée).
$N$ : Nombre total de jetons de sortie.
$T_{TPOT}$ (Time Per Output Token) : Temps de génération par jeton. Étant un modèle autorégressif, il est calculé en série en fonction des sorties précédentes.

4.1 Complexité du mécanisme d’auto-attention

La complexité de calcul de l’auto-attention (Self-Attention) dans l’architecture Transformer augmente de manière quadratique par rapport à la longueur de la séquence d’entrée $L$.

$$ \text{Complexity} = O(L^2 \cdot d) $$

Ici, $d$ est la dimension du vecteur de plongement (embedding). En raison de cette contrainte, $T_{TTFT}$ se dégrade généralement très rapidement lorsque le prompt s’allonge. Cependant, Gemini 1.5 de Google adopte des architectures d’optimisation innovantes telles que “Ring Attention” et “Block-wise Compute”, réussissant à générer le premier jeton en un temps raisonnable (de quelques secondes à quelques dizaines de secondes) même avec une entrée massive de 2 millions de jetons.

5. Structure tarifaire et stratégies d’optimisation des coûts

Le coût de l’API est essentiellement calculé en fonction du nombre de jetons d’entrée et de sortie.

$$ Cost = (Tokens_{in} \times Rate_{in}) + (Tokens_{out} \times Rate_{out}) $$

Toutefois, de nouveaux mécanismes ont été introduits dans les API récentes pour réduire considérablement les coûts.

5.1 Cache de prompts (Prompt Caching)

L’envoi de très longs prompts système ou d’une grande quantité de documents récupérés par RAG à chaque fois entraîne des coûts énormes. Pour y remédier, chaque entreprise propose une fonction de mise en cache.

Avec Anthropic (Claude) et Google (Gemini), il est possible de réduire considérablement les coûts d’entrée (jusqu’à 90 %) en mettant en cache des blocs de texte spécifiques.

Le modèle de coût lors de l’utilisation du cache est le suivant :

$$ Cost_{cached} = (Tokens_{cache\_write} \times Rate_{cache\_write}) + (Tokens_{cache\_read} \times Rate_{cache\_read}) + (Tokens_{out} \times Rate_{out}) $$

Ici, $Rate_{cache\_read}$ est fixé à environ 10 % à 25 % du $Rate_{in}$ habituel. Cela permet d’exploiter un chatbot à moindre coût tout en maintenant en permanence une base de code de plusieurs dizaines de milliers de lignes en tant que connaissances contextuelles.

5.2 API par lots (Batch API)

Pour les tâches ne nécessitant pas de temps réel (analyse de journaux, classification de grandes quantités de données, etc.), OpenAI et Anthropic fournissent une API par lots (Batch API). C’est un mécanisme puissant qui permet d’envoyer des requêtes en groupe et de recevoir les résultats dans les 24 heures, à la moitié du prix normal de l’API (50 % de réduction).

6. Comparaison de l’expérience développeur (DX) et des SDK

Du point de vue de l’efficacité du développement, nous comparons les SDK (Software Development Kit) fournis par chaque entreprise.

6.1 API OpenAI

C’est la plus largement utilisée et la prise en charge par les bibliothèques tierces (LangChain, LlamaIndex, etc.) est la plus rapide. De plus, la fonctionnalité de sorties structurées (Structured Outputs) garantit le retour de réponses respectant à 100 % le schéma JSON, ce qui facilite grandement l’intégration des systèmes.

6.2 API Anthropic (Claude)

L’interface de son SDK est raffinée et réputée très facile à utiliser, notamment au niveau des définitions de types TypeScript. La structure de l’API Message est particulièrement intuitive, permettant d’écrire simplement des requêtes multimodales incluant plusieurs images.

6.3 API Google Gemini

Il existe deux types d’accès : via Google Cloud Vertex AI et via AI Studio (Google Gen AI SDK), ce qui peut sembler un peu confus pour les débutants. Cependant, le SDK Vertex AI destiné aux entreprises est entièrement intégré au système de gestion des identités et des accès (IAM) de GCP, permettant de mettre en place un environnement de développement sécurisé.

7. Pratique ! Implémentation d’un test d’intégration de plusieurs API avec Python

Ici, nous allons utiliser Python pour implémenter un script qui envoie des requêtes asynchrones simultanées aux trois API (OpenAI, Anthropic, Gemini) et compare leurs latences.

 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


import asyncio
import time
import os
from openai import AsyncOpenAI
from anthropic import AsyncAnthropic
import google.generativeai as genai

# Initialisation des clients
openai_client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
anthropic_client = AsyncAnthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))
genai.configure(api_key=os.environ.get("GEMINI_API_KEY"))

prompt = "Veuillez expliquer de manière simple pour les débutants les bases de l'informatique quantique et son impact sur la cryptographie actuelle."

async def fetch_openai():
 start_time = time.time()
 response = await openai_client.chat.completions.create(
 model="gpt-4o",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "OpenAI (GPT-4o)", elapsed, response.choices[0].message.content

async def fetch_anthropic():
 start_time = time.time()
 response = await anthropic_client.messages.create(
 model="claude-3-5-sonnet-20240620",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "Anthropic (Claude 3.5 Sonnet)", elapsed, response.content[0].text

async def fetch_gemini():
 start_time = time.time()
 model = genai.GenerativeModel('gemini-1.5-pro')
 # Utilisation de la méthode asynchrone du SDK Python Gemini
 response = await model.generate_content_async(prompt)
 elapsed = time.time() - start_time
 return "Google (Gemini 1.5 Pro)", elapsed, response.text

async def main():
 print("Envoi de requêtes à chaque API LLM...")

 # Exécution des 3 API en parallèle
 results = await asyncio.gather(
 fetch_openai(),
 fetch_anthropic(),
 fetch_gemini()
 )

 for provider, latency, text in results:
 print(f"--- {provider} ---")
 print(f"Latency: {latency:.2f} seconds")
 print(f"Response (Excerpt): {text[:100]}...\n")

if __name__ == "__main__":
 asyncio.run(main())

En exécutant ce script, vous pouvez facilement mesurer quel modèle répond le plus rapidement (en minimisant $T_{total}$) dans un environnement réseau réel.

8. Implémentation du Tool Calling (Function Calling) avec Node.js

Pour qu’un LLM fonctionne non pas comme un simple chatbot, mais comme un “agent IA” qui interagit avec des systèmes externes, le Tool Calling (ou Function Calling) est indispensable. Voici un exemple en Node.js (TypeScript) où l’API OpenAI est invitée à appeler une API météo.

 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


import OpenAI from "openai";

const openai = new OpenAI({
 apiKey: process.env.OPENAI_API_KEY,
});

async function runAgent() {
 const tools = [
 {
 type: "function",
 function: {
 name: "get_weather",
 description: "Obtient la météo actuelle pour la ville spécifiée.",
 parameters: {
 type: "object",
 properties: {
 location: {
 type: "string",
 description: "Nom de la ville (ex: Tokyo, New York)",
 },
 },
 required: ["location"],
 },
 },
 },
 ];

 const response = await openai.chat.completions.create({
 model: "gpt-4o",
 messages: [{ role: "user", "content": "Quel temps fait-il à Tokyo aujourd'hui ? Aurai-je besoin d'un parapluie ?" }],
 tools: tools,
 tool_choice: "auto",
 });

 const message = response.choices[0].message;

 if (message.tool_calls) {
 const toolCall = message.tool_calls[0];
 console.log(`Le LLM a demandé un appel d'outil : Nom de la fonction = ${toolCall.function.name}`);

 const args = JSON.parse(toolCall.function.arguments);
 console.log(`Arguments : ${args.location}`);

 // Implémentez ici la logique pour appeler l'API météo réelle (ex: OpenWeatherMap)
 // const weather = await fetchWeatherFromAPI(args.location);

 // Vous pouvez passer le résultat obtenu au LLM pour générer la réponse finale
 }
}

runAgent().catch(console.error);

Claude 3.5 Sonnet et Gemini 1.5 Pro disposent également de fonctionnalités de Tool Calling équivalentes. Bien qu’il y ait quelques différences dans la façon dont les schémas sont définis, le flux de base est commun.

9. RAG vs Fenêtre de contexte étendue : Que faut-il adopter ?

Actuellement, l’un des plus grands débats en matière d’architecture d’IA d’entreprise est de savoir s’il faut “utiliser RAG (génération augmentée par la recherche) pour intégrer des connaissances externes, ou tout confier à une fenêtre de contexte massive (Long Context)”.

Avantages et défis de RAG (Retrieval-Augmented Generation)

Avantages : Faible coût (car seuls les morceaux nécessaires sont placés dans le prompt), facilité d’identification des preuves (sources) de la réponse.
Défis : Comme cela dépend de la précision de la recherche sémantique, cette méthode n’est pas adaptée aux tâches de raisonnement complexe où le contexte est dispersé dans plusieurs documents (par exemple : “Analysez chronologiquement la cause fondamentale du retard du projet A à partir des procès-verbaux de toutes les réunions de l’année dernière”).

Contexte étendu (Long Context, comme les 2 millions de jetons de Gemini 1.5 Pro)

Avantages : Aucune perte d’information due à la recherche. Même dans le test de “chercher une aiguille dans une botte de foin” (Needle In A Haystack : NIAH), Gemini 1.5 Pro et Claude 3.5 Sonnet peuvent extraire des informations avec une précision de plus de 99 %.
Défis : La consommation de jetons devient massive et fait grimper les coûts, et la latence ($T_{TTFT}$) augmente.

Conclusion : La meilleure pratique en 2026 est l’“approche hybride”. La conception dominante consiste à utiliser le RAG avec une base de données vectorielle pour les questions-réponses quotidiennes, et à utiliser un contexte étendu avec cache de prompts pour les tâches spécialisées nécessitant une analyse complexe ou la révision d’un code complet.

10. Comparaison des capacités de traitement multimodal

Dans les applications d’IA de nouvelle génération, il est nécessaire de comprendre directement non seulement le texte, mais aussi les images, le son et les vidéos.

sequenceDiagram participant User as "Utilisateur" participant Client as "Application Frontend" participant API as "API LLM (Multimodal)" User->>Client: Téléchargement Vidéo & Prompt Texte Client->>API: Envoi d'Octets Vidéo/URI + Texte Note over API: Découpage vidéo & séparation audio Note over API: Modèle d'Embedding Multimodal API-->>Client: Retour de Résumé Textuel & Horodatages Client-->>User: Affichage des Insights

OpenAI (GPT-4o) : La précision de la reconnaissance d’images est extrêmement élevée et elle excelle dans la lecture de dessins manuscrits ou de graphiques complexes. En outre, la conversation vocale native à très faible latence (quelques centaines de millisecondes) à l’aide de l’API Realtime est également très puissante.
Google (Gemini 1.5 Pro) : Surpasse les autres en matière d’analyse vidéo. Vous pouvez insérer directement un fichier vidéo d’une heure (images + audio) et il est capable de répondre à des questions précises telles que “Quel est le titre du document tenu par la personne visible sur le bord droit de l’écran à 12 minutes 45 secondes ?”.
Anthropic (Claude 3.5 Sonnet) : Ses capacités de reconnaissance d’images (Vision) sont au même niveau que GPT-4o et très remarquables. Il fait preuve d’une force inégalée dans l’aide au développement frontend, par exemple en lui donnant une capture d’écran de l’interface utilisateur et en demandant : “Générez le code du composant React pour cet écran”.

11. Sécurité et conformité de niveau entreprise

Lorsque les entreprises utilisent des API LLM dans un environnement de production, leurs principales préoccupations sont “nos données seront-elles utilisées pour former l’IA ?” et “répondent-elles aux exigences de conformité ?”.

Les trois sociétés déclarent explicitement qu’elles n’utilisent pas les données (prompts et réponses) envoyées via l’API pour former leurs modèles (Zero Data Retention / No Training on Customer Data) (*cela diffère pour les interfaces de discussion Web gratuites destinées aux consommateurs).

Si un niveau de sécurité encore plus élevé est requis :

OpenAI : En passant par Azure OpenAI Service, vous pouvez bénéficier de la sécurité de niveau entreprise de Microsoft, de son SLA et d’une connexion réseau fermée via Azure Private Link.
Google : En passant par Google Cloud Vertex AI, il est possible d’avoir une isolation réseau stricte en utilisant VPC Service Controls et une protection des données via CMEK (clés de chiffrement gérées par le client).
Anthropic : En l’utilisant via AWS Bedrock ou Google Cloud Vertex AI, vous pouvez vous appuyer sur l’infrastructure de sécurité robuste de ces fournisseurs de cloud.

12. Conclusion : Le guide de sélection ultime par cas d’utilisation

Bien que nous ayons effectué une comparaison sous plusieurs angles jusqu’à présent, la conclusion finale à la question “laquelle choisir ?” dépend de votre cas d’utilisation.

Développement de logiciels complexes, génération de code et raisonnement avancé : 👑 Gagnant : Claude 3.5 Sonnet (Anthropic) Il offre actuellement les meilleures performances dans la compréhension du contexte du code, la refactorisation et la création de textes naturels et humains. La facilité d’utilisation de l’API et l’efficacité de ses coûts grâce au cache de prompts sont également exceptionnelles.
Analyse de documents ultra-longs et traitement par lots de vidéo/audio : 👑 Gagnant : Gemini 1.5 Pro (Google) La fenêtre de contexte de 2 millions de jetons est une arme unique. Il n’y a pas de meilleur choix que Gemini pour les tâches nécessitant une vue d’ensemble des données, telles que l’analyse d’un manuel PDF de plusieurs centaines de pages ou le résumé d’un long enregistrement de réunion.
Polyvalence, vitesse d’exécution et sorties structurées stables (JSON) : 👑 Gagnant : GPT-4o / GPT-4o-mini (OpenAI) Il accomplit toutes sortes de tâches sans difficulté et bénéficie de la prise en charge d’outils tiers la plus abondante. L’écosystème OpenAI est indispensable lorsque vous avez besoin d’un parsing JSON infaillible utilisant les sorties structurées (Structured Outputs) ou d’un raisonnement logique très avancé avec le modèle o1.

Recommandation pour le routage multi-modèles

Plutôt que de s’appuyer sur une seule API (vendor lock-in), la tendance future est l’architecture de “routage LLM” qui bascule dynamiquement d’un modèle à l’autre en fonction de la difficulté et de l’importance de la tâche. Par exemple, vous pouvez répondre aux questions simples des utilisateurs avec des modèles peu coûteux et rapides comme GPT-4o-mini ou Gemini 1.5 Flash, et ne basculer la tâche sur Claude 3.5 Sonnet que si un traitement complexe est jugé nécessaire, permettant d’atteindre un équilibre optimal entre coût et performances.

L’évolution de l’IA ne s’arrête jamais. Comprenez profondément les forces et faiblesses de chaque API ainsi que les caractéristiques de leur architecture, et construisez des applications d’IA flexibles et évolutives.

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.