Comment exécuter GLM-5.3-Flash localement

TL;DR

Vous pouvez exécuter GLM-5.3-Flash en local car Z.ai a publié les poids du modèle sous licence MIT. Le point clé est la mémoire : le modèle compte environ 320B de paramètres au total, même si seulement 18B sont actifs par token. Les poids FP8 natifs représentent environ 306 GiB avant les surcoûts d’exécution et de cache KV, tandis que les quantifications GGUF courantes vont d’environ 93 GB en 1-bit à 200 GB en Q4 et 341 GB en Q8.

Pour une mise en production sur GPU, vLLM ou SGLang sont les voies les plus directes. Pour une station de travail avec beaucoup de RAM et un ou plusieurs GPU grand public, KTransformers est conçu pour l’inférence hétérogène CPU-GPU. Pour l’expérience locale la plus simple, utilisez un build GGUF avec llama.cpp ou Ollama. Un GPU classique de 24 GB ou 32 GB ne peut pas contenir le modèle complet à lui seul ; l’usage local sur un seul GPU dépend de la RAM système, de l’offload et/ou de la quantification.

Qu’est-ce que GLM-5.3-Flash ?

Pour une présentation complète du modèle et l’interprétation des benchmarks, voir Qu’est-ce que GLM-5.3-Flash ? sur CometAPI. Ce guide de déploiement ne conserve que les informations de dimensionnement nécessaires ici : GLM-5.3-Flash est un MoE multimodal 320B / 18B entraîné sur un corpus de 30T tokens.

Le dépôt officiel indique une fenêtre de contexte de 1 048 576 tokens, des poids sous licence MIT et des voies prises en charge pour le service local. Le tableau ci-dessous sert de référence de déploiement ; le reste de cet article se concentre sur l’installation, la mémoire, la vérification et le dépannage.

Pourquoi GLM-5.3-Flash est plus efficient que sa taille ne le laisse penser

Un modèle 320B évoque un modèle dense 320B conventionnel, mais ce n’est pas ainsi que GLM-5.3-Flash dépense son calcul. Le routeur MoE n’active qu’une fraction de la capacité d’experts par token, tandis que la refonte de l’attention réduit le coût de conservation et de récupération de l’état long contexte.

Z.ai annonce des réductions du calcul d’attention et de l’usage du cache KV par rapport à GLM-5.3. C’est important car le cache KV croît avec la longueur de contexte et la concurrence ; un modèle qui se charge à 8K de contexte peut quand même manquer de mémoire dès qu’on lui demande de servir des conversations beaucoup plus longues.

Source : Annonce officielle de Z.ai

Quelle est la qualité de GLM-5.3-Flash ?

Le tableau ci-dessous conserve les scores de première main les plus pertinents pour le déploiement. Z.ai rapporte de meilleurs résultats de benchmark pour GLM-5.3-Flash par rapport à GLM-5.2 ; voir la présentation du modèle de CometAPI pour une interprétation plus complète. Ici, l’enjeu pratique est de savoir si les gains justifient le coût matériel et opérationnel local.

Le motif est particulièrement pertinent pour l’auto-hébergement : les cas d’usage forts du modèle ne sont pas la conversation légère, mais les agents de code, l’automatisation pilotée par outils, le travail sur documents à long contexte, et les workflows multimodaux où la résidence des données ou le contrôle de l’infrastructure peuvent justifier l’effort de déploiement.

De combien de RAM ou de VRAM GLM-5.3-Flash a-t-il besoin ?

La planification mémoire est la partie la plus importante de ce guide. La recette officielle vLLM indique que le checkpoint FP8 natif représente environ 306 GiB de poids FP8. KTransformers recommande donc de réserver au moins 350 GB de mémoire système disponible pour sa voie CPU-GPU FP8 native.

Si vous utilisez GGUF, Unsloth publie des quantifications de 1-bit à BF16. La taille de fichier n’est pas la même que la mémoire totale à l’exécution : il faut aussi prévoir de la marge pour le runtime, les métadonnées du modèle, les buffers de calcul, les composants multimodaux et le cache KV.

La troisième colonne est un guide de planification de déploiement, pas une spécification matérielle minimale officielle. L’adéquation réelle dépend de la longueur de contexte, de la taille de lot, du runtime, de l’offload GPU et de l’implémentation de la quantification.

Quel runtime local utiliser ?

