La atención dispersa de GLM-5.3 reduce el cómputo, pero persiste la demanda de HBM

La atención dispersa de GLM-5.3 reduce la cantidad de contexto que lee cada operación de atención, pero no elimina automáticamente el problema de capacidad de HBM del modelo. Un análisis del 28 de septiembre concluyó que seleccionar tokens relevantes aún puede requerir acceso al historial de contexto completo. El resultado cuestiona una suposición tentadora: que menos tokens atendidos necesariamente implican una reducción proporcional de la memoria de GPU.

La distinción importa porque GLM-5.3 está orientado a tareas de programación y agentes de larga duración, en las que el contexto se acumula entre llamadas a herramientas, archivos, resultados de pruebas y revisiones. La atención dispersa reduce el trabajo dentro del cálculo principal de atención. La caché KV, que almacena representaciones reutilizables de claves y valores de tokens anteriores, puede seguir creciendo con toda la secuencia.

DeepSeek Sparse Attention constituye el punto de referencia arquitectónico. Su indexador identifica un conjunto limitado de tokens útiles antes de que el modelo ejecute su cálculo principal de atención. GLM-5.3 combina ese método con representaciones comprimidas de caché, reutilización de índices entre capas y software de servicio capaz de trasladar entradas inactivas de la caché a la memoria del host.

Por tanto, la competencia central no se limita a atención dispersa frente a atención densa. Se trata de la dispersidad algorítmica frente al requisito físico de mantener disponible una conversación larga. Esa competencia determina si el ahorro de memoria se traduce en menor capacidad de HBM, menor demanda de ancho de banda, mayor concurrencia o simplemente en un equilibrio distinto entre GPU y memoria del sistema.

Lo que realmente cambia la atención dispersa de GLM-5.3

GLM-5.3 reduce la cantidad de trabajo de atención costoso por token, pero el modelo aún necesita una forma de localizar información relevante a lo largo de su historial.

GLM-5.3 pertenece a la familia GLM-5 de Z.ai, que utiliza una arquitectura de mezcla de expertos. Un modelo de mezcla de expertos activa solo una parte de su conjunto total de parámetros para cada token. Según el informe de GLM-5, la familia combina este cómputo enrutado con un diseño de atención de contexto largo derivado del trabajo de DeepSeek.

Z.ai afirma que GLM-5.3 utiliza el mismo modelo base que GLM-5.2. Sus mejoras de capacidades comunicadas proceden del posentrenamiento, y no de otra ronda de preentrenamiento del modelo base. Esa distinción significa que el debate actual sobre memoria se refiere a cómo se comporta la arquitectura existente bajo cargas reales de servicio, no a una nueva capa de atención inventada para GLM-5.3.

El mecanismo relevante es DeepSeek Sparse Attention, o DSA. La atención dispersa limita la atención completa a un subconjunto seleccionado de tokens anteriores, en lugar de procesar todos los tokens previos con el mismo coste. DeepSeek presentó este diseño orientado a producción en su investigación V3.2.

DSA primero ejecuta un componente ligero llamado lightning indexer. El indexador puntúa las posiciones anteriores y elige los tokens top-k, es decir, el conjunto limitado considerado más relevante para la consulta actual. El cálculo principal de Multi-Head Latent Attention opera entonces sobre esas posiciones seleccionadas.

Multi-Head Latent Attention, o MLA, almacena representaciones latentes comprimidas en lugar de un vector completo independiente de clave y valor para cada cabeza de atención. Esta compresión reduce la caché almacenada por token. La selección dispersa reduce después la cantidad de esa caché que lee la operación principal de atención.

Se trata de dos ahorros diferentes. MLA se dirige al tamaño del estado almacenado en caché de cada token. DSA se dirige al número de posiciones en caché consumidas por el costoso cálculo de atención.

La combinación modifica de forma sustancial el perfil de cómputo y ancho de banda. La atención central puede pasar de procesar relaciones en todo el contexto a procesar una selección top-k fija. Con secuencias largas, esto limita el crecimiento de la carga de trabajo principal de atención.

Sin embargo, el lightning indexer aún necesita suficiente información para puntuar candidatos a lo largo del historial conservado. El modelo no puede seleccionar un token antiguo si el sistema de servicio ha descartado toda representación utilizable de ese token.

