Olivier Le Moal - stock.adobe.co

GLM 5.2 : le Chinois zAI remet les grands modèles open weight sur le devant de la scène

Avec GLM 5.2, le fournisseur chinois publie un modèle open weight capable de rivaliser avec les LLM propriétaires américains majoritaires, sur le cloud, sur site et presque en local.

Zhipu AI, plus connu sous le nom de zAI, continue de se faire remarquer. Le 16 juin dernier, la startup chinoise a présenté GLM 5.2.

Selon Artificial Analysis, le grand modèle de langage fait 11 points de pourcentage de mieux que GLM 5.1 lorsqu’il est confronté à son banc d’essais Intelligence Index. Avec un score de 51 points sur 100, c’est le modèle open weight (licence MIT) le mieux noté. Il surpasse MiniMax M3 (44 points), DeepSeek V4 Pro (44 points) et Kimi K2.6 (43 points). Mieux, il surpasse de peu le très efficace Gemini 3.5 Flash (50 pts), tout en se positionnant juste derrière GPT-5.5 (55 pts) et Claude Opus 4.8 (56 points). Pour rappel, avant d’être retiré, Fable 5 – fusionné avec Opus 4.8 – obtenait un score de 60 sur 100.  

Une fenêtre de contexte d’un million de tokens « pour de vrai »

GLM 5.2 s’appuie sur la même base que son prédécesseur – une architecture mixture of Experts rassemblant 744 milliards de paramètres, dont 40 milliards sont actifs. Les gains sont à chercher de modifications architecturales notables.

Désormais, l’acteur asiatique affiche une fenêtre de contexte de 1 million de tokens – contre 200 000 pour GLM-5.1. Et zAI d’insister sur la robustesse de cette dernière. « Il est facile de prétendre disposer d’un contexte de 1 million de tokens. Il est bien plus difficile d’en garantir la fiabilité face aux contraintes réelles de l’ingénierie », déclarent les ingénieurs de zAI dans un billet de blog « À cette fin, nous avons considérablement étendu l’entraînement sur des contextes de 1 million de tokens pour les scénarios impliquant des agents de programmation, en couvrant la mise en œuvre à grande échelle, la recherche automatisée, l’optimisation des performances et le débuggage complexe ».

Par ailleurs, la société applique une technique qu’elle nomme IndexShare, tiré du projet de recherche IndexCache. Ici, il s’agit de réduire le coût de calcul que représente le mécanisme DeepSeek Sparse Attention (DSA), utilisé au sein de l’architecture de GLM 5.2.

Introduit avec le LLM DeepSeek V3.2 en décembre 2025, DSA est un mécanisme d’attention éparse visant lui-même à optimiser le coût de calcul de la fenêtre de contexte. Pour ce faire, il introduit un module d’indexation léger qui sélectionne les tokens les plus pertinents à travers les couches de réseau de neurones avant l’étape d’attention. Si cette mesure top K permet de réduire le temps de calcul, l’indexeur doit encore analyser tous les tokens dans chaque couche du réseau de neurones. Problème, le coût de calcul quadruple si le volume de tokens en entrée est doublé.

Or, la startup a remarqué que les tokens les plus pertinents sont largement similaires dans les couches neuronales adjacentes. D’où le projet IndexCache qui distingue des couches complètes et des couches partagées. En clair, seules certaines strates importantes ont leur propre indexeur, tandis que les autres réutilisent la sélection de tokens faite par la couche complète la plus proche. Résultat, la société réduirait les coûts d’indexation de 75 %.

Avec GLM 5.2, « l’indexeur est placé au début des quatre couches et [les tokens les plus pertinents] qui s’y trouvent sont partagés. Cela permet de réduire le calcul du produit scalaire de l’indexeur et l’opération “topk” dans trois des quatre couches », illustre zAI. « Le modèle GLM-5.2 a été entraîné avec IndexShare à mi-parcours, avec une longueur de séquence de 128 000 tokens ». GLM 5.2 dépasserait ainsi son prédécesseur « tout en nécessitant moins de puissance de calcul ».  

zAI a également appliqué cette technique de réutilisation des calculs entre les « têtes » neuronales utilisées pour la prédiction multitoken (MTP). Cet élément d’architecture, également mis en lumière par Meta et DeepSeek, permet de prédire plusieurs tokens simultanément et donc d’accélérer les réponses.

Ici, la startup a également corrigé des erreurs au niveau du KV Cache. Un token pouvait « faire attention » à lui-même dans la couche de cache contenant les paires clés-valeurs, ce qui pouvait créer des incohérences entre l’entraînement et l’inférence. Désormais, dans une séquence de cinq tokens, le cinquième ne peut consulter que les quatre précédents en provenance du même modèle principal. Avec cette modification, la couche MTP accepterait jusqu’à 20 % de tokens supplémentaires par prédiction.

Une meilleure utilisation des puces et de leur mémoire

Cette réutilisation du KV Cache était jusqu’alors appliquée uniquement lors de l’inférence. Malgré tout, si l’approche minimise le coût en FLOPS par token, elle ne réduit pas de manière proportionnelle l’espace occupé par un token dans le KV Cache, signale zAI.

En clair, comme l’expliquait Google avec DiffusionGemma, les LLM souffrent moins du manque de puissance de calcul que de la mémoire disponible. zAI dit ainsi avoir mis en place une stratégie pour gérer plus finement la mémoire avec la technique LayerSplit. Celle-ci permet de diviser les couches d’un modèle en segments répartis sur plusieurs GPU.

