Faire tourner GLM-5.2 en local : la configuration complète

Ce que GLM-5.2 change vraiment

GLM-5.2 n'est pas juste un chatbot de plus. C'est un modèle pensé pour les tâches longues : lire beaucoup de contexte, garder un plan, modifier du code, lancer des outils, revenir sur ses erreurs et continuer à travailler pendant longtemps. C'est exactement le territoire des agents de code.

Le blog officiel annonce un contexte solide de 1 million de tokens, plusieurs niveaux d'effort pour le code et IndexShare pour réduire le coût du long contexte. Hugging Face affiche 753B paramètres pour le checkpoint BF16, tandis que la recette vLLM décrit environ 743B paramètres totaux et 39B actifs.

753B ou 743B : pourquoi les chiffres ne collent pas toujours

Deux chiffres officiels coexistent : 753B dans la fiche Hugging Face et environ 743B / 39B actifs dans la recette vLLM. Les outils ne comptent pas toujours de la même manière les embeddings, têtes auxiliaires ou variantes de checkpoint.

La formulation prudente est donc : GLM-5.2 est un énorme MoE d'environ 743 à 753 milliards de paramètres, dont environ 39 milliards sont actifs par token. Pour le matériel, la taille exacte du checkpoint choisi reste la mesure utile.

Benchmarks : là où il fait très mal

Est-ce qu'il me dépasse ?

La bonne réponse est : sur certaines tâches, probablement oui. Si la tâche est un long projet de code avec beaucoup de fichiers, beaucoup de contexte et un agent qui doit tenir une stratégie pendant longtemps, GLM-5.2 peut être plus adapté que beaucoup de modèles généralistes.

Mais il ne faut pas transformer un benchmark en religion. Un modèle peut battre GPT ou Claude sur Terminal-Bench, puis être moins bon en écriture, multimodal, instruction-following fin, sécurité, latence, coût, disponibilité ou stabilité API. GLM-5.2 est surtout une alerte : l'open-weights chinois arrive très fort sur le code agentique.

Quelle taille faut-il réellement charger ?

La fiche GGUF d'Unsloth expose désormais plusieurs quantifications publiques. La taille du fichier n'est pas la mémoire totale requise : gardez une marge pour le système, le runtime et le cache KV. Le contexte de 1 million de tokens n'est donc pas un réglage à activer par défaut sur une station domestique.

Trois configurations adaptées à GLM-5.2

La recette SGLang précise une limite importante : le BF16 complet tient sur un nœud de 8×B300, ou sur 8×MI325X/MI355X, mais pas avec assez de marge sur un seul nœud 8×H200, 8×B200 ou 8×MI300X. Le FP8 reste donc la voie officielle raisonnable pour ces nœuds. Ce sont des configurations datacenter, pas des conseils d'achat grand public.

La configuration OutilsIA à construire

Pour une machine réellement achetable, notre choix est une station 512 Go orientée GGUF IQ2/Q3. Le CPU et les huit canaux mémoire comptent davantage qu'un simple record de VRAM, car la majorité des poids reste en RAM. Deux GPU accélèrent l'inférence, mais ne transforment pas 64 Go de VRAM en 254 Go.

Installer GLM-5.2 avec Ollama ou llama.cpp

La bibliothèque Ollama classique ne fournit pas encore un petit tag officiel prêt à l'emploi. Hugging Face documente en revanche le lancement direct des GGUF Unsloth. Commencez par la quantification la plus légère compatible avec votre RAM, sur un disque disposant de plusieurs centaines de gigaoctets libres.

Le catalogue OutilsIA classe donc GLM-5.2 comme modèle de station et n'en lance pas automatiquement le téléchargement. C'est volontaire : un clic ne doit pas déclencher silencieusement 239 ou 466 Go de transfert.

Windows ou Linux avec Ollama

# Quantification 2 bits : environ 239 Go
ollama run hf.co/unsloth/GLM-5.2-GGUF:UD-IQ2_M

# Quantification Q4_K_M documentée : environ 466 Go
ollama run hf.co/unsloth/GLM-5.2-GGUF:UD-Q4_K_M

Le second téléchargement n'a de sens que sur une machine disposant d'au moins 768 Go de mémoire exploitable. Sur 512 Go, restez sur IQ2/Q3 et réduisez le contexte initial.

llama.cpp : serveur local compatible OpenAI

# Windows
winget install llama.cpp
llama serve -hf unsloth/GLM-5.2-GGUF:UD-IQ2_M --ctx-size 8192

