NVIDIA DGX Spark · 9 November 2026

LLM open source sur NVIDIA GB10 DGX Spark : la carte complète de l’automne 2026 (moteurs, MoE, fine-tuning, clusters)

La promesse est séduisante : 128 Go de mémoire unifiée dans une station de bureau lancée à 3 999 $. La réalité est plus subtile : une bande passante d’environ 273 Go/s qui plafonne tout, un GPU Blackwell SM12.1 qui refuse les builds standards de vLLM, et une orchestration qui demande du doigté. Mais un an après le lancement, l’écosystème a mûri — et la gamme s’est dédoublée. DeepSeek V4 Flash tourne en cluster avec speculative decoding, le fine-tuning local est passé à l’échelle avec Unsloth, NVIDIA a ouvert une porte d’entrée à 64 Go à 4 999 $, et une release logicielle d’octobre 2026 a rebattu les cartes côté pile d’inférence. Voici l’état de l’art complet, vérifié source par source.

Le paradoxe du GB10 : 128 Go qui promettent tout, une bande passante qui décide tout

Quand NVIDIA a annoncé le DGX Spark en octobre 2025, la fiche technique a fait tourner les têtes : un SoC Grace Blackwell GB10 avec 128 Go de mémoire unifiée CPU/GPU, une architecture GPU SM12.1, un CPU ARM64 (SBSA), et un prix de lancement de 3 999 $ qui le positionnait comme la « workstation IA de bureau » par excellence. La promesse implicite : faire tourner des modèles de 70 milliards de paramètres en local, sans cloud, sans latence, sans compromis. NVIDIA a d’ailleurs démarré les livraisons dès le lancement, via son site et ses partenaires OEM — Acer, ASUS, Dell Technologies, Gigabyte, HP, Lenovo et MSI (ChannelNews).

La réalité physique est plus têtue. Cette mémoire unifiée, aussi généreuse soit-elle, est bridée par une bande passante d’environ 273 Go/s — un chiffre qui n’apparaît pas dans la communication NVIDIA mais qui circule dans les analyses techniques indépendantes. Pour un LLM, c’est le facteur qui décide de tout. Le décodage (decode) d’un token est fondamentalement un problème de bande passante : chaque token généré nécessite de relire l’intégralité des poids du modèle. Avec un modèle de 70B en FP8 (~70 Go), une bande passante de 273 Go/s plafonne théoriquement le débit à environ 3,9 tokens/s en mono-utilisateur. En pratique, les quantifications et les architectures MoE changent la donne, mais la contrainte reste là.

Ajoutez à cela l’absence de NVLink-C2C entre le CPU et le GPU — contrairement aux DGX plus gros et à la DGX Station, dont le CPU Grace et le GPU Blackwell sont reliés par NVLink-C2C — et vous obtenez une machine dont les performances dépendent autant du logiciel que du matériel. C’est exactement le point de départ du test exhaustif mené par Dre Dyson et relayé sur le forum développeur NVIDIA : une exploration systématique des combinaisons possibles entre LiteLLM, llama-swap et les moteurs d’inférence. Le résultat de ce travail, c’est une architecture de référence qui transforme le Spark en véritable multiplexeur de modèles — à condition de savoir ce que l’on fait.

Une gamme qui se dédouble : la Spark 64 Go à 4 999 $ et la flambée des 128 Go

L’actualité matérielle la plus marquante de cet automne ne concerne pas les performances, mais le catalogue. NVIDIA a officialisé le 2 octobre 2026 une seconde SKU du DGX Spark, dotée de 64 Go de mémoire unifiée, commercialisée à partir du 23 octobre 2026 au prix de 4 999 $ — soit 1 000 $ de plus que le tarif de lancement de la version 128 Go en 2025 (Hardwareluxx Russia, kod.ru). Le paradoxe est savoureux : la machine « au rabais » est aujourd’hui plus chère que l’originale ne l’était à sa sortie.

La raison tient en un mot : la mémoire. Le marché DRAM traverse une flambée sans précédent, et NVIDIA n’y échappe pas. La version 128 Go, elle, a vu son prix s’envoler jusqu’à 6 950 $ — au point que la nouvelle entrée de gamme à 64 Go devient, en valeur absolue, la configuration la plus accessible du catalogue (Next.ink, Clubic). Cette SKU divise la communauté : elle suffit pour l’inférence de modèles 30B en quantification agressive et pour du LoRA léger, mais elle ferme la porte aux modèles 70B+ en FP8 et aux contextes longs, qui restent l’apanage des 128 Go. Pour un cluster, la question devient purement économique : deux Spark 64 Go offrent plus de mémoire agrégée que deux Spark 128 Go pour un budget comparable — au prix d’une bande passante par nœud identique et d’une complexité d’orchestration accrue.

