LLM auto hébergées · 20 October 2026

Windows ML en 2026 : l’OS veut devenir votre runtime LLM — ce qu’on sait vraiment, ce qu’on nous vend, et ce qu’il faut garder de côté

Windows 11 26H2 est là, Microsoft martèle que ses Copilot+ PC sont « les PC Windows les plus rapides et les plus intelligents jamais conçus », et une documentation « Windows ML Runtime API » existe bel et bien sur Microsoft Learn. Mais entre la promesse d’un runtime LLM intégré à l’OS — GGUF, NPU, API compatible OpenAI — et la réalité vérifiable d’octobre 2026, il y a un gouffre que cet essai entend mesurer honnêtement.

Le point de départ : ce qui est documenté, et ce qui ne l’est pas

Commençons par un exercice de probité que tout le monde devrait faire avant de titrer sur « l’OS devenu runtime LLM ». À la date du 20 octobre 2026, les sources officielles Microsoft que nous avons pu consulter — la page produit Windows, la page de téléchargement de Windows 11, le support Windows — ne mentionnent nulle part « Windows ML », encore moins le support GGUF, une API compatible OpenAI, ou un quelconque routage NPU pour l’inférence de grands modèles de langage. Ce qu’elles disent, en revanche, c’est que la version actuelle est « Mise à jour Windows 11 2026 | Version 26H2 », et que Microsoft promeut des « Copilot+ PC » comme « les PC Windows les plus rapides et les plus intelligents jamais conçus », avec IA intégrée — sans le moindre chiffre de performance (tokens/s, TOPS, watts) à l’appui.

Une page existe pourtant, sur Microsoft Learn, intitulée « Windows ML Runtime API overview ». Son existence atteste qu’il y a bien une API runtime Windows ML documentée. Mais son contenu détaillé n’est pas dans notre corpus, et aucune source tierce indépendante — presse tech, dépôt GitHub, blog développeur, fil r/LocalLLaMA — ne vient corroborer les caractéristiques précises avancées dans le cadrage de cet article : chargement de GGUF natif, endpoints /v1/chat/completions, routage CPU/GPU/NPU automatisé.

Autrement dit : le basculement est réel dans son principe (une pile d’inférence système, documentée, sur Windows 11 26H2), mais les détails techniques qui circulent relèvent pour l’instant d’annonces, de fuites ou d’inférences communautaires qu’il faut traiter comme telles. C’est précisément ce qui rend le sujet intéressant : nous sommes au moment exact où un runtime local cesse d’être un bricolage d’utilisateur pour devenir une brique de l’OS, et où il faut décider si c’est une bonne nouvelle.

De DirectML à aujourd’hui : la longue marche d’une couche d’abstraction

Pour comprendre ce que Windows ML est devenu, il faut se rappeler ce qu’il était. Windows ML a été introduit au Build 2018 comme une surcouche d’exécution au-dessus de DirectML, l’API DirectX de Microsoft dédiée au calcul tensoriel. L’idée était simple et très « Microsoft première époque » : les développeurs d’applications Windows n’avaient plus à se soucier du matériel — le système choisissait le meilleur accélérateur disponible (GPU intégré, GPU dédié, CPU) et exécutait le modèle ONNX fourni. C’était une abstraction d’inférence classique, orientée vision par ordinateur et petits modèles, pas du tout pensée pour des LLM de plusieurs milliards de paramètres.

La génération suivante est arrivée avec les Copilot+ PC et l’intégration de ce que Microsoft a appelé le Windows Copilot Runtime, une couche système exposant des modèles first-party — dont Phi Silica, un petit modèle de langage optimisé pour tourner sur NPU — à destination des applications Windows. À ce stade, Windows ML n’était plus seulement une abstraction de calcul : il devenait un distributeur de modèles et un orchestrateur d’exécution, avec un objectif clair — que les applications puissent appeler une IA locale sans embarquer elles-mêmes un runtime, des poids et des pilotes.

Le saut revendiqué en 2026 consiste à étendre cette logique aux modèles open source au format GGUF, c’est-à-dire au format de facto de l’écosystème llama.cpp, et à exposer le tout derrière une API compatible OpenAI. Sur le papier, c’est une bascule considérable : le format le plus populaire de la communauté locale, servi par le runtime le plus officiel qui soit. Dans les faits, cette jonction est loin d’être triviale, et c’est là que le bât blesse.

GGUF + ONNX Runtime : un mariage contre nature ?

