AI on kenji.blog

Cas d'utilisation des dernières API Microsoft.Windows.AI et exemples de code

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

Exemples d’utilisation des dernières API Microsoft.Windows.AI et code source : Explorer les profondeurs de Windows Copilot Runtime

1. Introduction : Une nouvelle ère où l’IA est intégrée nativement à Windows

Ces dernières années, l’évolution de la technologie de l’IA a été remarquable, avec un changement de paradigme rapide de l’utilisation de grands modèles de langage (LLM) dans le cloud vers l’inférence de l’IA sur des appareils en périphérie (PC locaux). Au cœur de cette évolution se trouvent le « Windows Copilot Runtime » fourni par Microsoft pour Windows 11, ainsi que l’API « Microsoft.Windows.AI » pour le manipuler.

Bien que le développement d’applications utilisant des API cloud (telles qu’OpenAI ou Azure OpenAI) soit facile, il s’accompagne de défis liés à la latence, à la confidentialité et aux coûts continus. D’autre part, en exécutant des modèles d’IA localement, vous pouvez créer des applications à latence ultra-faible qui fonctionnent même hors ligne, sans avoir à extraire de données confidentielles de l’appareil.

Dans cet article, nous fournirons une explication extrêmement détaillée de l’architecture jusqu’à l’optimisation des performances, en utilisant des exemples de code pratiques en C# et C++ concernant la méthode d’implémentation des fonctionnalités d’IA locale, qui deviendra indispensable dans le développement futur d’applications Windows. Nous irons bien au-delà de la simple invocation d’API pour plonger dans les détails techniques avancés, tels que l’utilisation du matériel sous-jacent (NPU et GPU) et l’intégration avec DirectML.

2. Windows Copilot Runtime et vue d’ensemble de l’architecture

Windows Copilot Runtime est une suite d’IA conçue pour permettre aux développeurs d’intégrer facilement des modèles d’IA sous Windows tout en tirant parti des meilleures performances. Ce runtime abstrait l’accélération matérielle au niveau du système d’exploitation (OS) et fournit une interface unifiée aux développeurs.

graph TD App["Application Windows (C# / C++)"] --> API["API Microsoft.Windows.AI"] App --> ORT["ONNX Runtime"] API --> WCR["Windows Copilot Runtime (Couche OS)"] WCR --> SLM["Modèles Locaux (Phi-Silica, etc.)"] ORT --> DML["Fournisseur d'exécution DirectML"] SLM --> DML DML --> DXCore["DXCore / DirectX 12"] DXCore --> NPU["NPU (Unité de traitement neuronal)"] DXCore --> GPU["GPU (Unité de traitement graphique)"] DXCore --> CPU["CPU"]

Comme le montre le diagramme d’architecture ci-dessus, les applications peuvent accéder directement aux petits modèles de langage (SLM : Phi-Silica, etc.) intégrés au système d’exploitation en utilisant l’API de haut niveau Microsoft.Windows.AI. De plus, lors de l’utilisation de modèles personnalisés, il est possible d’utiliser explicitement l’accélération matérielle via ONNX Runtime et DirectML. Étant donné que la couche OS optimise la distribution de la charge de travail vers le CPU, le GPU et le NPU, les développeurs peuvent créer des applications d’IA hautement performantes sans avoir à se soucier profondément des différences matérielles.

3. Accélération matérielle et évaluation mathématique du NPU

Les PC Copilot+ les plus récents sont équipés d’un NPU (Neural Processing Unit), un processeur spécialisé dans le traitement de l’IA. Les performances du NPU sont généralement évaluées en TOPS (Tera Operations Per Second).

Lors de l’inférence du modèle d’IA, la capacité de calcul, en particulier la multiplication de matrices (GEMM : General Matrix Multiply), détermine le débit. Les performances maximales théoriques du matériel $P_{\text{peak}}$ sont estimées par la formule mathématique suivante.

$$ P_{\text{peak}} = f \times N_{\text{cores}} \times N_{\text{MACs/core}} \times 2 $$

Où,

$f$ est la fréquence d’horloge du NPU (Hz)
$N_{\text{cores}}$ est le nombre de cœurs dans le NPU
$N_{\text{MACs/core}}$ est le nombre d’unités MAC (Multiply-Accumulate) par cœur
Le dernier $2$ est dû au fait qu’une opération MAC est comptée comme deux opérations (FLOPs/OPs) de multiplication et d’addition.

Par exemple, dans le cas d’un NPU avec une fréquence de 1,5 GHz, 4 cœurs et 4096 MACs par cœur,

$$ P_{\text{peak}} = 1.5 \times 10^9 \times 4 \times 4096 \times 2 \approx 49.15 \text{ TOPS} $$

Il est mathématiquement démontré que ces performances dépassent les 40 TOPS requis pour un PC Copilot+ sous Windows 11.

De plus, l’inférence des modèles d’IA, en particulier des LLM (phase de décodage), a tendance à être limitée par la mémoire (Memory-Bound). La bande passante théorique de la mémoire système $BW$ est calculée comme suit.

$$ BW = f_{\text{mem}} \times W_{\text{bus}} \times \frac{2}{8} $$