El análisis de SemiAnalysis identifica este punto como el límite crucial. La atención dispersa reduce el tráfico de memoria durante la operación central de atención de producto escalar escalado. No reduce necesariamente la capacidad total de memoria necesaria para conservar el contexto que puede seleccionarse.

Ese límite se vuelve más claro por debajo del umbral de dispersidad. DSA utiliza una configuración top-k de 2.048 posiciones en la configuración analizada por SemiAnalysis. Una secuencia que contiene menos posiciones no dispone de un conjunto mayor que podar, por lo que la atención sigue siendo densa.

Los motores de servicio también eligen distintos modos de ejecución según la longitud de la secuencia y la topología de despliegue. Una implementación puede priorizar un modo de menor cómputo para contextos más cortos y pasar después a un modo de menor uso de memoria a medida que el tráfico de memoria se vuelve dominante. Por tanto, la atención dispersa no ofrece una aceleración fija para cada solicitud.

El cambio significativo es más acotado y útil. La atención dispersa de GLM-5.3 reduce el coste recurrente de consultar un historial largo. No hace que ese historial deje de existir.

Por qué un menor tráfico de atención no equivale a menor capacidad de HBM

La presión sobre la HBM procede del contexto retenido, mientras que la atención dispersa cambia principalmente qué entradas retenidas lee la GPU durante cada operación.

La memoria de alto ancho de banda, o HBM, es la memoria rápida conectada directamente a un acelerador. Su ancho de banda ayuda a las GPU a alimentar grandes operaciones matriciales, mientras que su capacidad limitada restringe cuántos modelos y solicitudes activas caben en cada dispositivo.

Durante la generación autorregresiva, un modelo produce un token tras otro. Reutiliza las claves y valores calculados para tokens anteriores mediante la caché KV. Sin esa caché, el servidor tendría que recalcular repetidamente toda la secuencia precedente.

Por tanto, cada solicitud activa reserva memoria para su contexto. Una sesión larga de programación puede incluir archivos de repositorio, salida de comandos, intentos de parche, registros de pruebas y razonamiento anterior. Un agente puede producir muchos más tokens que un intercambio ordinario de preguntas y respuestas.

La atención dispersa modifica el patrón de lectura. En vez de cargar cada posición histórica en la operación principal de atención, el modelo carga el conjunto top-k seleccionado. Esto puede reducir el consumo de ancho de banda de memoria y el cómputo realizado tras la selección.

La capacidad sigue una regla distinta. Si cualquier posición anterior continúa siendo apta para su selección, su representación debe seguir siendo accesible en algún lugar. Un diseño de servicio convencional mantiene todo el historial KV en HBM, incluso cuando el kernel principal de atención lee solo un subconjunto pequeño.

El sistema resultante puede quedar limitado por capacidad antes que por cómputo. Cada solicitud puede ejecutar menos trabajo de atención, pero seguir ocupando memoria proporcional a la longitud de su contexto. Aumentar la concurrencia coloca entonces más historiales completos en el mismo dispositivo.

Esto explica por qué la atención dispersa no se traduce directamente en una reducción equivalente de la demanda de HBM. El sistema ahorra tráfico activo sin reducir necesariamente el estado residente. La visión lógica que tiene el modelo de su historial sigue siendo completa, incluso cuando cada paso de atención es selectivo.

La diferencia se parece a un gran archivo con un sistema rápido de recuperación. Una recuperación más rápida reduce cuántos documentos se leen para cada pregunta. No reduce el tamaño del archivo salvo que los documentos antiguos se trasladen a otro lugar o desaparezcan.

La compresión de la caché KV de GLM-5.3 sigue siendo importante. Las representaciones más pequeñas por token permiten que quepa más contexto dentro de un presupuesto de memoria dado. También reducen los bytes transferidos cuando las entradas seleccionadas participan en una operación de atención.

Sin embargo, el estado comprimido sigue acumulándose con la longitud de la secuencia. Una curva lineal de memoria más pequeña sigue siendo una curva lineal de memoria. Los contextos largos y muchas solicitudes simultáneas pueden acabar consumiendo la capacidad ahorrada.

