L’attention clairsemée de GLM-5.3 réduit le calcul, mais la demande en HBM persiste

L’attention clairsemée de GLM-5.3 réduit la quantité de contexte lue par chaque opération d’attention, mais elle ne résout pas automatiquement le problème de capacité HBM du modèle. Une analyse du 28 septembre a montré que la sélection des tokens pertinents peut toujours nécessiter l’accès à l’historique complet du contexte. Ce constat remet en question une hypothèse séduisante : moins de tokens pris en compte par l’attention devrait forcément signifier proportionnellement moins de mémoire GPU.

Cette distinction est importante, car GLM-5.3 cible les tâches de programmation et d’agents de longue durée, où le contexte s’accumule au fil des appels d’outils, des fichiers, des résultats de tests et des révisions. L’attention clairsemée réduit le travail au sein du calcul d’attention principal. Le cache KV, qui stocke des représentations réutilisables des clés et valeurs issues des tokens précédents, peut continuer à croître avec la séquence complète.

DeepSeek Sparse Attention fournit le point de référence architectural. Son indexeur identifie un ensemble limité de tokens utiles avant que le modèle n’effectue son calcul d’attention principal. GLM-5.3 combine cette méthode avec des représentations de cache compressées, la réutilisation d’index entre couches et un logiciel de serving capable de déplacer les entrées de cache inactives vers la mémoire hôte.

L’enjeu central n’est donc pas seulement l’attention clairsemée contre l’attention dense. Il oppose la parcimonie algorithmique à l’exigence physique de conserver une longue conversation disponible. Cet enjeu détermine si les économies de mémoire se traduisent par une capacité HBM plus faible, une demande de bande passante réduite, une concurrence accrue, ou simplement un autre équilibre entre GPU et mémoire système.

Ce que change réellement l’attention clairsemée de GLM-5.3

GLM-5.3 réduit la quantité de travail d’attention coûteux par token, mais le modèle a toujours besoin d’un moyen de localiser les informations pertinentes dans son historique.

GLM-5.3 appartient à la famille GLM-5 de Z.ai, qui utilise une architecture de mélange d’experts. Un modèle de mélange d’experts n’active qu’une partie de son ensemble total de paramètres pour chaque token. Selon le rapport GLM-5, cette famille combine ce calcul routé à une conception d’attention à long contexte issue des travaux de DeepSeek.

Z.ai indique que GLM-5.3 utilise le même modèle de base que GLM-5.2. Les gains de capacités annoncés proviennent du post-entraînement, plutôt que d’un nouveau cycle de pré-entraînement du modèle de base. Cette distinction signifie que le débat actuel sur la mémoire porte sur le comportement de l’architecture existante sous des charges de serving réelles, et non sur une nouvelle couche d’attention inventée pour GLM-5.3.

Le mécanisme pertinent est DeepSeek Sparse Attention, ou DSA. L’attention clairsemée limite l’attention complète à un sous-ensemble sélectionné de tokens antérieurs, au lieu de traiter tous les tokens précédents avec le même coût. DeepSeek a introduit cette conception orientée production dans ses recherches V3.2.

DSA exécute d’abord un composant léger appelé lightning indexer. L’indexeur attribue un score aux positions précédentes et choisit les tokens top-k, c’est-à-dire l’ensemble limité jugé le plus pertinent pour la requête courante. Le calcul principal Multi-Head Latent Attention opère ensuite sur ces positions sélectionnées.

Multi-Head Latent Attention, ou MLA, stocke des représentations latentes compressées au lieu d’un vecteur complet distinct de clé et de valeur pour chaque tête d’attention. Cette compression réduit le cache stocké par token. La sélection clairsemée réduit ensuite la part de ce cache lue par l’opération d’attention principale.

Il s’agit de deux économies différentes. MLA cible la taille de l’état mis en cache de chaque token. DSA cible le nombre de positions mises en cache consommées par le calcul d’attention coûteux.

Cette combinaison modifie considérablement le profil de calcul et de bande passante. L’attention centrale peut passer du traitement des relations sur l’ensemble du contexte au traitement d’une sélection top-k fixe. À de grandes longueurs de séquence, cela limite la croissance de la charge de travail de l’attention principale.

Cependant, le lightning indexer a toujours besoin de suffisamment d’informations pour évaluer les candidats sur l’historique conservé. Le modèle ne peut pas sélectionner un ancien token si le système de serving a supprimé toute représentation exploitable de ce token.

