GGML on kenji.blog

Fini Python ! J'ai construit un moteur d'inférence d'IA uniquement en C++

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

1. Introduction : Pourquoi abandonner Python et créer un moteur d’inférence d’IA en C++ ?

Dans le développement moderne de l’IA, Python est le standard de facto. Grâce à des frameworks puissants tels que PyTorch et TensorFlow, il est possible de construire, d’entraîner et d’inférer des réseaux de neurones complexes en quelques lignes de code. Cependant, derrière ces frameworks, des langages de bas niveau comme le C++ et CUDA gèrent les opérations de calcul lourdes. Python ne sert finalement que de « colle » (glue).

Alors, pourquoi s’embêter à exclure Python et à créer un moteur d’inférence d’IA uniquement en C++ ? Il y a plusieurs raisons fortes à cela.

Performances extrêmes et faible latence : Vous pouvez complètement éliminer les surcoûts liés au GIL (Global Interpreter Lock) de Python et au typage dynamique. Particulièrement dans les systèmes nécessitant un temps réel, un délai de quelques millisecondes peut être fatal.
Facilité de déploiement : Il est très difficile de configurer un environnement Python (avec d’énormes bibliothèques et l’enfer des dépendances) sur la machine de l’utilisateur final. Avec C++, il vous suffit de distribuer un seul exécutable binaire lié statiquement (un .exe ou un binaire ELF).
Prise en charge des périphériques Edge : Dans des environnements aux ressources très limitées comme les smartphones, les systèmes embarqués ou le Raspberry Pi, il n’y a pas la marge pour exécuter un runtime Python consommant plusieurs gigaoctets de mémoire.
Contrôle direct du matériel : C++ permet un contrôle de bas niveau tel que le moment de l’allocation de la mémoire, l’utilisation explicite d’instructions SIMD et l’optimisation des transferts de mémoire avec le GPU.

Dans cet article, fortement inspirés par l’architecture de la bibliothèque « GGML » développée par Georgi Gerganov, nous plongerons dans les profondeurs techniques pour expliquer le processus de construction à partir de zéro d’un moteur d’inférence permettant d’exécuter de grands modèles de langage (LLM) uniquement avec du C++.

2. Vue d’ensemble de l’architecture du moteur d’inférence

Le processus d’inférence de l’IA est essentiellement une « série continue d’énormes calculs matriciels ». Afin d’exécuter cela efficacement, un moteur d’inférence doit être composé des éléments suivants.

graph TD A["Données d'entrée (Tokens/Images)"] --> B["Gestion des Tenseurs"] B --> C["Graphe de Calcul (DAG)"] C --> D["Memory Arena & Allocateur"] C --> E["Planificateur & Pool de Threads"] E --> F["Backend CPU (AVX2/ARM NEON)"] E --> G["Backend GPU (CUDA/Metal)"] F --> H["Résultats de Sortie"] G --> H

Gestion des Tenseurs (Tensor Management) : Gère la structure de données des tableaux multidimensionnels et le pas (Stride) pour chaque dimension.
Graphe de Calcul (Computation Graph) : Représente les opérations de chaque couche du réseau de neurones sous la forme d’un graphe orienté acyclique (DAG).
Memory Arena : Un mécanisme de gestion de mémoire pré-allouée pour éviter le surcoût de l’allocation dynamique de mémoire (malloc ou new).
Backend : Implémentations d’opérations (kernels) optimisées pour un matériel spécifique, tel que CPU ou GPU.

Nous allons assembler tout cela en utilisant les puissantes fonctionnalités du C++ (templates, arithmétique de pointeurs, RAII, etc.).

3. Le secret de la gestion de la mémoire : Memory Arena et alignement SIMD

