Comment lancer GLM-5.3 Uncensored EXL3 en local ?

GLM-5.3 Uncensored EXL3 se lance sur une configuration multigPU capable de loger environ 273 Gio de poids, avec de la mémoire supplémentaire pour le cache KV et le contexte. Je détaille sa fabrication, les ressources nécessaires, la quantification et les limites à vérifier avant un déploiement agentique.

Qu’est-ce que GLM-5.3 Uncensored EXL3 ?

GLM-5.3 Uncensored EXL3 est une édition auto-hébergeable de GLM-5.3, préparée pour l’inférence sur des grappes de GPU locales ou louées. Sa création suit trois étapes distinctes. Ce n’est pas un nouvel entraînement du modèle.

1. Modèle de base	GLM-5.3, fourni par Z.ai.
2. Modification des poids	dealignai modifie directement les poids du modèle pour retirer des comportements d’alignement.
3. Quantification	Infatoshi publie la version EXL3 en 3,0 bpw, c’est-à-dire environ 3 bits par poids en moyenne.

La quantification réduit l’espace nécessaire au stockage et à l’exécution du modèle, au prix d’une représentation moins précise des poids. La taille annoncée est d’environ 273 Gio. La fiche indique une licence MIT.

Le terme « uncensored » décrit ici l’objectif de la modification attribuée à dealignai : retirer des comportements liés à l’alignement. Il ne prouve pas que toutes les restrictions ont disparu, ni que le modèle répondra à toutes les demandes. Les informations disponibles ne détaillent pas la méthode exacte de modification, les comportements retirés, les évaluations effectuées ni les éventuelles limites observées. Ces points ne doivent donc pas être déduits du seul nom de l’édition.

Les éléments établis sont la provenance en trois étapes, le format EXL3 à 3,0 bpw, la taille approximative, la licence annoncée et la destination en auto-hébergement. Les détails non documentés restent à vérifier dans les ressources publiées par les mainteneurs avant tout déploiement.

Quel matériel faut-il pour l’exécuter ?

Il faut une configuration multi-GPU importante : les poids du modèle occupent environ 273 Gio, auxquels s’ajoutent la mémoire nécessaire au cache KV et au contexte. La capacité totale requise dépend donc aussi de la longueur du contexte et des réglages d’inférence.

Le test documenté a été réalisé sur 8 GPU NVIDIA A100 de 40 Go. TabbyAPI répartit automatiquement le modèle entre les GPU disponibles. Cette configuration atteste d’un lancement dans cet environnement, mais elle ne définit pas une configuration minimale : les éléments publiés ne permettent pas d’en déduire une capacité minimale, un débit ou un coût d’exécution.

Les usages visés sont les postes de travail multi-GPU, les grappes de GPU louées et les systèmes d’inférence d’entreprise. Pour un déploiement, il faut aussi réserver de la mémoire au cache KV — les données conservées pour accélérer la génération — et au contexte, c’est-à-dire aux tokens traités et générés pendant une requête.

Aucune voie officielle d’exécution sur CPU seul ou sur un GPU unique n’est documentée. Je ne considérerais donc pas ces options comme des configurations prises en charge pour cette version.

Ressource	Valeur documentée	Réserve
Poids du modèle	Environ 273 Gio	Le cache KV et le contexte demandent de la mémoire supplémentaire.
Test multi-GPU	8 GPU NVIDIA A100 de 40 Go	Test documenté, pas configuration minimale déclarée.
Répartition du modèle	Automatique avec TabbyAPI	La configuration testée repose sur plusieurs GPU.
Usages visés	Postes multi-GPU, grappes louées, inférence d’entreprise	Aucun débit ni coût n’est déduit.
CPU seul ou GPU unique	Aucune voie officielle documentée	Ne pas les considérer comme des modes pris en charge.

Comment le modèle a-t-il été construit ?

