Deux DGX Station servent GLM-5.3 à 608 tokens par seconde
NVIDIA relie deux DGX Station par ConnectX-8 pour garder les 464 Go de poids de GLM-5.3 NVFP4 en mémoire graphique, là où un seul GPU GB300 n'offre que 252 Go de HBM3e. Sur SPEED-Bench Coding, le service monte à 607,8 débittokens par secondeNombre de tokens produits par seconde en génération. Avec le temps d'attente du premier token, c'est le chiffre qui dit si un modèle est utilisable au quotidien sur une machine donnée.Fiche du lexique de sortie à seize requêtes simultanées, puis retombe à 385,0 à trente-deux, avec 453,5 secondes de latence moyenne.
par Gyom 14 novembre 2026 à 07:33 3 min de lecture rubrique : Machines et coûts
etiquettes : Local · GPU · Coût
NVIDIA publie le 13 novembre 2026 une recette de service pour GLM-5.3 en NVFP4 sur deux DGX Station reliées par ConnectX-8, avec vLLM en parallélisme de tenseurs. La version de Z.ai quantifiée en NVFP4 porte 753 milliards de paramètrespoids du modèleNombre de valeurs apprises par un modèle. À quantification égale, plus de paramètres veut dire plus de mémoire occupée, et en général de meilleures réponses.Fiche du lexique, dont 40 milliards activés par tokenPlus petite unité de texte qu'un modèle manipule. Un mot courant tient souvent en un seul, un mot rare se découpe en plusieurs morceaux. Les prix, les limites et les débits s'expriment en tokens, pas en mots.Fiche du lexique : l'activation creuse le calcul, mais chaque token peut appeler des experts différents, donc tous les poids doivent rester disponibles. Le point de contrôle pèse environ 464 Go, quand un seul GPU GB300 embarque 252 Go de HBM3e.
Deux machines derrière un seul point d'accès compatible OpenAI
Chaque Station garde et calcule à peu près la moitié des poids, et les deux rangs exposent une seule adresse compatible avec l'API d'OpenAI. NVIDIA fixe la liaison RDMA à 400 000 Mb/s avec une MTU de 9 000 octets, et demande la même image vllm/vllm-openai:v0.30.0-aarch64 des deux côtés, digests arm64 comparés avant de lancer quoi que ce soit. La Station A porte le rang 0 et l'API, la B le worker, et la copie des poids passe par SSH sans mot de passe. Le déchargement vers le processeur est désactivé : tout tient en mémoire graphique, sinon la mesure ne porterait plus sur ce qu'elle prétend mesurer. vLLM ajoute la prédiction multi-token, un cache KVKV cacheMémoire intermédiaire qui conserve les états d'attention déjà calculés pour ne pas les refaire à chaque nouveau token. C'est ce qui rend la conversation suivie supportable en coût de calcul.Fiche du lexique en FP8 et la mise en cache des préfixes pour tenir la charge simultanée.
607,8 tokens par seconde à seize requêtes, 385 à trente-deux
Sur SPEED-Bench Coding, avec quatre tokens de brouillon par pas et un cache KV en FP8, AIPerf mesure le débit de sortie suivant la simultanéité : 107,4 tokens par seconde à une requête, 386,0 à huit, 607,8 à seize, puis 385,0 à trente-deux. Le pic est net et la chute surprend : à trente-deux, la latence moyenne d'une requête atteint 453,54 secondes, contre 136,46 à seize et 49,84 à une seule. Le premier token arrive en 479,75 millisecondes à une requête, en 482,90 à seize, puis en 899,36 à trente-deux. L'écart entre deux tokens suit la même pente, 8,78 millisecondes à une requête, 23,77 à seize, 77,90 à trente-deux.
Le débit par utilisateur tombe de 115 à 13 tokens par seconde
Le tableau donne aussi le débit par utilisateur, celui qu'un humain ressent : 115,3 tokens par seconde quand il est seul, 13,0 quand ils sont trente-deux. Passer de seize à trente-deux requêtes ne divise donc pas seulement la vitesse par neuf, cela fait reculer le débit total de la machine, parce que la file d'attente sature avant le calcul. La conclusion du tutoriel est de relancer AIPerf avec ses propres invites pour trouver la simultanéité qui convient, ce qui revient à dire que le bon réglage dépend du trafic et non du matériel.
Ce que deux stations remplacent, et ce que le tutoriel ne chiffre pas
L'argument avancé est l'usage plus que le débit : inférenceExécution d'un modèle : une entrée, une sortie. Le calcul se sépare en un pré-remplissage de la question, puis une génération token par token.Fiche du lexique sur des données sensibles ou propriétaires, prototypage d'agents sur son bureau, itération sur les invites sans coût par token. Comparé à une grappe de huit DGX Spark mesurée en octobre sur le même GLM-5.3, le montage à deux stations vise autre chose, la mémoire HBM3e d'un GB300 et le parallélisme de tenseurs sur deux cartes, plutôt qu'un To de mémoire unifiée réparti sur huit machines. Le tutoriel ne donne ni le prix des deux stations, ni leur consommation, ni le coût par token qui en découle, et c'est pourtant là que se joue la comparaison avec une API facturée au million de tokens.
Source primaire NVIDIA, « When One GPU Isn't Enough: Serving GLM-5.3 Across Two NVIDIA DGX Stations with vLLM », blog développeurs NVIDIA, 13 novembre 2026