Comment faire fonctionner GLM-5.3-Flash en local

GLM-5.3-Flash est un modèle de 320 milliards de paramètres publié sous la licence MIT. Ces deux faits vont dans des directions opposées : la licence vous autorise à l'exécuter comme bon vous semble, et le nombre de paramètres indique que vous aurez besoin de matériel puissant pour y parvenir.

Le point intéressant est que 18 milliards de ces 320 milliards de paramètres sont actifs par token, et des versions quantifiées existent. Cette combinaison met ce modèle à la portée de configurations bien plus modestes que le nœud 8x H200 que la plupart des guides supposent.

Cet article examine honnêtement les différents niveaux de matériel, d'un nœud de production en pleine précision à une version quantifiée sur une station de travail, et couvre les cas où l'auto-exécution est pertinente.

Ce que vous chargez réellement

L'architecture de mélange d'experts (mixture-of-experts) est ce qui rend cela possible. Les 320 milliards de paramètres doivent résider en mémoire, mais seulement 18 milliards participent à un token donné, de sorte que la demande de calcul est bien inférieure à ce que le total suggère. La mémoire est votre contrainte principale, pas les FLOPs.

Z.ai rapporte également un cache KV environ 4,4 fois plus petit que celui de GLM-5.3, ce qui est d'une importance capitale pour les travaux à long contexte. Le cache KV est ce qui consomme de la mémoire à mesure que votre contexte se remplit, et sur une fenêtre d'un million de tokens, c'est normalement ce qui vous tue.

Niveau 1 : pleine précision sur un nœud de production

Pour un service en pleine qualité avec une concurrence réelle, la configuration de référence est un nœud 8x H200 (141 Go chacun, environ 1 128 Go au total). Un nœud 8x H20 fonctionne également.

Chiffres approximatifs : les poids seuls nécessitent entre 700 et 800 Go selon la précision, et vous avez besoin d'une marge supplémentaire pour le cache KV et les frais généraux d'exécution. La capacité cloud louée pour un nœud de ce type coûte environ 24 $ à 48 $ par jour.

vLLM

vLLM est le choix par défaut le plus courant et bénéficie du support écosystémique le plus large. La taille de parallélisation tensorielle doit être une puissance de deux :

vllm serve zai-org/GLM-5.3-Flash \
  --tensor-parallel-size 8 \
  --max-model-len 1048576 \
  --trust-remote-code

Commencez avec un --max-model-len plus petit pendant que vous validez la configuration. Demander la fenêtre complète d'un million de tokens immédiatement signifie allouer le cache KV pour celle-ci, et un échec dans ce cas se manifeste par une erreur de mémoire insuffisante plutôt que par un problème de configuration.

SGLang

SGLang a offert un support dès le premier jour pour ce modèle, avec des recettes publiées pour H100, H200, B200, B300 et GB200, y compris le service multimodal. Z.ai a utilisé une pile basée sur SGLang pour son propre service de pré-lancement.

python -m sglang.launch_server \
  --model-path zai-org/GLM-5.3-Flash \
  --tp 8 \
  --context-length 1048576

SGLang a tendance à l'emporter sur la sortie structurée et les charges de travail agentielles à forte concurrence. Si vous servez un agent de codage plutôt qu'une interface de chat, il est utile de le comparer à vLLM plutôt que de choisir par défaut.

Les deux piles nécessitent un analyseur d'appels d'outils configuré pour que l'appel de fonctions fonctionne correctement. Vérifiez les drapeaux actuels dans la documentation de chaque projet, car les noms des analyseurs changent entre les versions.

Niveau 2 : quantifié sur du matériel plus modeste

C'est le niveau que la plupart des analyses ignorent, et c'est celui qui importe pour quiconque ne dispose pas d'un centre de données.

