Une nouvelle puce ne transporte pas automatiquement son écosystème
RTX Spark assemble trois choix inhabituels pour un PC Windows : un CPU Grace Arm, un GPU Blackwell RTX et jusqu’à 128 Go de mémoire unifiée. NVIDIA annonce jusqu’à 6 144 cœurs CUDA, 20 cœurs CPU, 1 PFLOP FP4 et une pile CUDA native. Microsoft ajoute un ordonnanceur adapté aux 20 cœurs, une gestion thermique commune et un plafond mémoire GPU relevé pour laisser les grands modèles utiliser davantage de la RAM partagée.
Ces chiffres décrivent une famille, pas une configuration unique. Les mentions « jusqu’à » couvrent des portables et des petits PC de bureau conçus par Microsoft, ASUS, Dell, HP, Lenovo et MSI. Elles ne publient ni la bande passante mémoire, ni la puissance électrique soutenue, ni la quantité de mémoire réellement laissée au GPU après Windows et les applications.
Notre comparaison entre RTX Spark et DGX Spark posait déjà cette frontière matérielle. DGX Spark documente 273 Go/s de LPDDR5x. RTX Spark n’a pas encore de chiffre équivalent. Recopier 273 Go/s dans une fiche RTX Spark supposerait que le contrôleur, la fréquence, la largeur de bus et le profil de puissance sont identiques, ce que les sources ne disent pas.
Le problème logiciel commence un étage plus haut. Un modèle LLM ne consomme pas directement « CUDA ». Il traverse un pilote, un runtime, PyTorch ou un chargeur de tenseurs, des extensions compilées, des kernels d’attention, une gestion du KV cache, un serveur et parfois WSL. Chaque maillon doit exister pour Windows Arm64, pas seulement pour Windows x64 ou Linux aarch64.
Au 12 août, il faut distinguer livré, preview et annoncé
| Couche | État public | Ce que cela permet | Limite actuelle |
|---|---|---|---|
| Matériel RTX Spark | Annoncé pour l'automne | Cible finale portable et desktop | Pas de machine commerciale à mesurer |
| Pilote RTX Spark | Developer Preview | Développement CUDA sur Windows Arm | Problèmes connus et validation finale à venir |
| CUDA Toolkit 13.4 | Developer Preview | Compilation native Arm64 et cross-compilation | Pas une pile GA de production |
| TensorRT-RTX 1.6 | Support officiel Windows Arm | Compilation et exécution de graphes IA sur RTX | Ce n'est pas TensorRT-LLM |
| Windows ML + TensorRT | Intégration annoncée | Chemin natif via l'Execution Provider | Versions finales et couverture LLM à qualifier |
| PyTorch CUDA | Prévu, build en cours | Framework attendu pour l'écosystème Python | Timeout GPU possible pendant les builds |
| llama.cpp / Hugging Face / Unsloth | Prévus | Inférence et adaptation locale attendues | Pas de validation finale RTX Spark publiée |
| vLLM | Pas de Windows natif | WSL possible selon la documentation générale | Aucune recette RTX Spark WSL validée |
| TensorRT-LLM | Documentation Linux | Serving LLM optimisé sur les plateformes prises en charge | Pas de guide Windows Arm natif |
NVIDIA ne cache pas le statut. Son annonce du 16 juillet s’intitule RTX Spark Developer Preview et propose de commencer sur un appareil Windows on Arm existant. Le dernier pas de la procédure consiste à valider sur RTX Spark « lorsque le matériel et le logiciel pris en charge seront disponibles ». Cette phrase interdit de traiter le kit actuel comme une preuve de compatibilité finale.
La chronologie n’est pas un échec. Porter CUDA, les drivers, les compilateurs et les dépendances Python vers une nouvelle combinaison OS et architecture demande une phase de transition. Elle impose simplement de séparer une API compilable d’un système de serving reproductible.
CUDA natif résout le bas de la pile
Prism permet à Windows 11 on Arm d’exécuter des applications x86 et x64. Il traduit leurs instructions CPU vers Arm et bénéficie sur RTX Spark d’optimisations propres au microprocesseur. Cette compatibilité aide un éditeur, un IDE ou une interface graphique qui n’a pas encore de binaire natif.
Elle ne traduit pas le noyau. Microsoft exige que les pilotes en mode kernel et les pilotes d’impression soient compilés en Arm64. Une extension Python qui contient du C++ ou du CUDA doit aussi être compatible avec l’architecture du processus qui la charge. Un processus Arm64 ne peut charger qu’une DLL Arm64 ; un processus x64 ou Arm64EC suit d’autres conventions binaires.
NVIDIA fournit donc les pièces que Prism ne peut pas inventer : pilote Arm64, compilateur CUDA 13.4 et pilote x64 de cross-compilation. Le développeur peut porter le code CPU, reconstruire ses extensions et vérifier le chemin CUDA depuis une autre machine Windows on Arm avant l’arrivée du GPU final.
Cette chaîne explique pourquoi « CUDA fonctionne » ne suffit pas à conclure « vLLM fonctionne ». vLLM compile de nombreux kernels et dépend d’une combinaison précise de PyTorch, Triton, FlashAttention ou FlashInfer, NCCL et bibliothèques système. Une roue manquante ou une ABI incompatible bloque le serveur avant le premier token.
TensorRT-RTX est prêt, mais ce n’est pas TensorRT-LLM
TensorRT-RTX 1.6 est la première brique avec un statut net. Ses notes de version ajoutent une prise en charge officielle de Windows on Arm pour RTX Spark, CUDA 13.4 et un chemin zéro copie adapté à la mémoire unifiée. Une application peut allouer des buffers d’entrée et de sortie mappés avec cudaMallocHost() et éviter des copies explicites hôte-vers-device puis device-vers-hôte.
Le terme zéro copie ne signifie pas qu’aucun octet ne circule ou que le CPU et le GPU lisent à la même vitesse. Il signifie que les deux processeurs peuvent adresser le buffer mappé sans que l’application organise deux transferts séparés. Le coût se déplace vers les accès mémoire réels, le placement des pages et la cohérence. Sans bande passante RTX Spark publiée, impossible d’en déduire un débit LLM.
TensorRT-RTX compile des graphes ONNX ou issus de PyTorch pour les GPU RTX. TensorRT-LLM ajoute les structures propres au serving des modèles génératifs : moteurs de modèles, batching, KV cache, parallélisme, speculative decoding et serveur. Les documentations de TensorRT-LLM proposent une installation par conteneur ou pip sur Linux, testée sur Ubuntu 24.04. Le support Windows de TensorRT-RTX ne se propage pas automatiquement à TensorRT-LLM.
PyTorch est le test de maturité du milieu de pile
Microsoft formule prudemment sa promesse : le partenariat prévoit d’apporter PyTorch accéléré par CUDA, llama.cpp, TensorRT, les frameworks Hugging Face, Unsloth et Kohya. La même page distingue ces technologies futures des applications Arm natives déjà disponibles, comme Blender ou DaVinci Resolve.
Le forum NVIDIA confirme que PyTorch n’est pas encore un chemin banal. Ses problèmes connus signalent qu’une CI ou une compilation PyTorch peut déclencher un timeout GPU, rendre le système inerte ou provoquer un redémarrage. Ce défaut concerne un workflow de construction, pas nécessairement l’inférence d’une roue finale. Il montre cependant que l’étage framework reste en validation.
llama.cpp devrait demander moins de dépendances qu’un serveur Python complet : son backend CUDA et son format GGUF concentrent davantage de code dans un même projet. « Devrait » reste une hypothèse d’ingénierie. Au 12 août, NVIDIA et Microsoft ne publient ni binaire RTX Spark final, ni matrice de modèles, ni résultats reproductibles avec tailles de contexte et paramètres de quantification.
La bonne grille ne consiste pas à demander si l’exécutable démarre. Il faut vérifier si le modèle se charge sans duplication de mémoire, si les kernels réellement utilisés sont accélérés, si le KV cache reste dans la limite GPU, si le prompt long ne déclenche pas de pagination hostile et si le débit tient après plusieurs minutes sous le profil thermique du portable.
vLLM sous WSL reste une possibilité, pas encore une recette
La documentation vLLM écrit deux faits utiles. Son système complet ne fonctionne que sous Linux ; Windows n’est pas pris en charge nativement. Pour un PC Windows, le projet recommande WSL avec une distribution Linux compatible ou un fork communautaire. Il sait aussi construire une image linux/arm64 pour Grace Hopper et Grace Blackwell.
Assembler ces deux faits donne une piste, pas une validation RTX Spark. WSL doit exposer le GPU Blackwell au conteneur Linux Arm64. La version du pilote hôte doit correspondre au runtime CUDA invité. PyTorch et les dépendances doivent fournir des wheels aarch64 compatibles, puis les kernels doivent reconnaître la cible du GPU RTX Spark. Aucun guide officiel ne publie encore cette combinaison complète avec une mesure de débit.
WSL peut devenir le chemin le plus court vers l’écosystème Linux de serving. Microsoft met d’ailleurs en avant l’accès à cet écosystème pour DGX Station sous Windows. L’absence d’une recette RTX Spark au 12 août interdit seulement d’en faire une caractéristique acquise des premiers portables.
La mémoire unifiée enlève une copie, pas le plafond de bande passante
La capacité de 128 Go ouvre des modèles qui dépassent les 24 ou 32 Go d’une carte mobile. Un checkpoint quatre bits de 70 milliards de paramètres approche 35 Go pour ses valeurs brutes ; les échelles, le KV cache, le contexte et les buffers augmentent ce total. Une enveloppe de 128 Go laisse une marge qu’un GPU discret grand public n’offre pas.
Le CPU et le GPU partagent toutefois la même mémoire physique. Ils se disputent sa capacité et sa bande passante. Windows, le cache disque, le navigateur et les services résidents occupent une partie de l’espace. Le GPU relit les poids pendant le decode ; si la mémoire livre moins d’octets par seconde qu’une RTX 5090, une plus grande capacité peut charger un modèle plus gros tout en produisant moins de tokens par seconde.
Microsoft annonce un plafond plus élevé et « plus intelligent » sur la mémoire totale accessible au GPU ainsi que des pages plus grandes dans les régions partagées. Ces changements réduisent les limites artificielles et le coût de traduction d’adresses. Ils ne créent pas de bande passante supplémentaire. Le chiffre décisif reste absent de la fiche publique.
Les problèmes connus indiquent quoi mesurer
Le Developer Preview signale des transferts CUDA hôte-vers-device plus faibles que prévu avec de la mémoire pageable. NVIDIA recommande de verrouiller les pages via cudaMallocHost, cudaHostAlloc ou cudaHostRegister. TensorRT-RTX exploite précisément ce chemin pour son zéro copie. Une application qui conserve des buffers Python ordinaires peut donc mesurer un comportement très différent d’une application optimisée.
TensorRT-RTX documente aussi un échec possible de cudaMallocAsync() sur les systèmes à mémoire unifiée, même lorsque de la mémoire physique reste disponible. Le contournement consiste à fournir un allocateur fondé sur cudaMalloc(), avec une baisse possible de performance et la désactivation des CUDA Graphs. C’est un détail de release note, mais il touche directement les runtimes qui préallouent de larges pools.
Le pilote peut laisser l’écran noir environ deux minutes pendant l’installation, et Nsight Copilot n’est pas disponible dans la préversion Arm64. Ces limites ne condamnent pas la plateforme. Elles définissent un plan de qualification concret : buffers pinned contre pageable, allocateur asynchrone contre synchrone, graphes activés ou non, stabilité des builds, reprise après timeout et comportement thermique soutenu.
Le premier benchmark sérieux devra publier la pile entière
Comparer RTX Spark à une RTX 5090 ou à DGX Spark demandera plus qu’un même nom de modèle. Il faudra figer la machine exacte, la version de Windows, le pilote, CUDA, le framework, le runtime, le commit, la quantification et la longueur de contexte. Une configuration native Windows devra être distinguée de WSL ; Prism devra être identifié lorsqu’un processus x64 intervient.
Les mesures minimales sont le temps de chargement, le temps jusqu’au premier token aux percentiles 50 et 99, le débit de decode à concurrence 1 puis sous charge, la mémoire réellement disponible, la bande passante observée, l’énergie et la fréquence après trente minutes. Il faut ajouter les erreurs d’allocation, les recompilations de kernels et le nombre d’opérateurs retombés sur le CPU.
Au 12 août, tout classement chiffré manquerait au moins le matériel commercial et sa pile finale. La conclusion la plus favorable et la plus honnête est plus simple : Microsoft et NVIDIA ont franchi le verrou du pilote et du compilateur Arm64 ; TensorRT-RTX fournit déjà un chemin officiel ; la chaîne LLM complète n’a pas encore traversé le même niveau de preuve.
Windows peut gagner sans devenir Linux
RTX Spark n’a pas besoin de porter chaque outil Linux nativement le jour un pour devenir utile. TensorRT-RTX et Windows ML peuvent servir les applications distribuées aux utilisateurs finaux. WSL peut accueillir les serveurs de recherche et les dépendances qui restent liées à Linux. Prism peut conserver les outils x64 autour du chemin critique.
La réussite dépendra de la frontière entre ces trois mondes. Si le modèle passe de Python Arm64 à des extensions CUDA natives sans copie cachée, et si WSL expose le GPU sans casser les wheels aarch64, les 128 Go deviendront un vrai poste de développement LLM. Si chaque projet exige sa propre compilation et son propre contournement d’allocateur, RTX Spark restera une excellente démonstration matérielle avec un coût d’intégration trop élevé. L’automne ne devra donc pas seulement livrer des machines ; il devra livrer une matrice de versions reproductible.
Sources et méthode
- Microsoft, « Introducing a powerful new chapter for Windows PCs, accelerated by NVIDIA RTX Spark », 31 mai 2026. Source primaire pour le matériel annoncé, WPS, MPTF, la mémoire unifiée, Prism, Windows ML, les applications natives et la formulation « plans to bring » concernant la pile IA.
- NVIDIA, page produit RTX Spark, consultée le 12 août 2026. Source primaire pour les maxima de 6 144 cœurs, 20 cœurs CPU, 1 PFLOP FP4 et 128 Go, ainsi que le statut « Notify Me ». La page ne publie pas de bande passante mémoire.
- NVIDIA Developer Forums, « RTX Spark Developer Preview », 16 juillet 2026. Source NVIDIA pour le pilote, CUDA 13.4, la stratégie de portage et les problèmes connus. Il s’agit d’une préversion, pas d’une matrice GA.
- NVIDIA TensorRT-RTX 1.6, notes de version et guide d’installation, mis à jour le 27 juillet 2026. Sources primaires pour Windows Arm, CUDA 13.4, le zéro copie, les conditions de cache et les problèmes d’allocation.
- vLLM, installation GPU, consultée le 12 août 2026. Source primaire pour l’absence de support Windows natif, la recommandation WSL et la construction Linux arm64 sur Grace Blackwell.
- NVIDIA TensorRT-LLM, installation Linux, consultée le 12 août 2026. Source primaire pour le périmètre documenté Ubuntu, CUDA, PyTorch et conteneurs ; aucune installation Windows Arm native n’y est proposée.
- Microsoft Learn, FAQ Windows on Arm, portage Arm et Arm64EC. Sources primaires pour le périmètre de Prism, l’obligation de pilotes Arm64 et les règles de chargement entre architectures.
