LLM auto hébergées · 1 September 2026

WSL 3 : le passthrough GPU/NPU qui rend l’IA locale enfin viable sur Windows

Pendant des années, faire tourner un LLM open source sur Windows relevait du parcours du combattant : dual-boot Linux, pilotes capricieux, performances en berne. Avec l’aperçu de WSL 3 dévoilé à la Build 2026, Microsoft promet un accès quasi natif au GPU et au NPU. Mais que vaut vraiment cette promesse, et que change-t-elle pour celles et ceux qui veulent faire de l’IA chez eux sans se ruiner ?

Le casse-tête de l’IA locale sur Windows : pourquoi le dual-boot était la seule issue

Il y a encore quelques mois, lancer un modèle de langage volumineux sur une machine Windows relevait du jeu de patience. Les outils qui dominent l’écosystème open source — Ollama, llama.cpp, vLLM — ont été pensés pour Linux, et leur exécution sous Windows passait par WSL 2. Or, WSL 2 repose sur une machine virtuelle Hyper-V complète, embarquant un noyau Linux intégral. Cette couche de virtualisation matérielle, si elle est pratique pour la compatibilité, se révèle un goulot d’étranglement redoutable dès qu’il s’agit d’accéder au GPU.

Concrètement, les utilisateurs qui souhaitaient exploiter pleinement leur carte graphique pour de l’inférence locale devaient choisir entre deux maux : accepter une pénalité de performance parfois sévère via WSL 2, ou s’engager dans un dual-boot Linux. Ce dernier, s’il offre des performances optimales, impose une partition dédiée, une gestion des pilotes (NVIDIA, AMD) souvent délicate, et un aller-retour permanent entre deux systèmes pour la moindre tâche bureautique. Pour un amateur passionné, le coût en temps et en complexité est dissuasif.

D’autant que l’intérêt de l’IA locale n’a cessé de croître. Les modèles récents, comme les séries Llama, Qwen ou Mistral, se déclinent en versions quantifiées qui tiennent dans des budgets VRAM raisonnables : un modèle 8B en 4-bit occupe environ 4 à 5 Go de VRAM, un 13B en Q4_K_M environ 10 Go. Avec une carte comme une RTX 4060 ou 4070, on peut faire tourner des modèles de 7 à 13 milliards de paramètres confortablement. Mais encore faut-il pouvoir y accéder sans passer par des heures de configuration. C’est exactement la promesse que Microsoft a mise sur la table le 2 juin 2026.

WSL 3 : la promesse d’un passthrough GPU/NPU quasi natif

Le mardi 2 juin 2026, lors du keynote de la Build 2026 à San Francisco, Microsoft a présenté en avant-première WSL 3. L’objectif affiché est ambitieux : rendre l’IA locale enfin viable sur Windows, en offrant un accès direct au GPU et au NPU (Neural Processing Unit) depuis l’environnement Linux. Selon l’article de TechTimes qui relate l’annonce, WSL 3 s’appuie sur une « nouvelle architecture de VM légère basée sur un accès matériel paravirtualisé » qui contournerait le chemin de virtualisation matérielle complète de WSL 2.

Il faut ici être prudent : cette information provient d’une source unique, TechTimes, un média tiers qui n’est pas la documentation officielle de Microsoft. Aucun nom d’ingénieur, aucune session de conférence dédiée, aucune citation directe de l’entreprise n’est rapportée. Le chiffre de « 1,4 milliard d’appareils actifs Windows » est avancé comme le potentiel de la base installée, mais sans source primaire identifiée. Cela dit, la direction est crédible : Microsoft pousse depuis plusieurs années son initiative Copilot+ PC, avec des NPU dédiés, et WSL 3 s’inscrit logiquement dans cette stratégie.

