Deux vitesses qui comptent
Le débit de décodage est la vitesse à laquelle le modèle génère des jetons après avoir commencé à répondre, mesurée en jetons par seconde (tok/s). Il détermine la rapidité avec laquelle une réponse de chat ou une complétion de code apparaît à l’écran. La latence de préremplissage est le temps que le modèle met pour traiter votre entrée avant de générer le 1er jeton, mesuré en millisecondes par jeton (ms/jeton). Elle détermine la pause entre l’appui sur Entrée et le début du streaming de la sortie. Les charges de travail différentes privilégient des vitesses différentes :Le temps jusqu’au premier jeton (TTFT) combine la latence de préremplissage avec tout délai de planification ou de file d’attente. Pour un seul utilisateur sur du matériel local, le TTFT est approximativement égal au temps de préremplissage. Sous charge concurrente, la mise en file d’attente s’ajoute au TTFT de manière indépendante.
Ce que la précision signifie pour la vitesse
La précision contrôle le nombre de bits représentant chaque poids dans le modèle. Moins de bits signifie des poids plus petits, ce qui modifie 2 choses : la quantité de mémoire occupée par le modèle et la quantité de données que le GPU lit par jeton.Comment la précision affecte différemment le décodage et le préremplissage
Voici l’idée clé : le décodage et le préremplissage rencontrent des goulots d’étranglement matériels différents, donc le même changement de précision les affecte de manière inégale.Le décodage est limité par la bande passante mémoire
Pendant le décodage, le modèle génère 1 jeton à la fois. Pour chaque jeton, il lit toute la matrice de poids depuis la mémoire et effectue une petite quantité de calcul par poids. Le GPU passe la majeure partie de son temps à attendre que les données arrivent depuis la mémoire, plutôt qu’à faire des calculs. Des poids plus petits = moins de données à lire = décodage plus rapide. L’accélération est approximativement proportionnelle à la réduction de mémoire :- FP16 → FP8 : accélération du décodage d’environ 1.8-2.0x
- FP16 → INT4 : accélération du décodage d’environ 2.5-3.5x
- FP16 → NVFP4 : accélération du décodage d’environ 2.5-3.0x
Le préremplissage est limité par le calcul
Pendant le préremplissage, le modèle traite tous les jetons d’entrée en parallèle. Il lit les poids une fois mais effectue une grande multiplication matricielle sur tous les jetons de l’invite. Le GPU passe la majeure partie de son temps à faire des calculs, plutôt qu’à attendre la mémoire. La quantification aide moins le préremplissage car le calcul est le goulot d’étranglement, pas la lecture des poids :- FP16 → FP8 : accélération du préremplissage d’environ 1.3-1.5x
- FP16 → INT4 : accélération du préremplissage d’environ 1.2-1.5x
- FP16 → NVFP4 : accélération du préremplissage d’environ 1.3-1.5x
Implication pratique
À mesure que la précision diminue, le décodage s’améliore plus rapidement que le préremplissage. À INT4, un modèle qui semblait lent en FP16 génère du texte rapidement mais fait toujours une pause notable sur les invites longues. Cette asymétrie conduit aux recommandations spécifiques à la charge de travail ci-dessous.Consommation énergétique selon les niveaux de précision
Une précision plus basse réduit la consommation d’énergie pour 2 raisons : moins de lectures mémoire (l’accès mémoire domine le coût énergétique) et une arithmétique plus simple (une multiplication INT4 coûte moins cher qu’une multiplication FP16).Enveloppe de puissance de DGX Spark
La puce GB10 de DGX Spark a une TDP d’environ 40W partagée entre le CPU Grace et le GPU Blackwell. Voici les plages de puissance observées pendant l’inférence :Attentes de puissance des GPU grand public
Coût d’un service 24/7
Pour un DGX Spark fonctionnant en continu sous charge de décodage :
Sur un GPU grand public comme le RTX 4090 à 10 heures/jour :
Méthodologie de benchmark
Exécutez ces tests sur votre propre configuration pour voir comment la précision affecte votre modèle et votre matériel spécifiques.Mesurer le débit de décodage
Générez un nombre fixe de jetons de sortie à partir d’une invite courte et mesurez les jetons par seconde.Mesurer la latence de préremplissage
Chronométrez le temps que le modèle met pour produire son 1er jeton à différentes longueurs d’invite.Mesurer la consommation d’énergie
Ce qu’il faut rapporter
Remplissez ce tableau pour chaque niveau de précision que vous testez :Tableau de décision réel
Choisissez la ligne qui correspond à votre charge de travail principale :Pourquoi ne pas toujours utiliser INT4 ?
Pourquoi ne pas toujours utiliser INT4 ?
La quantification INT4 (GPTQ, AWQ, Q4_K_M) réduit la qualité de manière notable sur les modèles plus petits et les tâches de suivi d’instructions. Sur les modèles de moins de 13B paramètres, l’écart de qualité entre FP16 et INT4 peut dégrader la sortie. Sur les modèles de 70B+, l’écart se réduit car le modèle a plus de capacité pour absorber le bruit de quantification. Testez votre modèle spécifique avant de vous engager.
La précision du cache KV affecte-t-elle ces chiffres ?
La précision du cache KV affecte-t-elle ces chiffres ?
Oui. Le cache KV FP8 (défini avec
--kv-cache-dtype fp8 dans vLLM) réduit de moitié la mémoire du cache KV indépendamment de la quantification des poids. Il a un impact minimal sur la vitesse de décodage mais vous permet d’ajuster des contextes plus longs ou plus d’utilisateurs concurrents. Voir Ajustement de la mémoire DGX Spark pour les tableaux de dimensionnement.Comment la longueur du contexte change-t-elle la vitesse de décodage ?
Comment la longueur du contexte change-t-elle la vitesse de décodage ?
Le décodage lit l’intégralité du cache KV à chaque jeton. Les conversations plus longues construisent des caches plus grands, donc le décodage ralentit à mesure que le contexte grandit. Un modèle à un contexte de 4K peut générer à 40 tok/s mais chuter à 25 tok/s à un contexte de 32K sur le même matériel. Voir Cache KV et contexte pour la mécanique.
Commandes de benchmark rapides
Utilisez celles-ci comme points de départ pour comparer les précisions sur un seul modèle.Suite de benchmark vLLM
Benchmark llama.cpp
Évaluation intégrée Ollama
Comparer entre les précisions
Exécutez la même invite à chaque précision et enregistrez les résultats dans un tableau :Étapes suivantes
Ajustement de la mémoire DGX Spark
Dimensionnement du cache KV, compromis par lots et paramètres d’ajustement pour la mémoire unifiée de 128 Go.
vLLM sur DGX Spark
Installation, configuration NVFP4 et commandes de lancement optimales.
Évaluer un déploiement
Tests de bout en bout via Tokios — latence, streaming et comparaison des clients.
Concepts de quantification
Explication approfondie de GPTQ, AWQ, GGUF et des compromis de quantification.