A janela de contexto de 1M do GLM é a característica definidora do atual modelo GLM emblemático, e não é uma opção de configuração. Elevar um teto utilizável de 200.000 para 1.000.000 de tokens exigiu mudanças na arquitetura de atenção, na descodificação especulativa e na stack de serviço — três peças de engenharia distintas que só produzem uma janela utilizável quando combinadas.
Esta página explica cada uma delas em linguagem simples, com os valores publicados anexados. A versão curta: um indexador partilhado reduz a computação por token em 2.9× com 1M de contexto, uma camada de previsão multi-token redesenhada aumenta o comprimento de aceitação da descodificação especulativa em cerca de 20%, e um conjunto de mudanças de memória e de kernel impede que a capacidade da KV-cache se torne o muro. Todos os valores são tal como publicados pelos autores do modelo.
O problema óbvio do contexto longo é o custo quadrático da atenção, e a atenção esparsa resolve-o em princípio, fazendo com que cada token atenda a um subconjunto selecionado de tokens anteriores em vez de a todos. Mas a atenção esparsa precisa de um indexador — um mecanismo leve que decide a que tokens vale a pena atender — e executar esse indexador em todas as camadas reintroduz um custo que cresce com o comprimento do contexto. Com 200.000 tokens, esse overhead é tolerável. Com um milhão, não é.
O segundo problema é que, passadas algumas centenas de milhares de tokens, o estrangulamento deixa de ser computação de todo. Passa a ser a capacidade da KV-cache, a eficiência dos kernels de contexto longo e o overhead do lado do CPU — um problema de memória e de sistemas, não de matemática. Um modelo pode ser arquitetonicamente capaz de uma janela de um milhão de tokens e continuar a ser impossível de servir se a cache não couber ou o escalonador travar.
O IndexShare é a resposta arquitetónica. Em vez de cada camada do transformer calcular os seus próprios índices top-k, cada quatro camadas partilham um único indexador leve. Ele fica na primeira das quatro e os seus índices top-k são reutilizados pelas outras três — o que remove o produto escalar do indexador e a seleção de top-k de três em cada quatro camadas.
O resultado publicado é uma redução de 2.9× nos FLOPs por token com 1M de contexto, sem qualquer perda de qualidade reportada a longa distância. O IndexShare foi usado a partir do mid-training com sequências de 128K, em vez de ser acoplado apenas no momento da inferência, o que é importante: um esquema de partilha introduzido só no serviço criaria uma incompatibilidade entre a forma como o modelo foi treinado e a forma como corre.
A previsão multi-token acelera a geração ao rascunhar vários tokens à frente e verificá-los em seguida, e a sua eficiência mede-se pelo comprimento de aceitação — quantos tokens rascunhados sobrevivem em média à verificação. Na geração anterior, a camada MTP sofria de uma incompatibilidade entre a KV-cache usada durante o treino e a usada na inferência, o que limitava o comprimento de aceitação a 4.56 ao longo de 7 passos MTP.
O design atual executa o indexador uma vez no primeiro passo de rascunho e reutiliza os índices nos passos seguintes, partilhando tanto os índices como o estado da KV. Acrescentar rejection sampling ao caminho de descodificação especulativa e uma perda de variação total ponta a ponta eleva o comprimento de aceitação para 5.47 — cerca de 20% mais tokens aceites por passagem de verificação. A ablação publicada está abaixo.
| Base | 4.56 |
| + IndexShare + KVShare | 5.10 |
| + Rejection Sampling | 5.29 |
| + Perda TV ponta a ponta | 5.47 (+20%) |
Todos os valores desta página são resultados tal como publicados pelos autores do modelo. O glmmodel.com apenas os reporta; não executa estas avaliações.
Três mudanças respondem ao lado dos sistemas. A gestão de memória baseada em LayerSplit dá um controlo mais fino sobre a forma como o estado do modelo é particionado e paralelizado, para que a alocação de cache deixe de ser tudo ou nada. O trabalho de kernel escalado a contextos longos é coordenado com o pipeline de transferência de cache, para que computação e movimento de memória se sobreponham em vez de serializar. E a gestão de cache do lado do CPU, o escalonamento de pedidos e a afinação dos caminhos de execução removem overhead que é invisível em contexto curto mas dominante em contexto longo.
O efeito reportado é que a vantagem de throughput aumenta à medida que o contexto cresce — quanto mais longo o prompt, maior a diferença face a um caminho de serviço ingénuo. É essa a propriedade que transforma uma janela de contexto de 1M de uma especificação em algo que se consegue realmente correr sob carga.
Vantagem relativa de throughput à medida que o contexto cresce, conforme descrito pelos autores do modelo.
Leia os benchmarks do modelo GLM e depois ponha um modelo real a trabalhar. O playground acima é gratuito e não exige nada de si; se quiser um conjunto de ferramentas de IA mais completo, o plano gratuito do nosso parceiro começa aqui.