La gestion de la mémoire dans un moteur d’inférence est l’un des éléments les plus critiques, directement lié aux performances. Lors de l’inférence, en particulier lors du passage à travers chaque couche d’un modèle Transformer, un nombre massif de tenseurs intermédiaires est généré. Si vous allouez et libérez cela avec un malloc standard à chaque fois, la fragmentation du tas et les changements de contexte de l’OS entraîneront des baisses de vitesse fatales.

C’est pourquoi nous adoptons l’approche du « Memory Arena ». Il s’agit d’une méthode où la quantité maximale de mémoire requise est calculée (ou fixée) et allouée en une seule fois au début de l’inférence, puis la mémoire est découpée en incrémentant simplement un pointeur.

3.1 L’importance de l’alignement

Les processeurs modernes prennent en charge les instructions SIMD (Single Instruction, Multiple Data). Il s’agit d’AVX2/AVX-512 pour Intel/AMD et de NEON pour ARM. Ces instructions traitent des données de 256 bits (32 octets) ou de 512 bits (64 octets) à la fois, mais la mémoire de données traitée doit être alignée sur une limite d’octets spécifique (généralement 32 octets ou 64 octets).

Voici un exemple d’implémentation C++ d’un Memory Arena qui prend en compte l’alignement.

 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


#include <cstdint>
#include <cstddef>
#include <stdexcept>
#include <iostream>

struct MemoryArena {
 size_t size;
 size_t offset;
 uint8_t* data;

 MemoryArena(size_t size) : size(size), offset(0) {
 // Utilise posix_memalign pour POSIX et _aligned_malloc pour Windows
#ifdef _WIN32
 data = static_cast<uint8_t*>(_aligned_malloc(size, 64));
#else
 if (posix_memalign(reinterpret_cast<void**>(&data), 64, size) != 0) {
 throw std::bad_alloc();
 }
#endif
 }

 ~MemoryArena() {
#ifdef _WIN32
 _aligned_free(data);
#else
 free(data);
#endif
 }

 void* allocate(size_t bytes, size_t alignment = 64) {
 // Calcul de l'alignement (trouver le padding)
 size_t pad = (alignment - (offset % alignment)) % alignment;
 if (offset + pad + bytes > size) {
 throw std::runtime_error("OOM: MemoryArena out of memory");
 }
 offset += pad;
 void* ptr = data + offset;
 offset += bytes;
 return ptr;
 }

 void reset() {
 offset = 0; // La libération de mémoire consiste simplement à réinitialiser le pointeur (O(1))
 }
};

Ainsi, lors de la création d’un tenseur, la mémoire est toujours obtenue via cette arena. À la fin de chaque étape d’inférence (comme la génération d’un token), il suffit d’appeler reset() pour réutiliser instantanément la mémoire.

4. Structures de données des Tenseurs et la magie du Stride

Un tenseur est un concept qui généralise un scalaire, un vecteur et une matrice. Ce qui est important dans l’implémentation, c’est que bien que les données réelles soient disposées en mémoire comme un tableau continu unidimensionnel, elles possèdent le concept de « Stride » (pas) pour être interprétées de manière multidimensionnelle.

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


enum class DataType {
 FP32,
 FP16,
 INT8, // Pour la quantification
 INT4 // Pour la quantification
};

struct Tensor {
 int n_dims; // Nombre de dimensions
 int64_t ne[4]; // Nombre d'éléments par dimension (Number of Elements)
 size_t nb[4]; // Stride pour chaque dimension en octets (Number of Bytes)
 DataType type; // Type de données
 void* data; // Pointeur vers la charge utile (payload)

 // Pour le graphe de calcul
 enum OpType op;
 Tensor* src0;
 Tensor* src1;
};

Le stride nb[i] représente la distance en octets en mémoire entre des éléments adjacents dans la dimension i. Par exemple, si une matrice de $M \times N$ éléments (FP32, 4 octets par élément) est stockée en Row-Major (priorité aux lignes), le stride sera le suivant :

nb[0] = 4 (octets) : Déplacement dans le sens des colonnes
nb[1] = $N \times 4$ (octets) : Déplacement dans le sens des lignes