# Puis tester l'API locale
curl http://127.0.0.1:8080/v1/models

Augmentez le contexte seulement après avoir mesuré la mémoire. Le “1M context” est une capacité architecturale, pas une promesse que le cache KV tiendra dans votre station.

ZCode avec GLM-5.2 : ce qui est local et ce qui ne l'est pas

ZCode est un environnement de développement agentique de bureau conçu autour de GLM-5.2. Il regroupe objectifs longs, lecture et modification de fichiers, terminal, Git, revue, sous-agents, compétences, plugins, MCP, contrôle mobile et développement distant par SSH ou Docker.

Parcours ZCode recommandé

1. Installez ZCode depuis le site officiel et ouvrez un projet test.
2. Pour démarrer vite, connectez un compte Z.ai et sélectionnez GLM-5.2 dans le sélecteur de modèles.
3. Pour du vrai local, démarrez d'abord le serveur GLM-5.2 sur http://127.0.0.1:8080/v1.
4. Dans Model Settings, ajoutez un fournisseur personnalisé OpenAI compatible et renseignez cette Base URL.
5. Testez une instruction courte avant Goal Mode ; n'accordez les permissions terminal qu'après lecture du plan.
6. Pour une station distante, créez la connexion SSH depuis le bureau. Le contrôle mobile ne crée pas lui-même une nouvelle connexion SSH.

Quel chemin choisir ?

1. Vous avez moins de 256 Go de RAM : utilisez ZCode avec Coding Plan/API ou choisissez un modèle local 14B/32B.
2. Vous avez 384 à 512 Go : expérimentez IQ1/IQ2 avec llama.cpp ou Ollama, contexte court, sans promesse de fluidité.
3. Vous construisez une station 768 Go/1 To : Q3/Q4 devient envisageable ; privilégiez ECC, bande passante mémoire et stockage.
4. Vous servez plusieurs utilisateurs : suivez les recettes FP8 SGLang/vLLM sur 8 GPU serveur.

Questions fréquentes

Peut-on lancer GLM-5.2 avec Ollama ?

Oui via les GGUF Hugging Face, notamment ceux d'Unsloth. Ce n'est toutefois pas un petit modèle de la bibliothèque Ollama : vérifiez plusieurs centaines de gigaoctets libres avant le premier téléchargement.

Une seule RTX 5090 suffit-elle ?

Non. Ses 32 Go servent à l'offload et accélèrent une partie du calcul, mais le modèle quantifié reste majoritairement en RAM. Même deux RTX 5090 totalisent seulement 64 Go de VRAM.

Un mini-PC Strix Halo 128 Go peut-il le charger ?

Non pour les quantifications complètes listées ici : le plus petit GGUF public fait environ 217 Go. Strix Halo reste excellent pour des modèles beaucoup plus petits, mais pas pour ce checkpoint intégral.

ZCode est-il une solution locale ?

L'application et l'espace de travail sont locaux. Avec Coding Plan, le modèle est distant. Pour une chaîne totalement auto-hébergée, il faut sélectionner dans ZCode un fournisseur personnalisé qui pointe vers votre serveur compatible OpenAI/Anthropic.

Quelle RAM faut-il pour GLM-5.2 en local ?

384 à 512 Go pour expérimenter avec IQ1/IQ2, 512 Go pour certains Q3, et 768 Go à 1 To conseillé pour un Q4 avec marge.

Verdict OutilsIA

GLM-5.2 est probablement l'un des modèles open-weights les plus importants de 2026 pour le code agentique. Il ne remplace pas votre assistant local aujourd'hui, mais il montre la direction : grands contextes, agents longue durée, licences ouvertes, et pression énorme sur les modèles fermés.

La phrase juste n'est pas "GLM-5.2 bat tout le monde". La phrase juste est : GLM-5.2 prouve qu'un modèle open-weights peut entrer dans la même conversation que GPT, Claude et Gemini sur des tâches de code très difficiles.

Sources

• Z.ai : GLM-5.2 Built for Long-Horizon Tasks
• Fiche Hugging Face GLM-5.2
• Unsloth / Hugging Face : GGUF, tailles et commandes
• vLLM : recette GLM-5.2 FP8
• SGLang : matériel, mémoire et déploiement GLM-5.2
• KTransformers : tutoriel CPU-GPU GLM-5.2
• Documentation officielle ZCode
• ZCode : Coding Plan, API et fournisseurs auto-hébergés
• ZCode : développement distant SSH et Docker