#Pourquoi GLM-5.2 en local

La plupart des modèles « frontier » (les plus gros et les plus capables) restent enfermés derrière une API : GPT, Gemini, ou les versions 100B+ de Qwen et DeepSeek. GLM-5.2 casse cette logique. Zhipu AI a publié les poids complets sous licence MIT — la plus permissive qui soit, sans clause d'attribution ni de partage à l'identique — et la communauté a produit des quants GGUF fonctionnels dès la sortie. Résultat : vous pouvez héberger un modèle de classe frontier chez vous, sans compte, sans quota, sans fuite de données.

L'intérêt n'est pas la vitesse — soyons clairs, un 753B en local ne rivalisera jamais avec un endpoint cloud pour la réactivité. L'intérêt est la souveraineté totale sur un modèle qui, en qualité brute, joue dans la même cour que les meilleurs services propriétaires : raisonnement long, code sur de grosses bases, contexte de 1 million de tokens. Pour un agent de code qui tourne des heures sur du code propriétaire sous NDA, la question de la vitesse passe après celle de la confidentialité.

En deux mots

GLM-5.2 = 753B MoE, licence MIT, contexte 1M, avec des quants GGUF réels sur Ollama et LM Studio. C'est le seul modèle frontier-size qu'on peut honnêtement recommander d'auto-héberger aujourd'hui — à condition d'avoir la RAM ou la VRAM pour le porter.

#Ce qui change depuis GLM-5.1

Si vous cherchez à installer un GLM raisonnable sur un GPU 12 à 24 Go, ce guide n'est pas le bon : GLM-5.1 (dense 9B et 32B) est fait pour ça, et notre guide dédié le couvre en détail. GLM-5.2 vise un autre public. La confusion est fréquente parce que les noms se suivent, mais les deux modèles ne jouent pas dans la même catégorie de matériel.

Architecture: GLM-5.1 est dense (9B, 32B). GLM-5.2 est un MoE de 753B au total, avec une fraction d'experts activés par token. On ne le déploie pas sur un GPU grand public seul.
Licence: GLM-5.1 est sous GLM License (variante Apache avec attribution). GLM-5.2 passe à la MIT pure — usage commercial sans contrainte, aucune clause virale.
Contexte: 128k sur GLM-5.1 (1M via YaRN dégradé). GLM-5.2 gère nativement 1M tokens, un vrai avantage pour l'analyse de gros dépôts.
Cible matérielle: GLM-5.1 : un GPU 8-24 Go. GLM-5.2 : Mac à 256 Go de mémoire unifiée, ou box multi-GPU, ou serveur avec beaucoup de RAM et offload.
Cas d'usage: GLM-5.1 pour un assistant local réactif. GLM-5.2 pour un modèle frontier de référence, quand la qualité prime sur la vitesse.

→

Lequel choisir

Si votre matériel plafonne à 24 Go de VRAM, restez sur GLM-5.1 32B : il sera plus rapide et plus confortable. GLM-5.2 n'a de sens que si vous disposez de 128 Go et plus de mémoire (unifiée ou RAM+VRAM) et que vous acceptez 5 à 15 tok/s en échange de la qualité frontier.

#753B MoE : comprendre le modèle

GLM-5.2 est un Mixture-of-Experts : sur ses 753 milliards de paramètres, seule une fraction est activée à chaque token généré. C'est ce qui rend l'inférence envisageable en local — le calcul par token reste raisonnable — mais le piège est ailleurs : la totalité des poids doit tenir en mémoire, même les experts qui ne sont pas sollicités à un instant donné. C'est la mémoire, pas la puissance de calcul, qui est le facteur limitant.

Paramètres totaux: 753B, répartis entre un backbone partagé et un banc d'experts routés dynamiquement.
Paramètres actifs: Une fraction par token (routage top-k). C'est ce qui permet un débit décent malgré la taille totale.
Contexte: 1M tokens natif. Attention : le KV-cache à 1M consomme énormément de mémoire, réservez-le aux cas qui le justifient.
Licence: MIT. Vous pouvez fine-tuner, redistribuer, intégrer en produit commercial sans obligation.
Format: Poids d'origine en BF16 (~1,5 To). Inutilisable tel quel en local : c'est là qu'interviennent les quants GGUF.