En parallèle, la concurrence s’organise. Acer a livré ses propres mini-PC RTX Spark à partir du 8 septembre 2026, avec 128 Go unifiés et un positionnement 500 à 1 000 $ sous le DGX Spark officiel. ASUS a présenté à l’IFA 2026 sa gamme ProArt RTX Spark (GR1X, P14, P16), jusqu’à 1 pétaflop annoncé pour les agents IA locaux, et a complété le 5 octobre 2026 avec l’Ascent GX10 64GB, un « supercalculateur agentique compact » taillé pour les modèles 30–35B (ASUS). Et NVIDIA a discrètement publié PAIR (Personal AI Router), un outil open source gratuit qui fédère les machines compatibles d’un réseau domestique en un « centre de données IA personnel » — un signal clair que la stratégie locale de NVIDIA ne s’arrête pas au Spark isolé.

La concurrence ne s’arrête pas à la gamme GB10. AMD a lancé son Ryzen AI Halo 192 Go à 7 299,99 $ chez Micro Center, premier desktop compact capable de charger des modèles open-weight de 300 milliards de paramètres — mais les benchmarks indépendants donnent toujours l’avantage au DGX Spark sur la vitesse (TechTimes, 14 octobre 2026). Et NVIDIA prépare le terrain au-dessus avec la DGX Station for Windows (748 Go de mémoire cohérente, 20 pétaflops FP4, lancement Q4 2026 via six partenaires OEM) — la vraie machine pour qui veut du NVLink-C2C et du fine-tuning lourd (tech-insider.org, 8 octobre 2026).

Écosystème logiciel : la release d’octobre 2026, CUDA 13.4 et le tournant MoE

Depuis le lancement, l’écosystème logiciel du DGX Spark a considérablement évolué. La version de CUDA a progressé : les containers NGC officiels de NVIDIA pour DGX Spark tournent désormais sous CUDA 13.4, qui apporte son lot d’optimisations pour l’architecture SM12.1. En parallèle, NVIDIA a publié en juillet 2026 une première preview de CUDA 13.4 pour Windows sur Arm — un signal fort pour la future plateforme RTX Spark, qui partage l’architecture GB10 avec le DGX Spark. Les développeurs peuvent dès maintenant préparer des applications natives Arm64, et SEGA l’a déjà prise en charge. Le firmware du Spark a d’ailleurs intégré, début septembre 2026, un certificat de démarrage Windows UEFI, confirmant la bascule prochaine de tout un pan de l’écosystème vers Windows-on-Arm.

Mais le fait logiciel majeur de cet automne est ailleurs. Le 21 octobre 2026, NVIDIA a déployé sa release logicielle d’octobre 2026 pour le DGX Spark — et les partenaires GB10 (Acer, ASUS et consorts) reçoivent les mêmes mises à jour (forum développeur NVIDIA). Cette release s’accompagne d’un travail de fond sur l’inférence mixture-of-experts : le 27 octobre, NVIDIA a publié sur son blog technique les trois leviers d’accélération MoE sur DGX Spark, mesurés sur Ling-3.0-flash d’Inclusion AI en batch-size 1 (NVIDIA Technical Blog). Le résultat : le temps par token de sortie passe de 27,71 ms à 9,72 ms, soit un gain de débit de 42,5 % — et une ré-exécution du benchmark GSM8K qui montre quelle part de ce gain synthétique survit à une charge réelle (blog.neticslabs.com, 31 octobre 2026). Nous y revenons en détail plus bas, car c’est probablement l’optimisation la plus rentable à activer aujourd’hui sur un Spark.

Côté moteurs d’inférence, le paysage s’est enrichi. TensorRT-LLM est désormais pleinement supporté sur le GB10, avec des kernels optimisés pour la quantification FP8 et MXFP4. NVIDIA a même détaillé un workflow en ligne de commande pour faire tourner Nemotron-3.5 Lightning sur DGX Spark 64 Go, benchmarks et résultats de speculative decoding à l’appui (blockchain.news, 30 octobre 2026). vLLM reste le moteur de production par excellence, mais il a été rejoint par Atlas, un moteur écrit en Rust qui promet une « Kernel Hypercompilation » et qui affiche des performances impressionnantes : 82 tokens/s sur Qwen3-Next-80B sur un seul Spark. Son installation se fait en deux minutes, mais il ne supporte pas encore le fine-tuning — un manque que la communauté espère voir comblé.

