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

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

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

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

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

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

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

1.1 Tendances technologiques entourant les LLM locaux en 2026

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

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

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

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

2.1 Configuration matérielle recommandée

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

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

2.2 Configuration de WSL2 (Windows Subsystem for Linux 2)

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

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

1
2
3
4
5


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

# Mise à jour du noyau
wsl --update

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

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

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

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

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

3.1 Deux phases : Prefill et Decode

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

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

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

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

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

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

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

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

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

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

4.2 La magie de la quantification (Quantization)

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

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

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

4.3 Calcul du cache KV (Version compatible GQA)

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

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

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

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

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

Où :

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

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

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

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

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

5.1 Installation et exécution

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

1

ollama run llama3:8b

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

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

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

1
2
3
4
5
6
7
8
9


FROM llama3:8b

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

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

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

1
2


ollama create SeniorDev -f ./Modelfile
ollama run SeniorDev

5.3 Utilisation depuis des applications externes (Éditeurs IA)

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

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

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

6.1 Procédure de compilation de llama.cpp

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

1
2
3
4
5
6
7
8


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

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

6.2 Lancement avancé en mode serveur

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

1
2
3
4
5
6
7


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

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

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

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

7.1 LM Studio

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

7.2 Architecture RAG à l’aide d’AnythingLLM

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

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

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

8. Fine-tuning sur Windows WSL2 (LoRA)

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

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

1
2
3
4


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

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

9. Dépannage des performances

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

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

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

2. Erreur “CUDA out of memory”

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

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

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

10. Conclusion et perspectives d’avenir

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

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

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

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