Faire tourner des LLMs sur le DGX Spark

Le DGX Spark est un ordinateur IA compact de NVIDIA équipé d’une puce GB10. Le CPU et le GPU partagent la mémoire. Il permet d’exécuter des modèles de langage localement et se place à côté d’un bureau.

Le détail intéressant est dans le compute FP4. NVIDIA présente le Spark avec un petaFLOP FP4, mais sur sm_121 il manque le chemin d'instructions dont NVFP4 a besoin. vLLM prévient lui-même et retombe sur Marlin, qui déquantise les poids 4-bit vers BF16. Tu stockes donc en 4-bit, et ce gain mémoire est réel, mais tu calcules à un niveau plus élevé. Pour le compute pur c'est un inconvénient, pour la mémoire et la bande passante non, et sur ce matériel c'est là qu'est le gain.

La règle du pouce : la taille du modèle en milliards de paramètres, fois les octets par paramètre, c'est ce que tu dépenses en mémoire. BF16 coûte 2 octets par paramètre, FP8 un, NVFP4 un demi. Un modèle 30B en BF16, c'est donc environ 60 Go de poids, en NVFP4 plus que 15. À ça s'ajoute le KV cache, et il grandit avec ta longueur de contexte.

Ce qui tient dans 128 Go dépend de la taille et de la précision du modèle. Après le chargement des poids, il faut garder de la place pour le cache KV. La précision influence donc aussi le contexte utilisable.

Le prefill traite le prompt ; le decode génère les tokens de réponse. Avec des prompts courts, la vitesse de sortie est la plus visible. Les prompts longs peuvent demander beaucoup de traitement initial. Dans mes tests sur le Spark, ce délai augmentait fortement avec les grands contextes.

Lors de mon test de surcharge, les requêtes restaient en file d’attente et le serveur ne plantait pas. Le délai augmentait toutefois. Vérifiez donc le temps d’attente en charge en plus du débit.

Les chiffres exacts par modèle et longueur de contexte sont dans la suite de benchmarks, tournée sur un seul Spark avec un protocole de mesure fixe. Le raisonnement derrière ces trois chiffres est dans un essai à part.

J’utilise vLLM pour servir les modèles via une API. Il prend en charge la configuration NVFP4 que je teste et peut traiter les prompts longs par morceaux avec le chunked prefill.

Le chunked prefill est activé dans ma configuration. J’ajuste max-num-batched-tokens et l’utilisation de la mémoire à la longueur de contexte souhaitée. Ces paramètres influencent la stabilité et le débit. La configuration figure dans le journal de développement sur Gemma-4.

Une API cloud peut être plus pratique si vous pouvez y traiter vos données et ne souhaitez pas gérer un serveur de modèles. Un Spark est une option pour garder le contrôle du traitement.

Le matériel n'est qu'une partie du choix. Le guide de décision IA locale compare aussi qualité, frontières de données, opérations, coûts et évolution.

Pense aux PME et organisations qui travaillent avec des données personnelles, des documents internes ou des données clients qui doivent rester proches sous le RGPD. Là, la question n'est plus "quel est le modèle le plus rapide", mais "quelle partie a même le droit de sortir". Un Spark sous ton propre contrôle répond à ça bien plus facilement qu'un contrat avec un fournisseur cloud.

Avec votre propre matériel, vous choisissez la version du modèle et le moment des mises à jour. La machine limite la capacité. Vous gérez aussi la maintenance et les mises à jour.

Tous les chiffres de ce site proviennent d’un seul Spark, avec un protocole fixe : mêmes prompts, mêmes seeds et trois exécutions par mesure. La configuration, les prompts et les sorties brutes sont publics sur GitHub.

Vous obtenez d’autres résultats sur un autre Spark ou une autre version de vLLM ? Envoyez vos paramètres et vos mesures pour que nous puissions examiner les différences.