Le point technique le plus délicat, et le plus rarement expliqué dans les annonces, est celui du format. GGUF est le format natif de l’écosystème GGML/llama.cpp. Il embarque les poids quantifiés (Q4_K_M, Q8_0, Q5_K_S, etc.), les métadonnées du modèle, le tokenizer, et une disposition mémoire pensée pour l’inférence CPU/GPU efficace sur des machines à mémoire limitée. ONNX, de son côté, est un format de graphe computationnel standardisé, portable entre frameworks, mais qui ne contient pas nativement la notion de quantification « à la GGML » ni les mêmes conventions de tenseurs.

Faire lire du GGUF par un runtime fondé sur ONNX Runtime ne consiste donc pas à « ajouter un parseur ». Cela implique soit une conversion à la volée GGUF → ONNX (coûteuse en temps de chargement et en RAM), soit l’ajout de kernels de déquantification GGML directement dans ONNX Runtime GenAI — la bibliothèque de Microsoft dédiée à l’inférence générative. La seconde option est la seule viable pour des performances sérieuses, mais elle revient à réimplémenter dans ONNX Runtime une partie de ce que llama.cpp fait déjà très bien depuis des années.

Ce que cela signifie concrètement pour l’utilisateur : même si Windows ML 2026 sait charger des GGUF, il ne le fera probablement pas avec la même efficacité qu’un llama.cpp optimisé pour votre matériel précis. Les quantifications Q4_K_M et Q8_0, qui sont les plus utilisées en local, reposent sur des schémas de blocs (super-blocks avec échelles et minimums) dont l’implémentation fine détermine largement le débit. Un runtime généraliste qui doit gérer à la fois ONNX, GGUF et potentiellement d’autres formats aura nécessairement des kernels moins spécialisés qu’un projet mono-format comme llama.cpp, dont la communauté peaufine les noyaux CUDA, Vulkan, Metal et autres depuis des années.

C’est là qu’intervient la comparaison avec l’existant. En septembre 2026, llama.cpp v0.5.0 a continué d’évoluer avec des changements de backend, de modèle et de serveur, et un llama-server qui expose déjà une API HTTP locale. Sur les iGPU AMD Radeon 780M, les gains apportés par les optimisations Vulkan de llama.cpp ont été mesurés à environ +50 %, dont +12,9 % rien qu’avec un réglage MMVQ, avec des débits de l’ordre de 10-12 tok/s sur Llama 3 8B Q4 et Qwen 2.5 7B, et 8-11 tok/s sur Mistral 7B Q4_K_M. Ces chiffres, issus de la communauté, donnent l’étalon auquel un runtime système devra se mesurer. Aucune donnée publique équivalente n’existe à ce jour pour Windows ML.

Le routage CPU/GPU/NPU : promesse séduisante, réalité fragmentée

L’argument massue de Windows ML, c’est le routage automatique entre CPU, GPU et NPU. En théorie, l’utilisateur n’a plus à choisir son backend : le système détecte le matériel, sélectionne l’accélérateur le plus adapté, et bascule en cas de dépassement mémoire. En pratique, ce routage est un exercice d’équilibriste sur un parc matériel extraordinairement hétérogène.

Côté NPU, les choses sont encore plus dispersées qu’on ne le croit. Les NPU des Copilot+ PC reposent sur des architectures différentes selon le fondeur : Qualcomm avec son Hexagon (via le backend QNN), AMD avec ses Ryzen AI, Intel avec ses Lunar Lake et leurs NPU intégrés. Chacun a son SDK, ses limitations de types de tenseurs, ses contraintes de taille de contexte. Un NPU est excellent pour un petit modèle type Phi Silica, beaucoup moins pour un 70B en Q4_K_M qui ne tiendra de toute façon pas dans sa mémoire dédiée. Le routage « intelligent » de Windows ML devra donc, dans la plupart des cas réels, renvoyer vers le GPU ou le CPU — ce qui rend l’argument NPU beaucoup moins décisif qu’il n’y paraît pour l’utilisateur de LLM open source.

Il y a par ailleurs une ironie que les pages officielles de Microsoft rendent visible sans le dire : l’assistant d’installation de Windows 11 ne s’exécute pas sur les PC ARM, uniquement x64 ; l’outil de création de média ne crée que du contenu x64. Autrement dit, la stratégie NPU/ARM (Snapdragon X et compagnie) coexiste avec des outils d’installation encore x64-only. Ce n’est pas un détail : cela montre à quel point la pile Windows reste marquée par des décennies d’héritage x86, et combien l’unification runtime souhaitée par Windows ML devra composer avec cette fragmentation.

Pour l’utilisateur qui possède une RTX 4060 ou 4070, la question est encore plus simple : son GPU CUDA est déjà parfaitement exploité par llama.cpp, Ollama ou LM Studio, avec des débits qui n’ont rien à envier à un runtime système. Le gain de Windows ML, dans ce cas, se limite à la simplicité d’installation et à l’intégration OS — pas à la performance brute.

