Une lenteur rédhibitoire en local

L'exécution du modèle GLM-5.2 directement sur un Mac doté de 64 Go de mémoire vive ne permet d'atteindre qu'un débit d'environ deux tokens par seconde, selon les premiers retours d'utilisateurs et d'observateurs du secteur. Ce résultat, bien en deçà des attentes pour un modèle open-weight réputé, transforme l'inférence locale en une expérience quasiment inexploitable pour des travaux de codage ou d'agent nécessitant des échanges en temps réel.

Ce goulet d'étranglement contraste vivement avec les promesses de GLM-5.2, qui se positionne comme le nouveau modèle ouvert de référence sur l'indice d'intelligence établi par Artificial Analysis. Sur cet indice, GLM-5.2 affiche un score de 51, contre 56 pour Claude Opus 4.8, tout en se situant dans une fourchette de coût par tâche nettement inférieure.

Des optimisations logicielles pour compenser

Face à cette limitation matérielle, des outils comme l'IDE open-source Stagewise ont été conçus pour tirer le meilleur parti de GLM-5.2, notamment dans un contexte de développement d'agents logiciels. Stagewise, qui fonctionne sur la machine de l'utilisateur, propose plusieurs mécanismes pour atténuer l'impact de la lenteur d'inférence.

L'IDE conserve une partie stable des premiers échanges de la conversation d'un tour à l'autre, ce qui améliore le taux de succès du cache et réduit à la fois la latence et le coût. En cas de modification de l'environnement de travail — renommage de fichier, ouverture d'un onglet, déplacement d'une sélection — le système transmet un « delta d'état » compact au modèle, évitant ainsi de renvoyer l'intégralité du contexte.

De plus, le moteur d'exécution comprime automatiquement le contexte au fur et à mesure que la tâche s'allonge : les échanges les plus anciens sont résumés et élagués, de sorte que le modèle conserve un ensemble de travail ciblé. Ces optimisations rendent possibles des tâches de longue durée — implémentations multi-fichiers, refontes s'étalant sur plusieurs heures, sessions de débogage complexes — qui seraient autrement irréalistes avec une cadence de deux tokens par seconde.

Une flexibilité de déploiement

Stagewise permet d'utiliser GLM-5.2 via plusieurs voies : un compte hébergé par Stagewise lui-même, un point de terminaison tiers, ou l'inférence locale. Les utilisateurs disposant déjà d'un accès à GLM peuvent pointer l'IDE vers leur configuration existante, qu'il s'agisse d'abonnements API, de fournisseurs tiers ou d'inférence locale.

L'absence de vision native, un handicap contourné

Un autre inconvénient majeur de GLM-5.2 est son absence de capacités visuelles natives : il ne peut pas inspecter directement le contenu d'images. Dans un codebase réel, cela constitue une limitation significative, car les captures d'écran, les ressources exportées et les fichiers de conception font partie de l'espace de travail.

Stagewise pallie partiellement cette lacune via un pipeline de transformation de fichiers qui convertit chaque image en un contexte structuré exploitable par le modèle sous forme textuelle : type de fichier, dimensions, format et une représentation compacte de l'image. Ainsi, même si GLM ne dispose pas d'une véritable vision, il peut traiter des fichiers d'image dans le même flux de travail que les fichiers source et de configuration.

Un écosystème encore en construction

Si GLM-5.2 excelle dans les benchmarks en cloud, son exécution locale révèle des défis matériels et logiciels non négligeables. Les solutions d'optimisation comme Stagewise montrent que l'industrie cherche à adapter l'infrastructure aux capacités du modèle plutôt que l'inverse. Mais pour l'instant, un Mac équipé de 64 Go de RAM ne suffit pas à libérer tout le potentiel de ce modèle, et la vitesse d'inférence reste un frein majeur à son adoption en local.