La concurrencia deja rápidamente al descubierto esta compensación. SemiAnalysis informó de resultados en los que aumentar las solicitudes simultáneas de ocho a dieciséis redujo la reutilización de tokens de prompt desde la memoria de GPU. La proporción de reutilización en GPU cayó del 90,3 por ciento al 54,8 por ciento.

La reutilización desde la memoria del host subió del 6,0 por ciento al 40,3 por ciento en la misma comparación. La tasa combinada de aciertos de caché se mantuvo por encima del 95 por ciento en cada nivel de concurrencia comunicado. Estos resultados muestran que la capacidad de caché útil puede extenderse más allá del acelerador.

No significan que la memoria del host iguale la latencia de HBM. Mover datos a través de la conexión CPU-GPU genera un coste de E/S, y los fallos de caché pueden interrumpir una ruta de decodificación que, de otro modo, sería eficiente. El sistema de servicio debe predecir, obtener y desalojar datos sin que las transferencias dominen el tiempo de generación.

La implicación para el mercado de memoria también es más matizada que una simple caída de la demanda. La atención dispersa puede reducir el tráfico de HBM por paso de atención. Al mismo tiempo, una inferencia de contexto largo más barata puede fomentar sesiones más largas y una mayor concurrencia de solicitudes.

Ese efecto rebote importa para la planificación de infraestructura. Cuando cada solicitud se vuelve menos costosa de procesar, los operadores suelen admitir más trabajo simultáneo. El ancho de banda de memoria ahorrado puede convertirse en rendimiento adicional en lugar de hardware sin utilizar.

Por tanto, la demanda de HBM puede persistir incluso a medida que la atención se vuelve más selectiva. La demanda de DRAM del host también puede aumentar porque los historiales completos se trasladan a un nivel de memoria más grande y más lento. A escalas aún mayores, los sistemas de almacenamiento pueden absorber prefijos reutilizables o datos de caché inactivos.

La cuestión práctica ya no es si la atención dispersa ahorra memoria en abstracto. Es qué nivel de memoria aloja cada parte de la caché KV de GLM-5.3 y con qué frecuencia la mueve el motor de servicio.

HiSparse saca el historial completo de la GPU

HiSparse convierte las lecturas selectivas de la atención dispersa en ahorros reales de capacidad de HBM al separar la disponibilidad lógica de la caché de su residencia física en la GPU.

El equipo de SGLang diseñó HiSparse como una caché KV jerárquica para el servicio de atención dispersa. Mantiene un pequeño conjunto de trabajo en la GPU mientras almacena todo el historial KV en memoria del host fijada. La memoria fijada es memoria de CPU preparada para transferencias predecibles a un acelerador.

Con este diseño, las entradas antiguas de caché siguen estando lógicamente disponibles para GLM-5.3. No todas permanecen físicamente residentes en HBM. El indexador puede seleccionar una posición, y el sistema de servicio puede recuperar esa posición cuando la GPU no la tiene.

HiSparse utiliza una política de uso menos reciente para su caché de dispositivo. Cuando los tokens seleccionados no están presentes en HBM, el sistema los carga desde la memoria del host. Desaloja entradas utilizadas menos recientemente para mantener acotado el conjunto de trabajo de la GPU.

Esta arquitectura convierte una propiedad a nivel de modelo en un ahorro a nivel de sistema. La atención dispersa identifica el pequeño conjunto requerido por la operación actual. HiSparse garantiza que solo una selección limitada y un búfer de trabajo deban ocupar HBM durante la decodificación.

El artículo de HiSparse describe el sistema como exacto e independiente del indexador. Exacto significa que la ubicación de la caché cambia sin aproximar deliberadamente la salida de atención seleccionada por el modelo. Independiente del indexador significa que el gestor de memoria no depende de un único algoritmo de selección.

Sus evaluaciones cubren DSA, Native Sparse Attention y Quest en plataformas H200, B200 y GH200. Los autores informan de hasta 4,7 veces mayor rendimiento máximo de generación en cargas de trabajo de contexto largo.

Se trata de un resultado de sistema bajo configuraciones probadas, no de un multiplicador de velocidad garantizado para GLM-5.3. La longitud de la carga de trabajo, la concurrencia de solicitudes, el ancho de banda de interconexión, la localidad de selección y las tasas de fallos de caché afectan todos al resultado.