L’analyse de SemiAnalysis identifie cela comme la limite cruciale. L’attention clairsemée réduit le trafic mémoire pendant l’opération centrale d’attention par produit scalaire mis à l’échelle. Elle ne réduit pas nécessairement la capacité mémoire totale requise pour préserver un contexte sélectionnable.

Cette limite devient plus claire sous le seuil de parcimonie. DSA utilise un réglage top-k de 2 048 positions dans la configuration examinée par SemiAnalysis. Une séquence contenant moins de positions ne dispose d’aucun vivier plus large à élaguer, l’attention reste donc dense.

Les moteurs de serving choisissent également différents modes d’exécution selon la longueur de séquence et la topologie de déploiement. Une implémentation peut privilégier un mode à calcul réduit pour les contextes courts, puis basculer vers un mode à mémoire réduite lorsque le trafic mémoire devient dominant. L’attention clairsemée n’offre donc pas une accélération fixe pour chaque requête.

Le changement significatif est plus circonscrit et plus utile. L’attention clairsemée de GLM-5.3 réduit le coût récurrent de consultation d’un long historique. Elle ne fait pas disparaître cet historique.

Pourquoi une baisse du trafic d’attention ne signifie pas une capacité HBM réduite

La pression sur la HBM provient du contexte conservé, tandis que l’attention clairsemée modifie principalement les entrées conservées que le GPU lit lors de chaque opération.

La mémoire à haute bande passante, ou HBM, est la mémoire rapide directement reliée à un accélérateur. Sa bande passante aide les GPU à alimenter de grandes opérations matricielles, tandis que sa capacité limitée restreint le nombre de modèles et de requêtes actives pouvant tenir sur chaque appareil.

Lors de la génération autorégressive, un modèle produit un token après l’autre. Il réutilise les clés et les valeurs calculées pour les tokens antérieurs via le cache KV. Sans ce cache, le serveur devrait recalculer à répétition toute la séquence précédente.

Chaque requête active réserve donc de la mémoire pour son contexte. Une longue session de programmation peut inclure des fichiers de dépôt, des sorties de commandes, des tentatives de correctifs, des journaux de tests et des raisonnements antérieurs. Un agent peut produire bien plus de tokens qu’un échange classique de questions-réponses.

L’attention clairsemée modifie le schéma de lecture. Au lieu de charger chaque position historique dans l’opération d’attention principale, le modèle charge l’ensemble top-k sélectionné. Cela peut réduire la consommation de bande passante mémoire et les calculs effectués après la sélection.

La capacité suit une règle différente. Si une position antérieure reste éligible à la sélection, sa représentation doit rester accessible quelque part. Une conception de serving conventionnelle conserve l’historique KV complet dans la HBM, même lorsque le noyau d’attention principal ne lit qu’un petit sous-ensemble.

Le système qui en résulte peut être limité par la capacité avant de l’être par le calcul. Chaque requête peut effectuer moins de travail d’attention, tout en occupant une mémoire proportionnelle à la longueur de son contexte. L’augmentation de la concurrence place alors davantage d’historiques complets sur le même appareil.

Cela explique pourquoi l’attention clairsemée ne se traduit pas directement par une réduction équivalente de la demande en HBM. Le système économise du trafic actif sans nécessairement réduire l’état résident. La vision logique que le modèle a de son historique reste complète, même lorsque chaque étape d’attention est sélective.

La différence ressemble à une grande archive dotée d’un système de recherche rapide. Une récupération plus rapide réduit le nombre de documents lus pour chaque question. Elle ne réduit pas l’archive, à moins que les documents anciens ne soient déplacés ailleurs ou supprimés.

La compression du cache KV de GLM-5.3 reste néanmoins importante. Des représentations plus petites par token permettent de faire tenir davantage de contexte dans un budget mémoire donné. Elles réduisent également les octets transférés lorsque des entrées sélectionnées sont intégrées à une opération d’attention.

Toutefois, l’état compressé continue de s’accumuler avec la longueur de séquence. Une courbe de mémoire linéaire plus faible reste une courbe de mémoire linéaire. Les longs contextes et de nombreuses requêtes simultanées peuvent finir par consommer la capacité économisée.

