Configuration matérielle requise pour GLM-5.3 (2026) : GPU, VRAM et RAM

Vous vous demandez si GLM-5.3 peut tourner sur la carte graphique de votre PC ? Pour le modèle phare, la réponse est non : le checkpoint actuellement distribué exige une capacité mémoire de niveau serveur. GLM-5.3-Flash abaisse la barrière, mais reste un modèle volumineux qui réclame plusieurs GPU. Et charger un checkpoint quantifié ne garantit pas pour autant une expérience fluide avec un agent de programmation.

La réponse matérielle en un coup d’œil

Le modèle complet GLM-5.3 repose officiellement sur une topologie de 8 GPU en FP8, tandis que la prise en charge complète d’un contexte d’un million de tokens est documentée pour 8× B200. Une machine dotée de 24, 64, 128 ou 192 Go de mémoire n’est donc pas une cible réaliste pour le modèle complet, même si le routage MoE parcimonieux n’active qu’une partie des paramètres pour chaque token.

La fiche du modèle sur Hugging Face indique actuellement 753 329 940 480 paramètres au total, dont 751 226 191 872 paramètres en FP8, ainsi qu’une taille totale de 755 643 409 571 octets pour les fichiers safetensors. La recette vLLM arrondit ces chiffres à environ 743 milliards de paramètres au total et 39 milliards de paramètres actifs. Ces arrondis diffèrent légèrement, mais ne changent rien à la conclusion matérielle.

Calcul brut de la mémoire occupée par les poids

Les chiffres ci-dessous sont des estimations arithmétiques qui ne comptent ni le cache KV, ni les activations, ni les tampons d’exécution, ni la surcharge de l’allocateur. Pour FP8 et BF16, ils se basent sur l’échelle d’environ 753 milliards de paramètres du modèle phare actuel ; les valeurs NVFP4 et 2 bits correspondent à des implémentations précises.

Ce qui a changé depuis les recommandations matérielles initiales

Le dépôt de GLM-5.3 est désormais disponible avec des fichiers FP8 natifs. Pour les métadonnées du checkpoint, consultez la fiche du modèle ; pour la topologie et les options de lancement, référez-vous à la recette vLLM officielle ; enfin, les retours communautaires sont utiles pour connaître les performances mesurées. La recette actuelle annonce une fenêtre de 1 048 576 tokens.

Dimensionnez selon la mémoire, pas selon le nombre de paramètres

Avec GLM-5.3, la mémoire occupée par les poids est la première contrainte, et celle du contexte arrive juste après. Le nombre réduit de paramètres actifs limite le calcul, mais ne dispense pas de stocker les experts routés ni les tampons nécessaires à l’exécution.

24 à 64 Go : ne prévoyez pas d’exécuter le GLM-5.3 complet en local

Une RTX 4090, une RTX 5090 ou toute autre carte de 24 Go ne peut pas contenir le checkpoint FP8 natif du modèle phare, dont les fichiers safetensors occupent environ 756 Go dans le dépôt Hugging Face actuel. Même une carte professionnelle de 64 Go reste très loin du compte.

Le déport vers le CPU peut permettre de charger un modèle quantifié pour une expérimentation, mais ce n’est pas une configuration par défaut viable pour un service de programmation interactif. L’agent doit encore enchaîner les appels aux outils à une vitesse acceptable.

128 à 192 Go : non pour le modèle phare, Flash dans une configuration bien précise

Une machine à mémoire unifiée de 128 ou 192 Go reste sous le seuil nécessaire au déploiement FP8 natif du modèle phare. Flash dispose toutefois d’une voie concrète : un profil validé publiquement exécute un checkpoint EXL3/TR3 4 bpw épinglé sur 2× RTX PRO 6000 Blackwell 96 Go.

Ce profil utilise 175,6 Go de données de checkpoint, environ 220 Go d’espace disque libre, des communications PCIe peer-to-peer et un runtime épinglé. Il annonce une limite de 262 144 tokens par requête, mais il s’agit bien d’un déploiement sur deux GPU distincts, pas de 192 Go de mémoire système ordinaire. Pour cette configuration Flash précise, le profil indique également un décodage à 171,7 tokens par seconde et un délai médian avant le premier token de 0,059 seconde.

2 à 4 GPU à grande mémoire : envisagez Flash, pas le modèle phare

Deux à quatre cartes à grande capacité mémoire constituent la première plage qui mérite d’être étudiée pour Flash, car la précision, le runtime, la longueur du contexte, le batching et les entrées image modifient tous le budget mémoire. Le profil validé sur deux GPU prend en charge le texte, les outils structurés et les images en entrée sémantique. La vidéo est désactivée, le point d’accès n’intègre aucune authentification et le template vision fourni nécessite une correction réversible avant toute validation multimodale. Ces détails concernent cette recette épinglée, pas tous les builds de Flash ni le modèle phare.

8× H200 ou H20 : la topologie FP8 officielle du modèle phare

