Sur un portable MSI équipé de la puce RTX Spark de Nvidia, une IA du type de ChatGPT tourne près de cinq fois moins vite sous Linux que sous Windows. Le ralentissement apparaît dès que le chargeur est branché. Alex Ziskind, qui teste du matériel pour développeurs sur YouTube, a publié la mesure en vidéo le 31 octobre 2026.
Le 4 novembre, un utilisateur a décrit le même blocage sur un autre portable, dans un rapport de bug déposé chez Nvidia. Il avance une autre cause que le chiffrement évoqué en ligne : le pilote Linux interroge le contrôleur d’énergie de la puce dans une version de protocole que ce contrôleur refuse. Nvidia a publié dans la nuit une version du pilote qui ajoute celle qu’il attend. Aucun test ne dit encore si elle corrige la panne.
La RTX Spark réunit sur une même puce un processeur central Grace, de conception Arm, et un processeur graphique (GPU) Blackwell, chargé des calculs de l’IA. Les deux partagent jusqu’à 128 Go de mémoire. Nvidia a fêté son lancement le 16 octobre.
Sa page produit présente six portables signés Asus, Dell, HP, Lenovo, Microsoft et MSI. Elle promet de faire tourner des modèles « jusqu’à 120 milliards de paramètres » et ne mentionne que Windows 11. Nvidia diffuse aussi librement ses propres modèles ouverts conçus pour tenir dans la mémoire d’une machine locale.
Le même modèle, quatre configurations
Le test d’Alex Ziskind porte sur un MSI Prestige N16 Flip AI+ et sur GPT-OSS-120B, le modèle ouvert d’OpenAI de 120 milliards de paramètres. Sous Windows, le portable génère 65,4 tokens par seconde (un token est un fragment de mot). Dans WSL, le sous-système qui fait tourner Linux à l’intérieur de Windows, il en génère 65,1.
Le DGX Spark, le petit ordinateur de bureau que Nvidia livre sous Linux, atteint 61 tokens par seconde. Avec Linux installé directement sur le portable et le chargeur branché, le débit tombe à 13,9.
Sous Linux, tout dépend du chargeur. Sur batterie, le portable atteint 61 à 67 tokens par seconde dans LM Studio, une application qui fait tourner des modèles en local. Son GPU est alors cadencé vers 1 800 MHz. Chargeur branché, le GPU reste bloqué vers 780 MHz, contre environ 2 200 MHz sous Windows, et le débit tombe à 15 tokens par seconde.
MindStudio, une société de logiciels d’IA, a publié les chiffres détaillés du test le 1er novembre. Elle note que d’ordinaire, un portable ralentit plutôt sur batterie. Sur une série de tests plus longue, Windows a terminé en 8 minutes environ et Linux en 37. Les températures sont restées entre 40 et 47 °C, ce qui écarte une surchauffe.
Un composant que seul Windows pilote
Le billet de blog de MindStudio met en cause « Nvidia Platform Controllers and Framework », un composant visible dans le gestionnaire de périphériques de Windows. Ce contrôleur répartit l’énergie disponible entre le processeur et le GPU.
Quand on le désactive sous Windows, le débit tombe d’environ 83 tokens par seconde, la seconde référence Windows du billet, à un peu plus de 30. Le GPU passe de 2 000 à 786 MHz, presque sa fréquence sous Linux. Réactivé, le composant rend la vitesse.
Selon le billet, le micrologiciel, ce logiciel intégré au matériel, transmet à ce composant une table de réglages d’énergie chiffrée, que seul le pilote Windows sait lire. MindStudio ne dit pas comment ce chiffrement a été établi. Le billet conclut que la correction doit venir de Nvidia, avec une gestion d’énergie équivalente dans son pilote Linux.
Cette thèse du micrologiciel chiffré a fait le titre d’une discussion ouverte le 4 novembre sur Hacker News, un forum de développeurs où le billet a recueilli plus de 580 votes, puis sur Reddit.
Un rapport de bug met en cause le pilote Linux
Le rapport de bug date du 4 novembre à 17 h 44, heure de Paris, et porte sur un Asus ProArt P16. Il figure sur GitHub, dans le dépôt où Nvidia publie en source ouverte les modules noyau de son pilote Linux. Ces modules forment la partie du pilote logée dans le noyau du système. Sur secteur, le GPU de l’Asus reste entre 747 et 754 MHz quelle que soit la charge, pour environ 2,3 watts.
Selon les mesures de l’auteur, les cœurs de calcul tournent en réalité de 183 à 191 MHz, quatre fois moins que la valeur affichée. Sur cet Asus, débrancher le chargeur ne change rien.
La cause avancée concerne ce même contrôleur d’énergie, que Nvidia appelle NVPCF. Le micrologiciel le rend accessible par ACPI, l’interface qui permet au système d’exploitation d’interroger le matériel. Le contrôleur ne répond qu’aux requêtes formulées dans la révision 3.0 de son protocole, notée 0x300 dans le code. Le pilote Linux ne l’interroge qu’en révisions 1.0 et 2.0 : chaque appel échoue, et le service d’énergie de Nvidia s’arrête au démarrage.
Le code publié par Nvidia va dans ce sens. La version 615.78.08 de ces modules, publiée le 7 octobre, est installée sur l’Asus comme sur le Surface décrit plus bas. Son fichier des révisions ne prévoit pour ce contrôleur que 0x100 et 0x200, soit 1.0 et 2.0.
Le rapport ajoute que la puce n’impose pas elle-même la limite : elle réserve 52,8 watts au GPU, alors que la puce entière n’en consomme que 13. L’auteur demande à Nvidia si la révision 3.0 est prévue sous Linux, ou si le pilote peut au moins appliquer un budget d’énergie par défaut.
Le soir même, en réponse au rapport, un second utilisateur a décrit un cas voisin sur un Surface Laptop Ultra de Microsoft. Le contrôleur n’y répond lui aussi qu’à la révision 3.0, mais l’effet est inverse. Le GPU tourne à environ 2 400 MHz et 50 watts, sans limite d’énergie fixée par la machine.
Sous une charge prolongée, la puce de ce Surface reste vers 80 watts jusqu’à ce que la coque dépasse 57 °C, le seuil critique pour Windows. L’ordinateur s’est éteint une fois. Son propriétaire le bride désormais avec un petit programme maison.
Une nouvelle version du pilote dans la nuit
Le 5 novembre vers 1 h 20, heure de Paris, Nvidia a publié sur le même dépôt la version 620.70.06 de ces modules. Son fichier des révisions ajoute la révision 0x300 du contrôleur, celle qui manquait selon le rapport. Le pilote contient désormais le code qui l’interroge en révision 3.0.
La même version inscrit les puces RTX Spark N1X dans la liste des GPU pris en charge, quel que soit le fabricant. Les versions 615 n’en mentionnaient aucune. La publication renvoie seulement à la page de téléchargement du pilote et ne cite pas le rapport n° 1521. Aucun test public ne dit encore si cette version lève le blocage sur secteur.
Micrologiciel chiffré ou pilote incomplet ?
Les deux explications peuvent coexister, mais situent la panne à des endroits différents. Le rapport de bug place l’échec avant toute question de chiffrement : le pilote interroge le contrôleur dans une révision refusée. Interrogé dans la bonne révision, le contrôleur renvoie un bloc de 128 octets d’apparence aléatoire. Table chiffrée ou format pas encore décodé : le rapport ne tranche pas.
Le titre de la discussion sur Hacker News annonce une vitesse réduite à 35 % sous Linux. La mesure principale du test, 13,9 contre 65,4 tokens par seconde, correspond plutôt à 21 % de la vitesse sous Windows. Le chiffre le plus proche de 35 % vient du test sous Windows avec le composant désactivé : environ 38 %.
Les documents publics portent sur trois portables et peu de tâches. Le billet de MindStudio ne donne ni les versions de ses logiciels ni le modèle d’IA de sa mesure à 83 tokens par seconde. À l’heure où nous publions, Nvidia n’a pas répondu au rapport de bug ni commenté publiquement ces tests.
Notre analyse
Nvidia présente la RTX Spark comme un PC Windows pour le développement d’IA, la création et le jeu, avec CUDA, sa plateforme de calcul sur GPU. Selon MindStudio, une bonne partie des outils d’IA locale tournent pourtant d’abord sous Linux, y compris dans les entreprises qui hébergent elles-mêmes leurs modèles ouverts. C’est le cas de vLLM, un serveur qui fait tourner un modèle pour de nombreux utilisateurs.
Avec Linux installé directement, le GPU est bridé sur secteur sur deux des trois portables et privé de toute limite d’énergie sur le troisième. WSL garde la pleine vitesse et le DGX Spark, vendu sous Linux, atteint 61 tokens par seconde. Selon MindStudio, son GPU est de même conception que celui de la RTX Spark. Pour l’IA locale, le choix du matériel se juge donc aussi au système d’exploitation visé.
Côté processeur, Nvidia fournit du code Linux pour cette puce. Dans une modification du 14 octobre, les responsables d’Omarchy, une distribution de Linux, écrivent que Nvidia leur a demandé d’intégrer son correctif pour les modes d’énergie du processeur. Nvidia livre ce correctif dans ses propres images système RTX Spark. Côté graphique, la seule trace publique reste la version 620.70.06, publiée sans commentaire.
Trois questions restent ouvertes. La version 620.70.06 rend-elle sa vitesse au GPU sur secteur, et sur quels portables ? Le comportement dépend-il du micrologiciel de chaque fabricant, comme le suggèrent les trois cas ? La table renvoyée par le contrôleur est-elle vraiment chiffrée ?
Les prochains signaux viendront des premiers tests de cette version, d’une réponse de Nvidia sur GitHub et des mises à jour de BIOS (le micrologiciel de démarrage) des fabricants.
Sources
- NVIDIA Didn’t Want Me to Do This… Linux on RTX Spark, Alex Ziskind sur YouTube, 31 octobre 2026
- Linux on the Nvidia RTX Spark Laptop: What Actually Works, MindStudio, 1er novembre 2026
- RTX Spark N1X (10de:2e03): GPU runs at ~190 MHz on AC; NVPCF only answers DSM revision 0x300, which the Linux RM never asks, NVIDIA/open-gpu-kernel-modules sur GitHub, 4 novembre 2026
- acpidsmguids.h, version 615.78.08 des modules, Nvidia sur GitHub, 7 octobre 2026
- acpidsmguids.h, version 620.70.06 des modules, Nvidia sur GitHub, 5 novembre 2026
- NVIDIA RTX Spark, page produit, Nvidia, consultée le 5 novembre 2026
- Use NVIDIA’s RTX Spark driver in omarchy-power-profiles-daemon, Omarchy sur GitHub, 14 octobre 2026
- Nvidia RTX Spark encrypted firmware slows inference speed to 35% on Linux, Hacker News, 4 novembre 2026
Image d’en-tête : graphique MACCUS, données Alex Ziskind (31 octobre 2026) et MindStudio (1er novembre 2026).