Dans le cas d’une mémoire LPDDR5x-8533 ($f_{\text{mem}} = 8533 \text{ MT/s}$) et d’un bus de 128 bits ($W_{\text{bus}} = 128$), la bande passante est d’environ $136 \text{ GB/s}$. Dans l’optimisation des applications d’IA, il est crucial d’économiser cette bande passante, ce qui rend la quantification du modèle (Quantization), décrite plus loin, indispensable.

4. Configuration de l’environnement de développement

Pour utiliser les dernières API Windows AI, vous devez configurer l’environnement et la chaîne d’outils suivants.

OS : Windows 11 version 24H2 ou ultérieure (Appareil équipé d’un NPU répondant aux exigences des PC Copilot+ fortement recommandé)
SDK : Windows App SDK (version compatible avec l’extension AI v1.5 ou ultérieure)
Environnement de développement : Visual Studio 2022 (v17.10 ou ultérieure), charge de travail de développement natif en C++ et charge de travail de développement de bureau .NET
Packages : Installez Microsoft.Windows.AI et Microsoft.ML.OnnxRuntime.DirectML via NuGet

1
2
3
4
5
6


<!-- Exemple de configuration pour .csproj -->
<ItemGroup>
 <PackageReference Include="Microsoft.Windows.AI" Version="1.0.0-preview1" />
 <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.5.240311000" />
 <PackageReference Include="Microsoft.ML.OnnxRuntime.DirectML" Version="1.17.1" />
</ItemGroup>

5. [Plongée en profondeur 1] Utilisation d’un modèle de langage local (Phi-Silica) avec C#

Windows Copilot Runtime intègre en tant que composant standard du système d’exploitation « Phi-Silica », un petit modèle de langage très efficace développé par Microsoft. Cela permet un traitement du langage naturel avancé (résumé de texte, génération de code, chatbot) dans un environnement hors ligne, sans avoir à télécharger des gigaoctets de modèles depuis le réseau.

Voici un exemple de code avancé pour créer une IA de chat en C# en utilisant l’espace de noms Microsoft.Windows.AI.Generative. Il prend en charge les réponses en streaming et génère du texte en temps réel sans bloquer le thread de l’interface utilisateur.

 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


using System;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Windows.AI.Generative;

namespace WindowsAI.Sample
{
 public class LocalLanguageModelService
 {
 private LanguageModel _languageModel;
 private bool _isInitialized = false;

 /// <summary>
 /// Initialise le modèle de langage. Vérifie la disponibilité du NPU et charge le modèle sur le périphérique optimal.
 /// </summary>
 public async Task InitializeAsync()
 {
 if (_isInitialized) return;

 Console.WriteLine("Vérification de la configuration requise et de la disponibilité du modèle d'IA local (Phi-Silica)...");

 // Vérifie si le modèle est disponible sur le système (s'il n'est pas pris en charge, un téléchargement peut être invité)
 var availability = await LanguageModel.CheckAvailabilityAsync();
 if (availability != LanguageModelAvailability.Available)
 {
 throw new InvalidOperationException($"Le modèle d'IA local n'est actuellement pas disponible. État : {availability}");
 }

 // Crée une instance du modèle (à ce stade, le mappage dans l'espace mémoire et l'initialisation du NPU ont lieu)
 _languageModel = await LanguageModel.CreateAsync();
 _isInitialized = true;

 Console.WriteLine("L'initialisation du modèle de langage est terminée. L'accélération matérielle via DirectML est active.");
 }

 /// <summary>
 /// Reçoit l'invite de l'utilisateur et génère une réponse en streaming.
 /// </summary>
 public async Task GenerateResponseStreamAsync(string prompt, CancellationToken cancellationToken)
 {
 if (!_isInitialized) await InitializeAsync();

 Console.WriteLine($"\n[Entrée utilisateur] : {prompt}\n[Assistant IA] : ");

 // Définit les hyperparamètres lors de la génération
 var options = new LanguageModelOptions
 {
 Temperature = 0.7f,
 TopP = 0.9f,
 MaxTokens = 2048,
 RepetitionPenalty = 1.1f
 };

 // Construction du contexte de conversation
 var context = new LanguageModelContext();
 context.AddSystemMessage("Vous êtes un assistant IA avancé fonctionnant directement sur le NPU local de Windows. Pensez logiquement étape par étape et répondez de manière concise.");
 context.AddUserMessage(prompt);

 try
 {
 // Appel de l'API d'inférence en streaming
 var responseStream = _languageModel.GenerateResponseStreamAsync(context, options);

 // Itération asynchrone sur les morceaux (chunks) retournés sous forme de IAsyncEnumerable
 await foreach (var chunk in responseStream.WithCancellation(cancellationToken))
 {
 // Affiche les jetons générés (morceaux) sur la console en temps réel
 // Pour les applications d'interface utilisateur, utilisez DispatcherQueue ici pour refléter dans TextBox, etc.
 Console.Write(chunk.Text);
 }
 Console.WriteLine();
 }
 catch (OperationCanceledException)
 {
 Console.WriteLine("\n[La génération a été annulée par l'utilisateur ou le système]");
 }
 catch (Exception ex)
 {
 Console.WriteLine($"\n[Une erreur fatale s'est produite : {ex.Message}]");
 }
 }
 }
}

5.1 Explication de l’architecture dans l’implémentation C#