L’idée centrale est simple : plutôt que d’exécuter un noyau Linux complet dans une VM Hyper-V, WSL 3 utiliserait une VM légère avec un accès paravirtualisé au matériel. Les charges de travail CUDA et DirectML côté Linux se comporteraient alors « beaucoup plus proches » de ce qu’un install Linux natif donnerait, pour des frameworks comme PyTorch ou JAX. Mais là encore, l’article ne fournit aucun chiffre précis, aucune mesure de latence, aucun benchmark. Nous sommes face à une promesse, pas à une démonstration.

Sous le capot : l’architecture paravirtualisée qui contourne Hyper-V

Pour comprendre l’ampleur du changement, il faut revenir sur l’architecture de WSL 2. Celle-ci s’appuie sur une machine virtuelle Hyper-V complète, avec un noyau Linux réel, une allocation mémoire dynamique et un accès au GPU via un pilote de virtualisation (le fameux shim dxgkrnl). Ce dispositif fonctionne, mais il ajoute une couche d’abstraction qui se paie en performances, notamment pour les workloads d’inférence qui sollicitent intensivement la mémoire vidéo et les unités de calcul.

WSL 3, selon les informations disponibles, remplacerait cette VM complète par une VM légère, avec un accès matériel paravirtualisé. Le terme « paravirtualisation » est important : il désigne une technique où le système invité est conscient de la virtualisation et communique directement avec l’hyperviseur pour accéder au matériel, plutôt que de passer par une émulation complète. C’est le principe utilisé par VirtIO dans le monde KVM, ou par les pilotes paravirtuels de VMware. Dans le cas de WSL 3, cela signifierait que le GPU et le NPU seraient exposés directement au noyau Linux, sans intermédiaire logiciel lourd.

Cependant, aucun nom de code architectural n’est donné, aucune précision sur les mécanismes exacts (DMA, VirtIO, etc.) n’est fournie. On ignore si le shim dxgkrnl est totalement supprimé ou simplement allégé. La source ne mentionne pas non plus la gestion de la mémoire unifiée entre le NPU, le GPU et la RAM système. Autant de zones d’ombre qui devront être éclaircies par la documentation officielle ou des tests indépendants. En l’état, on ne peut que constater l’intention : éliminer le goulot d’étranglement de WSL 2.

Chiffres et benchmarks : que vaut vraiment la performance « quasi native » ?

C’est le point le plus délicat. L’article de TechTimes affirme que les workloads CUDA et DirectML « se comportent beaucoup plus proches de ce qu’un install Linux natif donnerait », mais aucun chiffre n’est fourni : ni tokens/seconde, ni latence, ni consommation VRAM. Aucune comparaison avec un dual-boot Linux sur une RTX 4060 ou 4070 n’est mentionnée. Nous sommes donc face à une affirmation non vérifiée, sans protocole de test ni matériel précisé.

Les premiers retours, s’ils existent, ne sont pas rapportés. On peut toutefois raisonner sur les ordres de grandeur. L’inférence d’un modèle 8B en 4-bit sur une RTX 4060 (8 Go de VRAM) produit typiquement entre 40 et 60 tokens par seconde en natif Linux. Si WSL 3 atteint effectivement 90 à 95 % de ces performances, la différence serait à peine perceptible pour un usage interactif. En revanche, si la pénalité reste de l’ordre de 20 à 30 %, les utilisateurs exigeants préféreront toujours le dual-boot.

Il faut aussi considérer la maturité des pilotes. Sous Linux, les pilotes NVIDIA propriétaires sont aujourd’hui très performants pour l’inférence, mais leur intégration dans un environnement virtualisé paravirtualisé est un défi technique. Microsoft devra fournir des pilotes de virtualisation robustes pour que la promesse se concrétise. En l’absence de benchmarks indépendants, le scepticisme est de mise. La prudence s’impose : « quasi natif » est un terme marketing tant qu’aucun chiffre ne vient l’étayer.

Quel matériel pour en profiter ? NPU supportés et limites au lancement