La concurrence révèle rapidement ce compromis. SemiAnalysis a rapporté des résultats où le passage de huit à seize requêtes concurrentes réduisait la réutilisation des tokens de prompt depuis la mémoire GPU. La part de réutilisation du GPU est passée de 90,3 % à 54,8 %.

La réutilisation depuis la mémoire hôte est passée de 6,0 % à 40,3 % dans la même comparaison. Le taux de succès combiné du cache est resté supérieur à 95 % à tous les niveaux de concurrence rapportés. Ces résultats montrent que la capacité de cache utile peut s’étendre au-delà de l’accélérateur.

Ils ne signifient pas que la mémoire hôte égale la latence de la HBM. Le déplacement des données via la connexion CPU-GPU génère un coût d’E/S, et les défauts de cache peuvent interrompre un chemin de décodage autrement efficace. Le système de serving doit prédire, récupérer et évincer les données sans laisser les transferts dominer le temps de génération.

L’implication pour le marché de la mémoire est également plus nuancée qu’une simple baisse de la demande. L’attention clairsemée peut réduire le trafic HBM par étape d’attention. Dans le même temps, une inférence à long contexte moins coûteuse peut encourager des sessions plus longues et une plus grande concurrence des requêtes.

Cet effet rebond importe pour la planification de l’infrastructure. Lorsqu’une requête devient moins coûteuse à traiter, les opérateurs admettent souvent davantage de travail simultané. La bande passante mémoire économisée peut devenir un débit supplémentaire plutôt que du matériel inutilisé.

La demande en HBM peut donc persister alors même que l’attention devient plus sélective. La demande en DRAM hôte peut aussi augmenter, car les historiques complets sont déplacés vers un niveau de mémoire plus grand et plus lent. À une échelle encore plus grande, les systèmes de stockage peuvent absorber des préfixes réutilisables ou des données de cache inactives.

La question pratique n’est plus de savoir si l’attention clairsemée économise de la mémoire dans l’abstrait. Elle est de déterminer quel niveau de mémoire héberge chaque partie du cache KV de GLM-5.3, et à quelle fréquence le moteur de serving la déplace.

HiSparse déplace l’historique complet hors du GPU

HiSparse transforme les lectures sélectives de l’attention clairsemée en économies réelles de capacité HBM en séparant la disponibilité logique du cache de sa résidence physique sur le GPU.

L’équipe SGLang a conçu HiSparse comme un cache KV hiérarchique pour le serving d’attention clairsemée. Il conserve un petit ensemble de travail sur le GPU tout en stockant l’historique KV complet dans la mémoire hôte épinglée. La mémoire épinglée est une mémoire CPU préparée pour des transferts prévisibles vers un accélérateur.

Dans cette conception, les anciennes entrées du cache restent logiquement disponibles pour GLM-5.3. Elles ne restent pas toutes physiquement résidentes dans la HBM. L’indexeur peut sélectionner une position, et le système de serving peut récupérer cette position lorsque le GPU ne la contient pas.

HiSparse utilise une politique de moindre utilisation récente pour son cache d’appareil. Lorsque les tokens sélectionnés sont absents de la HBM, le système les charge depuis la mémoire hôte. Il évince les entrées les moins récemment utilisées afin de maintenir un ensemble de travail GPU borné.

Cette architecture transforme une propriété au niveau du modèle en une économie au niveau du système. L’attention clairsemée identifie le petit ensemble requis par l’opération courante. HiSparse garantit que seule une sélection limitée et un tampon de travail doivent occuper la HBM durant le décodage.

L’article HiSparse décrit le système comme exact et indépendant de l’indexeur. Exact signifie que le placement du cache change sans approximer intentionnellement la sortie d’attention sélectionnée par le modèle. Indépendant de l’indexeur signifie que le gestionnaire de mémoire ne dépend pas d’un seul algorithme de sélection.

Ses évaluations couvrent DSA, Native Sparse Attention et Quest sur les plateformes H200, B200 et GH200. Les auteurs rapportent un débit maximal de génération jusqu’à 4,7 fois supérieur sur des charges de travail à long contexte.

Il s’agit d’un résultat au niveau du système dans des configurations testées, et non d’un multiplicateur de vitesse garanti pour GLM-5.3. La longueur des charges de travail, la concurrence des requêtes, la bande passante d’interconnexion, la localité de sélection et les taux de défauts de cache influencent tous le résultat.