Choisissez vLLM quand le débit et la compatibilité écosystème comptent le plus. Choisissez SGLang pour évaluer le service orienté agents, les sorties structurées ou les requêtes multimodales. Choisissez KTransformers lorsque le modèle ne tient pas en VRAM mais que vous avez des centaines de gigaoctets de RAM système. Choisissez llama.cpp ou Ollama lorsque la quantification GGUF et la facilité d’expérimentation priment sur la correspondance avec le checkpoint natif.

Comment exécuter GLM-5.3-Flash avec les poids natifs

Exécuter avec vLLM

vLLM est l’option orientée production la plus claire si vous disposez d’accélérateurs de classe serveur. La recette officielle actuelle prend en charge plusieurs stratégies de parallélisation et documente le service FP8 natif. Considérez les configurations publiées comme des références, pas comme la garantie que chaque combinaison de GPU fonctionnera avec les mêmes flags.

Étape 1 : Préparer l’environnement

Utilisez Linux avec une pile NVIDIA prise en charge, assez de mémoire GPU agrégée pour le checkpoint plus l’overhead d’exécution, et une version récente de vLLM ou le conteneur recommandé par la recette en vigueur. Commencez avec une fenêtre de contexte plus petite pendant la validation au lieu d’allouer d’emblée le million de tokens complet.

Étape 2 : Démarrer le serveur

pip install vllm

vllm serve "zai-org/GLM-5.3-Flash" \
  --tensor-parallel-size 8 \
  --served-model-name zai-org/GLM-5.3-Flash

Pour les déploiements avancés, la recette vLLM officielle documente le cache KV en FP8 sur systèmes Blackwell pris en charge, le décodage spéculatif MTP, l’analyse d’appels d’outils, l’analyse du raisonnement, et la dissociation prefill/décode. Vérifiez la recette vLLM actuelle avant de copier des flags en production, car le support peut évoluer rapidement.

Étape 3 : Tester l’endpoint compatible OpenAI

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"}
    ]
  }'

Exécuter avec SGLang

SGLang est une autre voie de service de premier plan listée dans la carte du modèle officielle. Il est particulièrement intéressant à tester pour des agents à haute concurrence, la génération structurée, les requêtes multimodales et les applications intensives en outils.

Étape 1 : Installer SGLang

pip install sglang

Étape 2 : Lancer le serveur de modèle

python3 -m sglang.launch_server \
  --model-path "zai-org/GLM-5.3-Flash" \
  --host 0.0.0.0 \
  --port 30000

Étape 3 : Vérifier l’endpoint

curl -X POST "http://localhost:30000/v1/chat/completions" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [{"role": "user", "content": "Give me three local deployment checks."}]
  }'

La carte du modèle officielle sur Hugging Face fournit également des exemples de requêtes multimodales pour SGLang. Si vous avez besoin d’appels d’outils, utilisez les flags d’analyseur recommandés par la recette SGLang actuelle plutôt que de supposer que les flags d’une ancienne version de GLM restent inchangés.

Exécuter avec KTransformers

KTransformers est l’option la plus importante pour les utilisateurs qui entendent « local » comme une station de travail plutôt qu’un serveur à huit GPU. Son implémentation GLM-5.3-Flash lit directement les poids FP8 officiels et réalise une inférence hétérogène CPU-GPU des experts.

Le tutoriel actuel indique que le modèle FP8 occupe environ 306 GiB et conseille 350 GB de mémoire système. Il prend en charge les GPU NVIDIA SM89 et SM120, y compris les séries RTX 40 et 50, ainsi que des kernels experts CPU FP8 AVX-512. Le tutoriel inclut des configurations de lancement à quatre GPU et à un seul GPU.

Un seul RTX 4090 ou RTX 5090 peut participer à l’inférence, mais cela ne fait pas de GLM-5.3-Flash un modèle de 24–32 GB. La majeure partie du modèle réside toujours en dehors de la VRAM GPU, de sorte que la capacité et la bande passante de la mémoire système deviennent centrales pour les performances.

Étape 1 : Créer un environnement Python propre

conda create -n glm53flash python=3.11 -y
conda activate glm53flash

Étape 2 : Installer KTransformers

pip install "ktransformers[sglang]"

Étape 3 : Télécharger les poids officiels

Téléchargez zai-org/GLM-5.3-Flash depuis Hugging Face vers un stockage local. Prévoyez suffisamment d’espace disque pour le checkpoint et assez de RAM pour la configuration serveur active.