HiSparse también superpone las transferencias con computación útil. Mientras se ejecuta una capa, el sistema puede preparar entradas de caché seleccionadas para una capa posterior. Esta superposición por capas oculta parte de la latencia creada por el movimiento del host al dispositivo.

La reutilización entre capas facilita esa programación. Si las capas adyacentes seleccionan muchas de las mismas posiciones, el sistema conoce de antemano la probable demanda de caché. Las entradas recuperadas para una capa pueden seguir siendo útiles para las siguientes.

El coste restante es la E/S. Un fallo de selección requiere que los datos viajen desde la memoria de la CPU hasta HBM. Los fallos frecuentes, las selecciones dispersas o un ancho de banda limitado entre host y dispositivo pueden eliminar parte de la ganancia de rendimiento.

Ese riesgo separa la dispersión teórica de la eficiencia en producción. Un kernel disperso puede leer menos entradas una vez que llegan. El sistema completo aún debe encontrar esas entradas, transferirlas, asignarlas a páginas utilizables y coordinar su ciclo de vida.

El tiempo hasta el primer token introduce otra limitación. El prefill, que procesa el prompt inicial, tiene características distintas de la decodificación token a token. HiSparse se dirige principalmente a la fase de decodificación, donde la caché ya existe y crece con la generación continuada.

La implementación de SGLang combina HiSparse con la desagregación de prefill y decodificación. Esa arquitectura asigna el procesamiento del prompt y la generación de tokens a distintos workers. Así, cada fase puede usar una distribución de memoria y una asignación de hardware adecuadas para su carga de trabajo.

El diseño también modifica la demanda de infraestructura. HBM se convierte en una caché caliente en lugar de ser el único almacén de la conversación activa. La DRAM del host conserva el historial más amplio, mientras que la interconexión pasa a formar parte de la ruta crítica.

Esto puede reducir la capacidad de HBM necesaria para cada solicitud de decodificación. No elimina los bytes que representan la conversación. Reubica muchos de ellos y añade software responsable de mantener cerca de la GPU el subconjunto adecuado.

Por tanto, para los operadores, la métrica relevante no es solo el tamaño del modelo o la longitud máxima de contexto. Deben considerar la huella de HBM por solicitud, la asignación de memoria del host, la tasa de fallos, el volumen de transferencia y la latencia de los tokens de salida con una concurrencia realista.

La atención dispersa hace posible ese diseño por niveles. HiSparse lo hace operativo. Ninguno de los dos hace que la gestión de memoria sea gratuita.

IndexShare Reduce el Coste de Encontrar Tokens Relevantes

Una vez que la atención completa se vuelve dispersa, el propio indexador se convierte en un cuello de botella visible, por lo que la siguiente optimización de GLM reutiliza decisiones de selección entre capas.

Una capa DSA estándar tiene su propio indexador lightning. Ese componente puntúa los tokens históricos antes de que el cálculo principal de atención seleccione su conjunto top-k. El indexador es más ligero que la atención completa, pero aun así examina el contexto.

A medida que crece el contexto, puntuar repetidamente cada posición histórica en cada capa se vuelve costoso. La ruta principal de atención se ha reducido, por lo que un trabajo que antes parecía menor representa una proporción mayor de la latencia total.

Z.ai aborda este problema con IndexShare, también descrito públicamente como IndexCache. En lugar de ejecutar un indexador independiente en cada capa de atención dispersa, grupos de capas reutilizan una selección compartida.

El enfoque se basa en un patrón observado: las capas vecinas suelen elegir muchos de los mismos tokens históricos. El estudio de IndexCache informa de una superposición del 70 al 100 por ciento entre las selecciones top-k de capas adyacentes en su análisis.

Esa superposición genera redundancia. Una capa completa designada puede calcular un índice, mientras que las capas compartidas posteriores reutilizan las posiciones seleccionadas. El patrón de producción analizado para GLM asigna un indexador a grupos de cuatro capas DSA.

En un modelo DSA de 30.000 millones de parámetros, los investigadores eliminaron hasta el 75 por ciento de los cálculos del indexador con una degradación de calidad reportada como insignificante. Midieron un prefill hasta 1,82 veces más rápido y una decodificación hasta 1,48 veces más rápida frente a DSA estándar.