Le cœur de ce code réside dans la validation avant exécution par LanguageModel.CheckAvailabilityAsync() et le streaming asynchrone par GenerateResponseStreamAsync(). Copilot Runtime, fonctionnant en arrière-plan du système d’exploitation, reçoit cet appel d’API, lance en interne ONNX Runtime et sélectionne le fournisseur d’exécution optimal (DirectML + NPU dans de nombreux PC récents) en fonction de la configuration du système.

Les développeurs peuvent intégrer un pipeline d’inférence d’IA de pointe dans leurs applications avec seulement quelques lignes de code C#, sans avoir à se soucier de la forme du tenseur du modèle, de l’implémentation du tokenizer ou de la gestion de la mémoire du cache KV.

6. [Plongée en profondeur 2] Inférence ultra-rapide de modèles personnalisés avec C++ et DirectML

Lors de la gestion de domaines spécifiques qui ne peuvent pas être couverts par le modèle de langage standard du système d’exploitation (tels que la segmentation d’images personnalisée, la reconnaissance vocale, les modèles de détection d’objets personnalisés, etc.), les développeurs doivent interagir directement avec ONNX Runtime et DirectML, situés dans la couche inférieure de Microsoft.Windows.AI.

L’utilisation de C++ permet d’optimiser à l’extrême l’allocation de la mémoire et de libérer les performances maximales du NPU/GPU. Voici une implémentation de base d’un pipeline d’initialisation et d’inférence avancé pour exécuter un modèle personnalisé au format ONNX (par exemple, YOLOv8) en C++ à l’aide de DirectML.

 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
94
95
96
97
98
99


#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>
#include <onnxruntime_cxx_api.h>
#include <dml_provider_factory.h>

class CustomVisionAIProcessor {
private:
 Ort::Env env;
 Ort::Session session{nullptr};
 Ort::AllocatorWithDefaultOptions allocator;

public:
 CustomVisionAIProcessor(const std::wstring& modelPath)
 : env(ORT_LOGGING_LEVEL_WARNING, "VisionAIProcessor") {

 Ort::SessionOptions sessionOptions;
 // Optimisation du nombre de threads
 sessionOptions.SetIntraOpNumThreads(1);
 // Définit le niveau d'optimisation du graphe au maximum
 sessionOptions.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);

 // 1. Ajout du fournisseur d'exécution DirectML (DML EP)
 // device_id = 0 est l'adaptateur par défaut recommandé par le système (NPU ou GPU hautes performances)
 const OrtApi& ortApi = Ort::GetApi();
 OrtDmlApi* dmlApi = nullptr;
 OrtStatus* status = ortApi.GetExecutionProviderApi("DML", ORT_API_VERSION, reinterpret_cast<void**>(&dmlApi));

 if (status == nullptr && dmlApi != nullptr) {
 Ort::ThrowOnError(dmlApi->SessionOptionsAppendExecutionProvider_DML(sessionOptions, 0));
 std::cout << "[Info] Le fournisseur d'exécution DirectML a été attaché avec succès." << std::endl;
 } else {
 std::cerr << "[Warning] Échec de l'obtention de l'API DirectML. Exécution en mode de secours CPU." << std::endl;
 if (status != nullptr) ortApi.ReleaseStatus(status);
 }

 // 2. Chargement du modèle et création de la session
 try {
 session = Ort::Session(env, modelPath.c_str(), sessionOptions);
 std::cout << "[Info] Le modèle ONNX a été chargé avec succès et le graphe de calcul a été compilé." << std::endl;
 } catch (const Ort::Exception& e) {
 std::cerr << "[Error] Échec du chargement du modèle : " << e.what() << std::endl;
 throw;
 }
 }

 void RunInference(const std::vector<float>& imageTensor, const std::vector<int64_t>& inputShape) {
 // 3. Création du tampon du tenseur d'entrée
 Ort::MemoryInfo memoryInfo = Ort::MemoryInfo::CreateCpu(OrtArenaAllocator, OrtMemTypeDefault);
 Ort::Value inputTensor = Ort::Value::CreateTensor<float>(
 memoryInfo,
 const_cast<float*>(imageTensor.data()),
 imageTensor.size(),
 inputShape.data(),
 inputShape.size()
 );

 // 4. Obtention dynamique des noms de nœuds d'entrée et de sortie
 auto inputNamePtr = session.GetInputNameAllocated(0, allocator);
 auto outputNamePtr = session.GetOutputNameAllocated(0, allocator);
 const char* inputNames[] = { inputNamePtr.get() };
 const char* outputNames[] = { outputNamePtr.get() };

 // 5. Exécution de l'inférence (Déchargée vers le NPU/GPU via DirectML)
 std::cout << "[Info] Démarrage de l'exécution du moteur d'inférence..." << std::endl;
 auto startTime = std::chrono::high_resolution_clock::now();

 auto outputTensors = session.Run(Ort::RunOptions{nullptr}, inputNames, &inputTensor, 1, outputNames, 1);

 auto endTime = std::chrono::high_resolution_clock::now();
 auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime);

 // 6. Obtention et analyse du tenseur de résultat
 float* outputData = outputTensors.front().GetTensorMutableData<float>();
 size_t outputSize = outputTensors.front().GetTensorTypeAndShapeInfo().GetElementCount();

 std::cout << "[Result] Inférence terminée : " << duration.count() << " ms" << std::endl;
 std::cout << "[Result] Nombre d'éléments du tenseur de sortie : " << outputSize << std::endl;
 // * Après cela, implémentez le processus de NMS (Non-Maximum Suppression) et le dessin de la boîte de délimitation pour le tenseur de sortie
 }
};