HiSparse chevauche également les transferts avec le calcul utile. Pendant qu’une couche s’exécute, le système peut préparer des entrées de cache sélectionnées pour une couche ultérieure. Ce chevauchement entre les couches masque une partie de la latence créée par les mouvements de l’hôte vers le périphérique.

La réutilisation entre les couches facilite cette planification. Si des couches adjacentes sélectionnent un grand nombre des mêmes positions, le système connaît à l’avance la demande probable sur le cache. Les entrées récupérées pour une couche peuvent rester utiles pour les couches suivantes.

Le coût restant est l’E/S. Un échec de sélection exige que les données transitent de la mémoire CPU vers la HBM. Des échecs fréquents, des sélections dispersées ou une bande passante hôte-périphérique limitée peuvent effacer une partie du gain de débit.

Ce risque distingue la sparsité théorique de l’efficacité en production. Un noyau sparse peut lire moins d’entrées une fois qu’elles sont arrivées. Le système complet doit toujours trouver ces entrées, les transférer, les mapper dans des pages utilisables et coordonner leur durée de vie.

Le délai avant le premier token impose une autre contrainte. Le prefill, qui traite le prompt initial, présente des caractéristiques différentes du décodage token par token. HiSparse cible principalement la phase de décodage, où le cache existe déjà et croît à mesure que la génération se poursuit.

L’implémentation de SGLang associe HiSparse à une désagrégation prefill-decode. Cette architecture attribue le traitement des prompts et la génération de tokens à des workers différents. Chaque phase peut alors utiliser une disposition mémoire et une allocation matérielle adaptées à sa charge de travail.

Cette conception modifie aussi les besoins d’infrastructure. La HBM devient un cache chaud plutôt que le seul stockage de la conversation active. La DRAM hôte conserve l’historique plus volumineux, tandis que l’interconnexion devient une partie du chemin critique.

Cela peut réduire la capacité HBM nécessaire pour chaque requête de décodage. Cela n’élimine pas les octets qui représentent la conversation. Cela en relocalise une grande partie et ajoute un logiciel chargé de maintenir le bon sous-ensemble à proximité du GPU.

Pour les opérateurs, la métrique pertinente n’est donc pas seulement la taille du modèle ou la longueur maximale de contexte. Ils doivent mesurer l’empreinte HBM par requête, l’allocation de mémoire hôte, le taux d’échec, le volume de transferts et la latence des tokens de sortie à une concurrence réaliste.

L’attention sparse rend cette conception à plusieurs niveaux possible. HiSparse la rend opérationnelle. Aucun des deux ne rend la gestion de la mémoire gratuite.

IndexShare réduit le coût de la recherche des tokens pertinents

Une fois l’attention complète devenue sparse, l’indexeur lui-même devient un goulot d’étranglement visible. La prochaine optimisation de GLM réutilise donc les décisions de sélection entre les couches.

Une couche DSA standard possède son propre indexeur lightning. Ce composant évalue les tokens historiques avant que le calcul principal d’attention ne sélectionne son ensemble top-k. L’indexeur est plus léger que l’attention complète, mais il examine tout de même le contexte.

À mesure que le contexte s’allonge, évaluer à répétition chaque position historique dans chaque couche devient coûteux. Le chemin principal de l’attention a été allégé, de sorte qu’un travail auparavant mineur représente une part plus importante de la latence totale.

Z.ai traite ce problème avec IndexShare, également décrit publiquement sous le nom d’IndexCache. Au lieu d’exécuter un indexeur indépendant dans chaque couche d’attention sparse, des groupes de couches réutilisent une sélection partagée.

L’approche repose sur une tendance observée : les couches voisines choisissent souvent un grand nombre des mêmes tokens historiques. L’étude IndexCache rapporte, dans son analyse, un chevauchement de 70 à 100 % entre les sélections top-k de couches adjacentes.

Ce chevauchement crée de la redondance. Une couche complète désignée peut calculer un index, tandis que les couches partagées qui suivent réutilisent les positions sélectionnées. Le schéma de production évoqué pour GLM attribue un indexeur à des groupes de quatre couches DSA.

Sur un modèle DSA de 30 milliards de paramètres, les chercheurs ont supprimé jusqu’à 75 % des calculs d’indexeur avec une dégradation de qualité rapportée comme négligeable. Ils ont mesuré un prefill jusqu’à 1,82 fois plus rapide et un décodage jusqu’à 1,48 fois plus rapide que le DSA standard.