El artículo también presenta resultados preliminares de GLM-5 a escala de producción. Estos hallazgos respaldan el mecanismo, pero no sustituyen pruebas independientes amplias en cargas de trabajo y stacks de serving de GLM-5.3.

La reutilización de selecciones introduce su propio requisito de entrenamiento. Un indexador compartido debe identificar tokens que sirvan a varias capas, no simplemente ajustarse a la distribución de atención de una sola capa. IndexCache entrena los indexadores conservados con respecto a un promedio de las distribuciones de atención a las que dan soporte.

Ese ajuste importa porque las capas consecutivas están relacionadas, pero no son idénticas. Una capa temprana puede priorizar detalles léxicos, mientras que una capa posterior podría favorecer una dependencia formada durante el procesamiento intermedio. La reutilización se vuelve perjudicial si elimina un token necesario solo para un miembro del grupo.

Por tanto, el método expone una segunda compensación. Más compartición elimina trabajo adicional del indexador. Menos compartición preserva más comportamiento de selección específico de cada capa.

IndexShare también interactúa con HiSparse. Cuando las capas comparten un índice, el motor de serving puede reutilizar las entradas de caché recuperadas entre esas capas. Las selecciones compartidas reducen el cálculo top-k repetido y pueden hacer más predecible la recuperación del host al dispositivo.

Esta combinación ataca tres costes distintos:

• MLA comprime la representación almacenada para cada token.

• DSA restringe la atención completa a posiciones históricas seleccionadas.

• IndexShare evita recalcular selecciones similares en cada capa.

• HiSparse traslada las entradas KV inactivas de HBM a la memoria del host.

Estos componentes no deben reducirse a una sola afirmación sobre memoria. La compresión afecta los bytes por token. La atención dispersa afecta las lecturas activas. La compartición de índices afecta la sobrecarga de selección. La descarga afecta la ubicación física.

Cada capa de optimización puede desplazar el cuello de botella a otro lugar. Las cachés más pequeñas pueden revelar sobrecarga de cómputo. Una atención principal más barata puede revelar latencia del indexador. La descarga puede revelar limitaciones de ancho de banda de transferencia. Una mayor concurrencia puede revelar límites de capacidad de memoria del host.

Las características del hardware determinan qué cuello de botella aparece primero. SemiAnalysis estimó un perfil de intensidad aritmética que sugiere que la configuración de atención de GLM difiere del equilibrio de DeepSeek orientado a H800. También vinculó el diseño de GLM con el respaldo del fabricante chino de aceleradores Moore Threads.

Esa interpretación del hardware sigue siendo una inferencia, no un objetivo de diseño de Z.ai divulgado. GLM-5.3 admite múltiples frameworks de serving y plataformas de aceleradores, por lo que los operadores deberían medir el modelo en su propia ruta de despliegue.

La lección más amplia es que la atención dispersa de GLM-5.3 no puede evaluarse mediante un único recuento de FLOP. El rendimiento de serving surge del comportamiento conjunto de su indexador, caché comprimida, jerarquía de memoria, kernels y carga de trabajo.

La Verdadera Prueba Es la Eficiencia de Memoria en Producción

GLM-5.3 validará su diseño de memoria solo si los operadores pueden mantener sesiones largas de agentes sin trasladar costes inaceptables a la latencia, la DRAM o la complejidad operativa.

La primera señal que hay que observar son los benchmarks independientes de GLM-5.3 con contextos largos y alta concurrencia. La velocidad máxima de una sola solicitud revela poco sobre un servicio que gestiona muchos agentes persistentes. Las pruebas deberían informar conjuntamente del uso de HBM, el uso de DRAM del host, los fallos de caché y las distribuciones de latencia.

Un resultado convincente mostraría que la descarga de caché KV de GLM-5.3 admite más solicitudes simultáneas mientras mantiene estable la latencia por token. Si el rendimiento aumenta solo tras aceptar grandes picos de latencia, el ahorro de memoria tiene un valor limitado para los agentes de programación interactivos.