int main() {
 try {
 // Chemin du modèle ONNX à exécuter
 CustomVisionAIProcessor processor(L"models/yolov8n_quantized.onnx");

 // Données d'image factices pour l'inférence (taille de lot 1 x 3 canaux x 640 x 640)
 std::vector<int64_t> inputShape = {1, 3, 640, 640};
 std::vector<float> dummyImage(1 * 3 * 640 * 640, 0.5f);

 processor.RunInference(dummyImage, inputShape);
 } catch (const std::exception& e) {
 std::cerr << "Le programme s'est terminé de manière anormale : " << e.what() << std::endl;
 return -1;
 }
 return 0;
}

6.1 L’importance de la gestion de la mémoire et de l’inférence “zéro copie” en C++

Le principal avantage de l’utilisation de DirectML avec C++ est la possibilité d’une intégration étroite avec DirectX 12 (DX12). Bien que le code ci-dessus inclue une copie de données standard à partir de la mémoire du processeur à des fins éducatives, dans les moteurs de jeux réels et les applications de traitement vidéo, il existe de nombreux cas où les images (textures) sont déjà conservées dans l’espace mémoire du GPU ou du NPU à l’aide de DX12.

Dans ce cas, en utilisant la fonction de liaison (binding) avancée de OrtDmlApi, vous pouvez réaliser une « Inférence Zéro Copie (Zero-Copy Inference) », où les ressources DX12 sont mappées directement en tant que tenseurs ONNX Runtime. En conséquence, la surcharge de transfert de données sur le bus PCIe (la consommation de la bande passante $BW$ mentionnée ci-dessus) disparaît complètement, et la fréquence d’images dans le traitement vidéo en temps réel s’améliore de manière spectaculaire.

7. Optimisation des performances et bonnes pratiques

Les stratégies d’optimisation indispensables lors du développement d’applications d’IA de premier ordre utilisant l’API Windows AI et DirectML sont résumées ci-dessous.

7.1 Quantification de modèle (Quantization) et boîte à outils Olive

Pour libérer la véritable puissance du NPU, il est absolument indispensable de quantifier (Quantization) les poids et les activations du modèle d’IA de FP32 (virgule flottante simple précision) à INT8 ou INT4. L’architecture du NPU est spécialisée pour l’arithmétique entière, et comparée au FP32, l’INT8 permet théoriquement un débit 4 fois supérieur et des économies d’énergie significatives.

En utilisant la chaîne d’outils Olive (ONNX Live) fournie par Microsoft, les modèles tels que PyTorch peuvent être automatiquement optimisés pour les environnements Windows. Olive prend fortement en charge l’optimisation spéciale de l’attention pour les modèles Transformer et la compilation de graphes par matériel.

7.2 Traitement par lots vs Compromis du streaming interactif

Dans les appels d’API, en traitant par lots plusieurs requêtes d’inférence, vous pouvez augmenter l’efficacité d’utilisation du NPU (Compute Utilization). Cependant, dans le cas d’une interface utilisateur interactive comme un chatbot, le temps d’affichage du premier jeton (TTFT : Time To First Token) détermine l’expérience utilisateur (UX) plutôt que le débit. Par conséquent, pour les interfaces utilisateur interactives, la meilleure pratique consiste à définir la taille du lot sur 1 et à concevoir une génération en streaming en priorité.

7.3 Tâches en arrière-plan et intégration du système d’exploitation

L’inférence de l’IA consomme une quantité massive d’énergie locale et de ressources système. Il est nécessaire de s’intégrer à l’ App Lifecycle API de Windows pour implémenter une suspension temporaire (Suspend) des tâches d’inférence de faible priorité ou pour réduire la consommation de ressources lorsque l’application passe en arrière-plan.

sequenceDiagram participant User as "Utilisateur" participant App as "Application Windows (C#)" participant API as "Microsoft.Windows.AI" participant OS as "Windows Copilot Runtime" participant ORT as "ONNX Runtime (DML)" participant NPU as "Matériel NPU" User->>App: "Entrer l'invite" App->>API: "GenerateResponseStreamAsync()" API->>OS: "Envoi de la tâche d'inférence" OS->>ORT: "Demande d'exécution du graphe" ORT->>NPU: "Exécution de la liste de commandes via DirectML" NPU-->>ORT: "Calcul terminé (1 jeton généré)" ORT-->>OS: "Résultat du tenseur" OS-->>API: "Texte décodé" API-->>App: "IAsyncEnumerable Morceau" App-->>User: "Dessin de caractères en temps réel sur l'UI" Note over ORT,NPU: "Répéter cette boucle à grande vitesse jusqu'à la fin"

Ce diagramme de séquence illustre la beauté du traitement asynchrone où les données circulent de la couche matérielle NPU la plus basse vers la couche de présentation de l’application, diffusées en continu sans bloquer le thread de l’interface utilisateur.

8. Perspectives d’avenir et évolution de Windows AI

L’API Microsoft.Windows.AI et Copilot Runtime évoluent rapidement en ce moment. Les mises à jour futures pour les développeurs devraient apporter les changements de paradigme suivants :