Des versions GGUF quantifiées sont publiées sur unsloth/GLM-5.3-Flash-GGUF, allant jusqu'à des formats agressifs de 1 et 2 bits tels que IQ1_S et IQ2_XXS. Une quantification à 2 bits d'un modèle de 320 milliards ramène les poids dans une plage qu'un poste de travail à haute mémoire ou un équipement grand public multi-GPU peut gérer, particulièrement avec le déchargement CPU.

Deux mises en garde honnêtes :

Une quantification agressive nuit à la qualité. IQ1_S est loin de la pleine précision. Sur un MoE de 320 milliards, la dégradation est souvent plus douce que le même traitement appliqué à un modèle dense, car il y a plus de redondance à perdre, mais "fonctionne" et "fonctionne bien" sont des affirmations différentes. Testez-le sur vos propres tâches avant d'en tirer des conclusions.

La documentation d'Unsloth pour ce modèle est marquée comme en cours de développement. La disponibilité des quantifications et les paramètres recommandés sont encore en évolution. Vérifiez ce qui est réellement publié avant de planifier une construction autour d'un format spécifique.

Pour les configurations lourdes en CPU et hybrides, KTransformers est conçu précisément pour ce cas, maintenant les experts MoE dans la RAM système et ne déplaçant sur le GPU que ce qui est nécessaire. Sur un modèle MoE avec 18 milliards de paramètres actifs, cette architecture convient exceptionnellement bien. TokenSpeed est également listé parmi les runtimes supportés.

Notre guide pour exécuter GLM-4.7-Flash localement couvre la version de ce workflow pour les modèles plus petits, et exécuter GLM-5 localement gratuitement couvre la configuration générale de GLM local.

Calcul de votre budget mémoire

Deux chiffres déterminent si une configuration est adaptée.

Poids. À environ 2 octets par paramètre en BF16, 320 milliards de paramètres représentent environ 640 Go avant les frais généraux. FP8 réduit cela de moitié. Une quantification à 4 bits le ramène à environ 160 Go, et les formats agressifs à 2 bits descendent encore plus bas au prix d'une réelle perte de qualité.

Cache KV. Celui-ci évolue avec la longueur du contexte et la concurrence, et c'est ce qui surprend les gens. Une configuration qui se charge bien avec un contexte de 8K peut échouer à 128K parce que le cache a grossi, pas les poids. La réduction de 4,4x rapportée par Z.ai par rapport à GLM-5.3 aide beaucoup ici, mais l'échelle reste linéaire en termes de tokens.

L'implication pratique est de dimensionner en fonction de votre longueur de contexte réelle, et non du maximum annoncé par le modèle. Très peu d'applications nécessitent la totalité du million de tokens, et provisionner pour une fenêtre que vous n'utilisez jamais est le moyen le plus courant de rendre ce modèle inabordable.

Si vous suiviez l'histoire précédente des poids ouverts pour cette famille, notre article sur l'auto-hébergement de GLM-5.3 a été écrit avant la publication. Les poids pour Flash sont maintenant disponibles sous MIT, donc les directives ici la remplacent.

Réglage fin (Fine-tuning)

La licence MIT permet le réglage fin et la redistribution, ce qui est inhabituel à ce niveau de capacité et constitue la raison la plus forte de conserver les poids vous-même.

Soyez réaliste quant au coût. Le réglage fin complet d'un modèle de 320 milliards est hors de portée pour la plupart des équipes. Les méthodes efficaces en paramètres telles que LoRA sont la voie pratique, et sur un modèle de mélange d'experts, il y a une question de conception supplémentaire de savoir si vous adaptez le routeur, les experts ou les couches d'attention. C'est un domaine actif avec des directives moins établies que pour les modèles denses.

Si votre objectif est l'adaptation au domaine plutôt que de nouvelles capacités, testez d'abord l'incitation (prompting) et la récupération (retrieval) sur le modèle de base. Sur un modèle avec une fenêtre de contexte d'un million de tokens, inclure votre connaissance du domaine dans l'invite est souvent moins cher et plus efficace que de l'entraîner.

Paramètres d'échantillonnage

Z.ai publie différentes recommandations par tâche :