GLM-5.3 Uncensored EXL3 a été construit en modifiant directement le checkpoint FP8 de zai-org/GLM-5.3, puis en le quantifiant au format EXL3. Aucun fine-tuning n’a été effectué.

Le modèle de départ est un modèle mixture-of-experts de 753 milliards de paramètres. Cette architecture répartit le calcul entre 256 experts routés, dont huit sont activés pour chaque jeton, auxquels s’ajoute un expert partagé. Le modèle utilise une attention MLA, une attention latente multi-tête qui réduit les besoins liés au cache d’attention, comprend 78 couches et inclut une couche MTP, dédiée à la prédiction de plusieurs jetons.

Dealignai a modifié le checkpoint FP8 à l’aide du fichier CRACK_SURGERY.json. Il s’agit d’une intervention directe sur les poids du modèle, pas d’un nouvel entraînement. Le checkpoint obtenu a ensuite été quantifié avec ExLlamaV3, le moteur utilisé pour produire les poids EXL3.

La quantification s’est appuyée sur un jeu de calibration de 250 séquences de 2 048 jetons. La calibration sert à guider la compression à partir d’exemples d’entrée représentatifs. Les composants n’ont pas tous reçu la même précision : le nombre de bits par poids varie selon les parties du modèle. La couche MTP a été quantifiée séparément.

Deux chiffres sont à distinguer. La publication présente le modèle comme une quantification à 3,0 bpw, c’est-à-dire environ trois bits par poids. La moyenne rapportée est de 3,04 bits par poids. Cet écart vient du fait que 3,0 bpw est la valeur de publication, tandis que 3,04 décrit la moyenne obtenue sur les composants quantifiés.

Comment le faire tourner avec TabbyAPI ?

GLM-5.3 Uncensored EXL3 s’exécute en local avec ExLlamaV3 et TabbyAPI, sur une configuration multi-GPU. Le déploiement documenté répartit automatiquement le modèle sur huit GPU A100 de 40 Go.

Les poids occupent environ 273 Gio. Cette valeur ne couvre pas toute la mémoire nécessaire : le cache KV — qui conserve les clés et valeurs utilisées par l’attention — et le contexte demandent de la mémoire supplémentaire. La marge disponible dépend donc aussi de la longueur du contexte et des usages prévus.

Un point bloque les usages agentiques : le parseur GLM4.5 de TabbyAPI peut convertir en nombres des arguments textuels transmis lors d’appels d’outils. Une chaîne qui devrait rester du texte risque alors d’être interprétée comme une valeur numérique. Ce bogue doit être corrigé avant d’utiliser le modèle avec des agents ou des outils ; sans correction, les arguments transmis peuvent être altérés.

La couche MTP (prédiction de plusieurs tokens) peut servir au décodage spéculatif, une méthode qui vise à accélérer la génération en anticipant plusieurs tokens. Les informations disponibles ne documentent pas de procédure d’activation : je ne peux donc pas recommander de configuration précise.

Éléments documentés	À vérifier avant déploiement
ExLlamaV3 avec TabbyAPI sur plusieurs GPU.	La mémoire réellement disponible après chargement des poids.
Répartition automatique sur 8 GPU A100 de 40 Go.	La marge nécessaire au cache KV et au contexte visé.
Poids d’environ 273 Gio.	La correction du parseur GLM4.5 avant tout usage agentique.
La couche MTP peut servir au décodage spéculatif.	La disponibilité et la procédure d’activation de MTP dans votre version de TabbyAPI.

Quel est l’impact de la quantification sur les résultats ?

La quantification EXL3 entraîne une perte de fidélité modérée, visible sur la perplexité, tandis que les résultats mesurés sur certains benchmarks d’agents restent proches de la référence FP8. Ces chiffres décrivent un protocole précis, pas une équivalence générale entre les deux modèles.

Sur 20 séquences de 2 048 jetons de wikitext-2, la perplexité passe de 3,302 en FP8 à 3,440 en EXL3. La perplexité mesure à quel point le modèle est surpris par le texte : une valeur plus élevée indique ici une prédiction moins fidèle. L’écart est réel, mais reste limité dans cet échantillon.