Intégration OS native des API multimodales : Traitement simultané fluide non seulement du texte, mais aussi de la voix, des images et même des flux vidéo en direct, offrant une inférence d’IA intermodale en standard au niveau du système d’exploitation.
Prise en charge au niveau du système du RAG (Retrieval-Augmented Generation) : Création d’assistants IA personnels ultra-avancés qui protègent entièrement la vie privée de l’utilisateur en reliant les documents personnels sur le PC local et l’index Windows Search aux modèles d’IA dans le bac à sable sécurisé du système d’exploitation.
Mise à l’échelle dynamique des ressources du NPU : Lorsque plusieurs applications d’IA (par exemple, la suppression du bruit en arrière-plan et la génération de code au premier plan) fonctionnent en même temps, le planificateur du noyau (kernel scheduler) Windows bascule dynamiquement le contexte d’exécution du NPU, un mécanisme qui garantit la qualité de service (QoS).

9. Conclusion : L’avenir des applications transformé par l’IA locale

Windows Copilot Runtime et l’API Microsoft.Windows.AI de Windows 11 ont apporté une arme extrêmement puissante appelée « IA locale » à tous les développeurs Windows. Il n’est plus nécessaire de s’en remettre entièrement aux API du cloud. Il est possible d’offrir aux utilisateurs des expériences d’IA de nouvelle génération qui éliminent la latence, maintiennent fermement la confidentialité et fonctionnent parfaitement même hors ligne.

Utilisez les connaissances expliquées dans cet article concernant l’intégration du modèle de langage standard du système à l’aide de C#, l’évaluation mathématique des performances et l’optimisation matérielle extrême à l’aide de C++ et de DirectML pour créer vos propres applications Windows « IA natives » de nouvelle génération. Les possibilités infinies offertes par l’IA s’étendent juste au-delà du code que vous écrivez.

Remarque : Cet article est basé sur l’API en version préliminaire et les dernières spécifications en date de septembre 2026. Les spécifications de l’API et les exigences matérielles étant susceptibles d’être modifiées avec les mises à jour de Windows, assurez-vous de toujours consulter la documentation officielle de Microsoft Learn lors de la mise en œuvre.

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++ !

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.

Comment les programmeurs devraient-ils survivre à l’ère de l’IA ?

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

Comment les programmeurs devraient-ils survivre à l’ère de l’IA ? La fin du codage et l’aube d’une nouvelle ingénierie

En 2026, le domaine du développement logiciel traverse une période de bouleversements sans précédent. Il y a quelques années à peine, le concept d’“IA qui écrit du code” se limitait tout au plus à générer du code passe-partout (boilerplate) ou à l’autocomplétion de fonctions, agissant comme un simple “outil d’assistance” pour les programmeurs. Cependant, avec l’évolution phénoménale des grands modèles de langage (LLM), la situation s’est fondamentalement inversée. L’IA moderne n’est plus une simple “machine à écrire intelligente”. Si on lui fournit un document de définition des exigences, elle s’est transformée en un “ingénieur junior autonome” capable d’assembler instantanément et de manière autonome l’ensemble d’un système, allant du front-end à la logique back-end, la conception du schéma de la base de données, et même la construction de pipelines CI/CD.

Dans une telle époque, comment nous, “programmeurs” et “ingénieurs logiciels”, devons-nous survivre ? Alors que la valeur économique de l’acte même d’“écrire du code” se dégonfle rapidement, les “codeurs” qui ne connaissent que la syntaxe d’un langage de programmation spécifique et maîtrisent l’API d’un framework particulier sont rapidement éliminés du marché.

Dans cet article, nous examinerons en détail les stratégies de survie des programmeurs à l’ère de l’IA sous des angles techniques, mathématiques et philosophiques. Il ne s’agit pas d’une simple théorie de carrière, mais d’une redéfinition de la discipline de l’ingénierie logicielle elle-même.

1. L’histoire de l’abstraction (Abstraction) et la redéfinition de la “programmation”

Si l’on regarde l’histoire de l’ingénierie logicielle, on se rend compte qu’elle a toujours été l’histoire de l’“abstraction” (Abstraction). Nous avons constamment construit des couches pour décrire des systèmes plus complexes dans un langage plus proche de l’homme.

Les premiers informaticiens manipulaient directement les commutateurs matériels physiques à l’aide de cartes perforées et donnaient des instructions aux ordinateurs en langage machine (une séquence de 0 et de 1). Par la suite, le langage d’assemblage est apparu, permettant de contrôler le matériel avec des mnémoniques facilement compréhensibles par les humains. Au fur et à mesure que l’époque avançait, des langages de haut niveau tels que C et Fortran ont fait leur apparition, réussissant à encapsuler des détails matériels complexes tels que la gestion de la mémoire et les registres du CPU. Par la suite, avec des langages modernes comme Java, Python, Ruby et TypeScript, les programmeurs ont pu se concentrer davantage sur “ce qu’ils veulent que l’ordinateur fasse (What)” plutôt que sur “comment faire fonctionner l’ordinateur (How)”.

L’émergence de l’IA (LLM) est le dernier et le plus grand changement de paradigme de cette histoire de l’abstraction. Si l’évolution des langages de programmation était de “masquer le matériel”, l’évolution du LLM est de “masquer la syntaxe”.