L’article présente également des résultats préliminaires de GLM-5 à l’échelle de la production. Ces résultats étayent le mécanisme, mais ne remplacent pas des tests indépendants étendus couvrant les charges de travail et les stacks de serving de GLM-5.3.

La réutilisation des sélections introduit sa propre exigence d’entraînement. Un indexeur partagé doit identifier des tokens utiles à plusieurs couches, et non simplement reproduire la distribution d’attention d’une seule couche. IndexCache entraîne les indexeurs conservés sur une moyenne des distributions d’attention qu’ils prennent en charge.

Cet ajustement importe, car les couches consécutives sont liées sans être identiques. Une couche précoce peut privilégier les détails lexicaux, tandis qu’une couche ultérieure peut favoriser une dépendance formée durant le traitement intermédiaire. La réutilisation devient nuisible si elle élimine un token requis par un seul membre du groupe.

La méthode révèle donc un second compromis. Davantage de partage supprime plus de travail d’indexation. Moins de partage préserve davantage de comportements de sélection spécifiques aux couches.

IndexShare interagit également avec HiSparse. Lorsque des couches partagent un index, le moteur de serving peut réutiliser les entrées de cache récupérées entre ces couches. Les sélections partagées réduisent les calculs top-k répétés et peuvent rendre les récupérations de l’hôte vers le périphérique plus prévisibles.

Cette combinaison s’attaque à quatre coûts distincts :

• MLA compresse la représentation stockée pour chaque token.

• DSA limite l’attention complète aux positions historiques sélectionnées.

• IndexShare évite de recalculer des sélections similaires dans chaque couche.

• HiSparse déplace les entrées KV inactives de la HBM vers la mémoire hôte.

Ces composants ne doivent pas être réduits à une seule affirmation sur la mémoire. La compression affecte les octets par token. L’attention sparse affecte les lectures actives. Le partage d’index affecte la surcharge de sélection. Le déchargement affecte l’emplacement physique.

Chaque niveau d’optimisation peut déplacer le goulot d’étranglement ailleurs. Des caches plus petits peuvent révéler une surcharge de calcul. Une attention principale moins coûteuse peut révéler la latence de l’indexeur. Le déchargement peut révéler la bande passante de transfert. Une concurrence plus élevée peut révéler la capacité de mémoire hôte.

Les caractéristiques matérielles déterminent quel goulot d’étranglement apparaît en premier. SemiAnalysis a estimé un profil d’intensité arithmétique suggérant que la configuration d’attention de GLM diffère de l’équilibre de DeepSeek orienté H800. L’analyse a également relié la conception de GLM au soutien du fournisseur chinois d’accélérateurs Moore Threads.

Cette interprétation matérielle reste une inférence, et non un objectif de conception divulgué par Z.ai. GLM-5.3 prend en charge plusieurs frameworks de serving et plateformes d’accélérateurs. Les opérateurs devraient donc mesurer le modèle sur leur propre chemin de déploiement.

La leçon plus large est que l’attention sparse de GLM-5.3 ne peut pas être évaluée à travers un seul décompte de FLOP. Les performances de serving découlent du comportement conjoint de son indexeur, de son cache compressé, de sa hiérarchie mémoire, de ses noyaux et de sa charge de travail.

Le véritable test est l’efficacité mémoire en production

GLM-5.3 ne validera sa conception mémoire que si les opérateurs peuvent maintenir de longues sessions d’agents sans déplacer des coûts inacceptables vers la latence, la DRAM ou la complexité opérationnelle.

Le premier signal à surveiller est le benchmarking indépendant de GLM-5.3 dans des contextes longs et à forte concurrence. La vitesse de pointe d’une requête unique révèle peu de choses sur un service gérant de nombreux agents persistants. Les tests devraient rapporter conjointement l’utilisation de HBM, l’utilisation de DRAM hôte, les échecs de cache et les distributions de latence.

Un résultat convaincant montrerait que le déchargement du cache KV de GLM-5.3 permet davantage de requêtes simultanées tout en maintenant stable la latence par token. Si le débit n’augmente qu’au prix de fortes pointes de latence, l’économie de mémoire a une valeur limitée pour les agents de programmation interactifs.