Étape 4 : Démarrer le serveur mono-GPU

MODEL_PATH=/path/to/GLM-5.3-Flash

CUDA_VISIBLE_DEVICES=0 python -m sglang.launch_server \
  --model-path "$MODEL_PATH" \
  --kt-weight-path "$MODEL_PATH" \
  --served-model-name GLM-5.3-flash \
  --host 0.0.0.0 \
  --tp-size 1 \
  --context-length 501025 \
  --mem-fraction-static 0.65 \
  --chunked-prefill-size 2048 \
  --kt-method FP8 \
  --kt-cpuinfer 64 \
  --kt-threadpool-count 2 \
  --kt-num-gpu-experts 0 \
  --kt-gpu-prefill-token-threshold 2048 \
  --cuda-graph-bs 1 2 4 \
  --limit-mm-data-per-request '{"image":8,"video":1}' \
  --mm-process-config '{"image":{"max_pixels":1254400}}' \
  --tool-call-parser glm47 \
  --reasoning-parser glm45

Le tutoriel utilise une configuration validée à 501,025 tokens bien que le modèle prenne en charge jusqu’à 1M de contexte. C’est un rappel utile : configurez le contexte dont vous avez réellement besoin, pas le maximum « marketing », car la marge de contexte a un coût mémoire direct.

Étape 5 : Vérifier le serveur

curl http://localhost:30000/v1/models

L’endpoint de chat compatible OpenAI est en texte brut : http://localhost:30000/v1/chat/completions.

Comment exécuter un modèle GGUF GLM-5.3-Flash quantifié

Exécuter GLM-5.3-Flash avec llama.cpp

Si vous ne souhaitez pas exécuter le checkpoint FP8 natif, GGUF rend la cible mémoire plus flexible. Unsloth publie plusieurs quantifications GGUF de GLM-5.3-Flash et fournit des commandes directes pour llama.cpp. Le build Q4_K_XL fait environ 200 GB, donc même cette voie « grand public » suppose encore un système à grande mémoire.

Installer sur macOS ou Linux

curl -LsSf https://llama.app/install.sh | sh

Installer sur Windows

winget install llama.cpp

Démarrer un serveur local avec Q4_K_XL

llama serve -hf unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

Exécuter directement dans le terminal

llama cli -hf unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

Si votre machine ne peut pas accueillir Q4_K_XL, il existe des fichiers plus petits en 3-bit, 2-bit et 1-bit. Ne choisissez pas le plus bas nombre de bits simplement parce qu’il tient : une quantification agressive peut modifier la fiabilité du raisonnement, le formatage des appels d’outils, la qualité du code et le comportement multimodal. Validez le build exact sur votre propre jeu de tests.

Exécuter GLM-5.3-Flash avec Ollama

Ollama est la voie en ligne de commande la plus courte si vous l’utilisez déjà pour des modèles locaux. Unsloth documente le chargement direct depuis Hugging Face pour ses builds GGUF de GLM-5.3-Flash.

ollama run hf.co/unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

La commodité d’Ollama ne change pas la taille sous-jacente du modèle. Q4_K_XL reste autour de 200 GB, et les versions à plus faible nombre de bits échangent mémoire contre qualité. Si vous n’avez que 32–64 GB de RAM système, GLM-5.3-Flash n’est pas une cible locale sensée ; utilisez plutôt un modèle plus petit ou une API hébergée.

Choisir une quantification GGUF

Choisissez la quantification de plus haute qualité qui tient avec suffisamment de marge pour le runtime et le cache KV. Commencez par Q4_K_XL lorsque vous avez environ 256 GB ou plus de mémoire système ; envisagez des builds à plus faible nombre de bits uniquement si les limites matérielles l’exigent, et validez le raisonnement, la génération de code, les appels d’outils et le comportement multimodal par rapport à une référence native ou hébergée avant le déploiement.

Comment vérifier votre déploiement local

Un journal de démarrage réussi ne suffit pas. Testez les comportements dont votre application dépendra réellement. Une séquence d’acceptation utile est : génération de texte de base, votre vraie longueur de contexte, appel d’outils avec vos schémas, entrée multimodale si nécessaire, et débit sous une concurrence réaliste.

Test de fumée de base

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