L’API compatible OpenAI : le vrai changement de paradigme

Si l’on met de côté les débats sur les performances, l’élément le plus intéressant de Windows ML 2026 est peut-être le moins spectaculaire : l’exposition d’une API compatible OpenAI, avec des endpoints du type /v1/chat/completions et /v1/models. C’est ce qui pourrait réellement changer la donne pour les développeurs.

Aujourd’hui, faire tourner un LLM local et l’intégrer dans une application demande soit d’utiliser Ollama (qui expose déjà une API compatible OpenAI, avec son propre écosystème et ses Modelfile), soit de monter soi-même un llama-server, soit de passer par LM Studio et son serveur local. Chacun a ses conventions, ses quirks, ses limitations. Si Windows expose nativement les mêmes endpoints, une application Windows pourrait appeler un modèle local exactement comme elle appellerait OpenAI ou Mistral, sans embarquer de runtime, sans gérer de pilotes, sans se soucier du matériel. C’est un changement d’ergonomie majeur pour l’écosystème applicatif Windows.

Mais — et c’est là que le doute méthodique est légitime — cette promesse soulève trois questions non résolues. Premièrement, la compatibilité : une API « compatible OpenAI » l’est rarement à 100 %. Les paramètres de sampling, la gestion des tool calls, le streaming, les formats de réponse JSON structurés sont autant de zones où les implémentations divergent. Deuxièmement, la gouvernance : si c’est l’OS qui expose l’endpoint, qui décide du modèle chargé, de la quantization, des paramètres par défaut ? L’utilisateur ou Windows ? Troisièmement, la télémétrie : un runtime système qui voit passer toutes vos requêtes locales est un point d’observation idéal. Rien dans nos sources ne permet d’affirmer ou d’infirmer que Microsoft collecte des données sur les prompts, mais la question mérite d’être posée explicitement — c’est le prix potentiel de la simplicité.

Tableau comparatif : ce que chaque solution apporte réellement

Ce tableau, volontairement schématique, met en évidence une réalité simple : Windows ML n’écrase personne sur le terrain de la performance ou du contrôle. Son avantage est ailleurs — dans l’intégration, la distribution et la standardisation.

Les cas où Windows ML gagne vraiment

Il serait malhonnête de ne voir dans Windows ML qu’un énième runtime. Dans plusieurs scénarios, il apporte une valeur réelle.

Le premier est celui de l’utilisateur non technique qui veut faire tourner un LLM local sans se battre avec des pilotes CUDA, des builds Vulkan ou des variables d’environnement. Aujourd’hui, ce public se tourne vers LM Studio ou Ollama, qui font déjà très bien le travail. Mais si Windows propose la même chose sans installation, avec une découverte de modèles intégrée et une gestion automatique du matériel, cela abaissera encore le seuil d’entrée. C’est un progrès, même modeste.

Le deuxième est celui du développeur d’applications Windows qui veut embarquer une fonctionnalité IA locale sans dépendre d’un runtime tiers. Pouvoir appeler /v1/chat/completions sur la machine de l’utilisateur, avec un modèle géré par l’OS, simplifie considérablement la distribution : pas de bundle de plusieurs gigaoctets, pas de mise à jour de runtime à gérer, pas de compatibilité matérielle à assurer. C’est un gain d’ingénierie considérable pour l’éditeur.

Le troisième est celui de la sécurité et de la conformité. Un runtime signé par Microsoft, mis à jour via Windows Update, avec une surface d’attaque réduite par rapport à un binaire tiers, peut séduire les DSI qui refusent aujourd’hui de laisser installer Ollama sur les postes de travail. Ce n’est pas un argument de performance, mais c’est un argument réel dans le monde de l’entreprise.

Les cas où il faut continuer à mettre les mains dans le cambouis

À l’inverse, il y a des situations où Windows ML restera probablement un mauvais choix, au moins à court terme.

Dès que l’on veut contrôler finement la quantization — tester un Q5_K_S contre un Q4_K_M, expérimenter un Q6_K sur un modèle spécifique — llama.cpp reste imbattable. La communauté produit des variantes, des recettes, des optimisations par modèle et par matériel que jamais un runtime généraliste ne pourra égaler.

Dès que l’on veut faire du fine-tuning ou du LoRA local, il faut oublier Windows ML : rien dans nos sources n’indique qu’il supporte ces workflows, et ce n’est de toute façon pas sa vocation.

Dès que l’on utilise Linux ou macOS, la question ne se pose pas : Windows ML est, par construction, une brique Windows. Or beaucoup d’utilisateurs de LLM local travaillent sur Mac (avec MLX, llama.cpp Metal) ou sur des serveurs Linux. Le Mac mini M6 avec 32 Go de mémoire unifiée, évoqué dans notre corpus pour OpenClaw, reste une alternative sérieuse à un PC Windows pour l’inférence locale.

