Contexte matériel et logiciel

Les ordinateurs portables équipés du module Nvidia RTX Spark (ex. MSI Prestige N16 Flip AI Plus) utilisent le même GPU que le serveur DGX Spark. Sous Windows, le pilote propriétaire décrypte une table de puissance fournie par le firmware et autorise des fréquences d’horloge supérieures à 2 GHz. Sous Linux, le même GPU fonctionne avec le pilote open‑source de Nvidia, mais la fréquence maximale se bloque à environ 780 MHz dès que l’appareil est branché sur le secteur.

Cette limitation provient d’un composant nommé Nvidia Platform Controllers and Framework, visible uniquement dans le gestionnaire de périphériques Windows. Le firmware transmet à ce contrôleur une table de réglages de puissance chiffrée ; Windows possède la clé de déchiffrement, alors que le pilote Linux ne reçoit aucune version décryptée.

Impact sur les charges d’inférence

Les tests avec le modèle GPT‑OSS‑120B montrent un écart de débit de génération de texte. Sous Windows, le GPU atteint 65,4 tokens/s ; le même résultat est reproduit sous WSL (65,1 tokens/s) et sur le DGX Spark (61 tokens/s). En revanche, l’exécution native sous Linux ne dépasse que 13,9 tokens/s, soit près de cinq fois moins.

Avec le framework vLLM et huit clients simultanés, WSL délivre 127 tokens/s contre 39,5 tokens/s sous Linux. La différence persiste même lorsque le portable fonctionne sur batterie : la fréquence monte à 1 800 MHz et le débit atteint 61‑67 tokens/s, alors qu’en mode secteur la fréquence chute à ≈ 780 MHz et le débit tombe à ~15 tokens/s.

Gestion de la mémoire unifiée

Le système réserve par défaut 96 GB de la mémoire unifiée de 128 GB pour le GPU, ne laissant que 32 GB au CPU. Sous Linux, le pilote ne voit initialement que 28 GB de RAM, car le paramètre de répartition ne peut être modifié que depuis Windows. En réduisant la réservation GPU à 4 GB via l’interface Windows, Linux accède à plus de 120 GB, ce qui rend possible un bureau 4K à 120 Hz avec audio, clavier et pavé tactile fonctionnels.

Analyse technique et perspectives de correction

Les mesures de température (40‑47 °C) excluent un throttling thermique. La cause identifiée est donc purement logicielle : le contrôleur de plateforme ne s’active pas sous Linux, empêchant le pilote d’appliquer les profils de puissance élevés. Une désactivation du contrôleur dans Windows reproduit exactement la même chute de fréquence et de débit, confirmant que le firmware, et non le noyau Linux ou le pilote CUDA, limite les performances.

La résolution passe par une implémentation du même module de gestion de puissance dans le pilote Linux. Sans la clé de déchiffrement du tableau de puissance, le GPU restera limité à la fréquence basse, même si le matériel est capable de bien plus. En attendant, WSL constitue la solution la plus proche des performances Windows, car il exploite la pile de pilotes Windows tout en offrant un environnement Linux.