Le speculative decoding s’est imposé comme la technique phare de 2026. vLLM supporte désormais nativement le DSpark (draft model intégré) pour DeepSeek V4 Flash, et le Multi-Token Prediction (MTP) pour Qwen3.8-Flash-Next. Sur ce dernier, le MTP apporte un speedup de 1,67x (de 83 à 138 tok/s) sans perte de qualité, grâce à une vérification exacte des tokens prédits (banandre.com, 2 septembre 2026). Le moteur Uzu a également publié son implémentation de speculative decoding, d’abord pour Qwen3.6 27B, avec un support imminent pour Qwen3.8 27B et Muse Glimmer (trymirai.com, 3 septembre 2026).

Les modèles open-weight stars du moment sur le Spark sont nombreux. En juillet 2026, Ant Ling-3.0-Flash (124B-A5B) a fait une entrée remarquée : un modèle MoE à attention hybride (KDA et MLA empilés 5:1), avec 5 milliards de paramètres actifs, une fenêtre de contexte native de 256K tokens extensible à 1M, et un débit de 15-20 tokens/s sur un seul DGX Spark — c’est d’ailleurs le modèle de référence choisi par NVIDIA pour ses mesures MoE d’octobre. Poolside Laguna S 2.1 (118B) est sortie le 23 juillet 2026, présentée comme le plus puissant modèle open-weight occidental pour le codage. Et DeepSeek V4 Flash 0731 a redéfini les attentes en matière d’agents privés : avec seulement 13B de paramètres actifs, elle offre des performances agentiques de niveau frontière sur un cluster de deux DGX Spark.

Les trois leviers MoE de NVIDIA : 27,71 ms → 9,72 ms par token

C’est la nouveauté la plus exploitable de l’automne, et elle mérite qu’on s’y arrête. Dans son évaluation en batch-size 1 de Ling-3.0-flash, NVIDIA a identifié que le goulot d’étranglement n’est pas là où on l’attend : à cette taille de lot, le décodage est dominé par la dispersion des accès mémoire aux experts et par le coût de routage, pas par le calcul matriciel. Trois leviers en découlent (NVIDIA Technical Blog, 27 octobre 2026) :

1. L’ordonnancement des experts — regrouper les tokens qui sollicitent les mêmes experts pour transformer des accès aléatoires en accès contigus, ce qui réduit drastiquement les défauts de cache sur une mémoire unifiée où la latence compte autant que la bande passante.
2. Le cache d’experts — garder les experts les plus fréquemment routés résidents en mémoire rapide plutôt que de les recharger à chaque token.
3. La précision des routes — alléger le calcul de routage lui-même, qui devient significatif quand le nombre de paramètres actifs par token est faible (5B pour Ling-3.0-flash).

Le gain mesuré est spectaculaire sur le papier : 27,71 ms à 9,72 ms par token de sortie. Mais la ré-exécution de GSM8K par des observateurs indépendants (blog.neticslabs.com, 31 octobre 2026) apporte la nuance indispensable : une partie du gain est synthétique et dépend du profil de routage. Sur une charge réelle, le gain reste substantiel mais inférieur au chiffre marketing. La leçon à retenir pour votre propre Spark : activez ces trois leviers, mais mesurez sur votre workload, pas sur le benchmark publié.

Pourquoi le MoE est-il le format naturel d’un GB10 à mémoire unifiée ? Parce que la contrainte du Spark est la bande passante, et que le MoE ne relit par token que les paramètres actifs. Un modèle de 124B à 5B actifs coûte, en lecture de poids, l’équivalent d’un dense de 5B — tout en offrant la capacité d’un 124B. C’est exactement le compromis que la machine récompense. La cartographie des MoE ouverts qui tiennent sur un seul Spark en 2026 s’est d’ailleurs bien étoffée : Ling-3.0-Flash, Qwen3.8-Flash-Next, DeepSeek V4 Flash, et les variantes 30–35B-A3B qui atteignent jusqu’à 67 tok/s en GGUF via llama.cpp sur un seul nœud.

