La fenêtre de contexte 1M de GLM est la caractéristique déterminante du modèle GLM phare actuel, et ce n'est pas une simple option de configuration. Faire passer un plafond utilisable de 200 000 à 1 000 000 de tokens a exigé des changements dans l'architecture d'attention, dans le décodage spéculatif et dans la pile de service — trois travaux d'ingénierie distincts qui ne produisent une fenêtre exploitable qu'une fois combinés.
Cette page explique chacun d'eux en langage clair, chiffres publiés à l'appui. En résumé : un indexeur partagé réduit le calcul par token de 2.9× à 1M de contexte, une couche de prédiction multi-tokens repensée augmente la longueur d'acceptation du décodage spéculatif d'environ 20 %, et un ensemble de changements mémoire et kernels empêche la capacité du KV-cache de devenir le mur. Tous les chiffres sont tels que publiés par les auteurs du modèle.
Le problème naïf du long contexte est le coût quadratique de l'attention, et l'attention sparse le résout en principe en faisant porter l'attention de chaque token sur un sous-ensemble sélectionné de tokens précédents plutôt que sur tous. Mais l'attention sparse a besoin d'un indexeur — un mécanisme léger qui décide quels tokens méritent l'attention — et exécuter cet indexeur dans chaque couche réintroduit un coût qui croît avec la longueur du contexte. À 200 000 tokens, cette surcharge est tolérable. À un million, elle ne l'est plus.
Le second problème est qu'au-delà de quelques centaines de milliers de tokens, le goulot d'étranglement cesse d'être le calcul. Il devient la capacité du KV-cache, l'efficacité des kernels long contexte et la surcharge côté CPU — un problème de mémoire et de systèmes plutôt que de mathématiques. Un modèle peut être architecturalement capable d'une fenêtre d'un million de tokens et rester inservable si le cache ne tient pas ou si l'ordonnanceur cale.
IndexShare est la réponse architecturale. Au lieu que chaque couche transformer calcule ses propres indices top-k, chaque groupe de quatre couches partage un indexeur léger unique. Il se trouve sur la première des quatre, et ses indices top-k sont réutilisés par les trois autres — ce qui supprime le produit scalaire de l'indexeur et la sélection top-k dans trois couches sur quatre.
Le résultat publié est une réduction de 2.9× des FLOPs par token à 1M de contexte, sans perte de qualité rapportée à longue portée. IndexShare a été utilisé dès le mid-training, à une longueur de séquence de 128K, plutôt que greffé au moment de l'inférence — et cela compte : un schéma de partage introduit uniquement au moment du service créerait un décalage entre la façon dont le modèle a été entraîné et celle dont il s'exécute.
La prédiction multi-tokens accélère la génération en rédigeant plusieurs tokens à l'avance puis en les vérifiant, et son efficacité se mesure à la longueur d'acceptation — combien de tokens rédigés survivent en moyenne à la vérification. Dans la génération précédente, la couche MTP souffrait d'un décalage entre le KV-cache utilisé à l'entraînement et celui utilisé à l'inférence, ce qui plafonnait la longueur d'acceptation à 4.56 sur 7 étapes MTP.
La conception actuelle exécute l'indexeur une seule fois lors du premier brouillon et réutilise les indices pour les étapes suivantes, en partageant à la fois les indices et l'état KV. L'ajout d'un échantillonnage par rejet au chemin de décodage spéculatif et d'une perte de variation totale de bout en bout porte la longueur d'acceptation à 5.47 — environ 20 % de tokens acceptés en plus par passe de vérification. L'ablation publiée figure ci-dessous.
| Référence | 4.56 |
| + IndexShare + KVShare | 5.10 |
| + Échantillonnage par rejet | 5.29 |
| + Perte TV de bout en bout | 5.47 (+20%) |
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.
Trois changements répondent au versant systèmes. La gestion mémoire fondée sur LayerSplit offre un contrôle plus fin sur la façon dont l'état du modèle est partitionné et parallélisé, si bien que l'allocation du cache cesse d'être du tout ou rien. Le travail sur les kernels adapté aux longs contextes est coordonné avec le pipeline de transfert de cache, de sorte que calcul et mouvement mémoire se recouvrent au lieu de se sérialiser. Enfin, la gestion du cache côté CPU, l'ordonnancement des requêtes et le réglage des chemins d'exécution éliminent une surcharge invisible en contexte court mais dominante en contexte long.
L'effet rapporté est que l'avantage en débit s'accroît à mesure que le contexte s'allonge — plus le prompt est long, plus l'écart avec un chemin de service naïf se creuse. C'est cette propriété qui transforme une fenêtre de contexte 1M d'une spécification en quelque chose que vous pouvez réellement faire tourner en charge.
Avantage de débit relatif à mesure que le contexte s'allonge, tel que décrit par les auteurs du modèle.
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.