La ventana de contexto de 1M de GLM es la característica definitoria del modelo GLM insignia actual, y no es un parámetro de configuración. Elevar el techo utilizable de 200.000 a 1.000.000 de tokens exigió cambios en la arquitectura de atención, en el decodificado especulativo y en el stack de servicio: tres piezas de ingeniería distintas que solo producen una ventana utilizable cuando se combinan.
Esta página explica cada una de ellas en lenguaje llano, con las cifras publicadas asociadas. En resumen: un indexador compartido reduce 2.9× el cómputo por token con 1M de contexto, una capa de predicción multi-token rediseñada eleva la longitud de aceptación del decodificado especulativo en torno a un 20%, y un conjunto de cambios de memoria y kernels evita que la capacidad de KV-cache se convierta en el muro. Todas las cifras son las publicadas por los autores del modelo.
El problema evidente del contexto largo es el coste cuadrático de la atención, y la atención dispersa lo resuelve en principio haciendo que cada token atienda a un subconjunto seleccionado de tokens anteriores en lugar de a todos. Pero la atención dispersa necesita un indexador, un mecanismo ligero que decide a qué tokens merece la pena atender, y ejecutar ese indexador en cada capa reintroduce un coste que crece con la longitud de contexto. Con 200.000 tokens esa sobrecarga es tolerable. Con un millón, no.
El segundo problema es que, pasados unos cientos de miles de tokens, el cuello de botella deja de ser el cómputo por completo. Pasa a ser la capacidad de KV-cache, la eficiencia de los kernels de contexto largo y la sobrecarga en CPU: un problema de memoria y de sistemas más que de matemáticas. Un modelo puede ser arquitectónicamente capaz de manejar una ventana de un millón de tokens y seguir siendo inservible si la caché no cabe o el planificador se atasca.
IndexShare es la respuesta arquitectónica. En lugar de que cada capa del transformer calcule sus propios índices top-k, cada cuatro capas comparten un único indexador ligero. Se sitúa en la primera de las cuatro y sus índices top-k se reutilizan en las otras tres, lo que elimina el producto escalar del indexador y la selección top-k en tres de cada cuatro capas.
El resultado publicado es una reducción de 2.9× en los FLOPs por token con 1M de contexto, sin que se reporte pérdida de calidad a larga distancia. IndexShare se usó desde el entrenamiento intermedio con secuencias de 128K en lugar de añadirse en tiempo de inferencia, y eso importa: un esquema de compartición introducido solo en el servicio crearía un desajuste entre cómo se entrenó el modelo y cómo se ejecuta.
La predicción multi-token acelera la generación esbozando varios tokens por adelantado y verificándolos después, y su eficiencia se mide con la longitud de aceptación: cuántos tokens esbozados sobreviven de media a la verificación. En la generación anterior, la capa MTP sufría un desajuste entre la caché KV usada durante el entrenamiento y la usada en inferencia, que limitaba la longitud de aceptación a 4.56 a lo largo de 7 pasos MTP.
El diseño actual ejecuta el indexador una sola vez en el primer paso del borrador y reutiliza los índices en los pasos siguientes, compartiendo tanto los índices como el estado KV. Añadir muestreo por rechazo a la ruta de decodificado especulativo y una pérdida de variación total de extremo a extremo eleva la longitud de aceptación a 5.47, aproximadamente un 20% más de tokens aceptados por pasada de verificación. La ablación publicada está más abajo.
| Referencia | 4.56 |
| + IndexShare + KVShare | 5.10 |
| + Muestreo por rechazo | 5.29 |
| + Pérdida TV de extremo a extremo | 5.47 (+20%) |
Todas las cifras de esta página son resultados publicados por los autores del modelo. glmmodel.com los reproduce; no ejecuta estas evaluaciones.
Tres cambios abordan el lado de los sistemas. La gestión de memoria basada en LayerSplit da un control más fino sobre cómo se particiona y paraleliza el estado del modelo, de modo que la asignación de caché deja de ser todo o nada. El trabajo de kernels escalado a contextos largos se coordina con la canalización de transferencia de caché, para que cómputo y movimiento de memoria se solapen en lugar de serializarse. Y la gestión de caché en CPU, la planificación de peticiones y el ajuste de rutas en tiempo de ejecución eliminan una sobrecarga invisible con contexto corto pero dominante con contexto largo.
El efecto reportado es que la ventaja de rendimiento se amplía a medida que crece el contexto: cuanto más largo es el prompt, mayor es la distancia respecto a una ruta de servicio ingenua. Esa es la propiedad que convierte una ventana de contexto de 1M de una especificación en algo que realmente puedes ejecutar bajo carga.
Ventaja relativa de rendimiento a medida que crece la longitud de contexto, según la describen los autores del modelo.
Consulta los benchmarks del modelo GLM y luego pon a trabajar un modelo real. El playground de arriba es gratuito y no te pide nada; si quieres un kit de IA más completo, el plan gratuito de nuestro partner empieza aquí.