La question du matériel est cruciale pour les utilisateurs à budget limité. Selon l’article, le passthrough NPU de WSL 3 couvrira au lancement deux familles de processeurs : Qualcomm Snapdragon X Elite et les plateformes Intel Meteor Lake et Lunar Lake. En revanche, le support AMD n’est pas disponible au lancement et est prévu pour une mise à jour future. Cette exclusion est significative : les puces Ryzen AI 300 d’AMD, pourtant présentes sur de nombreux PC Copilot+, ne pourront pas bénéficier du passthrough NPU dans un premier temps.

Il faut noter que l’article ne mentionne pas explicitement la gamme « Intel Core Ultra 200V », mais parle de « Lunar Lake », dont cette gamme fait partie. Pour les utilisateurs AMD, cela signifie qu’ils devront attendre une mise à jour, ou se contenter de l’accès GPU (qui, lui, n’est pas limité à ces familles, mais l’article ne le précise pas clairement). Pour un budget de 800 à 1000 euros, un PC avec un Intel Core Ultra 200V ou un Snapdragon X Elite est envisageable, mais il faudra vérifier la présence d’un GPU discret pour les modèles plus lourds, car les NPU intégrés, même performants, ne remplacent pas une carte graphique pour les gros modèles.

Ollama, LM Studio, llama.cpp : l’écosystème Linux tourne-t-il sans modification ?

C’est une question centrale pour l’adoption. L’article mentionne Ollama, llama.cpp et vLLM comme des outils que les développeurs utilisent, mais il ne précise pas s’ils fonctionneront sans modification dans WSL 3. Aucun test n’est rapporté, aucune déclaration des mainteneurs n’est citée. On peut raisonnablement supposer que si WSL 3 expose un GPU de manière standard (via les API CUDA ou DirectML), ces outils fonctionneront tels quels, puisqu’ils sont conçus pour Linux. Mais c’est une hypothèse, pas une certitude.

Le point technique important est la gestion des pilotes. Sous WSL 2, l’accès GPU passait par un shim Windows (dxgkrnl) qui traduisait les appels CUDA en appels DirectX. Ce mécanisme, bien qu’ingénieux, ajoutait une latence et limitait certaines fonctionnalités (par exemple, la gestion fine de la mémoire). WSL 3, en paravirtualisant l’accès, pourrait permettre à CUDA de s’adresser directement au pilote NVIDIA, sans passer par la couche Windows. Mais l’article ne confirme pas explicitement la suppression du shim. Il dit seulement que WSL 3 « contourne le chemin de virtualisation matérielle complète », ce qui pourrait encore impliquer un shim modifié.

Quant à LM Studio, il n’est pas mentionné dans la source. Cet outil, très populaire pour l’IA locale sur Windows, repose sur llama.cpp et fonctionne nativement sous Windows. Il n’aura probablement pas besoin de WSL 3, mais les utilisateurs qui préfèrent l’écosystème Linux (Ollama, scripts Python, etc.) y trouveront un intérêt. En l’état, la compatibilité logicielle reste à démontrer.

WSL 3 face aux alternatives : Docker, machines virtuelles, dual-boot

Pour évaluer l’intérêt de WSL 3, il faut le comparer aux solutions existantes. Docker Desktop, par exemple, permet d’exécuter des conteneurs Linux sous Windows, mais l’accès GPU y est historiquement limité (via NVIDIA Container Toolkit, avec des performances correctes mais pas natives). Les machines virtuelles classiques (VirtualBox, VMware) offrent un accès GPU partiel, souvent avec des pilotes 3D limités, et sont peu adaptées à l’inférence LLM. Le dual-boot reste la référence en termes de performances, mais au prix d’une lourdeur opérationnelle.

Si WSL 3 tient ses promesses, il offrirait le meilleur des deux mondes : la simplicité de Windows avec des performances proches de Linux. Pour les utilisateurs à budget limité, cela supprimerait la barrière du dual-boot, qui exige de la rigueur technique et du temps. Mais il faut garder à l’esprit que WSL 3 n’est qu’un aperçu, sans date de sortie stable annoncée. Les utilisateurs pressés devront encore patienter.

Les angles morts : mémoire unifiée, bande passante, et modèles 32B