graph TD A["Code machine / Cartes perforées (Années 1940)"] --> B["Langage d'assemblage (Années 1950)"] B --> C["Langages compilés de haut niveau (Années 1970)"] C --> D["Langages gérés / de script (Années 1990)"] D --> E["Langage naturel via LLMs (Années 2020)"] E --> F["Agents IA autonomes (2026-)"] style E fill:#f9f,stroke:#333,stroke-width:2px style F fill:#fbb,stroke:#333,stroke-width:2px

L’époque où les développeurs manipulaient des pointeurs en s’inquiétant des fuites de mémoire ou écrivaient des centaines de lignes de code de base pour analyser du JSON est révolue. Définir des systèmes en utilisant le langage naturel (japonais, anglais, ou français), qui est le langage le plus abstrait pour l’humanité, est devenu le standard de la “programmation” en 2026.

2. Modèle mathématique de la productivité : Surfer sur la vague de la croissance exponentielle

Évaluons quantitativement l’amélioration de la productivité apportée par l’IA à l’aide d’un modèle mathématique. La productivité individuelle dans le développement logiciel traditionnel, $P_{traditional}$, pouvait être modélisée comme une combinaison linéaire du niveau de compétence de l’individu $S$, de l’expérience du domaine $E$ et de l’efficacité des outils $T$.

$$ P_{traditional} = c_1 \cdot S + c_2 \cdot E + c_3 \cdot T $$

Cependant, dans le développement moderne utilisant l’IA, la capacité de l’IA $A(t)$ agit comme un “puissant levier” (Multiplier) qui amplifie les capacités humaines. Comme la capacité de l’IA croît de manière exponentielle avec le temps $t$ (la version IA de la loi de Moore), la productivité à l’ère de l’IA $P_{AI}(t)$ peut s’exprimer par l’équation suivante :

$$ P_{AI}(t) = \alpha \cdot S_{core} \cdot e^{\beta \cdot A(t)} $$

Ici, chaque variable signifie ce qui suit :

$\alpha$ : Coefficient de productivité humaine de base
$S_{core}$ : “Compétences fondamentales humaines” non remplaçables par l’IA (conception d’architecture, compréhension des exigences métier, jugement éthique, etc.)
$A(t)$ : Capacité absolue du modèle d’IA au temps $t$ (nombre de paramètres, fenêtre de contexte, capacité de raisonnement)
$\beta$ : Coefficient indiquant l’efficacité avec laquelle les outils d’IA peuvent être exploités (qualité de l’ingénierie des prompts et sophistication du flux de travail collaboratif avec l’IA)

La conclusion clé tirée de cette formule est que dans un monde où $A(t)$ augmente de manière exponentielle, les compétences traditionnelles telles que la simple vitesse de frappe ou la mémorisation d’un langage spécifique ont un impact extrêmement faible sur la productivité globale. Au lieu de cela, le coefficient $\beta$ pour tirer parti de la croissance exponentielle de l’IA, et $S_{core}$, qui est le domaine que l’IA ne peut pas couvrir, deviennent les facteurs dominants qui déterminent la valeur marchande d’un ingénieur.

3. Probabilité d’automatisation des tâches (Probability of Automation)

Alors, quelles tâches seront automatisées et quelles tâches resteront entre les mains de l’homme ? La probabilité $P_{auto}(T)$ qu’une tâche donnée $T$ soit entièrement automatisée par l’IA peut être formulée comme suit :

$$ P_{auto}(T) = 1 - \exp\left(-\lambda \cdot \frac{\text{Predictability}(T)}{\text{Complexity}(T) \times \text{Context Dependency}(T)}\right) $$

$\text{Predictability}(T)$ : Prévisibilité de la tâche (dans quelle mesure des modèles existent dans les données passées)
$\text{Complexity}(T)$ : Complexité de la tâche
$\text{Context Dependency}(T)$ : Force du “contexte implicite” (connaissances spécifiques au domaine ou relations humaines) dont dépend la tâche
$\lambda$ : Taux de progrès technologique de l’IA

Les tâches présentant une prévisibilité élevée et une faible dépendance au contexte, telles que l’écriture du routage d’une API ou la création d’un simple écran CRUD, auront $P_{auto} \approx 1$ et seront presque entièrement automatisées. En revanche, les tâches avec une dépendance extrêmement élevée au contexte, telles que “Comment intégrer en toute sécurité des systèmes existants avec de nouveaux microservices” ou “Comment concevoir un flux d’authentification qui satisfait aux exigences du département juridique sans compromettre l’expérience utilisateur”, sont difficiles à automatiser.

4. Retour de la syntaxe à l’architecture (Structure)

Séparer clairement ce en quoi l’IA excelle de ce en quoi les humains excellent est une condition absolue de survie.

graph LR Sub1["Domaines d'excellence de l'IA"] Sub2["Domaines d'excellence de l'humain"] A["Génération de code à partir de spécifications"] --> Sub1 B["Correction d'erreurs de syntaxe et de bugs"] --> Sub1 C["Génération de code de base / de tests"] --> Sub1 D["Analyse de journaux et reconnaissance de modèles"] --> Sub1 E["Conception d'architecture système"] --> Sub2 F["Résolution des exigences ambiguës"] --> Sub2 G["Négociation inter-équipes"] --> Sub2 H["Jugement éthique / Responsabilité"] --> Sub2