La carte du modèle définit des niveaux de reasoning_effort et utilise max par défaut. Pour reproduire des benchmarks, conservez max ; sur une station de travail lente, low ou high peut rendre les tests itératifs bien plus pratiques.

Ajoutez ensuite des vérifications propres à votre charge :

• Long contexte : envoyez un document ou un prompt de taille dépôt proche de votre longueur de production visée, pas 1M par défaut.
• Appels d’outils : vérifiez le JSON des arguments, la sélection d’outils, la récupération après erreurs d’outils et les appels répétés.
• Multimodal : testez les formats d’images ou de vidéo et les plages de résolution que vous utiliserez en pratique.
• Concurrence : mesurez latence et mémoire pendant plusieurs requêtes simultanées.
• Quantification : comparez le même ensemble de prompts à une référence native ou hébergée avant de valider un build GGUF bas débit.

Comment réduire l’usage mémoire de GLM-5.3-Flash

Utiliser une fenêtre de contexte plus petite

Le modèle prend en charge jusqu’à 1M de tokens, mais la plupart des workflows locaux n’ont pas besoin d’autant de contexte pour chaque requête. Réduisez le maximum configuré jusqu’à ce qu’il corresponde à votre application. Cela diminue la pression du cache KV et peut transformer un déploiement instable en solution exploitable.

Quantifier les poids

Passer de BF16 à Q8, Q6, Q4 ou des GGUF à plus faible nombre de bits peut réduire drastiquement la mémoire dédiée aux poids. Le compromis concerne la qualité des sorties et parfois la compatibilité runtime ; considérez le niveau de quantification comme un choix de modèle, pas seulement une option de stockage.

Utiliser l’offload CPU

KTransformers et llama.cpp peuvent déplacer une part substantielle de l’état du modèle en RAM système. C’est la principale raison pour laquelle l’inférence de GLM-5.3-Flash sur un seul GPU est plausible, mais cela déplace aussi le goulot d’étranglement vers les capacités CPU et la bande passante mémoire.

Réduire la concurrence

Chaque requête longue simultanée consomme du cache additionnel et des buffers d’exécution. Un déploiement en station de travail performe souvent mieux avec une petite cible de concurrence et une file d’attente explicite qu’avec un parallélisme de type serveur.

Comment améliorer la latence interactive

Pour un usage local interactif, abaisser reasoning_effort peut réduire la longueur du raisonnement généré, la latence de réponse et la consommation de tokens. Cela ne réduit pas la mémoire nécessaire pour charger les poids ; cela peut seulement diminuer l’usage de cache au moment de la requête en raccourcissant la séquence générée. Utilisez low pour une itération rapide, et passez à high ou max quand une tâche exige un raisonnement plus profond ou un comportement comparable aux benchmarks.

Faut-il exécuter GLM-5.3-Flash en local ou utiliser une API ?

L’auto-hébergement est intéressant quand la confidentialité, la résidence des données, le fonctionnement hors ligne, des paramètres d’inférence personnalisés ou du matériel inactif détenu importent. Il l’est moins lorsque vous avez besoin d’un accès occasionnel au modèle sans maintenir des centaines de gigaoctets de mémoire et une pile de service complexe.

Si le déploiement local n’est pas requis, vous pouvez accéder à GLM-5.3-Flash via un flux chat-completions compatible OpenAI en utilisant l’ID de modèle glm-5.3-flash. C’est utile comme endpoint de référence pour comparer votre build local quantifié à une implémentation hébergée ou comme solution de repli en production pendant que vous testez l’auto-hébergement.

from openai import OpenAI
import os

client = OpenAI(
    base_url="https://api.cometapi.com/v1",
    api_key=os.environ["COMETAPI_KEY"],
)

response = client.chat.completions.create(
    model="glm-5.3-flash",
    messages=[{"role": "user", "content": "Reply with OK"}],
)

print(response.choices[0].message.content)

Problèmes courants lors de l’exécution de GLM-5.3-Flash en local

Le modèle se charge puis plante sur un long prompt

Cela signifie généralement que vous avez dimensionné pour les poids mais pas pour le cache KV. Réduisez la longueur de contexte et la concurrence, puis augmentez progressivement en surveillant la mémoire GPU et système.

Un fichier Q4 tient sur disque mais pas en RAM

La taille du fichier GGUF n’est pas l’empreinte complète à l’exécution. Laissez une marge significative pour les buffers du runtime, le cache et le système d’exploitation.

KTransformers sur un seul GPU est extrêmement lent