La segunda señal es un soporte de despliegue más amplio para HiSparse y gestores de memoria similares. SGLang ha integrado HiSparse, y vLLM también ha documentado trabajo en torno a la arquitectura. Un comportamiento consistente entre motores reforzaría la idea de que los modelos dispersos pueden utilizar residencia limitada en HBM en producción.

Un soporte fragmentado de kernels debilitaría esa conclusión. La atención dispersa depende de selección especializada, gestión de páginas, formatos de caché y kernels de atención. Un modelo puede tener pesos abiertos y seguir siendo difícil de servir eficientemente fuera de un stack de software reducido.

La tercera señal es evidencia sobre la calidad de los agentes a largo plazo. La optimización de memoria solo importa si el modelo recupera de forma fiable requisitos anteriores, decisiones de código y resultados de herramientas. Los errores de selección que aparecen tarde en una sesión pueden ser difíciles de diagnosticar.

La estrategia de postentrenamiento de GLM-5.3 hace que esto sea especialmente relevante. Z.ai afirma que el modelo mejoró su capacidad de programación en un 50 por ciento frente a GLM-5.2 en su benchmark interno Z.ai Code Bench. Sigue siendo una comparación reportada por la empresa.

Z.ai también informa de un resultado del 84,5 por ciento en CyberGym, frente al 77,2 por ciento de GLM-5.2. CyberGym mide si un modelo puede encontrar y validar vulnerabilidades de software a partir del código fuente. El lanzamiento de GLM-5.3 presenta estas mejoras como evidencia de capacidades agentivas y de ciberseguridad más sólidas.

Estas capacidades aumentan tanto la utilidad como el riesgo. Las sesiones más largas impulsadas por herramientas pueden facilitar el análisis de repositorios, las pruebas y la investigación de vulnerabilidades. Esa misma persistencia puede ayudar a automatizar pasos de explotación o conservar material sensible dentro de una caché de serving.

Por consiguiente, la ubicación de memoria tiene una dimensión de seguridad. La DRAM del host, las cachés de prefijos compartidas y las capas de caché distribuidas amplían los lugares donde puede residir el estado de una conversación. Los operadores necesitan aislamiento, expulsión, control de acceso y observabilidad en todos los niveles.

El trabajo de optimización asíncrona de un solo rollout del modelo pertenece a este contexto, aunque no reduce directamente la memoria de inferencia. SAO se entrena con un rollout por prompt y utiliza un modelo de valor independiente para estimar retornos a nivel de token.

El artículo de SAO afirma que el método aborda la inestabilidad y los efectos off-policy en el entrenamiento asíncrono de agentes. Se implementó en el pipeline de entrenamiento agentivo de GLM-5.2 e informa el linaje de postentrenamiento detrás de GLM-5.3.

SAO puede mejorar la eficiencia de entrenamiento para trayectorias largas y desiguales de agentes. También conlleva sobrecarga adicional de entrenamiento porque el modelo de valor se ejecuta junto al modelo de política. Es otro ejemplo de reducir un cuello de botella aceptando un coste en otro lugar.

Para los equipos empresariales, la tarea inmediata es una evaluación disciplinada. Realicen seguimiento del prompt completo, el contexto seleccionado, la ubicación de caché, el comportamiento de fallos, la latencia de salida y el éxito de tareas bajo la misma carga de trabajo. Las cifras agregadas de tokens por segundo ocultan demasiado.

Los equipos también necesitan registros duraderos de las configuraciones de modelos y los experimentos de serving. Una base de conocimiento con capacidad de búsqueda puede conectar resultados de benchmarks con versiones de kernels, configuraciones de caché e incidentes de despliegue.

La atención dispersa de GLM-5.3 cambia la economía de leer contextos largos. No elimina el requisito de preservarlos. La arquitectura reduce el tráfico de atención activa, mientras que IndexShare reduce la sobrecarga de selección y HiSparse limita la residencia en la GPU.

La pregunta para la próxima oleada de benchmarks es concreta: ¿puede GLM-5.3 convertir esos ahorros en concurrencia sostenida sin trasladar el cuello de botella a las transferencias del host o a la calidad de recuperación? Observe la ocupación medida de HBM, la latencia de fallos de caché y la precisión en agentes de larga duración. En conjunto, esas señales mostrarán si la atención dispersa ofrece un mejor sistema de serving en lugar de un mejor kernel de forma aislada.