Pourquoi vLLM refuse de tourner « out of the box » sur le GB10

C’est le premier choc pour quiconque débarque sur le DGX Spark avec des habitudes de workstation NVIDIA classique : vLLM, le moteur d’inférence le plus utilisé en production, ne fonctionne pas avec un simple pip install. L’architecture SM12.1 du GPU Blackwell, combinée au CPU ARM64, exige des builds personnalisés.

La communauté a répondu avec deux projets GitHub essentiels. Le premier, spark-vllm-docker (par eugr), fournit des wheels pré-compilés de vLLM et FlashInfer, spécifiquement adaptés au GB10. Le second, spark-vllm-mxfp4-docker (par christopherowen), va plus loin : il propose des forks de vLLM, FlashInfer et CUTLASS qui activent la quantification native MXFP4 — un format 4 bits dont le GB10 tire parti matériellement. C’est ce fork qui permet d’atteindre les performances les plus impressionnantes documentées sur la machine.

La stabilité dépend ensuite d’un écosystème logiciel en évolution rapide. Les containers NGC officiels de NVIDIA pour DGX Spark, les versions de CUDA (12.8 puis 13, désormais 13.4), PyTorch et les nightly builds de vLLM conditionnent tout. Un utilisateur du forum NVIDIA résume bien l’état d’esprit : « It works reliably but it is not fast » — ça fonctionne de manière fiable, mais ce n’est pas rapide. Cette phrase, prononcée à propos du fork MXFP4, dit beaucoup de la maturité actuelle de la plateforme : les fondations sont solides, mais l’optimisation fine reste un travail de spécialiste.

LiteLLM et llama-swap : le duo qui transforme 128 Go en multiplexeur de modèles

L’architecture recommandée par le test de Dre Dyson est simple dans son principe, élégante dans son exécution. Votre application parle à LiteLLM (port 14000), qui agit comme une passerelle API unifiée compatible OpenAI. LiteLLM route ensuite les requêtes par nom de modèle vers llama-swap (port 28080), l’orchestrateur qui décide quel moteur d’inférence doit être réveillé.

Le cœur du système, c’est le mécanisme de hot-swap de llama-swap. Plutôt que de garder tous les modèles chargés en mémoire — impossible avec 128 Go partagés —, llama-swap démarre des conteneurs Docker éphémères à la demande et les évince après un délai d’inactivité. Concrètement, il définit trois tiers de modèles avec des limites de VRAM strictes :

Le tier L est particulier : charger un modèle de cette taille (typiquement un 70B+ en FP8) évince automatiquement tous les autres modèles. C’est un choix assumé : sur 128 Go de mémoire unifiée, seuls ~108 Go sont utilisables après démarrage du système, et un modèle L mange presque tout l’espace. Sur la nouvelle Spark 64 Go, cette architecture demande d’être repensée de fond en comble : le tier L disparaît, et la frontière se déplace vers des modèles 30B en Q4/Q5 avec un KV cache réduit.

La gestion de la fragmentation mémoire est un autre défi. Chaque conteneur Docker réserve sa part de VRAM, et les allers-retours de chargement/déchargement laissent des trous. Le test recommande de configurer soigneusement les variables d’environnement Docker et les limites de chaque tier pour éviter les OOM — un sujet que nous détaillons plus bas.

vLLM, llama.cpp, Ollama, Atlas : quatre philosophies face à la mémoire unifiée

C’est ici que le comparatif devient intéressant, car chaque moteur incarne une philosophie différente de l’inférence.

vLLM est le moteur de production par excellence. Son continuous batching (PagedAttention) lui permet de traiter 32+ requêtes simultanément en réorganisant dynamiquement les lots. C’est un avantage décisif pour les agents ou les applications multi-utilisateurs. En revanche, vLLM nécessite des builds personnalisés sur le GB10, et il ne supporte que les formats Safetensors (FP8, MXFP4 via le fork de christopherowen). Pas de GGUF ici. Depuis août 2026, vLLM intègre officiellement le support de DeepSeek V4 Flash avec speculative decoding DSpark et MTP.

llama.cpp reste le couteau suisse. Il avale les GGUF, tourne sur CPU comme sur GPU, et c’est lui qui offre les débits mono-utilisateur les plus élevés sur les petits MoE : jusqu’à 67 tok/s sur un 35B-A3B. C’est aussi le moteur de référence pour les quantifications agressives (IQ2_XXS, Q4_K_M) qui permettent de faire tenir un DeepSeek V4 Flash sur un seul Spark — antirez a mesuré environ 14 tok/s en single-stream et 410 t/s en prefill avec un IQ2_XXS sur un seul nœud. Le compromis : pas de batching continu sophistiqué, donc des performances qui s’effondrent en multi-utilisateur.