La divergence KL, qui quantifie l’écart entre deux distributions de probabilité, se situe entre 0,089 et 0,097 selon le sens de comparaison. Sa médiane par jeton est de 0,021. Pour les jetons sur lesquels le modèle FP8 est très sûr de sa prédiction, la divergence médiane tombe à 0,0011. L’écart est donc concentré sur une partie des prédictions, plutôt que réparti uniformément.

Sur tau2-bench airline et retail, les écarts observés sont faibles et non significatifs aux tailles d’échantillon testées. Ça ne prouve ni que les modèles sont équivalents, ni que le résultat se maintiendra sur d’autres tâches, jeux de données ou réglages d’inférence. La qualité de la quantification doit être évaluée sur vos propres cas d’usage, surtout si votre application dépend de réponses rares ou très précises.

Métrique	Protocole	Résultat	Interprétation prudente
Perplexité	20 séquences de 2 048 jetons de wikitext-2	FP8 : 3,302 ; EXL3 : 3,440	Perte de fidélité mesurable dans ce protocole.
Divergence KL	Comparaison dans les deux sens	0,089 à 0,097 ; médiane par jeton : 0,021	Écart entre distributions, dépendant du sens de comparaison.
Divergence sur les jetons très sûrs en FP8	Sous-ensemble défini par la confiance du modèle FP8	Médiane : 0,0011	Écart médian faible sur ce sous-ensemble.
tau2-bench airline et retail	Tailles d’échantillon testées	Écarts faibles, non significatifs	Pas de preuve d’équivalence générale.

Cette configuration correspond-elle à votre usage ?

GLM-5.3 Uncensored EXL3 est une option d’auto-hébergement pour les environnements multigPU, pas un modèle conçu pour une machine standard. Ses quelque 273 Gio de poids et le besoin mémoire du cache KV imposent une infrastructure conséquente ; le test documenté utilise 8 A100 de 40 Go. La quantification EXL3 augmente modestement la perplexité par rapport au checkpoint FP8, tandis que les résultats observés sur deux benchmarks d’agents restent proches dans les limites des échantillons testés. Pour un usage agentique, le bogue de parsing des appels d’outils doit être traité. Vous pouvez ainsi évaluer le coût matériel, le compromis de fidélité et les risques d’intégration avant de déployer le modèle localement.

FAQ

• Combien de mémoire faut-il pour GLM-5.3 Uncensored EXL3 ?
  Les poids occupent environ 273 Gio. Il faut ajouter la mémoire nécessaire au cache KV et au contexte, dont la quantité dépend de la configuration d’exécution.
• Peut-on exécuter ce modèle sur un seul GPU ?
  Aucune voie officielle sur un seul GPU n’est documentée. Le test rapporté utilise 8 GPU A100 de 40 Go avec TabbyAPI.
• Quelle est la différence entre EXL3 3,0 bpw et 3,04 bits par poids ?
  3,0 bpw correspond à la désignation de la version publiée. La moyenne mesurée des poids quantifiés est de 3,04 bits par poids, car les composants n’utilisent pas tous la même précision.
• La quantification dégrade-t-elle fortement les résultats ?
  La perplexité passe de 3,302 en FP8 à 3,440 en EXL3 sur le protocole rapporté. Les écarts observés sur tau2-bench airline et retail sont faibles et non significatifs aux tailles d’échantillon testées, sans prouver une équivalence générale.
• Le modèle est-il prêt pour les appels d’outils ?
  Un bogue du parseur GLM4.5 de TabbyAPI peut convertir des arguments textuels en nombres. Il faut corriger ce problème avant un usage agentique. La couche MTP peut servir au décodage spéculatif.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en Analytics, Data engineering et automatisation IA. J’accompagne les équipes sur l’infrastructure data, l’évaluation des modèles et leur intégration dans des workflows fiables.