L’IA surpasse les humains dans l’“optimisation locale”. Les humains n’ont aucune chance de rivaliser en matière de vitesse et de précision pour écrire une fonction, une classe ou un module unique. Cependant, l’IA est très vulnérable face à l’“optimisation globale” et au “contexte manquant” (Missing Context).

Les programmeurs de demain doivent changer de rôle, passant de “travailleurs qui écrivent du code” à “architectes qui orchestrent d’innombrables composants générés par l’IA”. Avoir une vue d’ensemble de tout le système, décider où tracer les frontières des microservices, comment résoudre le compromis entre disponibilité et cohérence dans le théorème CAP en fonction du contexte commercial, comment contrôler la dette technique. Il s’agit d’un travail intellectuel de haut niveau que seuls des humains comprenant la vision globale et les objectifs commerciaux peuvent accomplir.

5. La définition des exigences est la “véritable ingénierie des prompts”

L’expression “ingénierie des prompts” que l’on entend souvent ces derniers temps est souvent confondue avec un “astuce pour tromper l’IA afin d’obtenir la sortie souhaitée”. Cependant, l’essence de l’ingénierie des prompts dans le développement logiciel est sans aucun doute “l’ingénierie avancée des exigences” (Requirements Engineering).

Afin de donner des instructions à l’IA en langage naturel et de lui faire produire le logiciel prévu, les éléments suivants doivent être strictement verbalisés :

Objectif (Why) : Pourquoi cette fonctionnalité est-elle nécessaire ? Quelle est sa valeur commerciale ?
Contraintes (Constraints) : Exigences de performance (latence, débit), exigences de sécurité, contraintes de coût.
Cas limites (Edge Cases) : Traitements de secours lorsque l’utilisateur fournit une entrée inattendue.
Interfaces (Interfaces) : Spécifications d’intégration avec les systèmes existants.

Des instructions vagues (prompts) ne peuvent donner naissance qu’à des systèmes vagues et fragiles. La capacité à écouter profondément “ce que le client voulait vraiment”, à organiser des exigences contradictoires et à créer des spécifications (prompts) sans failles logiques. C’est là la compétence de “codage” la plus puissante à l’ère de l’IA. Les programmeurs passeront de plus en plus de temps face à Notion ou à des fichiers Markdown plutôt qu’à des éditeurs de code, décrivant avec précision ce que devrait être le système sous forme de texte.

6. L’avantage écrasant de la connaissance du domaine (Domain Knowledge)

L’IA ayant été formée sur des codes open source et des documents publics du monde entier, elle connaît bien les technologies Web et les algorithmes généraux. Cependant, il y a des données auxquelles l’IA n’a pas accès. Ce sont les “règles commerciales spécifiques à votre entreprise” et les “connaissances du domaine profondément enracinées dans un secteur particulier (médical, financier, manufacturier, etc.)”.

Par exemple, supposons que vous développiez un système de dossiers médicaux électroniques dans une startup médicale. L’IA sait “comment créer une interface utilisateur de tableau avec React” ou “la structure de données générale de HL7 FHIR”. Cependant, elle n’a pas appris les connaissances tacites telles que “Dans un service spécifique de l’hôpital A, dans quel ordre les médecins consultent-ils les données des patients, et quel type d’interface utilisateur minimiserait le risque d’erreur médicale ?”.

Dans un monde où la technologie elle-même se banalise (commoditisation), la véritable valeur d’un ingénieur naît à l’intersection de la “technologie” et du “domaine commercial”. Ce ne sont pas ceux qui se battent uniquement avec leurs compétences techniques, mais les talents qui possèdent une expertise approfondie dans un domaine spécifique, tel que la médecine, la finance, la logistique ou le divertissement, et qui peuvent résoudre les problèmes de ce domaine à l’aide de l’outil puissant qu’est l’IA, qui dirigeront le marché de demain.

7. Le “problème du tramway” du développement logiciel : Qui prend la responsabilité ?

À mesure que la dépendance à l’IA augmente, nous sommes confrontés à d’importants problèmes philosophiques et éthiques. C’est la question de la “localisation de la responsabilité” dans l’ingénierie logicielle.

Si un code généré de manière autonome par l’IA provoque un bug grave dans un environnement de production, entraînant des centaines de millions de pertes pour une entreprise, ou s’il provoque un dysfonctionnement dans un système médical qui met des vies en danger, qui en prendra la responsabilité ? L’entreprise qui a développé le modèle d’IA ? Ou l’ingénieur qui a saisi le prompt ? On ne peut pas “licencier” ou “arrêter” une IA.

Le rôle de l’“humain” en tant que sujet assumant la “responsabilité légale et éthique (Accountability)” de l’impact du système sur la société ne disparaîtra pas, peu importe l’avancée de la technologie. Au contraire, plus le processus de génération de code devient une boîte noire, plus l’homme assumera la lourde responsabilité d’“approbateur final (Approver)” et de “superviseur (Supervisor)” du système.

Auditer si l’architecture ou le code proposé par l’IA répond aux normes de sécurité, s’il n’y a pas de problème éthique (s’il n’inclut pas de biais), s’il respecte la conformité, et donner le feu vert final. L’acte même de “prendre la responsabilité” deviendra une partie importante du travail d’un ingénieur.

8. Programmation en binôme avec l’IA et gestion de la charge cognitive (Cognitive Load)