Ollama est l’entrée de gamme confortable. Il encapsule llama.cpp derrière une API simple, gère le téléchargement des modèles et le hot-swap de façon transparente. C’est le bon choix pour prototyper, pas pour produire : le contrôle sur la mémoire et les paramètres d’inférence est trop limité pour un Spark qu’on veut exploiter à fond.

Atlas est le nouveau venu qui bouscule la hiérarchie. Écrit en Rust, il promet une « Kernel Hypercompilation » — la génération de kernels spécialisés à la volée pour l’architecture cible — et affiche 82 tok/s sur Qwen3-Next-80B sur un seul Spark. Son installation en deux minutes contraste avec les builds vLLM à la main. Sa limite actuelle : pas de fine-tuning, et un écosystème encore jeune.

Le tableau ci-dessous résume les compromis sur un Spark 128 Go :

Fine-tuning : la Spark n’est plus seulement une machine d’inférence

Le basculement est net en 2026 : le DGX Spark, vendu comme machine d’inférence et d’agents locaux, est devenu une plateforme de post-entraînement crédible. LoRA, QLoRA, DoRA, RL, diffusion — les retours d’expérience se sont accumulés, et la chaîne outillée s’est stabilisée autour d’Unsloth, qui documente désormais explicitement le fine-tuning sur DGX Spark (Unsloth) et sur DGX Station.

Ce que la mémoire unifiée change vraiment au fine-tuning : les 128 Go partagés CPU/GPU permettent de charger un modèle de base plus gros que sur une carte graphique classique de même prix, et surtout de garder les activations, les gradients et l’optimiseur dans le même espace d’adressage. Sur un Spark 128 Go, un LoRA sur un modèle 30–35B est confortable ; un QLoRA en 4 bits ouvre la porte à des modèles plus gros au prix d’un peu de qualité. La Spark 64 Go, elle, reste un outil réel pour du LoRA léger et du QLoRA sur des modèles 30B, mais ferme la porte aux runs lourds.

La chaîne complète, du dataset brut à l’adaptateur, suit toujours les mêmes étapes : préparation du dataset (format chat, masquage des prompts), choix de la méthode (LoRA, QLoRA, DoRA), réglage du rang, de l’alpha, du learning rate et de la longueur de séquence, entraînement sous Unsloth avec les kernels optimisés, puis fusion de l’adaptateur et quantification pour l’inférence. Les réglages qui font ou cassent un run sur GB10 sont documentés : un rang trop élevé sur un petit dataset surapprend, un learning rate trop haut sur un MoE déstabilise le routage, et une longueur de séquence mal calibrée fait exploser le KV cache.

Côté logiciel, la release d’octobre 2026 et CUDA 13.4 ont compté pour le fine-tuning : compatibilité PyTorch améliorée sur Arm64, kernels FlashAttention plus stables, et surtout un écosystème de notebooks Unsloth (plus de 250) qui tournent désormais sans patch sur la machine. Pour les charges plus lourdes — gpt-oss-120b, Qwen3.5-35B-A3B — c’est vers la DGX Station (200+ Go de VRAM, 700+ Go de mémoire unifiée, NVLink-C2C) qu’il faut se tourner, pas vers le Spark.

Clusters DGX Spark : quand deux (ou quatre) nœuds changent l’équation

Le vrai saut de performance du Spark ne vient pas d’un nœud, mais de plusieurs. Un cluster de deux Spark change la catégorie de la machine : la mémoire agrégée atteint 256 Go, ce qui permet de charger des modèles jusqu’à 405 milliards de paramètres, et le tensor parallelism (TP=2) sous vLLM transforme les débits.

Les chiffres canoniques, mesurés sur deux Spark en TP=2 avec vLLM et DeepSeek-V4-Flash en FP8 :

• Single-stream : ~41 tok/s (contre ~14 tok/s pour un seul nœud en IQ2_XXS via llama.cpp — la comparaison n’est pas parfaitement homogène, mais elle donne l’ordre de grandeur du gain).
• Prefill : ~1 785 tok/s.
• Débit agrégé à concurrence 32 : ~350 tok/s.