Le deuxième signal est une prise en charge plus large du déploiement pour HiSparse et des gestionnaires de mémoire similaires. SGLang a intégré HiSparse, et vLLM a également documenté des travaux autour de cette architecture. Un comportement cohérent entre les moteurs renforcerait l’idée que les modèles sparse peuvent utiliser une résidence HBM limitée en production.

Une prise en charge fragmentée des noyaux affaiblirait cette conclusion. L’attention sparse dépend de mécanismes spécialisés de sélection, de gestion des pages, de formats de cache et de noyaux d’attention. Un modèle peut avoir des poids ouverts tout en restant difficile à servir efficacement en dehors d’une stack logicielle étroite.

Le troisième signal est la présence de preuves sur la qualité des agents sur de longues durées. L’optimisation mémoire n’importe que si le modèle récupère de manière fiable les exigences antérieures, les décisions de code et les résultats d’outils. Les erreurs de sélection qui apparaissent tard dans une session peuvent être difficiles à diagnostiquer.

La stratégie de post-entraînement de GLM-5.3 rend ce point particulièrement pertinent. Z.ai affirme que le modèle a amélioré ses capacités de programmation de 50 % par rapport à GLM-5.2 sur son benchmark interne Z.ai Code Bench. Cela reste une comparaison communiquée par l’entreprise.

Z.ai rapporte également un résultat de 84,5 % sur CyberGym, contre 77,2 % pour GLM-5.2. CyberGym mesure la capacité d’un modèle à trouver et valider des vulnérabilités logicielles à partir du code source. La publication de GLM-5.3 présente ces progrès comme la preuve de capacités agentiques et de cybersécurité renforcées.

Ces capacités accroissent à la fois l’utilité et le risque. Des sessions plus longues, guidées par des outils, peuvent faciliter l’analyse de dépôts, les tests et la recherche de vulnérabilités. Cette même persistance peut aider à automatiser des étapes d’exploitation ou à conserver du matériel sensible dans un cache de serving.

Le placement de la mémoire a donc une dimension de sécurité. La DRAM hôte, les caches de préfixes partagés et les couches de cache distribuées multiplient les emplacements où l’état d’une conversation peut résider. Les opérateurs ont besoin d’isolation, d’éviction, de contrôle d’accès et d’observabilité à tous les niveaux.

Les travaux du modèle sur Single-Rollout Asynchronous Optimization s’inscrivent dans ce contexte, même s’ils ne réduisent pas directement la mémoire d’inférence. SAO s’entraîne sur un rollout par prompt et utilise un modèle de valeur distinct pour estimer les rendements au niveau des tokens.

L’article SAO indique que cette méthode traite l’instabilité et les effets hors politique dans l’entraînement asynchrone des agents. Elle a été déployée dans le pipeline d’entraînement agentique de GLM-5.2 et éclaire la lignée de post-entraînement à l’origine de GLM-5.3.

SAO peut améliorer l’efficacité de l’entraînement pour des trajectoires d’agents longues et irrégulières. Elle entraîne aussi une surcharge d’entraînement supplémentaire, car le modèle de valeur fonctionne aux côtés du modèle de politique. C’est un autre exemple de réduction d’un goulot d’étranglement en acceptant un coût ailleurs.

Pour les équipes d’entreprise, la tâche immédiate est une évaluation rigoureuse. Suivez le prompt complet, le contexte sélectionné, le placement du cache, le comportement des échecs, la latence de sortie et la réussite des tâches dans la même charge de travail. Les chiffres agrégés de tokens par seconde masquent trop de choses.

Les équipes ont également besoin de registres durables des configurations de modèles et des expériences de serving. Une base de connaissances consultable peut relier les résultats de benchmarks aux versions des noyaux, aux paramètres de cache et aux incidents de déploiement.

L’attention sparse de GLM-5.3 modifie l’économie de lecture des contextes longs. Elle n’abolit pas l’obligation de les conserver. L’architecture réduit le trafic d’attention actif, tandis qu’IndexShare diminue la surcharge de sélection et HiSparse limite la résidence sur GPU.

La question pour la prochaine vague de benchmarks est concrète : GLM-5.3 peut-il transformer ces économies en concurrence soutenue sans déplacer le goulot d’étranglement vers les transferts hôtes ou la qualité de récupération ? Surveillez l’occupation HBM mesurée, la latence des échecs de cache et la précision des agents sur de longues durées. Ensemble, ces signaux montreront si l’attention sparse apporte un meilleur système de serving plutôt qu’un meilleur noyau pris isolément.