Les annonces de Microsoft brillent par leur silence sur des points techniques cruciaux. Le premier est la gestion de la mémoire unifiée. Sur les machines avec NPU, la mémoire est partagée entre le CPU, le GPU et le NPU. Pour faire tourner un modèle de 32 milliards de paramètres en 4-bit, il faut environ 24 Go de VRAM (selon les configurations recommandées du marché), ce qui dépasse largement la capacité des NPU intégrés actuels. Comment WSL 3 gérera-t-il le débordement sur la RAM système ? Aucune spécification n’est fournie.

Le deuxième angle mort est la bande passante mémoire. Un modèle 32B en 4-bit nécessite de lire environ 16 Go de poids pour générer un token. À une vitesse de 20 tokens par seconde, cela représente un débit de 320 Go/s. Les NPU intégrés, avec leur mémoire LPDDR5, plafonnent souvent autour de 100-150 Go/s. Même les GPU discrets de milieu de gamme, comme une RTX 4060 (272 Go/s), sont à la limite. Sans une gestion fine de la bande passante, les performances pour les gros modèles seront décevantes.

Enfin, l’article ne dit rien sur la gestion de la mémoire partagée entre le NPU et le GPU. Peut-on combiner les deux pour exécuter un modèle plus gros ? Peut-on décharger une partie des couches sur le NPU ? Autant de questions sans réponse. Les utilisateurs qui rêvent de faire tourner un Qwen 2.5 32B ou un DeepSeek V3 (MoE) sur une machine à 1000 euros devront probablement se contenter de modèles plus petits, ou attendre des éclaircissements techniques.

Et après ? Ce que WSL 3 change pour la démocratisation de l’IA locale

Si WSL 3 tient ses promesses, l’impact pourrait être considérable. En éliminant le besoin de dual-boot, Microsoft abaisserait la barrière technique pour des millions d’utilisateurs Windows. L’IA locale deviendrait accessible à celles et ceux qui ne veulent pas toucher à une partition Linux, mais qui souhaitent exécuter des LLM open source pour des raisons de confidentialité, de coût ou de souveraineté. Les 1,4 milliard d’appareils Windows actifs constituent un marché potentiel immense.

Reste que les questions en suspens sont nombreuses. La date de sortie stable n’est pas annoncée. Le support AMD, essentiel pour une large part du parc, est repoussé. Les benchmarks indépendants manquent cruellement. Et la gestion de la mémoire unifiée, point névralgique pour les modèles volumineux, reste un mystère. En attendant, les utilisateurs sérieux continueront de jongler entre Windows et Linux, ou se tourneront vers des solutions comme Ollama avec son moteur MLX sur Mac, qui offre déjà des performances impressionnantes sur Apple Silicon.

WSL 3 est une promesse, pas une réalité. Mais c’est une promesse qui va dans le bon sens : celle d’un Windows qui ne soit plus un obstacle à l’IA locale, mais un terrain de jeu. Si Microsoft parvient à la concrétiser, le dual-boot pourrait bien devenir un souvenir pour les amateurs d’IA. Et pour ceux qui hésitent encore à se lancer, c’est une raison de plus de surveiller les prochaines mises à jour de Windows 11.

Sources

• WSL 3 at Build 2026: Near-Native GPU and NPU Passthrough Brings Local AI to Windows — TechTimes, 2 juin 2026
• Windows 11 Local AI Brings the NPU into the Enterprise Conversation — Virtualization Review, 13 juillet 2026
• Windows 11’s June 2026 Update Lands June 9 With Shared Audio And NPU Monitoring — TechTimes, 6 juin 2026
• Best Hardware for Running Open-Source AI Models Locally in 2026 — Memeburn
• Ollama vs LM Studio : lequel choisir pour une IA locale ? — Alexi Tauzin, 1er août 2026
• Ollama vs. LM Studio vs. llama.cpp: Which Local AI Runtime Should You Use in 2026? — MachineLearningMastery, 29 juillet 2026

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