La mémoire avant tout

Ne raisonnez pas comme pour un modèle dense. Un MoE 753B n'active qu'une partie de ses poids par token, mais il faut TOUS les charger en mémoire. Un quant 2-bit descend le modèle à ~200 Go environ ; c'est ce chiffre-là qui détermine si votre machine peut l'accueillir, pas le nombre de paramètres actifs.

#Les quants GGUF (unsloth)

La communauté a produit les quantifications qui rendent GLM-5.2 exploitable. Les quants dynamiques d'unsloth sont la référence : ils appliquent une précision variable selon l'importance des couches, ce qui préserve la qualité mieux qu'une quantification uniforme au même poids. C'est décisif à très basse précision, où chaque bit compte.

Q2_K_XL (unsloth): ~200 Go. Le point d'entrée réaliste. Qualité dégradée mais utilisable, c'est la version qui tient sur un Mac 256 Go ou une box multi-4090.
Q4_K_M: ~380-400 Go. Le sweet spot qualité, mais réservé aux serveurs à très grosse mémoire ou multi-GPU costaud.
Q5_K_M: ~480 Go. Peu de gain perceptible sur Q4 pour ce type de modèle ; rarement justifié en local.
Q8_0 / BF16: 800 Go à 1,5 To. Domaine du serveur GPU professionnel, hors de portée d'une machine grand public.

Télécharger un quant unsloth (Hugging Face)

# huggingface-cli doit être installé : pip install -U huggingface_hub
# Q2_K_XL est réparti en plusieurs shards GGUF
huggingface-cli download unsloth/GLM-5.2-GGUF \
  --include "*Q2_K_XL*" \
  --local-dir ./glm-5.2-gguf

→

Pourquoi les quants dynamiques

À 2-bit, une quantification uniforme détruit la cohérence du modèle. Les quants dynamiques unsloth gardent en précision plus haute les couches sensibles (attention, embeddings) et compressent agressivement le reste. C'est ce qui fait qu'un Q2_K_XL reste cohérent là où un Q2 naïf part en vrille.

#Prérequis matériels réalistes

Il n'y a pas de configuration « légère » pour GLM-5.2. Voici les deux profils qui fonctionnent vraiment, sans tricher sur les chiffres.

Mac Apple Silicon 256 Go: Un Mac Studio M-series avec 256 Go de mémoire unifiée accueille le Q2_K_XL avec de la marge pour le contexte. La mémoire unifiée est ici un avantage décisif : pas de séparation CPU/GPU.
Mac 192 Go: Jouable mais serré : le Q2_K_XL passe, mais réduisez la fenêtre de contexte et fermez tout le reste. 128 Go est en dessous du seuil praticable.
Box multi-GPU: Plusieurs RTX 4090 (24 Go chacune) + beaucoup de RAM système pour l'offload CPU. On ne fait pas tenir 200 Go en VRAM seule, on répartit GPU + RAM.
Stockage: 200 Go libres minimum pour le Q2, un SSD NVMe rapide (le chargement initial lit des centaines de Go).
RAM système (box): 128 Go de RAM au minimum si vous offloadez des experts sur CPU, 256 Go pour être confortable.

#1. Installation avec LM Studio

LM Studio est souvent le plus simple pour un modèle de cette taille, surtout sur Mac : son moteur MLX et sa gestion mémoire sont bien rodés, et l'interface montre en temps réel combien de mémoire le modèle réclame avant de le charger. C'est précieux quand on flirte avec la limite.

01
1. Installer LM Studio
Téléchargez LM Studio depuis le site officiel (lmstudio.ai) et installez-le. Sur Mac, prenez la version Apple Silicon native.
02
2. Chercher le modèle
Dans l'onglet de recherche, tapez « GLM-5.2 » et repérez le dépôt unsloth GGUF. LM Studio affiche pour chaque quant s'il est compatible avec votre RAM disponible (badge vert/orange/rouge).
03
3. Choisir le quant Q2_K_XL
Sélectionnez la variante Q2_K_XL. LM Studio télécharge tous les shards automatiquement — comptez un long moment selon votre connexion (200 Go).
04
4. Régler le contexte
Avant de charger, baissez la longueur de contexte à une valeur raisonnable (8k-16k pour tester). Ne mettez pas 1M d'entrée : le KV-cache ferait exploser la mémoire.
05
5. Charger et tester
Cliquez sur « Load ». Surveillez la jauge mémoire. Une fois chargé, envoyez un premier prompt et mesurez le débit affiché en tok/s.