Le modèle prend également en charge trois modes de raisonnement via reasoning_effort, avec les valeurs low, high et max. Max est la valeur par défaut. Sur du matériel local, cela importe plus que sur l'API, car les tokens de raisonnement sont une génération que vous payez en temps réel plutôt qu'en dollars. Si votre équipement génère lentement, low fait la différence entre utilisable et inutilisable.

L'auto-hébergement est-il financièrement judicieux ?

Généralement non, et le prix de l'API en est la raison.

Au prix catalogue, GLM-5.3-Flash coûte 0,15 $ par million de tokens d'entrée. Un nœud 8x H200 loué à environ 1 000 $ par mois vous permet d'obtenir environ 6,7 milliards de tokens d'entrée d'utilisation de l'API. Maintenir un volume supérieur à cela, en continu, est une opération d'envergure.

Le nœud coûte également le même prix qu'il soit saturé ou inactif, tandis que l'API ne facture que ce que vous utilisez. À moins que votre utilisation ne soit réellement élevée 24 heures sur 24, le coût fixe est perdant.

Les raisons d'auto-héberger ne sont donc pas financières :

• Résidence des données et confidentialité. Rien ne quitte votre infrastructure.
• Pas de limites de débit. Votre capacité est votre capacité.
• Garanties de disponibilité. Aucune dépendance vis-à-vis de la disponibilité ou des décisions tarifaires d'un fournisseur.
• La licence MIT. Vous pouvez modifier, affiner et redistribuer. C'est inhabituel pour un modèle à ce niveau de capacité et c'est l'argument le plus fort de la liste.
• Matériel que vous possédez déjà. Si les GPU sont achetés et inactifs, le coût marginal est l'électricité, et le calcul entier s'inverse.

Notre analyse des prix détaille davantage le côté API de cette comparaison.

Vérification de votre déploiement

vLLM et SGLang exposent tous deux des endpoints compatibles OpenAI, de sorte que la même forme de requête fonctionne sur votre serveur local et sur Z.ai :

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [{"role": "user", "content": "reply with OK"}]
  }'

Il est utile de tester au-delà d'un simple test rapide : le comportement à long contexte à la longueur dont vous avez réellement besoin, l'entrée d'image si vous servez en multimodal, l'appel d'outils avec vos schémas réels, et le débit sous concurrence plutôt que la latence d'une seule requête.

C'est là qu'une collection de tests enregistrée prend tout son sens. Dirigez Apidog vers votre serveur local et le endpoint Z.ai avec l'URL de base comme variable d'environnement, exécutez la même suite sur chacun et comparez. Vous découvrirez rapidement si votre version quantifiée gère toujours les schémas d'outils dont votre application dépend, ce qui est le mode de défaillance que les gens découvrent en production plutôt qu'avant.

FAQ

Quel est le matériel minimum ? Pour la pleine précision, un nœud de classe 8x H200. Pour les versions GGUF quantifiées, considérablement moins, bien que la qualité diminue avec le niveau de quantification.

Dois-je avoir les 320 milliards de paramètres en mémoire ? Oui. Seuls 18 milliards sont actifs par token, mais l'ensemble doit résider en mémoire. La mémoire est la contrainte ; le calcul ne l'est pas.

Lequel est le meilleur, vLLM ou SGLang ? SGLang a eu un support dès le premier jour avec des recettes multimodales publiées et l'emporte souvent sur la concurrence et la sortie structurée. vLLM a un support écosystémique plus large. Évaluez les deux sur votre charge de travail.

Puis-je l'exécuter sur un seul GPU ? Pas en pleine précision. Avec une quantification agressive et le déchargement CPU via KTransformers, un système à GPU unique et haute mémoire, plus beaucoup de RAM système, est plausible. Attendez-vous à une génération lente.

La licence est-elle vraiment MIT ? Oui. Les poids sont publiés sous licence MIT, ce qui permet l'utilisation commerciale, la modification et la redistribution.