Alors que le modèle ouvert GLM-5.2 de Z.ai suscite l'intérêt pour ses performances en codage et en agents, une expérience technique récente vient de démontrer le potentiel d'inférence de cette architecture. Un développeur a réussi à exécuter GLM-5.2 sur le runtime TileRT, conçu à l'origine par Xiaomi MiMo, et a obtenu des vitesses de traitement environ cinq fois supérieures à celles du runtime standard vLLM sur une configuration matérielle identique.

L'expérience, menée sur un nœud loué équipé de huit GPU NVIDIA B200, a abouti à un débit d'environ 480 tokens par seconde. En comparaison, le même modèle exécuté via vLLM sur les mêmes cartes graphiques n'atteignait qu'environ 96 tokens par seconde. Le service OpenRouter, qui propose le modèle en ligne, plafonnait à environ 104 tokens par seconde. Ces mesures, issues de trois séries de tests par configuration, ont utilisé les mêmes poids du modèle en format FP8.

Des obstacles techniques multiples

Pour parvenir à ce résultat, le développeur a dû surmonter plusieurs difficultés. La première tenait à l'incompatibilité entre le runtime TileRT, dont la version 0.1.4 est conçue pour l'environnement CUDA 13, et les pilotes présents sur le nœud loué, qui utilisaient CUDA 12.8. Une mise à jour complète du pilote a été nécessaire, incluant la mise à niveau du gestionnaire de communication inter-GPU (fabric manager) pour maintenir la connectivité NVLink entre les huit cartes.

Le second obstacle était plus fondamental : TileRT ne supporte que le modèle GLM-5.1, alors que GLM-5.2 intègre une innovation nommée « IndexShare ». Cette technique d'attention parcimonieuse (sparse attention) permet à un quart seulement des couches du réseau de calculer l'index de sélection des tokens, les trois quarts restants réutilisant cet index. Cela réduit d'environ 2,9 fois la charge de calcul attentionnel sur les longs contextes. Mais le chargeur de TileRT s'attend à trouver un indexeur dans chaque couche, ce qui n'est plus le cas dans GLM-5.2.

Un contournement ingénieux mais limité

Pour tromper le runtime, le développeur a synthétisé les indexeurs manquants en copiant ceux des couches « pleines » vers les couches « partagées », en ajustant 399 petits tenseurs. Les 700 gigaoctets de poids réels du modèle sont restés inchangés. La qualité des réponses a été vérifiée sur plusieurs questions de connaissances générales et s'est avérée identique à celle du modèle exécuté via OpenRouter.

Cependant, cette astuce comporte une limitation majeure : elle n'est exacte que tant que la longueur totale du contexte reste inférieure à 2048 tokens. Au-delà, les indexeurs synthétisés, qui calculent leur propre sélection au lieu de réutiliser celle de la couche pleine, se trompent de tokens et le modèle génère du contenu incohérent. Le noyau d'inférence fermé de TileRT, qui exécute l'ensemble des 78 couches en un seul appel, ne permet pas d'intervenir pour corriger ce mécanisme. La limite des 2048 tokens est donc infranchissable sans une mise à jour officielle du runtime.

Des performances prometteuses pour des cas précis

Malgré cette contrainte, les tests montrent que pour des tâches de génération de code – Python, JavaScript ou algorithmes – le modèle atteint des vitesses de traitement très élevées, comprises entre 479 et 492 tokens par seconde sur les huit GPU B200. Une seule requête SQL a échoué avec une erreur CUDA. Le plafond de 2048 tokens reste suffisant pour un grand nombre de tours de conversation techniques, mais le rend inutilisable pour l'analyse de longs documents.

Ces résultats soulignent le potentiel du runtime TileRT pour l'inférence de grands modèles de langage, tout en rappelant les défis que posent les innovations logicielles comme IndexShare face à des environnements d'exécution fermés. Ils ouvrent également la voie à des optimisations futures, dès lors que Z.ai ou Xiaomi MiMo proposeront une compatibilité native entre GLM-5.2 et TileRT.