C’est attendu lorsque la plupart du travail d’experts est servi depuis la mémoire CPU. Vérifiez le placement NUMA, la bande passante mémoire, le support d’instructions CPU, le comportement de stockage pendant le chargement, et si votre charge ne serait pas mieux servie par un modèle quantifié plus petit.

L’appel d’outils renvoie du JSON mal formé

Confirmez que votre runtime utilise l’analyseur recommandé pour l’intégration actuelle de GLM-5.3-Flash. Les flags d’analyseur peuvent changer entre versions de framework ; n’utilisez pas aveuglément une commande de lancement écrite pour un ancien modèle GLM.

Ollama ou llama.cpp commence à télécharger des centaines de gigaoctets

C’est normal pour cette famille de modèles. Vérifiez le tag de quantification avant de démarrer le téléchargement, confirmez l’espace disque libre, et contrôlez d’abord la taille de fichier correspondante dans le dépôt GGUF.

FAQ

Puis-je exécuter GLM-5.3-Flash sur une RTX 4090 ?

Oui, une RTX 4090 peut participer à l’inférence hétérogène CPU-GPU de KTransformers, mais les 24 GB de VRAM sont loin de suffire pour contenir le checkpoint complet. La voie FP8 KTransformers officielle exige toujours environ 350 GB de mémoire système disponible.

Puis-je exécuter GLM-5.3-Flash sur une RTX 5090 ?

Oui, les GPU de la série RTX 50 sont explicitement inclus dans la liste de support actuelle de KTransformers. Comme avec une 4090, la contrainte clé est le reste du système : capacité RAM, bande passante mémoire, support CPU et quantité de contexte allouée.

Puis-je exécuter GLM-5.3-Flash avec 128 GB de RAM ?

Seules les quantifications GGUF les plus agressives s’en approchent : Q2_K_XL fait environ 109 GB et IQ2_XXS environ 102 GB. Une fois l’overhead d’exécution et le cache KV inclus, 128 GB est une cible très serrée. Ce n’est pas la configuration à choisir si vous voulez une qualité prévisible ou un long contexte.

GLM-5.3-Flash peut-il fonctionner dans Ollama ?

Oui. Unsloth documente le chargement direct dans Ollama pour ses builds GGUF, y compris UD-Q4_K_XL.

De combien de VRAM GLM-5.3-Flash a-t-il besoin ?

Il n’existe pas un seul chiffre correct de VRAM. Le déploiement serveur natif distribue le checkpoint à travers des accélérateurs ; KTransformers combine la VRAM du GPU avec des centaines de gigaoctets de RAM système ; llama.cpp peut offloader un GGUF quantifié entre CPU et GPU. Planifiez selon le runtime et la quantification que vous comptez utiliser.

GLM-5.3-Flash est-il open source ?

La formulation la plus sûre est poids ouverts sous licence MIT. Le dépôt officiel sur Hugging Face liste explicitement la licence MIT et fournit des checkpoints téléchargeables.

GLM-5.3-Flash local est-il moins cher que l’API ?

Pas automatiquement. L’hébergement local peut avoir du sens si vous possédez déjà du matériel adapté, maintenez une utilisation élevée de façon constante, ou devez garder les données dans votre infrastructure. Pour des charges intermittentes, l’accès hébergé évite généralement une lourde charge fixe en matériel et en exploitation.

Conclusion

GLM-5.3-Flash est exceptionnellement efficient pour un modèle d’environ 320B de paramètres au total, mais « Flash » ne signifie pas « petit ». Son design MoE à 18B de paramètres actifs réduit le calcul, tandis que l’attention hybride linéaire et clairsemée rend le long contexte nettement moins coûteux ; néanmoins, les poids exigent toujours des centaines de gigaoctets, à moins d’utiliser une quantification agressive.

La décision pratique de déploiement est donc simple : utilisez vLLM ou SGLang pour une infrastructure GPU de classe serveur ; utilisez KTransformers si vous avez une station de travail avec une très grande mémoire système et souhaitez une inférence CPU-GPU FP8 native ; utilisez llama.cpp ou Ollama lorsque la quantification GGUF et la facilité d’expérimentation comptent le plus. Si aucun de ces profils matériels ne correspond à votre machine, utilisez un endpoint hébergé GLM-5.3-Flash plutôt que de forcer un modèle 320B dans une configuration locale inadaptée.