Vous pouvez exécuter un modèle GLM en local parce que les poids sont réellement publiés, et non protégés par un formulaire de demande ou un point de terminaison hébergé. Cette page couvre les quatre éléments qui décident du succès d'un déploiement local : la licence sous laquelle vous opérez, l'endroit où vivent les poids, les frameworks de service pris en charge, et la façon de dimensionner le matériel pour la longueur de contexte dont vous avez réellement besoin plutôt que pour le seul nombre de paramètres. Aucun n'est difficile isolément ; c'est de réussir les quatre en même temps que dépend la différence entre un déploiement qui fonctionne et un week-end de débogage.
La raison de s'y intéresser est simple. Un modèle GLM open source tournant sur votre propre matériel garde chaque prompt dans votre réseau, ne peut pas être retiré sous vos pieds, et peut être affiné sur des données que vous n'enverriez jamais à un tiers. Ce sont ces propriétés qui poussent des équipes à choisir des poids ouverts même quand un modèle hébergé obtient quelques points de plus.
Les poids des modèles GLM principaux sont publiés sous licence MIT, sans restriction régionale. MIT est à peu près aussi permissive qu'une licence logicielle peut l'être : usage, modification, distribution et déploiement commercial, avec attribution et sans garantie. Il n'y a pas de clause d'usage acceptable distincte venant restreindre ce que la licence accorde par ailleurs, ni de clause géographique décidant où vous pouvez la servir.
Cela compte davantage pour des modèles que pour du logiciel ordinaire, car beaucoup de versions nominalement ouvertes comportent des clauses qui rendent le déploiement en production juridiquement ambigu. Vérifiez le fichier de licence livré avec le point de sauvegarde précis que vous téléchargez — c'est le texte qui fait foi, et il se lit en une trentaine de secondes.
Les poids sont publiés sur HuggingFace et sur ModelScope. Les deux hébergent les points de sauvegarde complets plutôt que des adaptateurs ou des versions partielles : vous pouvez donc les récupérer avec l'outillage standard de l'une ou l'autre plateforme. Répliquer le point de sauvegarde dans votre propre dépôt d'artefacts avant la mise en production est une bonne pratique, pour la même raison que pour les images de conteneurs : votre déploiement ne devrait pas dépendre de la disponibilité d'un hébergeur externe au moment où vous montez en charge.
Les auteurs du modèle annoncent la prise en charge de cinq piles d'inférence qui, ensemble, couvrent pratiquement toutes les formes de déploiement local, de la station de travail unique au cluster multi-nœuds.
L'implémentation de référence. La plus lente pour du service en production, mais le moyen le plus simple de confirmer qu'un point de sauvegarde se charge et génère correctement avant d'investir dans une pile plus rapide. Commencez ici pour déboguer.
Le choix de production habituel. L'attention paginée et le batching continu le rendent solide sous charge concurrente, et c'est généralement le chemin le plus rapide entre un point de sauvegarde téléchargé et un point de terminaison compatible OpenAI sur votre propre matériel.
Optimisé pour la génération structurée et la forte réutilisation de préfixes. Un bon choix quand de nombreuses requêtes partagent un long prompt système ou un préfixe de document commun, ce qui est exactement la forme de la plupart des charges agentiques.
Un chemin de service supplémentaire pris en charge et annoncé par les auteurs du modèle, utile lorsque ses caractéristiques de déploiement conviennent mieux à votre infrastructure que les alternatives.
Vise l'inférence hétérogène CPU et GPU, ce qui le rend intéressant pour du matériel contraint : il peut décharger des parties du modèle vers la mémoire système et garder utilisable un grand modèle sur une machine qui ne pourrait pas le contenir autrement.
L'erreur la plus fréquente en déploiement local est de budgéter la mémoire pour les poids en oubliant le KV-cache. Le nombre de paramètres fixe un plancher, mais le cache croît avec la longueur de contexte et la concurrence, et à long contexte il domine. C'est le même mur que les auteurs du modèle ont rencontré en servant le vaisseau amiral : au-delà de quelques centaines de milliers de tokens, le goulot d'étranglement cesse d'être le calcul pour devenir la capacité du cache, l'efficacité des kernels et la surcharge CPU.
La conséquence pratique est qu'il faut dimensionner pour votre distribution réelle de contextes, et non pour le maximum que le modèle supporte. Faire tourner GLM-5.2 avec une fenêtre de 128K est une proposition matérielle très différente de le faire tourner au million complet, et la plupart des charges de travail n'approchent jamais le plafond. Si votre matériel est juste, les paliers légers GLM-4.7-Flash et GLM-4.5-Air, ou GLM-5.1 à contexte 200K, tiendront là où le vaisseau amiral ne tiendra pas.
Adaptez le modèle à la machine. Sur un accélérateur de station de travail unique, GLM-4.7-Flash à 30B ou GLM-4.5-Air sont les options réalistes et sont parfaitement capables pour la classification, l'extraction, le résumé et les modifications de code de routine. Sur un nœud multi-GPU sérieux, GLM-5.1 vous offre une fenêtre de 200 000 tokens à un coût de cache bien inférieur à celui du vaisseau amiral. Sur un cluster, GLM-5.2 vous donne le contexte 1M complet, des niveaux d'effort explicites et la meilleure colonne de benchmarks publiée de la famille. Pour de la transcription plutôt que de la génération, GLM-ASR assure l'étape de reconnaissance sous la même licence.
Parcourir tous les modèles GLM →
Tous les chiffres de cette page sont des résultats tels que publiés par les auteurs du modèle. glmmodel.com les rapporte ; il n'exécute pas ces évaluations.
Consultez les benchmarks des modèles GLM, puis mettez un vrai modèle au travail. Le playground ci-dessus est gratuit et ne demande rien ; si vous cherchez une boîte à outils IA plus complète, l'offre gratuite de notre partenaire commence ici.