En utilisant cela, des opérations telles que « Transposer » (Transpose) ou la création de « Vues » (View) peuvent être réalisées simplement en échangeant les valeurs du stride, sans impliquer de copie de mémoire. C’est très élégant et rapide.

5. Construction du Graphe de Calcul (DAG) et Évaluation Paresseuse

À l’instar de PyTorch et d’autres, notre moteur d’inférence adopte également une évaluation paresseuse (Lazy Evaluation) proche du « Define-by-Run ». Autrement dit, le calcul n’est pas effectué au moment où la fonction d’opération est appelée ; seul le graphe (les dépendances entre les nœuds) est construit.

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


Tensor* tensor_add(MemoryArena& arena, Tensor* a, Tensor* b) {
 Tensor* out = create_tensor(arena, a->type, a->n_dims, a->ne);
 out->op = OpType::ADD;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Tensor* tensor_mul_mat(MemoryArena& arena, Tensor* a, Tensor* b) {
 // b est souvent transposé
 int64_t ne[2] = { a->ne[0], b->ne[1] };
 Tensor* out = create_tensor(arena, a->type, 2, ne);
 out->op = OpType::MUL_MAT;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Le flux du processus d’inférence est le suivant :

graph LR A["Définir les Tenseurs"] --> B["Construire le Graphe via les Opérations"] B --> C["Tri Topologique"] C --> D["Allouer la Mémoire pour les Sorties"] D --> E["Exécuter les Nœuds dans l'Ordre"]

Lors de l’évaluation du graphe (passage avant ou Forward Pass), le tri topologique est utilisé pour exécuter les nœuds dans l’ordre, à partir de ceux qui n’ont aucune dépendance. S’il s’agit uniquement d’inférence, la gestion de la mémoire est extrêmement simple car il n’est pas nécessaire de conserver les gradients pour la rétropropagation (Backpropagation).

6. Le cœur des mathématiques et de l’optimisation : Produit Matriciel (GEMM)

Plus de 90 % de la charge de calcul de l’inférence d’IA est consacrée à la multiplication matricielle (GEMM : General Matrix Multiply). Qu’il s’agisse du mécanisme d’attention, qui est le cœur des modèles Transformer, ou des réseaux feed-forward (FFN), tout se résume à d’énormes produits matriciels.

Le produit $C = A B$ (taille $M \times N$) de deux matrices $A$ (taille $M \times K$) et $B$ (taille $K \times N$) est exprimé mathématiquement comme suit :

$$ C_{i,j} = \sum_{k=0}^{K-1} A_{i,k} \cdot B_{k,j} $$

Si vous implémentez cela de manière naïve avec une triple boucle, les défauts de cache (cache misses) seront fréquents et les performances seront médiocres.

6.1 Blocage de cache (Cache Blocking) sur le CPU et optimisation SIMD

La strategy de base pour accélérer GEMM sur le CPU est la suivante :

Tiling de boucle (Blocage de cache) : Divisez la matrice en petits blocs qui tiennent dans le cache L1/L2 et effectuez les calculs.
Emballage des données (Packing) : Réorganisez les données en interne de sorte que le modèle d’accès à la mémoire soit continu.
Utilisation de SIMD : Utilisez des instructions FMA (Fused Multiply-Add) comme _mm512_fmadd_ps dans AVX-512 pour effectuer de nombreuses opérations de multiplication-addition en un seul cycle d’horloge.

Voici un exemple simplifié de produit scalaire vectoriel (Dot Product) utilisant des intrinsèques C++ et SIMD.

 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


#include <immintrin.h> // Pour les instructions AVX

// Produit scalaire rapide pour FP32 en utilisant AVX2
float dot_product_avx2(const float* a, const float* b, int n) {
 __m256 sum256 = _mm256_setzero_ps();
 int i = 0;

 // Traitement de 8 éléments à la fois (256 bits = 32 octets = 8 * 4 octets)
 for (; i <= n - 8; i += 8) {
 __m256 va = _mm256_loadu_ps(a + i);
 __m256 vb = _mm256_loadu_ps(b + i);
 // Instruction FMA : sum256 = va * vb + sum256
 sum256 = _mm256_fmadd_ps(va, vb, sum256);
 }

 // Addition horizontale des valeurs dans le registre SIMD
 float result[8];
 _mm256_storeu_ps(result, sum256);
 float dot = result[0] + result[1] + result[2] + result[3] +
 result[4] + result[5] + result[6] + result[7];

 // Traitement du reste
 for (; i < n; ++i) {
 dot += a[i] * b[i];
 }
 return dot;
}

Même avec cette petite amélioration, vous pouvez obtenir une vitesse plusieurs fois à des dizaines de fois supérieure à celle d’une implémentation naïve.

7. Franchir le mur matériel : Intégration des backends CUDA et Metal

Une implémentation purement C++ fonctionnera raisonnablement bien sur un CPU, mais pour exécuter des modèles gigantesques comme les LLM à des vitesses pratiques (par exemple, générer plus de 20 tokens par seconde), la puissance de calcul parallèle d’un GPU est indispensable. Par conséquent, nous introduisons une couche d’abstraction de backend dans notre moteur.

7.1 Abstraction du Backend

En utilisant le polymorphisme C++, nous permettons de changer l’exécuteur (Executor) des opérations.

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


class Backend {
public:
 virtual ~Backend() = default;
 virtual void alloc_buffer(Tensor* t) = 0;
 virtual void free_buffer(Tensor* t) = 0;
 virtual void copy_to_device(Tensor* t) = 0;
 virtual void copy_to_host(Tensor* t) = 0;

 // Exécution de diverses opérations
 virtual void compute_add(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
 virtual void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
};

7.2 Implémentation du backend NVIDIA CUDA

Pour exploiter les GPU NVIDIA, nous implémentons un backend en utilisant les extensions CUDA C++. Bien qu’il soit possible d’écrire vos propres kernels, il est préférable d’utiliser « cuBLAS » pour la multiplication matricielle, car c’est la bibliothèque la plus performante fournie par NVIDIA.

 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


#include <cublas_v2.h>
#include <cuda_runtime.h>

class CUDABackend : public Backend {
private:
 cublasHandle_t handle;

public:
 CUDABackend() {
 cublasCreate(&handle);
 }

 ~CUDABackend() {
 cublasDestroy(handle);
 }

 void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) override {
 // Dans CUDA, la valeur par défaut est Column-Major, il faut donc faire attention aux paramètres
 const float alpha = 1.0f;
 const float beta = 0.0f;

 int m = src0->ne[0];
 int k = src0->ne[1];
 int n = src1->ne[1]; // En supposant que src1 est transposé

 cublasSgemm(handle, CUBLAS_OP_T, CUBLAS_OP_N,
 m, n, k,
 &alpha,
 (const float*)src0->data, k,
 (const float*)src1->data, k,
 &beta,
 (float*)dst->data, m);
 cudaDeviceSynchronize();
 }
};

Le transfert de données (cudaMemcpy) entre la mémoire CUDA et la mémoire hôte (CPU) est très lourd, il est donc essentiel de concevoir le système pour conserver autant que possible tous les poids (tenseurs de poids) et les tenseurs intermédiaires dans la VRAM pendant l’inférence.

7.3 Backend Apple Silicon (Metal)

Ces dernières années, les puces M1/M2/M3 (Apple Silicon) pour Mac sont devenues excellentes en tant que machines d’inférence d’IA. La raison en est la « mémoire unifiée ». Puisque le CPU et le GPU partagent la même zone mémoire, les transferts de mémoire coûteux entre l’hôte et le périphérique via le bus PCIe, comme avec CUDA mentionné précédemment, sont complètement inutiles.

Pour appeler Metal depuis C++, vous pouvez utiliser l’Objective-C++ (fichiers .mm) comme pont, ou utiliser la bibliothèque metal-cpp. Nous utiliserons des Compute Shaders de Metal (écrits dans un style proche du C++ dans des fichiers .metal) pour écrire nos kernels.

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


// Shader Metal (kernel.metal)
#include <metal_stdlib>
using namespace metal;

kernel void mul_mat_kernel(
 device const float* A [[buffer(0)]],
 device const float* B [[buffer(1)]],
 device float* C [[buffer(2)]],
 constant uint3& dims [[buffer(3)]],
 uint2 gid [[thread_position_in_grid]]
) {
 uint m = dims.x; uint k = dims.y; uint n = dims.z;
 uint row = gid.y; uint col = gid.x;

 if (row < m && col < n) {
 float sum = 0.0;
 for (uint i = 0; i < k; ++i) {
 sum += A[row * k + i] * B[i * n + col]; // Simplification
 }
 C[row * n + col] = sum;
 }
}

Dans l’environnement Apple Silicon, une bibliothèque d’optimisation appelée MPS (Metal Performance Shaders) est également fournie pour la multiplication matricielle. En l’utilisant en production, vous pouvez atteindre des vitesses d’inférence stupéfiantes.

8. Traitement spécifique aux modèles Transformer : Attention et cache KV

Les LLM de pointe tels que LLaMA 2/3 et GPT sont basés sur l’architecture Transformer. Afin de l’implémenter en C++, il est indispensable de construire la « Scaled Dot-Product Attention » représentée par la formule suivante.

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

De plus, lors de la génération de tokens de type autorégressif (Autoregressive), il est nécessaire de conserver les résultats calculés des tokens passés (Key et Value). C’est ce qu’on appelle le « Cache KV (Key-Value Cache) ».

graph TD T["Token Actuel"] --> Q["Requête (Query)"] T --> K["Clé (Key)"] T --> V["Valeur (Value)"] K --> KCache["Ajouter au Cache KV"] V --> VCache["Ajouter au Cache KV"] Q --> Dot1["Q * K_Cache^T"] KCache --> Dot1 Dot1 --> Scale["Mise à l'échelle (1/sqrt(d))"] Scale --> Softmax["Softmax"] Softmax --> Dot2["Sortie Softmax * V_Cache"] VCache --> Dot2 Dot2 --> Out["Vecteur de Contexte"]

L’allocation de mémoire pour le cache KV est également effectuée à l’avance dans l’arena pour la longueur maximale du contexte (par exemple, 4096 ou 8192 tokens), fonctionnant comme un buffer circulaire. Cela évite les réallocations à chaque étape de génération.

En outre, pour le codage de position (Positional Encoding), nous implémentons le « RoPE (Rotary Position Embedding) », qui est devenu la norme ces dernières années. Il s’agit d’une méthode pour intégrer les informations de position en tant que vecteur de rotation dans un espace complexe. L’optimisation des appels aux fonctions sin et cos en C++ (comme l’utilisation de tables de recherche - Lookup Tables) est la clé des performances.

9. Optimisation extrême grâce à la quantification (Quantization) des modèles

Si vous chargez un grand modèle (par exemple, un modèle LLaMA à 7 milliards de paramètres) tel quel en FP32 (virgule flottante 32 bits), les poids seuls consommeront environ 28 Go de mémoire (VRAM). Si vous incluez le cache KV et les buffers d’inférence, cela dépasse facilement les 30 Go, ce qui le rend impossible à exécuter sur un GPU grand public typique.

C’est là que la « Quantification (Quantization) » devient indispensable. C’est également la véritable force du format GGML.

La quantification est une technique permettant de réduire intentionnellement la précision des poids.

FP16 (16 bits) : Réduit la taille de moitié. Presque aucune dégradation de précision.
INT8 (8 bits) : Réduit la taille au quart. Légère dégradation.
INT4 (4 bits) : Réduit la taille au huitième. L’utilisation de facteurs de blocage et de mise à l’échelle personnalisés permet une inférence pratique.

Du côté du moteur d’inférence, il lit les poids compressés en INT4 (ou INT8) depuis la mémoire et les étend (Dequantize) en FP16 ou FP32 juste après les avoir chargés dans les registres du CPU ou du GPU pour effectuer les calculs.

Étonnamment, il est plus rapide de réduire la quantité de données lues depuis la mémoire, même si cela augmente la quantité de calcul. En effet, sur le matériel moderne, le goulot d’étranglement pour les tâches d’inférence n’est pas la « puissance de calcul (Compute Bound) » mais la « Bande Passante Mémoire (Memory Bandwidth Bound) ». Avec un moteur implémenté en C++ et doté d’une quantification INT4, il est possible de faire tourner fluidement un LLM local même sur un MacBook Air avec 8 Go de VRAM.

10. Réglage des performances : Architecture NUMA et Pool de Threads

Lors de l’inférence sur CPU, le multithreading est indispensable. Cependant, le simple lancement de nombreux std::thread n’est pas optimal.

Dans les serveurs multi-sockets modernes et les CPU haut de gamme comme les Ryzen Threadripper, l’architecture NUMA (Non-Uniform Memory Access) est adoptée. L’accès à la mémoire physiquement proche d’un certain cœur de processeur (mémoire locale) est rapide, mais l’accès à la mémoire associée à un autre processeur devient extrêmement lent.

Les moteurs d’inférence C++ avancés utilisent les techniques suivantes :

Épinglage de threads (Thread Pinning) : Fixer (définir l’Affinité) chaque thread à un cœur CPU spécifique pour éviter l’invalidation du cache causée par les changements de contexte.
Allocation sensible à l’architecture NUMA : Allouer la mémoire sur le même nœud NUMA que le thread qui traite les données.
Pool de threads avec Work-Stealing : Implémenter un planificateur (scheduler) efficace où chaque nœud du graphe de calcul est divisé en tâches plus fines, et les threads inactifs s’emparent automatiquement des tâches à exécuter.

En tirant parti de ces techniques, vous pouvez maintenir l’utilisation du CPU à près de 100 % et atteindre un débit (throughput) proche du maximum théorique.

11. Conclusion : Le plaisir de piloter l’IA avec les « muscles » du C++

Python est certes pratique. En matière de recherche et développement et de prototypage, aucun langage ne peut l’égaler en productivité. Cependant, dès que vous passez à la phase de « faire fonctionner le modèle terminé dans le monde réel, efficacement, et sur n’importe quel appareil », c’est là que le C++ entre en jeu.

Manipuler directement les tableaux d’octets en mémoire, pousser les registres à la limite avec les instructions SIMD, lutter avec la bande passante de la VRAM du GPU, tout cela pour construire un moteur d’inférence qui génère tour à tour du texte naturel (tokens) sur la console… Le sentiment d’accomplissement que vous ressentez à ce moment-là procure une « pure joie d’ingénieur » que vous ne pourrez jamais obtenir en appelant simplement model.generate() dans un framework Python.

La technologie de l’IA a tendance à être une « Boîte Noire », mais en écrivant tout vous-même en C++, des opérations sur les tenseurs à l’allocation de mémoire, vous pouvez comprendre en profondeur le véritable mécanisme par lequel les LLM « pensent ».

Si vous avez des connaissances de base en C++ et un fort intérêt pour la technologie de l’IA actuelle, je vous encourage vivement à relever le défi de développer votre propre moteur d’inférence. Le code source de GGML et llama.cpp constitueront sans doute les meilleurs manuels vivants.

Maintenant, abandonnons le lourd runtime de Python et faisons tourner l’IA de pointe grâce aux muscles du C++ !

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).