En travaillant avec l’IA, la nature de la “charge cognitive (Cognitive Load)” humaine évolue également. La charge cognitive lors de l’écriture de code à partir de zéro et la charge cognitive lors de la “lecture et de la révision” de centaines de lignes de code inconnu généré par l’IA sont complètement différentes.

Selon la théorie de la charge cognitive en psychologie, la mémoire de travail humaine s’épuise rapidement lors du traitement d’informations complexes qui ne correspondent pas aux schémas existants (structures de connaissances dans le cerveau). Le code généré par l’IA contient parfois des optimisations très avancées auxquelles les humains ne penseraient pas, mais il peut aussi contenir des “hallucinations” ignorant le contexte.

Pour éviter cela, il est nécessaire de systématiser le processus de révision de l’IA.

sequenceDiagram participant H as "Ingénieur humain (Architecte)" participant A as "Agent IA" participant S as "CI/CD & Tests" H->>A: "Définir des exigences et contraintes strictes" A->>H: "Proposer l'architecture et le code initial" Note over H,A: Phase de révision : Charge cognitive élevée H->>A: "Critiquer les choix de conception, demander un remaniement" A->>S: "Générer le code final & Pousser" S-->>H: "Résultats des tests automatisés & Analyse statique" H->>H: "Approbation finale & Prise de responsabilité"

L’homme doit perfectionner à l’extrême sa compétence à “lire rapidement et repérer instantanément les défauts logiques (Code Reading & Auditing)”, bien plus que sa compétence à “écrire”. L’importance du développement piloté par les tests (TDD) s’accroît encore à l’ère de l’IA. Avant de laisser l’IA écrire le code, l’approche dominante sera qu’un humain ou une autre IA écrive d’abord un code de test rigoureux, et oblige l’IA à corriger le code jusqu’à ce qu’il réussisse ce test.

9. Stratégies de survie spécifiques : Que devrions-nous apprendre dès demain ?

Sur la base de l’analyse qui précède, nous présentons un plan d’action spécifique pour permettre aux programmeurs de survivre à l’ère de l’IA.

Réapprendre minutieusement les “bases” de la technologie : On peut laisser à l’IA le soin de savoir comment utiliser les frameworks. Cependant, une compréhension approfondie du fonctionnement des systèmes d’exploitation, des protocoles réseau (TCP/IP, HTTP/3), de la structure interne des bases de données (B-Tree, niveaux d’isolement des transactions), des structures de données et des algorithmes est absolument nécessaire. Des bases solides en informatique sont indispensables pour juger si la sortie de l’IA est correcte.
Maîtriser l’architecture cloud et les systèmes distribués : Plutôt que de se concentrer sur des codes individuels, il faut se concentrer sur la manière de combiner les ressources cloud telles qu’AWS, GCP et Azure pour construire des systèmes évolutifs. Comprendre les concepts d’IaC (Infrastructure as Code) tels que Terraform, et cultiver la capacité de concevoir des systèmes entiers sous forme de code.
Devenir un expert du domaine d’activité : Apprendre profondément le modèle commercial, les réglementations légales et la psychologie comportementale des utilisateurs du secteur auquel on appartient. Dépasser le cadre d’un ingénieur et adopter une perspective proche de celle d’un chef de produit (PM).
Affiner ses compétences en communication et en facilitation : Le processus de résolution de l’“ambiguïté” entre les humains et de formation d’un consensus ne peut être remplacé par l’IA. Les compétences interpersonnelles pour dialoguer avec les parties prenantes et découvrir les véritables problèmes deviendront les compétences les plus précieuses.
Utiliser pleinement l’IA comme un “collègue” : Au lieu de craindre l’évolution des outils d’IA, les utiliser comme l’arme la plus puissante. Utiliser quotidiennement les LLM les plus récents et les agents de codage de l’IA, et accumuler des “connaissances tacites” sur les endroits où l’IA échoue et comment ajuster les prompts pour en tirer les meilleures performances.

Conclusion : N’ayez pas peur, surfez sur la vague

L’automatisation de la programmation par l’IA ne signifie pas la “mort” du métier de programmeur. C’est plutôt une “Renaissance” qui nous libère du “travail non essentiel” dans le développement logiciel, comme la correction de fautes de frappe, la résolution de problèmes de configuration d’environnement ou l’écriture de code de base fastidieux.

Au cours de l’histoire, que ce soit lors de l’apparition des métiers à tisser automatiques ou des tableurs (Excel), le pessimisme quant à la disparition des emplois a toujours été répandu. Cependant, la réalité est qu’une amélioration spectaculaire de la productivité a créé de nouvelles demandes, donnant naissance à des emplois plus avancés. La même chose se produira dans le monde du logiciel. Le fait de pouvoir “créer des systèmes à bas prix” permettra aux logiciels de pénétrer tous les domaines qui n’avaient pas encore été informatisés en raison des coûts, et les problèmes que les ingénieurs devront résoudre (What) s’étendront à l’infini.

Aujourd’hui, nous, programmeurs, avons l’opportunité d’évoluer, passant du statut d’artisan écrivant du code à celui de “chef d’orchestre” dirigeant l’intelligence colossale qu’est l’IA. Au lieu de rester sur le rivage par peur de la vague technologique, surfons sur cette vague le plus tôt possible, et embarquons pour un voyage visant à créer des systèmes plus grands et plus précieux. L’ère de l’IA est véritablement l’ère où commence la véritable “ingénierie”.

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)