La recette vLLM officielle désigne huit GPU H200 ou H20 comme topologie standard pour le FP8 natif. Elle utilise un parallélisme tensoriel sur huit cartes, un cache KV en FP8, une prédiction multi-token sur cinq tokens, la sélection automatique des outils ainsi que les parseurs de raisonnement et d’appels d’outils spécifiques à GLM.

Il s’agit de la topologie documentée, pas d’une garantie concernant un débit précis. Les performances réelles dépendent de l’interconnexion, de la longueur du contexte, de la taille des lots, du nombre de séquences simultanées et du build de service utilisé. La page vLLM fournit la configuration, mais aucun débit de production mesuré.

8× B200 : choisissez cette configuration si le contexte d’un million de tokens est essentiel

La recette officielle positionne huit GPU B200 pour la configuration complète avec une fenêtre de 1 048 576 tokens. Cette capacité supplémentaire est avant tout une question de VRAM : le cache KV augmente avec le nombre de séquences actives et la longueur du contexte. Une configuration qui fonctionne à 32K ou 128K tokens ne pourra donc pas forcément gérer un million de tokens avec le même niveau de concurrence.

Commencez avec une valeur plus basse pour --max-model-len, puis augmentez-la uniquement après avoir mesuré l’utilisation du cache KV. Une grande fenêtre de contexte est précieuse pour les dépôts et documents volumineux, mais elle ne rend pas toutes les requêtes économiques ou peu latentes.

Les exigences de l’hôte que la recette officielle ne précise pas

La recette vLLM détaille la topologie GPU et les options de lancement, mais ne publie pas de valeur universelle pour la RAM système, la consommation électrique, le refroidissement, la marge de stockage ou le réseau. Ces paramètres varient selon le checkpoint, le runtime, la cible de contexte et la plateforme du fournisseur.

Le chemin de déploiement officiel minimal

Le déploiement documenté utilise vLLM 0.28.0 et expose un point d’accès compatible avec l’API OpenAI. Il est conçu pour un nœud multi-GPU : recopier la commande sur une machine plus modeste ne supprime pas les besoins mémoire du modèle.

Installer le runtime documenté

uv venv
source .venv/bin/activate
uv pip install "vllm==0.28.0" --torch-backend=auto
uv pip install "transformers>=5.15.0"

La recette vLLM précise également que DeepGEMM est requis pour obtenir de bonnes performances en FP8. Vérifiez la recette actuelle avec l’image logicielle de la cible avant de provisionner un nœud payant.

Lancer GLM-5.3 en FP8 natif

vllm serve zai-org/GLM-5.3 \
  --kv-cache-dtype fp8 \
  --tensor-parallel-size 8 \
  --speculative-config.method mtp \
  --speculative-config.num_speculative_tokens 5 \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --enable-auto-tool-choice \
  --served-model-name glm-5.3

Chaque option a une fonction précise :

• --tensor-parallel-size 8 répartit le checkpoint sur huit GPU.
• --kv-cache-dtype fp8 limite la pression sur le cache par rapport à un cache de précision supérieure.
• Le réglage MTP sur cinq tokens active le décodage spéculatif décrit dans la recette officielle.
• --tool-call-parser glm47 et --reasoning-parser glm45 structurent la sortie du modèle pour l’utilisation des outils et le raisonnement.
• --enable-auto-tool-choice permet au serveur de sélectionner les outils lorsque le client les fournit.

Valider le point d’accès avant de connecter un agent

curl -X POST "http://localhost:8000/v1/chat/completions" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "glm-5.3",
    "messages": [
      {"role": "user", "content": "Write a Python function that reverses a linked list."}
    ],
    "max_tokens": 256
  }'

Une réponse valide confirme que le modèle est chargé, mais ne prouve ni le bon fonctionnement des outils ni celui du contexte long. La fiche officielle mentionne aussi SGLang comme voie compatible avec l’API OpenAI, mais ce guide utilise vLLM, car sa topologie GPU et ses options sont documentées dans une recette dédiée.

Le budget mémoire caché : cache KV et raisonnement toujours actif

La fiche du modèle GLM-5.3 et la recette vLLM considèrent que le mode réflexion est toujours activé. Les valeurs de niveau de raisonnement prises en charge sont low, high et max ; max est utilisé par défaut lorsqu’aucun réglage inférieur pris en charge n’est fourni.

Un raisonnement plus long consomme davantage de tokens en sortie. De son côté, un agent de programmation peut conserver de grands préfixes de dépôt dans le cache KV au fil d’appels répétés aux outils. Plus le nombre de séquences simultanées augmente, plus les besoins du cache progressent, même si les poids du modèle ne changent pas.

Utilisez ces réglages comme leviers de déploiement :

• Low : le meilleur point de départ pour la programmation interactive, les requêtes courtes et les outils sensibles à la latence.
• High : à privilégier lorsqu’une tâche demande davantage de planification tout en conservant un budget de réponse interactif.
• Max : à réserver aux tâches difficiles et longues, lorsque les tokens de raisonnement supplémentaires sont justifiés.