Elle a exploité la parallélisation pour augmenter la capacité de cache disponible lors des requêtes les plus longues à traiter. La startup s’est également penchée sur l’optimisation des kernels en lien avec la longueur du contexte. Sans oublier la coordination entre GPU et CPU. Là, il s’agit de réduire les temps morts dans le pipeline d’exécution.

Par ailleurs, zAI a revu son pipeline pour paralléliser les tâches d’entraînements à l’aide d’agents IA. Il s’agit d’accomplir des tâches « plus complexes » d’apprentissage par renforcement et de distillation des connaissances. Cela aurait permis de fusionner plus de dix modèles experts au sein du LLM.

La startup a également fourni un effort pour compresser les traces de raisonnement lors de l’entraînement, détecter et bloquer les tentatives de « reward hacking » tout en évitant l’instabilité du modèle après ce filtrage. L’objectif est de forcer le modèle à résoudre véritablement les problèmes au lieu de chercher des raccourcis, comme copier directement la réponse.

GLM 5.2 : zAI a le droit à son moment DeepSeek

Si les efforts paient en sciences, en mathématiques et dans l’exécution de tâches bureautiques, la consommation de tokens est hausse. Selon Artificial Analysis, en moyenne GLM-5.2 a généré 43 000 tokens (en incluant les réponses et le raisonnement) pour répondre à chaque tâche du test du cabinet, contre 26 000 pour GLM 5.1. En proportion, GLM-5.2 utilise beaucoup plus de tokens de raisonnement. D’ailleurs, si l’on compare uniquement les tokens de sortie, GLM-5.2 ne consomme « que » 20 millions de tokens en plus par rapport à GLM-5.1 (140 millions vs 120 millions de tokens).

Toutefois, les tarifs de zAI s’avèrent bien plus abordables que ceux pratiqués par ses homologues américains. Facturé 1,4 dollar pour 1 million de tokens en entrée et 4,4 dollars pour le même volume en sortie, il bénéficierait d’un rapport performance-prix équivalent à ses compétiteurs open weight.

Et les premiers benchmarks ne semblent pas totalement truqués. « Sur toute une série de tâches différentes, c’était le premier modèle open weight qui ne semblait pas nettement moins performant que les meilleurs modèles propriétaires », déclare Itamar Golan, cofondateur et CEO de Prompt Security, un ancien de Sentinel One et d’Orac Security. « Il n’est pas parfait. Il n’a pas encore fait l’objet de tests comparatifs exhaustifs. Mais ses capacités sont étonnantes ».

D’autres usagers de LinkedIn partagent cet avis et en concluent que le GLM 5.2 peut répondre à la majorité des tâches. En parallèle, un modèle comme Opus 4.8 peut être utilisé pour résoudre les problèmes les plus complexes ou les plus longs à résoudre, estiment-ils.

« GLM 5.2 est […] le meilleur modèle open weight à ce jour », lâche Wade Foster, cofondateur et CEO de Zapier. « Nous l’avons fait tourner sur AutomationBench de Zapier : il égalise Opus 4,7 max, qui affichait le meilleur score lors du lancement en avril. Mais GLM 5.2 coûte 0,67 dollar par tâche contre 1,80 dollar pour Opus 4.7 max. Moins de la moitié du prix », souligne-t-il. Opus 4.7 et 4.8 coûtent 5 dollars pour un million de tokens en entrée, et 25 dollars pour le même volume en sortie.

Outre la disponibilité sur les infrastructures chinoises, GLM 5.2 est accessible chez les acteurs spécialisés comme Together AI, Baseten, Nebius, FireWorks, DeepInfra ou encore sur AWS via la marketplace.

Cerise sur le gâteau, comme c’est un modèle open weight, il est possible de l’héberger localement. À condition d’accepter les compromis.  

Un modèle « frontière » accessible sur site (voire en local pour les mieux équipés)

En FP8, le modèle pèse 893 Go (1,5 To en FP16) et requiert à minima huit GPU Nvidia H100 (80 Go de VRAM par carte), idéalement 8 H200 avec le framework d’inférence vLLM. Selon zAI, le contexte de 1 million de tokens est disponible avec 8 GPU Nvidia B200 (192 Go de VRAM par carte). « Oui, bien l’inférer coûte cher. 8 H200 revient à 400 000 dollars à l’achat ou à 20 000 dollars par mois à la location », note Itamar Golan. « Mais de nombreuses entreprises dépensent des millions par mois dans les API d’Anthropic et d’OpenAI », soupèse-t-il.

Toutefois, Unsloth propose une compression GGUF en 2 bits (245 Go). Là, le modèle tient sur 256 Go de mémoire unifiée d’un Mac doté d’une puce Apple Silicon M ou sur un GPU doté de 24 Go de VRAM et 256 Go de mémoire vive. Cela réclame une grosse station de travail. Ici, le checkpoint retient 82 % des connaissances de GLM-5.2, tout en étant 84 % plus petit. Unsloth ne précise pas la vitesse du LLM dans ces deux configurations.

Des compressions au format 1, 3, 4 et 5 bits sont également disponibles. Les versions 4 (475 Go) et 5 bits (570 Go) ne présentent pas d’écart notable avec l’étalon FP8.

Pour approfondir sur Data Sciences, Machine Learning, Deep Learning, LLM