Enfin, dès que l’on veut servir plusieurs utilisateurs ou faire du batch, vLLM reste la référence, avec des optimisations de serving (PagedAttention, continuous batching) que Windows ML n’a aucune raison de répliquer pour un usage mono-utilisateur.

Ce que « local » veut dire quand c’est l’OS qui orchestre

C’est la question de fond, et elle dépasse largement les considérations techniques. Quand un LLM tournait dans un binaire llama.cpp lancé à la main, « local » signifiait quelque chose de précis : les poids étaient sur votre disque, le calcul se faisait sur votre matériel, aucune requête ne sortait de votre machine. C’était vérifiable, auditable, et c’est d’ailleurs ce qui a fait le succès de l’écosystème.

Quand c’est l’OS qui orchestre, la définition devient plus floue. Oui, le calcul reste local. Mais l’OS peut, en principe, vérifier les modèles, les signer, les mettre à jour, collecter des métriques d’usage, ou même décider qu’un modèle n’est pas autorisé pour des raisons de sécurité. Rien dans nos sources ne permet d’affirmer que Microsoft fait cela aujourd’hui — mais c’est la pente naturelle d’un runtime système, et il faut le dire clairement. La confiance dans un binaire open source que l’on compile soi-même n’est pas la même que la confiance dans une API système dont on ne voit pas le code.

Cela ne signifie pas que Windows ML est un cheval de Troie. Cela signifie que le compromis change de nature : on gagne en simplicité et en intégration, on perd en transparence et en contrôle. Pour un usage personnel ou professionnel où la confidentialité est critique, la question mérite d’être posée explicitement avant de basculer.

Verdict : un basculement réel, mais pas encore une révolution

Windows ML en 2026 est un projet sérieux, documenté (une page Microsoft Learn existe, c’est un fait), intégré à Windows 11 26H2, et porté par une stratégie cohérente : faire de l’OS la couche d’inférence par défaut, avec un format populaire (GGUF), une API standard (compatible OpenAI) et un routage matériel automatique. Sur le papier, c’est un basculement silencieux du runtime local vers la pile système, et il faut le prendre au sérieux.

Mais à la date du 20 octobre 2026, les preuves manquent pour valider les promesses. Aucun benchmark public indépendant ne compare Windows ML à llama.cpp, Ollama, LM Studio ou vLLM. Aucune donnée officielle Microsoft ou Qualcomm ne documente les tokens/s, le temps de première token ou la consommation watt sur Snapdragon X Elite, Ryzen AI 300, Lunar Lake ou RTX 4060/4070. Aucune source tierce ne confirme le support GGUF natif, l’API OpenAI intégrée, ou le routage NPU effectif. Les pages officielles consultées ne mentionnent même pas Windows ML.

Cela ne veut pas dire que rien n’existe. Cela veut dire que nous sommes dans une phase où l’annonce précède la preuve, et où l’utilisateur avisé doit garder ses outils actuels sous la main. Pour l’utilisateur qui veut contrôler, optimiser, expérimenter : llama.cpp reste la référence, avec sa communauté, ses kernels spécialisés et ses gains mesurés (jusqu’à +50 % sur iGPU AMD Radeon 780M avec Vulkan, par exemple). Pour l’utilisateur qui veut la simplicité et l’intégration OS : Windows ML mérite d’être testé, mais pas encore adopté les yeux fermés.

Le vrai basculement, s’il a lieu, se jouera sur deux choses : la performance réelle mesurée par des tiers indépendants, et la transparence du runtime. Tant que ces deux conditions ne sont pas remplies, « local » restera, pour beaucoup d’entre nous, synonyme de binaire compilé à la main — et c’est très bien ainsi.

Sources

• Windows — Microsoft (FR)
• Téléchargement de Windows 11 — Microsoft (FR)
• Support Windows — Microsoft
• Windows ML Runtime API overview — Microsoft Learn
• Microsoft Windows — Wikipédia (EN)
• Microsoft Windows — Wikipédia (FR)
• llama.cpp v0.5.0 in 2026: What Changed, How to Install, Run GGUF & Use the Local API — gyanaangan.in (27 septembre 2026)
• Performance LLM sur GPU AMD Radeon 9070XT — quelllm.fr (25 septembre 2026)
• Modèles GGUF : types de quantification et exécution — convly.ai (9 septembre 2026)
• Faire tourner une IA en local en 2026 : guide complet — Brief IA (18 septembre 2026)
• New Co-Design Framework Speeds Up LLM Inference on Mixed Hardware by Taming Memory Bottlenecks — bioengineer.org

Article recherché et rédigé automatiquement · Magazine Electrosens