La recette officielle recommande --max-num-seqs 32 pour la configuration B200 avec contexte complet et utilise des réglages de cache en FP8. Considérez cette valeur comme un point de départ : réduisez la concurrence si le serveur manque de mémoire et ne revendiquez pas la prise en charge d’un million de tokens tant qu’une requête réelle n’a pas atteint cette plage sans troncature du cache.

Quand l’API devient le choix matériel le plus rationnel

Avec l’auto-hébergement, une capacité GPU reste réservée même lorsqu’aucun développeur n’envoie de requête. Pour un trafic intermittent, une faible concurrence ou une équipe encore en phase de validation de GLM-5.3, l’API évite d’acheter ou de louer en continu un nœud à huit GPU. En contrepartie, il faut accepter la gestion des données chez le fournisseur et une dépendance à sa plateforme.

La page tarifaire actuelle de Z.ai indique pour GLM-5.3 un prix de 1,40 $ par million de tokens en entrée, 0,26 $ par million de tokens d’entrée mis en cache et 4,40 $ par million de tokens en sortie. Pour GLM-5.3-Flash, elle affiche les tarifs catalogue de 0,15 $ / 0,03 $ / 0,50 $, avec une promotion de 50 % annoncée jusqu’au 9 septembre 2026 ; vérifiez la page de facturation en ligne avant d’établir votre budget.

Ces exemples illustrent le coût des tokens ; ils ne constituent pas un calcul de seuil de rentabilité face à l’auto-hébergement. Pour comparer correctement, il faut intégrer le prix horaire du nœud, le débit soutenu en tokens par seconde, le taux d’utilisation, l’électricité, le stockage, le temps d’ingénierie ainsi que les exécutions d’agents échouées ou relancées. Pour le détail des tarifs, consultez le guide des tarifs de l’API GLM-5.3-Flash d’AIReiter.

En pratique :

• Choisissez l’API GLM-5.3 hébergée si vous avez besoin du modèle phare, mais avec une demande irrégulière ou modérée.
• Choisissez GLM-5.3-Flash si le coût réduit des tokens, les entrées multimodales ou une cible d’auto-hébergement plus modeste comptent davantage que la capacité du modèle phare.
• Choisissez l’auto-hébergement du GLM-5.3 phare lorsque la confidentialité, le contrôle ou un usage soutenu justifient un déploiement sur huit GPU.

FAQ sur la configuration matérielle de GLM-5.3

GLM-5.3 peut-il tourner sur une RTX 4090, une RTX 5090 ou un GPU de 24 Go ?

Non, pas dans sa version complète. Le dépôt FP8 natif actuel contient environ 756 Go de fichiers safetensors. Une carte de 24 Go ne peut donc intervenir que dans une expérimentation extrême avec déport ou quantification, et non héberger le modèle pour un service standard.

128 ou 192 Go de RAM suffisent-ils ?

Non pour le déploiement FP8 natif du modèle phare. Le profil Flash validé utilise deux GPU distincts de 96 Go, un checkpoint 4 bpw épinglé et du stockage supplémentaire ; cela ne revient pas à disposer de 192 Go dans un ordinateur portable ou une station de travail à mémoire unifiée.

Quelle différence entre GLM-5.3 et GLM-5.3-Flash ?

Ce sont deux modèles distincts : la fiche du modèle phare indique environ 753 milliards de paramètres au total, tandis que Z.ai présente Flash comme un modèle de 320 milliards de paramètres au total, dont 18 milliards actifs, avec une conception native multimodale. Flash est plus petit et moins cher, mais reste un modèle de niveau serveur, pas un modèle de bureau de 18 milliards de paramètres.

Quelle précision choisir ?

Utilisez le FP8 natif si la topologie documentée sur huit GPU est disponible. Préférez BF16 pour une évaluation de référence ou spécialisée lorsque la mémoire de niveau multi-nœuds est acceptable. Le NVFP4 ne doit être envisagé que sur du matériel Blackwell compatible ; rappelez-vous que le checkpoint NVFP4 référencé est une re-quantification communautaire, et non le package original fourni par défaut.

Puis-je connecter GLM-5.3 à un agent de programmation ?

Oui. La recette vLLM officielle active un point d’accès compatible avec l’API OpenAI ainsi que les parseurs d’appels d’outils et de raisonnement. Les clients compatibles avec cette interface peuvent donc se connecter après validation du serveur. Testez toutefois le harnais exact, le schéma des outils et le comportement sur les longues sessions : une complétion de chat réussie ne suffit pas à prouver la compatibilité avec un agent.

La suite à donner

Avec une machine de bureau ou un hôte de moins de 192 Go, commencez par tester l’API hébergée. Louez la topologie documentée sur huit GPU avec une charge représentative, ou évaluez Flash sur une machine multi-GPU à grande mémoire. Ne passez à l’auto-hébergement qu’après avoir mesuré une utilisation suffisante pour justifier le coût de l’infrastructure par le contrôle et la confidentialité.