MLX vs GGUF sur Mac

LM Studio propose aussi des versions MLX (format Apple) pour certains modèles. Pour GLM-5.2, le GGUF unsloth reste la voie confirmée et la plus documentée. Si une version MLX quantifiée apparaît, elle peut offrir un léger gain de vitesse sur Apple Silicon, mais vérifiez d'abord qu'elle existe réellement avant de la chercher.

#2. Installation avec Ollama

Ollama sait aussi servir GLM-5.2 à partir d'un GGUF, via un Modelfile qui pointe vers les fichiers téléchargés. C'est la voie à privilégier si vous voulez exposer le modèle en API OpenAI-compatible à d'autres outils (agents, IDE, Open WebUI).

Modelfile pour un GGUF local

# Fichier : Modelfile
FROM ./glm-5.2-gguf/GLM-5.2-Q2_K_XL-00001-of-00005.gguf

PARAMETER num_ctx 16384
PARAMETER temperature 0.6

Créer et lancer le modèle

# Créer l'entrée Ollama à partir du Modelfile
ollama create glm-5.2 -f Modelfile

# Lancer
ollama run glm-5.2

Une fois créé, GLM-5.2 est servi comme tout modèle Ollama sur l'endpoint par défaut http://localhost:11434. N'importe quel client OpenAI-compatible peut alors l'interroger en pointant sur cette adresse.

Vérifier la répartition GPU/CPU

# Dans un autre terminal, après le premier prompt
ollama ps

Débordement attendu

Avec un modèle de cette taille, ollama ps affichera presque toujours un mélange GPU/CPU sauf sur une machine surdimensionnée. C'est normal ici, contrairement aux petits modèles : l'objectif n'est pas le 100% GPU mais de faire tenir le modèle sans swap disque, qui lui tuerait vraiment les performances.

#3. Config Mac 256 Go

C'est la configuration la plus élégante pour GLM-5.2. La mémoire unifiée d'Apple Silicon signifie que le GPU et le CPU partagent le même pool : pas de transferts coûteux, pas de découpage manuel. Un Mac Studio avec 256 Go charge le Q2_K_XL et laisse de la place pour un contexte confortable.

Modèle chargé: Q2_K_XL (~200 Go) tient, avec ~40-50 Go restants pour le KV-cache et le système.
Débit attendu: Autour de 5 à 12 tok/s en génération selon la longueur de contexte. Confortable pour du travail asynchrone, frustrant pour du chat interactif rapide.
Contexte praticable: 32k à 64k sans souci. Monter vers 128k+ est possible mais grignote vite la mémoire via le KV-cache.
Outil recommandé: LM Studio pour la simplicité, ou Ollama si vous branchez des agents dessus.

→

Libérer la limite mémoire GPU sur Mac

macOS réserve par défaut une part de la mémoire unifiée au système. Pour laisser plus de RAM au GPU sur une grosse config, on peut ajuster iogpu.wired_limit_mb via sysctl. Faites-le prudemment et testez : réserver trop peu au système rend la machine instable.

#4. Box RTX 4090 en 2-bit

Sur PC, il faut composer avec la séparation VRAM/RAM. Une seule RTX 4090 (24 Go) ne suffit évidemment pas à contenir 200 Go : la stratégie consiste à charger un maximum d'experts en VRAM et à offloader le reste sur la RAM système via llama.cpp. Le débit dépend alors directement du ratio GPU/CPU et de la vitesse de votre RAM.

Lancement llama.cpp avec offload

./llama-server \
  -m glm-5.2-gguf/GLM-5.2-Q2_K_XL-00001-of-00005.gguf \
  -c 16384 \
  -ngl 99 \
  --n-cpu-moe 40 \
  -fa \
  --host 0.0.0.0 --port 8080