C’est ce dernier chiffre qui compte pour un agent ou un service multi-utilisateurs : 350 tok/s agrégés, c’est le niveau d’un petit serveur d’inférence, dans deux boîtes de bureau. Le pari de Dre Dyson — faire tourner Qwen3.5-397B-A17B sur deux Spark — illustre la limite haute : 397 milliards de paramètres tiennent dans 256 Go, mais à un débit qui impose des compromis, et pour un budget d’environ 12 000 $.

L’orchestration reste le point sensible. Le tensor parallelism exige une interconnexion réseau correcte (les deux nœuds doivent se voir à faible latence), et la configuration vLLM en TP=2 sur GB10 demande les mêmes builds personnalisés que sur un nœud seul, avec en plus la synchronisation des processus. La release d’octobre 2026 et les outils de type PAIR simplifient la fédération, mais on reste loin du plug-and-play d’un cluster DGX classique.

La question économique, elle, se pose désormais en trois options : deux Spark 64 Go (mémoire agrégée supérieure, budget contenu, mais bande passante par nœud identique et complexité accrue), deux Spark 128 Go (la configuration de référence pour les gros modèles, mais à 6 950 $ l’unité), ou une DGX Station (NVLink-C2C, 748 Go de mémoire cohérente, 20 pétaflops FP4 — mais un autre budget et un lancement Q4 2026). Pour un laboratoire qui veut de l’inférence agentique privée à l’échelle d’une équipe, deux Spark 128 Go restent le meilleur compromis en octobre 2026.

Ce qu’il faut retenir pour votre Spark en octobre 2026

Trois conclusions se dégagent de cet automne. D’abord, la release logicielle d’octobre 2026 et les trois leviers MoE de NVIDIA sont le gain le plus immédiat : 27,71 ms à 9,72 ms par token sur Ling-3.0-flash, à activer et à mesurer sur votre propre charge. Ensuite, la gamme s’est complexifiée : la Spark 64 Go à 4 999 $ est une porte d’entrée réelle pour l’inférence 30B et le LoRA léger, mais les 128 Go à 6 950 $ restent la seule option pour les 70B+ et les contextes longs — et le cluster de deux nœuds est ce qui transforme vraiment la machine. Enfin, l’écosystème a mûri mais reste exigeant : vLLM demande toujours des builds personnalisés sur SM12.1, Atlas promet la simplicité mais pas encore le fine-tuning, et le fine-tuning lui-même passe par Unsloth avec des réglages précis.

Le DGX Spark n’est plus une promesse : c’est une plateforme avec des forces claires (mémoire unifiée, MoE, cluster) et des limites claires (bande passante, builds, orchestration). Savoir lesquelles s’appliquent à votre workload, c’est tout l’enjeu.

Sources

• NVIDIA Technical Blog — 3 Ways to Boost MoE Inference on NVIDIA DGX Spark (27 octobre 2026)
• blog.neticslabs.com — Three MoE Inference Optimizations on DGX Spark (31 octobre 2026)
• Forum développeur NVIDIA — DGX Spark Software Updates, October 2026 Release (21 octobre 2026)
• blockchain.news — NVIDIA details edge AI workflow for DGX Spark and TensorRT Edge-LLM (30 octobre 2026)
• ASUS — Ascent GX10 64GB: Compact Agentic AI Supercomputer (5 octobre 2026)
• TechTimes — AMD Ryzen AI Halo 192GB Loads Models No Rival Can: DGX Spark Still Wins on Speed (14 octobre 2026)
• tech-insider.org — NVIDIA DGX Station for Windows: 748GB, 20 PFLOPs (8 octobre 2026)
• Next.ink — Le DGX Spark descend à 64 Go, NVIDIA moteur et victime de la pénurie de mémoire
• Clubic — NVIDIA lance un DGX Spark 64 Go, moins de mémoire mais une drôle d’astuce pour dépasser le modèle 128 Go
• ChannelNews — NVIDIA lance DGX Spark, une station de travail pour l’IA
• Unsloth — Fine-tuning des LLM avec NVIDIA DGX Spark et Unsloth
• Unsloth — Fine-tuning des LLM sur NVIDIA DGX Station avec Unsloth
• banandre.com (2 septembre 2026) — MTP Qwen3.8-Flash-Next
• trymirai.com (3 septembre 2026) — speculative decoding Uzu
• Hardwareluxx Russia, kod.ru — SKU 64 Go

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