-ngl 99: Tente de placer un maximum de couches en GPU. llama.cpp remplit la VRAM disponible et bascule le reste sur CPU.
--n-cpu-moe 40: Garde les couches MoE indiquées sur le CPU. C'est le levier clé pour un MoE : on met le backbone dense en VRAM et on offloade les experts sur RAM. Ajustez le nombre selon votre VRAM.
-fa: Flash attention, réduit la consommation mémoire du KV-cache. À garder activé.
Multi-GPU: Avec 2 à 4 RTX 4090, llama.cpp répartit automatiquement (--split-mode). Plus de VRAM = moins d'offload CPU = meilleur débit.

Le débit chute vite avec l'offload

Chaque couche renvoyée sur CPU coûte cher. Sur une seule 4090 avec l'essentiel des experts en RAM, attendez-vous à 2 à 5 tok/s — c'est lent. Le multi-GPU améliore nettement la situation. Sur PC, GLM-5.2 est un exercice de patience, réservez-le aux tâches où la qualité justifie l'attente.

#5. Agents de code longue durée

C'est là que GLM-5.2 en local prend tout son sens malgré sa lenteur. Un agent de code qui refactore une grosse base, lit des dizaines de fichiers et raisonne sur des heures se moque d'une latence de quelques secondes par token : il travaille en tâche de fond. Ce qui compte, c'est la qualité du raisonnement et le contexte de 1M qui lui permet de garder tout le dépôt en tête, le tout sans qu'une ligne de code propriétaire ne quitte votre machine.

Contexte massif: Le million de tokens permet d'injecter une base de code entière dans le prompt plutôt que de la fragmenter, ce qui améliore la cohérence des modifications multi-fichiers.
Tool calling: GLM-5.2 gère les appels d'outils au format OpenAI, indispensable pour un agent qui lit, écrit et exécute.
Endpoint OpenAI: Via Ollama (localhost:11434) ou llama.cpp (localhost:8080), branchez Aider, Cline ou tout agent parlant l'API OpenAI.
Travail asynchrone: Lancez la tâche, faites autre chose. À 5-10 tok/s, un gros refactor prend du temps mais tourne sans supervision.

La confidentialité comme argument principal

Pour du code sous NDA ou secret industriel, GLM-5.2 local est l'un des rares moyens d'obtenir une qualité proche du frontier sans jamais transmettre le code à un tiers. La lenteur devient un compromis acceptable face au risque juridique et de fuite qu'implique un agent cloud.

#Attentes honnêtes et dépannage

Aucun guide sérieux ne prétendra que faire tourner un 753B en local est fluide. Voici les problèmes réels et leurs correctifs.

Swap disque = mort: Si le modèle déborde en swap disque, le débit tombe à des secondes par token. Réduisez le contexte, prenez un quant plus petit, ou fermez les autres applications gourmandes en RAM.
Chargement très lent: Charger 200 Go depuis un SSD prend plusieurs minutes. C'est normal. Un SSD NVMe rapide fait une vraie différence ; un disque externe USB est à proscrire.
OOM au chargement: Sur Mac, ajustez la limite GPU (iogpu.wired_limit_mb). Sur PC, augmentez --n-cpu-moe pour renvoyer plus d'experts sur RAM.
Qualité en baisse: À 2-bit, le modèle peut halluciner davantage. Baissez la température (0.6 ou moins) et privilégiez les quants dynamiques unsloth plutôt qu'un Q2 uniforme.
Débit décevant: C'est attendu. Un frontier-size en local n'est pas rapide. Si vous voulez de la vitesse, GLM-5.1 32B ou un Qwen3 seront bien plus réactifs.

#Pour aller plus loin

GLM-5.2 est un cas extrême qui touche à la quantification, au matériel et au déploiement d'agents. Ces guides couvrent les fondamentaux à maîtriser autour.

Le petit frère raisonnable: « GLM 5.1 en local : l'alternative open-weight à connaître » — si votre matériel plafonne à 24 Go, c'est le modèle GLM qu'il vous faut, bien plus réactif.
Comprendre les quants: « Choisir sa quantification (Q4, Q5, Q8, FP16) » — indispensable pour saisir pourquoi le 2-bit dynamique rend GLM-5.2 accessible sans le détruire.
Coder avec un agent local: « Aider + Ollama : coder dans le terminal avec un agent 100% local » — le point de départ pour brancher GLM-5.2 sur un vrai workflow de développement.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Modèles · 10 min